Keith, What a great insight to all of this you have. Not that I would expect any less.
See inline .... but broadly I agree with your positioning entirely. Cheers Steve T On 17 Jan 2006, at 16:40, Keith Harrison-Broninski wrote: > 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. > :-) > > 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): Of course it is impossible to find any formal underpinning to BPM(L) despite suggestion to the contrary. BPEL also has no public formal underpinning although avid researchers are trying to fill this gap after the event. Whereas WS-CDL always had formal underpinnings at heart, even if they got started late in the day, being a concrete deliverable based on the public requirements document. Now it would be interesting if BPMN had a formal treatment too and then had formal semantics attached to it. Then it would very much be capable of being an interchange format - regardless of how one might feel about it. >> “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) > 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." > I could not agree more. I am not adverse to using orchestration in islands across a distributed landscape but let us not pretend it is any more than it is. Otherwise we run the same risk as in the 1970's which was the solution to all problems was a centralised DBMS. We moved away from that pretty rapidly. It would be interesting to see how one might describe human interaction (which is a communication of sorts) using something like WS-CDL "which is a language for communication centred design" [Kohei Honda et al] Cheers Steve T > -- > > 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. > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
