Re: [service-orientated-architecture] BPEL+

[Keith Harrison-Broninski]

Steve Ross-Talbot wrote: So if we have a standard graphical notation and we generate BPEL from it and then generate Java or imbue an application server with the semantics of the generated BPEL, my question is what value is the BPEL. If my language of discourse is BPMN then BPEL does not really give me much at all. I can go from BPMN to Java or imbue some application server with appropriate semantics just as easily as I can do it through BPEL and out the other side. Indeed.  Though all this is the worst idea imaginable, of course, for certain folks - the "he-who-must-not-be-named" of BPM.  You're a braver man than I to speak out like this, Steve  :-) But since you have, let's follow this chain of thought to its natural conclusion. As BPM vanishes down into the murky world of middleware, BPEL's eventual disappearance does seem more and more likely, for exactly the reasons you say.  If BPMN is simply a sort of "visual tool for concurrent programming", why generate a brand new, designed-by-committee, feature-limited language like BPEL from it, instead of components created natively in mature programming technologies such as Java and .NET? Some BPM die-hards would start talking about the pi-calculus.  The original "third wave" specification for BPM was as a formally sound layer above such component technologies, based on mathematical representations of process.  But BPMN doesn't have such semantics, does it.  Some aspects of BPMN (e.g. the fundamental Pool and Lane constructs) have no semantics whatsoever!  Quoting the BPMN specification (v1.0 of 3 May 2004): “A Pool represents a Participant in the Process. A Participant can be a specific business entity (e.g, a company) or can be a more general business role (e.g., a buyer, seller, or manufacturer). Graphically, a Pool is a container for partitioning a Process from other Pools, when modeling business-to-business situations, although a Pool need not have any internal details (i.e., it can be a “black box”).” (P.103)  “Lanes are used to organize and categorize activities within a Pool. The meaning of the Lanes is up to the modeler. BPMN does not specify the usage of Lanes. Lanes are often used for such things as internal roles (e.g., Manager, Associate), systems (e.g., an enterprise application), an internal department (e.g., shipping, finance), etc.” (p.106) In other words, the fundamental BPMN construct, a swimlane, is at most a suggestion that certain activities should be carried out by the same agent.  This is at most.  In practice, it is "up to the modeler" what it means.  Hardly the formal underpinning that a BPMS was supposed to possess.  And since a process expressed in BPMN is not a formal construct, there seems little reason to turn it into BPEL.  For human-human interaction, BPEL offers nothing, and for enterprise automation, perhaps what we need is simply better tools on top of existing component technologies, tools offering those advantages of a BPMS that are perceptible to users: The ability to define processes graphically (the main reason people buy a BPMS) The chance in principle to circumvent the traditional build-compile-deploy cycle, although it is questionable how useful this really is in practice. Moreover, BPM vendors are busy consolidating with platform vendors, many of whom already offer sophisticated tooling for standard component technologies.  Since these vendors are well-positioned to incorporate the perceived benefits of a BPMS into their component tooling, the existence of BPEL as a sort of technology middle-man is going to become harder and harder to justify. So where does this leave BPM as a technology?  The only aspect of enterprise IT for which server-side component technologies do not provide adequate support, and hence for which we must look to BPM as a separate category, was identified by Ron in the last ZapFlash: "And, speaking of business processes, when humans are involved, it makes very little sense to have a centralized, computer-based system coordinating business processes on behalf of humans." Will BPM end up identified with client-side tools for process-based collaboration? -- All the best Keith http://keith.harrison-broninski.info YAHOO! GROUPS LINKS  Visit your group "service-orientated-architecture" on the web.    To unsubscribe from this group, send an email to:  [EMAIL PROTECTED]    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.