Source Code for this article

The goal of the Web services architecture is to enable seamless application integration over the network without regard to programming language or operating environment - one of the key components of the goal to enable inter-and intra-enterprise business processes and workflows to take advantage of the benefits that Web services offer. The Web Services Flow Language (WSFL) is a proposed grammar from IBM that extends the Web services architecture by providing the ability to describe a directed-graph model for defining and processing business processes in terms of the Web services that implement that process, and it defines a public interface that allows business processes to themselves be defined as Web services. This article offers only an initial taste of what WSFL is and what it has to offer; therefore, it may gloss over a few of the more in-depth concepts.

Business Process Basics
If you're unfamiliar with business process modeling and workflows in general, Figure 1 is an example of a simple workflow process modeled using a directed-edge graph. Each box is an activity (some work that needs to be done); each solid arrowed line (edge) represents the flow of processing control from one activity to another, with the arrow indicating the direction of the flow (thus the term "directed edge"). Decisions are made at various control points to determine whether or not to continue to processing, whether or not the current activity is finished and the graph may continue, whether or not an error has occurred, and so on. Dotted-lines connecting activities indicate the flow of information between activities.

Figure  1:

Based on this diagram, we can easily imagine the course of the workflow as processing moves from one activity to the next, and as decisions are made at each control point. WSFL is essentially a tool to model the exact same graph using an XML syntax that can be read by both humans and machines. By consuming WSFL, a workflow engine can walk through the business processes activity by activity, control point by control point. It's not a new concept by any means; however, given the revolutionary power of Web services to bridge cross-platform boundaries, WSFL is enhanced by its ability to model business processes that can easily span not only across business boundaries, but technology boundaries - overcoming a limitation that many workflow engines suffer from.

The workflow diagram illustrated in the figure is given in Listing 1 using WSFL syntax. Study the syntax and structure of the document well. For reference information about the syntax and the individual elements, see the Web Services Flow Language specification.

Learning the Lingo
WSFL, like workflow in general, has a language all its own; and, like anything, the key to mastering it is to master the vocabulary. Listed below are just some of the more important concepts within WSFL.

• Business process: The business process is any collection of activities that together accomplish some business objective. For example, processing a credit card number, hiring a new employee, and submitting a patent are all examples of business processes.
• Flow model: The flow model is the actual XML representation of the directed graph that models the business process. It is the structure used to compose Web services defined by Web Services Description Language (WSDL) documents into workflows. Flow models may be known by several different names: flow composition, orchestration, and choreography are just three of the most common synonyms.
• Global model: Simply modeling the processing flow between activities within a workflow (which in WSFL terms means modeling the processing flow between Web services) is not enough. In addition to the flow model, there needs to be a way of specifying exactly how the Web services involved in the process are expected to interact with each other. That is where the global model comes in. The global model defines the necessary links between Web services that specify how messages will be sent from one service to another as the processing flow defined by the flow model is executed.
• Recursive composition: One of the cool things about WSFL is that once you've defined both the global and flow models for a given business process, it's then possible to define the entire process as a single Web service that may be used within other business processes. In other words, you can recursively compose WSFL business processes using other existing WSFL business processes. This enables a great deal of flexibility and the possibility of fine granularity in the models you define. It also opens up the door to some very cool business possibilities.
• Service provider: A service provider is the party responsible for performing a particular activity within a business process. In WSFL, every activity is a Web service; therefore, every service provider is a Web service provider as defined by the Web Services Architecture Document.
• Service provider type: In order to maintain a clear separation between the definition of the business process and its implementation, WSFL's flow and global models define each activity as being implemented by specific types of service providers rather than by the specific service providers themselves. The service provider type is defined by a Web Service Interface document using WSDL. Service providers must properly implement the appropriate Web Service Interface in order to be classified as the appropriate type of service provider to handle a particular activity in the business process.
• Control link: A control link is the WSFL equivalent to the directed edge (line) that we discussed earlier; that is, it's the mechanism through which the workflow processor walks through each of the activities in the business process.
• Data link: The data link, on the other hand, is the mechanism that the workflow processor uses to control the flow of data through the business process. While in most cases the data flow will closely follow the control flow, it's quite possible that the way that information flows through the process is different from the sequence of activities invoked.
• Transition conditions: As a business process is being run, the workflow processor must be able to recognize when a particular activity is finished and when the next activity can be determined and invoked. A transition condition is a true-or-false statement that the processor may use to determine the current state of any particular activity.
• Life cycle interface: As mentioned above, WSFL business processes are themselves capable of being defined as Web services. The lifecycle interface is the WSDL-defined Web Service Interface that describes the basic set of operations that all WSFL Web services support. These operations include the ability to invoke, suspend, resume, stop, and terminate the business process as well as to inquire as to its current state.

Getting into the Flow
Walking through the business process example given above, we can easily see the general processing flow through the graph as each of the activities is performed. The keys to the process are the activity and controlLink definitions; these control the actual flow of the process from one activity to the next. For example, Listing 2 describes the flow of control from the submitPO activity to the processPO activity.

The important concept here is simple: each activity is an individual Web service, described by a WSDL document. The controlLink links these Web services together in a sequential order. The dataLink definition, shown below, defines how data is supposed to flow from one activity to the next.

<dataLink source="submitPO" target="processPO">
<map sourcemessage="purchaseOrder" targetmessage="purchaseOrder"/>
</dataLink>

The messages that the sourceMessage and targetMessage attributes are referring to reference the WSDL-defined messages for both the source and target Web services. The dataLink element maps the two messages together, essentially stating that the sourceMessage is the same as the targetMessage.

What isn't shown in this WSFL example are the controlling transition conditions that actually determine whether or not each individual activity is currently complete and whether or not the workflow is ready to transition into its next activity.

You should also pay attention to the fact that the sample flowModel references three types of service providers: the buyer, the seller, and the shipper.

<serviceProvider name="buyer" type="buyer" / >
<serviceProvider name="seller" type="seller" / >
<serviceProvider name="shipper" type="shipper" / >

Each of these represent the significant roles that must be filled to complete the business process. Any Web service pro-vider who properly implements the buyer, seller, and shipper Service Provider Type definitions may fill these roles. Once an appropriate service provider has been identified, a reference to that provider may either be directly referenced with the WSFL document using locator elements, or the workflow engine may decide how exactly the links are resolved. This mechanism has been designed to give WSFL a great deal of flexibility, allowing business processes to be defined regardless of who is actually going to be responsible for implementing each of the individual activities.

Looking Ahead
WSFL is just a beginning, a first step into the potentially revolutionary changes that the Web services architecture can make in the way we tie together applications and businesses. My recommendation is that you learn more about WSFL, and the Web services architecture in general. I've provided some basic resources below to help you get started.

Resources

• If you're new to the area of Web services, I recommend that you read the Web Services Conceptual Architecture document to get a basic understanding of the fundamental concepts.
• WSFL builds heavily on the Web Services Description Language (WSDL), an XML-grammar for describing individual Web services.
• The WSFL specification represents IBM's input into a growing collection of XML-based workflow definition grammars that include the ebXML Business Process Specification, the Business Process Modeling Language, and Microsoft's proprietary XLANG that's at the heart of their BizTalk Server.
• The Web Services Flow Language specification.

Author Bio
James Snell is an architect in IBM's Emerging Technologies group. His primary focus is on the strategic evolution of IBM's Web Services Initiative, specifically as it relates to enterprise development. Prior to joining IBM, James worked for an independent software consulting firm providing custom enterprise development and consulting services for a variety of Fortune 500 and 100 customers. jasnell@us.ibm.com

Getting into the Flow: the Web Services Flow Language, by James Snell
WSJ Vol 02 Issue 03 - pg.42

	


Listing 1

<flowModel name="totalSupplyFlow" serviceProviderType="totalSupply">

 <serviceProvider name="buyer" type="buyer" />
 <serviceProvider name="seller" type="seller" />
 <serviceProvider name="shipper" type="shipper" />

 <activity name="submitPO">
 <performedBy serviceProvider="buyer"/>
 <implement>
 <export>
 <target portType="totalSupplyPT"

 operation="submitPO"/>
 </export>
 </implement>
 </activity>

 <activity name="processPO">
 <performedBy serviceProvider="seller"/>
 <implement>
 <export>
 <target portType="receivePO"

 operation="receivePO"/>
 </export>
 </implement>
 </activity>

 <activity name="processPayment">
 <performedBy serviceProvider="seller"/>
 <implement>
 <export>
 <target portType="totalSupplyPT"

 operation="processPayment"/>
 </export>
 </implement>
 </activity>

 <activity name="submitShippingOrder">
 <performedBy serviceProvider="seller" />
 <implement>
 <export>
 <target portType="totalSupplyPT"

 operation="submitShippingOrder"/>
 </export>
 </implement>
 </activity>

 <activity name="receiveShippingOrder">
 <performedBy serviceProvider="shipper" />
 <implement>
 <export>
 <target portType="totalSupplyPT"

 operation="receiveShippingOrder"/>
 </export>
 </implement>
 </activity>

 <activity name="shipProduct">
 <performedBy serviceProvider="shipper" />
 <implement>
 <export>
 <target portType="totalSupplyPT"

 operation="shipProduct" />
 </export>
 </implement>
 </activity>

 <controlLink source="submitPO" target="processPO"/>
 <controlLink source="processPO" target="processPayment" 
 />
 <controlLink source="processPayment" 
 target="submitShippingOrder" />
 <controlLink source="submitShippingOrder" 
 target="receiveShippingOrder" />
 <controlLink source="receiveShippingOrder" 
 target="shipProduct" />

 <dataLink source="submitPO" target="processPO">
 <map sourceMessage="purchaseOrder" 
 targetMessage="purchaseOrder"/>
</dataLink>
 <dataLink source="processPO" target="processPayment">
 <map sourceMessage="purchaseOrder" 
 targetMessage="purchaseOrder"/>
 </dataLink>
 <dataLink source="processPayment" 
 target="submitShippingOrder">
 <map sourceMessage="purchaseOrder" 
 targetMessage="shippingOrder" />
 </dataLink>
 <dataLink source="submitShippingOrder" 
 target="receiveShippingOrder">
 <map sourceMessage="shippingOrder" 
 targetMessage="shippingOrder" />
 </dataLink>
 <dataLink source="receiveShippingOrder" 
 target="shipProduct">
 <map sourceMessage="shippingOrder" 
 targetMessage="shippingOrder" />
 <dataLink>
</flowModel>


Listing 2

<activity name="submitPO">
 <performedBy serviceProvider="buyer"/>
 <implement>
 <export>
 <target portType="totalSupplyPT"
operation="submitPO"/>
 </export>
 </implement>
 </activity>

 <activity name="processPO">
 <performedBy serviceProvider="seller"/>
 <implement>
 <export>
 <target portType="receivePO"
operation="receivePO"/>
 </export>
 </implement>
 </activity>

 <controlLink source="submitPO" target="processPO"/>