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

become a bottleneck and also a single point of failure. In contrast, ESB allows
capacity to be added where it is most needed—at the service itself.
When the capacity of a single broker is reached, brokers can be combined
into clusters. These may act as a single virtual broker to handle increased
demand from users and applications. The ESB's use of integration brokers
and broker clusters increases scalability by allowing brokers to communicate
and dynamically distribute load on the bus. For example, in the event that an
increase in the use of the inventory services has overloaded the capacity of
their host machine(s), new machines and new brokers can be added to handle
the load without the need to change any of the services themselves and with-
out requiring any additional development or administration changes to the
messaging system. The notion of a separately deployable, separately scalable
messaging topology combined with a separately deployable, separately scal-
able ESB service container model is what uniquely distinguishes this archi-
tectural configuration. The distributed functional pieces are able to work
together as one logical piece with a single, globally accessible namespace for
locating and invoking services.
9.3 Event-Driven Nature of ESB
In an ESB-enabled event-driven SOA, applications and services are treated
as abstract service endpoints, which can readily respond to asynchronous
events. Applications and event-driven services are tied together in an
ESB-enabled event-driven SOA in a loosely coupled fashion, which allows
them to operate independently from each other while still providing value
to a broader business function. An event source typically sends messages
through the ESB that publishes the messages to the objects that have sub-
scribed to the events. The event itself encapsulates an activity and is a com-
plete description of a specific action. To achieve its functionality, the ESB
must support both the established Web Service technologies such as SOAP,
WSDL, and BPEL, as well as emerging standards like WS-ReliableMessaging
and WS-Notification.
An SOA requires an additional fundamental technology beyond the ser-
vice aspect to realize its full potential: event-driven computing. Ultimately,
the primary objective of most SOA implementations is to automate as much
processing as necessary and to provide critical and actionable information
to human users when they are required to interact with a business process.
This requires the ESB infrastructure itself to recognize meaningful events
and respond to them appropriately. The response could be either by auto-
matically initiating new services and business processes or by notifying
users of business events of interest, putting the events into topical context
and, often, suggesting the best courses of action. In the enterprise context