The EJB 3.0 spec simplifies the development of business logic and data handling for enterprise apps. The EJB 2.x spec features a CMP 2.0 component model, which provides a number of improvements to aid developer productivity and application performance.
In addition, this product continues to fully support enterprise beans written to the CMP 1.1 programming model and deployed in previous versions of this product; applications can use CMP 1.1 beans, CMP 2.0 beans, or a mixture of both. CMP 1.1 beans can be directly carried forward in an EJB 1.1 ejb-jar module or may be repackaged and combined with CMP 2.0 beans in an EJB 2.x module.
Innovations for EJB 3.0 development
EJB 3.0 uses JPA, which is simpler than the Container Managed Persistence Entity bean approach from earlier releases. With a focus on the premise that a simple Java Bean can be used in most cases, and greater complexity should only be used when called for, EJB 3.0 simplifies the application development process in the following ways.
- Annotations to provide component metadata. It is no longer necessary to create XML deployment descriptors.
- Programmatic defaults so you do not need to specify most commonly used requirements in the EJB container. You only need to specify an item if we do not want the default value.
- A dependency injection function and simpler lookup APIs for easier access to a bean's environment.
- Plain Old Java Object (POJO) development for both business logic and persistence. This enables unit test outside of the appserver, reducing the edit-compile-deploy-debug cycles currently used with applications. It also removes dependencies on external framework interfaces such as...
- No requirement for session beans to have home interfaces.
- Simplified entity persistence through the JPA. Light-weight domain modeling, including inheritance and polymorphism, is supported.
Innovations for EJB 2.x development
For EJB 2.x modules, a feature introduced in V5 of this product, called Access intent policies, eases the management of interactions between CMP beans and their underlying data stores. Each policy sets data access characteristics such as access type (read or update) and transaction isolation that affect the locking of resources, letting you choose the level of data integrity and performance for the application. The Integration Server product adds APIs to enable you to further customize IBM-provided access intent policies for your particular environment.
Access intent is frequently used with the function of application profiling.For example, we can configure one transaction to load an entity bean with strong update locks and configure another transaction to load the same entity bean without locks.
Sometimes when working with entity beans we might find that it is better to use the dynamic query service rather than the regular EJB query service (which can be referred to as deployment query).
Your application development can also include asynchronous messaging, which the product supports as a method of communication based on the JMS programming interface. The base JMS support enables product applications to exchange messages asynchronously with other JMS clients by using JMS destinations (queues or topics). An application can explicitly poll for messages on a destination.
See Introduction: Messaging resources.
The product also provides a message listener service that applications can use to automatically retrieve messages from JMS destinations for processing by message-driven beans, without the application having to explicitly poll JMS destinations.