1.7 Web Services in the BluePrints Application

The Java BluePrints Pet Store sample application uses Web services to communicate between its Order Processing Controller (OPC) and external supplier applications. This section examines the sample application's use of Web services to illustrate the architectural models and technologies discussed previously.

The sample application follows a document exchange for a purchase order initiated in the Java Pet Store front end. The Order Processing Center (OPC) application manages the order, sending every purchase order through a defined sequence: the OPC first ensures that the buyer has sufficient funds for the purchase and then orders the product from the supplier. The OPC defines the business process for handling purchase orders. The business process consists of a workflow, which is a sequence of steps with transitions between steps. Transition delegates are classes that handle the transitions between workflow steps. The sample application uses a document-oriented business process to co-ordinate its internal workflow and to communicate with its supplier application -- its transition delegates pass XML documents between workflow steps by placing JMS messages in message queues, a form of asynchronous communication. These JMS queues (and topics) are the transition points between steps. The XML documents serve as the internal data model for the applications, and they may be validated against specific public XML schemas (DTDs or XSDs).

The application was developed using an asynchronous architecture because of the amount of time it takes to process an order through the workflow. A document-centric approach was used because passing XML documents works best with asynchronous communication.

The Supplier is an external application that ships orders to customers and invoices the OPC. Because these applications are potentially on different platforms, communication between the Supplier and OPC is through a Web service. The two applications pass XML documents between them. These XML documents conform to a pre-defined public XML schema which is accessible through a public URL. Such schemas ensure proper document exchange and allow documents to be validated.

The communication between the OPC and Supplier applications is also asynchronous. With asynchronous communication, the OPC does not have to wait for the Supplier to complete its order processing. Figure 1.14 shows a high-level view of the communication between the OPC and the Supplier applications.

Figure 1.14 High Level View of Web Services in the Sample Application

The OPC application processes documents through its internal workflow using a series of message-driven beans and JMS queues. Each message-driven bean uses a pluggable transition delegate to determine the next step in the workflow. Using transition delegates allows for flexibility if the type of communication changes between workflow steps.

The OPC receives the purchase order through its Purchase Order Queue and obtains an order approval by sending a message to the Order Approval Queue. The Order Approval message-driven bean confirms if funds are available for the order.

Once the order is approved, the OPC then sends the order to the external Supplier application. To do this, the Order Approval message-driven bean invokes the Web Service Transition Delegate, which looks up the Supplier's Web service endpoint and the public XML schema for the document. The bean then sends the purchase order as an XML document to the Supplier's service endpoint.

The Supplier Web service endpoint receives the document and validates it against its public XML schema. It transitions valid purchase orders to the next step in the Supplier's workflow, using an approach similar to that of the OPC: JMS messaging with message-driven beans and transition delegates. The Supplier fills valid orders and ships products to the user. It also creates and returns an invoice as an XML document to the OPC. The Supplier sends the invoice document as an attachment to a request sent to the OPC's Web service.

The OPC Invoice Receiver Web service endpoint receives the invoice, validates it against the public XML schema, and places it in the JMS Invoice topic. The invoice now moves through the OPC's invoice processing workflow. Two message-driven beans, Invoice and Mail Invoice, both listen to the Invoice topic and both process an invoice placed in the topic. Mail Invoice sends an XML message that is used to generate an email message notifying the customer that the order is complete.

The sample application shows how to use an asynchronous messaging infrastructure with transition delegates to handle XML document exchanges. The process can encompass Web services. Let's look more closely at Web services and the XML document exchange between the applications.

Figure 1.15 The XML Document Flow in the BluePrints Application

Figure 1.15 shows how the OPC and Supplier exchange XML documents and use Web services. XML documents are used to pass information between these two applications. The document exchange starts with the TPASupplierOrder.xml document. Before sending this document to the Supplier, the OPC applies a stylesheet to the document to extracts its data or to convert it. Data must be extracted so that the proper steps may be taken to process the order. The OPC separates XML document validation and manipulation from Java code. The OPC also converts XML to Java objects.

Once the OPC has formatted the TPASupplierOrder.xml document to conform with the TPASupplierORder.xsd XML schema, the Supplier Order Sender JAX-RPC client sends the document to the Supplier's Web service endpoint. It reformats the document to the required schema definition for the Supplier. The Supplier Order Sender then sends the document as an attachment to the Supplier service JAX-RPC endpoint.

The endpoint receives the TPASupplierOrder.xml document. Before doing any processing to the document, the endpoint validates the document against the TPASupplierOrder.xsd XML schema, which it accesses from the OPC via a public URL. Once it determines the document is valid, it uses the XDE pattern to convert the document to its internal format. The endpoint then passes the internally formatted document to the next step in the workflow, SupplierOrderRcvr.

The order's contents determines how it moves through the Supplier workflow, and steps in the workflow communicate to each other asynchronously. Subsequent steps in the workflow do not have to validate the document because the service endpoint already converted it to the application's internal format. Once the order is filled and the invoice prepared, the Supplier sends the invoice to the OPC Web service endpoint. Its Invoice Sender JAX-RPC client follows steps similar to the OPC's Supplier Order Sender JAX-RPC client.

The service endpoint receives the document and validates it against the TPAInvoice.xsd XML schema. If valid, it sends the document to the InvoiceRcvr step, which asynchronously passes it to the next step in the invoice handling workflow.