Take for instance the Web/CGI application on the righthand side of Figure 10-1. Typically, it is connected directly to a database that contains the information it needs. However, in this scenario, the database is decoupled from the Web/CGI application by the XML switch. The Web/CGI application only submits an XML packet (a SOAP-like packet in this chapter) asking for relevant data. The switch interprets this packet and forwards it to the right location (in this particular case, a Python class that can perform the appropriate work). When the database responds, the information is “routed” back to the original caller. This allows for flexibility in the location or design of the database. In fact, it lets distributed systems commit to XML interfaces as they expose their functionality, instead of committing to the intricacies of table design or specific stored-procedure names.

This type of design is similar in architecture to message queuing designs, with some subtle and powerful differences. By decoupling different pieces of an enterprise, you’re able to share their functionality more broadly, and enjoy the independence of not being tightly bound to any specific application that consumes the data. In addition, by placing an intermediary between data sources and data consumers, you allow for business logic to exist at a level above and between applications, and not programmed directly into them. For example, in Figure 10-1, you could conceivably swap out the Profiles database, and instead use a third-party service on the Internet that contains customer data. That is, if you find that a web service provides better personalization and consumer data than you, you can connect with the service, develop an XML interface that is familiar to your network, and swap out the old database for the new service partner. The local applications as consumers of the information would be none the wiser, as the XML switch is still accepting their XML requests and results are still being routed back to the applications.

In addition to flexibility in system components, routing also adds another degree of scalability to a system. By routing XML requests for information around your network, you enable the ability to manage them as you would other types of network traffic. For example, you can replace individual systems with system farms consisting of multiple servers, and load balance the XML packets that are sent between them. In another case, XML switches could be daisy-chained together, much like routers and hubs are chained together for TCP/IP traffic. This concept enables you to do things such as broadcasting and duplication of read-only signals. It also allows you to create redundancy and multiple network paths to the same location.