- From: Monica J. Martin <Monica.Martin@Sun.COM>
- Date: Fri, 27 Oct 2006 13:35:03 -0700
- To: Gary Brown <gary@pi4tech.com>
- Cc: Martin Chapman <martin.chapman@oracle.com>, "'WS-Choreography List'" <public-ws-chor@w3.org>
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 Friday, 27 October 2006 20:35:17 UTC