11.5. Deployment Descriptors

Every Enterprise JavaBean component has a set of deployment descriptors contained in a deployment descriptor file in XML format. This allows a developer to specify the bean's transactional and security attributes declaratively. The container reads the deployment descriptors and enforces transaction and security constraints, state management, lifecycle, and persistence.

11.5.1. The Material Request Bean

One of the benefits of using a tool like JDeveloper is that it helps you to create the XML deployment descriptor through a series of wizards. In the case of the Material Request Bean, JDeveloper is used to create deployment descriptors for transaction control, EJB relationships, and the deployment environment.

Transaction Control

All the business methods in the MaterialRequest bean have the transaction attribute set to Requires. This means that a new transaction context will not be created if the method is called within an existing one. This will usually be the case, because the session bean controlling the Web interface will create a transaction context before calling the MaterialRequest bean methods. This is achieved by using the RequiresNew transaction attribute on the methods of the session bean.

Oracle9i database and the Oracle9iAS support declarative and programmatic transactions using JTA APIs. The Oracle J2EE container supports both JTA client and server-side demarcation and propagation of transaction contexts. Propagation of transaction context is necessary for including the invoked object into the global transaction. The JDBC drivers supplied by both Oracle9i database and the Oracle9iAS are also JTA-enabled, giving them the capability to incorporate client-side transaction demarcation.

EJB Relationships

In common with many EJB applications, the MaterialRequest bean must interact with other EJBs in the system. To do this in a portable way, you can define an EJB relationship within the deployment descriptor.

<ejb-ref>
  <description>BudgetCode Entity</description>
  <ejb-ref-name>ejb/BudgetCode</ejb-ref-name>
  <ejb-ref-type>Entity</ejb-ref-type>
  <home>cern.base.BudgetCodeHome</home>
  <remote>cern.base.BudgetCode</remote>
  <ejb-link>BudgetCodeBean</ejb-link>
</ejb-ref>

Doing this allows the MaterialRequest bean to always refer to the BudgetCode bean using the logical JNDI name “java:comp/env/ejb/BudgetCode,” giving a degree of independence. If the implementing class or the environment changes in some way, only the deployment descriptor would need updating, without having to modify any Java code.

The <ejb-link> tag in the deployment descriptor gives the name of the entity bean. (See the following code, which is part of an Oracle-specific deployment descriptor) Currently, Oracle implements this differently from the EJB1.1 standard. In this case, the name relates to a mapping entry in the vendor-specific deployment descriptor that maps the name of an EJB to a specific JNDI path.

<ejb-mapping>
  <ejb-name>BudgetCodeBean</ejb-name>
  <jndi-name>ais/base/BudgetCode</jndi-name>
</ejb-mapping>

Deployment Environment

Another important aspect of the deployment descriptor is the section that defines the EJB environment. You can use this feature to define resources that the EJB can retrieve in a platform-independent way at runtime. The following sample shows the part of the descriptor that is needed to connect to the database.

<resource-ref>
  <res-ref-name>jdbc/localDB</res-ref-name>
  <res-type>javax.sql.DataSource</res-type>
  <res-auth>Application</res-auth>
</resource-ref>

The database connection can then be obtained at runtime, using JNDI as follows.

if (ic == null)
  ic = new InitialContext ();

DataSource                     localDS =
       (DataSource)ic.lookup("java:comp/env/jdbc/localDB");

return localDS.getConnection();

How you bind the DataSource object to the JNDI namespace depends on the application server you are using. With Oracle9i, you bind a DataSource using the bindds command in the session shell, as in the following.

bindds  /edh/DataSource/localDB -rebind –url
      jdbc:oracle:thin:@edhdb:1521:ORCL
      -user scott -password tiger

Oracle provides support for transaction application failover (TAF). In case of connection failure, the application is automatically reconnected. Developers should also be aware that Oracle supports strong connection pooling to improve performance when interacting with the database.

11.5.2. The Material Request Executor (Session) Bean

The code for the Material Request Executor remains largely unchanged with the introduction of EJB. As stated previously, the Executor bean is responsible for maintaining the conversational state information. The Executor bean also plays the role of coordinator as it passes the HTTP request from the client to the user interface components and then obtains the resulting HTML stream for passing back to the browser.

This Executor bean is implemented as a stateful session bean; it has relatively few methods, and most of them simply delegate their implementation to other objects.

Transaction Control

As with many EJB applications, the session bean has responsibility for demarking transactions. This is done, in this case, mainly for efficiency. The entity beans have been defined such that all their business functions run in an existing transaction context if one exists (the Requires attribute in the application assembly section of the deployment descriptor). When users submit the HTML forms, it is possible they have updated many fields in the forms. This means that the Material Request Executor bean will make several calls to the MaterialRequest entity bean. By making all the calls part of the same transaction, the container will commit the changes to the database only after all the updates are complete.

The CatalogItem Bean

The CatalogItem bean is the representation of a product in the Stores Catalog. As with many the objects in the material request, it is effectively a read-only object (maintenance of the catalog is performed using a previously existing administration tool build, using Oracle Forms). One extra piece of functionality that has been added to the CatalogItem bean is an interface to the delivery lead-time information. This is provided through a stateless session bean.

Obtaining the Delivery Lead Time

For efficiency, a local copy (snapshot) of the catalog database table from the MMS database is taken nightly. This allows faster access to the catalog than through a database link, and the content of the catalog does not change often enough to require more-frequent updates. One piece of information that does change often, however, is inventory information. If an order can be fulfilled from stock, delivery happens within 24 hours. Otherwise, an order must be placed with an external supplier, which usually implies a longer delivery time. In order to give the EDH users some idea of the expected delivery time, live feedback from the MMS is required.

Minimizing the number of round trips between the business-logic tier and database tier can influence the response time. The relative percentage of read-only tables in the business-logic tier application can have an effect in the number of round trips your application has to perform. Database caches are effective in multitier environments in which databases are located on separate nodes. These caches reduce the load on the database tier by processing the most common read-only requests to data sets on the business logic tier. Oracle9iAS's database cache keeps track of queries and can intelligently route to the database cache or to the origin database, without any application code modification. Oracle9iAS database cache is not just an in-memory cache—it is also disk-backed cache. This combination does not limit the cache size of the memory footprints and also means that the cache is not “cold” immediately after a machine reboot.

This case provides a good example of where to use stateless session beans. This particular bean requires only a single method to call a stored procedure on the MMS database which returns a value object containing the delivery lead time and an associated comment. This feature creates a nice separation of the two systems; the ordering application (EDH) has no idea of how lead times are calculated—it knows only what service to ask (see Figures 11.12 and 11.13).

To simplify the use of this bean, a simple helper method, getLeadTime(), was added to the CatalogItem bean. This method obtains an instance of the Stores bean and calls its getLeadTime() method.