WfXML-R: REST based process integration

Posted by Gavin Terrill on May 29, 2008

Sections

Architecture & Design,

Enterprise Architecture

Topics

SOA ,

Architecture ,

REST ,

Business Process Management

Tags

AtomPub ,

Atom ,

GData

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:

WfXML-R REST Resources

/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.

1. Back to top

   What about hypermedia?

   by Mark Baker

   Is REST really so difficult? These obviously well-intentioned folks seem to understand the uniform interface and the value of resource identification, but do it using standardized names rather than using hypermedia. Sigh.

   Reply

2. Back to top

   Re: What about hypermedia?

   by Tammo van Lessen

   Mark, could please elaborate on this? On page 12 I see atom collections referring to "sub"-resources, so it seems possible to browse the API. Isn't that hypermedia?
   And, as long as there is no way to describe the meaning of hyperlinks in a machine-reasonable manner (i.e. the semantics, the content that is captured by a resource) there is still a need for a operating guideline that describes what a resource actually holds, or am I missing something?

   Reply

• Older >