JCEA Part 1: Enterprise Java Beans Container Model

1. General
2. References
3. Syllabus
   1. Concepts
   2. Common architectures
   3. Legacy connectivity
   4. EJB
   5. EJB Container model
   6. Protocols
   7. Applicability of J2EE
   8. Patterns
   9. Messaging
   10. Internationalisation
   11. Security
4. Reference
   1. UML
5. Resources
6. Further Tips

• State the benefits of bean pooling in an Enterprise JavaBeans container
  
• Explain how the Enterprise JavaBeans container does lifecycle management and has the capability to increase scalability

Background

Enterprise beans are software components that run in a special environment called an EJB container. The container hosts and manages an enterprise bean in the same manner that the Java Web Server hosts a servlet or an HTML browser hosts a Java applet. An enterprise bean cannot function outside of an EJB container. The EJB container manages every aspect of an enterprise bean at runtimes including remote access to the bean, security, persistence, transactions, concurrency, and access to and pooling of resources.

The container isolates the enterprise bean from direct access by client applications. When a client application invokes a remote method on an enterprise bean, the container first intercepts the invocation to ensure persistence, transactions, and security are applied properly to every operation a client performs on the bean. The container manages security, transactions, and persistence automatically for the bean, so the bean developer doesn't have to write this type of logic into the bean code itself. The enterprise bean developer can focus on encapsulating business rules, while the container takes care of everything else.

Containers will manage many beans simultaneously in the same fashion that the Java WebServer manages many servlets. To reduce memory consumption and processing, containers pool resources and manage the lifecycles of all the beans very carefully. When a bean is not being used, a container will place it in a pool to be reused by another client, or possibly evict it from memory and only bring it back when its needed. Because client applications don't have direct access to the beans--the container lies between the client and bean--the client application is completely unaware of the containers resource management activities. A bean that is not in use, for example, might be evicted from memory on the server, while its remote reference on the client remains intact. When the client invokes a method on the remote reference, the container simply re-incarnates the bean to service the request. The client application is unaware of the entire process. [quoted from Sun]

A container may provide the following services:

• Lifecycle management
• Bean Pooling
• Transactions
• Security
• Connection pooling
• Instance pooling

General

Distributed EJB objects are achieved by use of the following elements :

client

orchestrates lookup/creation of stubs; uses stubs for business operations

client stub

responsible for network aspects (marshalling, etc.) via a transparent business logic facade

server skeleton

responsible for servicing client requests and passes them onto the EJBObject

EJBObject

responsible for security, transactions, etc. before delegating method calls to the bean

bean class

actually implements the business logic

Bean Pooling

• Reduces the resource requirements for a single server – pooled beans are context switched as required
• Dynamic growth – pool can be expanded/contracted as demand requires
• Pooled objects are instantiated on startup instead of every time – may be “expensive” to instantiate.
• Fine-grained control of resources – able to set max/min beans
• Transparent to clients (through use of the Proxy pattern)

Lifecycle Management

Passivation is a technique that the EJB container can choose to temporarily serialize a bean and store it to the server filesystem or other persistent store so that it can optimally manage resources. The benefit of passivation is to allow the EJB container to make the best possible use of server resources by passivating a bean to free up resources and then re-activating it when resources are available.

A session bean can be passivated only between transactions, and not within a transaction.

• Dynamic resource management Lifecycle management enables a fine-degree of control over resources :
  • a small pool of beans can service many clients
  • resources can be swapped in/out as demand requires
  • container can employ caching
• Clustering Containers have good support for clustering at all levels :
  • distribute load over several machines
  • built in load balancing – JNDI, smart stubs, request forwarding

The EJB Lifecycle section below describes the transition between states of EJBs. These transitions support lifecycle management.

EJB Lifecycle

Session Beans

A client creates a session bean instance using one of the create<Method> methods defined in the session bean’s home interface. The session bean’s home interface is provided by the bean developer; its implementation is generated by the deployment tools provided by the container provider.

The container creates an instance of a session bean in three steps:

1. Calls the bean class’ newInstance method to create a new session bean instance.
2. Calls the setSessionContext method to pass the context object to the instance.
3. Calls the instance’s ejbCreate<METHOD> method whose signature matches the signature of the create<METHOD> method invoked by the client.

Stateless Session Bean

A statless session bean has the simplest lifecycle, either not existing or being in a pool ready to exception methods. It transitions directly between the two (creation and removal) and betwen ready and ready whilst in use by a client.

Passivation and Activation are not used in stateless session beans. A stateless session bean must not implement the SessionSynchronization interface.

Stateful Session Bean

Entity Bean

An entity bean instance is in one of the following three states:

• It does not exist.
  
• Pooled state. An instance in the pooled state is not associated with any particular entity object
  identity.
  
• Ready state. An instance in the ready state is assigned an entity object identity.

The following steps describe the life cycle of an entity bean instance: [taken from Sun's EJB 2.0 Specification]

• An entity bean instance’s life starts when the container creates the instance using newInstance and then initialises it using setEntityContext.
  
• The instance enters the pool of available instances. Each entity bean has its own pool. While the instance is in the available pool, the instance is not associated with any particular entity object identity. Any of these pooled instances may be used to execute finder (ejbFind<Method>) or home (ejbHome<Method>) methods.
• An instance transitions from the pooled state to the ready state when the container selects that instance to service a client call to an entity object. There are two possible transitions from the pooled to the ready state: through the creation of an entity (ejbCreate<Method> and ejbPostCreate<Method>) or through the activation of an entity (ejbActivate).
• When an entity bean instance is in the ready state, the instance is associated with a specific entity object identity. While the instance is in the ready state, the container can synchronize the instance with its representation in the underlying data source whenever it determines the need to using ejbLoad and ejbStore methods. Business methods can also be invoked zero or more times on an instance. An ejbSelect<Method> method can be called by a business method, ejbLoad or ejbStore method.
• The container can choose to passivate an entity bean instance within a transaction. To passivate an instance, the container first invokes the ejbStore method to allow the instance to prepare itself for the synchronization of the database state with the instance’s state, and then the container invokes the ejbPassivate method to return the instance to the pooled state.
• There are three possible transitions from the ready to the pooled state: through the ejbPassivate method, through the ejbRemove method (when the entity is removed), and because of a transaction rollback for ejbCreate, ejbPostCreate,or ejbRemove.
• The container can remove an instance in the pool by calling the unsetEntityContext() method on the instance.

1. SCEA Nutshell from Yahoo groups (member access only)
2. http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Overview3.html
3. http://developer.java.sun.com/developer/onlineTraining/EJBIntro/EJBIntro.html#Overview
4. Mastering Enterprise Java Beans II by Ed Roman, Scott Ambler, Tyler Jewell, Floyd Marinescu [download for free] has a very good section on the EJB life cycle.
5. EJB specification

Some questions on passivation, whose responsibility is it to relieve resources @ the time of passivation (bean/container?)

I belive the exam is set on the EJB1.0 specification and so message-driven beans are not covered