RESTful BPEL

[Assaf Arkin <ar...@intalio.com>]

Time to get the ball rolling to add REST support to Ode.

I started by looking at how we can send XML messages to arbitrary HTTP
URLs, which turned out to be fairly simple to do.  In case you're not
aware of it, WSDL ( 1.1 and 2.0) define protocol bindings for HTTP, so
it's a simple matter of configuring the service definition to use
these instead of SOAP.

It's good enough and gives you what some people call XML over HTTP,
other fondly refer to as POX, but it's still essentially SOAP without
the soap:envelope.  Doing REST takes more than that.

An important principle of REST is "hypermedia as engine of application
state"[1].  Essentially what happens when you follow a link from one
Web page (resource) to another, or submit a form and get redirected.
In the formalism of mobile processes we call this "channel passing".
In BPEL, the ability to assign partner links to/from variables.

But partner links are two level of abstractions away from a URL, and
the need to turn URLs into service references ends up obscuring the
process definition and hiding what it's trying to do behind a forest
of assignments.  It doesn't help that there's no way of telling
whether an operation on a partner link is going to create a resource
or delete it.

Isn't the whole point of doing REST in BPEL to make Web services
simple and more transparent?

It turns out the simplest solution is extending BPEL, applying the
REST principles without forcing BPEL authors to jump through hoops.
These extensions are kept to the minimum and use most of what already
exists.  And since we have two use cases, we'll break them up in two
parts.

Part 1 deals with using RESTful Web services from within a BPEL
process [2].  It uses the invoke activity with a few modifications
that make it REST friendly.  It gets rid of the WSDL abstraction and
handles HTTP directly, and avoids the overhead of partner links.  A
resource is a URL, and a URL is a string, and we already have place
holders for strings, in BPEL variables.

Part 2 deals with implementing a service using BPEL and exposing it
using the REST constraints [3].  Here we do need to create resources
(each process is a resource, after all), and manage related resources,
so we introduce the resource declaration.  The uniform interface gives
each HTTP method its own semantic, GET is not like POST, neither is
PUT like DELETE, so this part also deals with the specific semantics
for HTTP methods in receive/onEvent.

This is just a first draft, feedback is welcome, so are more use cases.

Assaf

[1] http://en.wikipedia.org/wiki/Representational_State_Transfer
[2] http://ode.apache.org/restful-bpel-part-i.html
[3] http://ode.apache.org/restful-bpel-part-ii.html

-- 
CTO, Intalio
http://www.intalio.com