The letter discusses the scenario that motivated this issue, why this scenario cannot be properly addressed in BPEL today and five proposed requirements to be met by a solution to this issue.

Issue to be resolved

How should BPEL support XML transformations?

Scenario

One of the key scenarios in business processes is gluing together systems with complementary semantics but different syntaxes. For example, one can imagine a purchasing system in one part of a company wanting to speak with an ordering system in another part of the company. The problem being that the two systems use different XML schemas and have slightly different semantics. This is a classic job for a business process. A key part of the business process's job is to transform the purchasing system's purchase message into a form that the ordering system understands. This transformation is typically achieved using a XML transformation technology.

Technical Issue

BPEL's limitations in the area of XML manipulation are discussed to some extent in issue 11. But this issue, issue 48, isn't so much about XML manipulation as it is about XML transformation. This is an area that has a rich history and wide spread support. The first standardized XML transformation technology was XSLT that was standardized in 1999 but already in wide use a few years before that. XQUERY is slated to be standardized in the coming months, has been five years in the making and already has implementations from 26 different organizations. Even newer efforts such as OASIS's CAM are just now getting started.

It would clearly behoove BPEL to allow its user community to leverage the massive industry wide investment in these technologies. Therefore the crux of this issue is how to best enable BPEL to provide support for these standardized XML transformation technologies.

Requirements

Please note that the examples are non-normative and only intended to illustrate possible ways in which the requirement could be met in order to better clarify the meaning of a requirement.

Hosted

Requirement: BPEL MUST provide a standard mechanism to host XML transformation technologies directly inside of a BPEL program.

Motivation: Transformations are intimately connected to the details of a particular BPEL program and the specific inputs it is receiving and outputs it is generating. Therefore one wants to be able to put the transformation definition directly inside of the BPEL program so as to establish as close a connection as possible.

Example: One could imagine either a new transformation activity or perhaps an extension to copy (the actual choice is an implementation decision and not something that appears appropriate for specification in a requirement) which would contain, in the case of XSLT, a <xsl:stylesheet> element.

Extensible

Requirement: BPEL's solution for hosting XML transformation technologies MUST be extensible so that it will be possible for the BPEL processor to discover statically what transformation technology is being used such that a processor can reject the specified technology if it does not support that particular type of transformation.

Motivation: While today there is only one standard XML transformation technology, XSLT, it is clear that more, such as XQUERY and CAM, are coming. Therefore the solution BPEL selects needs to be extensible so that there will be a clear means for using these newer technology in BPEL. It is also necessary to clearly define when these newer technologies are being used so the BPEL processor can detect when it has been asked to execute a technology it does not support.

Example: An attribute or other switch on the XML element used to host the transformation definition can specify what type of transformation technology is being used.

Flexible

Requirement: BPEL's solution for hosting XML transformation technologies MUST allow for each instance of a XML transformation specification to potentially use a different transformation technology.

Motivation: Different types of XML transformation technologies will be good at different things so a single global setting for the type of transformation technology used would be counter productive.

Example: The same as in the 'Extensible' requirement, each instance of a XML transformation definition could have its own attribute or element defining a switch specifying which XML transformation technology that instance was using.

Connected

Requirement: BPEL's solution for hosting XML transformation technologies MUST provide a mechanism to specify multiple sources of BPEL content as input to the transformation and specify the destination of the output.

Motivation: This is mostly a house cleaning requirement, it means that our transformation hosting mechanism has to provide syntax that allows one to specify multiple sources of BPEL content such as properties, service types, variables, etc. as well as multiple instances of those sources. It also requires us to provide a way to specify where the output of the transform will go.

Example: One could imagine specifying multiple 'from' elements as used in Assign/Copy to identify sources and a 'to' element to identify the destination.

XSLT

Requirement: The BPEL specification MUST include a fully defined solution for hosting XSLT in BPEL.

Motivation: The only way to know if the hosting solution actually works is to use it. Since XSLT is by far the most common XML transformation technology available it seems the more reasonable candidate to require BPEL to specify support for. There is, however, no requirement that BPEL implementations support XSLT, only that the BPEL spec tells them how to do it if they want to.

Example: Not only would the text specify where to place the <xsl:stylesheet> element but it would also define things such as what name should be used in the document function to allow for selection of different data sources in the transform.

wsbpel message