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] RE: Questions (RE: [wsbpel] Proposed agenda for May28-29 WS BPEL TC face to face)


Satish Thatte wrote:

>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?  
>  
>
The two use cases I have listed are the only ones we came across that 
justified something other than reverse order. Even these are quite rare, 
so I would prefer to solve them with the least amount of changes to the 
language. I am actually confirming your statement that there's no need 
to significantly complicate the compensation mechanism by selecting a 
compensation order. I have not encountered a use case, even a 
hypothetical one, that would justify that or could not be solved in some 
other way.

For the once-only case, passing parameters to the compensation handler 
would probably work. It may require a bit more logic in the compensation 
handler, but since the case is not very common I find it an acceptable 
solution.

As for doing things in concurrent, I would not rule out the ability to 
do things in parallel in order to shorten the completion time of the 
process. Taking advantage of multiproc servers is a benefit but I'm not 
sure if it would make any difference. However, some activities involve 
human intervention, with humans being non-scalable and not very 
deterministic resources. So the request we've had was to be able to 
involve different users concurrently in both normal activities and 
compensation activities.

The work around may be to start some process asynchronously from the 
compensation handler, so the compensation handler finishes almost 
immediately while compensation work is going on in the background. 
However, this does not allow you to wait for all compensations to 
complete. I guess we would see more use cases emerge when we add the 
ability to perform an activity n times in parallel and cancel ongoing 
activities when a critical number of activities complete.

arkin

>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
>>
>>    
>>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>  
>




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