More on wsa:To

Mark replies to my recent missive. Regarding the value of wsa:To itself, apparently Mark's concern is:

 

    "…that the spec didn't require that the address go in the appropriate place in the application protocol."

 

I really don't see how WS-Addressing can specify this given that the spec itself doesn't know anything about the underlying protocols that might be used to move around SOAP messages containing wsa:* headers. And even if the WG were tasked with providing normative bindings for, say, HTTP, SMTP, TCP and UDP, the value of the wsa:To may or may not make sense for one or more of those protocols.

 

Now, in *many* cases, the value of the wsa:To will be an HTTP URI. And the SOAP message containing that wsa:To will be transmitted using HTTP. And the HTTP request URI and Hostname: header will be taken from that HTTP URI. And DNS will be used to resolve the hostname from that HTTP URI to an IP address. I believe that at least one of our SOAP stacks works this way by default. But *many* is not *all*. And I see cases where the value of the wsa:Address element in an EPR is mapped to an application or transport protocol address by some configuration information in the system.

 

Mark asks me to consider the difference between application and transport protocols;

 

    "Please, please, please Gudge, take some time out to carefully consider that application protocols are very, very, different beasts than transport protocols"

 

Now, I think I have some idea of the difference between the two, although I'm obviously no expert; transport protocols just move bits around without any regard to what those bits are, whereas application protocols, while still moving bits around, care somewhat about what those bits look like. But in a SOAP world, it seems to me that SOAP is the application protocol ( it's the bit that cares what the messages look like ) and everything 'underneath', if I can use such a term, is just a way of moving messages around. So while I grant you that from the perspective of someone writing an SMTP server, there is a significant difference between TCP and SMTP, from the perspective of someone writing a SOAP application the difference is not particularly important.

 

I'm not quite sure what Mark is getting at when he talks about RPC;

 

    "If you've come from an RPC background (which I believe you have), there is simply no analogue for an application protocol in RPC architectures."

 

My background is first of all in messaging, then in DCE RPC and COM, then messaging and queuing, then SOAP (which I consider to be XML messaging). So while I've certainly worked with RPC systems, my guess is that if I sat down and worked out the actual numbers, I've spent more time working with messaging systems. I don't know whether that means I come from an RPC background or not…

 

Regarding my third point, Mark had this to say;

 

    "…acceptance of the issue is, for me, the only win I'm interested in. I don't really care how it's resolved."

 

It seems somewhat odd, to me, to raise an issue and then not care about the outcome. Like shooting for a basketball hoop but then immediately leaving the court, without caring whether the shot went in or not. I guess this means that if the TAG decide that the decision made by the WS-Addressing WG was OK, then Mark won't push back. I wonder why he didn't extend the same courtesy to the WS-Addressing WG? If the WG had accepted the issue, debated it for a few weeks and then closed it with no action, would that have been somehow different, perhaps?