RE: [wsbpel] invoke/receive-callback race conditions, even in the 1.1 sample (p.22)

[David RR Webber - XML ebusiness <Gnosis_@compuserve.com>]

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

<