magazine resources subscribe about advertising

 

 

 








 CD Home < Web Techniques < 2000 < August  

WF-XML and Interoperability

By Tom Spitzer

Many Internet commerce efforts require several organizations to make decisions and then take action on them. The automation of this process is formally referred to as workflow, and can be managed by software running across a number of different computers. The problem with this method is that there is no easy way to communicate across various processes. Fortunately, standards committees like the Workflow Management Coalition (WfMC) have focused on developing solutions to the process integration problem. The WfMC took a major step toward creating a common idiom for workflow engines when it released Wf-XML, a language designed to standardize data transfer requirements between interoperable systems.

To understand how Wf-XML works, let's say your company needs to build a server farm for a new interactive media service. You probably need to develop internal requirements and constraints and review them with various parties who are responsible for product management, finance, and application development. Think of this process as a workflow that results in specifications for the server farm, and possibly in the creation of a request-for-proposal (RFP) that you'll send to several potential vendors.

Each vendor that receives your RFP has its own internal process for delivering a proposal, which involves at least one salesperson and one system engineer. When you receive the proposal, you have your own review process, which may include inviting the top vendors to make in-person presentations. Once you decide, you probably submit some paperwork to your purchasing coordinator together with a copy of the vendor proposal. Someone writes up a purchase order and delivers it to the vendor. At this point, the vendor's internal systems take over, initiating several processes to obtain hardware and software and assemble them according to the promised configuration. These processes may in turn generate orders for computers, software, and other components from upstream vendors. If all goes well, the vendor delivers the proposed system on the requested date.

At the same time, the vendor's accounts receivable department generates an invoice and delivers it to your accounts payable department. If the vendor has given you terms, it's possible that the vendor will factor the receivable. Factoring is the practice of selling receivables to a finance company, which buys receivables for a discount of between 3 and 10 percent based on the purchasing company's credit. The factor initiates an internal credit application process, which involves collecting information from your accounts payable department, scoring that information, making a decision, and delivering payment to your vendor.

While you probably don't usually think of these steps in workflow terms, they actually require the completion of several workflow processes within three or more organizations. Web-based B2B commerce is all about facilitating the flow of these processes across organizational boundaries. Historically, this has been a difficult problem, because separate organizations use different software applications to manage internal processes. In fact, it's not unheard of for a single organization to use different applications to manage the same processes.

Architecture for Interoperability

Wf-XML provides a message-based architecture for communicating between workflow engines. It's much like a message-oriented middleware system (it's already a part of IBM's message-oriented middleware system). When one workflow engine sends another engine a message encoded in Wf-XML, it's effectively making a remote procedure call on that engine and providing the parameters that the procedure requires.

Wf-XML can represent the data required to support chained and nested workflows. When processes are chained, a process instance being enacted by one workflow engine triggers the creation and enactment of a subprocess on a second engine. Once the subprocess initiates, the first engine maintains no interest in the subprocess. When processes are nested, the process instance enacted on the first engine causes the creation and enactment of a subprocess instance on a second engine, then waits for the subprocess to terminate before proceeding.

To enable interoperability, workflow engines need to expose an API sufficient to parse a Wf-XML message and act on its contents. Although Wf-XML is defined independently of programming languages and data transport mechanisms, the WfMC expects that HTTP will become the most widely used data transport mechanism. To this end, Wf-XML can be used as an RPC mechanism between "generic services" that may consist of a number of different resources.

Message Structure

The Wf-XML specification defines an individual function that can be exposed to other processes or services as an "operation." There are three special groups of operations identified in version 1.0 of the specification: ProcessDefinition, ProcessInstance, and Observer. (I expect to see more groups such as Roles and Activities in future versions.) A resource must support operations defined for a given group, and may support more than one group. ProcessDefinition operations describe the service's basic functions, and provide a model for instances of the service. Defining a ProcessDefinition group for a generic service is the basic way to expose that service to other processes in the workflow application. ProcessInstance operations represent the instantiation of a ProcessDefinition group for an actual running process. Observer operations enable a process instance to advise other services of its completion or termination. This is especially important in nested sub-processes, where there must be a way for the requestor to determine when the subprocess completes.

Listing 1, Listing 2, and Listing 3 are example messages that elaborate several steps in the scenario I described earlier. As you may infer from the examples, each Wf-XML message contains a single WfMessageHeader section, and a single WfMessageBody section. It may also include an optional WfTransport section, which would describe the message transport mechanism and may include a means of identifying or synchronizing request and response messages, using a CorrelationData tag.

The WfMessageHeader section must contain either a Request or Response element, indicating which of these message types is being delivered, and a Key element that contains the URI of the resource that's either the target or the source of the response. A request message asks a remote resource to initiate an operation, and provides input data for that resource. A response message sends the results of an operation to the requesting resource. Unlike the model defined by HTML and HTTP, not every Wf-XML request requires a response.

The initial message from our system to the vendor's system, as shown in Listing 1, advises the vendor that we're submitting an RFP and that we expect an acknowledgement. This request specifies CreateProcessInstance.Request as the desired operation. We can send this message to several vendors and we should receive a "receipt," like that in Listing 2, from each vendor.

Resulting vendor proposals look like the one in Listing 3 and contain a ProcessInstanceStateChanged message, with additional data describing the specifics of Vendor A's proposal. Our proposal processing system scores any resulting proposals from vendors. Ideally, we'll have created a sufficiently extensive rule base to allow our proposal processing system to pick the winner and issue a purchase order automatically. Once the purchase order is created, our purchasing system can use a workflow interchange message to deliver it to the winning vendor.

In almost all cases, additional data is necessary for the requesting or responding process to proceed. The specific data requirements of individual processes depend on their nature, and can't be addressed in a general process standard such as this. They can, however, be addressed by standards under development for specific industries. The Wf-XML standard uses the ContextData and ResultData elements as containers for process-specific data. In the request example ( Listing 1), I created a ContextData section for the RFP request that specifies the supplier, RFP identifier, and date. It also uses a URI to reference an XML file that would contain the actual contents of the RFP. For the response ( Listing 3), I used a ResultData section that contains an identifier, some data, and a URI to reference an XML file that would contain the actual contents of the proposal.

Eventually, XML messages describing actual workflows will be constructed by incorporating the Wf-XML namespace as well as one that refers to the data standard for an industry-specific process. At that time, the contents of the ContextData and ResultData elements will conform to those industry-specific data standards. Until those standards emerge, organizations that want to share workflows must agree on how to represent the data items specific to each process.

Where Will This Take Us?

Products that support process management are numerous. Many of the workflow vendors that participate in the WfMC seem poised to add the necessary interfaces to their own products. IBM is developing its MQ Series message-oriented middleware product to support workflow functions. The company claims compliance with earlier workflow processing standards (for backward compatibility) and offers an XML interface.

SAP offers a Business Workflow module and indicates on its Web site that, as a funding member of WfMC, the company is committed to the interoperability of workflow engines and actively participates in the specification of WfMC guidelines, including Wf-XML.

Widespread adoption of this standard will take some time, if it happens at all. I spoke to a product manager at a leading vendor of infrastructure software for corporate online procurement systems and B2B marketplaces. He agreed that it's important to integrate process steps between systems in our scenario: collaborative RFP development, and RFP processing between company and supplier. But he said that currently developers would have to write code at the API level to do it.

The WfMC also has some work to do before general purpose workflow vendors adopt XML. In its standardization work since 1993, WfMC has identified five interfaces to a workflow engine. These include interfaces for process definition, access by a workflow client, invocation of external applications, administration and monitoring, and delegating processes to other workflow engines. The initial Wf-XML standard addresses only the last of these interfaces, disappointing those who are looking for a process-definition schema. Over time, the coalition is likely to define schema for additional interfaces. There's an Open Source workflow engine development project under way that's taking a pragmatic approach to schema definition. The project has already released versions of process definition and client access schema for comments.

Understanding the structure of schema like these provides insight into the interfaces we need to develop. One day, the Web will support processes that cross departmental and organizational boundaries.

(Get the source code for this article here.)


Tom (tspitzer@acm.org) is vice president of product management at EC Wise, which provides design and design validation services for process oriented Internet services.




Copyright © 2003 CMP Media LLC