Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in /home4/vir007/public_html/ on line 2
Free Online EJB Intro Tutorials in EJB,EJB Intro in EJB
Search Site

Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in /home4/vir007/public_html/ on line 2
J2SE [Java 2 Standard Edition]
Core Java Introduction
Exception Handling
Collection & Util Classes
Input & Output Streams
Adwance Windows Toolkit (AWT)
Swings (Adwance GUI)
Event Handling
Java Networking
Remote Method Invocation (RMI)
Java Database Connectivity (JDBC)
J2EE [Java 2 Enterprise Edition]
Java 2 Enterprise Edition Intoduction (J2EE)
Server Side Programming (Servlet)
Java Server Pages (JSP)
Enterprise Java Bean
MVC Framework (Struts)
Advance Framework (Springs)
Object-relational mapping (Hibernate)
eXtensible Markup Language (XML)
Asynchronous JavaScript and XML (AJAX)
Monthly News Letter
Free SCJP Samples
Interviews Questions For Freshers
Interviews Questions For Experinced
Most Visited Links
Most Freaky Links

Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in /home4/vir007/public_html/ on line 2

Enterprise Java Beans Overview

An enterprise java bean is a server-side software component that can be deployed in a distributed multitier

Why we need an application server to deploy Ejbs?

EJB servers give you a bunch of services, so that you don’t have to write them yourself:
• Transaction Management
• Security
• Concurrency
• Networking
• Resource management
• Persistence
• Messaging
• Deploy time customization

Your beans run under the control (and protection) of the EJB server. The server steps into the middle of every
method call from a client to a bean and insert the “services” like security, transactions, and persistence.

EJB Overview

Types of Beans and Clinets of EJB

Types of Beans

Session beans: Session beans model business processes. They are like verbs because they are actions. The
action could be anything, such as adding numbers, accessing a database, calling a legacy system, or calling
other enterprise beans. Examples include a pricing engine, a workflow engine, a catalog engine, a credit card
authorizer, or a stock-trading engine.

Entity beans: Entity beans model business data. They are like nouns because they are data objects—that is,
Java objects that cache database information. Examples include a product, an order, an employee, a credit card,
or a stock. Session beans typically harness entity beans to achieve business goals, such as a stock-trading engine
(session bean) that deals with stocks (entity beans).

Message-driven beans: Message-driven beans are similar to session beans in that they are actions. The
difference is that you can call message-driven beans only by sending messages to those beans. Examples of
message-driven beans include beans that receive stock trade messages, credit card authorization messages, or
workflow messages. These message driven beans might call other enterprise beans as well. Messaging put
asynchronous behavior in the application.

TYpes of beans

Clients of EJB Component System
The following diagram shows some of the many possibilities of clients interacting with an EJB component

EJB Client

Distributed Objects and Middleware

Distributed objects are great because they allow you to break up an application across a network. However, as a
distributed object application gets larger, you need help from middleware services, such as transactions, security

Implicit Middleware (or Declarative Middleware or Request Interceptor)
The crucial difference between systems of the past (transaction processing monitors such as TUXEDO or CICS,
or traditional distributed object technologies such as CORBA, DCOM, or RMI) and the newer, componentbased
technologies (EJB, CORBA Component Model, and Microsoft.NET)
is that in this new world, you
can harness complex middleware in your enterprise applications without writing to middleware APIs. This is
shown in the next figure, and works as follows:

Write your distributed object to contain only business logic. Do not write to complex middleware APIs.
For example, this is the code that would run inside the distributed object:
    transfer(Account account1, Account account2, long amount) {   
        // 1: Subtract the balance from one account, add to the other

2. Declare the middleware services that your distributed object needs in a separate descriptor file, such
as a plain text file. For example, you might declare that you need transactions, persistence, and a security

3. Run a command-line tool provided for you by the middleware vendor. This tool takes your descriptor file as
input and generates an object that we’ll call the request interceptor.

4. The request interceptor intercepts requests from the client, performs the middleware that your distributed
object needs (such as transactions, security, and persistence), and then delegates the call to the distributed

Distributed Object in EJB

The values of implicit middleware are:

Easy to write: You don’t actually write any code to middleware APIs; rather, you declare what you need in a
simple text file. The request interceptor provides the middleware logic for you transparently. You focus away
from the middleware and concentrate on your application’s business code. This is truly divide and conquer!

Easy to maintain: The separation of business logic and middleware logic is clean and maintainable. It is less
code, which makes things simpler. Furthermore, changing middleware does not require changing application

Easy to support:
Customers can change the middleware they need by tweaking the descriptor file. For
example, they can change how a security check is done without modifying source code. This avoids upgrade
headaches and intellectual property issues.