W3C home > Mailing lists > Public > public-ws-chor@w3.org > October 2006

Re: Clarifying exchange type

From: Gary Brown <gary@pi4tech.com>
Date: Sat, 28 Oct 2006 16:55:21 +0100
Message-ID: <45437D69.2080502@pi4tech.com>
To: "Monica J. Martin" <Monica.Martin@Sun.COM>
CC: Martin Chapman <martin.chapman@oracle.com>, 'WS-Choreography List' <public-ws-chor@w3.org>

Hi Monica

Definitely a subject for debate at the next conf call.

I think the issue is that the spec is ambiguous in terms of usage of the 
request and respond actions related to an exchange. The only constraint 
at the moment is that there can only be a single non-fault exchange, 
with action=Respond, in the same interaction activity as an associated 
request exchange.

It does not however indicate whether two or more interaction activities 
could each have an exchange (with action=respond and no fault name), 
which would imply a request has more than one normal response.

Therefore the change I am proposing is designed to clarify the 
situations and enable more stringent validation to be applied. I think 
if we take the other route, which would be to constrain CDL only to deal 
with the request-only and request/response MEPs, this would be a big 
mistake. However, if this route was taken, it would still require 
clarifications in the spec to prevent the situation I have outlined.

The benefits of CDL are more widely applicable than just the current 
limited world of web services. Whether or not WSDL2, WS-Notifications 
etc will take off, they show that distributed systems require more, and 
they are trying to meet those requirements. I think it is therefore 
important for us to address those requirements in CDL, and at a tool 
level deal with runtime limitations, depending upon the runtime 
environment within which the choreography is being applied.


Monica J. Martin wrote:
> Gary Brown wrote:
>> Hi Monica,
>> The ability to define notifications has been in the spec from day 
>> one. It is simply a case of defining an interaction that has just a 
>> 'Respond' exchange in it with no preceding 'Request' exchange (in the 
>> same or any other interaction activity).
>> The new 'Notify' exchange type that I am suggesting would not require 
>> any new semantics, as it is so similar to the 'Respond' exchange, 
>> although it does enable us to tighten up the semantics around the 
>> 'Respond' exchange, to enable static validation to ensure that there 
>> is a matching 'Request' exchange, which is currently not possible,
> mm1: I agree we have a Respond exchange; however we may differ on 
> whether or not this is a Notify.  Granted it may be similar to 
> Respond; it may be Respond or, in other cases, its meaning may be very 
> different from Respond. Perhaps this is a case to consider whether a 
> Respond exchange is capable of specifying a Request match rather than 
> differentiating with a Notify. I have opted not to explain the 
> business level differences of a response or notify, as this has 
> historically been outside of this WG scope.
>> So basically, at the moment it is possible to define notifications as 
>> well as responses, but a CDL description may define these so they are 
>> ambiguous and there is no way to statically validate whether they are 
>> correct. This change would also be advantageous in a Web Services 
>> deployment, as it clearly indicates whether WS notifications is 
>> required, and if not available would enable an organisation to 
>> understand that the CDL could not be implemented.
> mm1: It appears that what you are asking for are more functions around 
> what Respond may be. Thanks.
Received on Saturday, 28 October 2006 15:55:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:37 UTC