FW: Message Dispatching Primer Section

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

FW: Message Dispatching Primer Section

Jonathan Marsh-2

Thank you for this comment.  The Working Group this issue as a CR127 [1].

The Working Group closed this issue as a duplicate of CR134 [2], which added
a paragraph to the primer addressing this issue.  You can see the resolution
implemented in the latest editor's draft [3].

Unless you let us know otherwise within two weeks, we will assume you agree
with the resolution of these issues.

[1] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR127
[2] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR134

Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Youenn Fablet
Sent: Wednesday, December 13, 2006 5:43 AM
To: www-ws-desc
Subject: Message Dispatching Primer Section

Reading section 5.1 in the primer, it is written that assigning unique
QNames of GED as inputs within the interface of the service is
sufficient to disambiguate the types of the messages that are received.

While this is certainly true for a typical SOAP service that uses the
Request/Response mep, this is not the case when the SOAP/Response mep is
In that case, the GED QName is not sent in the message, only the
subchildren local names are sent in the url.
It would be easy to have two different GED QNames with the same
subchildren local names.
I do not know whether we should improve the primer, but this might be
worth noting it anyway.

The same kind of issue also arises with the HTTP binding.
In this case, the dispatching may be done according the url, the method,
the content-type and possibly other bits of information.
This flexibility is good if we are going from a service to a WSDL document.
In a typical WSDL first situation, it may however be hard for authors
and tools to check that message dispatching will never be ambiguous.
A few guidelines may help with that respect.

Any thoughts?