David Chappell nails it (again!)
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:
- 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.
- 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
- 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.