[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)
Hi David, At this time, we have no liaison with the CPPA folks. Would you like to propose the same ? Regards, Rajesh. -----Original Message----- From: David RR Webber - XML ebusiness [mailto:Gnosis_@compuserve.com] Sent: Friday, July 11, 2003 1:28 AM To: Maciej Szefler Cc: wsbpel@lists.oasis-open.org; Eckenfels. Bernd Subject: RE: [wsbpel] invoke/receive-callback race conditions, even in the 1.1 sample (p.22) Maciej, Where this also shows up is the <partner> notion. Its not really a partner - but more a <process-connection>. Calling it partner causes disconnects - since how then do you make it re-usable across different partners - since its clearly just hardwired to one setup?!? And how would you align this with CPPA? We should ask the CPPA folks to comment on that. Do we have a liaison to them? DW. ============================================ Message text written by "Maciej Szefler" > Looking at this problem from the level of the mechanics of SOAP connection is the wrong approach: it ignores a whole layer of infrastructure neccessary to implementing a BPEL engine. You should think of the <receive> operation as an abstract synchronization mechanism between the BPEL process and the protocol adapter to which it is attached (perhaps SOAP, but maybe messaging, maybe CORBA!). If the protocol adapter cannot synchronize within some protocol-specific amount of time, it will send a protocol-level fault to the caller (or not if it is a one way invocation), and the processes would be flagged by the system as having a "adapter synchronization failure". This is exactly what would happen if a <request> / <reply> pair did not occur in the timeframe required by underlying protocol (e.g. if my process takes 1 minute to complete and the HTTP SOAP adapter it's attached to times the session out after only 15 seconds): here the <reply> synchronization between the protocol and process fails, resulting in the same ambiguous condition. It is misleading to suggest that these are "race conditions": this suggests that this is a "bug" in the specification. This is not a specification "bug"; this is simply an issue that the implementation must deal with in a non-naive, non-trivial way (i.e. with a fairly sophisticated guard manager and protocol adapter architecture). -maciej < --------------------------------------------------------------------- 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]