With this post, I'm starting a series of 4-Part BLOG. Every new Part will be published the following day. However, because of the publishing mechanism in ebizQ, every next Part will replace an announcement of the previous Part in the ebizQ Home page. Please, do not be confused with this - all existing Parts will be referred from each current Part.
Last week-end ZapThink posted a brilliant ZapFlash article - BPM in the Cloud: Disruptive Technology, which I highly recommend to read all those who use or plan to use BPM in Cloud (it seems BPM does not have enough problems on its own and now we are offered to pay for the new cloud problems).
To give you a taste of this article, here is just one short extract: "Sometimes, it feels like ZapThink is the lone voice of reason in the wilderness. We fought to cast SOA as a business-driven architectural approach in the face of massive vendor misinformation, hell-bent on turning SOA into an excuse to buy middleware. And while many organizations are successfully implementing SOA, perhaps with our help, in large part we lost that battle.
Today we're fighting the corresponding battle over the Cloud. The general battle lines are similar to the SOA days--ZapThink espousing business-driven architecture, while the vendors do their best to spin Cloud as an excuse to buy more gear. But just as the players in the two World Wars were largely the same even though the tactics were quite different, so too with SOA and the Cloud."
Though it is a bit of an exaggeration about the loneliness of ZapThink in the struggle for a business-driven SOA, their statement is fundamentally right - Computer Science in IT application was and is driven by vendors who hire talkative "scientists" to back up their products. However, from this point, I would debate the ZapThink arguments about BPM and BPM in SOA or Clouds rather than referring to vendors' scientists.
The first problem about BPM and Services that ZapThing picks up expressed as "Services are inherently stateless". Where ZapThink have gotten this idea about stateless services? One of the old names of a SO Principle was "Service statelessness" - a clumsy trick of words propagated by Thomas Erl while he, himself, formulated this principle as that the service has to manage its state; he did not say that the service must be stateless but just wanted, IMO, to promote an implementation of service scalability. In my review of SO Principles, I renamed aforementioned principle as "Service State Management", which I believe is more accurate. 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.
In the next section of the article, ZapThink makes a few non-justified statements and bases strategic conclusions on them. In particular, "In order to achieve the elasticity benefit of the Cloud for a distributed application, it's essential for the application tier to be stateless. ... As a result, there is simply no way a traditional BPM engine [M.P.: ESB] 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."
I do not see a connection between Cloud elasticity and statelessness of the applications running in the Cloud. In the essence, elasticity of Cloud is about ability to expand and shrink computational resources on demand, for an entire application or for its individual parts independently. If a service/process stateful and works at the moment, it can expand as needed (depending on the business rules for each of the process/orchestration steps) but should not be shrunk because it needs or might need the computational resources. What is needed should be dictated by the application, not by the Cloud policies (we do not Cloud that constraints us in how to do our business). That is, there is no architectural or logical contradiction between the stateful behaviour and the Cloud. Moreover, stateful application/service may look for Cloud implementation because of elasticity, i.e. an ability to maintain the state as long as needed consuming a lot of resources that are supposed to be cheap in the Cloud.
(to be continued)