Orchestration is the key feature of building an efficient distributed handler execution. Hoping that handlers hosted by different computers can intelligently execute messages without an orchestration is not reasonable. The distributed execution needs to be facilitated so that the sequence of the execution can be understood by the handlers.
69
Additionally, with the contribution of the orchestration, the handlers can be liberated from their limited surroundings and they can benefit from new features and resources.
Fortunately, we utilize SOAP messages in Web Services. It conveys metadata with data together. This feature minimizes the reference issue. Distributed computing requires a good referencing model for data and computing nodes. The referencing is one of the most challenging problems. The general solution of referencing a data object is the usage of pointers. However, there exist limitations in this solution. The referenced object may not be created again so that the pointer loses the object when the application needs to be restarted. Many solutions have been introduced for this problem. DISCWorld is an example and provides high level middleware to access to data and resources. It utilizes canonical names for the objects. When user makes a request, it is analyzed by a local IDSCWorld daemon. The daemon invokes a placement algorithm to assign the services to the processing nodes [87]. In Web Services, luckily, SOAP messaging is utilized. Therefore, data referencing becomes issue no more. The only entity that needs to be referenced is the handler so that the messages can be passed properly. Handler referencing is explained in section 3.2.2.
There exist many workflow systems that utilize markup languages. One of them is The Petri Net Markup Language (PNML) [88]. It makes Petri net model transferable so that users take advantage of newly developed facilities such as simulation, analysis and implementation tools. The main design principles of PNML are flexibility and compatibility. The idea is that it should not limit the features of any kinds of Petri net and be able to represent every Petri net model with its extensibility features. It also provides an effective compatibility with the well defined labels [89].
70
Additionally, several other projects benefits from the markup languages. eXchangeable Routing Language (XRL) uses XML base documents for the workflow management [90]. The language consists of basic routing structures that can be utilized to design more complex routing schemes.
Markup languages clearly provide many opportunities. DHArch handler orchestration mechanism also utilizes an XML based document to describe the sequence and the resources. XML carries semantic as well as syntax. This feature allows the document to be interpreted by other systems; additional tools and software can be utilized. In order to define the orchestration document, an XML schema is created. XML schemas describe the structure, content and semantics of XML documents [91]. They define the shared vocabularies of instances of XML documents. Now, we will explain the handler orchestration document schema:
Table 4-1: Simple elements in Orchestration Schema
<!--Element Definitions-->
<xs:element name="name" type="xs:string"/>
<xs:element name="address" type="xs:string"/>
<xs:element name="oneway" type="xs:boolean"/>
<xs:element name="mustPerform" type="xs:boolean"/>
<xs:element name="condition" type="xs:anyType"/>
<xs:element name="numberOfHandler" type="xs:short"/>
<xs:element name="numberOfLooping" type="xs:short"/>
DHArch handler orchestration schema contains several simple and complex elements to define the flow sequence, shown in Table 4-1. Simple elements contribute to build complex schema elements. Name, address, oneway and mustPerform are the elements to define a handler. Condition, numberOfLooping and numberOfHandler support to fabricate the execution constructs.
71
A time entity is necessary to monitor handler states. Therefore, a complex type is built for it, shown in Table 4-2. Several time-related variables are required to construct a handler. Start, end and execution times can be necessary to watch a handler execution. The instance of time element includes the definition and the value. A handler may use many time instances as well as it may not include any.
Table 4-2 : Complex time element
<xs:complexType name="timeType">
<xs:sequence>
<xs:element name="definition" type="xs:string"/>
<xs:element name="timeElement" type="xs:long"/>
</xs:sequence> </xs:complexType>
Handler is the most important entity of the orchestration schema. In other words, it is the keystone of an orchestration. Table 4-3 defines a handler. It is composed of several elements. The name is an identifier to increase readability of the document by the user. A handler must have a unique address so that a message can be delivered to. We keep tract of the time related data for a handler to collect statistic data and to assure the message delivery. We also have additional information to support handler execution.
Table 4-3 : Handler Definition
<!--Defines Handler-->
<xs:complexType name="handlerType">
<xs:sequence>
<xs:element ref="name"/>
<xs:element ref="address"/>
<xs:element ref="mustPerform"/>
<xs:element ref="oneway"/>
<xs:element name="time" type="timeType" minOccurs="0"
maxOccurs="unbounded"/> </xs:sequence>
72
The schema defines four basic constructs, shown in Table 4-4. The complex execution structures are composed from these basic constructs. They are sequential, parallel, looping and conditional. There may be only one of them as well as many of them in an orchestration. Each construct has a position parameter to identify its order in the execution. The constructs are sequentially ordered; they are processed in the order defined by the position element.
Table 4-4 : The execution constructs
<xs:element name="executionConstruct"> <xs:complexType> <xs:choice> <xs:element ref="sequential"/> <xs:element ref="parallel"/> <xs:element ref="looping"/> <xs:element ref="conditional"/> </xs:choice>
<xs:attribute name="position" type="xs:short" use="required"/> </xs:complexType>
</xs:element>
Many execution constructs get together to build an execution sequence. In the next section, we will explain the basic constructs.