Federated ESB Management System

Moving world with distribution of federated ESBs

As the services become very popular and play a dramatic roll in business world, taks they fullfill also become very advance rather than rendering same type of similar functionalities with a single domain. Due to this, it had to overcome and invent another solution without changing an existing services. 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 meaning of federated ESBs implies that the consistence of multiple ESB domains rendering services to form a one ESB. This logical ESB domain which performs and represent other combined ESBs establishes an access and control point for a all other services reside 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.

Typically there are two types of federated ESB architectures

• Routing via a global ESB

Client request is sent to a local ESB which in turn redirected to a global ESB if it is not resolved in local ESB. After that global ESB routes the request to the ESB instance which will be able to handle the request.

• Peer to Peer ESB with Central Configuration

When request comes to a particular ESB, it may try to resolve it in local. If that fails then the shared central area will be consulted. Now you may think what is the major differnet in between this scenario and previously depicted scenario. Of course there is a nomad differ.

In this scenario, each ESB which also has its own local registry, routes directly to the most appropriate ESB for final delivery of the message if it is unable to resolve the request.

Local registry keeps the configuration for services directly associated with each ESB. This is not enogh because when new request comes to a certain node, then it may have to forward it to another node here ESB in order to resolve it. For this, information providing the location of the services on other ESB's should be well managed. This is done through a shared central area. Managing this configuration is a matter to be concern here.

The key point is only the locations if other ESBs are kept in central point. But if all the informations relevant to other ESBs are kept in each ESBs local registry, it will be easier to map and forward requests to relevant ESB and could be said real time peer to peer with out a contrast. BUt demerit is that when adding or implementing new services or ESBs, then each and every time it has to be updated every ESBs locally resided registries explicitly.

It is however beneficially to create a network of replicating registries so that each ESB has direct access to configuration infomation on the local network.

Steps that must be carried out in advance are to cope with different type of ESBs. Currently ESB's are functioning well if they all are the same type, so above implementation is easier, but additional complexity could be come of to the content based routing to enable it for a heterogeneous environment.

Addressable areas of federated ESB architecture

• When there are different domains in Enterprise Business
• Distributed governance
• Differing ESB requirements that are best met by different products

and meanwhile Federated ESB must address following facts

• ES governance
• Security
• Management
• Orchestration