RE: [wsbpel] wspbel 4/4/2006: SOAP Binding References in Section 10.3 and 10.4

["Alejandro Guizar" <alex.guizar@jboss.com>]

Even tough we all agree that protocol bindings are outside of the scope
of BPEL, the SOAP binding is special in that it is the only choice for
BP-conformant bindings. Therefore, providing additional details on this
particular binding is quite appropriate IMO.

Rather than trimming the existing references, we should take the
opportunity to include another implementer's note describing the SOAP
binding's ability to select only the relevant parts of a message. 

Implementer's note: The soapbind:header and soapbind:body elements allow
for specifying the actual placement of WSDL message parts within a SOAP
envelope. Whereas this feature makes it possible to leave one or more
WSDL parts out of the SOAP envelope, outbound messages produced by a
BPEL runtime still MUST contain all the parts defined by the WSDL
message. The reason behind this restriction is preserving the
binding-agnostic nature of a BPEL process.

These notes do not seem to hurt; they provide insight to the enlightened
reader and may be safely skipped by the casual reader.

Finally, at this point we probably do not want to invest time scanning
the specification for spots to insert new notes into. I propose we keep
the existing note and reference, add the new note above and introduce
new notes only when the opportunity presents itself.

Thanks

-Alejandro

> -----Original Message-----
> From: Monica J Martin [mailto:Monica.Martin@Sun.COM]
> Sent: Wednesday, April 05, 2006 6:58 PM
> To: wsbpeltc
> Subject: [wsbpel] wspbel 4/4/2006: SOAP Binding References in Section
10.3
> and 10.4
> 
> Today, we discussed that it was outside of BPEL's scope to worry about
> protocol bindings. Reference the discussion on Issue 258 and Alves'
> comment re: SOAP binding ignoring parts.
> 
> However, we have such a mention currently in Section 10.3 that reads:
> 
> *Implementer's Note:* WS-BPEL treats faults as being based on
> abstract WSDL operation definitions, without reference to binding
> details. Normally, when sending or receiving a fault, a WS-BPEL
> process only deals with the fault information in the abstract fault
> message. A WSDL binding is required to transform the abstract fault
> message data to or from specific communication media. For SOAP
> bindings this means providing transformations between abstract fault
> message data and the sub-elements of the SOAP Fault element, namely
> the faultcode, faultstring, faultactor and detail elements. However
> the WSDL 1.1 standard SOAP binding explicitly precludes mapping any
> information from an abstract fault message to a SOAP Fault other
> than the contents of the detail element. In other words, there is no
> standard way to relate the faultcode, faultstring and faultactor
> sub-elements of a SOAP Fault element to data visible to a WS-BPEL
> process. Resolutions of this issue are out of scope of this
> specification.
> 
> And a later reference in Section 10.4:
> 
>     If, on the other hand, the response indicates a fault, the
faultName
>     attribute is used and the variable attribute (or its equivalenet
>     <toPart> elements), when present, will indicate a variable of the
>     message type for the corresponding fault. WS-BPEL treats faults
>     based on abstract WSDL 1.1 operation definitions, without
reference
>     to binding details. This limits the ability of a WS-BPEL process
to
>     determine the information transmitted when faults are returned
over
>     a SOAP binding. See the Implementer's Note in section 10.3.
Invoking
>     Web Service Operations - <invoke> for additional details.
> 
> This relates likely to:
> http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue170
> 
> We have at least two alternatives:
> 
>    1. Reconsider what we said today. (opening a larger set of issues)
>    2. Shorten text in Section 10.3 to be consistent with Section 10.4.
>       I'd opt for the minimal language in Section 10.4 and
abbreviating
>       any mention in Section 10.3, and perhaps relegating this to text
>       rather than an Implementer's Note.
> 
> We can discuss on Friday. Thanks.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php