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 whetherthe QName of a fault needs to be unique across all portTypes and operat ions


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]