7.Events Of EJB

Execution of EJBs

With EJB 2.1 and earlier, each EJB had to provide a Java implementation classand two Java interfaces. The EJB container created instances of the Java implementation class to provide the EJB implementation. The Java interfaces were used by client code of the EJB.

The two interfaces, referred to as the Home and the Component interface, specified the signatures of the EJB's remote methods. The methods were split into two groups:

class methods - not tied to a specific instance, such as those used to create an EJB instance (factory method) or to find an existing entity EJB (see EJB Types, below). These were declared by the Home interface.

instance methods, i.e. methods tied to a specific instance. These are placed in the Component interface.

Because these are merely Java interfaces and not concrete classes, the EJB container must generate classes for these interfaces that will act as a proxy in the client. Client code invokes a method on the generated proxies, which in turn places the method arguments into a message and sends the message to the EJB server.

Remote Communication

The EJB specification requires that EJB containers support accessing the EJBs using RMI-IIOP. EJBs may be accessed from any CORBA application or provide Web Services.

Transactions

EJB containers must support both container managed ACID transactions and bean managed transactions. Container-managed transactions use a declarative syntax for specifying transactions in the deployment descriptor.

Events

JMS is used to send messages from the beans to client objects, to let clients receive asynchronous messages from these beans. MDB can be used to receive messages from client applications asynchronously using either a JMS Queue or a Topic.

Naming and Directory Services: Clients of the EJB locate the Home Interface implementation object using JNDI. The Home interface may also be found using the CORBA name service. From the home interface, client code can find entity beans, as well as create and delete existing EJBs.

Security

The EJB container is responsible for ensuring the client code has sufficient access rights to an EJB.

Deploying EJBs The EJB Specification also defines a mechanism that lets EJBs bedeployed in a similar manner regardless of the specific EJB platform that is chosen. Information about how the bean should be deployed (such as the name of the Home or Remote interfaces, whether and how to store the bean in a database, etc.) are specified in the deployment descriptor.

The deployment descriptor is an XML document having an entry for each EJB to be deployed. This XML document specifies the following information for each EJB:

• Name of the Home interface
• Java class for the Bean (business object)
• Java interface for the Home interface
• Java interface for the business object
• Persistent store (only for Entity Beans)
• Security roles and permissions

EJB containers from many vendors require more deployment information than that in the EJB specification. They will require the additional information as separate XML files, or some other configuration file format. An EJB platform vendor generally provides their own tools that will read this deployment descriptor, and possibly generate a set of classes that will implement the Home and Remote interfaces.

Version History:

EJB 3.0, final release (2006-05-02)

Major changes: Annotations, alternative to deployment descriptors

EJB 2.1, final release (2003-11-24)

Major changes: Web service support (new): stateless session beans can be invoked over SOAP/HTTP. Also, an EJB can easily access a Web service using the new service reference.

EJB timer service (new): Event-based mechanism for invoking EJBs at specific times.

Message-driven beans accepts messages from sources other than JMS.

Message destinations (the same idea as EJB references, resource references, etc.) has been added.

EJB query language (EJB-QL) additions: ORDER BY, AVG, MIN, MAX, SUM, COUNT, and MOD.

XML schema is used to specify deployment descriptors, replaces DTDs

Overall goals

The standard component architecture for building distributed object-oriented business applications in the Java.

Make it possible to build distributed applications by combining components developed using tools from different vendors.

Make it easy to write (enterprise) applications: Application developers will not have to understand low-level transaction and state management details, multi-threading, connection pooling, and other complex low-level APIs.

Will follow the Write Once, Run Anywhere - philosophy of the Java. An enterprise Bean can be developed once, and then deployed on multiple platforms without recompilation or source code modification.

Address the development, deployment, and runtime aspects of an enterprise application’s life cycle.

Define the contracts that enable tools from multiple vendors to develop and deploy components that can interoperate at runtime.

Be compatible with existing server platforms. Vendors will be able to extend their existing products to support EJBs.

Be compatible with other Java APIs.

Provide interoperability between enterprise Beans and Java 2 Platform Enterprise Edition (J2EE) components as well as non-Java programming language applications.

Be compatible with the CORBA protocols (RMI-IIOP).