Enterprise Service Bus (ESB) - Guide to Cloud Computing for Business and Technology Managers - page 193

solutions, the physical ESB infrastructure is likely to be a centralized ESB
topology. A centralized ESB topology is concentrated on a single cluster, or
hub, of servers. This solution is reminiscent of hub-and-spoke middleware
topologies, which use a central node that manages all interactions between
applications and prevent an application having to integrate multiple times
with several other applications (see Chapter 5, Section 5.12.1, “Replacing a
Point-to-Point Integration Architecture with a Broker”). The hub-and-spoke
approach simply carries out one integration process on the central node,
which is a central point of control responsible for integration/translation
activities, maintaining routing information, service naming, and so forth.
The most popular hub-and-spoke EAI solution for the interenterprise arena
is integration brokering.
Even though a hub-and-spoke solution is capable of being stretched out
across organizational boundaries, it still does not allow the local autonomy
that individual business units require to operate semi-independently of each
other. This is usually caused by the integration broker's inability to easily
span firewalls and network domains. However, as explained earlier in this
chapter, the most serious drawback of this approach is that hub-and-spoke
solutions can quickly become a point of contention for large-scale implemen-
tations. In an environment of loosely coupled units, it does not make sense
for business process flow between localized applications or security domains
to be managed by a single centralized authority like an integration broker.
In circumstances where organizational or geographically dispersed units
need to act independently from one another, the infrastructure may become
more physically distributed while retaining at least logically the central
control over configuration. This calls for a federated hub solution. A feder-
ated ESB allows different enterprises such as manufacturers, suppliers, and
customers to plug together their integration domains into a larger federated
integration network. This topology allows for local message traffic, integra-
tion components, and adapters to be locally installed, configured, secured,
and managed while allowing for a single integrated transaction and security
model. In this figure, a federated ESB solution is used to form a virtual net-
work of trading partners across industries and services able to take advan-
tage of the wider range of options and partnering models.
The physical deployment of the ESB depends on candidate ESB technolo-
gies such as specialized MOM, integration brokers, and application servers.
The use and combination of different candidate ESB technologies result in a
variety of ESB patterns, each having its own requirements and constraints
in connection with its physical deployment. Some ESB configurations might
be suited to very widespread distribution to support integration over large
geographical areas, while others might be more suited to deployment in
localized clusters to support high availability and scalability. Matching the
requirements for physical distribution to the capabilities of candidate tech-
nologies is an important aspect of ESB design. Also important is the ability to
incrementally extend the initial deployment to reflect evolving requirements,