WfXML-R

Copyright © Jason Woodruff.  Visit the original at http://jasonwoodruff.wordpress.com/2008/04/25/wfxml-r/

Sandy Kemsley blogged about Pat Cappelaere speaking at a recent conference focused on enterprise architecture and process.

“He’s [Pat] using the term workflow to mean (I believe) the steps to assemble and process various resources and services into a web application: a service orchestration of various resources on the web using lightweight protocols. To implement this, they’ve created a RESTful version of the workflow bindings defined by WfMC as WfXML.  This was interesting, but I’m not at all clear what it was doing at this conference.”

FIrstly, I’m not sure what this conference was about, but I’m glad Patrice is out there talking about orchestration of resources.  This, to my way of viewing the world, is core to how I would like to build apps.  What I had missed (I must subscribe to Pat’s blog) is the publication of WfXML-R.

This diagram is taken from the 0.4 WfXML-R specification which “specifies that interoperable API using a RESTful approach between Workflow Engines and external applications being consumers and/or providers”.

I think this is a fab diagram for explaining the engine architecture.

The interfaces with which I think the specification is concerned are:

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 5, Definition of monitoring and control functions.

The workflow resources are defined as:

./workflows – primary container with links to other resources;

./definitions – the process definition eg BPEL;

./processes – a process instance;

./activities – the tasks and subprocesses of the process instance;

./traces – history / trail of the process instance;

./participants – people or other resources [I'm going to stop using the word service].

./workitems – tasks for humans waiting to be done.

./engine – yep, self-explanatory;

./errors – engine runtime errors.

The specification details how a remote application (interfaces 2 + 5 mainly, I suspect) would use Atom to GET information on the workspace containing the collections listed above.  Or to use POST, PUT and DELETE to start, halt/resume and stop a process instance respectively.

The specification also deals with interface 1, particularly creating, updating and deleting a new workflow definition using XPDL.

This is great stuff.  What is absent, and I don’t think was intended for inclusion looking at the use scenarios, is consideration of interface 3, invoked applications.  Of course this is the key to unlocking “orchestration of resources”.

Tags: WfXML-R