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: [wsbpel] Issue - R18 - Uniqueness of WSDL Faults

There are actually multiple cases:
 - multiple WSDL fault names with the same WSDL fault message
 - multiple WSDL fault names with different WSDL fault messages containing
the same WSDL part definition(s)

For these cases, you may have
(a) a binding that provides the fault name --> no issue
(b) a binding (like SOAP) that does not provide the fault name --> the
service provider should redesign the interface

IMO, this is another situation where WS-BPEL should not attempt to solve a
problem that resides between WSDL and bindings.

Kind Regards
 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

             Danny van der                                             
             <dannyv@tibco.com                                          To
             >                         Alex Yiu <alex.yiu@oracle.com>  
             11.10.2006 00:14          wsbpel@lists.oasis-open.org     
                                       Re: [wsbpel] Issue - R18 -      
                                       Uniqueness of WSDL Faults       

Alex Yiu wrote:

      Hi Danny,

      Regarding to the suggestion in your first bullet:
                  changing the fault catching behavior to not use fault
                  name, but its data type
      I am not sure I follow 100%. But, if my understanding is correct, we
      have already supported that kind of capabilities:

         <catch faultName="QName"?
            ( faultMessageType="QName" | faultElement="QName" )? >*

      <catch faultElement="foo:aFaultElement">
      <catch faultMessageType="foo:aFaultMsgType">

What I meant in the first bullet is that <catch faultName="QName"> is not a
well-defined option if the fault name can't be readily inferred.  So it
would need to be changed somehow, or removed.

      Of course, I guess the next question is: is that good enough? and do
      we need other extra "tools or ropes" suggested in your other bullets?

      And, I am not sure I follow your third bullet.

As for the 3rd bullet, I was suggesting that we specify an algorithm for
turning transmitted data into a fault QName.  As an example, I was
suggesting a lexical first match against the fault elements specified in
the WSDL.  Note that I don't have a suggestion for fault types, just
elements.  I imagine types would be similar, though.


      Alex Yiu

      ws-bpel issues list editor wrote:

            This issue has been added to the wsbpel issue list with a
            status of "received". The status will be changed to "open" if a
            motion to open the issue is proposed and that motion is
            approved by the TC. A motion could also be proposed to close it
            without further consideration. Otherwise it will remain as

            The issues list is posted as a Technical Committee document to
            the OASIS WSBPEL TC pages on a regular basis. The current
            edition, as a TC document, is the most recent version of the
            document entitled in the "Issues" folder of the WSBPEL TC
            document list - the next posting as a TC document will include
            this issue. The list editor's working copy, which will normally
            include an issue when it is announced, is available at this
            constant URL.

            Issue - R18 - Uniqueness of WSDL Faults
            Status: received
            Date added: 10 Oct 2006
            Date submitted: 10 October 2006
            Submitter: Danny van der Rijn
            Description: 1) Assume I have a WSDL portType that looks like
            the following:
            portType pT
                operation op
                      input element = "a:b"
                      output element = "a:c"
                      fault name="fault1" element = "a:fault"
                      fault name="fault2" element = "a:fault"

            Most WSDL transports (e.g. SOAP) do not tranport fault names on
            the wire. Usually all that is transmitted is the "a:fault"
            element, wrapped in some information that does not include the
            fault name.

            Yet 10.3 states that "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." We have no way of
            deriving, in this case, whether we're talking about foo:fault1
            or foo:fault2.

            Possible resolutions include
                  changing the fault catching behavior to not use fault
                  name, but its data type
                  disallowing WSDLs that use the same element in more than
                  one fault in an operation. (In the whole WSDL?)
                  explicitly specifying rules for inferring fault names.
                  For example, we could say that "a:fault" will always be
                  turned into "foo:fault1" and "foo:fault2" will never be
            2) Can't find in the spec what the QName of a non-declared
            fault is.
            Changes: 10 Oct 2006 - new issue

            To comment on this issue (including whether it should be
            accepted), please follow-up to this announcement on the
            wsbpel@lists.oasis-open.org list (replying to this message
            should automatically send your message to that list), or ensure
            the subject line as you send it starts "Issue - R18 -
            [anything]" or is a reply to such a message. If you want to
            formally propose a resolution to an open issue, please start
            the subject line "Issue - R18 - Proposed resolution", without
            any Re: or similar.

            To add a new issue, see the issues procedures document

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