OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] An amendment to the proposal for issue 103


The alternative proposal is to represent WSDL messages with parts as an 
XPath node-set. An XPath node-set is simply a collection of nodes, and 
in this proposal we let each node be an element who's unqualified name 
is identical to the WSDL message part name. We can use XPath (1.0 or 
2.0) axis to retrieve specific message parts.

For example, given a variable 'msg' that holds a WSDL 1.1 message with 
two parts 'foo' and 'bar', we would access both parts individually with 
the XPath expression:
  $msg/foo
  $msg/bar
we can access both parts collectively using other XPath axis functions. 
For example to access the entire message:
  $msg
to access all 'address' elements contained in both 'foo' and 'bar' 
message parts:
  $msg//address

The benefit of this proposal is that it treats messages as we would if 
we were to use WSDL 2.0. Since WSDL 2.0 does not use message parts, but 
represents messages as infosets, we will use a single XPath variable to 
access the entire message, and traverse its contents in the same manner. 
We therefore have to start thinking and designing processes in terms of 
WSDL 2.0.

Assaf


Satish Thatte wrote:

>There are two primary motivations for the excellent work Yaron and Alex have done on issue 103.  One is the desire to clarify the usage of XPath in BPEL including a precise definition of the environment provided for the XPath processor within a BPEL process definition.  The other is the idea of using the native XPath variable syntax as a binding mechanism for XML data held by a BPEL process.  The current proposal for 103 creates a pseudo-binding for WSDL messages that allows the content of the entire message to be viewed as a single XML infoset.  During the F2F meeting, many concerns were expressed about the consequences of creating such a pseudo-binding, and there were two proposals made to preserve the bulk of the work done in the present proposal for 103 while avoiding the pitfalls of the pseudo-binding.  I made one of the two proposals, and this note explains the proposal and the reasons why I prefer it.
>
> 
>
>The issue at hand is the exact nature of the binding for WSDL messages with parts.  My proposal is simply to invent a naming convention for message parts that allows parts to be named directly in XPath variable bindings.  Assume for the moment that we reserve "_" as a special delimiter that is not allowed to be used in BPEL variable names.  Assume further that "PO" is a BPEL variable with a part named "product".  Then we would permit the use of the form "$PO_product" in XPath to signify the (presumably XML) content of the product part of the message stored in the variable "PO".  This proposal is extremely simple and invents nothing beyond what WSDL 1.1 provides as a content model for message types.  There are other considerations in favor of this proposal that I list below.
>
> 
>
>The first thing to note is that at present, BPEL itself has no native feature for processing XML, nor does BPEL have any native notion of message content models.  All message and XML types, content models and handling in BPEL rely exclusively on external standards such as XML schema, WSDL 1.1 and XPath 1.0, and BPEL permits the integration of new standards through its mechanisms for specifying query and expression languages.  This proposal preserves the principle of keeping the BPEL specification out of the business of defining message content models. 
>
> 
>
>The second point to note is that WSDL allows parts to be based on type systems other than XML, for instance arbitrary MIME content types.  It is possible to have a part that carries a JPEG image, and it is perfectly reasonable for a BPEL process to assign the content of such a part from one message variable to a corresponding part in another message variable without ever concerning itself with the content type.  We assume that the process knows its message types and will bind only XML parts into XPath expressions.  Any proposal that attempts to create an XML-based content model for arbitrary WSDL 1.1 messages will run into trouble with these issues.
>
> 
>
>It may be argued that WSDL 2.0 has moved to a pure XML infoset model for messages, as indeed it has.  However, the WSDL 2.0 WG has not provided a "migration story" for rendering WSDL 1.1 messages in WSDL 2.0 infoset form, apart from the fact that the BPEL TC has explicitly declined to take a dependency on any WSDL 2.0 feature.  It hardly seems our place to provide an XML-based content model for WSDL 1.1 messages when the WSDL 2.0 WG has not done so.
>
> 
>
>All these considerations lead me to believe that we should be absolutely minimalist in binding the content of WSDL 1.1 message types to XPath expressions, and the proposal outlined here is exactly such a minimalist proposal.  The benefits of any proposal based on creating an XML-based content model for all WSDL 1.1 mesages must be weighed carefully against the cost and difficulties of specifying such a model, and the pitfalls implied by the considerations outlined above and others that will occur to you.
>
> 
>
>Satish
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
>
>  
>


S/MIME Cryptographic Signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]