El documento describe el patrón de arquitectura de software conocido como "Broker". El patrón introduce un componente Broker para coordinar la comunicación entre clientes y servidores de forma desacoplada. El Broker se encarga de reenviar solicitudes de clientes a los servidores apropiados y transmitir las respuestas. Esto permite que los clientes y servidores no dependan de detalles específicos del otro, mejorando la portabilidad y flexibilidad del sistema.

1. Patrón de Arquitectura
“Broker”
ANDRÉS FELIPE MONTOYA RÍOS
RE.VU/ANDRESMONTOYA
@MONTOYA118

2. Contexto
 Muchos sistemas se construyen a partir de un conjunto de servicios
distribuidos a través de varios servidores.
La implementación es complejo porque:
 Cómo los sistemas van a funcionar
 La forma en que se conectan entre sí
 Cómo van a intercambiar información
 La disponibilidad de los servicios de componentes.

3. Problemas que ataca el patrón
1. Construir un sistema de software complejo como un conjunto de
componentes desacoplados e inter-operativos, en lugar de una
aplicación monolítica.
2. Los servicios para agregar, remover, intercambiar, activar y
localizar componentes también son requeridos.Las aplicaciones
que usan estos servicios no deben depender de detalles
específicos del sistema para garantizar la portabilidad, incluso
dentro de una red heterogénea.

4. 3. Si los componentes manejan la comunicación ellos mismos, el
resultante enfrenta dependencias y limitaciones.
Por ejemplo:
Si el sistema es dependiente del mecanismo de comunicación
usadoLos clientes deben conocer la localización de los servidores, y
en muchos casos la solución es limitada a sólo un lenguaje de
programación.

5. 4. Los servicios para agregar, remover, intercambiar, activar y
localizar componentes también son requeridos.Las aplicaciones
que usan estos servicios no deben depender de detalles
específicos del sistema para garantizar la portabilidad, incluso
dentro de una red heterogénea.
5. Desde el punto de vista del desarrollador no debe haber
diferencia entre el desarrollo de software para sistemas
centralizados y desarrollar para sistemas distribuidos.
Por lo que no debe necesitar saber nada acerca de la
implementación de los detalles del objeto o acerca de su localización
física

6. Pregunta
 ¿Cómo estructuramos software distribuido de manera que los
usuarios del servicio no necesiten conocer la naturaleza y la
ubicación de los proveedores de servicios, haciendo fácil cambiar
dinámicamente los enlaces entre los usuarios y los proveedores?

7. Solución
 Introducir un componente Broker para
llevar acabo un mejor desacoplamiento
entre los clientes y servidores.

8. Definición
 “Es un patrón de arquitectura que se utiliza para estructurar sistemas
de software distribuidos con componentes desacoplados que
interactúan por invocaciones de servicios remotos.”
 El componente broker es responsable de coordinar la
comunicación; tanto de enviar/reenviar las peticiones, asi como de
transmitir los resultados y las excepciones.

9. Elementos - Cliente
 Son aplicaciones que acceden los servicios de, al menos, un
servidor.
 Para invocar servicios remotos, los clientes envían solicitudes al
broker. Después que la operación se ha ejecutado, los clientes
reciben respuestas o excepciones del bróker
 No necesitan conocer la ubicación de los servidores que acceden;
esto permite la agregación de nuevos servicios, y el movimiento de
los servicios existentes a otras ubicaciones, aún mientras el sistema
este ejecutándose.

10. Servidor
 Implementa objetos que exponen su funcionalidad a través de
interfaces que consisten de operaciones y atributos.
 Están disponibles a través de un lenguaje de definición de interfaz
(IDL) o un estándar binario.
Hay dos tipos de servidores:
 ofrecen servicios comunes a muchos dominios de aplicación.
 implementan una funcionalidad específica para un dominio de
aplicación particular.

11. Broker
 Es un mensajero, responsable de la transmisión de solicitudes de
clientes a servidores, así como de la transmisión de respuestas.
 Localiza al receptor de una solicitud basándose en un sistema de
identificadores únicos.

12. Proxy - Cliente
 Representan una capa adicional entre los clientes y el broker, para
proveer transparencia en el sentido que un objeto remoto aparece
como local ante el cliente, es decir esconden los detalles de
implementación.

13. Proxy - Servidor
Son responsables de:
 Recibir solicitudes
 Desempaquetar los mensajes de entrada
 El unmarshaling de los parámetros
 Llamar al servicio apropiado
 El marshaling* de resultados y excepciones antes de enviarlos al
cliente.
*Marshaling: transformar la representación en memoria de un objeto a
un formato apropiado para almacenaje o transmisión.

14. Puente
 Los puentes son componentes opcionales utilizados para esconder
los detalles de implementación cuando dos brokers interoperan.
 Supóngase que un sistema Broker se ejecuta en una red
heterogénea. Si se transmiten solicitudes sobre la red, se deben
comunicar brokers diferentes independientemente de las redes y
de los sistemas operativos utilizados.

15. Ejemplo
 El desarrollo del sistema de información de una ciudad (SIC) diseñado para
ejecutarse en una red de área amplia. utilizando un browser WWW.
 Los clientes son los browsers.Recuperan streams de datos desde los servidores httpd,
los interpretan, e inician acciones tales como el despliegue de documentos en la
pantalla, o la ejecución de applets de Java.Los servidores son servidores WWW que
proveen acceso a páginas HTML.
 Los servidores WWW se implementan como procesos demonios httpd que esperan la
entrada de solicitudes en puertos específicos. Cuando llega una solicitud al servidor,
se envía el documento solicitado y algunos datos adicionales al cliente.
 Un broker es la combinación de un gateway de Internet, y la infraestructura misma
de Internet. Cada intercambio de información entre un cliente y un servidor pasa a
través del broker. Un cliente especifica la información que requiere mediante URLs.
Utilizando estos identificadores únicos, el broker localiza los servicios requeridos, y
envía las solicitudes a los servidores apropiados. Cuando se agrega un nuevo
servidor, éste debe registrarse con el broker. Los clientes y servidores utilizan el
gateway de Internet como una interfaz al broker.
 Los browsers WWW y los servidores httpd proveen capacidades incorporadas para la
comunicación con el gateway del proveedor de Internet, así que, en este caso, no
es necesario preocuparse por los proxies.

16. Relaciones y Restricciones
 La relación de unión asocia clientes
(y, opcionalmente, proxies del lado
del cliente) y servidores (y,
opcionalmente, los proxies de
servidor) con brokers.
 El cliente sólo puede conectarse a
un broker (posiblemente a través de
un proxy del cliente). El servidor sólo
se puede unir a un broker
(posiblemente a través de un proxy
server-side).

17. Debilidades - Eficiencia Restringida
 Usualmente son más lentas que las aplicaciones cuya distribución
de componentes es estática y conocida.
 Los sistemas que dependen directamente de un mecanismo
concreto para la comunicación entre procesos también dan un
mejor desempeño que una arquitectura Broker

18. Baja Tolerancia a Fallos
 El broker puede ser un punto único de fallo.
 Un broker puede ser un objetivo para los ataques de seguridad.
 Si un servidor o un broker falla durante la ejecución de un
programa, Todas las aplicaciones que dependen del servidor o
broker no serán capaces de continuar satisfactoriamente.

19. Pruebas y Debugging
 Es tedioso debido a que el número de componentes implicados es
grande.
 Un Broker puede resultar complicado de probar

20. Tácticas - Disponibilidad
Recuperación de datos
 Redundancia activa (Hot spare)
 Redundancia pasiva (Warm spare)
 Spare (cold spare)
Detección
 Ping/Echo
 Excepciones

21. Modificabilidad
Prevención efecto dominó
 Ocultar información
 Manteniendo las interfaces
 Uso de intermediarios
Defer binding time
 Registro en runtime
 Reemplazo de componentes(servidores)

22. Seguridad
Resistiendo los ataques
 Autenticar usuarios
 Autorizar usuarios
 Mantener la confidencialidad de los datos
Detectando ataques
 Detección de intrusos
Recuperación de un ataque
 Restauración (Tacticas de disponibilidad)
 Identificación (Log de auditoría)

23. Variaciones del patrón – Sistemas
Broker de Comunicación Directa
 En esta variante los clientes pueden comunicarse directamente
con los servidores.
 El broker indica a los clientes los canales de comunicación que
provee el servidor, entonces el cliente puede establecer un enlace
directo al servidor solicitado.
 En estos sistemas, los proxies se encargan de las responsabilidades
del broker para manejar la mayoría de las actividades de
comunicación.

24. Sistemas Broker de Paso de
Mensajes
 Esta variante es apropiada para sistemas que se enfocan en la
transmisión de datos.
 Los servidores utilizan un tipo de mensaje para determinar lo que
deben hacer, en vez de ofrecer servicios que los clientes pueden
invocar.
 En este contexto, un mensaje es una secuencia de datos en bruto
junto con información adicional que especifica el tipo de mensaje,
su estructura y otros atributos relevantes.

25. Sistemas Broker Adaptadores
 Para aumentar la flexibilidad, se puede esconder la interfaz del
broker a los servidores utilizando una capa adicional, llamada capa
adaptadora, que es responsable de registrar e interactuar con los
servidores.

26. Sistemas Broker Negociantes
 Usualmente, un cliente envía una solicitud a un servidor identificado
en forma única, pero en algunas circunstancias los servicios y no los
servidores son el destino de las solicitudes de los clientes.
 En esta variante el broker debe conocer que servidores pueden
proveer un servicio especificado, y enviar la solicitud al servidor
apropiado.
 Sin embargo, los proxies del lado del cliente usan identificadores de
servicio en vez de identificadores de servidor para accesar a la
funcionalidad de los servidores. La misma solicitud puede enviarse a
varios servidores que implementen el mismo servicio.

27. Sistemas Broker Callback
 En vez de implementar un modelo de comunicación activa donde
los clientes producen solicitudes y los servidores las consumen, se
puede utilizar un modelo reactivo que se maneja por eventos sin
hacer distinción entre clientes y servidores.
 Cuando un evento llega, el broker invoca el método callback del
componente registrado para reaccionar ante ese evento, cuya
ejecución, a su vez puede generar nuevos eventos causando que
el broker dispare nuevas invocaciones de métodos callback.

28. Atributos de Calidad –
Interoperatibilidad
 Sistemas Broker diferentes pueden interoperar si entienden un
protocolo común para el intercambio de mensajes.
 Este protocolo es implementado y manejado por puentes, los
cuales son responsables de traducir el protocolo específico del
broker en un protocolo común, y viceversa.

29. La Transparencia de Ubicación
 Como el broker localiza un servidor utilizando un identificador único,
los clientes no necesitan conocer la ubicación de los servidores.
 De manera similar, los servidores no necesitan tomar en cuenta la
ubicación del cliente solicitante, ya que reciben todas las
solicitudes del componente broker local.

30. La Portabilidad
 El sistema Broker esconde el sistema operativo y los detalles del
sistema de red utilizando capas indirectas como APIs, proxies y
puentes.
 Cuando se requiera portar el sistema, es suficiente, en muchos
casos, portar el broker y sus APIs a una nueva plataforma, y
recompilar clientes y servidores.
 Si las capas más bajas esconden los detalles específicos del sistema
del resto del broker, sólo se requiere portar estas capas más bajas,
en vez de portar el broker completamente.

31. Extensibilidad
 Si los servidores cambian pero sus interfases permanecen sin
cambio, no se tiene impacto funcional sobre los clientes.
 Modificando la implementación interna del broker, pero no los APIs
que éstos proveen, no tiene efecto en clientes y servidores más que
cambios en el desempeño.

32. Reusabilidad
 Cuando se construyen nuevas aplicaciones cliente,
frecuentemente el desarrollador puede basar la funcionalidad de
su aplicación en los servicios existentes.
 Si están disponibles componentes que ofrecen servicios tales como
edición, visualización, impresión, acceso a bases de datos u hojas
de cálculo, no es necesario desarrollar nuevamente estos servicios,
sino integrarlos en la aplicación.

33. Usos
 CORBA: es una tecnología orientada a objetos para objetos distribuidos en
sistemas heterogéneos. Orbix, de IONA Technologies, usa la variante de
comunicación directa.
 SOM/DSOM de IBM: Es un sistema bróker compatible con CORBA que
implementa la interoperabilidad combinando el IDL de CORBA con un
protocolo binario.
 OLE de Microsoft: Define un formato estándar binario para exponer y acceder
a las interfaces del servidor.
 World Wide Web utiliza el patrón bróker para que los navegadores actúen
como intermediarios y los servidores de WWW como proveedores de servicios
 RMI de Sun: Tecnología para la invocación remota demétodos para la
plataforma Java.
 ATM-P de Siemens: Es la implementación de la variante de paso de mensajes
en sistemas de telecomunicaciones basados en Asynchronous Transfer Mode
(ATM).

34. Referencias
 Bass, L., Clements, P., & Kazman, R. (2013). Software Architecture in
Practice.
 Guardado Guzman, S. V. (2013). El Patrón Broker. Obtenido de
http://es.scribd.com/doc/143875290/El-Patron-Broker
 Mendoza Chapa, S. G. (1996). Seminario de Sistemas Distribuidos.
Broker.
 Rojas Rodríguez, M. (2010). Patrones Arquitectónicos para
Programación Distribuida. México D.F.