The Enterprise JavaBeans architecture
Reusability is and long has been a common theme in computing. Component models provide a consistent framework for software reuse. It is difficult to envision a component model that fits every problem context. The Enterprise JavaBean (EJB) specification is a standard for a component model specifically geared toward server-side Java tasks. By server-side Java, we are referring to tasks such as database connection, transaction control, persistence, fault tolerance, and caching. The EJB specification is the first attempt from Sun to address these types of activities and create a model for using Java in such environments.
If you look at the "server" world today, you will see middleware technologies, databases, traditional transaction processing monitors, CORBA, and other technologies. EJB is an attempt to provide a framework for these seemingly disparate systems without leaning towards one particular implementation. In fact, the EJB specification is intended mostly for vendors to make their products EJB compliant. It is not written for developers who want to create EJB components.
EJB is composed of three fundamental components. There are also a number of "auxiliary" components that complete the EJB model. The three core pieces of EJB are:
- The EJB server
- The EJB container
- Enterprise JavaBean
The auxiliary pieces of EJB are:
- Home interface
- Remote interface
- Deployment descriptor
- EJB-jar file
EJB serverThe EJB Server is a vendor-specific implementation which is responsible for providing the services necessary to host a container. Obviously, specialized containers require specialized EJB servers.
The EJB specification does not concern itself about how various services are implemented and whether a certain service is supported by all operating systems or not. It merely outlines what is expected of an EJB server and expects the implementation to provide that. In almost all cases, the implementation is vendor specific and most likely proprietary. That is okay, because Beans do not directly interact with the EJB server. They interact with the container. As long as the container meets the specification, it should be able to deploy any EJB that also conforms to the specification. The EJB server is typically implemented by extending an existing product, although there are some vendors that have started from ground zero and provide EJB servers.
EJB containerThe Bean is wrapped in a container. A container can hold one or more Beans and is responsible for providing the services required by the specification to each Bean requesting it. This is how EJB achieves conformity. It requires a minimal set of services to be provided by a container. This way, each Bean is guaranteed the same set of services regardless of the container in which it is running.
The specification allows for "specialized" containers. These are containers that provide more services than what is required by the specification. Such additional services are required to deploy specialized Beans. This is perfectly within the rules, but such Beans lose their portability, since they will only run inside containers that provide the specialized service they seek. This was a major compromise made by the designers of EJB so they could support a large percentage of existing systems. Furthermore, if there is anything in the EJB that can lead to implementation fragmentation and deviations, the specialized containers are it.
Enterprise JavaBeansEnterprise JavaBeans are the components you write. They represent the business logic you need to implement. The container and the EJB server take care of details of transaction integrity and transaction control. Therefore, your EJB can focus mostly on the specific business function that it is implementing. EJBs come in two flavors: session Beans and entity Beans.
Regardless of their flavor, EJB methods are never directly invoked by the client. There is an intermediate EJBObject that intercepts method calls from the client and delegates them to the EJB. An EJB must obviously implement the business logic and make this available via a remote interface (again, the client does not call the EJB methods directly) . It must also implement an
method, which is called by the container to create it (similar to how a class constructor works).
Session Beans must be supported in any EJB 1.0 compliant container, but support for entity Beans is optional. EJB 2.0 will mandate support for entity Beans as well. A session Bean is short-lived. Actually, it only lives during the session. It exists on behalf of a single client. Once the client terminates, the session Bean terminates. In case of an EJB server crash, all session Beans are destroyed. Clients must then reestablish new session Beans. Entity Beans are the counterpart to session Beans. They last typically longer than session Beans. They represent some data in the database so even when the EJB server crashes, the entity beans continue to exist. Well talk more about entity Beans after we complete the basic EJB architecture.