O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Carregando em…3
×

Confira estes a seguir

1 de 20 Anúncio

Mais Conteúdo rRelacionado

Mais recentes (20)

Anúncio

Unit 4.pdf

  1. 1. 1 Systems Integration Lecture 4
  2. 2. 2 Integration Topologies
  3. 3. 3 Intro  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. – Publish/Subscribe
  4. 4. 4 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 code.  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 components.
  5. 5. 5
  6. 6. 6 P2P  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 address changes.  To minimize these weaknesses, you can add another layer of indirection between endpoints that contains a broker.
  7. 7. 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. 7
  8. 8. Broker  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 systems.  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. 8
  9. 9. Broker 9  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 communication.  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.
  10. 10. Broker 10
  11. 11. Broker  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. 11
  12. 12. 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 architecture. 12
  13. 13. 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. 13
  14. 14. Hub – and – Spoke 14
  15. 15. 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 simplicity.  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 workload increases.  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. 15
  16. 16. Broker examples  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 16
  17. 17. Message Bus  A Message Bus provide a common communication mechanism between disparate systems.  To provide this common mechanism, the systems must have three elements: – 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 mechanism. 17
  18. 18. Message Bus  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 common bus.  Although message buses often use Publish/Subscribe implementations, these implementations are used by other topologies as well. 18
  19. 19. Message Bus  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 other subscribers.  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 enterprise. 19
  20. 20. Publish/Subscribe 20  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 Publish/Subscribe pattern: – List-Based Publish/Subscribe, – Broadcast-Based Publish/Subscribe, and – Content-Based Publish/Subscribe.

×