Ejb Basics

Enterprise JavaBeans is a specification for creating server-side scalable, transactional, multi-user secure enterprise-level applications. It provides a consistent component architecture framework for creating distributed n-tier middleware. It would be fair to call a bean written to EJB spec a Server Bean.

A typical EJB Architecture consists of

 an EJB server,application server
 EJB containers that runs on these servers,
 EJBs that run in these containers, 
 EJB clients and 
 other auxiliary systems like 

the Java Naming and Directory Interface (JNDI ) and the Java Transaction Service (JTS).

In a typical development and deployment scenario, there will be an EJB server provider who creates and sells an EJB server along with EJB containers that will run on these servers. Then there will be the EJB providers-people responsible for developing the EJBs and the Application assemblers-people that use pre-built EJBs to build their applications.

EJB Servers : These are analogous to the CORBA ORB. This provides the system services like a raw execution environment, multiprocessing, load-balancing, device access, provides naming and transaction services and makes containers visible.

EJB Containers : These act as the interface between an Enterprise Java Bean and the outside world. An EJB client never accesses a bean directly. Any bean access is done through container-generated methods which in turn invoke the bean's methods. The two types of containers are session containers that may contain transient, non-persistent EJBs whose states are not saved at all and entity containers that contain persistent EJBs whose states are saved between invocations.

EJB Clients : These make use of the EJB Beans for their operations. They find the EJB container that contains the bean through the Java Naming and Directory (JNDI) interface. They then make use of the EJB Container to invoke EJB Bean methods.

Enterprise Java Beans: There are three types of EJBs. They are

 Session Beans,
 Entity Beans, and
 Message-Driven Beans

Session Beans: Each Session Bean is usually associated with one EJB Client. Each Session Bean is created and destroyed by the particular EJB Client that it is associated with. A Session Bean can either have states or they can be stateless. However, Session Beans do not survive a System shutdown.

Entity Beans: Entity Beans always have states. Each Entity Bean may however be shared by multiple EJB Clients. Their states can be persisted and stored across multiple invocations. Hence they can survive System Shutdowns.

Message-Driven Beans [MDB]: These are similar to Stateless Session Beans, but they work asynchronously, and are clients to JavaMessageServices. The EJB deployer writes a server-specific configuration file to designate which messages it should listen for; when a message arrives, the server gets a MDB, and calls its onMessage(javax.ejb.Message) method.

EJB servers have a right to manage their working set. Passivation is the process by which the state of a Bean is saved to persistent storage and then is swapped out. Activation is the process by which the state of a Bean is restored by swapping it in from persistent storage. Passivation and Activation apply to both Session and Entity Beans.

There are two types of Session Beans. They are

 Stateless Session Beans and
 Stateful Session Beans

Stateless Session Beans: These types of EJBs have no internal state. Since they do not have any states, they need not be passivated. Because of the fact that they are stateless, they can be pooled in to service multiple clients (remember MTS components?)

Stateful Session Beans: These types of EJBs possess internal states. Hence they need to handle Activation and Passivation. However, there can be only one Stateful Session Bean per EJB Client. Since they can be persisted, they are also called Persistent Session Beans. These types of EJBs can be saved and restored across client sessions. To save, a call to the bean's getHandle() method returns a handle object. To restore, call the handle object's getEJBObject() method.

Persistence in Entity Beans is of two types. They are:

 Container-managed persistence
 Bean-managed persistence

Container-managed persistence: Here, the EJB container is responsible for saving the Bean's state. Since it is container-managed, the implementation is independent of the data source. The container-managed fields need to be specified in the Deployment Descriptor and the persistence is automatically handled by the container.

Bean-managed persistence: Here, the Entity Bean is directly responsible for saving its own state. The container does not need to generate any database calls. Hence the implementation is less adaptable than the previous one as the persistence needs to be hard-coded into the bean.

In the EJB 1.0 specification, EJBs were deployed as serialized instances (*.ser files). This method was not used much, and was also very complicated.

In the EJB 1.1 and later specifications, EJBs are seployed as specialized JAR files. The JAR file contains the compiled class files, other resources, a manifest file (without the serialized deployment descriptors mentioned above), a standard XML deployment descriptor file named ejb-jar.xml, and one or more server-specific descriptor files.

The standard file ejb-jar.xml lists the EJBs, declares which classes take up which roles for them, and declares names for resources they will use. It also declares security restrictions and transaction requirements. The server-specific files map the resource names and security roles to actual server-specific names. They also map entity bean instance variables to database columns.

Even though the 1.1 method is much simpler, it is still a bit complicated, but there are tools that can help; the most famous is XDoclet.

Other Auxiliary systems that are available to EJB systems are the Java Naming and Directory Interface (JNDI) which allows EJB Clients to find EJB beans and the Java Transaction Service (JTS) that provides transaction support in an EJB environment.

---

Wow. And this is just the basics? -- Yes, but it's not that complicated, considering the capabilities.

Which are mentioned in passing in three lines of the above, and which can be done in other less buzzword-compliant ways without the complexity. -- DonaldFisk

---

EjbBasics QuickQuestions

I see that JTS is listed as Auxiliary System. How long has JTS been around (compared to EJB itself), is it relatively mature (meaning sufficient complete and stable and available from most EJB vendors). How could EJB claim to be "Enterprise" without transaction support? --dl