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] Issue - 280 - discussion

Hi Mark and Alex,

I read all existing fault handling rules as Alex, QName matching based on
the declaration in the WSDL. If the actual thrown element data's QName does
not match the QName in a <catch faultElement="..."> it isn't catched by
that <catch>. IMO, in the following example the <catch> currently can't
catch the thrown variable and that's too true for rules 2 and 5:

<element name="E1" type="T"/>
<element name="E2" type="T"/>

<variable name="E1" element="E1"/>
<variable name="E2" element="E2"/>

    catch faultElement="E1"
    throw variable="E2"

Means there is currently no support for cross-over catching (elements of
the same type) or substitution groups. Maybe this needs a clarification.

But exactly that's the reason why we propose to resolve issue 280 by only
adding a faultType attribute to <catch> and do the matching by QName
according to the current rules 1 and 4. Like for elements, no support for
inheritance and cross-over catching. Currently no type-matching is
supported and with this proposal we don't like to change that when
resolving this bug issue which only addresses the existing inconsistency
between <throw> and <catch>.
For me, catching types is not only a 20% usecase. It's more a 50% usecase,
I think. The current spec makes extensive use of examples with multi-part
messages which parts are type-typed. And there are too a lot of existing
WebServices which have an interface with such messages. To be able to
support those existing stuff fully, I think BPEL needs to be able to throw
and catch types. As outlined in section 3 BPEL is open to support all kinds
of WebServices and does not only concentrate on specific other

Alex, regarding "... make it difficult for future BPEL standard to support
a richer semantics similar to the type-matching example above without
breaking backward compatibilities.":
When we decide to solve the bug by adding the possibility to catch types,
this will be part of rule 1 and 4. In a future BPEL standard, rule 1 and 4
will still be the first rules which have to be considered first for all
catch blocks. This means a <catch> which catches a type today will catch it
too in the future, because new rules have to be added after rule 1 and 4. I
don't see there any future backwards compatibility problems. Far from it, I
think this strict solution makes it easier to extend that in the future.

Best regards/Mit freundlichen Grüßen,


             "Mark Ford"                                                   
             -endpoints.com>                                            To 
                                       "'Alex Yiu'" <alex.yiu@oracle.com>  
             30.05.2006 06:36                                           cc 
                                       Dieter Koenig1/Germany/IBM@IBMDE,   
                                       Thomas Schulze/Germany/IBM@IBMDE,   
                                       RE: [wsbpel] Issue - 280 -          

The part of the rules that I'm questioning has to do with rule #2 and #5
which cover the single element part WSDL message. Do you read this to say
that the QName for the element comes from the actual element data or the
declaration of the <part element="qname"/> in the WSDL? There are cases
where the QNames could be different. It would be possible to construct a
WSDL message variable and populate it with an element for use with a
<throw> that differed from the element QName in the part description.
Perhaps the element used was part of a substitutionGroup or perhaps it was
simply user error. In either case, I'd like to clarify which QName to use
for the element when matching.

Here's rule #2 with my emphasis:

2.      Otherwise if the fault data is a WSDL message type where the
message contains a single part defined by an element and there exists a
<catch> construct with a matching faultName value that has a faultVariable
whose associated faultElement’s QName matches the QName of the element used
to define the part then the fault is passed to the identified <catch>
construct with the faultVariable initialized to the value in the single
part’s element.

It seems to me that we're driving this match based on the <part
element="qname"/> from the WSDL and not from the element data. If this is
the intent, then it feels a little inconsistent since in the other cases
we're basing the match on the contents of the data as opposed to some
declaration of its type. If this is not the intent, then perhaps this
section could do with a slight rewording to make it more clear?

From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Monday, May 29, 2006 9:35 PM
To: Mark Ford
Cc: 'Dieter Koenig1'; 'Thomas Schulze'; wsbpel@lists.oasis-open.org; Alex
Subject: Re: [wsbpel] Issue - 280 - discussion

Hi Mark,

Hope you had a good long weekend ... :-)

I would like to address your question about "ambiguities" of the last part
of email.

The current rule is clear to me that we are doing an exact QName match.
That is, substitutionGroup is not considered in the <catch> matching logic.

Further elaboration: <catch faultElement="foo:bar"> will catch only faults
that is of either element whose exact QName is "foo:bar" or message type of
single part of element whose exact QName is "foo:bar". And, it will NOT
catch a fault of element "foo:bar2" which is a part of substitutionGroup of

Our current <catch> rule does not touch any XML schema typing issue at all.
If in future we are ready to handle XML schema typing in our <cach>
matching rules, we can for sure consider adding support for
substitutionGroup at <catch> with a switch (that is a 20% usecase).

Back to commenting a bit more on Dieter's proposal: if we had introduced
"faultType", that I would consider it is a 50%~80% of people would expect
type-matching, instead of QName matching. That was also what I mentioned to
Yaron back in Fall 2005. Yaron decided not to deal with the type matching
problem by not introducing the "faultType" attribute in NY F2F (Dec 2005).


Alex Yiu

Mark Ford wrote:
      Does your proposal extend to elements as well? Specifically, should
      declared type of the element variable be considered as opposed to its

      I'm not sure if others have interpreted the rules as I have but my
      is that the Qname of the element content drives the match except in
      the case
      of a single part WSDL message which relies on the declared type.

      Regardless of this issue is resolved, I think we should clarify the
      matching rules to remove an possible ambiguities. For example, what
      happen if I had a schema that used substitutionGroups and threw a
      fault with
      an element within the substitutionGroup? Would the fault matching be
      by the declared type which was the head of the group or by the actual
      which was one of the allowed substitutions?

      -----Original Message-----
      From: Dieter Koenig1 [mailto:dieterkoenig@de.ibm.com]
      Sent: Monday, May 29, 2006 10:00 AM
      To: alex.yiu@oracle.com; Mark Ford
      Cc: Thomas Schulze; wsbpel@lists.oasis-open.org
      Subject: Re: [wsbpel] Issue - 280 - discussion

      Hi Alex and Mark, rules 1 and 4 should take care of both element and
      type by
      means of strict QName matching.

      In other words,
       - when a variable is defined with a type ns:t then it can be caught
      using a
      faultType that specifies the same QName ns:t
       - when a variable is defined with an element ns:e then it can be
      using a faultElement that specifies the same QName ns:e

      This clarification would need to be added to the two rules, and the
      faultType attribute be added to catch.

      Kind Regards

       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


                                             Mark Ford

                   24.05.2006 19:47
                                             Yiu <alex.yiu@oracle.com>

                                             Re: [wsbpel] Issue - 280 -


      [ Changing the subject line ... such the issue list can "correlate"
      email thread ;-) ]

      Currently, there is a set of rules stated in section "12.5 Fault
      to determine which <catch> will be used during fault handling.
      (under "in the case of faults thrown with associated date ...")

      As Mark stated, if we want to support XSD-type (both simple and
      type) in the <catch> clause, we need to modify that set of rules
      significantly. There are 6 rules involved in that set. They are just
      element's QName matching and message type's QName matching there.
      The passed resolution intentionally avoid any type inheritance-based
      checking there.

      If we allow simple-type or complex-type based <catch> clause, it
      would be
      odd to some users, if we don't do any type inheritance-based checking
      (similar to Java catch). If we do inheritance-based checking (e.g. a
      "foo:AddressType" based <catch> can handle a "foo:USAddressType"
      fault), we
      would wander in the territory of "best-match" schema type semantics,
      which I
      am not sure any other spec has done that before.

      If we don't do inheritance-based checking, it may not be that simple
      to resolve all the most appropriate <catch> either. e.g. which one
      will be
      <catch faultType="foo:AddressType">
      vs <catch faultElement="foo:AddressElem"> (where "foo:AddressElem" is
      on "foo:AddressType") vs <catch
      (where "foo:AddressMsgType" has a single part based on

      I am quite sure if we spend enough time, there will be a matching
      developed. But, at the same time, the 80-20 rules applies here. That
      is, we
      may need to double the size of rules (from 6 to 12) for a 20%
      Complexity kills usability.

      Last, it may be too late for this cycle of spec to add such a new
      feature to

      I hope my train of thoughts sound reasonable to you guys.

      Alex Yiu

      Mark Ford wrote:

            I think this issue boils down to how we determine the type of
            the fault
            data. The current matching rules match element data by their
            There is a subtle difference with WSDL Message fault data that
            define a
            single part of type element. In this case, the QName for the
            fault data


            the part's element type declaration as opposed to the actual
            data for
            that part.

            If we add support for type-typed variables, then we need to
            change how
            the type of the fault data is determined. The existing rules


            type of the fault data are insufficient in this regard because
            look only at the element data itself which could be ambiguous


            and elements.

            How do you propose to determine the type of the fault data?

            -----Original Message-----
            From: Thomas Schulze [mailto:ThomasSchulze@de.ibm.com]
            Sent: Tuesday, May 23, 2006 1:32 PM
            To: wsbpel@lists.oasis-open.org
            Subject: [wsbpel] BPEL Issue 280

            BPEL Issue 280 addresses an inconsistency between BPEL's
            <throw> and
            <catch>. While <catch> can only handle message-typed and


            <throw> can additionally throw type-typed data. The proposal is
            to put
            the restriction on <throw> to be able to throw only
            message-typed and
            element-typed data.

            Before doing this, I would like to discuss the other
            allowing <catch> to catch type-typed data.

            The BPEL 2.0 spec builds on WSDL 1.1 which allows to have
            messages with
            multiple parts. These parts can either be element-typed or
            For instance, assume the following WSDL message (from the
            example in section 5.1):

            <wsdl:message name="POMessage">
             <wsdl:part name="customerInfo" type="sns:customerInfoType"/>
             <wsdl:part name="purchaseOrder" type="sns:purchaseOrderType"/>


            Besides i.e. receiving such a message in a message-typed
            variable, you
            can use <fromPart>. This means, you can receive this message in

            <bpel:variable name="CustomerInfo"
            <bpel:variable name="PurchaseOrder"

            <bpel:receive name="ReceivePOMessage" partnerLink="..."
             <bpel:fromPart part="customerInfo" toVariable="CustomerInfo"/>
             <bpel:fromPart part="purchaseOrder"

            Now imagine a process which makes use of only such type-typed
            They never can be thrown when resolving the issue as proposed.
            If a


            of a BPEL process needs to throw such a variable, he is forced


            a new message or element making use of that type and then throw
            message-typed or element-typed variable.

            This problem have already been discussed in Issue 93
            The reasoning for not allowing to catch type-typed data was:
            complex types as faults is vaguely odd and WS-I requires that
            all SOAP
            faults be defined using elements so in general Web Services
            faults are
            typically elements anyway."

            I think WS-I does not apply here, because <throw> and <catch>
            are BPEL
            internal constructs. If a BPEL process should produce a Web
            fault <reply> have to be used. BPEL does not put any
            restrictions on
            replying a fault. So why on throwing a fault?

            Additionally remember chapter 8.1: "The infoset for a complex


            consists of a DII that contains exactly one child, which is an
            referenced by the document element property. ... However the


            document element MUST exclusively consist of the complex type
            assigned to the variable."
            Does that mean that type-typed variables have to be internally
            represented as element-typed? (maybe one of the DII / EII / AII
            / TII
            experts can


            that question) If yes, the catch logic shouldn't differ that
            much from
            the existing when allowing to catch type-typed data.

            I appreciate any comments/further thoughts on this. Tanks in

            Best regards/Mit freundlichen Grüßen,

                  Thomas Schulze


            To unsubscribe from this mail list, you must leave the OASIS TC
            generates this mail.  You may a link to this group and all your
            TCs in




            To unsubscribe from this mail list, you must leave the OASIS TC
            generates this mail.  You may a link to this group and all your
            TCs in



      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

      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

      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]