- From: Gary Brown <gary@pi4tech.com>
- Date: Sat, 28 Oct 2006 16:55:21 +0100
- 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. Regards Gary 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