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

[Prasad Yendluri <pyendluri@webmethods.com>]

Hi Alex,

I understood what you are proposing. I am not convinced that this is a 
good approach here.
IMO a simple cautionary note is better solution here than an 
encapsulation of all possible faults (here) into something different.

Regards, Prasad

Alex Yiu wrote:

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