Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Patrón de Arquitectura
“Broker”
ANDRÉS FELIPE MONTOYA RÍOS
RE.VU/ANDRESMONTOYA
@MONTOYA118
Contexto
 Muchos sistemas se construyen a partir de un conjunto de servicios
distribuidos a través de varios servidores.
...
Problemas que ataca el patrón
1. Construir un sistema de software complejo como un conjunto de
componentes desacoplados e ...
3. Si los componentes manejan la comunicación ellos mismos, el
resultante enfrenta dependencias y limitaciones.
Por ejempl...
4. Los servicios para agregar, remover, intercambiar, activar y
localizar componentes también son requeridos.Las aplicacio...
Pregunta
 ¿Cómo estructuramos software distribuido de manera que los
usuarios del servicio no necesiten conocer la natura...
Solución
 Introducir un componente Broker para
llevar acabo un mejor desacoplamiento
entre los clientes y servidores.
Definición
 “Es un patrón de arquitectura que se utiliza para estructurar sistemas
de software distribuidos con component...
Elementos - Cliente
 Son aplicaciones que acceden los servicios de, al menos, un
servidor.
 Para invocar servicios remot...
Servidor
 Implementa objetos que exponen su funcionalidad a través de
interfaces que consisten de operaciones y atributos...
Broker
 Es un mensajero, responsable de la transmisión de solicitudes de
clientes a servidores, así como de la transmisió...
Proxy - Cliente
 Representan una capa adicional entre los clientes y el broker, para
proveer transparencia en el sentido ...
Proxy - Servidor
Son responsables de:
 Recibir solicitudes
 Desempaquetar los mensajes de entrada
 El unmarshaling de l...
Puente
 Los puentes son componentes opcionales utilizados para esconder
los detalles de implementación cuando dos brokers...
Ejemplo
 El desarrollo del sistema de información de una ciudad (SIC) diseñado para
ejecutarse en una red de área amplia....
Relaciones y Restricciones
 La relación de unión asocia clientes
(y, opcionalmente, proxies del lado
del cliente) y servi...
Debilidades - Eficiencia Restringida
 Usualmente son más lentas que las aplicaciones cuya distribución
de componentes es ...
Baja Tolerancia a Fallos
 El broker puede ser un punto único de fallo.
 Un broker puede ser un objetivo para los ataques...
Pruebas y Debugging
 Es tedioso debido a que el número de componentes implicados es
grande.
 Un Broker puede resultar co...
Tácticas - Disponibilidad
Recuperación de datos
 Redundancia activa (Hot spare)
 Redundancia pasiva (Warm spare)
 Spare...
Modificabilidad
Prevención efecto dominó
 Ocultar información
 Manteniendo las interfaces
 Uso de intermediarios
Defer ...
Seguridad
Resistiendo los ataques
 Autenticar usuarios
 Autorizar usuarios
 Mantener la confidencialidad de los datos
D...
Variaciones del patrón – Sistemas
Broker de Comunicación Directa
 En esta variante los clientes pueden comunicarse direct...
Sistemas Broker de Paso de
Mensajes
 Esta variante es apropiada para sistemas que se enfocan en la
transmisión de datos.
...
Sistemas Broker Adaptadores
 Para aumentar la flexibilidad, se puede esconder la interfaz del
broker a los servidores uti...
Sistemas Broker Negociantes
 Usualmente, un cliente envía una solicitud a un servidor identificado
en forma única, pero e...
Sistemas Broker Callback
 En vez de implementar un modelo de comunicación activa donde
los clientes producen solicitudes ...
Atributos de Calidad –
Interoperatibilidad
 Sistemas Broker diferentes pueden interoperar si entienden un
protocolo común...
La Transparencia de Ubicación
 Como el broker localiza un servidor utilizando un identificador único,
los clientes no nec...
La Portabilidad
 El sistema Broker esconde el sistema operativo y los detalles del
sistema de red utilizando capas indire...
Extensibilidad
 Si los servidores cambian pero sus interfases permanecen sin
cambio, no se tiene impacto funcional sobre ...
Reusabilidad
 Cuando se construyen nuevas aplicaciones cliente,
frecuentemente el desarrollador puede basar la funcionali...
Usos
 CORBA: es una tecnología orientada a objetos para objetos distribuidos en
sistemas heterogéneos. Orbix, de IONA Tec...
Referencias
 Bass, L., Clements, P., & Kazman, R. (2013). Software Architecture in
Practice.
 Guardado Guzman, S. V. (20...
Upcoming SlideShare
Loading in …5
×
Upcoming SlideShare
gps system and application in mining
Next
Download to read offline and view in fullscreen.

Share

Patron de Arquitectura Broker

Download to read offline

Presentacion del patron de arquitectura de software "Boker"

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Patron de Arquitectura Broker

  1. 1. Patrón de Arquitectura “Broker” ANDRÉS FELIPE MONTOYA RÍOS RE.VU/ANDRESMONTOYA @MONTOYA118
  2. 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. 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. 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. 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. 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. 7. Solución  Introducir un componente Broker para llevar acabo un mejor desacoplamiento entre los clientes y servidores.
  8. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.
  • ElideVicencioAyala

    Apr. 7, 2020
  • SynergyStudio

    Jan. 12, 2017

Presentacion del patron de arquitectura de software "Boker"

Views

Total views

8,337

On Slideshare

0

From embeds

0

Number of embeds

23

Actions

Downloads

114

Shares

0

Comments

0

Likes

2

×