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

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

From: Doug Davis <dug@us.ibm.com>
Date: Thu, 4 Jun 2009 09:54:26 -0400
To: sylvain.marie@fr.schneider-electric.com
Cc: antoine.mensch@odonata.fr, Bob Freund <bob.freund@hitachisoftware.com>, public-ws-addressing@w3.org, public-ws-addressing-request@w3.org
Message-ID: <OF9677373C.984FC931-ON852575CB.004B730F-852575CB.004C66FD@us.ibm.com>
It depends on the implementation.  Some implementations allow for SOAP 
headers to be service specific - and that's the case I was thinking of 
when I compared MustUnderstand checking those headers to checking for 
one-wayness. For your implementation choice, I agree that you're in a bit 
of a bind - although, I consider checking for a valid wsa:Action as a WSA 
check.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.



sylvain.marie@fr.schneider-electric.com 
Sent by: public-ws-addressing-request@w3.org
06/04/2009 09:41 AM

To
Doug Davis/Raleigh/IBM@IBMUS
cc
antoine.mensch@odonata.fr, Bob Freund <bob.freund@hitachisoftware.com>, 
public-ws-addressing@w3.org, public-ws-addressing-request@w3.org
Subject
Re: [WS-Addressing] issue concerning reliable One-Way MEP detection






> checking all of the mU headers seems akin to checking the service's 
metadata for one-wayness.

Well although it makes sense, I do not fully agree with this. In my 
opinion the headers relate to the non-fonctional aspect of the service 
(the endpoint's policy, the processing pipe, some ws-* features...) ; 
while the action relates to the business aspect (i.e. it represents the 
operation to invoke in the end). In our implementation the core driver 
only knows the non-fonctional and delegates everything related to the 
functional part to higher layers. It would not be very elegant for the 
driver to ask a service if such or such operation is one way, whereas all 
other MEP and addressing-related stuff is automatically handled...

Best regards,

Sylvain

Doug Davis <dug@us.ibm.com>




Doug Davis <dug@us.ibm.com> 
04/06/2009 14:26



A

Bob Freund <bob.freund@hitachisoftware.com>

cc

antoine.mensch@odonata.fr, public-ws-addressing@w3.org, 
public-ws-addressing-request@w3.org, Sylvain Marie/FR/Schneider@Europe

Objet

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






Maybe but the spec doesn't actually say that. 
However, I think there's another thing that implementations would need to 
worry about. Even in a one-way message should the service be expected to 
return mustUnderstand faults or soap version faults? While its not 
required to, those sure are nice things to return if you can. So in those 
cases I would hope that an HTTP 202 wouldn't be automatically returned 
before these two checks were done - and checking all of the mU headers 
seems akin to checking the service's metadata for one-wayness. 

thanks
-Doug
______________________________________________________
STSM | Standards Architect | IBM Software Group
(919) 254-6905 | IBM 444-6905 | dug@us.ibm.com
The more I'm around some people, the more I like my dog. 

Bob Freund <bob.freund@hitachisoftware.com> 
Sent by: public-ws-addressing-request@w3.org 
06/04/2009 07:05 AM 


To
sylvain.marie@fr.schneider-electric.com 
cc
public-ws-addressing@w3.org, antoine.mensch@odonata.fr 
Subject
Re: [WS-Addressing] issue concerning reliable One-Way MEP detection








I would have thought that a wsa:replyTo element containing the child 
<wsa:Address> http://www.w3.org/2005/08/addressing/none</wsa:Address> 
could be used to infer a one-way message. 
-bob 

On Jun 3, 2009, at 10:05 AM, sylvain.marie@fr.schneider-electric.com 
wrote: 
Hi,

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 

<0F385492.jpg> 
Sylvain MARIÉ
Embedded Software Engineer
sylvain.marie@schneider-electric.com
+33 (0)4 76 57 67 31 / 34 67 31




______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________


picture
(image/gif attachment: 01-part)

picture
(image/gif attachment: 02-part)

picture
(image/gif attachment: 03-part)

picture
(image/gif attachment: 04-part)

picture
(image/gif attachment: 05-part)

picture
(image/gif attachment: 06-part)

picture
(image/gif attachment: 07-part)

picture
(image/gif attachment: 08-part)

picture
(image/gif attachment: 09-part)

picture
(image/gif attachment: 10-part)

picture
(image/gif attachment: 11-part)

picture
(image/gif attachment: 12-part)

Received on Thursday, 4 June 2009 13:55:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 4 June 2009 13:55:17 GMT