9.2 Enterprise JavaBeans


The JavaSoft Enterprise JavaBeans (EJB) specification defines a component architecture for building distributed, object-oriented business applications in Java. [1] The EJB architecture addresses the development, deployment, and runtime aspects of an enterprise application's life cycle. Figure 9-1 depicts the EJB architecture.

[1] A link to the complete EJB specification is available at http://www.sei.cmu.edu/cbs/mls/links.html#javasoft.

Figure 9-1. EJB architecture

graphics/09fig01.gif

EJBs encapsulate business logic. Each enterprise bean is deployed within a component framework, or container, that manages the details of security, transactions, connection management, and state management. An EJB container handles low-level details, such as automatic persistence, remote invocation, transaction boundary management, and distributed-transactions management. This allows the EJB developer to focus on the business problem. An EJB is, in essence, a transactional and secure object, some of whose runtime properties are specified at deployment, using XML documents called deployment descriptors.

Enterprise Javabean Types

The three kinds of EJBs are entity beans, session beans, and message-driven beans. Entity beans directly represent persistent business objects, such as an account or a purchase order, that can be shared among multiple clients . Entity beans are associated with a data store that keeps the persistent data between sessions, that is, across EJB server shutdowns or crashes. The data contained in an entity bean is most often stored in a relational database in one or more tables. However, the data can be stored anywhere , for example, in a legacy system.

Mapping EJB data to a persistent store can be implemented in the bean's methods , using bean-managed persistence (BMP), or can be delegated to the container, using container-managed persistence (CMP). CMP is applicable mostly in simple object-to-relational mappings, whereas BMP gives the bean developer detailed control over the storage of the bean's data fields. An advantage of using CMP is that the details of persistence can be configured during deployment ”using tools supplied by the container vendor. These details do not depend on implementation decisions made by the bean developer. Thus, applying CMP increases the portability and reusability of entity beans.

Session beans come in two varieties: stateless beans and stateful beans. A stateless session bean does not keep any internal state between method invocations by a client. All the information that is necessary to execute a method must be included in the method parameters. Therefore, a stateless session bean can be shared among many clients, and a container can provide a pool of identical beans that service client requests . This makes an application that consists only of stateless beans easily scalable.

In contrast, stateful session beans maintain an internal state and are thus capable of not only providing simple services but also managing entire work flows. The shopping cart in a Web site store is a good example of a stateful session bean. The contents of the shopping cart are captured in the bean's state, and this state is kept until the user completes the shopping session. The state in a session bean is not meant to be persistent; its lifetime is the length of a client session. Nevertheless, the session bean can read and update data in a database and take part in transactions. Each stateful session bean is bound to one particular client; it cannot be shared. This has drawbacks in scalability but can reduce network traffic because the session's state is kept on the server.

The newest bean type is the message-driven bean (MDB), introduced in the EJB v2.0 specification to integrate EJBs with the Java Message Service (JMS). An MDB is a stateless bean with a method that is invoked by the container when a JMS message arrives. This extends the EJB model to handle asynchronous events, which are not easily supported otherwise . In addition, MDBs enable the container to concurrently process a stream of messages by using a pool of bean instances.

Entity and session beans are accessible to clients, such as other EJBs or any Java program. A client can run locally in the same JVM as the accessed bean or remotely in any JVM. In addition, EJBs can be either be accessed only by local clients or by any remote client. Remotely accessible EJBs, such as a purchase order, are intended to be coarse-grained, whereas fine-grained components , such as purchase order line items or a delivery address, should be modeled as locally accessible enterprise beans or as dependent objects for efficiency.

MDBs are not directly visible to clients. The only way to access an MDB is for a client to send messages to the JMS destination for which the bean is registered as the message listener.

Persistence for Entity Beans

As previously mentioned, the EJB specification gives the bean developer a choice. The developer can implement the bean's persistence directly in the bean by using BMP or can delegate the bean's persistence to the container by using CMP.

In BMP, the developer implements object persistence directly in the bean implementation code, including creation and finder methods. Creation methods must generate records in the persistent store from data passed in as arguments to the method. Finder methods must formulate the proper queries to locate the correct records in the persistent store and return a primary key or keys. In addition to writing creation and finder methods, the bean developer must specify methods to refresh the bean from the persistent store, store the bean in the persistent store, and remove the bean from the persistent store.

In CMP, the deployer uses the container provider's tools to generate all the code that moves data between the bean instance and a database or an existing application. The bean developer specifies either the container-managed fields (EJB v1.1 and EJB v2.0) or the abstract persistence schema (EJB v2.0 only).

Support for Transactions

EJB servers must support distributed transactions to conform to the specification. This requires the container to support flat transactions that may span multiple servers or multiple database instances. The server must fulfill the role of a transaction manager that understands two-phase commits, as explained in Section 8.4.

Distributed transactions are carried out by the EJB server collaborating with JDBC drivers and databases. The database must support XA transactions to take part in the two-phase commit protocol. In addition, the JDBC driver must implement the XADataSource and XAConnection interfaces from the JDBC Optional Package, along with the JDBC v2.1 Core API. The EJB server itself has to contain an implementation of the JTS, which uses the JDBC driver's XADataSource and XAConnection interfaces to connect to the database [White 98].

Adding support for two-phase commits to a database driver is difficult and requires the cooperation of the database vendor. In most cases, developers rely on the vendor to provide the database drivers ”for example, Oracle for an Oracle JDBC driver and Sybase for a Sybase JDBC driver. There are also independent providers of JDBC drivers. Merant, for example, offers a sophisticated JDBC driver package for Oracle, Microsoft SQL Server, and other databases.

The transaction boundaries can be controlled by the container or by the bean provider. In container-managed transactions, the EJB's deployment descriptors describe the transactional behavior of the bean's methods. When using bean-managed transactions, the bean developer includes code to start a transaction in the bean's implementation. Commits or rollbacks are handled by the container in both cases. For example, a transaction is rolled back if an exception occurs during the transaction or if the bean in a bean-managed transaction sets a rollback flag. Otherwise, the container tries to commit the transaction.

Security

The EJB architecture shifts most of the burden of implementing security management from the bean to the EJB container and server. In particular, an enterprise bean's deployment descriptor features access control entries. These entries allow the container to perform runtime security management on behalf of the enterprise bean.

Security mechanisms fall into three categories: required by the EJB specification, EJB container and server specific, or hard-coded by the EJB developer [Jaworski 00]. The EJB specification describes a security infrastructure that addresses the authorization aspect of security. Authorization must be implemented by the container provider and regulates both the invocation of other beans and access to resources. Other security aspects include authentication, nonrepudiation, confidentiality, and security auditing. The EJB specification makes no provisions for these services other than the existing Java programming language security APIs. These APIs support only some of these security aspects. Support for nonrepudiation and security auditing is lacking. However, vendor-specific support for these services does exist in some products.

Products

JBoss

JBoss v2.4 is a free, open -source EJB server that includes full EJB v1.1 support, including all beans, all persistent types, and all transactional tags. [2] JBoss is supported on Windows 95/98/NT, Solaris Sparc, UNIX, OS/2 Warp, and other Java-enabled platforms. JBoss v3.0, the newest version, includes support for EJB v2.0 and runs on any platform with JVM 1.3.

[2] A link to the server is available at http://www.sei.cmu.edu/cbs/mls/links.html#jboss.

WebLogic

WebLogic, another commercial EJB server from BEA, complies with the EJB v2.0 specification, J2EE platform, and CORBA. BEA includes BEA Tuxedo transaction technology (T-Engine). WebLogic is supported on a broad range of platforms, including Windows NT, Windows 2000, Solaris, HP-UX, Red Hat and SuSE Linux, and IBM OS 390.

WebSphere

WebSphere is a commercial EJB server from IBM. Version 4.0 complies with the EJB v1.1 specification, including Entity Beans support, servlets v2.2, JSP v1.1, XML/XSL support, distributed transactions, and CORBA interoperability ”through Component Broker. When it is released, version 5.0 will support EJB v2.0. WebSphere is supported on JDK v1.3, AIX, Solaris, HP-UX, Linux, OS/400, Windows NT, and Windows 2000 platforms.



Modernizing Legacy Systems
Modernizing Legacy Systems: Software Technologies, Engineering Processes, and Business Practices
ISBN: 0321118847
EAN: 2147483647
Year: 2003
Pages: 142

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net