BROKER Publicador Suscriptor. Jonnathan Corredor Lorena Arrieta Alejandro Mosquera

Transcripción

1 BROKER Publicador Suscriptor Jonnathan Corredor Lorena Arrieta Alejandro Mosquera

2 Contenido 1. Descripción General 2. Guía de Implementación 3. Patrones Relacionados 4. Usos Conocidos 5. Variaciones 6. Ventajas y Desventajas

3 1. Descripción General

4 Qué problema soluciona el patrón? Publicador - Suscriptor Sistema distribuido donde cada nodo tiene comunicación directa con otro. Inflexibilidad Poca mantenibilidad

5 Solución En el centro se encuentra un mediador broker Es similar al patrón mediador, salvo que es distribuido.

6 Características del Patrón Descompone componentes que interactúan entre sí, a través de la invocación remota de servicios. Aplica para sistemas distribuidos. Permite el desacoplamiento de la comunicación entre clientes y servidores, al pasar la responsabilidad a un componentes central llamado broker.

7 Cómo es el proceso de conectar los clientes y servidores? 1. Registro de un nuevo servicio de un servidor

8 Cómo es el proceso de conectar los clientes y servidores? 2. Comunicación entre Clientes y servidores a través del broker,

9 Componentes 1. Clientes / Suscriptor 2. Servidores / Publicador 3. Broker 4. Bridges / Topic 5. Client-Site Proxies 6. Server-Site Proxies

10 Componentes Clientes y Servidores Clientes / Suscriptor Pone las peticiones en un mensaje y las envía al broker Espera respuesta - síncrono Continúa trabajando - asíncrono Servidor / Publicador Ofrecen los mismos servicios a múltiples entornos Ofrecen una funcionalidad a un único entorno

11 Componentes Proxies Esconden la implementación, tanto para el cliente y al servidor. Esconden el mecanismo de comunicación interno Funciona como una memoria relativa sobre los eventos de la conexión

12 Componentes Broker

13 Estructura Al Interior del Broker Componentes que enruta los mensajes en el sistema y coordina la comunicación. Mediador / Hub de comunicación Es el responsable del manejo de errores, comunicación. Las peticiones son codificadas al API del broker, para recibir y envía los mensajes. Mantiene el registro de los servidores y clientes

14 Componentes Bridge Encapsula funcionalidades específicas de la red Es opcional, solo aplica cuando hay necesidad de comunicar dos Brokers

15 Componentes Topic Son eventos o mensajes predefinidos asociados a un suscriptor / cliente. Cada evento tiene asociado a un conjunto de atributos

16 2. Guía de Implementación

17 Paso 1 / 6 Definir el objeto modelo que será utilizado Que es un objeto modelo? Una colección de objetos o clases que el sistema puede utilizar para llevar a cabo las tareas programadas. 1. Definir nombres de objetos, excepciones, tipos soportados, interfaces y operaciones.

18 Paso 2 / 6 Decidir qué tipo de componentes interoperables debe el sistema ofrecer 1. Especificando un estándar binario a. Cada objeto de la colección debe ser asociado con una representación binaria 2. Definiendo interfaces IDL a. Se generan código binario dependiendo del lenguaje que implementa la interfaz

19 Paso 3 / 6 Especificar los API s que el broker proveerá para comunicarse con el cliente y el servidor 1. Lado del cliente Definir qué clases son las encargadas de enviar y recibir solicitudes al broker 2. Lado del servidor Definir las clases que registran al servidor en los repositorios del broker Definir las clases que reciben solicitudes del broker

20 Paso 4 / 6 Usar objetos proxy para ocultar detalles de la implementación de los clientes y servidores 1. Proxy Cliente Empaqueta y limpia solicitudes que van desde el cliente al broker. Desempaqueta y limpia respuestas que van desde el broker hasta el cliente 2. Proxy Servidor Recibe solicitudes del broker e invoca los métodos al servidor correspondiente Retorna respuestas del servidor al broker

21 Paso 5 / 6 Diseñar el componente broker 1. Especificar los protocolos de comunicación con el proxy cliente y proxy servidor. 2. Definir la estrategia de manejo de excepciones para que sea entendible para el cliente y para el servidor 3. Si el cliente proxy o servidor proxy no proveen mecanismos marshaling y unmarshaling el broker debe proveerlos 4. Incluir un repositorio que contendrá la dirección de los servidores registrados y sus protocolos de comunicación

22 Paso 6 / 6 Desarrollar compiladores IDL Incluir un compilador de IDL para cada lenguaje de programación que se soporte

23 3. Patrones Relacionados

24 Patrón Mediador Mediador actúa como un broker

25 Patrón Proxy Mantiene una referencia al objeto real

26 4. Usos Conocidos

27 Otros usos Conocidos Corba: Usa IDL Microsoft OLE 2.x: Usa standard binario WWW

28 JMS Java Message Service

29 RabbitMQ

30 Apache Kafka

31 5. Variaciones

32 1. Direct Communication Broker System El broker le dice al cliente cual es el protocolo de comunicación con el servidor, y el cliente se comunica directamente con el servidor para futuras solicitudes

33 2. Message Passing Broker System Esta variante es adecuada para sistemas centrados en transmisión de datos. En esta variante no existen clases u objetos remotos. La comunicación es a través de mensajes. el mensaje es una secuencia datos que especifican la solicitud y los parámetros

34 3. Trader System El broker sabe qué servicios ofrece un servidor particular y de acuerdo a la solicitud enviada por el cliente, el broker toma la decisión de enviar la solicitud al servidor adecuado

35 6. Ventajas y Desventajas

36 Ventajas Transparencia en la localización de objetos, los servidores no son conocidos por los clientes Intercambiabilidad de los componentes y extensibilidad Portabilidad Interoperabilidad Reusabilidad

37 Desventajas Restricciones en la eficiencia (alto costo en comunicación) Baja tolerancia a fallos, el broker al ser el punto central de la transmisión de mensajes, si falla todo el sistema también.

38 GRACIAS! Preguntas?

39 Bibliografía [1] R. Hanmer, Pattern-Oriented Software Architecture For Dummies. John Wiley & Sons, [2] D. C. Schmidt, M. Stal, H. Rohnert, y F. Buschmann, Pattern-Oriented Software Architecture, Patterns for Concurrent and Networked Objects. John Wiley & Sons, [3] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, y M. Stal, Pattern-Oriented Software Architecture, A System of Patterns. John Wiley & Sons, 2013.