Re: [wsbpel] Issue - 280 - discussion

[Alex Yiu <alex.yiu@oracle.com>]

Mark,

Thanks for the quick reply.

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?

I guess I know where your question comes from.

I would say that is not intent. The intent of rule #2 and #5 is matching by identical element's QName, not matching by some schema type "declaration"+"instance-of" mechanism.

In section 12.5 Fault Handlers, I guess it would be safe for us to say that rule #1 and #4 has the clear intent to match by element's QName only, not by any schema type "declaration"+"instance-of" mechanism.

[See the elaboration paragraph after the 7 rules:

"Matching the type of a faultVariable to fault data as mentioned in points #1 and #4 above is more restrictive than in points #2 and #5. A WSDL message type variable can only match a WSDL message type fault data, while an element variable can only match element based fault data. They match only when their QNames are identical." ]

Rule #2 and #5 is heading to the same direction. Just the text is not "tight" enough to leave holes to create ambiguious cases you mentioned. If I could, I would add the new green text to Rule #2 as follows to plug those "holes":

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 and the QName of the single part of fault data then the fault is passed to the identified <catch> construct with the faultVariable initialized to the value in the single part’s element.

If people like the new text, I would suggest a similar changes to rule #5.:

5.      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 without a faultName attribute that has a faultVariable whose associated faultElement’s QName matches the QName of the element used to define the part and the QName of the single part of fault data then the fault is passed to the identified <catch> construct with the faultVariable initialized to the value in the single part’s element.

Thanks!



Regards,
Alex Yiu


Mark Ford wrote:

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 Yiu
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 "foo:bar".

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

Thanks!



Regards,
Alex Yiu





Mark Ford wrote:

Does your proposal extend to elements as well? Specifically, should the
declared type of the element variable be considered as opposed to its actual
content?

I'm not sure if others have interpreted the rules as I have but my reading
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 fault
matching rules to remove an possible ambiguities. For example, what would
happen if I had a schema that used substitutionGroups and threw a fault with
an element within the substitutionGroup? Would the fault matching be driven
by the declared type which was the head of the group or by the actual data
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 caught
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
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 
                                       Mark Ford                           
             24.05.2006 19:47          <mark.ford@active-endpoints.com>    
                                                                        cc 
                                       Thomas Schulze/Germany/IBM@IBMDE,   
                                       wsbpel@lists.oasis-open.org, Alex   
                                       Yiu <alex.yiu@oracle.com>           
                                                                   Subject 
                                       Re: [wsbpel] Issue - 280 -          
                                       discussion                          
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





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

Currently, there is a set of rules stated in section "12.5 Fault Handlers"
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 complex
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 using
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 either
to resolve all the most appropriate <catch> either. e.g. which one will be
matched?
<catch faultType="foo:AddressType">
vs <catch faultElement="foo:AddressElem"> (where "foo:AddressElem" is based
on "foo:AddressType") vs <catch faultMessageType="foo:AddressMsgType">
(where "foo:AddressMsgType" has a single part based on "foo:AddressType")

I am quite sure if we spend enough time, there will be a matching algorithm
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% usecase?
Complexity kills usability.

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


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


Regards,
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 QNames. 
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 
comes
    

from
  

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 for 
determining
    

the
  

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

types
  

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 element-typed
    

data,
  

<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 opportunity, 
allowing <catch> to catch type-typed data.

Rationale:
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 type-typed. 
For instance, assume the following WSDL message (from the initial 
example in section 5.1):

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

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

<bpel:variable name="CustomerInfo" type="sns:customerInfoType"/> 
<bpel:variable name="PurchaseOrder" type="sns:purchaseOrderType"/>

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

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

modeler
  

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

introduce
  

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

This problem have already been discussed in Issue 93 
(http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue93). 
The reasoning for not allowing to catch type-typed data was: "Throwing 
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 Service 
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 type
    

variable
  

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

the
  

document element MUST exclusively consist of the complex type values 
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
    

answer
  

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 advance!

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
  

at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




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

at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



    

---------------------------------------------------------------------
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
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




---------------------------------------------------------------------
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
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 




---------------------------------------------------------------------
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
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php