J2EE

The J2EE solution for serving application logic is Enterprise JavaBeans (EJBs). EJBs can be contacted directly by servlets, by applet containers or by JMS. In contrast, servlets are primarily meant for HTML-based, thin client session management and for delivering request and response to web user. By offloading the session and interaction to servlet, EJB can focuses on business logic.

EJB has built-in support for many low level technologies to enhance the scalability of server side logic. Comparing to client side logic (fat client), scalability is a challenge for server-side logic. The technologies include object persistence, transaction management and location transparency.

Under the J2EE model, EJBs are distributed objects managed by containers. The container provides surrogates (EJBObject) that interact with individual bean instances, on behalf of the client. The containers manage the lifecycle of its bean instances (creation and destruction). A client communicates with an EJBObject. The EJBObject acts as a middleman in the communication between client and bean. Its assignment to a bean instance is coordinated by the container. Client interacts with EJBs consists of the following steps:

1.A handle to an EJBObject is acquired by client.
2.Business methods of that object are called by client as needed.
3.After use, the client relinquishes the handle to the EJBObject.

The home interface is used for step 1 and 3. A local or remote interface for step 2.

The home interface provides factory-like services to create, destruct and find the EJB requested. The remote or local interfaces provide a clean API to application logics (business methods) encapsulated by the bean. The local interface is meant to be accessed by clients located on the same host as the bean.

Bean provides call-back method for the container to manage its lifecycle:

Creation: When the client demands but no available instance exists, the container must instantiate a new instance.

Destruction: Bean instances can be periodically garbage-collected.

Activation: A lite form of creation. Bean instances are pooled for performance reason. Container draw from the pool to fulfil a request.

Passivation: A lite form of destruction. A bean instance is returned to the pool.

There are 3 basic types of EJB:

Session beans are associated with specific business transaction, particularly one requested during an interactive session.

Message-driven beans are also associated with specific business action, particularly one that is necessary for application integration or batch processing.

Entity beans are associated with an application object that requires persistent storage.













Session beans are either stateful or stateless. Stateful session bean maintain state during communication with a client. They retain the values of their instance variables between client requests. It is important for the client to interact with the same bean. Theoretically, there should be as many stateful session beans as there are concurrent sessions. According to J2EE spec, stateful session beans may be periodically written to persistent storage.

Stateless session beans do not maintain state between requests and therefore can be used to process requests from any client. They are more scalable. However, session bean often requires state management. The state must be stored somewhere: cookies, URL rewrite, in server-side memory or in database.

Entity beans correspond to application objects that are meant to be persistent – contain potentially valuable information across sessions. It may be useful to think of entity bean as tables or relations in a relational database. They contains attributes, foreigh and primary keys to enforce entity integrity. Entity beans can be shared by multiple clients. Entity bean can relate to each other.

Entity bean's persustence can be either container managed or bean managed. BMP is there because J2EE implementation cannot know everything. The main advantages to CMP are simplicity and portability. You do not need to code SQL. You just need to provide a few methods that meet the requirements of your bean contract and specify some key information in the deployment descriptor. J2EE does the rest. As a result, your beans consist of much less Java code.

CMP method and mechanism for persistence vary between vendors. This means that CMP could be implemented by writing serializable Java object to the filesystem or by tight integration with a high performance database.
Since entity beans have relationships with other entity beans, there is a considerable likelihood that they'll be chatty in nature. Just as navigating a relational data model can result in many queries to the database, navigating through entity EJB objects can result in substantial cross-object communication – marshalling and network communication.

EJB 2.0 addresses this by offering a local model. For entity bean that are only called by other entity bean but not directly from client, maintaining a remote interface is a waste. EJB 2.0 develops the bean with a local interface and making it a local object.

The advantages are (1) more efficient argument marshalling – pass by reference rather than by value, (2) more flexibility in terms of security enforcement.

Another CMP feature in EJB 2.0 is container-managed relationships, equivalent to RI in database. Finally, CMP includes dependent objects, which can be thought of as extensions to entity bean. Dependent objects allow complex CMP fields to be represented in a separate class. This is a way of breaking up a more complex object into distinct parts.

BMP results in more time-consuming and complex development responsibilities. It also implies maintenance overhead for code and changes in data model. For performance, BMP may be more desirable but must be done right.

Session bean is unique on the method of invocation. Clients do not interact by calling a remote Java method. Instead, clients send messages via JMS and result in execution of an onMessage() bean function.