Implementing a Business Process (Composition) | Web Services Patterns: Java Edition

To illustrate how to construct a simple business process and how to compose business activities, you will look at a simple business process from the P.T. Monday Coffee Company domain. Specifically, a user will place an order for a particular product. This example is simplified; it does not have credit checking or the ability to search for additional product if it is not contained within your warehouse, but it will suffice to show the basics of composition and a business process.

From a user's perspective, the business process inputs include the following:

A customer key that identifies the customer making the order
An order structure that contains the key to the ordered products and the quantity of each product to order

The output from placing the order is a key to the order used by the customer or the application for tracking the progress of the order.

The sequence of steps that occurs within the business process is as follows :

An application starts the business process by submitting a customerId , an array of productSkus , and a matching array of quantities . The arrays of productSkus and quantities must match in size .
The business process puts the input data into the common pool of data for all of the business activities to access.
The business process determines that the first step is to determine if the products exist in the warehouse and reserve them.
The warehouse reservation business activity uses the common data structure for the product data and reserves the products in the warehouse. Assuming the activity completes successfully, the activity places a success record into the data structure and returns to the main business process.
The business process checks the state of the data structure and then launches the business activity to create the order.
After successful order creation, the business process launches an activity to notify the warehouse staff to send out the order.
After the process notifies the warehouse staff, the process finally returns an order identifier to the user.

All kinds of permutations of the previous sequence and potential locations can modify the process. For example, you could do additional validation along the way to ensure that a customer has enough credit for the order (you have customer credit card numbers stored in the customer information profile). You could also create the order identifier before going through the remainder of the steps, allowing the rest of the business process to execute asynchronously. This latter permutation requires some additional mechanics that Chapter 9, "Exploring the Asynchronous Business Process Pattern," discusses.

You can represent the previous business process in a variety of ways. You could use simple workflow diagrams for documentation, or you could explore the current generation of business modeling tools. High-end modeling tools generate the appropriate business process from the modeled diagram, much as Unified Modeling Language (UML) editors generate code from the diagram. Instead of using this approach, the next sections go into the construction of the business process based on the simple specifications mentioned previously.

Defining the Interface to a Business Process

Rather than starting with a service implementation, you will work from the interface to the service implementation this time. In theory, the future has a large set of standardized business process interfaces already available and accessible via a tModel in UDDI. Even now, there are working groups that help to define these standards and make them available.

Note	See ebXML's Web site (http://www.ebxml.org/) or OASIS's Web site (http://www.oasis- open .org/) for more information on business process standards.

The interface is a WSDL file with everything required to define a service, but without the location information for a particular service implementation. This file is similar to one you would retrieve from a tModel residing in UDDI for a generic service interface. Within the WSDL file are the following:

Definitions of Array_of_int and Array_of_String types are in the first portion of the WSDL file. Both are complex types and therefore must be defined within the WSDL file.
There are two message types defined in the WSDL file: createProductOrder Receive and createProductOrderResponse . The former defines the message for invoking the ProductOrder Web Service, the latter defines the expected return message.
A single port type, product order, exists in the WSDL file. The port contains a single operation, createProductOrder .
The file also contains a binding for the product order port, ProductOrderSoapBinding , but this binding goes ignored when you create your own service that adheres to the WSDL interface.

Using a tool provided with Apache Axis (WSDL2Java), you generate a Java interface for a service that adheres to the WSDL specification. This interface serves as the basis for the Java business process implementation. Other users of the WSDL file can implement the same business process interface in other languages. WSDL2Java generated the interface definition shown in Listing 8-1.

Listing 8-1: Interface Definition Generated from WSDL for a Business Process

 package com.servicefoundry.books.webservices.processes; public interface ProductOrder extends java.rmi.Remote {   public java.lang.String    createProductOrder(         java.lang.String customer,         java.lang.String[] productSkus,         int[] quantity)   throws java.rmi.RemoteException; }

From the Java interface, you can see a reversal in techniques as to the complexity of the data passed to and from the process. In the previous chapters, you built up the complexity of the interface because you were essentially creating proxies to an object model. In this chapter, I have reversed that trend, even to the point of passing keys to the order, products, and customers as strings rather than key classes.

This change from a rich object model back to basic, flat data is an important trend for the application. As mentioned in the previous chapters, the richer the object model, the more difficult to translate the object model to the other architectures involved in the network. You will use the business process as a buffer to the object model. Users of the business process need only a small set of data types; you will manipulate the richer data structures from within the process.

Implementing the Business Process

Implementing the business process is similar to the pattern shown in Figure 8-2, but because you are using Java to implement the business process, you can add additional information to the generic pattern. Figure 8-4 illustrates the concrete example of the business process implementation for creating a new order. In the class structure, you keep the abstract definition of a business activity to provide flexibility and a generic sequence processing. The association between the ProductOrderImpl and the BusinessActivity is fulfilled by a LinkedList of business activities that need to complete to finish the business process itself. Recall that the previous section generated the ProductOrder interface from the WSDL file defining the business process interface. You modified some of the inheritance structure to facilitate the more generic BusinessProcess framework. Nonetheless, the data passed into the ProductOrderImpl on the createProductOrder operation (with the same signature as Listing 8-2) will be inserted to the common Hashtable data structure. All of the business activities access this data structure as a common data pool.

Figure 8-4: Product order business process

The logic for processing the individual business activities is in the createProductOrder method on the ProductOrderImpl class. After each business activity, the createProductOrder method places the result data into the Hashtable using a predefined key. This Hashtable contains all data accessible to a business activity; the only catch is that you should determine the keys to the data before creating the business process. Listing 8-2 illustrates a simple example of implementing a business process using this technique. The code is overly lightweight with respect to exception handling, but I wanted to keep the focus on the business process itself.

Listing 8-2: Implementing the Product Order Business Process

 public class ProductOrderImpl implements ProductOrder {   LinkedList sequence = null;   Hashtable data = null;   public String createProductOrder(     String customer,     String[] productSkus,     int[] quantity) throws java.rmi.RemoteException {     setup();     data.put("PRODUCT_ORDER.CUSTOMER.ID", customer);     data.put("PRODUCT_ORDER.SKUS", productSkus);     data.put("PRODUCT_ORDER.QUANTITIES", quantity);     PersistenceManager pm = getPersistenceManager();     Transaction t = pm.currentTransaction();     t.begin();     String orderId = null;     boolean successful = true;     Iterator i = sequence.iterator();     while(i.hasNext() && successful) {       BusinessActivity activity = i.next();       activity.setData(data);       activity.run();       successful = activity.isSuccessful();       data.put(activity.getKey(),          activity.getReturnValue());     }     if(t.isActive() && successful){       t.commit();     } else {       if(t.isActive() && !successful) {         t.rollback();       }     }     return orderId;   }   protected void setup() {     sequence = new LinkedList();     data = new Hashtable(5);     BusinessActivity removeProducts = new        RemoveProductQuantity();     sequence.add(removeProducts);     BusinessActivity createOrderLines =        new CreateOrderLines();     sequence.add(createOrderLines);     BusinessActivity createOrder =        new CreateOrder();     sequence.add(createOrder);   }   protected PersistenceManager getPersistenceManager() {     return JDOUtilities.getPersistenceManager();   }   protected PersistenceManager pm = null; }

There are a couple of interesting points to note in Listing 8-2. First, by implementing the entire business process and all business activities in Java, the Java Data Objects (JDO) transactional capabilities help make the business process robust and keep the data within the application coherent . This ability becomes more difficult to implement as the business process and business activities remove themselves from the context of a particular language and start to span multiple companies and active systems. There are evolving transaction semantics for Web Services, but go into application planning assuming you will have to spend considerable time getting transaction scopes and fault tolerance correct.

A second interesting point to note about Listing 8-2 is the fine line between a business process, a business activity, and simple methods on objects. Simply put, a business activity can very well be another business process, but not all business activities will be formal business processes. Often, business activities will be more fine-grained than a business process. Object methods can represent a business process or a business activity. Most often, a series of object methods achieve a particular business process or activity.

After implementing the ProductOrderImpl , you create the appropriate WSDD file for Apache Axis and deploy it to the Axis engine. After that, clients can access your implementation of the ProductOrder interface, as defined by the WSDL structure you originally retrieved from UDDI.