As the usage of Web service interfaces grows, we're starting to see the emergence of some key sectors where Web services will make a huge impact. Much as Java found its sweet spot on the Web application server, Web services will find its own sweet spots. Grid computing and e-business "building blocks" are two examples of Web services sweet spots. Another area where we see Web services as critical is Business Process Management (BPM).

BPM is the ability to orchestrate and control the execution of a business process across heterogeneous systems. BPM allows a user to see the components of the infrastructure from a business process view, rather than as a set of applications and databases. Part of orchestrating a business process is being able to manage the process even when it goes outside the enterprise, a common occurrence in today's e-business environment. When a process flows outside the enterprise, it needs a bridge from the private process to the public process. It is at this bridge point that Web services become important.

This article describes the role of Web services in the orchestration of business processes. We will look at two examples: (1) incorporating information from a public process into a private process, and (2) exposing a private process outside the enterprise. This process flow is described using a combination of technologies, most notably the BPM product from CrossWorlds, the company recently acquired by IBM. Using CrossWorlds tools and Web service technologies, it's possible to define a business process, such as a purchase order, that has both a private process and a public process.

The Basics
Before we get into the scenarios, let's review the basics of BPM first. In order to orchestrate a business process, you first define a common data format to be used between applications, and then define a workflow to move that data from one step of the process to the other. In CrossWorlds terms, this is done using a combination of connectors, business objects, maps, and collaborations. Connectors are the interfaces into the specific applications - wrappers around whatever the key APIs are that act as interfaces into the product. Business objects are the data - the information you want to extract from one application and move to another. Maps define the relationship between the application data ("Application Specific Business Object") and the common format of that data ("Generic Business Object"). Finally, a collaboration puts it all together - it is the collection of connectors, business objects, and maps put together in order to effect a business process.

Figure 1 illustrates typical business process flows using IBM CrossWorlds. Within the enterprise, applications communicate with the CrossWorlds Interchange Server or ICS via connectors (1). For outbound flows, the collaboration (business process) can leverage a Web services gateway by converting the business object into a SOAP message (2). The reverse can be handled as well for inbound SOAP messages (3).

In the following pages, we'll discuss some practical examples of leveraging Web services within two common BPM scenarios.

Scenario 1: Using Web Services From Within a Business Process
As mentioned above, business process definitions take the form of a flow through a set of application and data transformation steps. For this first scenario, let's use the example of a simple business process called OrderProcessing. An appliance company, StoneCold Refrigerators, has a Web site that allows customers to order replacement parts directly from the company via its Web site. A parts catalog is published, customers can purchase parts, and the orders are stored in a staging database by the Web front end. Once an entry is created in the database, a collaboration is triggered and the OrderProcessing process begins. StoneCold has a collaboration that extracts the record from the staging database, converts it to the generic business object format, and then performs a number of steps:

• It updates the company's CRM system with the information, allowing customer support to see the order.
• It identifies the vendor that supplies the part and, if the vendor is set up to fulfill orders directly, StoneCold passes the order along for fulfillment (for this scenario we will assume this is the case). The vendor, EverPure, provides replaceable filter cartridges for StoneCold's water-in-the-door system.
• It updates billing, order status tables, etc.

StoneCold's business process now extends beyond the scope of its own systems. The business process, OrderProcessing, now includes EverPure's IT system. Web services provide the interface definition between the two companies' processes. It's immaterial to StoneCold how EverPure's process is built, due to the nature of Web services. EverPure exposes this process using a WSDL definition and a SOAP interface, allowing StoneCold to transact directly with EverPure's process (we will examine EverPure's OrderStatus business process in Scenario 2).

In CrossWorlds, the connector for Web services is metadata-driven. The connector uses the metadata encoded in the business objects it processes, rather than relying on instructions coded in the connector. The connector calls the SOAP data handler that converts the CrossWorlds generic business object into an appropriate SOAP request message. The SOAP Connector then calls the EverPure, Inc., Web service using the corresponding URI. Once the destination Web service has processed the request, it sends back a SOAP response message. The SOAP connector using the SOAP Data Handler converts the message back into a generic business object and passes it to the appropriate collaboration.

The end-to-end transaction is summarized in Figure 2. Purchases are staged in a database (1) from which a collaboration periodically polls for new entries (2). Part of the collaboration process is to identify appropriate suppliers for various items within an order (3) and update StoneCold's CRM system with pertinent customer information (4). The CrossWorlds collaboration calls the SOAP connector associated with the EverPure, Inc. Web service (5). The SOAP Connector then calls the EverPure, Inc. Web service using the corresponding URI (6).]

Scenario 2: Exposing a Business Process as a Web Service
In the first scenario we saw how to invoke a Web service from an internal business process. In this scenario, we'll examine how to expose a business process as a Web service, thus allowing the business process to be kicked off by invocation from a public process view.

As mentioned above, EverPure has their own process, OrderStatus, for allowing customer applications to perform order status checks. Like StoneCold, EverPure, Inc. uses CrossWorlds for business process management. Their OrderStatus process is defined as a CrossWorlds collaboration.

The OrderStatus collaboration is exposed to the Internet via a WSDL definition using CrossWorld's tooling (see below). The client application at StoneCold sends a SOAP request to the URI specified in this WSDL file. A UDDI registry, whether public or private, may be used to discover the service.

The interface between a business process and Web services in CrossWorlds is provided by a SOAP proxy class and servlet. The Web server routes the message to the SOAP servlet. The servlet in turn calls the appropriate SOAP proxy class. The proxy class then calls the CrossWorlds Server Access Interface (SAI), which converts the SOAP message into a generic business object (GBO). The SAI then calls the appropriate collaboration with the GBO. Once the collaboration has completed processing, it returns the response message to the Server Access Interface. The SAI then calls the data handler to open the SOAP message format, returning the message to the SOAP proxy class and SOAP servlet.

As Figure 3 shows, the client application at StoneCold sends a SOAP request message (1) to the URI specified in the WSDL file that describes the collaboration exposed as a Web service. The proxy class then calls the Server Access Interface (2) The SAI calls the SOAP data handler that converts the SOAP message into a generic business object (3). The SAI then calls the appropriate collaboration with the generic business object (4).

Being able to expose a business process as a Web service is becoming an increasingly important function of a BPM system. Over time, the mechanics of doing this will become easier and the implementation options more diverse. Today, with CrossWorlds, as in Scenario 2, the primary way is to use the Web Services Generation Utility to produce the code and definitions needed to expose a specified collaboration and port as a Web service. In the remainder of this article, we'll examine the basic steps required to expose a CrossWorlds business process to the outside world as a Web Service.

• Expose the collaboration: Once you've identified the collaboration you'd like to externalize as a Web service, you need to perform key foundation tasks: (1) change the collaboration's trigger port to allow external output, (2) develop maps to support the conversion of existing business objects to SOAP messages, and (3) make sure the business objects are properly populated.
• Develop business objects: Using the Business Object Designer tool, you'll need to create new input and output business objects to externalize the collaboration as a Web service. Business objects can be considered as messages.

• Create Data Handler metaobjects: As we saw in Scenario 2, the SAI calls the SOAP Data Handler to transform SOAP messages into business objects and in turn transform business objects into SOAP messages. To perform these tasks, the data handler metaobjects are required. Metaobjects contain transformation information, as well as an associated child metaobject as shown in Figure 4. The child metaobject defines the business object, the verb (create, retrieve, update, or delete), and the body name, e.g., getOrderStatus. The metaobjects are supplied to the Web Services Generation Utility in our example and can be seen in Figure 5, under Operation Details.

• Run the Web Services Generation Utility: In order to expose this collaboration as a Web service, the Web Services Generation Utility is invoked with a set of parameters to create the requisite WSDL file and SOAP interfaces. In Figure 5, once we've connected to the CrossWorlds server, (prometheus888), we specify the MIME type, collaboration name, collaboration port, and proxy class name.

The default MIME type is XML/SOAP. The MIME type tells the proxy class which Data Handler to use for converting the SOAP message into a business object.

The collaboration name is the executable collaboration object that the proxy class will call. The collaboration port, configured earlier to receive input from an external process, tells the proxy class where to send messages.

After the generation process is completed, the Web Services Generation Utility displays the six files shown in Figure 6. The WSDL service file shown in Listing 1 describes the Web services. The WSDL file documents five namespaces as attributes and uses seven elements to define network services.

prometheus888.xsd is the XML Schema file for the business objects used by the Web service. This file contains the type definitions for each business object referenced in the metaobjects specified earlier. The OrderStatus.cfg file contains the name-value pairs used by the proxy class and the prometheus888_Readme.txt file contains deployment information for the proxy and its methods on SOAP-enabled Web servers.

The last two files generated are the OrderStatus.java and OrderStatus.class files. The Java source code is provided for the proxy class to facilitate customization, if needed. The generated OrderStatus.class is ready to deploy.

• Deploy the Proxy Class: Individual deployment requirements vary depending on which SOAP-enabled Web server is used. Any Web server that listens for SOAP requests (SOAP 2.2) should be able to make the appropriate calls to the Java proxy class.