Section 14.4. Future Directions

14.4. Future Directions

BPEL is currently undergoing standardization at the OASIS organization, with many companies and groups contributing to this effort. Although the specification was not yet a standard at the time of this writing, the changes going into effect for what will likely be called WS-BPEL 2.0 stray only minimally from the details in this chapter and keep with the core guiding principles laid out.

Web service composition, however, has many open areas for research and industrial efforts. A few of these areas that are already seeing some activity include checking compliance of executable processes with their abstract counterparts, global models, extensibility, and the definition of new standards.

The use of abstract processes beyond the ability to formally define a business process is currently being studied. Its usage to check for compliance of a running Web service is one possible approach. It was noted earlier that you can derive an abstract process from an executable or vice versa by filling in missing parts. The tricky part comes from proving compliance between an executable and an abstract process. You can make this easier by providing harsh restrictions, such as only allowing a compliant executable to replace "empty" activities and provide the needed information for any variable's assignments that are labeled opaque. Although this drastically simplifies the problem, it is simply too restrictive to provide a general solution. Discussions and research are currently underway on what it means for such compliance to exist for processes in which the differences from the abstract one are more involved.

Another future direction is the ability to wire together different processes or even Web services to form something that is similar to WSFL's global models. Although partnerLinks provide some information on what is required from a compliant partner, they do not have enough information to derive a complete picture of wirings and relationships when you consider scenarios in which multiple processes are wired together. For example, partnerLinks are not enough to describe the setup in which two separate business processes should use the same bank process. The capability to define such global models, however, is at a level of abstraction above that of BPEL and would be expected to be defined in a compatible yet separate specification.

The addition of functionality to processes, as noted earlier, might be done either through proprietary language extensions or using policies. Current extensibility areas that are being studied include the inlining of other languages, such as Java. This has been the case for the definition of the BPELJ proposal [BPELJ]. Others include the capability to include human-facing activities. Finally, there have been proposals for extensions for quality-of-service capabilities. However, those are better represented as policy attachments because they clutter the business logic.

As additional standards and specifications are proposed for the Web services framework, keep in mind their modularity and their combined usage. With layering and modularity as core Web services principles, BPEL processes are expected to take advantage of new capabilities from such future standards by layering on top of the business logic that the BPEL process provides.