11.2. The EDH Component Model
As mentioned previously, the existing EDH architecture is based on the EJB specification, but it does not use any commercial EJB container. Figure 11.1 summarizes the main components of the existing EDH architecture.
Figure 11.1. CERN's Electronic Document Handling Application Architecture
11.2.1. EDH Document Servlet
Each electronic document in EDH has its own specific Document servlet. The role of the document servlet is that of a dispatcher. It uses a cookie stored on the user's browser to identify the user's ServletExecutor instance and then forwards the call directly to it.
11.2.2. EDH ServletExecutor
The ServletExecutor is the component that holds the conversational state information about the current interaction. An instance of a ServletExecutor exists for each open document on the user's screen. Its role is to hold references to the common business object (CBO) representing the document being edited and its user interface components, and to coordinate their activity. Oracle EJE addresses the scalability of such stateful components with a virtual machine architecture that reduces the response time by making sure each session perceives its own virtual Java virtual machine, Java global variables, threads, and garbage collector. The underlying runtime supplies the needed scalability. This enables the virtual machine to efficiently perform memory management, provide a low session footprint, and perform advanced garbage collection.
11.2.3. Common Business Objects
Within the EDH application, the equivalent of an Entity Bean is the Common Business Object (CBO). This object effectively provides an object representation of one of the application's business objects—for example, a purchase order, a person, or a currency. CBOs provide getX and setX methods for their properties, implement access control, have the ability to be persisted to the EDH database, and implement any necessary business logic (such as calculation of totals) and business rules (such as requiring mandatory fields, permitting only allowed types of cost center, and so on).
In accordance with the EJB specification, the application gets its CBOs from a Home interface through its findByX and/or create() methods. An EJB client first obtains a reference to the home interface with the Java Naming and Directory Interface (JNDI) mechanism. Oracle EJE behaves like a namespace server by implementing a JNDI interface resulting in location transparency. This is particularly useful when changes to the server environment must be made without seriously disrupting the client. In addition, the namespace has fast access to indexed entries in the cache, resulting in performance improvement.
11.2.4. Common Input Objects
The Common Input Objects (CIOs) are a set of classes responsible for building the user interface for our Web applications. Each CIO represents a single data type within the document. CIOs can be Numbers, Dates, and Text, as well as more-complex objects, such as People, Currencies, and Suppliers.
Within an EDH document, a CIO instance is created for each field. When the HTML form is submitted, the CIO is responsible for parsing the data from the user and performing some basic validation, such as maximum string length for Text input objects, or verifying if the person exists for Person input objects. One of the advantages in moving to frameworks such as Oracle Business Components for Java is that it provides mechanisms for defining, implementing, and executing validation logic in the business logic tier. The validation framework provides a consistent programming model that hides internal implementation details.
When a response is sent back to the user, the CIO is capable of creating an HTML representation of its value that can be substituted into an HTML template.
Figure 11.2 illustrates two CIOs in operation. As you can see, the CIO can represent itself in a manner that is appropriate to the data type and can also take into account the user's preferred language (the currency CIO is rendered in French). Oracle supports one of the richest sets of multilanguage character support in the market, incorporating many open and vendor-specific character sets within the database. Among the standards supported by Oracle is UTF8, or Unicode 2.1. Thus database utilities and error messages, sort order, date, time, monetary, numeric, and calendar conventions automatically adapt to the native language and locale.
Figure 11.2. Generating a User Interface Employing Common Input Objects
11.2.5. Runtime Scenario
Two classes, a DocumentServlet and a ServletExecutor, provide the user interface to the common business objects.
A single instance of the DocumentServlet exists for each type of document and is shared by all users. Its job is to find the appropriate ServletExecutor for the user and forward the requests to it.
A ServletExecutor instance is created for each open document window during the session. The job of the ServletExecutor is to interpret the information in the user's request and make the appropriate calls to the CBO. Once the ServletExecutor has processed the entire request, it then creates the response HTML by substituting placeholders in an HTML template with the values from the now updated CBO.
The Oracle Servlet Engine (OSE) provides the runtime environment to execute servlets. OSE supports the Java servlet specification for processing HTTP requests. OSE is designed for virtually unlimited linear scalability and supports thousands of concurrent users, with an extremely low session footprint. The mod_ose plugs into the Oracle HTTP server architecture and routes requests to the OSE. The OSE offers in-memory access to EJBs, enabling better performance. OSE supports authentication and access control, as required by the servlet specification. Servlets running in OSE efficiently use the Oracle9i application Server data cache, running in the same process space as the data cache SQL engine.
The OracleJSP implementation is highly portable across server platforms and servlet environments. OracleJSP can run in any servlet environment that complies with version 2.0 or higher of the Sun Microsystems Java servlet specification. In addition to the JSP specification, OracleJSP supports SQLJ programming in JSP scriptlets, and JML tags to support XSL transformations within a JSP page. OracleJSP has been ported on all Oracle servers and tools: Oracle9i, Oracle9iAS, and Oracle JDeveloper.
Figure 11.3 illustrates the sequence of events and how each object interacts when a user submits a form.
Figure 11.3. Electronic Document Handling Application Runtime Scenario
As shown in Figure 11.3, the steps in processing a form are
1. | |
2. |
The DocumentServlet then calls the ServletExecutor so that it can process the user's input. |
3. |
The ServletExecutor first makes a call to each of the CIOs so that they have an opportunity to interpret the user's input. |
4. |
If the CIO successfully interprets the form data, the ServletExecutor then calls the corresponding setX method on the CBO. The CBO either accepts the new value or throws a ConstrainedPropertyException, indicating that the value is not valid. If either the parsing of the user input or the setX method call of the CBO failed, then the CIO is set to error state, which appears to the user as an error message (see Figure 11.4). Figure 11.4. Date Input Object Showing Error Message
After all the CIOs have been processed, the ServletExecutor returns control to the document servlet. |
5. | |
6. |
