System integration is multifaceted and can be
approached through different architectural
models, depending on the number and nature of
components that need to be connected.
– Point-to-Point Connection
– The Broker (and its variants)
– Message Bus.
Point – to – Point Integration (P2P)
P2P is the architectural pattern in which every system is
directly connected to all other systems and apps it needs to
work in tandem and share information with.
This model can be realized via APIs, webhooks, or custom
With a P2P connection, data is extracted from one system,
modified or formatted, and then sent to another system.
Each application implements all the logic for data
translation, transformation, and routing, taking into account
the protocols and supported data models of other integrated
With P2P as the size of your integration network grows and
as the frequency of change increases, the operational cost
associated with this approach becomes significant.
Major advantage of the Point-to-Point Connection pattern
is simplicity of implementation.
The weakness of the Point-to-Point Connection pattern is
the duplication of transformation and routing code between
systems, and the high configuration cost of endpoint
To minimize these weaknesses, you can add another layer
of indirection between endpoints that contains a broker.
P2P: When to use it
Say, to interconnect six modules you need to
perform 15 integrations. This results in the
so-called star/spaghetti integration.
This approach suits companies that don’t
have complex business logic and run their
operations on just a few software modules. It
is also a perfect option for businesses aiming
at connecting to SaaS applications.
The Broker pattern and its variants are often used in both application
design and integration design.
The intent of a broker is to decouple source systems from target
In the context of Distributed Object Integration, the source system may
send a marshaled set of parameters when the source system requests a
method invocation from the target system.
In the context of Service-Oriented Integration, the source system may
send a message that requests a service from a target system. While the
contexts vary significantly, both use a Broker pattern to decouple the
source systems and the target systems.
There are three responsibilities that are involved in
communication as follows:
Routing. Routing involves determining the location of a
target system, and it is performed by using direct and indirect
Endpoint registration. Endpoint registration is the
mechanism that a system can use to register itself with the
Broker so that other systems can discover that system.
Transformation. Transformation is the process where an
element is converted from one format to another.
A Direct broker establishes initial communication between endpoints.
After the initial communication, the two endpoints communicate
directly by using client-side and server-side Proxies.
The Indirect broker behaves like a middleman such that all the
communication between endpoints passes through it. Using an
indirect broker allows a sender to be unaware of target details and
provides central control of the message flow. In this way, Indirect
Broker is similar to Mediator.
– While the Indirect Broker pattern is useful when you need to
control communications, Direct Broker offers better
performance, especially when an additional intermediary is
not needed for all communications.
Broker: Message Broker
A Message Broker communicates exclusively by using
messages and indirect communication. The Message
Broker is an important and frequently used integration
pattern. It is often referred to as a Hub-and-Spoke
Hub – and – Spoke
The hub-and-spoke model is a more advanced type of
integration architecture that addresses the issues of point-
to-point. The connections between all subsystems are
handled by a central hub (message broker), so they don’t
communicate with each other directly.
The hub serves as a message-oriented middleware with a
centralized integration engine to translate operations into a
single canonical language and route messages to the right
destinations. The spokes (adapters) connecting the hub to
the subsystems are managed individually.
Hub – and – Spoke
Pros and cons: Since every system has only one connection to the
central hub, things get better in terms of security and architecture
However, the centralization of the hub can be a weakness in such a
model. The whole infrastructure is dependent on the single
integration engine which can become the key bottleneck as the
When to use it: The hub-and-spoke model is widely-used in e-
commerce, financial operations, and payment processing. Besides,
it’s a preferable architecture for highly regulated industries that face
significant security risks.
Five examples of the Broker pattern:
– Microsoft Distributed Common Object Model (DCOM)
– Microsoft .NET Framework Remoting
– Common Object Request Broker Architecture (CORBA)
– Universal Description Discovery and Integration (UDDI)
– Microsoft BizTalk Server 2004
A Message Bus provide a common communication
mechanism between disparate systems.
To provide this common mechanism, the systems must have
– A set of agreed-upon message schemas
– A set of common command messages
– A shared infrastructure for sending bus messages to recipients
This shared infrastructure can be achieved either by using a
Message Router or by using a Publish/Subscribe
The Publish/Subscribe pattern describes a collaboration
where one system subscribes to change messages or to
event messages that are produced by another system.
In the Message Bus context, a system can subscribe to
bus messages. After the system subscribes, the system is
then sent all the messages that are addressed to this
Although message buses often use Publish/Subscribe
implementations, these implementations are used by
other topologies as well.
The advantage of a message bus is that once it is established,
the cost of adding new applications is minimal. A new
application can subscribe to bus messages without affecting
The disadvantage of a message bus is the significant amount of
work that is involved in creating common message schemas,
command messages, and shared infrastructure within an
Publish/Subscribe pattern helps keep cooperating
systems synchronized by one-way propagation of
messages because one publisher sends a message to
any number of intended subscribers.
However, there are significant differences in the next
level of design within the pattern.
These differences lead to three refinements of the
– List-Based Publish/Subscribe,
– Broadcast-Based Publish/Subscribe, and
– Content-Based Publish/Subscribe.
Apparemment, vous utilisez un bloqueur de publicités qui est en cours d'exécution. En ajoutant SlideShare à la liste blanche de votre bloqueur de publicités, vous soutenez notre communauté de créateurs de contenu.
Vous détestez les publicités?
Nous avons mis à jour notre politique de confidentialité.
Nous avons mis à jour notre politique de confidentialité pour nous conformer à l'évolution des réglementations mondiales en matière de confidentialité et pour vous informer de la manière dont nous utilisons vos données de façon limitée.
Vous pouvez consulter les détails ci-dessous. En cliquant sur Accepter, vous acceptez la politique de confidentialité mise à jour.