Vendors, Users Must Embrace BPEL -- Warts and All
Type: Advisory Report
Analyst: S. Willett
Report Date: May 10, 2005
Module: Application Infrastructure
ID: CIR13738 |
|
|
Summary
Issue
Web Services-Business Process Execution Language (WS-BPEL) has been touted by some vendors and industry analysts as the glue that will bind together Web Services. BPEL will put a standards-based process layer on top of a service oriented architecture, allowing for a new wave of free floating business process logic and composite applications, say supporters. Detractors have pointed out the many deficiencies in BPEL. In reality, BPEL does have a lot of problems, but it also looks like it’s the only game in town for a process standard.
Top
Perspective
Current Perspective
BPEL, or WS-BPEL, as it has now been renamed, has been touted as nothing less than the foundation for applications built on service oriented architectures. Larger vendors such as IBM and Oracle, as well as a bevy of smaller vendors such as Active Endpoints, Cape Clear, and others, are marketing their native BPEL process tools as a differentiator. Other vendors have pointed out that BPEL is immature, with a raft of deficiencies that make it a candidate for a “wait and see” approach at best. With BPEL 2.0 now out in draft form, it’s clear that BPEL will gain some incremental improvements, although it is not about to fulfill everyone’s wishes. Nevertheless, it’s time for users and vendors to take some action to make a better BPEL.
The advantages of BPEL are clear. For one, it is a standard execution language for processes, where none exists today. This makes porting or interoperation of processes from different platforms possible. BPEL is also built from the ground up with WSDL as its language for exchanging messages and interacting with endpoints. This makes it a plausible SOA-enabled process platform—again where none have existed before. BPEL, now part of OASIS, is also fitting into the intricate WS-x web of standards, which will also bolster its claim to be the process platform for SOAS and composite applications. The new version, BPEL 2.0, promises more functionality. There are specifications for “partner” endpoints, which could enable B2B, and there is more explicit support for XPath documents, and more flexibility around defining events and “expressions.”
The spec has its weaknesses. Developers say it is far more than a scripting language and is relatively hard to use and learn. The spec is silent about human oriented processes, which will be a big part of composite applications. In fact, it is silent about a lot of things that are part of traditional process applications, which is why detractors say it is too “loose” of a spec to be practical for interoperability. Another criticism is that the spec is maturing much too slowly, with 2.0 only containing modest improvements.
While these are valid criticisms, it is also clear that no spec is perfect and no one spec can do it all and shouldn’t be expected to. Where that has been tried, the spec has fallen over from its own weight. Since BPML, BPEL’s most proximate competitor, is all but dead, vendors and users in the BPM, integration, and SOA space will have to adopt BPEL as their own and work to minimize its deficiencies and bolster its strengths. For one, interested vendors need to make BPEL interoperate with related WS-x specs that deal with issues such as choreography, transactions, and security. Vendors also need a framework to make BPEL work with transformation, event handling, and message brokering, perhaps outside of the OASIS and WS-x standards (Sun & company have already attempted this with JBI). Human workflow also has to be dealt with, if not through BPEL, then through a closely related WS-x standard. In the meantime, BPEL vendors need to add in their own extensions for human workflow and interface development. It is also up to BPEL vendors to ease the learning curve through training, education, visual development tools, and testing/simulation features. Users have a big stake in this also, particularly those who have invested in SOAs as a roadmap for their IT environment. They should influence standards bodies either directly or through favored software vendors and deal with the imperfect BPEL spec with open eyes.
Top
Recommended Actions
Vendor Actions
• Vendors should work to adopt BPEL as their native BPM/workflow language in the long run (12-36 months).
• Vendors should move the BPEL standards process along at a quicker pace and attempt to include tighter interoperability with related WS-x standards relating to choreography, security, transactions, eventing, as well as WSDL and SOAP.
• Vendors should work to either include human workflow into BPEL or develop a closely related spec that allows human sub-processes. Until this is achieved, BPEL vendors need to add more human workflow into their products using their own technology.
• BPEL vendors should work to provide visual interfaces and education/training on BPEL to hasten the learning curve.
• Vendors should consider their own frameworks for allowing BPEL processes to seamlessly interoperate with integration technologies such as transformation, and messaging/message brokering. JBI is one example of this, but others are also possible.
User Actions
• Users who are implementing SOAs should put their weight behind BPEL as it is the most feasible standard for processes that link together services. They should plan to move to BPEL compliance (native) in the next 18-48 months.
• Users, however, should realize that it will be years before BPEL and interlocking WS-x standards will become a full reality, and they will have to rely on vendor implementations and extensions to fill the gap.
• Large user organizations should either join standards committees (in a working role or advisory role), or pressure vendors to make modifications in BPEL that reflect their real world concerns.
|
