General Java

Sun, IBM, Novell, Oracle and nearly 50 other companies have proposed the Java 2 Platform, Enterprise Edition (J2EE) as a solution for the development and deployment of e-business applications. What is J2EE? What does it offer to developers and users of e-business applications? This article answers these questions and provides a sample application built on J2EE principles.

The Promise of J2EE
As more business is conducted over the network, enterprises find they can achieve more with less; they can interact with their customers and business partners more quickly and cheaply using networked business-to-business and business-to-consumer applications. These enterprises are conducting e-business. J2EE promises to make e-business even more compelling by defining the means to quickly and inexpensively develop, modify and deploy portable, easy-to-use, reliable, interoperable, scalable and secure e-business applications. To fulfill the promise, J2EE defines the following elements:

• A platform, including a runtime environment based on industry-standard APIs and protocols, and a well-defined scheme for packaging and deploying multitier e-business applications.
• An application programming model for developing applications that leverage the platform.
  
• A compatibility test suite verifying that a J2EE platform implementation complies with the J2EE platform definition; successful completion of the test suite serves to assure application developers that their J2EE-compliant applications will deploy and run on that J2EE platform implementation.
• A reference implementation that intends to provide an operational definition of the J2EE platform. It provides concrete answers where the platform and application programming model definitions are open to interpretation, and also helps popularize J2EE, serving as a means of demonstrating the capabilities as well as a base for prototyping J2EE applications.

While I was writing this article, a public draft of the specification for the J2EE platform was available, and a beta draft of the J2EE application programming model specification and a beta version of the reference implementation had just become available. A beta form of the Compatibility Test Suite is expected before the end of 1999. See http://java.sun.com/j2ee for details.

I'll focus on the J2EE platform and its benefits, and offer a brief look into the application programming model. I'll also describe an application that demonstrates the principles of the J2EE application programming model.

The J2EE Target Environment - the Middle Tier
Enterprise-class e-business applications typically exhibit multiple logical tiers, as shown in Figure 1. Depending on the application, the client tier may provide only a user interface or may also run some business logic. The client communicates with the middle tier via the Internet, an extranet or an intranet. The middle tier generally performs some or all of the user interactions and runs some or all of the business logic. The Enterprise Information Services (EIS) tier encompasses legacy or new, business-critical data and applications that typically should be accessed only by the middle-tier business logic - for example, databases, ERP systems and transaction systems.

J2EE focuses on the middle tier, which forms the foundation of an environment that must be secure, highly available, scalable and manageable.

Figure 2 shows how J2EE addresses the middle tier. A Web server, enhanced to support Java servlets and JavaServer Pages (JSP), handles the user interaction. An application server running Enterprise JavaBeans performs the business logic and accesses the EIS on behalf of the user. (See http://java.sun.com/j2ee for more information about servlets, JSPs, EJBs and other aspects of enterprise Java and J2EE.)

Figure 2 shows that J2EE allows a wide diversity of clients and protocols between the multiple logical tiers of the e-business application. J2EE makes recommendations, however, on the preferred application model for clients based on business needs and customer requirements. From the Internet or intranets, J2EE anticipates HTML and HTTP clients. The former, such as Web browsers, communicate with the Web server via HTTP or HTTPS and send and receive only HTML for presentation to a user. HTTP clients also communicate with the Web server via HTTP or HTTPS, but can exchange richer information, such as XML documents. These clients would typically be built using Java-based applets or applications. In the intranet, although HTML and HTTP clients are preferred, J2EE also anticipates IIOP clients that communicate through the application server to interact with EJBs directly. Today such clients must be Java-based applets or applications; future clients may include Microsoft COM objects.

The J2EE Platform
The J2EE-platform specification defines a runtime architecture for J2EE-compliant applications and defines mechanisms for application assembly and deployment. The J2EE runtime architecture, shown in Figure 3, makes a clear distinction between the J2EE platform - that is, the runtime infrastructure for an application - and the application itself.

The platform consists of a set of containers: an applet container for client-side applets, a Web container for the servlets and JSPs, and an EJB container for the EJBs. The applets, servlets, JSPs and EJBs that constitute an application are called components.

The distinction between containers and components is very important. A container provides a standard runtime environment for a component, that is, a set of services the component can use to accomplish a specific task.

The component services define a concrete set of application programming interfaces that enable components of the proper type to access underlying J2EE services. A container can therefore transparently provide enterprise-critical services such as transaction management and security while simultaneously providing enterprise-critical attributes such as scalability, reliability and support for multiple users. These container properties make the task of writing components much easier and guarantee that components written by a component provider can be portable between J2EE platforms from different J2EE platform providers.

The set of J2EE services provided to a component by a J2EE container depends on the component type. The most basic applet container provides only the Java 2 Platform, Standard Edition (J2SE), which includes JavaIDL and the JDBC base (see http://java.sun.com/products/jdk/1.2). A more sophisticated applet container - for example, one that allows applets to access EJBs directly - provides additional enterprise APIs, such as JNDI and RMI/IIOP, as shown in Figure 3.

The Web container always provides the J2EE server core, which includes J2SE and the following enterprise APIs: a JDBC extension, RMI/IIOP, EJB client, JMS, JNDI, JTA, JavaMail and JAF. In addition, the Web container always provides the enterprise APIs for servlets and JSPs. The presence of JDBC requires that the Web container also provide a database service.

The EJB container always provides the J2EE server core and the enterprise APIs for EJB servers. It also provides a database and a transaction processing service to support the persistence and transactional capabilities of EJBs.

Any J2EE platform must supply all the containers, services and APIs required by the J2EE platform specification, eliminating the need for application writers to deal with tricky integration issues. Each version of the J2EE platform specification will require specific versions of the APIs. Future versions of the J2EE platform may require support for additional APIs.

One of the clear goals of J2EE is interoperability with a number of different clients. To achieve this, the J2EE platform services and APIs support a set of industry-standard communication protocols and data formats. J2EE requires support for the following protocols: TCP/IP and UDP/IP, HTTP, SSL (HTTPS), IIOP and JRMP. J2EE requires support for the following data formats: HTML, GIF, JPEG, and Java JAR and class files. Each version of the J2EE platform specification will require specific versions of the protocols and data formats. Future versions of the J2EE platform will require support for additional standards, such as XML.

Figure 4 depicts the J2EE platform specification for application assembly and deployment. Application assembly begins with the creation of components, such as servlets, JSPs and EJBs, using the APIs, protocols and data formats mentioned above. Multiple components for the same container type are packaged into a module that requires a module deployment descriptor containing information on how to deploy the components and how these components help compose an application. The module is the smallest unit for deployment on J2EE platforms.

A J2EE application includes one or more modules and an application deployment descriptor that describes the top-level view of an application - all the modules and information including application-level security roles. The final step in packaging the J2EE application is the creation of an enterprise Java archive file.

Deployment of a J2EE application on a J2EE platform leverages the platform's deployment tool to dearchive the application package, examine all the modules in the application and install the various components from the modules into the appropriate containers. Finally, the administrator must configure the component containers with deployment-specific values for all the properties in the various deployment descriptors, including security roles, user lists, transactional attributes and database targets.

A significant differentiator of the platform is the capability to assign different roles to different individuals or groups. J2EE platform providers offer the runtime environment including containers, APIs, enterprise services, and deployment and management tools. Component developers can create J2EE components, packaged as modules, that are independent of any particular platform implementation. Application packagers can create and sell applications using components provided by multiple component developers. A deployer installs and configures a J2EE application so it runs correctly and securely in a particular J2EE platform. A system administrator configures and manages the J2EE platform to make sure it provides an efficient and scalable runtime environment for applications. Even though the lines between the different roles may be blurred in some cases, this division of labor made possible with the J2EE platform increases the manageability of the platform itself, as well as the portability and manageability of applications deployed on the platform.

Further, it creates multiple opportunities for providers of e-business applications and application components and tools, and helps lower the cost of creating, deploying and using e-business applications.

J2EE Application Programming Model
The J2EE application programming model (APM) recommends how the J2EE platform specification should be applied to various application domains to derive the maximum benefit from the J2EE platform. The APM aims to make it easier to design manageable, deployable and maintainable e-business applications and get them to market quickly.

Figure 2 offers a high-level view of the J2EE APM. For the client tier of a J2EE application, the APM focuses primarily on a client that accesses a Web server using HTML (and later XML) over HTTP or HTTPS; however, the APM recognizes the likelihood that intranet clients will use IIOP to access the application server directly. In the middle-tier Web server the application uses JSPs and servlets for various forms of user interaction and control. In the middle-tier application server the application uses session EJBs to represent execution objects and uses entity EJBs to represent data or application objects.

Figure 3 offers a low-level view of the J2EE APM. At a low level the client-tier components use J2SE and perhaps some enterprise APIs to access the middle tier. The servlets, JSPs and EJBs in the middle tier use J2EE server core APIs and other enterprise APIs to access various enterprise services.

Since the APM is already defined at a high and low level by the J2EE platform specification, you should consider the J2EE APM specification to be a collection of architectural guidelines and design patterns for optimally developing and deploying e-business applications targeted at J2EE platforms.

The APM specification addresses a number of issues, including:

• Using servlets for processing client requests (controller) and JSPs for client responses (views)
• Accessing services directly or through "access objects" and "data access objects" abstractions
• Accessing EIS resources via EJBs or directly from JSPs
• Using session or entity EJBs
• Using distributed transactions versus local transactions
• Accessing external systems with "connectors"
• Using a model-view-controller design pattern
• Using JSPs or servlets in the Web container
• Accessing services directly or through "access objects" and "data access objects" abstractions
• Accessing EIS resources via EJBs or directly from JSPs
• Using session or entity EJBs
• Using distributed transactions versus local transactions
• Accessing external systems with "connectors"
• Applying security measures

A Sample Application - the Freeside Bank
IBM, as a supporter and contributor to J2EE, created a sample application that demonstrates important aspects of the J2EE platform. The Freeside Bank application, shown at JavaOne this year, is a prototypical banking scenario that includes activities such as customer login, account balance display and funds transfer. Freeside assumes a browser-based HTML client, uses JSPs to perform user interaction, and uses entity EJBs with container-managed persistence to represent customers and accounts and to perform transactions.

Freeside is a good approximation of a J2EE application and is useful to illustrate J2EE concepts, even though the application was implemented before the J2SE and J2EE specifications solidified.

In addition to demonstrating J2EE platform components, Freeside introduces the useful "command" design pattern, which is somewhat analogous to the "access object" design pattern in the APM specification. Briefly, the command pattern calls for the user of a command bean to instantiate the command bean, set the input parameters required to run the command's business logic, and then request that a command manager execute the command's business logic. The command manager incorporates knowledge about where to run the command's business logic, either locally to the client of the command or remotely. In either case, the client then locally accesses the results of the business logic execution. The command pattern presents a single model for local and remote command execution; for remote execution, commands result in fewer distributed method calls, greatly reducing the overhead in setting the input parameters, executing the business logic and retrieving results.

You can download the source and executable code for Freeside from www.developer.ibm.com/tech/integration/jsp.html. If you wish to run Freeside, you'll need Windows NT 4.0; JDK 1.1.6 or later; IBM's WebSphere Application Server, Advanced Edition 2.0 that includes IBM's HTTP Server v1.33 and IBM's DB2 v5.2; and a Web browser (4.0 level or higher, JavaScript-capable). You can find a free trial version of WebSphere at www.software.ibm.com/webservers/download.html.

Figure 5 shows the typical actions for a client request in Freeside and gives you a feel for how JSPs, commands and EJBs work together in a J2EE environment. The client makes a request on a controller JSP; the controller JSP uses a command bean to access an entity EJB with container-managed persistence.

The entity EJB represents information in a database. The EJB encapsulates its information content in a data bean that the command bean retrieves using a method on the EJB. The controller JSP extracts the data bean from the command and stores it in the Session object for the interaction. The controller JSP then redirects the client request to the display JSP, which then extracts the data bean from the Session object and performs the necessary activities to complete the request and display the results.

To make the description more concrete, I'll describe the Freeside customer-login process, starting from the Freeside "home page" (see Figure 6):

• The customer presses the "Online Banking" button that invokes the login JSP (login.jsp).
• The login JSP displays a form (see Figure 7) that collects the customer name and password; pressing the "Login" button invokes another JSP (doLogin.jsp). This separates user interaction from control.
• Listing 1 shows the key logic for the doLogin.jsp; it creates a Login command, sets the customer name and password parameters for the command, and requests that the command manager execute the command to authenticate the customer.
• Listing 2 shows the Login command "business logic"; it first gets an EJBHome object for the customer entity EJB, then attempts to find the customer in the bank's database using the customer name input parameter (customerLogin) as the key for the EJBHome finder method; assuming the customer exists, the EJBHome returns a customer EJB instance; the command then validates the password by comparing the password parameter (customerPW) to the password in the database, obtained by calling the getPassword() method on the Customer EJB; if the customer is validated, the command sets the output parameter (customerDataBean) to the bean returned by the Customer EJB getDataBean() method.

• Listing 3 shows the ejbCreate() and getDataBean() methods for the customer EJB; the EJBHome object for the customer EJB creates an instance and calls the ejbCreate() method when its search for the customer succeeds; ejbCreate() parameters are the information derived from the database by the EJBHome finder method; the getDataBean() method simply creates a data bean used to return customer information in one interaction rather than multiple interactions.
• Returning to doLogin.jsp in Listing 1, if the Login command succeeds, the JSP places the customer information returned by the Login command (and the Customer EJB) in the form of a data bean into the session object and redirects the browser to the viewBalance.jsp to display the account balances (see Figure 8); if the command fails, redirection is used to redisplay login.jsp.

• The viewBalance.jsp (see Listing 4) first gets the customer information in the form of a data bean from the session object, then retrieves account information by creating a ViewAccounts command, setting the parameters and asking the command manager to execute the command.
• Listing 5 shows the "business logic" for the ViewAccounts command. The command finds an EJBHome for the account entity EJB and then finds all the accounts for a customer using the customerID parameter as a key; the finder returns an enumeration of account EJBs; the command puts the data beans from all account EJBs in its output parameter (accounts).
• Listing 6 shows the ejbCreate() and getDataBean() methods for the account EJB; the EJBHome object for the account EJB creates an instance and calls the ejbCreate() method when its search for an account succeeds. The ejbCreate() method sets the information derived from the database by the finder method; the getDataBean() method simply creates a data bean used to return account information in one interaction rather than multiple interactions.
• Returning to viewBalance.jsp in Listing 4, if the ViewAccounts command succeeds the JSP proceeds to display the account information for all the accounts owned by the customer.

Once Freeside has displayed the account balances, the customer can request additional actions, such as transferring funds between the accounts. These additional actions use JSPs, commands and EJBs in a manner similar to that described above. The transfer action is particularly interesting in that it uses several levels of JSPs calling JSPs, commands calling other commands, and involves several entity EJB classes. A detailed description is beyond the scope of this article; you can examine the Freeside source if you're interested in learning more.

Conclusion
The J2EE platform defines a complete, machine-independent, standard environment that supports applications requiring security, reliability, scalability, transactions and other enterprise-class attributes. The J2EE APM builds on the productivity inherent in Java technology by offering guidelines for quickly creating J2EE-compliant applications while offering the flexibility required by specific applications. The J2EE compatibility test suite assures that J2EE platforms, expected to come from numerous vendors, offer a standard level of services and APIs for deploying J2EE-compliant applications. This allows application vendors to create a single application package for all J2EE platforms. Similarly, J2EE platform vendors benefit from a greatly expanded set of applications since compliant applications are guaranteed to run on their product. Platform vendors, however, can differentiate based on the level of security, reliability, scalability, tools support, legacy integration, manageability and other factors transparent to the application.

These characteristics give application vendors, platform vendors and customers a great deal of freedom of choice and lead to lower costs for J2EE platforms and applications.

You've seen the promise of J2EE, but can you buy a J2EE platform and begin developing and deploying J2EE applications? Not yet. But today major industry players sell products, usually called application servers, that exhibit many J2EE characteristics. You can use these application servers to begin leveraging the advantages of J2EE. IBM's WebSphere and BEA's WebLogic are examples of currently available application servers. These companies, and many others including Bluestone, Gemstone, Oracle and the Sun/Netscape alliance, are expected to offer J2EE-compliant platforms as soon as it's feasible. Many of the same vendors and lots of other companies, large and small, are expected to produce platform components, application components and full J2EE applications.

The e-business applications of today and tomorrow require a number of enterprise-class characteristics and the flexibility to support varied networked business-to-business and business-to-consumer situations. J2EE promises the very characteristics needed for inexpensive, rapid development and deployment of e-business applications. J2EE creates an environment for e-business applications that allows everyone - J2EE platform vendors, J2EE application vendors, server manufacturers, the businesses using J2EE platforms and applications and, most important, the end user - to win.