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.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Jean-Jacques Dubray on Dec 29, 2008
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:
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:
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.
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.
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).
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.
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
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.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
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.
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.
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.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
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.
8 comments
Watch Thread Reply