Years ago, enterprises began jumping on the Enterprise Service Bus (ESB) bandwagon. Yet today, thanks to the proliferation of multiple ESBs across their environments, SOA architects are having to once again rethink their optimal ESB implementation strategies.
The rise of multiple ESBs are a result of iterative SOA implementation approaches and the difficulty in ensuring a single ESB across the entire spectrum of SOA initiatives. In addition, enterprises that initially ensured a single centralized ESB architecture are being challenged with scalability issues, which are particularly important for any pervasive integration. Regardless of the camp they're in, these experiences are driving people towards federated ESB models.
Federated ESBs consist of multiple ESB domains working together to form a single, logical ESB. An individual ESB domain establishes an access and control point for a collection of services in that domain. Enterprise Service governance, security, and management become important considerations in a federated approach. Federated ESBs can be used for central management of ESB routing rules. For example, the ESB hosting the consumer service must know which ESB hosts the service to be invoked, what protocol to use, and message format so it can route the request. The Federated ESB's pattern adds orchestration of service consumer requests that span multiple ESBs, multiple service providers, or both.
In a federated ESB, there is one "master" ESB to which several "dependent" ESBs are connected, which forms a single federated logical domain. The master ESB acts as a single point of contact for the service consumers (external to the organization). The service consumer can make requests to any business unit in an enterprise via the master ESB. It also hosts the services for governance, security and management. The master ESB can have its own repository, helping in co-ordination of dependent ESBs via routing rules stored in central management.
Dependent ESBs host the services of different business units of an organization. The dependent ESBs receive the service requests from the service consumer (external to the organization) via the master ESB. Upon successful execution of the service request, the dependent ESB collates and sends the response to the service consumer via the master ESB. Dependent ESBs can host one or more business unit related services of an organization.
Here are the common scenarios where federated ESBs are a natural fit:
- Different "Domains" in Enterprise Business and Funding Models for them are Distributed or Federated
- Distributed geographical locations of the same enterprise
- Growth through mergers and acquisitions
- Distributed governance
- Differing ESB requirements that are best met by different products
- Acquisitions that have existing ESB infrastructures in place
- Decoupling to allow asynchronous development and deployment in various business units
- Central management of ESB routing rules
-1-