Friday, December 24, 2010

A simple introduction to EJBs

What are EJBs?


EJBs are Java Beans with a special ability. Normal Java Beans can be instantiated in the local JVM and the rest of the code can interact with this bean by making calls to the different methods in this bean.
EJBs are special in that they are not created in the local JVM. They are created in a remote JVM.

Structure of an EJB

When a Bean is designated as an EJB three classes are created. One the actual class where the functionality is present the second is a skeleton class which is used by the clients requiring the services of the class and the third is called the Home Interface which is used by the clients to instantiate the EJB. The skeleton class wraps the communication that happens between the two JVMs so that the developer is not bothered with the communication piece.

How are EJBs instantiated?

The following are the steps to used to instantiate an EJB
  1. Get the Home interface of the EJB using a JNDI Lookup
  2. Using the Home Interface instantiate the EJB
This creates a bean in the remote server and a handle to the remote bean is given to the code. Now the code can interact with the bean as if it were in the local JVM. The actual processing would be happening in the remote JVM.

What happens when a method of EJB is invoked?

When a function/method in the EJB is invoked the following happens:
  1. The skeleton “marshals” the parameters to be sent to the method
  2. The skeleton sends the parameters to the other JVM
  3. The function is executed in the other JVM
  4. The return value is “marshaled” and sent to the calling JVM
  5. The skeleton unmarshals the return value and gives it to the calling code.
  6. Marshalling is the process of converting the variables into a format using which it can be sent over the network to the remote JVM.

How does the communication happen

The communication used between the two JVMs was RMI, but now EJBs use Inter-ORB Communication. See http://www.ibm.com/developerworks/websphere/techjournal/0807_pape/0807_pape.html for more information.  This is a communication protocol used by CORBA ORBs (Object Request Brokers) over TCP networks.

Caution

Since every method call goes over the network it slows down the system. As a result from a performance perspective one should keep calls to EJB to the minimum. If one wishes to set a set of attributes of an EJB then one should set the values in a local bean and pass this bean as a whole to the remote bean. One should not invoke the set method of the remote bean for each attribute.
 

What are the types of EJBs?

The following are the types of the EJBs
  1. Stateless Session Beans
  2. Session Beans
  3. Entity Beans
  4. Message Driven Beans

Stateless Session Beans

These are the most popular of the EJB types. These are Beans that are used in Web Applications and typically address one business functionality. E.g. SaveCustomer could be a Stateless Session Bean which has the business logic to be executed to store a Customer to the database.  The advantage of having Stateless Session Beans are that irrespective of the server that the end user hit, in cluster, the actual execution could happen in any of the servers where the bean is deployed.
These beans do not maintain anything in the session. So once instantiated these beans could be used for any user.

Stateful Session Bean

These are same as Stateless Session Beans except that they maintain the session of the client.  So once a bean has been used for a client it will continue to be used for that user till the session of the user is terminated.

Entity Beans

These are beans that are used to keep Objects in the application. E.g. the Customer Object. These are used to persist the data in the Object to a persistent store, usually the database and to retrieve the objects from the database. There are two types of persistence possible
  1. Container Managed Persistence: In this the container does the persistence and retrieval from the persistent store. The developer only has to say Object.save or Object.get. The container uses the metadata to achieve this persistence and retrieval. This does not give the developer to control the performance of the application.
  2. Bean Managed Persistence: In this the developer writes code to persist the data into the persistent store and to retrieve data from the persistence store. This gives the developer the control over the performance of the application. This is the more popular of the two.

Message Driven Beans

These are similar to the Stateless and Stateful session beans in that they perform one operation. The difference is that they are triggered by messages sent on a queue, instead of executing when they are invoked explicitly from some program. These beans are tied to a queue and when an appropriate message comes on the queue these message beans are invoked automatically by the container in which they are running. These are useful when we need to perform some asynchronous processing.

What are the advantages of EJBs?

Scalability: The EJBs are remote and so to achieve high scalability one can deploy the EJBs on multiple servers and be able to scale the operations easily.
Transaction Management: Typically the developer has to maintain transactions in the database to ensure the ACID properties. And this transaction management generally goes into the code. With EJBs one need to build transactions in the code. One can configure the EJBs to start or continue existing transactions as required. Thus the developer need not worry about the maintaining transactions in the code.
Security Management: Most systems require a security which says which user can execute which action. This is typically coded into the application in most scenarios. With EJBs one can configure this too. One can configure the access rights of the users to execute different functionality. This means that the developer need not do any coding for basic security checks. It will be taken care of by the container based on the configuration.
 

How are EJBs packaged?

EBJs are packaged as ear files. These are on top of the war files. So the hierarchy is as follows:
Ear files contain
Deployment descriptor: This gives details of how the EJBs are the be deployed, which are the EJBs, what is the type, the security metadata, the transaction meta data
War Files: These contain the web applications and contain the following:
Static Files: These are static files like images, css, javascripts etc which are required by the web application
Jar files: These contain the java classes which are to be used in the web application.

How are EJBs deployed?

Each container has its own way of packaging and deploying the EJBs.

Some links


No comments: