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

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

After thinking about it, I now believe it is better to reduce/avoid
references to specific bindings. That's the duty of the WSDL
specification and the WS-I basic profiles. Anyway, we can talk about
this during the review.

-Alejandro

> -----Original Message-----
> From: Monica J Martin [mailto:Monica.Martin@Sun.COM]
> Sent: Wednesday, April 12, 2006 3:37 PM
> To: Alejandro Guizar; wsbpeltc
> Cc: Danny van der Rijn; Ron Ten-Hove
> Subject: Re: [wsbpel] wspbel 4/4/2006: SOAP Binding References in
Section
> 10.3 and 10.4
> 
> Alejandro,
> I would suggest we maintain a stance of binding neutrality. As Alex
> often says, 'this is a slippery slope.' I'll bring this up for
> discussion in the Section 10 review.
> 
> Thanks.
> 
> > guizar: Are you referring to this fragment?
> >
> > [...]outbound messages produced by a BPEL runtime still MUST contain
all
> > the parts[...]
> >
> > The paragraph I wrote is intended to complement Dieter's original
> > proposal. He added a clarification to the paragraph in section 8.1
> > which explains bpel:unitializedVariable.
> >
> > An attempt during process execution to read a variable or, in the
case
> > of a message type variable, a part of a variable before it is
> > initialized MUST result in the standard bpel:uninitializedVariable
> > fault. This includes the invoke and reply activity, where the
presence
> > of an uninitialized part also results in the standard fault
> > bpel:uninitializedVariable.
> >
> > Note that the SOAP binding allows 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 are still
> > required to contain all the parts defined by the WSDL message. The
> > motivation for this requirement is preserving the binding-agnostic
> > nature of a BPEL process.
> >
> > The general requirement is, in fact, provided in the first
paragraph.
> > The second paragraph provides insight on a potential issue with the
> > SOAP binding and informs readers why the issue is disregarded. I
> > changed the wording so that the requirement keyword MUST does not
> > appear in the second paragraph.
> >
> > I am not concerned with the format of these notes, be it preceding
> > them with the words "Implementer's note", wrapping them in a box or
> > just relegating them as text as Monica suggests - I care about them
> > being present in the spec.
> >
> > -Alejandro
> >
> >
------------------------------------------------------------------------
> >
> > *From:* Danny van der Rijn [mailto:dannyv@tibco.com]
> > *Sent:* Thursday, April 06, 2006 8:03 AM
> > *To:* Alejandro Guizar
> > *Cc:* Monica J Martin; wsbpeltc
> > *Subject:* Re: [wsbpel] wspbel 4/4/2006: SOAP Binding References in
> > Section 10.3 and 10.4
> >
> > Burying a general requirement in something called "Implementer's
note"
> > is a bad idea.
> >
> > I don't like the implementer's notes in general, and the
> > binding-specific ones in particular. I also tend away from providing
> > rationale's for requirements in the way you've described.
> >
> > I support Monica's 2nd option.
> >
> > Danny
> >
> > Alejandro Guizar wrote:
> >
> > 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
> >
> >
> >
---------------------------------------------------------------------
> > 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
> >
>