OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: Issue 304 - discussion - clarification on whether the QName ofa fault needs to be unique across all portTypes and operations

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.


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:

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.

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).

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:

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.

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."

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?"

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.

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.


Alex Yiu

Prasad Yendluri wrote:

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.


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


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
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?


Thomas Schulze wrote:
     Hi Prasad,

     a portType definition like the following would lead to problems,

         <portType name="My.Port.Type">
             <operation name="My.Operation">

     Best regards/Mit freundlichen Grüßen,

            Thomas Schulze

                  Prasad Yendluri


                  24.07.2006 15:53



                                            Re: [wsbpel] new issue -

                                            clarification on whether the
                                            of a fault needs to be unique

                                            across all portTypes and

     Hi Thomas,

     Why do we need such a limitation?  The local part is just an NCName
     (i.e. the LocalPart of the QName).


     Thomas Schulze wrote:

           Hi Prasad,

           so the only *new* limitation with this proposal would be that


           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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]