atom feed1 message in org.apache.ode.devRESTful BPEL
FromSent OnAttachments
Assaf ArkinNov 16, 2007 2:14 pm 
Subject:RESTful BPEL
From:Assaf Arkin (
Date:Nov 16, 2007 2:14:45 pm

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.


[1] [2] [3]