Please visit our home page too ! there is a lot of information on other standards and technologies
The Web Services Flow Language (WSFL) is an XML language for the description of Web Services compositions as part of a business process definition. It was designed by IBM to be part of the Web Service technology framework and relies and complements existing specifications like SOAP, WSDL, XMLP and UDDI. WSFL considers two types of Web Services compositions:
The unit of work in WSFL is an activity - activities represent nodes in a linked graph. The dataLink and controlLink represent the data flow and the control flow between these activities. A dataLink specifies that its source activity passes data to the flow engine as part of the process instance context, which in turn has to pass (some of) this data to the target activity of the dataLink. Data always flows along controlLinks. However, the controlLink path does not have to be direct and can comprise multiple activities. The dataLink enables the specification of a mapping between a source and a target document if necessary.
If we go back to the -calculus section, activity is associated with the concept of action. Once the corresponding activity is complete, the process instance reaches a given state. At this point another action may be triggered automatically based on the transition definition, and a new activity may start. A transition may be guarded by a condition, expressed as a function of the data flow. Events are associated with completion messages of an activity's operation, or can be an individual message (notification).
There is at most one controlLink between any two activities and the model must be acyclic, therefore forbidding loops within the control flow. However, the model supports recurring activities using an exit condition mechanism which will loop until the exit condition becomes true. The control flow model supports forks (activities with more than one outgoing transition) and joins (activities with more than one incoming transition). Activities which have no incoming transitions are called start activities, similarly, activities with no outgoing transitions are called end activities. When a flow model is instantiated, all of its start activities are determined and scheduled to be performed.
One goal of WSFL is to enable Web Services as implementations for activities of business processes. Each activity is associated with a service provider responsible for the execution of the process step. This relationship defines the association between activities which participate in the control flow and operations offered by the service provider. Activities correspond to nodes in a graph. Thus, an activity can have an input message, an output message, and multiple fault messages. This is how the message flow is specified. Each message can have multiple parts, and each part is further defined in some type system. This is the binding between the message flow and the data flow.
The Global Model provides a facility to model interactions between business partners. Notice that, as in the case of XLANG, a global model is merely a mapping between inputs and outputs. Unlike in ebXML BPSS business semantics such as non-repudiation, quality of service, legally binding, guaranteed delivery at the application level … cannot be specified by a global model. WSFL collaborations are a bit more useful than XLANG contracts since it enables mapping with bi-directional services, but they are still far from ebXML BPSS.