The goal of Web services is to enable seamless application integration over the network regardless of programming language or operating environment. The goal of Web services workflow is to enable the same type of seamless integration across business processes and transaction lifecycles that make use of many Web services.

The Web Services Flow Language (WSFL) is a new proposed standard from IBM that addresses workflow on two levels:

• it takes a directed-graph model approach to defining and executing business processes;
• it defines a public interface that allows business processes to advertise themselves as Web services.

In this, the first of four articles dedicated to helping you learn how to make the most of WSFL, I will begin by introducing the fundamental concepts that form the basis of this specification. The three remaining articles in the series will focus on actually using WSFL. This introduction is designed to only give you an initial taste of what WSFL is and what it has to offer; therefore, it will gloss over the detailed concepts. As this series continues, I will drill down further and explore some of the more important components of the specification.

Workflow is a four-letter word

Historically, workflow definition mechanisms have come and gone, riding on waves of complexity that would make the XML specification look like a children's fairy tale. The trick has always been to create a method of defining a process quickly and precisely without adding so much complexity to the control logic that it becomes too expensive to implement.

The WSFL separates itself from this quagmire by not attempting to be all things to all people, focusing on producing the core model of the workflow. It models the basic process and only simple directed edges that control the flow of processing logic from one activity to the next.

If you're unfamiliar with business process modeling and workflows, Figure 1 provides a basic example of a simple workflow process; it is an example of a directed-edge graph. Each box is an activity (some work that needs to be done), each solid arrowed line (an 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.

In Figure 1, we can imagine the course of the workflow as processing moves from one activity to the next, and as decisions are made at each control point.

The WSFL is a tool to essentially 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 is not a new concept by any means. However, given the revolutionary power of Web services to bridge cross-platform boundaries, the power of WSFL lies in its ability to model business processes that span technology boundaries as well as across business boundaries -- a limitation that most workflow engines suffer from.

The workflow diagram in Figure 1 has the WSFL syntax shown in Listing 1. Study the syntax and structure of the document well. For reference information about the syntax and the individual elements, see the WSFL specification (see Resources).

<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>

Back to top

Learning the lingo

WSFL, like workflow in general, has a vocabulary of its own; the key to mastering WSFL is to master this vocabulary. What I offer below is just a cursory glance at some of the more important WSFL concepts. There are actually quite a few more that we will pick up as the discussion continues over the course of this series of articles.

Business Process: The business process is any collection of activities that when combined accomplish a given 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 that is used to compose Web services, as defined by their individual Web Services Description Language (WSDL) documents (see Resources), into workflows. Flow models are sometimes known as flow composition, orchestration, and choreography to name three 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 is a set of the necessary links that specify how messages can be sent between the Web services in the flow model as the flow is executed.

Recursive Composition: One of the cool things about WSFL is that once you have defined both the global and flow models for a given business process, it is then possible to define the whole business process as a single Web service that may be used by other business processes. In other words, you can recursively compose WSFL business processes within existing WSFL business processes. This enables a great deal of flexibility and the possibility of fine granularity in the models that you define. It also opens up the door to some very exciting business possibilities that I'll explain in the fourth installment of this series.

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 (see Resources).

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 that we discussed earlier; that is, it is the mechanism through which the workflow processor walks through each of the activities in the business process.

Data Link: The data link 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 is quite possible that the way that information flows through the process is different than the sequence of activities that are 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.

Lifecycle 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 within a particular Web services application. These operations include the ability to invoke, suspend, resume, stop, and terminate the business process as well to inquire as to its current state.

Back to top

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 are performed. The key to the process are the activity and controlLink definitions; these control the actual flow. For example, Listing 2 describes the flow of control from the submitPO activity to the processPO activity.

    <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"/>

The concept that is important to grasp here is simple: each activity is an individual Web service described by a WSDL document. The various controlLink edges connect 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 sourceMessage and targetMessage attributes refer to 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 is not 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. I will cover these transitions in the next installment.

You should also pay attention to the fact that the sample flowModel refers to 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 provider 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 design 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.

Back to top

Looking ahead

In this installment, I have provided a first look at WSFL, what it does, and a little about how it does it. You have been introduced to the essential concepts that drive Web services workflow. In the next installment we'll walk through the necessary steps for actually modeling a business process, creating both the global and flow models and defining the types of service providers that will implement the steps of the process. In the third installment we'll look at how a service provider may implement a defined service provider type and assume the appropriate role within the business model. In the fourth and final installment, we'll explore the concept of recursive composition and demonstrate how business processes may be combined to solve ever more complex business issues.

Resources

• Be sure to check out the three previous installments of this column: Part 1, Part 2, and Part 3.
  
  
• If you are new to the area of Web services, it is highly recommended 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 is at the heart of their BizTalk Server.
  
  
• And, of course, there is the Web Services Flow Language specification itself.
  
  

About the author

James Snell is both an author and a developer and is one of the newest members of the IBM Web Services development team. He comes to IBM with an extensive background in custom enterprise application development and business-to-business integration, and a passion for the cutting edge of Web technology. You can reach him at jasnell@us.ibm.com.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Workflow is a four-letter word
• Learning the lingo
• Getting into the flow
• Looking ahead
• Resources
• About the author
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers