[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Re: Issue 304 - discussion - clarification on whetherthe QName of a fault needs to be unique across all portTypes and operat ions
Dieter, In general looks good to me. I think we want to stay away from saying anything regarding uniquely identifying a fault etc. E.g. "and the fault name to uniquely identify a fault." Could I request you to highlight the changed parts. It is difficult to see what changed exactly. Thanks. Dieter Koenig1 wrote: >If we are able to agree on using QNames in BPEL without requiring them to >point to unique fault names in WSDL, would the following be acceptable >specification language (note that [SA00049] is no longer needed)? > >Section 10.3 - change from: > > In the case of a request-response invocation, the operation might return > a WSDL fault message. This results in a fault identified in WS-BPEL by a > QName formed by the target namespace of the corresponding port type and > the fault name. [SA00049] To ensure uniqueness, this uniform naming > mechanism MUST be followed even though it does not match the WSDL’s > fault-naming model. WSDL 1.1 does not require fault names to be unique > within the namespace where the service operation is defined. Therefore, > in WSDL 1.1 it is necessary to specify a port type name, an operation > name, and the fault name to uniquely identify a fault. Using WSDL 1.1's > scheme would limit the ability to use fault-identification and handling > mechanisms to deal with invocation faults. > >to: > > In the case of a request-response invocation, the operation might return > a WSDL fault message. This results in a fault identified in WS-BPEL by a > QName formed by the target namespace of the corresponding port type and > the fault name. To ensure consistent fault identification, this uniform > naming mechanism MUST be followed even though it does not match the > WSDL’s fault-naming model. WSDL 1.1 does not require fault names to be > unique within the namespace where the service operation is defined. > Therefore, in WSDL 1.1 it is necessary to specify a port type name, an > operation name, and the fault name to uniquely identify a fault. Using > WSDL 1.1's scheme would limit the ability to use fault-identification > and handling mechanisms to deal with invocation faults. > > >Section 12.5 - change from: > > Data thrown with a fault can be a WSDL message type or a XML Schema > element. Each <catch>, which specifies a QName as its faultName > attribute value, can only catch a fault matching that particular QName. > This one-to-one relationship is necessary in order to guarantee proper > targeting for fault catching. If the data to be caught is a WSDL message > then the faultMessageType attribute is used to specify the message > type’s QName. If the data to be caught is a XML element then the > faultElement attribute is used to specify the element definition’s > QName. > >to: > > Data thrown with a fault can be a WSDL message type or a XML Schema > element. Each <catch>, which specifies a QName as its faultName > attribute value, can only catch a fault with a matching QName (see > section 10.3. Invoking Web Service Operations - Invoke for the > description of how to construct this QName from a fault defined in WSDL) > . Faults with the same name defined in multiple WSDL operations within > the same WSDL namespace can be caught by the same <catch> fault handler. > If the data to be caught is a WSDL message then the faultMessageType > attribute is used to specify the message type’s QName. If the data to be > caught is a XML element then the faultElement attribute is used to > specify the element definition’s QName. > > >Kind Regards >DK > > Dieter König Mail: dieterkoenig@de.ibm.com IBM Deutschland Entwicklung GmbH > > Senior Technical Staff Member Tel (office): (+49) 7031-16-3426 Schönaicher Strasse 220 > > Architect, Business Process Choreographer Fax (office): (+49) 7031-16-4890 71032 Böblingen > > Member, Technical Expert Council Tel (home office): (+49) 7032-201464 Germany > > > > > > > > Alex Yiu > <alex.yiu@oracle. > com> To > pyendluri@webmethods.com > 25.07.2006 02:15 cc > Thomas Schulze/Germany/IBM@IBMDE, > Ronald.Ten-Hove@Sun.COM, > wsbpel@lists.oasis-open.org, Alex > Yiu <alex.yiu@oracle.com> > Subject > Re: [wsbpel] Re: Issue 304 - > discussion - clarification on > whether the QName of a fault needs > to be unique across all portTypes > and operat ions > > > > > > > > > > > >Our email just crossed each other. :-) >I think we are converging. >Some clarification changes needs to be applied to the "one-to-one" wording >as well. > >Thanks! > > >Regards, >Alex Yiu > > >Prasad Yendluri wrote: > Hi Alex, > > I am ok with clarifying in the area you mention. However we cannot > say in the same spec faultName QNames uniquely identify the faults in > one part and not in other parts. I think we need to clarify the text > in section 12.5: > > "Data thrown with a fault can be a WSDL message type or a XML Schema > element. Each <catch>, which specifies a QName as its faultName > attribute value, can only catch a fault matching that particular > QName. This one-to-one relationship is necessary in order to > guarantee proper targeting for fault catching. " > Regards, > Prasad > > > > > From: Alex Yiu [mailto:alex.yiu@oracle.com] > Sent: Monday, July 24, 2006 4:28 PM > To: pyendluri@webmethods.com > Cc: Thomas Schulze; Ronald.Ten-Hove@Sun.COM; > wsbpel@lists.oasis-open.org; Alex Yiu > Subject: Re: [wsbpel] Re: Issue 304 - discussion - clarification on > whether the QName of a fault needs to be unique across all portTypes > and operations > > > Hi Prasad, > > I understand where you are coming from. > WS-BPEL fault name identification is different from WSDL 1.1. And, > that has been the fault name design of WS-BPEL 1.1 and 2.0 design for > a long while. And, that has been intentional for simplicity and > unification of fault handling from different sources: WSDL operation > and internal BPEL logic. > > And, the green text highlighted in a previous email shows that is not > by accident or mistake. > > ------------------------------ > In the case of a request-response invocation, the operation might > return a WSDL fault message. This results in a fault identified in > WS-BPEL by a QName formed by the target namespace of the > corresponding port type and the fault name. [SA00049]To ensure > uniqueness, this uniform naming mechanism MUST be followed even > though it does not match the WSDL’s fault-naming model. WSDL 1.1 does > not require fault names to be unique within the namespace where the > service operation is defined. Therefore, in WSDL 1.1 it is necessary > to specify a port type name, an operation name, and the fault name to > uniquely identify a fault. Using WSDL 1.1's scheme would limit the > ability to use fault-identification and handling mechanisms to deal > with invocation faults. > > Faults in WS-BPEL are defined only in terms of a fault name and > optional fault data. This means, for example, that if a fault is > generated from a messaging activity (as opposed to the <throw> > activity (see section 10.6. Signaling Internal Faults) or a system > fault), there is no need to keep track of the port type or operation > the message activity was using when the fault was received. In > consequence, all faults sharing a common name, defined in the same > namespace and sharing the same data type (or lack thereof) are > indistinguishable in WS-BPEL. Faults of a particular name may be > associated with multiple variable types. The <catch> construct in > WS-BPEL facilitates differentiation of faults with the same name, but > with different message or variable types. For details regarding fault > handling and <catch>, see section 12.5. Fault Handlers. > ------------------------------ > > In order to deliver the spec on time, let's stick with this current > semantics and clarify that underlined sentence. > > > Thanks! > > > > Regards, > Alex Yiu > > > > Prasad Yendluri wrote: > > > Hi Alex, > > We are not introducing a new feature. We need to fix the feature that > is totally broken in WS-BPEL currently. > > The spec text that reads > > "This results in a fault identified in WS-BPEL by a QName formed by > the target namespace of the corresponding port type and the fault > name." > > is plain incorrect. We cannot define this to be a QName when the > localpart has no chance of being unique in a given WSDL namespace and > symbol space. We cannot pretend something is a QName when it is not > (and violate the XML Namespaces W3C recommendation as well as the > WSDL component model and symbol space division). WSDL 1.1 section > 2.1.1 clearly states only the following types of definitions > contained in a WSDL document may be referenced as QNames: > WSDL definitions: service, port, message, bindings, and > portType > > > So, a <wsdl:fault> "name" @ by itself cannot form the localPart in > a QName. > > Thomas is 100% correct in pointing out that to achieve this, BPEL > also needs to constrain this aspect in WSDL 1.1 so that no two > faultNames in a WSDL namespace can use the same value. That of course > has two major draw-backs of (1) not permitting reuse of same > faultNames for the same fault in multiple WSDL operations and > portTypes and (2) not permitting WS-BPEL processes to be defined > based on existing Web services that do not follow this restriction. > > So, I see the simple fix to this is to change the currently flawed > WS-BPEL faultName derivation scheme or relax faultName not to be a > QName. > > We cannot leave in this fundamental and major flaw in the WS-BPEL > specification. We need to fix it. > > Regards, > Prasad > > Alex Yiu wrote: > > > > > Hi Guys, > > Let us use this email subject to correlate the email messages. So all > the discussion messages will be collected on the issue list. > > I would like to make a few points here: > > [a] > The intention of this issue openning is to clarify the statement > quoted in this issue description. I do not intend to add any new > features here. > > [b] > Hence, I am not sure changing the faultName definition to " > <PortType-Namespace>:<portType name>.<operation name>.<fault name>" > or adding new attribute such as faultPortType to <catch> is a good > idea. I concur others that it would just make a relatively > complicated <catch> more complicated. > > Also note that fault comes from two sources within BPEL: from a WSDL > operation or from executing a <throw> activity within a BPEL Process. > We have been treating them homogeneously for last 3 yrs of BPEL 2.0 > cycle. And,we need to continue doing so, for simplicity and > usability. That is another reason why we may not want to add portType > info to <catch>. I tend to think allow users to add portType and > operation name in <catch> is a nice to have feature. Not, a > must-have. In terms of 80-vs-20 usecase, it would fall into the 20% > side (or even 10% side). > > [c] > Let me quote the related spec text again here: > ------------------------------ > In the case of a request-response invocation, the operation might > return a WSDL fault message. This results in a fault identified in > WS-BPEL by a QName formed by the target namespace of the > corresponding port type and the fault name. [SA00049]To ensure > uniqueness, this uniform naming mechanism MUST be followed even > though it does not match the WSDL’s fault-naming model. WSDL 1.1 does > not require fault names to be unique within the namespace where the > service operation is defined. Therefore, in WSDL 1.1 it is necessary > to specify a port type name, an operation name, and the fault name to > uniquely identify a fault. Using WSDL 1.1's scheme would limit the > ability to use fault-identification and handling mechanisms to deal > with invocation faults. > > Faults in WS-BPEL are defined only in terms of a fault name and > optional fault data. This means, for example, that if a fault is > generated from a messaging activity (as opposed to the <throw> > activity (see section 10.6. Signaling Internal Faults) or a system > fault), there is no need to keep track of the port type or operation > the message activity was using when the fault was received. In > consequence, all faults sharing a common name, defined in the same > namespace and sharing the same data type (or lack thereof) are > indistinguishable in WS-BPEL. Faults of a particular name may be > associated with multiple variable types. The <catch> construct in > WS-BPEL facilitates differentiation of faults with the same name, but > with different message or variable types. For details regarding fault > handling and <catch>, see section 12.5. Fault Handlers. > ------------------------------ > > The GREEN text shows that it is a clear and conscious decision that > BPEL does NOT exactly following the WSDL 1.1 fault naming. That is, > one faultName does not always match to exactly one fault defined in > WSDL. > > The core question around this issue is: whether the underlined text > above disallow the one-to-many mapping case (as Thomas read it). > > My reading is: the phrase of "ensure uniqueness" used by some spec > edtior gives unintended implication or interpretation. Because: > > (I) > Bear in mind again that, we also allow the same faultName defined in > WSDL to be thrown within a BPEL process by a <throw> activity. If the > spec really intends to achieve the global uniqueness (based on > Thomas' interpretation) here, there should be an explicit statement > in <throw>, which say any WSDL defined fault cannot be used by a > <throw>. But, it is saying the opposite (see blue text): > -------------------------------- > WS-BPEL does not require fault names to be defined prior to their use > in a <throw> activity. This provides a lightweight mechanism to > introduce business-process faults. A fault name defined in a business > process, a WSDL definition or a WS-BPEL standard fault can be > directly used, by using an appropriate QName, as the value of the > faultName attribute and providing a variable with the fault data if > required. > -------------------------------- > > (II) > The second part of the green text: > "In consequence, all faults sharing a common name, defined in the > same namespace and sharing the same data type (or lack thereof) are > indistinguishable in WS-BPEL." > > (III) > And, WS-I does not have such a global uniqueness restriction pattern. > Given the role of BPEL spec, it is just infeasible that we can ever > enforce this restriction based on Thomas's interpretation. If that > was the interpretation of the spec, that would be the first thing > that customer will complain about ... "why in the world my WS-I > complaint WSDL are rejected by your BPEL processor?" > > > [d] > Thomas Schulze wrote: > > > > In <catch> and <reply> BPEL refers to a fault name by a QName. It > might be possible to change <reply> so it references the faultName by > NCName, because the portType and operation information is available > here. But on <catch> this context information is not available and a > QName is really required. Therefore BPEL currently introduces the > restriction that a faultName must be unique within a targetNamespace > to fulfill the QName uniqueness constrain and this should not be > changed with respect to XML Namespaces. > > > > Thomas ... I am not sure I follow your elaboration here. > > However, I do think the "global uniqueness" interpretation was based > on an overlooked usage of "to ensure uniqueness" in the spec text by > some previous spec editing. I hope I have convinced you that the true > intention of the spec is to allow one fault name (QName) mapped to > many fault definitions (from different operation/portTypes and > <throw> usages), after reading the green and blue text that I quoted > above. > > > [e] > Submitter proposal: > To avoid misinterpretation of the spec, suggest to change > from: "To ensure uniqueness" > to: "To ensure consistent fault identification" > > After this clarification, we need to double check whether there is a > real static analysis enforceable here. > > > > > Thanks! > > > Regards, > Alex Yiu > > > Prasad Yendluri wrote: > > > Thomas, > > The whole QName is the faultName in the WS-BPEL domain including the > <catch> block. > If you need the WSDL faultName, then based on the potyType and > operation names you can extract the correct name. > > Regards, > Prasad > > > Thomas Schulze wrote: > > > > > Hi Prasad, > > in case this portType contains a fault and you like to reference it > in > <catch> according to your proposal, the faultName QName would look > like > this: > > targetNamespace:My.Port.Type.My.Operation.faultName > > Right? The portType "My" containing the operation "Port" defining the > > faultName "Type.My.Operation.faultName" is not meant here. > > Best regards/Mit freundlichen Grüßen, > > Thomas Schulze > > IBM Deutschland Entwicklung GmbH, IBM Lab Boeblingen > WSS - Business Process Solutions - BPC Development 2 > Schoenaicher Strasse 220, 71032 Boeblingen, Kst. 3056, Geb. 7103-02, > Raum > 0006 > Phone: +49-7031-16-3094 (T/L: *120-3094); E-Mail: > ThomasSchulze@de.ibm.com > > > Prasad Yendluri > <pyendluri@webmet > hods.com> To > Thomas Schulze/Germany/IBM@IBMDE 24.07.2006 16:14 > cc alex.yiu@oracle.com, > Ronald.Ten-Hove@Sun.COM, > wsbpel@lists.oasis-open.org > Subject Re: [wsbpel] new issue > - clarification on > whether the QName of a fault > needs to be unique across > all portTypes and operations > > > > > Hi Thomas, > > I do not see a problem. Can you please explain why you think there > would be > a problem? > > Regards, > Prasad > > Thomas Schulze wrote: > Hi Prasad, > > a portType definition like the following would lead to problems, > > IMHO: > > <portType name="My.Port.Type"> > <operation name="My.Operation"> > ... > </operation> > </portType> > > Best regards/Mit freundlichen Grüßen, > > Thomas Schulze > > > > > Prasad Yendluri > > <pyendluri@webmet > > hods.com> > To > Thomas > Schulze/Germany/IBM@IBMDE > 24.07.2006 15:53 > cc > alex.yiu@oracle.com, > > Ronald.Ten-Hove@Sun.COM, > > > wsbpel@lists.oasis-open.org > > > Subject > Re: [wsbpel] new issue - > > clarification on whether > the > QName > of a fault needs to be > unique > > across all portTypes and > operations > > > > Hi Thomas, > > Why do we need such a limitation? The local part is just an > NCName > (i.e. the LocalPart of the QName). > > Regards, > Prasad > > Thomas Schulze wrote: > > > Hi Prasad, > > so the only *new* limitation with this proposal would be > that > portTypes > > and > > operatins must not contain the "." character when used > with > BPEL. Right? > > Best regards/Mit freundlichen Grüßen, > > Thomas Schulze > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]