The power of BPEL is that it lives in an ecosystem of standards. On its own BPEL can not address all the integration use cases. But coupled with the other SOA standards, you have a very powerful toolkit for building composite business processes:

FUD #1: BPEL does not have support for data tranformation. The truth is that BPEL has a pluggeable expression language and can be coupled with XPath, XSLT or XQuery. BPEL can also call out to "DataHub" services for data quality and enrichment requirements.

FUD #2: BPEL can not call Java, C# or other finer grain objets. The truth is that BPEL is based on WSDL and as such leverages the pluggeable binding capabilities of WSDL. Apache WSIF and JSR-208/JBI offer concrete implementation on how this can work.

FUD #3: BPEL can not orchestrate people tasks. The reality is that IBM, Oracle and BEA offer as part of their integration product a Task Service which encapsulates Human activities and can be plugged into an BPEL service as a standard asynchronous service.

FUD #4: BPEL does not include business rules. Here again business rules is best integrated into a BPEL process as a decision service or a call out from the expression language. There is no need for BPEL to re-invent the wheel.

The point about analyst level annotation is a valid one, and one that the industry is working on: BPEL/BPMN integration or BPEL/UML Activity Diagram integration or something more creative. But to be fair to BPEL, you have to admit that no other alternative delivers on "business analyst build application"...at least beyond very simplistic expense report type applications.

As more and more customers adapt SOA/BPEL, one can expect that 1) new "views" of BPEL will emerge based on metadata annotation of the BPEL process (similar to JavaDoc annotation of Java Code can generate documentation overview) and 2) the interface of the human task service and rules engine will standardize.

BPEL is no more a panacea than any other standard. BPEL's primary objective is to provide a standard notation for orchestrating process flows across services endpoints. In this context, BPEL's syntax and semantics are wonderfully expressive, supporting a rich foundation of (simple and complex) process patterns.

While it's true that BPEL does not attempt to address all business integration issues (BPEL's lack of human workflow constructs is well chronicled), many standards reach broad adoption specifically because they avoid the temptation to "boil the ocean". They address a defined problem in a leverageable, portable way, accepting the obvious limitations that accompany their specific focus. SOAP and WSDL are examples of standards with narrow apertures, yet they are among the most broadly used standards in the SOA community today.

As pundits and nay-sayers nip at BPEL's heels, BPEL uptake in the IT community is gathering significant momentum. Within 12 months, every major software stack will support BPEL either as a native process notation or an interoperability standard. It's also noteworthy that BPEL is being used at some level in thousands of IT organizations worldwide (I know this because my company, Active Endpoints, is the leading provider of open source BPEL technologies to those organizations).

Saying the BPEL is not a panacea for all types of business integration is stating the obvious, in my view. BPEL's original authors (IBM, Microsoft and BEA) had clear notions of the problem domain they were addressing in their original BPEL4WS specification, and those concepts have been well represented by the OASIS BPEL Technical Committee. The resulting standard will become an important addition to SOA's bedrock, and will competently support the implementation of composite, loosely-coupled information systems.