RE: [wsbpel] RE: Questions (RE: [wsbpel] Proposed agenda for May 28-29 WS BPEL TC face to face)

["Satish Thatte" <satisht@microsoft.com>]

Assaf,

I am wondering how common these cases are (you didn't actually provide
use cases ;-)).  The once-only case seems to have easy workarounds given
parameters for compensation handlers.  Concurrency is something to think
about more but I wonder how important it will really be in practice - my
personal belief is that concurrency in BPEL is more about
non-deterministic ordering rather than leveraging multiproc servers and
the like, and this becomes important especially for wait points.  What
do you see as being the essential need for concurrency in compensation
in practice?  

Satish

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com] 
Sent: Tuesday, June 03, 2003 4:24 PM
To: Satish Thatte
Cc: edwink@collaxa.com; wsbpel@lists.oasis-open.org; Diane Jordan
Subject: Re: [wsbpel] RE: Questions (RE: [wsbpel] Proposed agenda for
May 28-29 WS BPEL TC face to face)

Satish Thatte wrote:

> Aspect#1: Assuming a session based communication protocol and 
> WS-Addressing as a way of initiating the session using some form of 
> handle explicit correlation might eventually become unnecessary. We 
> should work out the details of what it would take to get this 
> simplification. However, in general we probably cannot assume 
> session-based communication. There are scenarios like multi-start 
> activities (example in spec) where correlation is not avoidable.
>
> Aspect#2: This seems to relate to multi-start activities. There is no 
> "ghost instance" semantics here, but there is rendezvous semantics. 
> The idea is to make the expression of rendezvous easy, but that does 
> mean more work for the infrastructure (effectively providing the 
> service you mention as an implicit part of the bus).
>
> Aspect#3&4&8: In my book, the items you mention are deployment related

> and not in scope for BPEL.
>
> Aspect#5: I believe this type of binding is ruled out by the charter.
>
> Aspect#6: I agree this type of pattern is a requirement.
>
> Aspect#7: I am not aware of any use cases where other-than-reverse 
> order is needed for compensating looped activities. Do you know of 
> such a case?
>
We did identify two cases.

The looped activity may execute zero or more times, but in some cases it

is sufficient to compensate for it exactly once. If you compensate for 
all instances then you are doing too much work. The compensation handler

cannot determine how many times it was executed since it has no access 
to shared variables, so it cannot narrow down the workload. If you put 
the compensation code outside the looped activity you additional logic 
to determine whether or not it even executed successfully.

An event handler may execute multiple instances in parallel. In some 
cases you may be able to invoke compensation handlers in parallel, which

may render compenstion more efficient. In some cases you may also be 
able to do that for a looped activity.

Perhaps we should allow a compensation handler to specify whether it 
supports concurrency and based on that have the engine execute it in 
parallel with or sequential to other compensation handlers.

Other than 'once only' or 'any order' we have not found a need to do 
anything other than reverse order.

arkin

> Satish
>