Re: [wsbpel] Issue - 66 - Zero or multiple matches of correlation set

[Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM>]

Satish Thatte wrote:

>BPEL operational semantics only applies to the behavior of a single
>process instance.  The mechanics and policies of the messaging layer are
>clearly out of scope.
>
While this is true, it isn't the whole story. BPEL makes behavioural 
assumptions about the messaging service. Should we attempt to make these 
explicit, as an aid to interoperability/portability, which are in our 
scope? Or is the current wording sufficient? This may be an issue for 
the new wsbpel-implement group to take up.

>That said, correlation is a declarative way of declaring the
>conversation keys used by a single instance, and hence it has
>implications for the routing behavior at the web service messaging
>layer.  Conversation keys ought to be unique, i.e., if they match that
>should be by design.  If uniqueness is violated inadvertently this is a
>bug, and I don't think we can arbitrate the behavior in the presence of
>application bugs!
>
Agreed. We should avoid "optimising the error case" unless the 
consequences of the error are catastrophic. For most (all?) BPEL use 
cases, this clearly isn't so. I'm not going to use a BPEL engine to 
control a nuclear reactor! :-)

>
>As for the "zero" case, this refers to a message that arrives when no
>one is interested - web service messaging spam.  Possibly part of a
>denial of service attack.  I don't understand why BPEL should deal with
>this issue.
>
Such a message isn't necessarily spam; it could be part of a race 
condition. (A sequence with send ... receive, where the response arrives 
before the receive is activated). There was a thread about this a couple 
of months ago, IIRC. I believe Collaxa has already addressed such 
concerns in their product, but it does mean that one cannot simply throw 
away such messages.

I believe you were referring to a slightly different case: 
uncorrelatable (is there such a word?) messages that are received. Such 
a condition would imply that no process instance exists which would ever 
be interested in the message, so then it could be safely placed in the 
messaging system's dead-letter queue or equivalent. There may be a minor 
issue here concerning order of operations within a BPEL engine, to 
ensure that correlation sets are properly commited to the PI's state 
before sending a (asynchronous) message where we depend on those sets to 
route the response back the the PI. It seems an obvious problem that any 
implementor would address properly, but it may be worth a sentence or 
two to make the intent of the spec explicit. (It may be more complex 
when users do cute things like have the send and receive activities run 
concurrently in a flow.)

Cheers,
-Ron