 | Level: Introductory James Snell (jasnell@us.ibm.com), Software Engineer, Emerging Technologies, IBM
01 Jun 2001 Workflow is the organization of processes into a well-defined flow of operations to fulfill a business need. IBM recently announced the release of a new XML grammar for defining software workflow processes within the framework of the Web services architecture. In this, the first of four discussions dedicated to the topic of workflow in Web services, I will introduce the fundamental concepts of the Web Services Flow Language, give you a quick tour of what it is, and what it is trying to accomplish.
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.
Figure 1: An illustration of a business process
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>
|
 |
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.
|
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.
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. |
Rate this page
| |
