Hub-and-Spoke Integration
The hub-and-spoke paradigm is based on a centralized hub and a number of
spokes that are directly attached to the hub; the spokes are not connected.
The centralized enterprise application integration middleware represents the
hub, and the applications to be integrated are reflected by the spokes. The
applications interact with each other via the centralized enterprise application
integration hub.
It is an important feature of hub-and-spoke architectures that the sender of
a message need not encode the receiver of the message. Instead, each message
is sent to the enterprise application integration hub. The hub is configured in such a way that the message structure and content can be used to automatically
detect the receiver or receivers of a message.
The advantage of these centralized middleware architectures is that the
number of connections can be reduced. No longer are connections in the order
of N × N required to connect N application systems. Since each application
system is attached to the centralized hub, N interfaces will suffice. Using these
interfaces, the specific relationships between the applications can be reflected
in the configuration of the middleware.
A centralized enterprise application integration middleware following the
hub-and-spoke paradigm is shown in Figure 2.7. The centralized hub provides
adapters that hide the heterogeneity of the application systems from
each other. Each application system requires the development of a dedicated
adapter to attach to the hub.
Depending on the complexity of these systems—and the availability of
generic adapters provided by the enterprise application integration vendor—
the development of the adapter might consume considerable resources. When
the adapters are in place and the hub is configured, the applications can
interact with each other in an integrated manner.
On a technical level, message brokers can be used to realize a hub-andspoke
enterprise application integration system. Message brokers are software
systems that allow a user to define rules for communication between applications.
Therefore, the burden of implementing—and changing—communication
structures is taken away from applications. By defining in a declarative way
how communication between applications takes place, implementation is redeemed
by declaration, i.e., by the declaration of the communication structures.
Response to change is improved, because the sender is not required to
implement these changes locally. These changes can be specified in a declarative
way in the central hub, rather than by coding in the applications.
The hub uses rules to manage the dependencies between the applications.
Based on these rules, the hub can use information on the identity of the sender,
the message type, and the message content to decide on which message queues
to relay a message received. Besides relaying messages to recipients, message
brokers also transform messages to realize data mapping between the applications,
so that data heterogeneity issues can be handled appropriately.
Adapters of application systems are used to perform these message transformations.
As shown in Figure 2.8, each application is linked to the message broker,
reflected by the directed arcs from the applications to the message broker, in
particular, to the rule evaluation component of the message broker. On receipt
of a message, the message broker evaluates the rules and inserts the message
into the queues of the recipients.
The queues are used for guaranteed delivery of messages. Note that any
change in the communication is handled through the message broker: by establishing
new rules or by adapting existing rules, these changes can be realized.
There is no implementation effort required for realizing these changes; just a
modification of the declarative rules.
Publish/subscribe is a mechanism to link applications to message brokers.
The idea is that applications can subscribe to certain messages or types of
messages. Applications can also publish messages. The information received
by publish and subscribe are used by the enterprise application integration
hub to realize the relaying of messages. Figure 2.8 also shows that at a technical
level enterprise application integration with a message broker relies on adapters that are used for transforming data and protocols between senders
and receivers.
Based on a message broker in which adapters for the applications to be
integrated are in place, applications can be integrated by developing an integration
application. This integration application communicates with the message
broker and, via the message broker and the adapters of the respective
systems, with the backend application systems.
Various types of interaction between the applications are possible, ranging
from simple invocations to complex interactions between multiple applications.
These complex interactions consist of a series of activities, each of
which is represented by an invocation of an application system. These activities
can be ordered, so that execution constraints are in place between the
respective invocations. These execution constraints might be determined by
data dependencies, so that a particular function of the enterprise resource
planning system can only be started when particular customer information is
extracted from the customer relationship management system.
While message brokers are a feasible solution to the enterprise application
integration problem, there are also some drawbacks with them. First of all,
the message broker contains considerable application logic. This application
logic is hidden in the rules that the message broker uses to relay messages. The
configuration and management of these rules becomes hard and cumbersome, since complex dependencies between rules can emerge, so that changing one
rule might have undesired implications on the overall system behaviour.
The main reason for these issues is the missing conceptual underpinning
of enterprise application integration. Despite rule mechanisms, enterprise application
integration technologies to a large extent rely on programming and
low-level configuration of adapters and message brokers. This applies to both
data integration and process integration.
Data integration is typically performed using data mapping tools. These
tools allow the mapping of data structures of the application to data structures
of the message broker. Conceptually, this approach requires a data model
hosted by the message broker that all applications have agreed upon, i.e.,
a global data model. In many cases the global data model is not explicitly
developed, but somehow hidden in the data mapping rules realized in the
adapters.
In typical enterprise application integration scenarios, the functionality
provided by the integrated applications is organized by a sequence or partial
order of steps, realizing a process. This process consists of activities that are
executed based on a set of execution constraints, and the execution of these
activities achieves an overall business goal. While in traditional enterprise application
integration scenarios, like the ones discussed so far, these process
structures are buried in rules that the message broker hosts, an explicit representation
of processes proves more appropriate.
As the next step in the evolution of information systems, workflow management,
which identifies process specifications as first-class citizens that contribute
to solving the process integration problem in enterprise application
integration scenarios is addressed. However, before addressing workflow management,
a second influencing factor for business process management is introduced
that emerges from business administration rather than from software
technology, i.e., enterprise modelling and process orientation.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment