    
    
    
   
|
Enterprise JavaBeans Author: Gopalan Suresh Raj Introduction:
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:
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 two types of EJBs. They are
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. 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 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 Here, the EJB container is responsible for saving the Bean's state. Since it is container-managed, the implementation is independant 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. EJBs are deployed as serialized instances (*.ser files). The manifest file is used to list the EJBs. In addition to this, a Deployment Descriptor has to be supplied along with each .ser file. It contains a serialized instance of an EntityDescriptor or a SessionDescriptor. A typical EJB manifest entry looks like this
Name: ~gopalan/BankAccountDeployment.ser
Enterprise-Bean: True
The Name line describes a serialized Deployment Descriptor. The Enterprise-Bean line indicates whether or not the entry be treated as an EJB. Deployment Descriptors are serialized instances of a class. They are used to pass information about an EJBs preferences and deployment needs to its container. The EJB developer is responsible for creating a deployment descriptor along with his/her bean. Other Auxillary 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 What do you think of this article? Have your say about the article. You can make your point about the article by mailing [email protected] (If you haven't allready joined, you can join by going to https://www.onelist.com/community/dev-java). You can also write a review. We will publish the best ones here on this article. Send your review to [email protected]. Please include the title of the article you are reviewing. Further Reading The Enterprise JavaBeans Series:
Author: Gopalan Suresh Raj You can meet Gopalan, and the other iDevResource authors in Author Central. Gopalan also maintains his own site at https://www.execpc.com/~gopalan/. Contributors to iDevResource.com get their own site at Author Central. Why not write an article and become a member of the iDevResource community. © Copyright 1997-2000 Gopalan Suresh Raj. Reproduced with Permission |
Enterprise Java Beans Series - Components at the Server
Contribute to IDR:
To contribute an article to IDR, a click here.
To contact us at IDevResource.com, use our feedback form, or email us. To comment on the site contact our webmaster. |
 | All content © Copyright 2000 IDevResource.com, Disclaimer notice |
