07/08/08 :: [SOA] Hint: Programming Models Matter in BPM too [permalink]
Fred Cummins asked the question last week: Why Should BPMN Support Choreography?
I may be wrong but I believe that BPDM started to support the concept of choreography under the momentum of Antoine Lonjon who was actively participating in the UN/CEFACT BPSS working group in the early 2000s.
Having been one of the editor of the OASIS ebBP 2.0.4 (and UN/CEFACT BPSS 1.1) and worked on BPSS/ebBP from 1999 to 2005, I may have an opinion or two on the question. Of course I have already clearly explained my opinions here on the relationship between BPMN, BPEL and Choreographies.
I generally highly respect the work coming out of the OMG, BPDM is no exception. This is the best "standards" organization and a lot of other standards organization could learn a thing or two on specification development processes. That being said, I am not sure the BPDM working group is really clear about what they are attempting to do.
Requirements for BPDM were very ambitious (way too ambitious?):
- Provide a common basis for all process oriented models
- Provide support for the service oriented world
- Integrate rules within processes
- Ensure Execution Interoperability of process models
- Use BPMN as the standard notation for processes
- Leverage other “process” knowledge : UML, BPMN, PSL
Unfortunately, the work around BPDM is rooted in corny understanding of the Business Process Management field. At the time when Antoine left the BPSS group the industry was still talking about "public" and "private" processes and of course, the corniest idea of all, that somehow there was a "compilation path" between a "business process model (BPMN)" and "orchestration" (BPEL) popularized by BPMI and BizTalk Server.
I have news for you, programming models matter in BPM too. It is not exactly new since I published this in 2002, but orchestration, choreography, B2B and workflow can participate in a unified programming model. I apologize to have to repeat myself, but these concepts seem to be so foreign to the BPM intelligentsia that it is not even funny to discuss them with them. I am actually quite disturbed how people can be closed to any discussion in that field too.
So one more time, the center of this unified programming model is the "resource lifecycle", I will say. Resources lifecycles interact and to events they publish and subscribe (not the processes, this is a myopic vision of BPM, an event is the occurrence of a state). Workflow of activities represent the work that is performed to advance the state of resource lifecycles. This model is trivial to understand, relatively trivial to implement with orchestration languages such as BPEL, BizTalk XLang, or Workflow Foundation. If you understand this programming model then to the following conclusions, you can come:
a) Business Processes "do not exist", a workflow, specified in BPMN for instance, is merely a possible set of activities to achieve a particular goal, it is not "THE set of activities". Do they represent the only possibility to achieve this goal? no usually the combinatorial possibilities are such that you can hardly define (with precision) a complete workflow when taking into account all states and transitions and all activities. Is BPMN useful, of course, it is important to use it for defining "best practices", communicate with the business, understand behavior and bottlenecks, but it is completely stupid to ever think someone will make use of BPMN to directly build entire solutions. The pundits seem to argue that they never said that, but as one of the post I read said, they kind of sell it that way even if they don't say it as clearly.
b) The distinction between private and public processes do not exist. A B2B boundary is an arbitrary legal boundary, you can label some of the interactions between resource lifecycles as being B2B but from a programming model perspective they are absolutely no different from a "private" interaction. Intuitively you should think, that if a manufacturing company buys its supplier there should be "no difference" in the information systems. The only thing that changes is the visibility (and control of course) but from a programming model perspective we should be able to express the continuity that truly exist.
c) Choreographies exist but the concept of Assemblies, I prefer (This is one and the same concept). Sure in B2B, you need an explicit contract, this is what OASIS ebBP offers today in a very sophisticated way. Now, I think that at the programming model level, WS-CDL and SCA's assembly specification should somehow merge. This would greatly improve SCA's assembly (only based on interface signatures today) and it will clearly show the value of WS-CDL in this programming model.
So, just as with the remoting bunch, the BPM bunch for decades, will err, until they finally understand the unified programming model behind their work (if ever). Interestingly (but not surprisingly) a tight coupling between the BPM programming model and the interactions that can be "remoted", there is.
You can see just by looking at the kinds of things that the remoting bunch (REST/RPC) and the BPM bunch (BPDM/BPMN) are doing and talking about that they will not connect for another 50 years. It is kind of ironic because the OMG wagged these two dogs for years, no to mention the concept of "State and Action" which are so central to UML. You would think someone at the OMG serendipitously uncover this programming model?
In all fairness, it was attempted with BOCA (Business Object Component Architecture) under the leadership of Jeff Sutherland amongst others. They were damn close but the bad press of CORBA and the simplistic views of some of the BOCA working group members such as Cory Casanave killed that initiative and prevented it to grow in this unified programming model. What a loss.
Does the OMG hold the key to that programming model? Sure, if it wants to, it has all the cards in hand, including, the SOA Consortium. IT is in dire need of this programming model, the question is who will have the guts to...?