Partager via

David Chappell nails it (again!)

  • Article

David Chappell recently published a great article with a horrible title: "The Case Against BPEL".  I hate the title because his article actually makes the case for the real value (imho) that BPEL provides - a standards-based approach for communicating public processes.   The original vision/intent of BPEL was to support both abstract (public) and executable (private) processes.

 

There are three public process scenarios I tend to think about regarding BPEL usage:

  1. The 800-lb gorilla in the value chain (e.g. Wal-Mart) dictates to  its suppliers how to interact with it using an abstract BPEL template.  Suppliers import the abstract BPEL and map their private processes into it. 
  2. An industry standards organization (e.g. a RosettaNet or HL7) could provide BPEL templates to its members as a set of "best practices" to ensure they implement the standardized process properly
  3. A distributed organization like a  bank could provide abstract BPEL templates to its branch offices, showing how the branches should interact with the corporate office for a given process.  (This is much like #1 except its within a single organization)

 

Organizations evaluating executable BPEL use it like a programming language - I'm not aware of any organizations leveraging portable executable BPEL implementations (if you are doing so please let me know - I'd love to hear about it). 

 

BPEL (to me) has always been about interoperable abstract processes - not portable executable processes. 

 

I expect the portability of executable BPEL will be relatively low to non-existent.  This is because the spec is missing some fundamental concepts for executable scenarios and vendors must extend the spec in non-standard (read: non-portable/non-interoperable) ways to get it to handle more detailed scenarios.