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

business events, such as a customer order, the arrival of a shipment at a load-
ing dock, the payment of a bill, and so forth affect the normal course of a busi-
ness process and can occur in any order at any point in time. Consequently,
applications that use orchestrated processes that exchange messages need to
communicate with each other using a broad capability known as an event-
dr iven SOA.
An event-driven SOA is an architectural approach to distributed comput-
ing where events trigger asynchronous messages that are then sent between
independent software components that need not have any information about
each other by abstracting away from the details of underlying service con-
nectivity and protocols. An event-driven SOA provides a more lightweight,
straightforward set of technologies to build and maintain the service abstrac-
tion for client applications.
To achieve a more lightweight arrangement, an event-driven SOA requires
that two participants in an event (server and client) be decoupled. With
fully decoupled exchanges, the two participants in an event need not have
any knowledge about each other before engaging in a business transaction.
This means that there is no need for a service contract in WSDL that expli-
cates the behavior of a server to the client. The only relationship is indirect,
through the ESB, to which clients and servers are subscribed as subscribers
and publishers of events. Despite the notion of decoupling in an event-driven
SOA, recipients of events require metadata about those events. In such situ-
ations, recipients of events still have some information about those events.
For instance, the publishers of the events often organize them on the basis
of some (topical) taxonomy or, alternatively, provide details about the event,
including its size and format, which is a form of metadata. In contrast to ser-
vice interfaces, however, metadata that is associated to events is generated on
an ad hoc basis as metadata tends to come along with the event rather than
being contained in a separate service contract. In particular, ad hoc meta-
data describes published events that consumers can subscribe to, the inter-
faces that service clients and providers exhibit as well as the messages they
exchange, and even the agreed format and context of this metadata, without
falling into the formal service contracts themselves.
9.4 Key Capabilities of an ESB
In order to implement an SOA, both applications and infrastructure must
support SOA principles. Enabling an application for SOA involves the cre-
ation of service interfaces to existing or new functions, either directly or
through the use of adapters. Enabling the infrastructure, at the most basic
level, involves the provision of the capabilities to route and deliver secure
service requests to the correct service provider. However, it is also vital that