Web service routing seems to be made into a very complex beast with webdav collections and what not. Essentially whats needed is a routing kernel, which is protocol independent, ie which uses a factory to construct messages in SOAP/REST/XML-RPC/SMTP/NNTP etc as abstract messages and filter on those.
Obviously stuff like authentication is better tackled at a general level, but otherwise routing is usually quite specific to the application at hand. One example would be a protocol exchanger which gets you the message on the device you have presence from (WAP/SMS/AIM, etc) if it is urgent. Another example I implemented recently is a telescope control and data system for a system of two telescopes we have in Taiwan. See http://www.astro.upenn.edu/~rahul/demo_c2.xml , especially the rules tags in that xml file, they describe how to route messages (which are shared memory mailboxes or xmlrpc queues depending on the situation). You'll see that there is a little routing language which specifies what to do.
It would seem to be that such routing is quite specific to the message structure (i have 4 unsigned ints and 3 structs in my messages). So besides dealing with header related stuff, a generic routing layer has little value. But this value may be enough to define it anyway.
It's interesting that each of the examples cited in Windley's entry are ones that are typically mentioned as motivators for applying Aspect Oriented Programming techniques.
I would be interesting to explore how different services could be layered when they are viewed as aspects.
Very insightful, Jeffrey.Posted by Sam Ruby at
This kind of thing has been around for a while; Intel had an XML directory product; Identrus had their "Transaction coordinator" There are a bunch of companies (mine included :) that see XML as a "new" type of network traffic, and provide devices to do routing, management, etc., analogous to firewalls, etc.Posted by Rich Salz at