WEEP Portal

Workflow Enactment Engine Project

About WEEP

From Wiki



The Workflow Enactment Engine Project aims to implement an easy to use and manage workflow enactment engine for WS-I/WSRF services and orchestrate the services as described by Web Services Business Process Execution Language compliant document. The workflow engine is built up of several components that collectively represent the core architecture which follows the recommendations of the Workflow Reference Model. The WEEP API is completely developed from scratch, mastering the latest Java technologies and WS-* standards/specifications.

WEEP provides the following:

  • Framework to process and validate WS-BPEL (version 2.0) documents.
  • Client toolkit for secure and reliable invocation of the engine.
  • Registry to import/export BPEL processes for reusing and caching.
  • Detailed statistics and notification about service execution and workflow processing.
  • Pluggable architecture for user defined and domain specific workflow activities.
  • Assure compatibility with the BPEL documents created in the third parties process designers like e.g. NetBeans, Eclipse etc.

WEEP can support the following:

  • Fault tolerant orchestration of distributed services
  • Perform WS-I/WSRF service invocation dynamically by evaluating its WSDL definitions.
  • Control (start, restart, stop, resume, suspend) and schedule the execution of WS-BPEL processes.


The design of the WEEP Engine adopts basic principles of the Workflow Reference Model and tries to implement the model to fit the requirements for the WS-I and WSRF-compliant services. Within the high level architecture we have identified a set of basic components with in the WEEP API.

Overview of the WEEP architecture
Overview of the WEEP architecture


The heart of the engine lies in the application programming interface (API), which creates, manages and executes workflow instances. Internally the API consists of set of essential components responsible for manipulating process instances.

Template Factory creates a new process instance and assigns a unique ID to it. From the WSRF service point of view it creates a new resource Process Template Resource (PTR) which represents a stateless process.

Engine Factory uses validated process definition from PTR and creates a new stateful process instance, which is runnable and is also represented by a resource Process Resource (PR), identified by a unique ID.

Engine Control is used to execute PR and control the execution of the process with possibilities to start, stop, resume and suspend the execution. Moreover the service can be queried for a state of the overall workflow execution or execution of a particular activity.

Dynamic Invoker - dynamic invocation od the WS-I and WSRF-compliant services.

Furthermore, the API offers five basic interfaces which are used to communicate with the engine and its internal components:


Process Definition

The definition of the business process presented in a workflow language is provided to the engine using this interface. The WEEP is primary aiming to support full WS-BPEL 2.0 specification and therefore a specialized component (BPEL-analyzer) validates and makes implicit conversion of the WS-BPEL document into a memory representation as well as conversion of the WSDL definitions of the invokable services including all the important information about service operations, parameters and their processing order. Moreover, by providing import filters, it is possible to transform any XML document into another using an XSLT processor, so it is possible to pay tribute to other workflow definition formats like e.i. XPDL. Thus, the Workflow Enactment Service should be able to execute any supported workflow format containing a sequence or flow of service invocations and can successfully be transformed to WS-BPEL behind the curtain. The user only notices the validation as a functionality of this component and if the validation is successful then a new process instance is created. Additionally, over this interface the user or any external application is also able to retrieve back the process definitions related to any workflow instance.

Administration & Monitoring

This interface gives access to the monitoring infrastructure for controlling and managing all the internal components. It gives possibility to extend default notification style to meet a more convenient type for a user. For example, the notification messages can be delivered to a URL using HTTP, via email using SMTP or via polling concept where the user has to poll the message queue of events. All information regarding the deployed processes like e.g. process description, variables' values, invocation times, workflow states etc. are stored in the database and can be accessed by the user of external application over this interface.

Client Applications

External applications can directly interact with the API over this interface or depending on the hosting environment they can use specialized and usually better defined interfaces like for example Web service interface. The implementation of the Enactment Service is highly dependent on the Java Management Extension (JMX) which provides a framework for managing distributed Web-based applications in a modular and dynamic manner. The JMX offers an ability to manage the Enactment Engine over its own interface which can be also accessed via simple graphical user interface.

Invoked Services The interface allows dynamic invocation of the WS-I/WSRF-compliant Webservices specified in the workflow definition in doc/literal encoded style. It is used to create and directly process the outgoing and incoming SOAP envelopes. Monitor the execution of the services together with error handling and recovery functionality.

Hosting Environments

The API allows to run the Enactment Engine as a standalone application directly managed by the JMX, but it is more convenient for the engine to be hosted by environments offering additional functionality (management, interfaces, security, etc.). The Globus Toolkit or Tomcat have such containers which can offer advanced maintenance of the Enactment Engine and improve its usability also with respect to the invoked services.

WEEP Engine Services for GT4

The GT4 extension defines three Managing Services allowing interaction with the engine API. There are two services able to create new resources representing static and active process (Process Template Factory and Process Engine Factory), and one service able to control the process execution (Process Engine Service). The services manage two following resources represented by their unique ID.

  • Process Template Resource (TPR) - is a resource representing static (stateless) process defined by BPEL and created by Process Template Factory.
  • Process Resource - is a resource created by Process Engine Factory representing active (stateful) process, which can be controlled by Process Engine Service.

The idea of creating three independet services responsible for managing the resources is to be able create more active instances of one static process definition as well as to allow distribution of the process definition and its enactment. GT4 Client Toolkit developed within this project contains a specialized client application able to dynamicaly invoke the managing services. The client interacts with the resources independently over SOAP messages (containing the ID of the managing resource) sent to the managing services.

Template Factory Service

The purpose of this factory service is to create a new resource Process Template Resource (PTR) representing a business process as described in a given BPEL file. This process is stateless and can not be executed using this resource. To create the PTR a BPEL file together with a WSDL file must be given to the factory as an archive (zip) file with extension .gwa (Grid Workflow Archive).

Implemented operations of the Process Template Factory are:

  • create - this operation creates a new PTR using definitions from the given GWA file
  • load - this operations tries to create a new PTR form a definitions already represented by a PTR, As input an ID of a PTR is required.
  • destroy - this operation simply destroys a PTR
  • list - this operation returns a list of all existing PTR along with their IDs and names
  • retrieve - this operation returns BPEL and WSDL definitions for the given PTR ID.

WSDL file defining the service can be found here:

WSDL file

Engine Factory Service

This service creates a new Process Resource (PR) representing a stateful process defined by the PTR. If a new Process Resource is created the initial state of the workflow is set to runnable.

Implemented operations of the Process Engine Factory are:

  • create - this operation instructs the service to create a new PR
  • list - this operation returns a list of all existing PRs created using a given PTR

WSDL file defining the service can be found here:

WSDL file

Control Engine Service The aim of this service is to control a PR created by the Process Engine Factory. A user has possibility to start, resume, suspend and stop the execution of the process and retrieve values of the variables and state of the execution. Therefore the service has three resource properties which represent:

WorkflowState - State of the overall process execution. Possible states of the workflow are:

  • runnable (initial state)
  • running
  • suspended
  • terminated
  • completed
  • failed

ActivityState - During the execution of the workflow each activity within the defined process has its own state, which can be obtained from this resource property containing an array of activities and their actual state. Possible states of an activities are following:

  • running
  • stopped
  • retrying
  • completed
  • failed

Variable - This resource property contains an array of all variables defined in the BPEL and their actual values.

Implemented operations of the Process Engine Service are:

  • start - simply starts the execution of a workflow.
  • resume - this operation causes to the engine either to resume a stopped workflow or to try to execute an erroneous workflow again. In the first case the execution is started where it was stopped. In the second case at the first erroneous activity.
  • suspend - this operation suspends a running workflow, but tries to finish the last running activity.
  • stop - this operation causes the execution of the workflow to be stopped. Stopping is only possible if a state of the workflow is running.

WSDL file defining the service can be found here:

WSDL file

Underlying Java Technologies

  • AXIOM(AXis Object Model) represents and manipulates XML in an object oriented way. Basically it is used to create and process the outgoing and incoming SOAP envelopes directly.
  • AXIS 2 provides advantages in terms of efficiency and speed. It is used to invoke Web and Grid Services in doc/literal encoded style.
  • iBATIS (Data Mapper Framework) uses the concept of so called SQLMaps to map Java objects to SQL statements. The maps decouple Java code from SQL and avoid the necessity of using JDBC
  • JMX (Java Management Extension) provides a framework for managing and monitoring distributed and Web-based applications in a modular and dynamic manner. It provides an ability to manage configuration and workflow execution in different ways, e.g., over a common interface like the Web browser.
  • JTA (Java Transaction API) provides standard interfaces for transactional interactions and a specification how to implement them. It's used to implement transactional support in a standard way.
  • StAX (Streaming API for XML) is used to parse XML in a more efficient way than it can be done with push-based SAX or tree-based DOM by allowing the application to retain control of the XML handling and on-demand processing.
  • XMLBeans is a technology for accessing XML by binding it to Java types
  • Maven2is a software project management and comprehension tool.

Projects using WEEP Engine