Hi Ugo,
I totally understand your viewpoints and concerns about SOAP binding
and WS-I BP. Similar viewpoints were expressed by WSDL/SOAP/WS-I-BP
teams at Oracle, during our internal brainstorming. That is exactly how
I created [option-I] for (2C) for illustration.
The core of this issue basically broils down to strike a balance point
between: SOAP/WS-I binding usage and non-SOAP usage binding of WSDL.
SOAP binding is definitely one of the most important bindings that we
need to deal with in BPWS.
If we just want to support WS-I BP 1.0 binding **ONLY** and if we care
a lot about the physical wire format, I would go for [option-I] also.
However, as mentioned in the proposal, XML schema element emulation of
WSDL message is a logical structure. It does not need to correspond to
the physical wire format. Because:
(a) different bindings (SOAP and non-SOAP) will lead to different
physical wire format. If we insists that the logical structure must
match parts of the wire format, the XPath in BPEL may need to be
changed upon the changes of deployment bindings of WSDL. (There may
even be some cases that the wire format does not exist for the message
parts. It can be just API calls for some bindings.)
(b) Even in a world that we cares only SOAP, we will have different
versions of WSDL (2.0), SOAP (1.2) and WS-I BP. That may lead to
different wire formats.
Disadvantage if we choose option-I:
For non-SOAP binding, the chances of a WSDL message with multipe parts
of using the same element will be increased. In those cases, users will
be forced to use some awkard position-based XPath expression. (I guess
you also see that point.)
An example in Java Land: if we use WSIF over Java Connector
Architecture (J2CA), it is likely that the J2CA driver returns a
hashmap of XML Elements (name-value pair).
Disadvantage if we choose option-II:
The BPEL processor just need to ignore the partname during applying
XPath processing to physical wire format message, when underlying
binding is a SOAP binding of document style.
I hope you can also see that the trade-off or disadvantages of
option-II is much lighter compared with option-I.
Thanks!
Regards,
Alex Yiu
Ugo Corda wrote:
Message
Correction
on my last point: in a document style SOAP binding, only one part can
end up in the SOAP body, but the message can still have multiple parts.
So, a position-based notation would still be required in those cases
where the message has multiple parts with same element name (but I
would suspect that it is a very small minority of cases).
Hi
Alex,
Yes,
I now see that my proposed change is identical to your original
option-I (which I had not read yet).
Let
me give you some points that I consider negative when choosing
option-II.
-
The "element" mapping has a double level element (the part-named
element plus the nested element-named element), while the "type"
mapping has only one level element (the part-named element - I am not
talking about any nested elements coming from the type definition
itself, of course).
-
Option-II is not consistent with what appears on the wire in the case
of a SOAP binding. (Before people start jumping on me saying that SOAP
binding is not part of the BPEL language, let me say that I know that
very well, but at the same time I think it is important to take into
account what happens in the SOAP binding - being it the current most
important binding when it comes to actual implementations - and to make
sure that BPEL's direction does not seem at odd with the current SOAP
binding direction).
Let
me elaborate on this point. The SOAP binding of WSDL 1.1 (after WS-I BP
1.0 clarifications) can have two different mappings to WSDL parts,
depending on the style:
1)
For rpc style (the part has to have a "type" attribute), the element
under the operation name element on the wire has the name of the type
(see BP 1.0, sec. 5.6.21, the SOAP message in the example). This is
consistent with your mapping (2B).
2)
For document style (the part has to have an "element" attribute), there
is only one element directly under the SOAP body on the wire and it
has the name of the "element" attribute of the part (see WS-I BP 1.0,
sec. 5.6.9). In other words, no double level element with one element
for the part and one nested element for the "element" attribute. This
is consistent with mapping (2C), option-I, but inconsistent with (2C),
option-II.
For
what concerns the case of two parts with same "element" attribute
value, that does not happen in the case of SOAP binding with document
style, since the message can only have one part. We don't know, of
course, about other bindings, but I would not be surprised if they
followed the same rule, since it makes sense to be talking about a
single document being sent over the wire.
Ugo
-----Original Message-----
From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Friday, May 07, 2004 12:52 AM
To: Ugo Corda
Cc: wsbpeltc; Alex Yiu
Subject: Re: [wsbpel] Issue 103 - draft proposal
Hi Ugo,
First of all, thank you very much for reading the proposal draft in
details.
I guess I did consider the mapping identical / similar to your
suggestion during our internal brainstorming. If you look at the
original longer version of proposal (before the simplified version), I
have two options listed in (2C).
I think what you are suggesting is option-I, while I prefer option-II.
The reasons that I prefer option-II are:
- Since the XPath to access a message part will always have a
part name (e.g. $msgVar/partName/... ), the Xpath will be more
intuitive:
- having an easy no-brainer mapping from <from
variable="msgVar" part="partName" /> to XPath
- having a consistent XPath for both wsdl:part[@type] and
wsdl:part[@element]: if we chose option-I, wsdl:part[@type] will have
its partName in XPath, while the Xpath for wsdl:part[@element] does
not.
- Consider Danny's example in previoue email, two parts
of same element QName, if we chose option-I, we need to use
position-based to distinguish different parts (e.g. $msgVar/bar[1]).
partName cannot be a part of XPath anymore.
I hope I have convinced you option-II is better.
Regarding to Issue 43, looking back into your resolution:
(I think you did a great job of catching those mistakes in the spec)
<message name="taxpayerInfo">
<part name="identification" element="txtype:socialsecnumber"/>
</message>
<bpws:propertyAlias propertyName="tns:taxpayerNumber"
messageType="tns:taxpayerInfo" part="identification"
query="/txtype:socialsecnumber"/>
<bpws:propertyAlias propertyName="tns:shipOrderID"
messageType="sns:shippingNoticeMsg"
part="shipNotice"
query="/shipNotice/ShipNoticeHeader/shipOrderID"/>
[bold part is your correction]
After passing Issue 103, the part semantics will be assimilated into
query string. The same examples will become:
<bpws:propertyAlias propertyName="tns:taxpayerNumber"
messageElement="tns:taxpayerInfo"
query="/identification/txtype:socialsecnumber"/>
The "identification" part is merged to query string.
<bpws:propertyAlias propertyName="tns:shipOrderID"
messageElement="sns:shippingNoticeMsg"
query="/shipNotice/ShipNoticeHeader/shipOrderID"/>
The "shipNotice" part is merged to the query string.
So, it is sync with what you want ... I guess. :-)
Agree? :-)
Regards,
Alex Yiu
P.S.:
---------------
(2C)(option-I) A
"wsdl:part" element which has an "element" attribute is mapped to an
"xsd:element" which has a "ref" attribute referring to the element in
"wsdl:part". The "xsd:element" has minOccurs=1 and maxOccurs="1".
<xsl:template
match="wsdl:part[@element]">
<xsd:element
ref="{@element}" minOccurs="1" maxOccurs="1" />
</xsl:template>
(2C)(option-II) A
"wsdl:part" element which has an "element" attribute is mapped to an
"xsd:element" which share the same "name" attribute value with
"wsdl:part". The "xsd:element" is based on an anonymous complex type,
which has a sequence of one "xsd:element. The "xsd:element" has a "ref"
attribute referring to the element in "wsdl:part" and has minOccurs=1
and maxOccurs="1".
<xsl:template
match="wsdl:part[@element]">
<xsd:element
name="{@name}">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="{@element}" minOccurs="1"
maxOccurs="1" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsl:template>
---------------
Ugo Corda wrote:
I would also rewrite [EX-7] as:
<xsd:element xmlns:xsd="http://www.w3.org/2001/XMLSchema"
name="GetLastTradePriceInput">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="foo:TradePriceRequest" minOccurs="0"
maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
Hi Alex,
If I understand your section 2 correctly, I
think that your proposed mapping (2C) is inconsistent with our previous
Issue 39 resolution, in the sense that the element constructed from a
part with an "element" attribute should take its name from the value of
the "element" attribute and not from the part name.
Ugo
|