[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 48 - XML Transform Support
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.
How should BPEL support XML transformations?
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.
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.
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.
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.
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.
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.
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.
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.
From: ws-bpel issues list editor [mailto:email@example.com]
Sent: Tuesday, August 12, 2003 4:15 AM
Subject: [wsbpel] Issue - 48 - XML Transform Support
This issue has been added to the wsbpel issue list. The issues list is posted as a Technical Committee document to the OASIS WSBPEL TC pages on a regular basis. The current edition, as a TC document, is the most recent document with the title in the "Issues" folder of the WSBPEL TC document list - the next posting will include this issue. The list editor's working copy, which will normally include an issue when it is announced, is available at this constant URL.
Issue - 48 - XML Transform SupportStatus: open
Date added: 12 Aug 2003
Submitter: Yaron Goland
Date submitted: 12 August 2003
Document: BPEL Spec
Description: How should BPEL support XML transformations? For example, we could make it possible to include a XSLT or XQUERY transform in a BPEL.
Changes: 12 Aug 2003 - new issue
To comment on this issue, please follow-up to this announcement on the firstname.lastname@example.org list (replying to this message should automatically send your message to that list), or ensure the subject line as you send it starts "Issue - 48 - [anything]" or is a reply to such a message.
To add a new issue, see the issues procedures document.
--------------------------------------------------------------------- To unsubscribe, e-mail: email@example.com For additional commands, e-mail: firstname.lastname@example.org