Flow Model
The actual process flow in WSFL is described as an acyclic-directed graph. Before you break out the mathematics textbook, this basically means that activities have directional links between them and you can't loop back to a previous activity.

Activities
Activities, which represent work to be performed, are eventually mapped to Web services. In the flow model, you can define the input message, output message, and faults of an activity. The activity's messages will eventually be mapped to the messages of the underlying Web service implementation.

Control Links
Activities are wired together through control links. Any number of control links can exit or enter an activity, but there can be only one control link between any two activities. Once an activity is completed, the WSFL engine will traverse to the activities specified by one or more control links. Parallelism is automatic since control links are processed simultaneously.

Data Link
A data link specifies the flow of data from one activity to another. Essentially, the output message returned by an activity becomes the input message for a downstream activity. If the messages match (same elements, etc.) then the mapping is done automatically. WSFL allows you to map parts of multiple messages into the input of an activity. For example, one activity calculates the price of an item and another determines the warehouse from which to ship the product. Both pieces of data could be combined and sent to a downstream activity. XPATH expressions are used to specify how to map data. If the same data arrives at an activity (two different upstream processes provide a price, for example), WSFL defines a set of mapping rules to determine which piece of duplicate data "wins" and is sent to the activity.

Conditional Links
Every control link can have a transition condition. The transition condition is an XPATH expression that evaluates to true or false. During runtime, all transition conditions are evaluated to determine whether a branch from an activity is actually traversed. An example transition condition might be "not(Credit_Check_Approved = 'Y')" If the credit check isn't approved, the link will be valid and the engine runs the downstream activity.

Join Activities and Conditions
An activity that has more than one control link entering it is called a join activity. Join activities have join conditions. If the join condition of an activity evaluates to true, the activity will be executed. If not, it won't. Join conditions are needed because each link is unaware of other links. If you want an activity to fire only if two or more previous activities returned a certain result, you would put that condition in the join condition. This would be done, for example, if an activity should only be executed if the customer's credit is OK and there is inventory in stock.

You can't use a transition condition because each link would only be aware of its previous activity's data. In this case you need information from both activities to make a decision. Figure 1 shows two activities that merge into one. Once the individual link statuses are (the credit is ok, inventory is in stock), the "create invoice" join condition will be evaluated. The join condition enforces that both links must be true for the process to proceed. (If either were false, then you would never get to the activity anyway.)

Join conditions can have a join evaluation property that is "deferred" or "immediate." The default is deferred and means that all links coming into an activity must be valid and completed before the join condition is evaluated, ensuring that all activities have finished. The result is synchronized execution. If the evaluation is immediate, the join condition is evaluated each time a link is completed; this way, an activity can fire before all the previous activities are completed. An example of this would be a supplier inventory check, where at least one supplier must confirm an item is in stock. The flow can continue once one supplier confirms the item is in stock without waiting for the other suppliers' responses.

Exit Conditions
Activities have exit conditions that are evaluated when the activity has completed. If it evaluates to false, the activity will execute again. This construct allows you to create a do-until loop within an activity (yes, you can create an endless loop). If you want to loop through complex functionality, then you can use the recursive composition feature of WSFL, which allows any complex process to also be a Web service used by another WSFL process.

FlowSource and FlowSink
When you define a process, you also define the incoming and outgoing message for that process. These are referred to as the FlowSource and the FlowSink. The FlowSource is always available to any process and any activity's output can be written to the FlowSink (see Figure 2).

Start and End Activities
Any activity without an incoming link is a start activity. Any activity with no outgoing links is an end activity. When a process is initiated, all start activities are executed and passed data from the FlowSource. When all end activities have been executed, the process is complete.

Logic Construction
It's possible to model almost anything you need in WSFL using conditional links, join conditions, and exit conditions. Traditional workflow systems use things like XOR-links, AND-links, and OR-links, which tend to be implemented in code; one of the problems with these is that if the business model changes, you might need to change the link type, which would require recoding of a link. With WSFL, you merely add a link and change any needed conditions; rapid process maintenance is a major benefit of WSFL.

The Global Model
Global models define how individual flow models are actually implemented. The flow model doesn't have mappings to particular Web services. Think of activities as placeholders where Web services will be plugged in. The global model lets you link individual activities with actual Web services.

In the global model, you can define service provider types, port types, service providers, service locators, and plug links. Going into detail on these would require another article twice the size of this one because of the abstraction they provide. Plug links are used to map specific activities in the flow model to the actual Web services that will be used. Services can be hard-coded, looked up from UDDI services, or even specified by the data that is used within the process itself.

Given the state of Web services today, I expect that most implementations of business processes will use hard-coded services references and that some of the more flexible portions of the global model will not be used for some time. However, WSFL does provide extreme flexibility in how actual services can be specified and called during execution time and it's good that WSFL anticipates the dynamic nature of Web services.

Another thing the global model allows is the definition of the public interface of the flow itself. It contains mappings to define what the resulting WSDL of the model will look like and allows outside services to call or return data to specific services within the flow as required. For example, you might have an activity in a flow that merely waits for notification from some outside process. That outside process will need a way to get to the specific activity managed by the WSFL engine.

Real World WSFL
As the first real-world commercial implementer of WSFL, my company faced a few hurdles and raised quite a few issues with IBM on where the spec itself should go. The bottom line is that we believe WSFL 1.0 is an excellent start toward a comprehensive specification for the orchestration and assembly of Web services into processes. Our overall experience was quite positive and we believe that early adoption of WSFL has given us a clear competitive advantage in the Web services orchestration marketplace.

There are a few areas in which WSFL is currently lacking, however. Because of these limitations, any real-world implementation must extend the current version of the specification. WSFL lacks some features needed for effective B2B implementations; many of these features are scheduled to be expressed in something called WSEL - Web Services Endpoint Language. WSEL describes things like timeout values, retry values, and other quality-of-service information needed to make B2B interactions work. WSEL has not been released, but the WSFL specification provides some high-level guidance as to where WSEL is heading.

WSFL doesn't handle asynchronous recursive processes very well. In BPM circles these are known as fan-in and fan-out scenarios; while they can be implemented in WSFL, they are complex and error-prone and require special services to make the processing work. I believe WSFL should have provisions for such requirements.

Finally, WSFL doesn't address some B2B and human workflow semantics, such as addressees, correlation IDs, and priority levels. These are required so that waiting processes can be delegated to various individuals and groups within an organization. WSFL's provision for a process ID is not sufficient.

Any major commercial implementation based on WSFL will have to have extensions to the base WSFL in order to be viable. Fortunately, the standards process works and all of the current weaknesses in WSFL are being addressed.

Summary
My company found WSFL to be a very usable and well thought-out specification and while we did have to extend it for commercial implementation, we were able to do so in a way that does not violate any of WSFL's basic premises and philosophies. When the WSEL specification emerges, vendors should not have problems updating their engines to handle it. If you're serious about Web services orchestration and moving away from hard-coded business processes, I highly recommend choosing a WSFL-based process management system.