Re: [wsbpel] Issue - 219 - proposal to vote

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

Prasad,

First of all, I hope most people would recognize that fault/exception 
encapsulation is a valid design pattern.

The question is when to apply this fault encapsulation concept vs when 
to keep the original faults.

In this case, I still tend to think it is beneficial to users to apply 
fault encapsulation here, especially in the light of engine-managed 
correlation.

That is, the same kind of correlationViolation fault should be thrown, 
regardless whether the engine-managed correlation header is mal-formed 
or the xpath in propertyAlias selection points to zero node in message 
payload.


I hope this may convince you better.
Thanks!


Regards,
Alex Yiu



Prasad Yendluri wrote:

> Alex,
>
> I don't think we should try and add smart semantics to the fundamental 
> error condition that caused the fault. The fault could be caused by a 
> bug in the language processor that was exposed by a specific (complex 
> :) XPath expression that is involved. By requiring an override to 
> throw the correlationViolation fault we could be creating a debug 
> nightmare. I think we should let the fault that corresponds to the 
> problem recognized  be thrown in this case.  I have learnt to put 
> additional catch blocks, when I ran into the fault that was not 
> necessarily declared. Saving couple of catch blocks is not worth it in 
> this case. Perhaps we can add a caution that indicates multiple fault 
> conditions are possible rather than convert into a different fault by 
> a ruling in the spec.
>
> Regards, Prasad
>
> Alex Yiu wrote:
>
>> 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