InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

IBM's BPM Zero Project: RESTful Worflow Management

Posted by Jean-Jacques Dubray on Dec 29, 2008

Sections
Operations & Infrastructure,
Enterprise Architecture,
Process & Practices,
Architecture & Design
Topics
Business Process Modeling ,
Cloud Computing ,
REST ,
Composite Application ,
SaaS ,
Architecture ,
Business Process Management
Tags
BPEL ,
Websphere sMash ,
BPMN ,
Project Zero

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.

Not very RESTful workflow by Stephen Molitor Posted
Re: Not very RESTful workflow by Jean-Jacques Dubray Posted
Re: Not very RESTful workflow by Stuart Charlton Posted
Re: Not very RESTful workflow by Stuart Charlton Posted
Re: Not very RESTful workflow by Jean-Jacques Dubray Posted
Re: Not very RESTful workflow by Eric Roch Posted
Re: Not very RESTful workflow by Jean-Jacques Dubray Posted
Re: Not very RESTful workflow by rania khalaf Posted
  1. Back to top

    Not very RESTful workflow

    by Stephen Molitor

    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.

  2. Back to top

    Re: Not very RESTful workflow

    by Jean-Jacques Dubray

    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).

  3. Back to top

    Re: Not very RESTful workflow

    by Stuart Charlton

    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...

  4. Back to top

    Re: Not very RESTful workflow

    by Stuart Charlton

    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.

  5. Back to top

    Re: Not very RESTful workflow

    by Jean-Jacques Dubray

    >> 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.

  6. Back to top

    Re: Not very RESTful workflow

    by Eric Roch

    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.

  7. Back to top

    Re: Not very RESTful workflow

    by Jean-Jacques Dubray

    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.

  8. Back to top

    Re: Not very RESTful workflow

    by rania khalaf

    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

Educational Content

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.

Beauty Is in the Eye of the Beholder

Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.

Architecting Visa for Massive Scale and Continuous Innovation

John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.