[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
Ron, I agree that there are possible race conditions that create the "zero case". One can look at this in one of two ways. A BPEL process model gives you a lot of information about what messages you will eventually be interested in, as soon as the correlation set(s) concerned are initialized. This can be used to anticipate interest. Alternatively, one can be optimistic and keep messages *in case* they will be needed by someone in future. In that case I don't know when you can throw them away, so I hope you work for a storage systems manufacturer ;-) In all seriousness, I don't know what specifically we can do to address the "when do I throw away a message when no one has expressed interest but someone might in future" problem, which is how I think you are interpreting the "zero case". If there is enough context (based on the endpoint the message arrived at, headers in the message, the source of the message) to understand which process and instance the message might have been intended for, then a RosettaNet-like error requirement can be satisfied, but that in essence requires process knowledge in the messaging layer, possibly encoded in some kind of ECA rule system. I would say that isn't BPEL territory. Satish -----Original Message----- From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM] Sent: Wednesday, September 24, 2003 11:31 AM To: Satish Thatte Cc: Danny van der Rijn; wsbpel@lists.oasis-open.org 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]