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 - 219 - proposal to vote




Hi,

If we don't use correlationViolation fault here, there will be a number 
of possible faults thrown - subLanguageExecutionFault, selectionFailure, 
incompatibleAssign ... One thing I am trying to avoid here is to ask 
users to catch all these kinds of faults. I can forsee some of 
not-so-hardworking BPEL programmers will just use a <catchAll> to handle 
all these faults instead of having just one <catch> on 
correlationViolation.

And, those XPath used in the propertyAlias are not shown directly in 
that part of BPEL source code. I am afraid that a relatively naive BPEL 
developer will forget all these XPath related faults can happen in a 
<receive> with correlation.

The programmer can still know what real issues are: the 
correlationViolation fault details should expose the root cause. (e.g. 
root cause : selectionFailure : the propertyAlias "/some/xpath" defined 
"/.../../foo.wsdl" points to zero node)

And, I would say having a higher-level fault/exception to hold the 
details of underlying rootCause is very commonly used design pattern (at 
least in Java API world).

See:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Exception.html#Exception(java.lang.Throwable)


I hope that will help explaining my thoughts on this issue.
Thanks!


Regards,
Alex Yiu



Yaron Y. Goland wrote:

> I am uncomfortable with the idea of obscuring a language fault with a 
> correlation violation. The underlying fault is a language fault and 
> for debugging and other purposes that is the fault that the programmer 
> needs to address. As such I believe we should stick with a language 
> fault in the case that a correlation set can't be initiated due to a 
> language error.
>
> In general having a single fault that can cover multiple different 
> fault conditions isn't a great idea. It significantly reduces the 
> value of the fault because the programmer can't be sure what the real 
> issue is.
>
>     Yaron
>
> Alex Yiu wrote:
>
>>
>>
>> -----------------------------------------------------------
>> In section "10.2 Defining and Using Correlation Sets"
>>
>> After the pargraph beginning with "If multiple correlation sets are used
>> in a message activity", add a paragraph:
>>
>> "If an error occurs during executing a propertyAlias used by a
>> correlation set in a message activity, correlationViolation fault MUST
>> be thrown, instead of underlying query language related fault (e.g.
>> selectionFailure)."
>>
>> Enrich the description of "correlationViolation" fault in Appendix A:
>>
>> FROM:
>> "Thrown when the contents of the messages that are processed in an
>> invoke, receive, or reply activity do not match specified correlation
>> information. "
>>
>> TO:
>> "Thrown when the contents of the messages that are processed in an
>> invoke, receive, or reply activity do not match specified correlation
>> information OR when the initiate attribute do not match the state of the
>> correlation information OR when a corresponding propertyAlias fails to
>> execute"
>>
>> -----------------------------------------------------------
>>
>>
>> Regards,
>> Alex Yiu
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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





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