Does BPM-in-the-Cloud Require RESTful Services? ZapThink Says Yes, but Doubts Exist.
Jason Bloomberg, analyst at ZapThink, claimed that cloud-based Business Process Management (BPM) software will be disruptive to those traditional BPM engines that cannot easily move to a cloud delivery model. Instead of describing the value proposition of BPM-in-the-cloud, Bloomberg’s article focused primarily on his assertion that REST-based services are a necessity for any cloudy BPM engine to work properly. Michael Poulin of ebizQ took issue with that claim and debated whether stateless, RESTful services were truly a necessity.
BPM is considered a discipline where business processes are captured, managed and optimized with the goal of improving organizational performance. Commercial BPM software solutions often contain a platform for modeling process-based applications and business rules, and a runtime engine that executes these applications. While some are now asking if BPM itself is a failure, Bloomberg sees value in BPM but laments the co-opting of the space by middleware vendors.
Vendors loved BPM because process engines were a natural add-on to their middleware stacks. Coordinating multiple applications meant creating multiple integrations, and for that you need middleware. Lots of it. And in spite of paying lip service to cross-platform Service compositions that would implement vendor-independent processes, in large part each vendor rolled out a proprietary toolset.
If these vendors think that they can simply shift their products into the cloud, they will fail because of their stateful architecture, according to Bloomberg.
Here’s where the story gets interesting. In order to achieve the elasticity benefit of the Cloud for a distributed application, it’s essential for the application tier to be stateless. The Cloud may need to spawn additional instances to handle the load, and any particular instance may crash. But because the Cloud is highly available and partition tolerant, such a crash mustn’t hose the process that Cloud instance is supporting.
As a result, there is simply no way a traditional BPM engine can run properly in the Cloud. After all, BPM engines’ raison d’être is to maintain process state, but you can’t do that on a Cloud instance without sacrificing elasticity! In other words, all the work the big vendors put into building their SOA-platform-centric BPM engines must now be chucked out the door. The Cloud has changed the rules of BPM.
Bloomberg said that cloud-based BPM solutions must maintain process state in the messages that pass between the client and server. This happens by embracing the hypermedia aspect of REST and removing any coupling between a client and the server running the BPM engine.
The power of this idea is obvious once you think through it, since the World Wide Web itself is the prototypical example of such a runtime workflow. You can think of any sequence of clicking links and loading Web pages as a workflow, after all—where those pages may be served up by different resources on different servers anywhere in the world. No heavyweight, centralized process engine in sight.
[Hypermedia Oriented Architecture]-based BPM is potentially a disruptive technology, and they’re facing the innovator’s dilemma.
While complimentary of Bloomberg’s thoughts on this matter, Poulin used his four-part article to take exception with the assertion that statelessness is key to a cloud-based BPM solution. Poulin cautions against excessive state transfer in messages.
Thus, if the service is implemented as a process, it is free to manage its state as needed to be stateful or stateless (if you think about services as of a service-factory and you can instantiate as many services as needed, your constraint is only HW resources, not a service state). An idea of 2008 about carrying a process state within the exchange messages while still keeping the service stateless resulted in quite painful failures of many who started sending MB of information through the service interfaces.
I do not see a connection between Cloud elasticity and statelessness of the applications running in the Cloud
Can a cloud-based BPM solution be successful without a centralized engine and relying only on hyperlinks and client-managed state? Poulin expressed his doubt through a thought exercise.
Indeed, if we do no processing, we need only links. Let's start a process in line with "No process engine needed!" using HPPT's GET and PUT: when a process is triggered, a link leads to the Rules Engine and is supposed to return an instruction on what to do next. Where is this instruction returned to? The requestor for rules was a "stateless" process that acted in response to a client's request; so, the instruction may be returned to the client only (remember, the process may not keep its state) and only in the case if this instruction is short enough for GET/PUT. Then, the client has to invoke the same process (may be different instance) and pass the instruction back (into the Cloud?) to the "process" to act upon, and so on. If you can sell it to any business, please, invite me celebrate stupidity of this business.
While Bloomberg said that his approach could appear radical to some, he contends that many cloud-based companies are already working in this new paradigm. Poulin, however, recommended that businesses exercise caution before moving something like BPM to the cloud, and follow the advice of Peter Drucker:
"There is nothing so useless as doing efficiently that which should not be done at all."