[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
Hi, +1 to Dieter's text. (Thanks, Dieter!!!) Also, similar request to highlight the changed text. Regards, Alex Yiu Prasad Yendluri wrote: > 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]