[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 66 - Zero or multiple matches of correlation set
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]