Recently, Patrice Cappelaere announced that an initiative to provide RESTful bindings to WF-XML 2.0 (pdf) has been accepted by the Workflow Management Coalition (WfMC) - WfXML-R.
WfXML-R aims to provide specifications around the 5 interfaces from the WfMC's Reference Model:
-
Interface 1: Definition of a standard interface between process definition and modeling tools and the work flow engine(s).
-
Interface 2: Definition of APIs for client applications to request services from the workflow engine to control the progression of processes, activities and work-items.
-
Interface 3: A standard interface definition of APIs to allow the workflow engine to invoke a variety of applications, through common agent software.
-
Interface 4: Definition of workflow interoperability models and the corresponding standards to support interworking.
-
Interface 5: Definition of monitoring and control functions.
Currently at version 0.4, WfXML-R lists support for the following use cases:
- Remote Application needs to discover and retrieve a list of available workflows, definitions and other available resources from server.
- Remote Application needs to be able to start (and stop) a process instance.
- Remote Application needs to:
- Find the current status of process instance
- Find the activities within that process that are currently being waited for
- Remote Application needs to be able to create, update and delete workflows and
- definitions.
- Remote Application needs to be able to start and stop the process engine, or create/delete a new engine.
- Remote Application needs to be able to check history and logs.
- Remote Application searches for specific resources
The REST resources identified at the time of writing include:
| /workflows |
This resource is the primary container initially created by a workflow analyst. This resource contains name information, author, and other meta-data related to the workflow. It points to other resources such as definitions and instances. |
| /definitions |
For a specific workflow, one or more process definitions can be specified, loaded into the engine and versioned. A process definition is necessary to specify the various activities to be performed by the workflow. A process definition is in essence the factory of process instances. |
| /processes |
Process instances perform the actual work. It contains the context information that distinguishes one process instance from another. A process instance resource can be used only once: it is created, then it can be started, it can be paused, resumed, terminated. If things go normally, it will eventually complete. |
| /activities |
The process instance will at any point in time be waiting for what it considers to be an external action to be completed. The activity represents this wait-point within the process. The process may be waiting for a human to interact with it, or it may be waiting for the result of an automated step in the process. The activity presents information about what the process is waiting for, such as the assignee, and possibly detail about how long it has been waiting, and how long it is willing to wait. In this case, the activity is acting as an observer of that remote process. The activity can provide the URL of the remote process instance that it is waiting on. |
| /traces |
As a particular process executes, the system may collect history information or traces regarding sequence paths, inputs/outputs after each activity, timestamps... |
| /participants |
Participants perform specific activities. They can be humans or other web services. |
| /workitems |
Human can be participants within a workflow and could be handed tasks (or activities) to perform. These requests could be queued in a “store” for the user to retrieve and complete. These requests are workitems. |
| /engine |
The engine itself is probably the most valuable resource to access. Remote Applications might want to check some engine attributes and change them. Administrators could create or delete a new engine resource... or get a list of running engines... |
| /errors |
The engine maintains a list of runtime errors that can be retrieved by the user. |
WfXML-R utilizes existing standards and protocols, including the Atom Publishing Protocol, Atom 1.0 Syndication Format, GData, OpenSearch and OCG Publish-Subscribe.