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 190 - BPEL Internal Faults (New Proposed IssueAnnouncement)



Hi Satish,

I guess one of the differences we are still having is:
Whether "convert-an-exist-to-a-fault-and-proceed" is one of the supported normative behavior.

To me, Issue 190 should be more about adding choices on how a BPEL implementation reacts to a BPEL Standard fault/failure, NOT changing / disallowing existing behavior:
  1. fault-and-proceed: the current semantics and BPEL 1.1 behavior
  2. exit-with-fault-data: one more choices of normative behavior
  3. other implementation reaction: e.g.: repair either data or process definition and proceed
To me, item (1) and (2) should be both specified and allowed by spec. And, of course (3) would be out of scope for this spec.

The key point is: the spec should provide a reasonably backward-compatible path / choice for existing BPEL 1.1 style process to migrate to BPEL 2.0 for this such a high impact issue, if those process definition happens to allow compensation after certain BPEL standard fault. (We are not just talking about minor keyword and syntax renaming.) If we drop item (1) from the spec, then there will be no spec / standard way to continue BPEL 1.1 behavior, which can be very useful in a number of cases.

That is why the tone of the issue description needs to be clearly spelled out in writing, before we proceed with "is-this-a-bug" vote.


Thanks!


Regards,
Alex Yiu



Satish Thatte wrote:

The only substantive difference between what Dieter originally suggested and my subsequent embellishment is that I suggested we allow “exit” (formerly terminate) to carry fault-like data and then treat all current “internal” faults (except joinFailure) as exits (as Dieter suggested) but with such data.  This allows engines dealing with such exited aka frozen process instances to privately support notions such as “convert an exit to a fault and proceed” or “repair process and continue”.

 


From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Monday, February 14, 2005 12:58 PM
To: Alex Yiu
Cc: Satish Thatte; ygoland@bea.com; Francisco Curbera; Prasad Yendluri; Danny van der Rijn; wsbpel@lists.oasis-open.org; alex.yiu@oracle.com
Subject: Re: [wsbpel] Issue 190 - BPEL Internal Faults (New Proposed Issue Announcement)

 


Hi

Just want to make it clearer for our standardization process:

Since the current tone projected by Satish and Paco are quite different from the one first described by Dieter, I think we need to a restated issue description in writing first for Issue 190. Then, we can decide and vote whether it is a feature or a bug to the spec.

After/if the issue is opened, we need to have a new proposal with exact wordings to vote on.

Thanks.

Regards,
Alex Yiu


Alex Yiu wrote:


Great.
Then, it seems to me that we are converging.
What we need now is a new proposal with exact wordings and clear description of the new semantics.

Thanks.

Regards,
Alex Yiu


Satish Thatte wrote:

If I understand your first question correctly, that was my notion of the convert-terminate-to-fault-and-continue behavior.  And then yes, the failure could be capped to a scope, since the "modeling" fault at that point will be treated like any other ordinary fault.
 
________________________________
 
From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Fri 2/11/2005 11:49 AM
To: Satish Thatte
Cc: ygoland@bea.com; Francisco Curbera; Prasad Yendluri; Danny van der Rijn; wsbpel@lists.oasis-open.org; alex.yiu@oracle.com
Subject: Re: [wsbpel] Issue 190 - BPEL Internal Faults (New Proposed Issue Announcement)
 
 
 
 
Hi, Satish,
 
I guess I undestand you point ...
 
More questions: Say:
If we don't call it "fault", after the process is "freezed" ...
and after user-inspection, he/she consider the fault should not affect
the compensation logic,  can the user select the action to activate a
fault handler of a related scope which does the compensation logic and
marked the scope faulted and continue rest of the process?
 
It is important to cap the system failure to one of child scopes, not
the whole process, for fault-tolerant design [ Oh my ..... the term
"fault" comes again ... do we really want to avoid that term? ]
 
Thinking out loud again: maybe we should still call them as fault and
have a clear explanation on how system failure will be handled
differently from an application fault?
 
 
Regards,
Alex Yiu
 



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