Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
News
IBM's BPM Zero Project: RESTful Worflow Management
Posted by Jean-Jacques Dubray on Dec 29, 2008 01:00 AM
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.
RelatedVendorContent
Comprehensive Threat Protection for REST, SOA, and Web 2.0 Applications
Usage Landscape: Enterprise Open Source Data Integration
Not very RESTful workflow
by
Stephen Molitor
Posted
Dec 30, 2008 7:41 PM
Re: Not very RESTful workflow
by
Jean-Jacques Dubray
Posted
Dec 31, 2008 4:05 PM
Re: Not very RESTful workflow
by
Stuart Charlton
Posted
Dec 31, 2008 4:22 PM
Re: Not very RESTful workflow
by
Stuart Charlton
Posted
Dec 31, 2008 4:31 PM
Re: Not very RESTful workflow
by
Jean-Jacques Dubray
Posted
Jan 2, 2009 11:34 AM
Re: Not very RESTful workflow
by
Eric Roch
Posted
Jan 6, 2009 6:09 PM
Re: Not very RESTful workflow
by
Jean-Jacques Dubray
Posted
Jan 6, 2009 9:00 PM
Re: Not very RESTful workflow
by
rania khalaf
Posted
Jan 9, 2009 1:16 PM
-
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: http://www.infoq.com/articles/webber-rest-workflow.
-
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" (http://www.infoq.com/news/2008/06/olc-wbm).
-
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...
-
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.
-
>> 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.
-
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.
-
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.
-
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. http://www.vitalab.tuwien.ac.at/~florian/papers/ic08-bite.pdf 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 http://books.google.com/books?id=FsvSSBBP0FYC&printsec=frontcover&dq=bite+khalaf&source=gbs_summary_r&cad=0 cheers, Rania
8 comments
Watch Thread Reply