[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] wspbel 4/4/2006: SOAP Binding References in Section 10.3and 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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]