Re: [wsbpel] Issue - 118 - When are Correlation Sets Mandatory?

[Maciej Szefler <mbs@fivesight.com>]

Yaron, 

On Thu, 2004-04-15 at 12:58, ws-bpel issues list editor wrote:

> Normative Change - The schemas for pick and receive make correlation
> sets optional. That would appear to be wrong. 
> 
This change would preclude start activities without a correlation set;
for example if every time I get a message on some port I want to start a
new process but there is nothing unique in the received message (the
operation may have an input message with no unique parts). To make this
more concrete, if I have a process for making pizza's, I might want the
makePizza(toppings) operation start the process. In this case there is
nothing in the makePizza input message to uniquely identify the new
pizza process (topping not being unique), so there is nothing to
initiate a correlation set with.  This is explictly allowed in the spec
in sec 6.5:

	 "If exactly one start activity is expected to instantiate the process,
the use of correlation sets is unconstrained. This includes a pick with
multiple onMessage branches; each such branch can use different
correlation sets or no correlation sets."

Are you of the opinion that such usage should not be permitted?


> Also note, that the WSDL 1.1 spec quite clearly states that
> request/responses do not have to be sent over synchronous transports
> so there may be values we could use for correlation sets. In other
> words, the situation is inconsistent. In some cases a request/response
> uses a synchronous transport and in other cases it could be using an
> asynchronous transport with some message based correlation. Do we want
> to distinguish these cases or do we want to just say that we presume
> that any time a request/response pattern is used there is some
> correlation mechanism implicitly known to the engine and therefore
> correlation sets are always optional on the incoming message? Reply
> the same issue as responses on invokes.
> Changes: 15 Apr 2004 - new issue
The transport being asynchronous is an irrelevant implementation detail
(at least as far as the BPEL language is concerned): the fact that the
operation is declared synchronous means that the transport (not the
engine) has some (transport-specicific) means of matching up the
response to the request. For the simple HTTP case this is simple: the
response is received on the same socket. For an asynchronous transport
like JMS, something like the correlationId property of the JMS message
would need to be used match up the response to the request; the setting
and interperetation of such a property would need to be a feature of the
JMS protocol binding. This applies to both in the invoke case and the
receive/reply case.  

-Maciej