|
Download Specification
What's new in the Enterprise JavaBeansTM 2.0 Specification?
Since its introduction over two years ago, Enterprise JavaBeansTM
(EJBTM) technology has maintained unprecedented momentum among platform providers and enterprise
development teams alike. That's because the EJB server-side component model simplifies development of middleware components that
are transactional, scalable, and portable. Enterprise JavaBeans servers reduce the complexity of developing middleware by providing
automatic support for middleware services such as transactions, security, database connectivity, and more.
EJB 2.0 technology represents a major new release offering many significant benefits, further simplifying and expediting
development and deployment of more feature-rich enterprise applications. On April 26, 2001, Sun released the EJB 2.0 specification
Final Proposed Draft #2 to the public through the Java Community ProcessSM (JCP 2.0).
This article describes the changes in EJB 2.0, and how these new features can make application development easier and faster.
As EJB technology has been a pivotal technology in enabling e-commerce implementations, an e-commerce retail site example will
be utilized in order to describe the key new features of the EJB 2.0 specification.
Integration with JavaTM Message Service (JMS) -- Asynchronous Capabilities
Streamline Systems
The use of asynchronous messaging allows the development of loosely-connected systems (or applications). These systems are
typically more resilient in the event of failures, and more easily extensible as new applications are developed. Additionally,
messaging provides an effective means of transmitting events between applications.
Java Message Service (JMS) brings asynchronous messaging services to Java applications developers.
The integration of JMS and EJB allows enterprise beans to participate fully in loosely connected systems. Through this
integration, message-driven beans can receive and act upon JMS messages, without the involvement (or existence) of an application
client user interface. This new capability makes EJB an excellent choice for the development of shared business services.
Additionally, any EJB can send asynchronous messages via the JMS API.
In the web retail example, when a shopper makes a purchase, an inventory bean could notify an ordering bean or external supply
chain management system of a low stock situation. Since this notification is asynchronous, the shopper does not have to wait while
this complex business to business reordering operation completes. Furthermore, disconnected users, such as cell phone users, may
request a transaction such as selling/buying stock and immediately disconnect. The appropriate asynchronous message will be sent
to the trading enterprise bean, which can execute the transaction and then send a notification pager message to the cell phone
user upon completion.
As this simple example demonstrates, JMS integration streamlines application behavior, eliminates bottlenecks and reduces wait
time for the user, resulting in a better shopping experience and heightened customer retention.
Container-Managed Persistence (CMP) -- Simplifying and Expediting Application Development
The EJB architecture greatly simplifies the connection between the application and the database tiers. The EJB 2.0 specification
takes this benefit to the next level by allowing developers to develop portable applications that are database-independent and
free of database access code.
Frequently, application developers don't have access to the physical database schema when building their applications. Sometimes
this is for security reasons. Sometimes it is because the physical schema has not been designed or finalized. Other times,
application developers don't want to know the entire physical database schema, especially when a large, complex database is shared
between many less-complex applications.
CMP can be used to isolate the application developer from the physical database schema. This done by creating an abstract schema
that matches the needs of the current application, and using CMP to map between the abstract and physical schemas. This technique
allows better partitioning of effort in the development staff, requires less code to be written and maintained, and provides faster
time to market. Additionally, the use of CMP ensures that applications are portable in the event of vendor or schema changes.
EJB 1.1 provided a simple CMP facility that provided some of these benefits. However, feedback from the development community
indicated that this facility was too limited, both in the data modeling capability and in the mechanism used to define the mapping
of the CMP bean to the database schema.
EJB 2.0 extends CMP to address these concerns. A far more robust modeling capability is added, with support for declarative
management of relationships between entity EJBs. Developers no longer need to re-establish relationships between the various beans
that make up their application -- the container will restore the connections automatically as beans are loaded, allowing bean
developers to navigate between beans much as they would between any standard Java objects.
EJB 2.0 also introduces for the first time a portable query language, based on the abstract schema, not on the more complex
database schema. This provides a database and vendor-independent way to find entity beans at run time, based on a wide variety of
search criteria.
What does all this mean? Developers can focus on creating business logic, while the EJB container automatically manages the
database access for their applications.
In the context of our web retail example, the benefit of CMP is realized in many places. For example, there are many related
database updates that need to occur in response to a purchase, in the inventory database, the purchase order database, the customer
database and so on. To complicate the situation, some of these databases may be relational, while others may be customer
relationship management systems or other enterprise applications. Declarative relationships between enterprise beans enable the
developer to specify the relationship between customers and purchase orders, once. He doesn't need to understand the storage
technologies, or foreign key relationships, or to manually write the database access code to facilitate all these database updates.
This increases competitiveness of the web retail site by enabling the development team to attain faster time to market, not only
for new applications, but also for application updates that are required to adapt to frequently changing market needs. The
resulting application will also be smaller in code-base, hence easier to maintain, and portable across application servers and
databases systems from different vendors, allowing the selection of different vendors as business needs change.
Local Interfaces -- Streamlining Calls Between Local Beans
EJB was originally designed around remote invocation using the Java Remote Method Invocation (RMI) mechanism, and later extended
to support to standard CORBA transport for these calls using RMI/IIOP. This design allowed for maximum flexibility in developing
applications without consideration for the deployment scenario, and was a strong feature in support of a goal of component reuse
in J2EE.
We received a good deal of community input regarding the way EJBs are used in the field. Many developers are using EJBs locally
-- that is, some or all of their EJB calls are between beans in a single container.
With this feedback in mind, the EJB 2.0 expert group has created a local interface mechanism. The local interface may be defined
for a bean during development, to allow streamlined calls to the bean if a caller is in the same container. This facility will thus
improve the performance of applications in which co-location is planned.
EJB 2.0 local interfaces can be very useful in the situations for which they were designed.
However, it is important to understand that the calling semantics of local interfaces are different from those of remote
interfaces. For example, remote interfaces pass parameters using call-by-value semantics, while local interfaces use
call-by-reference.
This means that in order to use local interfaces safely, application developers need to carefully consider potential deployment
scenarios up front, then decide which interfaces can be local and which remote, and finally, develop the application code with
these choices in mind.
While EJB 2.0 local interfaces are extremely useful in some situations, the long-term costs of these choices, especially when
changing requirements and component reuse are taken into account, need to be factored into the design decision.
Inter-Server Interoperability -- Enabling Heterogeneous Environments
Cross-server application portability has always been a core premise for EJB technology. The EJB 2.0 specification takes this
benefit to the next level by offering inter-server application interoperability. This will enable EJB technology-based applications
operating on EJB servers from different vendors to freely interoperate using the RMI-IIOP protocol.
In a web retail site, a shopping cart bean executing on an application server from one vendor will be able to obtain inventory
information by communicating with an inventory bean executing on an application server from a different vendor. Thus the retailer
will be able to deploy their EJB technology-based application across a heterogeneous environment mixing application servers from
different vendors, knowing that beans will be able to effectively communicate across these servers.
Conclusion
The EJB 2.0 specification, developed by the Java Community under the Java Community Process 2, is an important step in
streamlining the development and deployment of J2EE applications. When this specification is implemented in J2EE 1.3, application
developers will be able to develop applications that take full advantage of the core J2EE value propositions:
- J2EE enables faster solution deliver time to market.
- J2EE prevents vendor lock.
- J2EE simplifies integration.
Download Specification
|
Print-friendly Version
