ws-ore

ws-ore is a BPEL orchestration engine implemented in .Net, this application was developed as an MSc dissertation project for the University of Liverpool.

Overview

The design of ws-ore is divided into the two main activities that must be performed by an orchestration service, namely processing of BPEL scripts, and execution those scripts. These two activities were designed to be independent from each other as much as possible in order to achieve a high degree of modularity.

Processing BPEL files

Figure 1 ws-ore BPEL and WSDL processing

The result of the BPEL script processing is a data structure composed by a hierarchy of objects which represents the script inside orchestration. The transformation benefits from the fact that BPEL is a XML dialect, Tim Bray et al. (2000), and from .Net XML serialization functionality. Since both the input and output use XML, in some point in time, the transformation is greatly simplified by the usage of the XML stack of technologies. In this case XML Schemas, Henry S. Thompson et al. (2001), to validate BPEL and XSLT, James Clark (1999), to transform from (XML) BPEL into (XML) objects.

Once the transformation has been performed, the next step was to address the problem of deploying the BPEL script. This was not a trivial undertaking. To begin with, a BPEL file does not contain information about services that the script might reference (or information regarding message receiving) thus making the BPEL files insufficient for deploying purposes. To be of any usage, a BPEL script needs to have the capacity to send and receive messages from external referenced services. This is achieved with the use of WSDL files, Erik Christensen et al. (2001) that carry information specifying the details of external services. The processing of WSDL files follows the same approach used for BPEL files: XML Schema to validate, XSLT to transform and .Net serialization to create an object model from the resulting XML file. In the case of WSDL files we need to add additional information regarding binding and service location. This was achieved by loading the original WSDL file into an XML DOM and then changing and or adding the required data, before the transformation and deserialization occurs.

Once the BPEL and WSDL are processed, the last step to deploy a BPEL script is the fulfillment of requests for the BPEL script. This last step was achieved using the dynamic code generation libraries in .Net, namely the CodeDom namespace to dynamically generate and compile a Web Service.

Executing BPEL files

Figure2 ws-ore orchestration engine

After a script is deployed, execution can take place. The Orchestration engine built-in service listens for any incoming messages. This module is responsible for determining which script should be used to process the incoming message. In order to fulfill its duties the service accesses the script registry to determine which script should process the message. If an instance of that script is already loaded, that instance may be the target for the incoming message. In case there are multiple instances of the script already being executed, the correlations specified in the BPEL script are used to identify a specific instance. If no instances of this script are loaded, the option is to load a script from file and create a new instance to process the incoming message.

Once the script instance is selected, processing is carried out by the Process Controller responsible for the script activity execution. A script instance is a container for the BPEL Model objects, for a context used to store the script runtime information, such as variables, and for the WSDL Model objects.