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


I would also point out that fault/exception encapsulation is all well 
and good when you have an encapsulation mechanism. We do not.

	Yaron

Prasad Yendluri wrote:
> 
> 
> 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
>  >
>  >
>  >
> 



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