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] 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]