Designing J2EE 1.4 Web Applications: An Excerpt from Designing Web Services With the J2EE 1.4 Platform

Print-friendly Version

With the release of the Java 2 Platform, Enterprise Edition v. 1.4 Software Development Kit (J2EE 1.4 SDK), web services becomes a standard feature of the J2EE platform. Java web services, with its support for SOAP, WSDL, and WS-I Basic Profile, are now integrated with servlets, JSP pages, and enterprise beans. Developers new to web services can leverage their existing knowledge of J2EE, and developers familiar with Java web services can reuse the same APIs in a more standard way. With these opportunities come new choices and new design decisions that need to be made: What is the most appropriate way to implement a web service client? What is the proper integration technology to use: JAX-RPC, JMS, J2EE Connector architecture, or RMI-IIOP? How do design patterns fit in with web services?

To help developers make these critical design choices, with each new version of the J2EE technology released, Sun has offered the Java BluePrints, a set of guidelines that outline the design trade-offs and architectural implications of the latest features of the J2EE technology. The Java BluePrints:

• Consists of preferred practices, design choice analysis, reference code, and design pattern discussion.
• Goes through each of the major areas of the J2EE 1.4 platform and provides a detailed discussion on the design choices available and the implications for each choice.
• Includes the following topic areas: Service endpoint design, client design, XML processing, enterprise application integration, security, and application architecture.

The reference application for the J2EE 1.4 platform is a travel agency scenario titled Java Adventure Builder Reference application. The adventure builder reference application does for the J2EE 1.4 SDK what Java Pet Store did for the J2EE 1.2 and J2EE 1.3 SDKs. Like Pet Store, the adventure builder reference application is more than just sample code. It represents the earliest demonstration of design patterns, design decisions, and implementation of Sun's recommended practices for writing J2EE applications. The Java BluePrints web site includes online versions of the J2EE 1.3 BluePrints book, early access chapters to the upcoming J2EE 1.4 BluePrints book, a design pattern catalog put together by the authors of Core J2EE Patterns, and links to downloads of Pet Store and the adventure builder reference application. The adventure builder reference application is meant to showcase portable J2EE code. In addition to illustrating Java BluePrints guidelines, it has been verified with the J2EE 1.4 Application Verification Kit, Sun's tool for verifying portability in J2EE applications.

Java Adventure Builder Reference Application

The adventure builder reference application focuses on the latest features of the J2EE 1.4 platform. It presents a travel agency scenario where users can create custom-built travel adventures. Web services is about communication between clients and end points, and the adventure builder application seamlessly links multiple web services together to form a demonstration of the travel agency of the future where tourists can sightsee on Mount Kilimanjaro, journey to the Antarctic, or schedule a trip to the space station. The travel agency scenario itself is not as important as the techniques used to aggregate back-end services. In particular, the application takes advantage of the following features from the J2EE 1.4 SDK:

• Component-based development model to simplify J2EE application architecture
• Support for emerging Web Service standards such as the web services Interoperability Organization's WS-I Basic Profile 1.0.
• Support for using web services in a portable, interoperable way with such web service technologies such as JAX-RPC, SAAJ, JAXR, JAXP, and JAXB
• Scalable design for distributed applications
• Integration with existing enterprise information systems using industry standards such as JDBC API and JMS.

Typical Web Services Scenario

Enterprise applications cover a wide spectrum of scenarios such as interactions between business partners, supply chain management, and inventory management. A decision to use web services should be based on the factors involved. In many situations, JMS or RMI-IIOP may very well be a more appropriate solution. In general, web services may be the appropriate solution if you are dealing with the following situations:

• Need for interoperability in a heterogeneous environment
• Integration requirements for an environment containing various enterprise information systems
• Need to simultaneously support multiple client types such as J2EE applications, wireless devices, and PDAs
• Availability of web service tools
• Willingness to tolerate lower performance

Figure 1 shows the high level architecture of the Java Adventure Builder Reference application. Each feature is implemented as a module.

Basic steps in using the application include the following:

• From a browser, a customer selects vacation options to build a perfect vacation.
• A customer puts together these choices to build a vacation package.
• A customers submits the order.
• The web site builds a purchase order and sends it to the order processing center (OPC).
• The order processing center is responsible for fulfilling the order and interacts with internal departments and external suppliers to complete the order.

In essence, the adventure builder application consists of a front-end customer web site which provides an interface to customers and a back-end order processing center which handles order fulfillment processing.

Figure 1 Click to enlarge

Figure 2 shows the four types of participants in the adventure builder business process.

Figure 2 Click to enlarge

• Customers: customers shop and place orders.
• Customer web site: provides the web pages that let customers shop and place orders.
• Order Processing Center (OPC): the Order Processing Center is at the heart of the adventure builder enterprise, responsible for coordinating all activities necessary to fulfill a customer order. The OPC interacts with:
  • Customer web site: to handle order-related matters.
  • Customers: to send email notifications regarding orders
  • Credit card service: to collect payment
  • Suppliers: to fulfill the items in order
  • Internal adventure builder departments: to support and manage the order fulfillment process.
• External partners: airlines, hotels, and activity providers supply the services or components of a vacation. Other partners such as banks or credit card companies collect payments for the enterprise.

The business problem for adventure builder is to ensure that the participants interact successfully so that customers can purchase adventure packages. To solve this problem, the enterprise must architect, design, and build appropriate J2EE applications that provide the needed business functionality and tie the application modules together.

Order Processing Center In More Detail

The Order Processing Center (OPC) is the core module of the application which handles web services. For this reason, the rest of this article looks at it in more detail, examining its responsibilities for coordinating and communicating with other business units to fulfill orders.

The OPC module needs to perform the following functions:

• Receive customer orders from the web site and process these orders
• Coordinate activities according to the business workflow rules
• Track an order's progress through the steps of the order fulfillment process
• Manage customer relations, including tracking customer preferences and updating customers on the status of an order. This includes sending formatted emails to customers about order status.
• Manage financial information including verifying and obtaining approval for payment.
• Interact with business partners, airlines, hotels, car rental agencies, adventure or activity providers to fulfill a customer's adventure package.
• Provide and maintain a catalog of adventures and allow customers to place orders.

The OPC catalog manager needs to interact with external suppliers and also keep its customer offerings up to date.

OPC Submodules and Interactions

Figure 3 shows the logical submodules of the OPC and their relationship to the other participants.

Figure 3 Click to enlarge

• Order Receiver: Accepts purchase orders from the customer web site. This submodule starts the order fulfillment processing in the back end of the enterprise. Each order is identified by a unique ID.
• Workflow Manager: Enforces the process flow rules within the adventure builder reference application and tracks the state of each order during its processing. The workflow manager interacts with the internal departments and coordinates all the participants in the business process.
• Finance: Interacts with external bank and credit card services that collect payments and manage financial information.
• Customer relations manager: Provides order tracking information to the customer web site application. This submodule also sends formatted e-mail notices about order status directly to the clients.
• Order Filler: Exchanges messages with the various external suppliers to fulfill purchase orders. Messages include supplier purchase orders and invoices.
• Catalog Manager: Interacts periodically with the suppliers' catalog information to maintain the customer web site database. The catalog manager may also leverage a registry maintained within the OPC.

When the customer places an order, the following processing flow occurs. It is important to trace the messages and documents exchanged among participants.

• A purchase order flows from the customer web site to the OPC.,
• The finance department and the credit card services exchange credit card payment requests and verifications.
• The OPC order filler and the external suppliers exchange supplier purchase orders, invoices, and other documents.
• The Workflow Manager and other departments or submodules within the OPC exchange internal messages.

Figure 4 shows the detailed order fulfillment work flow.

Figure 4 Click to enlarge

Web Services Interaction and Message Exchange

In the above workflow, the key architectural issue that the adventure builder application must solve is the interaction among different entities or applications. These entities and applications must communicate with each other and may often exchange documents and messages of various types across numerous boundaries and work together in a coordinated fashion to solve particular business problems.

The message exchanges during the order fulfillment process is typical of most web service-based applications:

• Clients or customers communicate with the customer web site through a web browser.
• Once a customer places an order, the GUI communicates a purchase order to the OPC.
• The web site GUI also follows up with the OPC to ascertain the current status of an order.
• The OPC sends purchase order to suppliers and receives invoices from these suppliers in return.

Communication Technologies

When selecting a communication technology for an application, there are many options to choose from: JMS, RMI-IIOP, web services, and so forth. For the adventure builder application, web services is used as the technology for communication between the OPC and external entities such as an external partner which accepts purchase orders and returns invoices. This choice was made because the adventure builder application is interested in achieving the best interoperability with all modules and client types. It is also important to integrate with the functionality of various partners since they are the ones who actually provide the services to customers.

Web services provides a good interface for separating and decoupling software systems. This is important for the adventure builder application since it is being built upon existing systems developed and owned by different departments within the enterprise.

Within the OPC module, the communication with sub-modules primarily uses JMS. JMS, which provides a more tightly-coupled communication model than web services, works well here. Since the OPC controls the entire environment within the module, communication can be more tightly coupled. Most of the communication is between the OPC workflow manager and the department sub-modules, and all sub-modules are within this environment. Given the control over the environment and that most communications are asynchronous, using JMS is appropriate. Also, since there is additional overhead to using web services, an application should use it only when it requires the benefits of web services. For communication among the entities within the OPC, the benefits of web services are not necessary.

Although the OPC and customer web sites are within the same enterprise, communication between the OPC and the customer web sites uses web services rather than JMS. The OPC module makes its services available as a web service to the adventure builder reference application web site. That means that the web site uses the OPC's web service to fulfill an order. There are advantages to this implementation. The web site for the OPC module may be hosted outside the firewall even though the OPC module itself is always inside the firewall. By exposing a web site interface to the OPC, the web application running the web site may conveniently use the HTTP port available on the firewall to access the web service. Also, web services allow both the client and server to be on different hardware and software platforms. This makes web services a reasonable choice since the adventure builder web site may be hosted on a different hardware platform from the OPC module. Developers may want this platform flexibility since the web site is on the internet and may need to scale to handle very large loads. Furthermore, the web site must be responsive to customers whereas the OPC module, since it works asynchronously, is concerned with achieving high throughput.

Message Format

The adventure builder business problem involves the exchange of many different types of messages and documents such as purchase orders and invoices from different suppliers. Some of these documents or messages adhere to an internal format and others follow standard formats. Since the system must handle multiple message types, adventure builder uses XML as the message exchange format. While information can be passed either as XML documents or as Java objects, the choice of communication technology has implications for how information is passed through the system. Primarily, XML documents are used for communications, especially messages exchanged with trading partners. Since JMS is used internally within the OPC, a choice needed to be made between either passing XML documents between sub-modules or converting documents into Java objects. Since adventure builder models a document-oriented system and the sub-modules represent different departments, the decision was made to pass XML documents between them. By passing information in this format, internally each department has control over binding to the particular Java objects they need within their module. Passing XML documents also plays well for the chosen architecture which has a centralized workflow coordinator or manager that keeps the individual sub-modules and departments from directly communicating. In short, this keeps the department sub-modules more loosely coupled.

Communication Architecture

Figure 5 shows the architecture of the communication infrastructure for adventure builder.

Figure 5 Click to enlarge

In this architecture:

• The OPC uses a Workflow Manager which contains all process rules and flow logic to coordinate processing. The Workflow Manager also keeps track of the current state of each order while it is processed.
• Each participant knows its business functionality and how to execute its own step in the workflow; it does not need to know other steps in the process.
• Generally, each work step has a JMS resource and receives XML documents. The JMS resource is the integration point between the manager and each work module.
• A centralized service manages the interactions between the supplier and the OPC. Rather than having a separate web service endpoint for each message, all interactions between the OPC and supplier are grouped together and handled by a common endpoint and interaction layer.
• Other parts of the OPC act as clients to the web service. For example, the finance module uses the credit card service.

The OPC internally uses a hub-and-spoke model where the Workflow Manager coordinates the participants in the order fulfillment process. Each participant receives an XML document from the workflow manager, processes the XML document by applying its portion of the business logic, and returns the result to the Workflow Manager which determines the next step to execute in the workflow and dispatches the appropriate request by sending an XML document to the proper participant. Each participant executes its part of the business functionality and has no need to know the over all process of the workflow.

The Web Service endpoints, used on the edges of the OPC for interactions between the OPC and its external entities, have different considerations. You should consider each endpoint design individually based on its particular interactions.

Conclusion

The Adventure Builder Reference application demonstrates the coding of a J2EE 1.4 web service. This article has discussed the design decisions that were made and the rationale behind those decisions. There are many other important aspects to consider when learning the reference application; there are web service endpoint design issues, client considerations, and challenges when managing more complex web service interactions. The upcoming Java BluePrints book, Designing Web Services with the J2EE 1.4 Platform, discusses these issues in detail. Early access chapters of this book are currently available on the Java BluePrints web site.

About the Authors

Larry Freeman, Yutaka Yoshida, and Beth Stearns are members of the Sun Java BluePrints Engineering team.