Web Services Orchestration

Web Services rely to a great extent on XML and related technologies for describing their interfaces and the messages exchanged between client and Web Service. Their suitability for automated machine processing has also encouraged the development of specialized languages for describing Web service workflows as XML based languages.

The first notable languages to appear, XLANG [158] and WSFL [25], enabled only static composition of Web services [117]. XLANG relies on structured activities, whereas the second one permits the creation of workflows by linking activities.

As demonstrated in [117], the XLANG language is more restrictive than WSFL in the sense that some workflow patterns are not supported. One such example is arbitrary cycles, similar to the ’goto’ mechanism used in unstructured programming [192]. The

WSFL was superseded by the BPEL4WS V1.1 standard language which later was en-hanced and adopted as a OASIS standard under the naming WS-BPEL 2.0 [37]. Due to its massive support from industry, the WS-BPEL 2.0 called in short BPEL, now rep-resents the industry standard for describing Web Services orchestration. Its pure XML nature that on occasions makes describing workflows difficult motivated IBM to create a hybrid language, BPELJ [134] that allows Java components to be easier integrated with standard BPEL workflows.

Due to the acceptance of BPEL as de facto standard for describing Web Services orches-tration, researchers have also investigated the suitability of BPEL and related technolo-gies for describing scientific workflows. In order to analyse the suitability and expres-siveness of a language multiple perspectives should be used [192, 191]. The language’s power comes from the support it offers for existing control flow patterns, data flow pat-terns and interaction patpat-terns describing the relation between the process and the services it has to interact with. In [198] the author demonstrates the way BPEL is able to support most of the control flow patterns while [44] investigates multiple interaction patterns and the way they can be expressed in BPEL.

Learning from the experience and shortcomings of its predecessors, BPEL tries to pro-vide support for most of the features that industry and research communities found im-portant while trying to keep the language itself simple. BPEL is used to describe com-posed Web Services as business processes. While the business process itself is seen by an external client just like any other Web Service, the workflow engine that executes the process has the task to interact with partner Web Services that are the actual providers of services. The interaction plan results from the analysis done by the specialist that identifies the Web Services that are needed to solve a particular problem and the control flow and interaction patterns need to achieve its goal. External Web services called by the process are partners playing specific roles in relation with the process.

The full workflow lifecycle identified in [76] is supported by BPEL. Abstract workflows defined in BPEL capture the partners and the control flow of the process while actual

details about the location of Web services to be used can be provided at runtime. Inter-action with external Web Services is defined using the port types of the partner services.

Data types of the parameters used by partner port types can be automatically discovered from the WSDL documents and BPEL provides XML specific mechanisms to manip-ulate data based on their specific format. This functionality is required because it is often the case that the output received from one partner must be transformed to the input expected by another partner interface.

Modelling a workflow can be achieved using several language constructs. They are referred as BPEL activities, which are encoded as XML tags in the BPEL document describing the workflow. The most important ones are:

• Communication activities: receive, invoke, reply, pick, on message, on alarm

• Control activities: if, elseif, else, switch, otherwise, while, repeatUntil, flow, wait, exit, sequence, foreach

• Fault handling activities : throw, catch, catchall, terminate, compensate, compen-sateScope, rethrow

• Data manipulation and scope: assign, copy, scope, validate

• Auxiliary activities: empty, extensionActivity

Some of the activities mentioned represent themselves containers that can hold other activities. For instance, the sequence activity instructs the workflow engine to execute one after another the activities that it contains, regardless if they are calls to other services expressed using an invoke activity or an arbitrary combination of other activities.

An important requirement raised by scientific workflows is the ability to describe flows by combining already defined ones. BPEL supports this requirement since a work-flow document can be easily integrated into another document. Scopes of existing activ-ities and for the workflow itself can be created to prevent naming clashing for constructs

and variables that are defined to hold data. BPEL also offers support for exception handling and and compensation activities to deal with execution errors that may occur.

Results obtained from partner services may be temporarily stored and manipulated using XML based data manipulation mechanisms.

The most important control flow patterns have corresponding support in BPEL through intuitive BPEL activities. The sequence activity may be used to describe a sequence pat-tern, conditional patterns may be expressed if and switch activities, repetitive patterns may be expressed using while, repeatUntil and foreach activities. The order of execu-tion can be specified on one hand using the structured activities describe above combined with links that may be specified between activities. A link specifies a dependency rela-tionship between a source activity and a target activity. The target activity can only be started if all source activities on which it depends have been successfully completed.

Graphical interfaces, e.g. ActiveBPEL Designer [28], can be used to create abstract or concrete workflows using a visual interface and to assist the user in deploying the re-sulted workflow. The user has to define the partners that the workflow process must call and to combine these partners using control flow constructs. Once the workflow is spec-ified the user may even test the workflow by using fake partners automatically provided by the ActiveBPEL Designer environment. Such mock partners may be instructed to return a particular value when they are invoked. After the workflow is deployed as a process in the ActiveBPEL workflow engine it can invoked as regular Web Service by an external client. Depending on how the workflow is constructed, each call may create a separate instance of the workflow or it may reuse an existing one.

Any modification in the structure of the workflow requires that a new workflow is de-ployed and therefore dynamic modifications of its structure are not possible at run time.

Workarounds for this issue may still be possible. One solution would be to break the original workflow into multiple smaller workflows and have them executed one after another. Thus, depending on the dynamic status of the workflow it may call one of the existing workflows that can be individually be modified. Another similar option is to

implement workflows that cover most of the possible scenarios and based on the inter-nal state of the workflow and routing plan of the workflow to execute corresponding sub-section of the initial workflow. None of thesestrive solutions is ideal but at least alternatives are available if really needed.

Apart from the solution provided by BPEL language an important effort was conducted in the scope of several research projects with the aim to provide versatile solution for description and execution of workflows. While BPEL’s main intent was from the begin-ning to provide support for Web Services composition, research initiatives have tried to accommodate multiple distributed technologies. This approach is motivated by histor-ical evolution of distributed computing platforms for scientific computations that were developed over time using a wide range of technologies. Existing tools for scientific computations could not be rebuild from scratch and therefore solutions that could still use them had to be found. Since these systems do not target especially Web Services we include them in the category of Grid workflow systems in a broader sense of the Grid term and not restricted WSRF compliant services.