D.6. Appendix: Federated ESB Reference Architecture
489. The following chapter is based on the document "ESB Interop Spec for Federation" from MoD UK, EDS, IBM and ORACLE (a proposal for federated ESB for ESBs based on different technology).
490. The ESB is an architectural component which provides a set of services (or capabilities). The component itself exposes a set of services which are characterised by a protocol, one or more addresses and specifics ways of handling invocations, such as security. It also uses a set of ports to integrate with service providers (such as application functions). The capabilities provided by the ESB may include message format transformation and protocol conversion, and it offers a number of interactions styles including request-response and publish-subscribe.
491. Currently exists a lot of different ESB implementations and the aim is to enable federation of two or more ESB architectures that conform to the common specification for ESBs.
492. The following list of high-level requirements has been used to give an overview for the (Federated) ESB Reference Architecture:
-
It should be transparent to Service Consumers and Providers where the services they invoke are being delivered from (i.e. from which ESB).
-
Services can be exposed for either internal or external consumption. Service Consumers external to an ESB will not have access to that ESB's internal Service Providers.
-
Every message which emanates from a service should be identifiable and traceable back to its origin via a UUID. A component of this UUID is an identifier assigned to the domain when it joins the federation. (Alternatively time to live may need to be applied, so when set to 0 the message is private.) This prevents infinite loops.
-
ESBs must provide a mechanism for authenticating Service Consumers and for controlling their access to the services the ESB exposes externally.
-
ESBs must provide a facility for managing and publishing up-to-date service end-points for the services governed within the immediate zone and must be capable of storing service end-points for services offered by other governance zones.
-
ESBs should audit the processing of a service that it offers and make available the audit records captured, upon request from the Service Consumer that invoked the service.
-
Exceptions trapped by services invoked must be handled in a consistent manner across all ESBs within a federation. Whilst each ESB may implement exception handling differently, they must report errors to the Service Consumers following an agreed format and reporting mechanism.
Figure D.21. Federation ESB Architecture Overview
493. The diagram above provides a logical overview of the subsystems that have been used to provide a Service Oriented Infrastructure for delivery of Service Orientated applications.
494. The ESB Gateway acts as a proxy to provide controlled access to the ESB. A principal use of the ESB Gateway is to expose services in a consistent manner across all governance zones. This node allows generic actions to be defined and performed on all calls to services such as logging, auditing, monitoring, security, and threat protection.
Figure D.22. ESB Gateway
495. The ESB Gateway provides the single-point of control for federated service invocations, that either originate with a local Service Consumer call to a remote service (service hosted on external ESB) or a remote Service Consumer call to a local Service Provider.
496. Local Service Providers and Service Consumers are shielded from the federated ESBs (their consumers and providers) by the ESB Gateway, which separates all aspects of external ESB interoperability from how services are provided and consumed locally.
497. ESBs are federated on the basis that each of the zone's ESBs is autonomous, and yet they all have knowledge of the wider enterprise-level services. The next figure shows a topology for federated ESBs in which any consumer can call services in any zone without necessarily having set up the communication paths in advance.
Figure D.23. Federated ESB