[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] invoke/receive-callback race conditions, even in the 1.1 sample (p.22)
I can't help but wonder if this isn't an issue in error handling. The issue described below seems to specify a case in which someone called an interface before they were supposed to. I can't help but wonder if the correct behavior wouldn't be to return a generic SOAP error saying 'Sorry, that operation isn't currently available.' HTTP had standard errors for this sort of thing. Yaron > -----Original Message----- > From: Francisco Curbera [mailto:curbera@us.ibm.com] > Sent: Monday, July 07, 2003 7:49 AM > To: Eckenfels. Bernd > Cc: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] invoke/receive-callback race conditions, even in > the 1.1 sample (p.22) > > > > > > > Bernd, > > I agree - a crisp statement of your concern will help deal with it. > > Paco > > > > > > "Eckenfels. > > Bernd" To: > <wsbpel@lists.oasis-open.org> > > <B.Eckenfels@seeb cc: > > urger.de> Subject: RE: > [wsbpel] invoke/receive-callback race conditions, even in the 1.1 > sample > (p.22) > > 07/07/2003 10:25 > > AM > > > > > > > > Hello Francisco, > > every abstract programming language has a well defined set of semantics, > especially in the presence of concurrency. For example, if you look at the > java memeory model, there is the requirement, that you cannot (and > therefore must not) asume, that concurrent access to a freshly modified > object works. (Interesed parties might look up the Double Checked Locking > pattern for such an miss asumption). > > The same is true for a sequence. If we want to allow BPEL scripts > to run in > the way the samples shows, then our engines must execute steps in infinite > fast time. This is not a useful requirement for runtime engines and will > result in engines who do ugly hacks to work around the problem (i.e. > waiting while accepting not-found correlation events) or ignore the > problem, which will result in BPEL scripts which suceed on one engine, and > fail on the other. > > I will follow Minicas advice and raise a formal issue here. > > Greetings > Bernd > > > -----Original Message----- > From: Francisco Curbera [mailto:curbera@us.ibm.com] > Sent: Monday, July 07, 2003 3:04 PM > To: Eckenfels. Bernd > Cc: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] invoke/receive-callback race conditions, even in > the 1.1 sample (p.22) > > > > > > > Bernd, > > The meaning of the example you mention is that messages will be sent and > consumed in a particular order. I think it is clear that the specification > must assume that "the runtime engine behaves correct in this situation"; I > don't know what else could be assumed. > > The point you are making seems related to the set of assumptions we are > (implicitly) making about the capabilities of the runtime environment in > which BPEL-e will execute. Any language makes this kind of assumptions, > more or less explicitly; languages become higher level (and more useful) > often by pushing additional capabilities into the runtime. I think we have > to assume that the runtime will be able to cope with things as > simple as an > invoke-receive sequence; otherwise we would make modeling the simplest > message exchange protocol an exercise in concurrent programming - I don't > think we want to go there, but that is just my humble opinion. > > Regards, > > Paco > > This is different from writing a program that will > > > > "Eckenfels. > > Bernd" To: > <wsbpel@lists.oasis-open.org> > > <B.Eckenfels@seeb cc: > > urger.de> Subject: RE: [wsbpel] > invoke/receive-callback race conditions, even in the 1.1 sample (p.22) > > > 07/07/2003 03:55 > > AM > > > > > > > Hello Francico, > > > But, again, it is a statement about the > > implementation environment, not about the correctness or validity of the > > process. > > If common business process modelling asumes, that the runtime engine > behaves correct in this situation (and I dont see a clean way for the > runtime engine to do that), then the process is valid _only_ if the spec > allows this asumption. I dont see any implementation constraints in the > spec, and therefore the sample is highly unreliable. > > Note: possible solutions for fixing this problem in the engine includes: > reordering of activation (receive before invoke), pre-traversal of soon to > be enabled activities to make correlation entries before invoke is > commited, delay negative acceptance of incoming web service requests with > unmatched correlation, till engine signals "stable" state (all activites > activated), ... > > All of them are hard work and not clean, since dealing with timeouts and > making the system less perfomrant. Therefore personally I would vote for a > syntactic regulation, not an implementation constraint. > > Greetings > Bernd > > > "Eckenfels. > > Bernd" To: > <wsbpel@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 > > > > > > > Hello, > > 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.' > > or > > '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. > > Greetings > Bernd > > --------------------------------------------------------------------- > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org > > > > > --------------------------------------------------------------------- > 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]