I spoke at the CMG 2006 conference in Reno last week (I gave a presentation on SOA and appeared on a SOA panel). While at the conference I was confronted by a BPM-type who had lots of questions about BPEL. After some discussion I finally got the guy to realize that BPEL is an orchestration language, nothing more.
Trying to use an orchestration language for all of your BPM needs is like trying to drive a nail with a screwdriver - use the right tool for the right job and you'll find life is much easier.
Whoa! Terminology overload! BPM? BPEL?
I wrote an article which addresses just this aspect:
quote:
SOA and EDA implementations must be regarded in the context of Business Process Management (BPM). Modern BPM-tools are based on BPEL (Business Process Execution Language). The current BPEL implementation focuses strongly on the command-and-control model, the orchestration of services, and so on SOA. Beside orchestration BPEL - to a certain extend - also supports workflow, a kind of choreography, which goes in the direction of EDA. BPEL, however, has a procedural nature and runtime implementations need a controlling BPEL-engine. This is not a problem in case of SOA, but to achieve the aimed loose coupling of EDA it is. Good support for EDA would rather be a declarative model than a procedural model. A model where the designer – simply said – can connect events to publishers and subscribers by a point-and-click mechanism. Runtime implementations should be independent of a controlling engine, but rather be based on the earlier mentioned web services standards.
http://soa-eda.blogspot.com/2006/11/how-eda-extends-soa-and-why-it-is.html
Does BPEL relate to BPM the same way WS-* relate to SOA?
The article is fairly favorable and provides a fairly quick overview of the BPEL 2.0 spec. Here's some
I'm not really doing anything BPEL related these days but a post by Jesper Joergensen caught my eye.