|
Yes, indeed, Amit. Neither Steve nor I dispute that a process
specified in BPMN can be translated to BPEL. What we are asking, is
why bother? I can see no good argument for translating a BPMN process description into BPEL rather than directly into components built in (say) J2EE or .NET. As explained in a previous post, BPMN is not a formally sound language - so you can't hope for the chance to prove anything about an orchestration originally described using BPMN (as you could, for instance, with a choreography originally described in WS-CDL). So a BPEL description generated from BPMN is just a white elephant - a totally unnecessary intermediate stage. You can administer, monitor, and analyze processes implemented directly as components just as easily as processes implemented via BPEL - probably more easily given the maturity of existing component tooling. And this is not even to mention the original focus of this thread, which is the weakness of BPEL as an implementation language and consequent need for proprietary extensions - it is likely that a real-world BPEL process will be less portable than a J2EE/.NET component, not more portable. Even if BPEL staggers on for a few years, which is likely given the investment into it by platform vendors (more fool they), it offers negative ROI so will eventually disappear - and I don't think many experienced enterprise architects will bemoan its passing! BPM for enterprise automation will become equivalent to flowchart-based tools for component development and maintenance. Useful, but hardly the "third wave" revolution predicted for BPM. IMHO, the advent of BPMN spells the end of BPM as we know it, at least for enterprise automation - which is a shame, perhaps, but there you are. In its place, I see (my personal interest area of) human collaborative processes taking its place in the limelight, not as a server technology but as a peer-to-peer technology. -- All the best Keith http://keith.harrison-broninski.infoAmit Gupta (FSI) wrote:
YAHOO! GROUPS LINKS
|
- Re: [service-orientated-architecture] BPEL+ Amit Gupta \(FSI\)
- Re: [service-orientated-architecture] BPEL+ Keith Harrison-Broninski
- Re: [service-orientated-architecture] BPEL+ Ragavan
