Recently, I've spent a lot of time examining various BPEL-based products. They include Intalio, Cape Clear and Active Endpoints. After evaluating each of them, I've come to the conclusion that WS-BPEL is often not the right fit. If you're a pure-play Java shop, a solution such as JBoss jBPM maybe a much better fit (a future blog will go into some detail on how to use jBPM). The issues I see with BPEL are:
* BPEL, in an effort to support all vendors/platforms, only works with SOAP-based services. This means that every time an invocation is required, say to call an FTP or email adapter, the adapter/service must be exposed as a web service. That imposes a lot of extra overhead on the developer, and for internal services, seems onerous. Most of us don't live in a world where everything is automatically exposed as web services (I'm a big proponent of SOAP/Web services, but also realistic).
* Passing of data between activities/steps within a BPEL orchestration must be done using XML and WSDL constructs. Complex data transformations and assignments must frequently be performed using XSL, and developers who aren't well versed in the nuances of XSD schemas (in particular, namespaces) can become frustrated. Java and .NET developers must often wonder why they can't just pass a data class objects between the nodes.
* BPEL, by it's definition, is a closed standard. If a product is 100% BPEL compliant, extending it by supporting direct API java calls, for instance, automatically makes your orchestrations non-compliant, thus losing the benefits of the vendor neutrality and compatibility BPEL promises. Then what's the point of using BPEL?
* BPEL-based products are often app-server centric, meaning they have to be deployed an hosted. This often poses challenges from a testing standpoint, as developers must deploy their orchestration prior to being able to test it. Again, this impacts developer productivity in a negative way.
* BPEL introduces often very confusing nomenclature that must be learned. Concepts like "Partner Links", "Partner Link Types", "Partner Roles", "Port Types" and "Correlation Sets" are often not intuitive, and require a deep understanding of all things WSDL.
* Some products, such as Intalio, recognize the difficulties in modeling things natively in BPEL, so they use alternative, presumably more intuitive, solutions such as BPML. While that address some of the developer productivity concerns mentioned, they then rely on translation/code generation to output BPEL code. That "black-box" translation steps seems like a source of ongoing problems (the developer must, for example, try and determine why a diagram in BPML got translated into such-and-such BPEL code). Seems like a headache waiting to happen.
Add to Technorati Favorites
6 comments:
Well, certainly BPEL is not always the right fit, and you make some valid points in your post.
However, I have to disagree on some things.
Points #2 and #5: both of these concerns seem to indicate a lack of faith in a developer's ability to learn new things. BPEL is an XML based language which operates almost exclusively on XML data. Using XML technologies to manipulate that data is absolutely what should be happening in BPEL. Schema and XSLT are not difficult to understand, and I would assume that all SOA developers have these skills or could learn them without difficulty. As for BPEL introducing new concepts. Yes it does, but I have faith in people's ability to learn and grasp these (relatively few) concepts without too much trouble.
Point #1 (and to an extent #3): I don't see this as accurate. BPEL really makes no attempt to dictate the mechanism by which web services are invoked. It certainly doesn't require that SOAP be used. Yes, in order to invoke a service you must have WSDL for that service. But it's entirely possible (and highly useful) during deployment of your services to specify some other invocation method. Process/subprocess/Java invocation handlers are all possible and would be driven by engine-specific deployment information. This does not affect the vendor-neutral nature of BPEL.
Point #4: I'm behind you 100% on this one. Effect BPEL development relies heavily on tooling. Part of the tooling should be simulation and testing environments. ActiveBPEL Designer has an integrated simulation feature and a remote debugger, both of which are useful. Beyond that, I agree that tools need to begin incorporating better ways of testing BPEL processes without deploying to an app server.
Jeff, like everything related to technology, there is no single magic bullet so of course "BPEL is not always the right fit"...
first point jumps off the screen at me in regards to the limitations of BPEL, it is a fact that BPEL is not limited to web services, WSIF and JBI extends BPEL to HTTP/SOAP,POJOs, JCA,C sharp, and EJBs.....
Post a Comment