Why the Time Has Come for Federated ESBs

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

Advantages of a Federated ESB

As the federated ESB model continues to emerge, many benefits are being realized, including increased reuse by leveraging a common, federated registry and repository across multiple ESBs. In addition, federated ESBs enhance connectivity by enabling dynamic service selection for ESBs and enforcement of polices. Companies are also able optimize service usage by utilizing a common registry for impact analysis, change of notification, version management, etc across ESBs. Governance is also improved by scoping and promotion of service endpoint visibility according to federates deployment and topology requirements.

In order to ensure success, the right implementation strategy for a federated model needs to be adopted. An enterprise may adopt either a bottom-up or top-down approach for a federated topology implementation. With the bottom-up (or reactive federation) approach, the starting point is a set of individual ESB implementations resulting from successful ESB pilots which often use different approaches and infrastructure. Alternatively, the top-down (or proactive federation) methodology is applied to structure brand new ESB implementations as a set of collaborating and coordinated service domains reflecting the underlying enterprise structure and communities and varying requirements on infrastructure in support of the participating domains.

Another approach is 'Meeting in the middle', a hybrid of top-down and bottom-up.

When implementing a federated ESB, there are a few specific factors that should always be considered. These include the following:

  • Registry based services governance
  • Distributed deployment of services at logical domain ESBs
  • Common monitoring Dashboard implemented via BAM
  • Federated security management
  • Implementation by Heterogeneous ESB tool platforms

As the federated ESB model continues to emerge there will of course be challenges to overcome. For example, the capability of ESB product suites available in market to implement a true federation is a subject for debate, which demands proof of concepts prior to implementations. Also, the implementation of service virtualization, service management, service security and service governance is a complex proposition to be governed in a federated zone.

The level of domain autonomy to be granted to individual ESB domains will be another topic for enterprise IT stakeholders to ponder over for services visibility across logical domains.

In an era where enterprise customers are just as likely to be choosing best-of-breed solutions as they are to settle on a single vendor, the federated ESB model provides ample scope for organizations to realize both, due to the implementation philosophy itself. As industry experts continue to substantiate this approach, enterprises are already beginning to widely embrace the federated ESB topology.