Situated within their own tier of the Java 2 Enterprise Edition (J2EE) specification, EJB components tie the presentation layer of an application to back-end enterprise information systems, such as databases or mainframes. EJB architecture utilizes functionality from both EJB objects and the environment in which they run.
The why of EJBConceptually, EJB objects encapsulate business objects and concepts, letting developers concentrate on the details of solutions. From a design standpoint, EJB should incorporate portability and interplay. This arrangement allows a single EJB, whether developed in-house or by a third party, to work with multiple applications. For example, a customer relationship management (CRM) tool as well as an e-commerce application may use an EJB representing a customer. Configuration of these already adaptive objects becomes easier with deployment descriptors, XML files describing the EJB. Deployment descriptors allow modifying EJB properties and behavior without recompiling. The where of EJB
EJB objects reside in the EJB container, an environment providing a wealth of services to developers. Depending on configuration, a container may handle security, transactions, and instance management. By removing these tasks from programmers, development time significantly decreases. A distinction exists between J2EE servers and EJB containers -- an EJB container may be part of a J2EE server, but it's not mandatory. As part of a J2EE server, EJB clients usually take the form of Java servlets or Java Server Pages. However, freed from the dependence on the Web tier of J2EE, standalone EJB containers service requests from many types of clients, applications written in Java or other languages. Communication with the EJB container is the only prerequisite for a client. The what of EJB
EJB objects fall into three categories:
- Session Beans
- Entity Beans
- Message Driven Beans
Session Beans act on a session-by-session basis. After a client requests and receives bean functionality, the session with that particular bean ends, leaving no record of what occurred. Session Bean types further divide, acting in a stateless or a stateful manner. Stateless Session Beans have no knowledge of the client or any semblance of context regarding the request, making them ideal for one-off use. An example of this would be in a bug-tracking system where the user searches for all open bugs. The client application contacts a Stateless Session Bean, passing the search parameters. In turn, the bean accesses a database, selects entries matching the criteria, and passes records back to the client. When communication completes, the bean retains no recollection of the interaction. Because of this behavior, multiple distinct clients may simultaneously access a Stateless Session Bean with no ill effect. In contrast, Stateful Session Beans associate requests with a specific client, joining client and bean in a one-to-one relationship. A shopping cart bean provides the quintessential example of this. The user performs the standard e-commerce tasks of adding products to the cart, entering address information, and placing the order. The cart bean maintains state and thereby knowledge of all these variables, associating them with a single client.
