EJB

Enterprise Java Beans Overview

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

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.

Types of Beans and Clinets of EJB 

  

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.
 

 

Clients of EJB Component SystemThe following diagram shows some of the many possibilities of clients interacting with an EJB component
system.
 

 

 

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
etc.

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:

1. 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
check.

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
object.


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
code.

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.

What Constitutes an Enterprise Bean?

An enterprise bean component is not a single monolithic file—a number of files work together to make up an
enterprise bean.

For e.g. writing a SessionBean we require
    1. A bean class that implements SessionBean interface.
    2. Two remote interfaces, one extending EJBObject interface and other extends EJBHome interface.
    3. Deployment descriptor, ejb-jar.xml file having declaration of the beans, their remote interfaces and what
        they expect from container.

The EJB ObjectEnterprise beans are not full-fledged remote objects. When a client wants to use an instance of an enterprise
bean class, the client never invokes the method directly on an actual bean instance. As a component developer,
this means your life is simplified greatly because you can rapidly develop components without writing,
debugging, or maintaining code that calls middleware APIs.

The EJB object is a surrogate object that knows about networking, transactions, security, and more. It is an
intelligent object that knows how to perform intermediate logic that the EJB container requires before a method
call is serviced by a bean class instance. An EJB object is the request interceptor, or the glue, between the client
and the bean. EJB objects replicate and expose every business method that the bean itself exposes. EJB objects
delegate all client requests to beans.
EJB Object is depicted below:



You should think of EJB objects as physical parts of the container; all EJB objects have container-specific code
inside of them. (Each container handles middleware differently and provides different qualities of service.)
Because each bean’s EJB object is different, your container vendor generates the class file for your EJB objects
automatically.

Each EJB container ships with a suite of glue-code tools. These tools are meant to integrate beans into the EJB
container’s environment. The tools generate helper Java code—stubs, skeletons, data access classes, and other
classes that this specific container requires. Bean providers do not have to think about the specifics of how each
EJB container works because the container’s tools generate its own proprietary Java code automatically.

The container’s glue-code tools are responsible for transforming an enterprise bean into a fully managed,
distributed server-side component. This involves logic to handle resource management, life cycle, state
management, transactions, security, persistence, remote accessibility, and many other services. The generated
code handles these services in the container’s proprietary way.

The Home Object
The client cannot instantiate an EJB object directly because the EJB object can exist on a different machine than
the one the client is on. Similarly, EJB promotes location transparency, so clients should never be aware of
exactly where an EJB object resides.

To acquire a reference to an EJB object, your client code asks for an EJB object from an EJB object factory.
This factory is responsible for instantiating (and destroying) EJB objects. The EJB specification calls such a
factory a home object.

The chief responsibilities of home objects are the following:• Create EJB objects• Find existing EJB objects (for entity beans)• Remove EJB objects

Just like EJB objects, home objects are proprietary and specific to each EJB container. They contain interesting
container-specific logic, such as load-balancing logic, logic to track information on a graphical administrative
console, and more. And just like EJB objects, home objects are physically part of the container and are autogenerated
by the container vendor’s tools.




Deployment Descriptors
To inform the container about your middleware needs, you as a bean provider must declare your components’
middleware service requirements in a deployment descriptor file. For example, you can use a deployment
descriptor to declare how the container should perform lifecycle management, persistence, transaction control,
and security services. The container inspects the deployment descriptor to fulfill the requirements that you lay
out. The deployment descriptor is the key to implicit middleware.

For example, you can use a deployment descriptor to specify the following requirements of your bean.
Bean management and lifecycle requirements
Persistence requirements (entity beans only)
Transaction requirements
Security requirements



-------------------------------------------------------------------------------------------------------------------------