OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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]