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:
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.
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:
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:
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:
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 2 shows the four types of participants in the adventure builder business process.
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.
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:
The OPC catalog manager needs to interact with external suppliers and also keep its customer offerings up to date.
Figure 3 shows the logical submodules of the OPC and their relationship to the other participants.
When the customer places an order, the following processing flow occurs. It is important to trace the messages and documents exchanged among participants.
Figure 4 shows the detailed order fulfillment work flow.
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:
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.
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.
Figure 5 shows the architecture of the communication infrastructure for adventure builder.
In this architecture:
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.
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.
Larry Freeman, Yutaka Yoshida, and Beth Stearns are members of the Sun Java BluePrints Engineering team.