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 - 120 - What are the semantics when an initial<receive> has no correlation set?


Ugo,

    A very interesting question. For outbound message exchanges (<invoke>s), could a specific portType/operation be used by separate process definitions? I believe so. Is it reasonable to suppose that the c-set (in and out) would be the same across the multiple definitions?

    The <receive>/<onMessage> case is simpler. I believe that separate process definitions cannot share the same portType/operation.

    This does open up an interesting question, given our correlation model: can we imagine the ability to share correlated <receive> activities that use the same portType/operation., as long as we can guarantee no ambiguity in correlation at run-time? (no correlating to more than one process instance). Just a thought. I'd rather we didn't go there, myself.

-Ron

Ugo Corda wrote:
Message
Ron,
Good point. I think it really depends on how hidden the correlationID is in the case of engine-managed correlation. If the correlationID is only visible, say, at the transport level, there is of course no chance of static analysis. But what if, for instance, the correlationID is declared at the WSDL level (and qualified as such - so I am more thinking in terms of WSDL 2.0). Wouldn't it be something equivalent to the current c-sets?
 
Ugo



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]