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: [wsbpel] Re: Issue 304 - discussion - clarification on whether theQName of a fault needs to be unique across all portTypes and operat ions


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]