Christina Lau, distinguished engineer at IBM, gave recently a presentation at the Devoxx Conference “BPM 2.0 – a REST based architecture for next generation workflow management”. The goal of her presentation is to help us better understand BPM-as-a-Service (BaaS) to better prepare for it.
She defines BaaS with 5 key concepts based on Rashid Khan’s post on the topic:
- Model and execute processes in a hosted environment
- Integrate with both inside the firewall data and internet services
- Business users collaborate to create the business processes with a browser using RIA technologies
- Monitor, administer, rate, discuss processes over the internet
- Web-based reporting and monitoring (BAM) capabilities
She has initiated the BPM Zero project (which is part of IBM’s Project Zero and ultimately WebSphere sMash) following these principles. BPM Zero will offer a Web-based BPMN editor. Her presentation also features specialized BPMN activities dubbed “HTTP activities”: Receive, Reply, Invoke.
BPM Zero integrates with ILOG JRules to offer a business-centric configuration of decision services.
Christina and her team sees a tight integration between BPM Zero and what she calls “RESTful SOA”: Feeds, Twitter, Chat, email, SaaS (Google Apps), IaaS (Storage)… She explains that a light weight workflow can act as a scripting engine to tie together RESTful services.
The key characteristics of this scripting language are:
- Compatible subset of BPEL execution semantics
- Up and running in seconds
- Built-in extension mechanism
- Built-in security support
Security is a key part of this project as Christina explains:
Workflows can invoke a lot of services that have different security mechanisms – e.g. http basic access authentication, OAuth, OpenID, etc
She concludes by some recommendations to get ready for taking advantage of BPM-as-a-Service:
- Use BPMN to describe your processes
- REST-enabled your Assets
- Make content simple and human readable (XML, Atom, JSON)
- Make them available via URL with HTTP actions (GET, POST, PUT, DELETE)
- Leverage low cost deployment and third party applications hosted on the cloud
This presentation continues to send strong signals that Cloud Computing is going to significantly impact BPM. It also echoes some of the products already on the market (such as RunMyProcess.com, MyProcess.com) or soon to come.
Community comments
Not very RESTful workflow
by Stephen Molitor,
Re: Not very RESTful workflow
by Jean-Jacques Dubray,
Re: Not very RESTful workflow
by Stuart Charlton,
Re: Not very RESTful workflow
by Stuart Charlton,
Re: Not very RESTful workflow
by Jean-Jacques Dubray,
Re: Not very RESTful workflow
by Eric Roch,
Re: Not very RESTful workflow
by Jean-Jacques Dubray,
Re: Not very RESTful workflow
by rania khalaf,
Not very RESTful workflow
by Stephen Molitor,
Your message is awaiting moderation. Thank you for participating in the discussion.
I don't see what's RESTful about the workflow. A RESTful workflow would use representational state transfer to manage state and the workflow. Like this: www.infoq.com/articles/webber-rest-workflow.
Re: Not very RESTful workflow
by Jean-Jacques Dubray,
Your message is awaiting moderation. Thank you for participating in the discussion.
actually me neither. "Send", "Receive" and "Invoke" don't sound very RESTful, unless I am mistaken. On another note, the article you are pointing out has nothing to do with workflow...
Ultimately there is a fundamental question that need to be answered: What is the relationship between Resource Orientation and BPM. Interestingly, the BPMN camp does not really think in terms of resources and the REST camp rarely think in terms of BPM. Yet, it is obvious that there has to be an articulation between the two. As hint, I could suggest considering the concept of "Resource Lifecycle" (www.infoq.com/news/2008/06/olc-wbm).
Re: Not very RESTful workflow
by Stuart Charlton,
Your message is awaiting moderation. Thank you for participating in the discussion.
I agree JJ. Not just the enterprise resource, but the human-human or human-computer activities and interactions themselves should be modeled with a lifecycle, one that's independent of the processes that weave them together.
This was something BEA was trying to get towards with the AquaLogic Pathways and Pages products before the Oracle aquisition, sadly I think it's all stalled now...
Re: Not very RESTful workflow
by Stuart Charlton,
Your message is awaiting moderation. Thank you for participating in the discussion.
Stephen,
As interesting as it was, I don't think that article is the final word in how to RESTfully describe workflow. Much of that example is about illustrating how to manipulate the various resources used in a workflow -- it doesn't, for exmaple, attempt to model process state as its own resource, independent of the resources manipulated in that process.
I don't really know what the benefit of REST-enabled process state management would be - probably minor. An area where RESTful Web Architecture would shine is, in my opinion, human interaction & task management - independent of process engines. Basically, a RESTful alternative to WS-HumanTask and BPEL4People.
Besides that, I think a media type to model resource lifecyles, as JJ alludes to, would also be very valuable for enterprise use of this architectural style.
Re: Not very RESTful workflow
by Jean-Jacques Dubray,
Your message is awaiting moderation. Thank you for participating in the discussion.
>> An area where RESTful Web Architecture would shine is, in my opinion,
>> human interaction & task management - independent of process engines.
The problem however is that REST does not have any semantic to impose "task boundaries" on HATEOS. It does not know anything about users, roles and groups either, let alone ACLs on resources. So I don't really see any advantage REST would bring in the BPM space without additional semantics.
I believe REST is an anti-thesis of BPM as it is designed to enable "free navigation" across vast islands of knowledge and not to build enterprise class process centric information systems.
Some people equate naively the ability to invoke an action by combining a noun to an HTTP verb as an enterprise class capability. As a matter of fact this is what most middleware products do and quickly claim victory. This is exactly how BPM Zero sees REST and claims that it offers a "RESTful" composition platform.
It is not until we will understand that there is indeed an application model specific to connected systems that articulates Service Orientation, Resource Orientation and Event Orientation, that we will be able to build process centric information systems.
Re: Not very RESTful workflow
by Eric Roch,
Your message is awaiting moderation. Thank you for participating in the discussion.
I cannot imagine why anyone would want to build a work flow engine that was truly RESTful. BPM is about managing the state of a long-running, human-centric business processes. REST is by definition stateless. I am also not sure how to REST enable an application that was not build in the REST style to begin with. You cannot just slap a URI on top of an application and call it REST. There is more to REST than that. This is yet another example of hijacking the REST acronym for marketing purposes.
Re: Not very RESTful workflow
by Jean-Jacques Dubray,
Your message is awaiting moderation. Thank you for participating in the discussion.
Eric:
yes, I think we are past REST today. As Ted Neward said, nowadays, REST is whatever people say it is as long as they use HTTP. The next stage of evolution is "REST is a failure" (not that I consider it a failure). This is coming in about 12 months. Some people will write articles explaining that nobody understand REST. Vendors will add a couple more anotations du jour to their Service Framework and we'll start another "architectural" cycle.
Re: Not very RESTful workflow
by rania khalaf,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi all,
Great to hear some feedback :)
One thing that might help answer some of these questions is to look at some of the papers we've written about the flow language used in BPM Zero (slides, p31)), specifically addressing how it relates to REST concepts, SOA middleware, 'traditional' SOA flow (BPEL). You may have already come across the language as either 'Bite' or 'the Project Zero assemble flow language'.
1) Rosenberg, F., Curbera, F., Duftler, M., Khalaf, R., (Sept/Oct 2008). Composing RESTful Services and Collaborative Workflows: A Lightweight Approach. IEEE Internet Computing, 12(5), 24-31, IEEE.
www.vitalab.tuwien.ac.at/~florian/papers/ic08-b...
2) F. Curbera, M. J. Duftler, R. Khalaf, D. Lovell: Bite: Workflow Composition for the Web. ICSOC 2007: 94-106
which you can find here by scrolling to p.94
books.google.com/books?id=FsvSSBBP0FYC&prin...
cheers,
Rania