Introduction

The workflow engine is called Methexis and it´s based on a strongly lightened version of the Open Business Engine (OBE) to largely reuse its architectural concepts and implementations of the WfMC WfMS reference architecture. All relations to application servers have been removed and many heavyweight libraries with minor functionalities have been replaced or removed from the engine. It has been extended with the cababilities of using remote workflow processes as sub processes and the opportunity to use context information to (1) influence the control flow, (2) choose suitable products to use, (3) personalize interaction and (4) trigger activities (see my poster for context usage).

Implementation

The API description can be found here: InteractionManager

 

Overview

For an overview of the overall workflow glosarry please have a look at our WorkflowGlossary

The first version of the engine has been checked in together with the InteractionManager.

What is working:

• If several "smart products" are running distributedly and one product calls a subworkflow that isnt locally available, the workflow is called on the (first) remote engine that is found
• When the remote workflow is finished, the state is transported back
• With the SmartProducts platform a local administrator GUI is started to observe processes
• External RMC calls via MundoCore can be described and executed
• THEORETICALLY also triggers can be described
  • Used to set content of context to workflow variables or to signal, that something has been finished
  • This requires the context server to work, not fully included in platform yet
• Direct UI triggering or indirect UI triggering (if automation fails) is possible but results in a System.out.println since no other components are there so far
• Parameter passing is now implemented for serializable objects
• API for remote administration client is finished, same as for local clients
• AdministrationGUI can be used for remote clients now

Next todos:

• Including context triggers with SPARQL-Querie

 

Acronyms

• WfMC Workflow Mangement Coalition
• WfMS Workflow Management System
• XPDL XML Process Definition Language
• XML Extensible Markup Language
• OBE Open busines engine
• WAPI Workflow application Programming Interface
• SPI Service Programming Interface

 

Basic WfMS architecture

The WfMC has proposed a WfMS reference model. For detailed information about the interfaces, consult http://www.wfmc.org/reference-model.html

 

The Model

Just for later use, this section defines some important concepts and differences between the wirkflow definition in XPDL and the later instantiation. Whenever something from the model is referenced to, we talk about a definitions. The XPDL standard allows packing several processes into one XPDL package. Thus, we have package definitions and process definitions. Within both, there might be variables defined. Variables defined in the package are comparable to "public static" variables in Java, they are accessible from all processes in the package. Variables defined in the scope of one process are only visible and accessible for this process. These variables are represented by attribute definitions. A workflow consists of one or more activities, whereas an activity itself can be a sub workflow or an executable activity. They are represented by activity definitions. Following the specifications, for all XPDL components there is a definition within the model. Each definition object has an unique ID.

If we reference to concrete instantiations of a workflow, we speak about instances. We have package instances, process instances, attribute instances, or activity instances. Each instance has a unique ID assigned to be able to identify the instance and a definition ID, linking to its definition. Instances are the working instantiations of their definitions, containing e.g. concrete values (for attribute instances).

 

Architecture of Methexis

The WfMS is realized in a layered architecture. The topmost layer towards a user are administration tools or applications which access workflow information in a standardized client manner. They access the engine over the WAPI interface, which provide functions like getting lists of process definitions or current activity instances. The WAPI defines the interface for usual clients that just represent and/or manipulate the state of the workflows within the engine.
The next layer provides the basic functionality of the WfMS. Here the XPDL model is located. This is the standardized representation of one or more workflows. The workflow engine plans, checks and manages the execution and states of workflows. If an activity is finished, it is e.g. responsible for checking outgoing conditions of transitions and deciding if the transitions should be activated or not. If an activity has to be executed, the engine hands it to the workflow runner, which is finally responsible for e.g. executing implementations (tool agents).
One layer below, the SPI is located. This interface provides the possibility to enrich the engine with all kinds of services. Some of the current services provide direct functionality used by the engine itself, like the EvaluatorFactory, which is used to evaluate expressions, e.g. Javascript expressions for transitions. Other services can be provided by third parties to enhance the capabilities of the engine. In our project, this might for example be used by WP4 to write a service, which notifies listeners about "pieces of information that might be required in the near future". Thus, these information migtht be pre cached on the local product.

 

• Methexis WfMS Architecture:
  

 

---

Working examples

 

Remote workflows

The first and important thing is: remote workflows just look like normal sub workflows. An activity is declared as subflow activity. A usual engine would now search in its packages, if a workflow can be found that has the given ID. Methexis further searches via service discovery of MundoCore if remote engines are available, which might provide this workflow.
If a remote workflow is selected to be executed, the engine triggers the workflow remotely and if the remote workflow is finished, this returns the control to the current engine and the same activity. The activity is finished then and its transitions will be processed.

 

• How remote workflows basically work:
  

Like for normal processes, it is also possible to pass (serializable) content. The concepts of formal and actual parameters is thereby used like shown in the next figure. For further information on IN, OUT and INOUT parameters consult the XPDL standard.

 

• Formal and Actual Parameter processing:
  

 

Finally, for sake of documentation, the interfaces used to search/call remote workflows.

• Remote interface architecture:
  

 

XPDL Example

• coffeeMachinePackage.xpdl: A workflow, that might run on a coffee machine and does a RMC call on the coffee machine simulator
• coffeeRecipe.xpdl: A simple workflow, that gives output over UIAdapter and calls a remote workflow (contained in coffeeMachinePackage)

 

 

• Remote_Main_Detailed_Activity.png:
  

 

• Remote_Main_OVariables.png:
  

 

• Remote_Main_Overview.png:
  

 

• Remote_Sub_FP.png:
  

 

Application example

An example for a simple remote workflow can be found in the SVN in the CoffeeMachineDemo: Demo.
/ Go to the folder config/config/processes/ and open the coffee recipe.

 

Registering for context

• contextTest.xpdl: A simple workflow, that registers itself with the context manager and waits for any event from the coffee machine (simulator)

 

 

Remote Method Calls

Within the coffeeMachinePackage.xpdl example, a RMC on the CoffeeMachineSimulator is called. Therefore we use a ToolAgent and pass the required information (interface of the remote object, method name, parameter values)

• RMC_TA_Assignment.png:
  

This shows the definition of a ToolAgent

• RMC_TA_Definition.png:
  

 

• RMC_TA_Details.png:
  

 

Misc workflows

This is more an engine test workflow, the different colors and thicknesses of edges represent different types of transitions

• package.xpdl: Test workflow with all kings of transitions (normal, conditioned, exception, else)

 

Annotations

Annotation Type	Scope	Key	Annotation Created By	Used For
ContextConfig	Activity	contextConfig	MethexisTools	Registering with ContextManager to receive events of a certain type. Resulting context items can be saved as workflow variables or trigger the workflow to continue the current activity.
UIConfig	Activity	uiConfig	MethexisTools	Describes what to do with "responses of the user", e.g. when a button is clicked. Like ContextConfig: userfeedback can be saved as a workflow variable or trigger the annotated activity.
Selection MetaData	Activity (remote subworkflows)	SELECTION_META_DATA	Ontology	This is a comma separated list that specifies concepts for selecting best suitable workflow. Currently a simple string comparision is done...
MetaData	Process	META_DATA	Ontology	Describes the scope of the workflow, thus, what the workflow can be used for
ContextLink	Variables	contextLink	MethexisTools	WorkflowVariables might be linked with context values. This config describes of what kind this relation is.

Tools

Workflow Editor

As an editor, you might use the workflow editor JaWE. Unfortunatelly Enhyrda changed their website and erased all files on SourceForge. Thus, I provide the latest version I downloaded hiere:

• twe-3.0-1.x86.exe: Together Workflow Editor for Windows

 

ContextConfig and RMC-Call Generator

Configurations are passed as XML strings. I just use the MundoCore TypedMaps to serialize objects in a easy way.

• methexisTools.jar: A tool to generate configs for context registrations and RMC calls

 

Standalone version of Methexis

The standalone version of the workflow engine is independent from the SmartProducts platform. This can be used as long as the platform isn't fully available. Of course some function is not completely available (as context manager...)

• 20100628MethexisStandalone.rar: 20100628MethexisStandalone.rar