Last night I couldn't sleep, so I started to put together some thoughts I'd been having lately regarding web services and level 5 routing. Some might want to quibble and call it level 4, but since the transport for SOAP is HTTP (a level four protocol), I'll call it level 5. The idea is pretty simple: the advent of standards for application integration has brought us to the point where applications can be put together by scripting calls to existing services. Because the APIs are exposed and documented and the calls happen "in the clear" instead of buried inside a monolithic application, one can conceive of a routing architecture for these service calls that performs the following functions (and more):
- Service Call Switching. Think of this as load balancing for web services done at the interface level. This could be done simply to balance load, to shuttle potentially high load jobs to specific servers, or to move a new version of the service into production. For example, imagine developing version 2.0 of your web service and instead of cutting over to it one evening or weekend, you just shunt 5% of the traffic to it for a while and then slowly crank up the volume to ensure its functioning properly and can handle the load. When you're satisfied its working, you cut over to the new version and tear the old version down.
- Filtering Based on Context. Probably the most obvious example of context sensitive filtering is in the area of authorization. Suppose that the level 5 router has access to SAML messages about authentication and authorization information for users. The router could be configured to filter messages (coming or going) based on that authentication information. So, for example, someone requesting health care information about a patient could be denied access altogether, or the return message could be filtered to return only the right information.
- Event Monitoring. Suppose you'd like to put an alarm on certain kinds of calls. The router could be configured to monitor traffic and send an alert (message) when it is triggered. So, for example, a sales manager could be alerted to an order from a certain customer or over a certain amount and take some special action. Or, the inventory management system could be alerted when a call is made to order an extraordinarily large number of some part, etc.
- Logging. Any event or call, including the content, could be monitored and logged for later analysis.
- Service Facades. The router could provide service facades to wrap a service in a more generic interface or one that the company supports internally. As an example, suppose that your company has built a nice employee portal that uses a web service provided by your health insurer and then you change insurers. The ability to easily map one service to another would provide a service facade that makes integrating the new service easier. I think in many cases this could be done using a graphical tools based on the respective WSDL information.
- Business Rules Repository. Rather than scripting, such a router could contain (or access) a business rules repository and use it to provide aggregated services.
Of course, all this would have to happen reliably and quickly. One question that might come to mind is "Why would you want to do any of these things at the interface? Why not build them into the application?" That's a fair question and I'd answer in two parts:
- Separation of concerns. Do the security and logging outside the application rather than building it in. Then its modular and can be easily changed out.
- Reliability. A pre-built, widely used infrastructure component is likely more reliable and scalable than a homegrown solution.
- You may not have access. You may want to filter or log access to services you don't control.
I've got to run now. I'll write more about this later.
