Is BPEL universal?

Jeff Davis blogs about some of what he sees as the short-comings with BPEL: What's wrong with BPEL?. It is a mixed-bag - somethings are correct, some aren't. Here are they points:

1. BPEL only works with SOAP-based services. This isn't true. With BPEL 1.1 spec, BPEL required WSDL as a means to specify a partner's API. Now WSDL can support SOAP bindings, but other bindings exist (e.g. WSDL-HTTP). So at a spec-level SOAP wasn't a prescription. However, in practice many BPEL 1.1 engines only supported SOAP-bindings. With BPEL 2.0 even this dependency on WSDL has been removed. - BPEL 2.0 doesn't require WSDL, and it already didn't require SOAP. The standard has deliberately and in my view correctly moved away from the WSDL/SOAP heritage. BPEL is a process workflow language about manipulating XML documents - so now it requires only XML Schema. I think over the next year many of the existing BPEL tools will support creating partner descriptions from REST+XSD, WADL and POX. The next version of Cape Clear supports inclusion of REST-style services directly in BPEL (no SOAP required). We've also greatly simplified connecting to JMS, Email, FTP, etc from BPEL with or without SOAP.
   
2. Passing of data between activities requires XML and WSDL constructs. Again BPEL 2.0 removes the WSDL part. You only need XSD knowledge. Admittedly this is confusing for developers - so I think this is mostly a valid point.. Looking forward, good tool support can help. BPEL 2.0 also supports expression languages. I think innovative companies will provide good Java-XML bindings automatically to make them amenable to Javascript or Groovy manipulation.
3. BPEL is a closed standard. This is the point that if you use an proprietary extension then you are no longer vendor neutral. While this point is true in the general sense, many BPEL engines provide the ability for developers to define XPath extension functions to Java which can be called from within BPEL. This is a reasonably indepdendent extension mechanism. Also, any Specification can be called a closed standard from this point of view. So should we abandon standards?
   
4. BPEL requires deployment for testing. This is true of some products (it is true of Cape Clear). Not sure I agree with the "impacts developer productivity". I think productivity can be enhanced through good tools: viewers, debuggers and test frameworks. For example Cape Clear allows developers to use Buckminster to automatically build, deploy and test BPEL or Java Web Services from within a continuous-build system.
   
5. BPEL is confusing - I agree with this point. There are lots of new things to learn. I'll get back to this point at the end.
6. BPML as a solution to BPEL/Process modelling - only makes things more brittle. I agree, but my advice would be: don't use BPML as a means of specifying BPEL. BPEL is a programming language, to gain its power, you need to use it directly.
   

So as I said a mixed bag, some right, some wrong. Jeff mentions that JBoss JBPM may be a better fit than BPEL for Java shops (which is interesting given his point 3 above). I obviously wouldn't agree :-) However, I think a more interesting issue is whether BPEL is a universal tool, can it/ should it be applied to all integrations involving Web Services. No it shouldn't. There is no such thing as a universal tool - there are no silver bullets. BPEL is incredibly powerful and has very well defined semantics, but it has a sweet-spot: orchestrating stateful web services together. If that is not what you are doing, for example, you are using BPEL as a stateless route-n-transform mediation, you can do this in BPEL, but if you are a Java shop, you can quite easily do this in Java. Many of the ESB's on the market (including Cape Clear) will help you do this with no BPEL required. So pick the appropriate tool to fit your circumstances.