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

Doug,

The spec does not indicate in any explicit way how to interpret  
addressing headers to determine the message exchange pattern.

We went though the whole discussion, perhaps it was before you began  
participating after CR, that there really is no such thing as a one- 
way message when the possibility of faults are considered since a  
fault IS a response.

If what is intended is a true one-way, then none of those faults would  
be returned, but most folks really talk about an application one-way  
where faults returned from addressing or perhaps SOAP or any other  
lower lying layer would be returned by that layer.

So a premature 202 should not block a 500 nor should a mU fault block  
an http or lower level transport error.  Those lower levels are  
insensible to EPRs

-bob


"On Jun 4, 2009, at 8:26 AM, Doug Davis wrote:

>
> 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
>
>
>