Justin complains that no one has commented or answered his comments on WS-Addressing. Since some of his comments are directly addressed to me, I think it's only fair to respond :)
I've been looking into WS-Addressing, too, trying to understand the whole thing. I haven't quite contemplated all scenarios, but I think Justin's comments make a lot of sense, overall. I've got my own thoughts on WS-Routing, which I'll perhaps mention another time, but I do think there are some much more significant differences between it and WS-Addressing.
But allow me to present a new design question. Justin proposes using the wsa:ReplyTo element to provide for immediate or deferred response of the message. I'm not quite sure how it would work out. I just can't see this making much sense, in a way. My first question is, how would the WSDL look like for a service that could either respond right away or via a callback message? I can think of a few ways, but none that are too clean. This is one case where I'd prefer to actually split the service in two: one sync, another async.
The whole asynchronous Web Service idea has been nagging at me for a while, and Justin's introduction of wsa:ReplyTo provides a good context for me asking this question: What should the HTTP-response content be for a SOAP call that's basically one-way? (yes, I know I'm blatantly displaying my ignorance here...). Basically, it all boils down to: is a soap-envelope required on the response, and if so, why? [1] (iow, why wouldn't just a 200 Accepted response be enough).
[1] One reason for this question is just considering alternative, non-HTTP soap bindings on one-way protocols, such as STMP or a Message Queueing system.
