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 - 53 - Final end of scopes ( was RE: [wsbpel] Issue 3 -- proposal for discussion)


Yaron Goland wrote:
> Absent the use of enableInstanceCompensation 
> shouldn't it be up to the process itself 
> to decide how long its compensation handlers stay active?

If the process is involved in an economic exchange with trading
partners, the lifetime of compensation handlers may be part of the
agreed-upon rules of exchange.

This also relates to abstract BPEL:  while I agree that it is possible
to mirror one BPEL process in order to design its counterparty process,
in the end, an economic exchange will require both parties to the
exchange to act in concert.  Which means both parties will care whether
lurking compensation handlers can pull the rug out from under their
agreements.  (More below...)

[...]
> Another example is if a process that is handling a purchase order 
> receives a message confirming that the order has been delivered 
> and that the process may not terminate.

The critical points in an economic exchange are order acceptance,
receipt of goods and/or services, and receipt of payment.  Once any one
of those critical points are agreed upon by both parties, compensation
is no longer appropriate, and both parties will want to know that
compensations can no longer fire and undo the agreement.

For example, when an order is accepted, the buyer knows that further
search is unnecessary, and the seller can safely expend resources to
fulfill the order.  I know that current practices in trusting
relationships do not always provide full closure in these interactions
either, but at least they don't hang an automatic undo over the order.

And if full closure is easily and cheaply available, why wouldn't
businesses want it?

[...]
> This is not to say that there isn't a role for 
> explicit coordination protocols, 
> it is simply to argue that providing for support 
> for explicit coordination protocol 
> probably shouldn't be at the top of our stack of priorities.

Of course I am making an argument for an explicit Confirm handler, which
when invoked would disable related Compensations.  It's less than an
explicit coordination protocol, but at least would provide explicit
closure.

Most of the use cases mentioned for BPEL so far involve economic
exchanges between companies.  I think they will want closure, as soon as
they figure out what it means.  But we'll see...

-Bob Haugen


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