|Eckenfels. Bernd||Jul 4, 2003 8:42 am|
|Frank Leymann||Jul 5, 2003 9:25 am|
|Eckenfels. Bernd||Jul 6, 2003 8:14 am|
|Francisco Curbera||Jul 6, 2003 5:50 pm|
|Eckenfels. Bernd||Jul 7, 2003 12:41 am|
|Francisco Curbera||Jul 7, 2003 5:47 am|
|Monica J. Martin||Jul 7, 2003 6:05 am|
|Eckenfels. Bernd||Jul 7, 2003 7:11 am|
|Francisco Curbera||Jul 7, 2003 7:32 am|
|Yaron Y. Goland||Jul 7, 2003 11:00 am|
|Eckenfels. Bernd||Jul 7, 2003 11:22 am|
|Yaron Y. Goland||Jul 9, 2003 10:33 am|
|Assaf Arkin||Jul 9, 2003 10:52 am|
|Eckenfels. Bernd||Jul 10, 2003 2:46 am|
|Maciej Szefler||Jul 10, 2003 12:20 pm|
|David RR Webber - XML ebusiness||Jul 10, 2003 12:45 pm|
|Rajesh Pradhan||Jul 11, 2003 5:20 am|
|David RR Webber - XML ebusiness||Jul 11, 2003 12:12 pm|
|Subject:||Re: [wsbpel] invoke/receive-callback race conditions, even in the 1.1sample (p.22)|
|From:||Francisco Curbera (curb...@us.ibm.com)|
|Date:||Jul 6, 2003 5:50:17 pm|
Unless I am missing something, I think there is a misconception on what the process in page 22 (and any BPEL process for that matter) means. Each one of the invokes is a one way operation. There is no "reply" associated with those operations; they complete as soon as the message is sent. From the "public protocol" point of view as defined by the BPEL process, however, the statement being made is that the invoice will not be received before the two first messages have been sent. The problem you raise is thus an implementation issue and not a problem with the process specification (which is quite clear): it may be the case that IF the implementing engine is sufficiently slow AND its messaging infrastructure doesn't enqueue messages, THEN the "invoice" message MAY be lost. That would certainly be possible: it would be a really lousy implementation of a perfectly correct process specification. But, again, it is a statement about the implementation environment, not about the correctness or validity of the process.
"Eckenfels. Bernd" To: <wsb...@lists.oasis-open.org> <B.Eckenfels@seeb cc: urger.de> Subject: [wsbpel] invoke/receive-callback race conditions, even in the 1.1 sample (p.22)
07/04/2003 11:56 AM
in the 1.1 spec, there is a sample on p.22 featuring call back ports for the result of price calculation. This sample suffers from a possible race condition:
<sequence> <invoke operation="initiatePriceCalc" /> <invoke operation="sendShippingPrice" /> <receive operation="sendInvoice" /> </sequence>
In this sample, requesting a invoice by Purchase Order, the second invoke adding shipping infos, and the reply waiting for the calculated invoice. So depending on the runtime engine, the receive activity might not get activated before the response is already received. Besides the fact, that this sample is not dealing with correlations, it might be rewritten as:
<flow> <receive /> <sequence> <invoke /> <invoke /> </sequence>
But this still is open for a race condition (as the activation sequence of a flow is undefined).
So, we beed to address two issues here:
a) is it required for the enactment service to support receives which are depending (by link or sequence) on the completion of invokes. If yes, how deep this dependency should be allowed. If it is not required for the enactment, then the sample is illegally constructed.
b) if we do not allow the sequencing and declare the sample as broken, then an alternative notation with a flow may be used, but also requires some sematic definitions:
'flows are activated top down, this meens if a receive activity in a flow is before the invoke (with no links), then engines have to gurantee, that the corellation entry is made before the service is invoked.'
'flows are activated, so that all ready receicves are invoked before ready invokes.'
We have the problem, that we can't use links to express a relationship like "if the receive has established the orrelation entry, then invoke". The other problem is, that my proposed regulation for flow does not help with receives, which are not directly nested below the flow. For example a
<flow> <sequence> <receive /> .. </sequence> <invoke> </flow>
does not reliable work with the "first all receive" nor with the "top down activation" definition.
I started this discussion, to ensure my understanding of the situation is correct. If you agree, I will raise a formal issue.
Note: this is also reláted to issue 31, because generating a UUID is a requirement for the b) solution.