I've been trying to get my head around how the whole SOAP Processing Model works (specially in v1.2), while at the same time trying to digest WS-Routing and the concept of SOAP Intermediaries.
Most makes sense right from the start, but there are a few things I'm still not completely clear on. Any comments would be appreciated as usual (hey, we're here to learn, aren't we?):
- Pretty much all examples of WS-Routing I've seen seem to imply static routing, where the initial sender has full knowledge a priori of the "Network Topology". Is this really the only model supported? (Section 3.4 of the WS-Routing spec would suggest no, but I'm not entirely sure).
My main concern for this is that I believe that, to be throughly useful, routing should be as transparent as possible to the application; even to the point that any clients should be allowed to be oblivious to the fact that routing might happen. Here, I'm thinking something similar to how MSMQ 3.0 routing model hides routing details from the queue client. I have not seen any WS-Routing implementations that do this, and instead explicit coding seems to be required on the client to support routing right now.
- Both the SOAP Intermediaries and WS-Routing Intermediaries model, plus the whole SOAP roles+processing-model thingie seem to imply (at least from my rather very basic understanding of the subject) that the initial sender knows who the ultimate receiver is, which might be more evident by the no "to"-element rewrite requirement for WS-Routing Intermediaries. Perhaps I'm wrong about this.
One of my concerns for this is whether this would permit (and how) the common concept of external gateways (no, not ws-routing gateways, I'll talk about those in a minute), that receive messages coming from some exterior boundary, and route them to internal endpoints. Of course, this whole question depends on whether the endpoint referenced in the "to" element is supposed to be the same one as the ultimate receiver or not.
- What exactly is the difference between WS-Routing intermediaries and WS-Routing Gateways, and, indeed, why make a distinction at all? It just feels kinda artificial to me. The WS-Routing spec says that a WS-Routing Gateway can "act as a gateway into a foreign protocol environment". It also indicates that a WS-Routing Intermediary might also be a WS-Routing Gateway (who comes up with such long names, for pete's sake?), so it must follow all WS-Routing Intermediary's rules (including the no-to-rewriting-rule). However, it also says that if a WS-Routing receiver rewrites the to-element would only be considered a WS-Routing Gateway, not an intermediary. And to top it all, it also says that an intermediary that uses different protocol bindings on its two ends would not be considered a Gateway!
Question No. 2332332: where does this discussion leave a WS-Receiver that rewrites the to-element and yet does not use different protocols on either side? It is clearly not a Gateway, but neither an intermediary? Am I the only one that finds all this somewhat confusing?
OK, enough ranting and questioning for today :)
