The most direct way of integrating applications is programming point-to-point interactions between the different applications interacting (direct connection pattern). However, when the number of interactions reaches a certain volume, this approach suffers serious limitations owing to the fact that:
- The integration logic required by the applications (e.g., selecting a transport protocol, a data format, a service provider) is usually complex owing to their great heterogeneity. Thus, for example, it is normal to have to mediate between different transport protocols, convert between different data formats and reconcile diverse interaction patterns (e.g., connecting a synchronous and an asynchronous system).
- The integration logic is not reused, therefore each application needs to completely implement and manage the logic required to interact with all the applications with which it integrates. As a result, a connection explosion occurs that makes the corporate management of the systems resulting from the integration impossible (e.g., for establishing a uniform criterion for naming services, for routing messages, etc).
Obviously, what is needed is an infrastructure that minimizes the integration logic required to incorporate the applications, providing basic capabilities in which that logic is supported. While not necessarily linked to the SOA model, the Enterprise Service Bus (ESB) is emerging as the concept that brings together and includes all the capabilities of this infrastructure. An Enterprise Service Bus is distributed software that provides an infrastructure for integrating applications, in particular, for integrating them as per the SOA model. Basically, this infrastructure is a messaging service that can be accessed using different transport protocols (e.g., HTTP, JMS, FTP, SMTP); supports configuring complex routing logic; supports multiple interaction patterns (request-response, publication-subscription, event notification, etc.), which permits transforming message formats, and virtualizes the location of the services.
In short, an ESB gets rid of the direct (point-to-point) connections between providers and consumers by forcing these connections to always take place via the bus. Far from being a problem, the intermediation of the ESB goes even further in decoupling the consumers from the providers. As a result, it increases the value (usefulness) of the services.
Thus, connecting TrustedX to an ESB (Figure 1) boosts its functionality almost limitlessly as it makes it possible to access its services in just about every way imaginable (e.g., using non-Web protocols, using asynchronous interaction patterns, reusing service interfaces different to TrustedX's and those already coupled with the applications).