Re: Exchange type issue

> Steve Ross-Talbot wrote: I think the BPEL thing is a red herring. We 
> have always been able to  model or describe more than BPEL can handle. 
> Our concept of channel  identity is not supported by BPEL (from 
> memory) and is much richer  than BPEL.
>
> The ability to have a response with not matching request is in-built  
> into WS-CDL and always has been. What we match is not request/ 
> response but send/receive - and interaction. A request and a response  
> can be modeled as two explicit interactions but can, as a  
> convenience, be modeled in a single interaction. If we have them  
> explicit then implementors can choose how to match (usually on  
> operation name) but I do not think this is mandatory. When we have a  
> request and a response in a single interaction the operation names  
> are by definition matched - they share the same operation name.
>
> A notification exchange type makes explicit a pattern which in turn  
> provides clarity of description. It becomes clear as to the intent.  
> And this can only be a good thing. Just because BPEL doesn't support  
> it doesn't mean we should not. Just because many Web Service stacks  
> do not support it does not mean we should not. One day they may well  
> support it and so by supporting what is in the standards and what the  
> wider non-web service community use ensures we achieve one of our  
> goals, namely that we all want WS-CDL to have wider utility than  
> current tools provide today and wider utility outside of a strictly  
> web service environment - hence the optional role interface in WS-CDL.

mm1: I just made an observation to consider in the total scope of our 
discussion, not to create a religious war (for others than myself). As 
far as the exchange type, we need to discuss in detail whether the issue 
is the need for a new exchange type or reconsideration of the semantics 
and constraints of the current 'respond.' I'm anxiously awaiting this 
final observation to be addressed. Thanks.