atom feed18 messages in org.oasis-open.lists.wsbpelRE: [wsbpel] invoke/receive-callback ...
FromSent OnAttachments
Eckenfels. BerndJul 4, 2003 8:42 am 
Frank LeymannJul 5, 2003 9:25 am 
Eckenfels. BerndJul 6, 2003 8:14 am 
Francisco CurberaJul 6, 2003 5:50 pm 
Eckenfels. BerndJul 7, 2003 12:41 am 
Francisco CurberaJul 7, 2003 5:47 am 
Monica J. MartinJul 7, 2003 6:05 am 
Eckenfels. BerndJul 7, 2003 7:11 am 
Francisco CurberaJul 7, 2003 7:32 am 
Yaron Y. GolandJul 7, 2003 11:00 am 
Eckenfels. BerndJul 7, 2003 11:22 am 
Yaron Y. GolandJul 9, 2003 10:33 am 
Assaf ArkinJul 9, 2003 10:52 am 
Eckenfels. BerndJul 10, 2003 2:46 am 
Maciej SzeflerJul 10, 2003 12:20 pm 
David RR Webber - XML ebusinessJul 10, 2003 12:45 pm 
Rajesh PradhanJul 11, 2003 5:20 am 
David RR Webber - XML ebusinessJul 11, 2003 12:12 pm 
Subject:RE: [wsbpel] invoke/receive-callback race conditions, even in the 1.1 sample (p.22)
From:Eckenfels. Bernd (B.Ec@seeburger.de)
Date:Jul 6, 2003 8:14:41 am
List:org.oasis-open.lists.wsbpel

Hello Frank,

[ your explanation about sequence and flow and asumptions allowed ]

My point was, that with the currently specified behaviour of runtime engines, it is not possible to model the callback scenario, as described in the 1.1 BPEL spec.

It contains a sample, where ones does invoke a invoice creation service with 2 sets of info, and the service will call back. it is modelled as a sequence at the invoker side, and this is simply not reliable. My suggestion to use a flow instead would make it a bit more reliable, but still it depends on unwritten runtime engine behaviour.

So my point is: there is a lack of sematics specification. If we accept this, we must not show examples which depend on it.

Greetings Bernd