11.4. The CERN Material Request
The CERN Material Request is a Web-based electronic document that allows any of the 10,000 people working on CERN activities to purchase any of 16,000 standardized items from the CERN Stores Catalogue.
The Material Request document resembles almost any on-line order form, as you can see in Figure 11.10. It consists of a simple header that holds information about the customer, and how the goods are to be paid for, followed by one or more line items that contain quantity, description, and price fields.
Figure 11.10. The EDH Material Request Document
One of the first steps in converting the document to EJB is to identify the existing objects:
BudgetCode
CatalogItem
Currency
Location
MaterialRequest
MaterialRequest Line Item
Person
The list is divided into “simple” objects (Person, Location, Budget Code, and CatalogItem) that were converted to EJBs in the same way as were the Currency object, and the more complicated updatable objects.
11.4.1. The CERN Stores Catalog
Every item in the CERN catalog has a unique identification number (the SCEM[1] code) that allows for identification in the Materials Management System (MMS) database. CERN uses a commercial MMS from Baan running on an Oracle database. The CERN Stores Catalog itself is a separate custom application that provides two primary interfaces.
[1] Standard de Classification pour Equipement et Matriels
A set of tables in an Oracle database that contain all information available for every item in the catalog
A Web application (written in Oracle's PL/SQL programming language) that has the ability to “paste” a chosen product ID to another Web form, using JavaScript
These intefaces are designed to ensure that although CERN plans to reimplement the Web application with Java technologies, no changes will be required to this infrastructure.
The Material Request form accepts the product ID pasted into it, and then revalidates it on the server.
11.4.2. The Material Request Bean
The MaterialRequest bean is the primary business component in the application. It contains all the business logic for implementing our Material Request document (see Figure 11.11).
Figure 11.11. UML Diagram of MaterialRequest Bean and Object Associations
At this stage, bean-managed persistence was chosen, rather than defer it to the container because our MaterialRequest maps to more than one table and has relationships to other EJBs that must be persisted.
Persistence Methods
With bean-managed persistence, you must provide implementations for the ejbCreate(), ejbLoad(), ejbStore(), and all the finder methods.
The database schema for the Material Request consists of two tables, one that holds the main contents of the documents (EDHMAG), and the other that holds the individual line items (EDHMAGLI). The following is the start of the MaterialRequest bean implementation.
public class MaterialRequestBean implements EntityBean {
transient EntityContext ctx;
String shortDescription;
String comment;
Date creationDate;
ArrayList line_items;
Person creator;
BudgetCode budCode;
...
11.4.3. Object Relationships
The preceding Unified Modeling Language (UML) code shows that the MaterialRequest also references two other objects, a BudgetCode that indicates the account being charged for the purchase, and a Person object corresponding to the document creator. These objects will be stored as attributes of the EJB, and the relationship will be persisted by storing the primary key of the referenced objects in the ejbStore() method and then refinding the Person and BudgetCode objects again in the ejbLoad() method (see the following code) from the appropriate home interface through its findByPrimaryKey(). Alternatively, you can also do this in the getter method if the related object is not always needed (lazy initialization).
InitialContext ic = new InitialContext();
BudgetCodeHome bch = (BudgetCodeHome)ic.lookup
("java:comp/env/ejb/BudgetCode");
budCode = bch.findByPrimaryKey(budCodePK);
...
Notice that the Oracle EJB container does not require you to use PortableRemoteObject.narrow() when obtaining object references through JNDI. Instead, a simple Java cast is all that is needed.
Business Methods
The business methods of the MaterialRequest are where the business-specific logic is implemented.
The business methods fall into two categories.
The business logic specific to the MaterialRequest—for example, the methods responsible for validating the consistency of the materials request, and for calculating its total value in a specific currency
The methods responsible for manipulating the line items
The Material Request Line Items
The MaterialRequestLineItem objects are simple Java language objects. They implement the serializable interface so that they can be transported over the network by value. The infrastructure support needed to enable this communication is performed using RMI-IIOP, which is supported in the Oracle EJE environment. The line items are not implemented as EJBs for two reasons. First, they exist only within the context of a MaterialRequest object, and would never be referenced outside that context. Second, EJBs are relatively heavyweight objects that consume resources on the server and, therefore, should be used only where their added capabilities (such as transactions) are required.
As the previous illustrates, MaterialRequestLineItem objects are contained within the MaterialRequest. This is achieved by extending the ejbLoad() and ejbStore() methods so that the line items are retrieved along with the header in the ejbLoad() method, and stored at the same time as the header in the ejbStore() method.
Although it doesn't currently, plans are for Oracle JDeveloper to provide support for the Unified Modeling Language. Initially, it will consist of two UML modelers: a class modeler and an activity modeler. Developers will be able to use the class modeler to generate Java classes or Oracle Business Components for Java applications. In addition, a reverse engineering facility will allow developers to build UML models from existing code. The code will be automatically synchronized with the UML model so that changes you make in the class modeler are immediately reflected in your code, and the converse.