About Opentopia
Opentopia Directory Encyclopedia Tools

Enterprise JavaBean

Encyclopedia : E : EN : ENT : Enterprise JavaBean

 

This article or section is in need of attention from an expert on the subject.
Please help recruit one, or improve this page yourself}} if you can. See [discussion page] for details.
The Enterprise JavaBeans (EJB) specification is one of the several Java APIs in the Java Platform, Enterprise Edition. EJB is a server-side component that encapsulates the business logic of an application. The EJB specification was originally developed by Sun Microsystems (EJB 1.0 and 1.1) and later under the Java Community Process as [JSR 19] (EJB 2.0), [JSR 153] (EJB 2.1) and [JSR 220] (EJB 3.0).

The EJB specification details how an application server provides:

Additionally, the Enterprise JavaBean specification defines the roles played by the EJB container and the EJBs as well as how to deploy the EJBs in a container.

EJBs are deployed in an EJB container within the application server. The specification describes how an EJB interacts with its container and how client code interacts with the container/EJB combination. The EJB classes used by applications are included in the package. (The package is a service provider interface used only by EJB container implementations.)

Each EJB must provide a Java implementation class and two Java interfaces. The EJB container will create instances of the Java implementation class to provide the EJB implementation. The Java interfaces are used by client code of the EJB.

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

Note: Additionally Home or the Component Interfaces can be Local or Remote

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. ''' The proxies use RMI-IIOP to communicate with the EJB server.

The server will invoke a corresponding method on an instance of the Java implementation class to handle the remote method invocation.

-->'''

Contents

[Title missing]

Home interface

The Home interface lets client code manipulate certain class methods (that is, methods that are not associated with any particular instance) of the EJB. An EJB Home interface extends either the or interface. The EJB container provides the actual implementation of a bean's Home interface(s).

The EJB 1.1 specification fixes the kind of class methods that can be defined to either be methods to create an EJB or to find an existing EJB if it is an entity bean.

The EJB 2.0 specification lets application developers define new class methods beyond create, delete, and find.

The Home interface defines the lifecycle methods of an EJB class, which includes creating, instantiating, and destroying the instance of EJB from the container.

Remote and local interfaces

The remote and local interfaces define the instance-specific methods of the bean class that may be called by the bean client's code. A bean provides either a remote or local interface, or both. The local interface can only be used by clients running in the same EJB container and same Java virtual machine; the remote interface can be used by both distributed and local clients.

A local interface defines the object used by local client code to call methods on the EJB. A local interface extends the interface .

The remote interface defines the remote object used by the client code to call methods on the EJB. A remote interface extends the interface . Unlike a local interface, each method in a remote interface declares that it "throws ".

Remote and local interfaces have different method call semantics. A local interface uses call by reference semantics for object parameters to EJB methods, the same as ordinary Java method invocations. A remote interface uses call by value semantics. The difference between call-by-reference and call-by-value becomes important if the EJB changes the state of the object parameters—changing the state of a call-by-value parameter only changes the state of the copy of the object in the method, whereas changing the state of a call-by-reference parameter changes the state of the original object.

EJB implementation class

EJB implementation classes are supplied by the application developers. They contain business logic or hold the business data for the object interface. They implement all the methods specified by the Remote interface, and potentially some of those specified by the Home interface.

Correspondence between interface methods and implementation methods

Method invocations on the Home interface are dispatched to the corresponding methods on the bean implementation class with 1) the prefix 'ejb'; 2) the first letter of the Home interface method capitalized; and 3) having exactly the same argument types.

Method invocations on the Remote interface are dispatched to the corresponding implementation method having the same name and arguments.

EJB types

An EJB container can hold four major categories of beans:

Stateless session beans are distributed objects that do not have state associated with them thus allowing concurrent access to the bean. The contents of instance variables are not guaranteed to be preserved across method calls.

Stateful session beans are distributed objects having state. The state could be persisted, but access to the bean instance is limited to only one client.

Entity beans are distributed objects having persistent state. The persistent state may or may not be managed by the bean itself. Beans in which their container manages the persistent state are said to be using Container-Managed Persistence (CMP), whereas beans that manage their own state are said to be using Bean-Managed Persistence (BMP).

Message Beans are distributed objects that respond to JMS messages. These beans were added in the EJB 2.0 specification to allow event-driven beans.

Remote communication

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

Transactions

EJB containers must support both container managed 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.

Naming and directory services

Clients of the enterprise Java bean 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 enterprise Java beans be deployed 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:

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.

Recommended programming model

EJBs should be used in large, distributed, transaction-intensive enterprise scenarios where scalability is a key factor.

In the recommended programming model from Sun, stateful and stateless session beans should encapsulate business logic whereas entity beans should be used to represent business data. Message Driven Beans should represent asynchronous business logic.

NOTE: For large-scale enterprise applications processing large volumes of data, the decision to use entity beans should be based on a very careful analysis. Entity beans provide a way of mapping a given bean to a given table (or tables) for the purpose of working with data on a particular table (or tables). Conceptually, this is a very organized approach. However, in practice, this can result in significant performance drags on the application server when servicing large transaction volumes requiring data from many different relational tables. Under these conditions, other alternative J2EE ways of accessing the required data exist and should be seriously considered over the use of entity beans. If entity beans are used, a course-grained approach is generally recommended in which a given entity bean is mapped to multiple database tables, meaning that entity bean can contain data retrieved from multiple tables to service the transaction. By using a course-gained entity-bean approach, the total number of entity beans required by the application generally goes down, thereby significantly reducing performance overhead on the server.

External links

 

From Wikipedia, the Free Encyclopedia. Original article here. Support Wikipedia by contributing or donating.
All text is available under the terms of the GNU Free Documentation License See Wikipedia Copyrights for details.

Search Titles
0123456789
ABCDEFGHIJ
KLMNOPQRST
UVWXYZ?

E-mail this article to:

Personal Message: