Based on the discussion in the last conference call, regarding support for some or all of the MEPs in WSDL2.0, I don't understand why there needs to be a restriction on an interaction to just handle request-response and one-way MEPs.

If an interaction was to simply denote a single message exchange, then it would be possible for CDL to model any form of MEP, as well as request-response-or-fault situations that currently cannot be modelled with the current interaction.

The reason given on the conference call was that a request/response pair needed to be defined in a single 'interaction' due to the concrete grounding that an interaction represents. However, this grounding can be inferred from the binding to an appropriate WSDL operation.

For example, if we imagine three roles (A,B,C), where A performed a synchronous request/response op on B (i.e. buy), but to achieve this operation, B needs to communicate with C (i.e. performCreditCheck), we have:

<sequence>
	<interaction role="AB" fromRole="A" toRole="B" operation="buy" >
		<exchange action="request" .... />
	</interaction>
	<interaction role="BC" fromRole="B" toRole="C" operation="performCreditCheck" >
		<exchange action="request" .... />
		<exchange action="response" .... />
	</interaction>
	<interaction role="AB" fromRole="A" toRole="B" operation="buy" >
		<exchange action="response" .... />
	</interaction>
</sequence>

If an interaction is restricted to having to represent a request-response MEP as a single interaction, then CDL will be limited in the types of business protocol that can be modelled. Although a "work-around" could be to model the response as a one-way on an interface provided by role A, in some cases we may not be in a position to dictate how the business protocol is implemented by the WSDL interfaces (e.g. in cases where a web service already exists).

I believe that it would be possible to postpone the mapping/grounding of interaction (requests/responses) until the spec is parsed against a particular binding, at which point, it would be possible to infer that the operation 'buy' is a request-response, and therefore a valid CDL specification must have a response following the request.

This also means that all possible MEPs in WSDL 2 could be supported (i.e. the current set plus any others defined in the future), as the CDL spec is not imposing any restrictions on how request and response messages are grouped. This is only performed as part of validating that the CDL specification correctly conforms to the groundings/semantics defined by the concrete bound interface definitions.

To extend this example, we could then handle request-response-or-fault situations in the following manner:

<sequence>
	<interaction role="AB" fromRole="A" toRole="B" operation="buy" >
		<exchange action="request" .... />
	</interaction>
	<interaction role="BC" fromRole="B" toRole="C" operation="performCreditCheck" >
		<exchange action="request" .... />
		<exchange action="response" .... />
	</interaction>
	<choice>
		<interaction role="AB" fromRole="A" toRole="B" operation="buy" >
			<exchange action="response" .... />
		</interaction>
		<interaction role="AB" fromRole="A" toRole="B" operation="buy" fault="InvalidCredit" >
			<exchange action="fault" .... />	
		</interaction>
	</choice>
</sequence>