In a complex enterprise such as
a bank, two topologies (bus and hub-and-spoke) often need to be simultaneously
deployed in order to achieve Enterprise Integration.
If applications are integrated
in a point-to-point manner, the number of interfaces and the associated
complexity grows rapidly with growth in applications (approaching n-squared,
where n is the number of applications). Another implication of point-to-point
connectivity is the tight coupling between applications. When a new application
is introduced, other applications have to be aware of the precise data format
expected, the integration style, the protocol used, etc. Integration styles can
range from service calls (which may be RESTful web services, SOAP web services,
CORBA or RMI calls etc.), to message-based integration (e.g. MQ), file-based
integration or even using a shared-database for integration. Such tight
coupling strangles flexibility, or the ability of the enterprise to iterate.
Bus topology, in the form of an
Enterprise Service Bus is typically used solve these problems and to decouple
interfacing applications.
Using a bus, interfacing
applications are shielded from the protocols, message formats, physical
endpoints etc. used by their peers. Additionally, the bus can be used to
publish messages to multiple subscribers, and even to implement an Event-Driven
Architecture if so desired.
However, this level of
decoupling is not sufficient. If an application needs to provide data (say
transactions or portfolio positions or customer data etc.) to 40 other
applications, generally it still needs to extract the data independently for
all 40 applications and feed it over the bus. This is because of variation in
the needs of the 40 applications (such as expecting incremental data vs. a full
set, end-of-day vs. near-real-time, reconciled/clean data or raw, etc.).
To solve this problem,
Hub-and-Spoke topology in the form of a Data Hub is typically created.
This might be called an
Operational Data Store (ODS) and contains commonly used data which is replicated
from source systems to the Data Hub. Applications form the spokes and obtain
common data from the hub. With a Data Hub, the next level of decoupling occurs.
Data consumers do not need data producers to be available at the precise moment
they need the data, so availability of applications goes up. Applications are
shielded from the volume of data requests, and can focus on executing business
functions without impact to performance. Apart from scalability, another
advantage of the Hub is that data consolidation and data enrichment/correction
can occur in the hub.
Apart from a Data Hub, a Service
Hub is often created to house common services that access data in the Data Hub
and/or invoke other applications to fulfill requests (including Service
Orchestration). The services in the Service Hub can be used to implement common
semantics across the enterprise.
The Data/Service Hub has be
overlaid on the bus i.e., the Data/Service Hub itself has to be interfaced to
the bus.
