The WS-Routing specification was published a long time ago and we implemented it together with WS-Referral (although we didn't call it that) in WSE 1.0. Neither specification has garnered much attention and, with the arrival of WS-Addressing, both are somewhat superseded.
For the WSE 2.0 Tech Preview, we removed several components of the /Path header and replaced them with their equivalents from WS-Addressing. Despite the fact that we added additional transports to WSE for the Tech Preview we left the HTTP-based Router largely untouched and didn't do anything for the other transports.
Moving forward for the final release we're going to complete the transition over to a WS-Addressing world and remove the last vestiges of WS-Routing, although we'll continue to provide support for SOAP intermediaries, in particular content-based routers. Routing will be "next hop" based with the sender and intermediaries able to determine where the message is to be sent next and we'll be cleanly separating the notion of Actor / Role from transport address. This is a pretty big change to the product and is affecting lots of areas, particularly the transport layers - if you've built a custom transport for WSE 2.0 Tech Preview, you should expect to have to rework it for the final release.
Posted by herveyw at November 12, 2003 09:00 PMHey, wonderful blog! On a completely different note: Could you sometimes write an entry where you comment on WS-ReliableMessaging vs WSE? Will we get any implementation of that before Indigo? Well, I would certainly love it ;) Thanks! David
Posted by: David at November 13, 2003 01:20 AMOne of the problems encountered when playing with custom transports and routing with WSE2.0 was that WebServicesClientProtocol-derived proxy didn't play nice with addressing. For instance it was impossible to deliver message to "http://a/b/c.asmx" and have addressing header wsa:To field set to "http://e/f/g". It seemed that any value assigned to SoapEnvelope.Context.Addressing.To field on proxy side would get overwriten by the value of SoapEnvelope.Destination, so immediate message recipient was always same as wsa:To. The SoapClient-style proxy didn't have this problem, but it was less user friendly - I couldn't find a way to generate strongly typed SoapClient-stlyle proxies from WSDL. Is this going to be fixed?
Posted by: Gia at November 13, 2003 09:51 AMHey, what is the scoop for people that are itching to use WSE 2.0? Right now I am building an application that could really benefit from it, and its killing me to do it the way I am now, knowing whats around the corner. Any ETA on a production licensable version? :)
Posted by: Bryan Batchelder at November 13, 2003 02:19 PMI was doing some digging thru WSE 2.0 yesterday and came across some stuff that I wonder about (I haven't tested this, just based on digging thru code)
It appears that in SoapReceiver Dispatch.. if the message has a RelatesTo, it appears to check that the URI does not have a scheme that matches any Transport scheme. I didn't think the standard put any restrictions on MsgId URI's. What if I happened to use my company URL with an appended number unique to my site for msg id's (something like http://mycompany.com/123)?
Also in the same code it seems to verify that the scheme of the To URI matchs the scheme of the channel that the message came in on. I've read the Web Services Addressing whitepaper several times (I find it very confusing) and it does seem to imply that perhaps the To URI must be an actual network address but I'm not so certain. Is it really necessary to tie the To URI so closely to the transport being used? What if I'm tunneling or doing some proxy thing? If it really must be an actual address why check just scheme and not host and port?
Posted by: Dave Angers at November 14, 2003 10:54 AM