Topologies

Integration servers use a "hub-and-spoke" topology. The integration server, as the hub, rests between the source and target applications being integrated in a configuration that resembles a star (see Figure 9.9). Although this configuration is the most traditional one, new developments suggest the various advantages of leveraging integration servers that use other topologies, such as multihub or federated.

Figure 9.9. Hub-and-spoke configuration.

In the multihub configuration, a number of integration servers are linked, with the source and target applications connected to any of the brokers in the configuration (see Figure 9.10). This configuration can scale, making it possible to integrate virtually unlimited numbers of source and target applications. When more applications need to be integrated than a single integration server can handle, more integration servers can be added to the network.

Figure 9.10. Multihub configuration.

Like the multihub configuration, the federated configuration supports several integration servers working together to solve an application integration problem. However, federated configurations typically mean that several different types of integration servers, independent of one another, are working in concert to integrate a trading community. This is a common configuration which makes perfect sense, because most trading partners don't agree on the make and model of integration servers. Therefore, the various integration servers must learn to interoperate. What's important to understand about this configuration is the fact that the source and target applications are statically bound to a particular integration server (see Figure 9.11). The message processing is not shared among integration servers. They typically hand off information, one to another, through a common interchange format such as XML.

Figure 9.11. Federated configuration.

The evolution of integration servers is clear. As they become more sophisticated, there is a clear movement away from the simple hub-and-spoke configuration toward the multihub configuration. Unfortunately, this transition is not, and will not be, a smooth one. Some integration servers are able to support multihub configurations. Others are unable to intelligently share the message-processing load. Integration servers that can exist in a multihub configuration become successful by learning to "share the load" with other integration servers on the network. Load-balancing mechanisms that are able to off-load message-processing work to integration servers with available capacity help make it possible to simply add integration servers to the network. They locate the broker, configure it, replicate the repository, and put the integration server to work.

In addition to the ability to scale a definite requirement for application integration the multihub configuration provides a fail-safe service. With several integration servers sharing the network load, a single failure will not shut down the system. The others can continue processing the information. To say that this is an advantage is a profound understatement. Unfortunately, it is an "uneven" advantage. Many of these fail-safe features vary from vendor to vendor, with some more effective than others. However, an uneven advantage remains an advantage. With the integration server as the beating heart of application integration, it is only prudent to incorporate sound mechanisms to protect it from failure.