GWorkflowDL is a standard to describe Grid application workflows that has been devised in the scope of the K-WfGrid Project. It is strongly based on the well-known Petri Net formalism for describing processes and it uses the notions of PetriNet's transitions and places to model activities and synchronisation, respectively. It is able to represent several levels of workflow abstractness as well as it is prepared for dynamic changes of workflow structure and information at runtime.
The GWorkflowDL language is based on Colored Petri Nets that model activities (or operations) enacted during execution as transitions. The model uses the notion of places to synchronise the operations among themselves. For example, to picture two operations that should be synchronised with a data transfer, one may place two transitions (one for each of the operations) and a place with an incoming arrow from the producer operation and an outgoing arrow to the consumer operation. What is more, each place and transition has its own color that depicts the level of abstractness a given workflow element is described on. The colors start with red for a complete abstract operation that is nothing known about it, through a yellow operations that are abstract in a sense of having an interface but not implementation up to blue and green ones where also the possible realisation of a given operation is known (e.g. in terms of an address of a Web Service that has to be invoked to acquire the desired result).
The WCT is responsible for getting any completely unknown (ie red) part and turning it into a yellow-colored subworkflow.
|
Here one may see a very simple example of an initial workflow that is accepted by the Workflow Composition Tool. It depicts just one dependency that specifies a type of data that the requestor wants to be produced (the bottom yellow circle). The other parts are there mainly for the reason of validation with regard of the Petri Net formalism. |
|
On the picture to the right one may find an example of a fully-composed, abstract workflow which declares that is able to produce the needed data. Such a workflow may be a result of the execution of the WCT over the initial workflow presented in the previous figure. Step by step, let's analyze the elements found in those two diagrams:
|
|
|
As one may see in the third picture, sometimes the tool is not able to give a full solution to a given problem - e.g. assume there is no operation registered in the environment that would be able to produce Inter Data 2. In such a case the tool will insert the red part in the workflow indicating there are some unmet dependencies. Later on one may upload the partially composed workflow like this as an initial workflow which may yield a better solution if the situation in the environment changed. |
All the workflows that are acceptable for the WCT (or are produced by the tool) are described in a special notation format associated with the GWorkflowDL language. It is based on the XML structure of the document and the schema for the last version of the notation standard could be found here . To have a simple example let's see how the initial ("red") workflow from the previous section would look like in the XML format.
<workflow
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xsi:noNamespaceSchemaLocation="http://www.gridworkflow.org/kwfgrid/src/xsd/gworkflowdl_0_9.xsd">
<place ID="begin">
<token>
<control xsi:type="xsd:boolean">true</control>
</token>
</place>
<place ID="Output">
<tokenClass type="data" owl="some.namespace#RequiredData"/>
</place>
<transition ID="Unknown">
<inputPlace placeID="begin"/>
<outputPlace placeID="Output"/>
<operation/>
</transition>
</workflow>
As one may see the language contains the structures and elements to describe the PetriNets in general while being extended the way that it can also contain more Project-oriented tags. The most interesting part for the end user is the mysterious owl attribute. In fact it relates a certain part of the workflow to a concept defined in the ontologies that describe the semantics of that part in terms of application domain knowledge. The most important locations of that attribute are places and operations. In the above case we may see the owl attribute set for the output place - the value of that attribute is a URI that points to a concept in a domain ontologies tree.
One may also find an empty operation tag in the above example - such an empty operation corresponds with a red transition in the GWorkflowDL notation standard. During the composition phase it may become a yellow transition that is represented with some special elements in the xml representation of the language:
<operation>
<WSClassOperation owl="some.namespace#A"/>
</operation>
As you can see there is also the owl attribute to annotate an operation class with a proper concept from the ontologies. Where to find those concepts and how to use them is described in the section on semantics in the workflow.
The official GWorkflowDL development page
A webpage inside the Grid Workflow Forum that describes GWorkflowDL.