- From: Assaf Arkin <arkin@intalio.com>
- Date: Thu, 22 May 2003 12:18:48 -0700
- To: Ricky Ho <riho@cisco.com>
- CC: public-ws-chor@w3.org
Ricky Ho wrote: > Assaf, > > Can you confirm my understanding from your previous message ? > > When a caller invoke a service (which is implemented in BPEL using > <receive>) and pass-in a transaction context. The caller will receive > a SOAP fault if any of the following happens .... > a) The <receive> is NOT defined within a <scope> Every <receive> is defined within some scope (process = scope) ;-) > b) The <receive> is NOT the first activity of that <scope> AND some > "different" context has already been established. (e.g. There is an > <invoke> preceding this <receive>, or there is another <receive> > preceding this <receive>) This is where the specification becomes ambiguous and could result in potential interoperability issues. There are multiple interpretations that may not all work well with each other. My interpretation: - When you get a message associated with some context you try to find a process that can handle it that is visible in that context. If you have some receive activity that is registered in some other context than it's not visible to you. - If you have no process that can handle the message and the interaction is sychronous, then you need to send back a fault. - If you have no process that can handle the message and the interaction is asyncronous then you let it sit in some queue until it can be delivered. arkin > > > Best regards, > Ricky
Received on Thursday, 22 May 2003 15:55:07 UTC