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 the1.1 sample (p.22)


Yaron Y. Goland wrote:

> <sequence>
>   <invoke operation="initiatePriceCalc" partner="foo"/>
>   <invoke operation="sendShippingPrice" partner="foo"/>
>   <receive operation="sendInvoice" partner="foo"/>
> </sequence>
>
>If all the messages are going to the same partner then the only race
>condition is that partner foo has returned the sendShippingPrice response
>and so now moves on to make the sendInvoice request. But if the process
>hasn't processed the response to sendShippingPrice before foo sends
>sendInvoice then foo will get an error message.
>  
>
While the process performs these activities strictly in serial order, 
there is nothing here to preclude the partner from a) potentially doing 
them in parallel or b) treating them as separate activities (e.g. two 
different processes). In the later case the partner may end up sending 
them in any order.

I actually find this a very natural way to define a process in which the 
understanding of the modeler is:
1. I need response to sendShippingPrice so I can do something with it
2. I need input for sendInvoice so I can do something with it
3. Exact order in which messages are received is not material

 From the perspective of the modeler this is very natural. I may call 
two people (or even the same one) and ask them to fax me some 
information and handle that information in some pre-defined order. If 
one is faster to response, or the same person has some information 
available and needs time to retrieve other information, I may end up 
with the faxes being received in order in which they were produced, 
different from order in which I expect to handle them.

Instead of calling one of them and saying "I'm not ready yet, please 
send later", I would probably put one of them in my inbox until I can 
attend to it.

Rather than write <receive> activities based on the timing in which 
messages may be recieved (low-level) I would expect people to model 
processes using <receive> activities based on the timing in which 
messages are to be processed (high-level). So I find that the 
expectation to have some form of queuing mechanism there to be 
consistent with the natural business-oriented modeling of the process.

arkin

>There are three ways to solve that problem that I can think off:
>	#1 - Put in a queue that will hold messages for a predetermined period to
>see if an operation that can accept them is activated and if not time the
>message out and return an error.
>	#2 - Immediately return an error stating something like "That operation is
>not available yet, please try again later."
>	#3 - Use a signaling system that lets the process send a signal to foo
>confirming that the response to sendShippingPrice has been successfully
>processed and the process is now ready to continue to the next step.
>
>#1 is a combination of a configuration problem (which should probably be
>handled in the WSDL) and an error specification problem which I discussed in
>a previous letter and said BPEL probably needs to solve.
>
>#2 is just the error specification problem I have already discussed.
>
>#3 requires the introduction of a reliable messaging protocol with signaling
>capacity which is outside the scope of BPEL but could certainly be built
>underneath BPEL.
>
>What other solution would you suggest?
>
>		Yaron
>
>
>  
>
>>-----Original Message-----
>>From: Eckenfels. Bernd [mailto:B.Eckenfels@seeburger.de]
>>Sent: Monday, July 07, 2003 11:37 AM
>>To: wsbpel@lists.oasis-open.org
>>Subject: RE: [wsbpel] invoke/receive-callback race conditions, even in
>>the 1.1 sample (p.22)
>>
>>
>>Hello Yaron,
>>
>>for the service provider, who gets an WS invocation, there is no
>>way to know, when he is allowed to answer to that request. In
>>best case he will answer immediatelly after the SOAP call is
>>completed, worst case he wont answer at  all.
>>
>>Asuming the best case: It is not an error for a web service to
>>answer fast. If the web service happens to answer faster than the
>>requestor's engine enabled the next activity, then of course the
>>requested service will get an soap fault like "no correlation,
>>your callback is unexpected".
>>
>>This will most likely confuse the responding service provider,
>>and even more, it will break the process, since the answer is
>>lost. The requestor's receive for the callback will time out,
>>since it was already answered before it was enabled.
>>
>>This is called a race condition, and quite common in programming.
>>For example in java it is a deadly sin to use notify() to wake up
>>an thread, without also setting a boolean flag, to avoid the
>>thread to fall asleep at all. Same situation. In java you have to
>>use synchronized, in BPEL there is no formal way, thats a lack in
>>the spec. There is no atomic operation (specified) which allowd
>>to invoke/receive.
>>
>>Greetings
>>Bernd
>>
>>
>>-----Original Message-----
>>From: Yaron Y. Goland [mailto:ygoland@bea.com]
>>Sent: Monday, July 07, 2003 8:17 PM
>>To: wsbpel@lists.oasis-open.org
>>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
>>>
>>>
>>>      
>>>
>>---------------------------------------------------------------------
>>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
>  
>


-- 
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700


This message is intended only for the use of the Addressee and
may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not the intended recipient, dissemination of this
communication is prohibited. If you have received this communication
in error, please erase all copies of the message and its attachments
and notify us immediately.




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