Next in thread →
Next in month →
Re: [wsbpel] Re: Issue 304 - discussion - clarification on whether theQName of a fault needs to be unique across all portTypes and operat ions
Resending the same text in a Word doc (with change highlighting):
(See attached file: Issue 304.doc)
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 23:23 cc
Dieter Koenig1/Germany/IBM@IBMDE,
, 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
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:
>> 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
>>
>>
>>
>
---------------------------------------------------------------------
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
Next in thread →
Next in month →