Enhancing Web Services Infrastructures with JMSby Gunnison Carbone
Web services are revolutionizing the Internet by enabling applications to speak a common language: XML. Under the Web services paradigm, a single application can tap into the services of millions of applications scattered throughout the Internet. The potential of this is enormous. Web services allow cooperation, communication, and integration on a global scale.
While Web services technology enables the execution of remote functions and messaging, it does not provide a robust infrastructure for handling information. An enterprise-class application that communicates with Web services must ensure that the data can be handled appropriately.
When employing Web services, one must ask questions like: Can our application scale to increased messaging demands? If our application crashes, is the Web services data lost? How do we efficiently replicate similar Web services clients across several applications? How do we connect our Web-services-facing applications to back-end systems?
As an example, let's look at a hypothetical e-commerce application that receives and processes orders through Web services. If the Web services data is not persisted, the data will be lost if the application fails. If the system is inundated with orders -- spiking from, say, a few thousand transactions a day to 10 or 100 times that amount -- it must be able to handle the increased load. If the application needs to interface with a backend system (i.e. an inventory management system) to determine if a product is in stock, there must be a bridge for efficient and reliable communication.
These problems are created but unfortunately not solved through the Web services architecture. Web services must be combined with additional technology for robust enterprise messaging. One very strong candidate is the Java Message Service (JMS). JMS provides a reliable, scalable, and loosely coupled architecture for messaging. The combination of Web services with JMS creates an architecture that can communicate across the Internet, reliably handle data, and integrate with backend systems.
A first-generation Web-services-enabled application contains or directly interfaces with a client that communicates with Web services, as depicted in Figure 1. This architecture enables the application to find and communicate with remote systems, but does not implement data relability, scalability, and reusage of Web service client logic. The addition of JMS creates a second generation for architecting Web services systems, as shown in Figure 2. JMS decouples the application from the task of Web services messaging. Applications communicate directly or through an adapter to the JMS server.
In this new architecture, hybrid JMS and Web services clients handle the bulk of the messaging duties. Information is passed through the JMS server, which natively handles issues like failover, load balancing, and guaranteed message delivery. By decoupling the Web services client from the application, several applications can effortlessly reuse a single Web services client. Decoupling makes it a simpler process to upgrade the Web service as inevitable software changes occur. Additionally, an application that becomes busy will have its Web services data automatically queued in the JMS server until it is able to process the messages. In a tightly coupled architecture, the application's Web services piece would have to wait until the application is ready to begin processing data.
A Second-generation Web service
To demonstrate this second-generation Web services architecture, we'll develop an example using several popular open source tools. This example is a simplified portion of an e-commerce system. It is composed of four Java classes:
JMSClientSendReceive.java: This class provides basic functionality for a JMS client that can both send and receive messages with JMS queues. The
ShippingClientclasses extend this class.
OrderApplication.java: This is a bare-bones enterprise application for processing orders. It utilizes
ShippingServiceto calculate shipping costs for each order.
OrderApplicationinterfaces with the JMS server to send and receive messages from the
ShippingClient.java: This is a hybrid JMS/Web services client that provides a bridge between JMS messaging and SOAP communication. For simplicity, our example client utilizes the Remote Procedure Call (RPC) method for invoking
ShippingService.java: This is a simple Web service that implements one function,
calculateShippingCost, which returns a shipping cost based on the order's weight and destination.
To build our system, we'll utilize the following open source tools:
Open3.org JMS Messaging Server. The Open3.org community provides an LGPL open source implementation of the latest JMS 1.0.2-b specification.
Apache SOAP. Apache SOAP is an implementation of the SOAP 1.1 specification. We'll use Apache SOAP to build the Web services client and, together with Apache Tomcat, host our sample Web service.
Apache Tomcat: The ever-popular JSP/Servlet container hosts the
Figure 3 displays the basic architecture of the system.