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: 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
>
> 25.07.2006 02:15 cc
> Thomas Schulze/Germany/IBM@IBMDE,
> ,
> , 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 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:]
> Sent: Monday, July 24, 2006 4:28 PM
> To:
> Cc: Thomas Schulze; ;
> ; 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:
>
>
>
> Prasad Yendluri
> <pyendluri@webmet
> hods.com> To
> Thomas Schulze/Germany/IBM@IBMDE 24.07.2006 16:14
> cc ,
> ,
>
> 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
> ,
>
> ,
>
>
>
>
>
> 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
>
>
>
