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

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

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

sylvain.marie

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


Sylvain MARIÉ
Embedded Software Engineer

[hidden email]
+33 (0)4 76 57 67 31 / 34 67 31

Reply | Threaded
Open this post in threaded view
|

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

Bob Freund-Hitachi
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, [hidden email] 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

[hidden email]
+33 (0)4 76 57 67 31 / 34 67 31



smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Doug Davis

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  |  [hidden email]
The more I'm around some people, the more I like my dog.



Bob Freund <[hidden email]>
Sent by: [hidden email]

06/04/2009 07:05 AM

To
[hidden email]
cc
[hidden email], [hidden email]
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, [hidden email] 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

[hidden email]
+33 (0)4 76 57 67 31 / 34 67 31



Reply | Threaded
Open this post in threaded view
|

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

sylvain.marie

> 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

Inactive hide details for Doug Davis <dug@us.ibm.com>Doug Davis <[hidden email]>





A

Bob Freund <[hidden email]>

cc

[hidden email], [hidden email], [hidden email], 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 | [hidden email]
The more I'm around some people, the more I like my dog.

Bob Freund <[hidden email]>
Sent by: [hidden email]

06/04/2009 07:05 AM

To
[hidden email]
cc
[hidden email], [hidden email]
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,
[hidden email] 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

[hidden email]
+33 (0)4 76 57 67 31 / 34 67 31




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


pic10670.gif (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Bob Freund-Hitachi
In reply to this post by Doug Davis
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  |  [hidden email]
The more I'm around some people, the more I like my dog.



Bob Freund <[hidden email]>
Sent by: [hidden email]

06/04/2009 07:05 AM

To
[hidden email]
cc
[hidden email], [hidden email]
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, [hidden email] 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

[hidden email]
+33 (0)4 76 57 67 31 / 34 67 31





smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Doug Davis
In reply to this post by sylvain.marie

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  |  [hidden email]
The more I'm around some people, the more I like my dog.



[hidden email]
Sent by: [hidden email]

06/04/2009 09:41 AM

To
Doug Davis/Raleigh/IBM@IBMUS
cc
[hidden email], Bob Freund <[hidden email]>, [hidden email], [hidden email]
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

Inactive hide details for Doug Davis <dug@us.ibm.com>Doug Davis <[hidden email]>



Doug Davis <[hidden email]>

04/06/2009 14:26



A

Bob Freund <[hidden email]>

cc

[hidden email], [hidden email], [hidden email], 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 | [hidden email]
The more I'm around some people, the more I like my dog.

Bob Freund <[hidden email]>
Sent by: [hidden email]

06/04/2009 07:05 AM


To
[hidden email]
cc
[hidden email], [hidden email]
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,
[hidden email] 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

[hidden email]
+33 (0)4 76 57 67 31 / 34 67 31





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

Reply | Threaded
Open this post in threaded view
|

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

sylvain.marie

> Some implementations allow for SOAP headers to be service specific

Sorry I made a shortcut in my last post. I meant all elements related to the different WS-* standards - as opposed to all business elements defined by the user.

> I consider checking for a valid wsa:Action as a WSA check.

Yes, but this does not require that the driver asks about the service metadata.
For example we use the standard java UnsupportedOperationException, for the business layer to indicate that an invocation of {action, message} is not supported. If WS-Addressing was used for that invocation, the driver will then convert it to an "action Not Supported" fault. this clearly makes the services independent from all proocol-related stuff.
Of course the separation would be different in other langagues...

Sylvain


Sylvain MARIÉ
Embedded Software Engineer

[hidden email]
+33 (0)4 76 57 67 31 / 34 67 31


Inactive hide details for Doug Davis <dug@us.ibm.com>Doug Davis <[hidden email]>





A

Sylvain Marie/FR/Schneider@Europe

cc

[hidden email], Bob Freund <[hidden email]>, [hidden email], [hidden email]

Objet

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


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 | [hidden email]
The more I'm around some people, the more I like my dog.

[hidden email]
Sent by: [hidden email]

06/04/2009 09:41 AM

To
Doug Davis/Raleigh/IBM@IBMUS
cc
[hidden email], Bob Freund <[hidden email]>, [hidden email], [hidden email]
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

Inactive hide details for Doug Davis <dug@us.ibm.com>Doug Davis <[hidden email]>


Doug Davis <[hidden email]>

04/06/2009 14:26


A

Bob Freund <[hidden email]>

cc

[hidden email], [hidden email], [hidden email], 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 | [hidden email]
The more I'm around some people, the more I like my dog.
Bob Freund <[hidden email]>
Sent by: [hidden email]

06/04/2009 07:05 AM

To
[hidden email]
cc
[hidden email], [hidden email]
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,
[hidden email] 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

[hidden email]
+33 (0)4 76 57 67 31 / 34 67 31





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


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


pic08237.gif (1K) Download Attachment