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