Using Weblogic and Enterprise Java Beans in a web application

Note that I'm not trying to sell you on this as a particular solution. Rather, I'm describing one particular implementation using this architecture.

Overview

A major marketing firm in the Cincinnati area has employed Cardinal in the development of a web interface for one of their main products. The web interface will provide a set of programmable API's for customers to have full access to their database and business rules in real time over the web. The final solution can be customized to fit an existing eCommerce platform.

Application architecture

Weblogic has been selected as the application server environment, although the product is portable to other application servers including IBM's Websphere. The application consists of eleven Enterprise Java Beans (EJBs), over 40 Java Server Pages (JSPs), and 39 Extensible Stylesheet Transformation (XSL) files.

The web interface consists of JSP pages that invoke methods on a Java EJB client. This client converts those method calls into XML requests that are then sent to a single EJB dispatcher that interprets the request. The dispatcher examines the XML (after converting the incoming message to an XML Document Object Model (DOM) representation) and dispatches new XML requests to the other EJBs in the system that act on these requests. Some of the EJBs in the system are general in function and can turn the XML request into SQL commands which are executed against the Oracle database via Java Database Connectivity (JDBC). Other EJBs are specialists and transform the incoming data in the XML request into more complex behaviors.

Once the EJB has processed the data, the results are placed into an XML message and sent back to the dispatcher EJB. This dispatcher grafts the results into the original XML request and sends the modified XML back to the client. The client then passes the XML data into an XSL transformation file and returns that HTML text to the JSP page. The JSP page takes that HTML text and integrates it into the page output.

The progress of any transaction can be monitored at several levels (debug, informational, warning, and error) via the Java Message Service (JMS) and associated clients. In this implementation, the system is monitored in real time by Java Swing GUI JMS clients that provide detailed information on any transaction in the system. Additional JMS clients provide persistant logging and auditing of transactions to disk file or database table.

Advantages and disadvantages

An advantage to this kind of architecture is the relative ease with which changes can be made to the system. If most requests are simple database queries, those can be handled by the general beans. Even stored procedure calls are handled by the general beans. Only for complex sub-systems with rich data (say, dynamic surveys) are custom EJBs required.

Another, non-obvious advantage is that the system is portable to different front-ends. Note that the web interface communicates with the application server via XML. This is typically done via EJB calls from one Java VM to another, but an HTTP POST Java Servlet has been written to handle this kind of communication as well (for B2B communication). Additional front-ends can be developed for web-enabled phones, legacy EDI systems, interactive voice response systems, etc.

A third advantage is scalability. The EJBs in the system are stateless and work with individual transactions rather than sessions. In the implementation described above, the web application maintains state for the user (keeping track of log ins, timing out expired sessions, etc.) while all the transactions against the system occur as simple requests. If needed, the system could be scaled to a cluster of application servers to handle the requests with no additional development effort.

A disadvantage to this kind of system is that it is expensive to run. You cannot expect most commodity hardware to put up with the kind of load that the application server and database will put on it. There are several components that require a strong commitment to fast hardware to keep transaction times to a mimimum.

Development team skills

The primary skills needed to update an application built with these technologies include application server administration, varying levels of SQL programming (for database changes), JSP maintenance and development, XML Data Type Definition (DTD) maintenance and development, and XSL transformation file maintenance and development.

New development of a system like this requires an experienced team who understand the Java 2 Enterprise Architecture (J2EE), SQL, XML, XSL transformations, and web interface development.

In business

There have already been two production installations of this system for the marketing firm's clients, with another scheduled to begin in March and several more lined up for later in 2001. The time to develop a new web site based on this architecture is two weeks or less for the XML DTD, JSP, and XSLT development. This is predicated on the readiness of the graphics, text, page flow, and database infrastructure. Most clients of this firm use the generic page flow developed for this product and already have the firm's database installed and configured as part of their current busines.