W3C home > Mailing lists > Public > public-ws-addressing@w3.org > June 2009

[WS-Addressing] issue concerning reliable One-Way MEP detection

From: <sylvain.marie@fr.schneider-electric.com>
Date: Wed, 3 Jun 2009 16:05:49 +0200
To: public-ws-addressing@w3.org
Cc: antoine.mensch@odonata.fr
Message-ID: <OFDD922989.E8F3A6B0-ONC12575CA.003A073F-C12575CA.004D7002@schneider-electric.com>


I have been working for the fast few years on Devices Profile for Web
Services (DPWS) specification, and especially on an implementation
(https://forge.soa4d.org/). DPWS 1.0 was originally referring to WSA
member's submission, while DPWS 1.1 specification has now moved to
WS-Addressing 1.0.

WS-Addressing specifies how messages corresponding to different Message
Exchange Patterns (MEP) are sent. However it does not seem to specify a
reliable way to detect which MEP is actually in use. In particular the
One-Way MEP may not be detected reliably, which prevents devices to make
any optimisation (for example, send the empty HTTP response for SOAP/HTTP
binding). The only alternative is to inspect the actionUri and refer to a
service's WSDL in order to retrieve the appropriate MEP.

In DPWS implementations we think that the driver should be able to
implement the default processing chain without necessary knowing about the
web services deployed on top of it. We first thought about using the
absence of "replyTo" as a good indicator for a One-Way MEP but since
WS-Addressing 1.0 this does not work any more, as replyTo always have a
default value ("anonymous"). No we are thinking about using the absence of
"messageId" as a clue to detectt One-Way MEPs but this is clearly a hack
and not something we may rely on in he future.

What is the opinion of WS-Addressing's WG about this ? Thank you very much
in advance,

Best regards,


                   Sylvain MARIÉ                        
                   Embedded Software Engineer           
                   +33 (0)4 76 57 67 31 / 34 67 31      

(image/jpeg attachment: 0F385492.jpg)

Received on Thursday, 4 June 2009 10:30:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:18 UTC