FACULTAD DE INGENIERÍA Y ARQUITECTURA
CARRERA DE INGENIERÍA DE SISTEMAS
PATRONES (PARTE IV)
ARQUITECTURA DE SOFTWARE
ÁREA DE INGENIERÍA DE SOFTWARE
AGENDA
• Patrones de Componente y Conector (III)
• Arquitectura Orientada a Servicios
• Publicar-Suscribir
• Datos Compartidos
PATRONES DE ARQUITECTURA
Patrones de Patrones de Patrones de
Módulo Componentes Asignación
y Conectores
PATRONES DE COMPONENTE Y CONECTOR
Modelo-Vista-
Broker
Controlador
Cliente
Pipe-and-Filter
Servidor
PATRONES DE COMPONENTE Y CONECTOR
Arquitectura
Peer-to-Peer Orientada a
Servicios
Publicar-suscribir Datos compartidos
ARQUITECTURA ORIENTADA A SERVICIOS
• Contexto: Un gran número de servicios es ofrecido (y
descrito) por proveedores y consumido por un grupo de
clientes. Los clientes necesitan saber y utilizar estos servicios
sin un conocimiento detallado de su implementación.
• Problema: Cómo podemos soportar interoperabilidad de
componentes distribuidos corriendo en distintas plataformas
y escritos en diferentes lenguajes, provistos por diferentes
organizaciones y distribuidos en Internet. Cómo pueden
localizarse servicios y combinarse, manteniendo requisitos
de rendimiento, seguridad y disponibilidad.
ARQUITECTURA ORIENTADA A SERVICIOS
• Solución: El patrón SOA describe una colección de
componentes distribuidos que proveen y / o consumen
servicios. Componentes clientes y proveedores pueden
estar escritos en distintos lenguajes y plataformas.
• Clientes y proveedores están desplegados independientemente y
pueden pertenecer a distintas organizaciones.
• Los componentes tienen interfaces que describen los servicios
que solicitan de otros componentes y los que proveen.
• Los atributos de calidad de un servicio pueden ser especificados
en un acuerdo de nivel de servicio (SLA).
SOA - SOLUCIÓN
Visión General
• Procesamiento se consigue a través de un conjunto de componentes que cooperan y proveen y/o
consumen recursos en una red. La secuencia de interacciones es normalmente descrita con un
lenguaje de descripción de flujo de trabajo.
Elementos
• Proveedores de servicios: Incluyen restricciones de autorización y rendimiento (SLA).
• Consumidores de servicios: Directos o a través de intermediarios.
• ESB: Intermediario que puede direccionar o transformar mensajes.
• Registro de Servicios: Proveedores registran sus servicios y consumidores los “descubren”.
• Servidor de Orquestación: Coordina las interacciones basadas en lenguaje para procesos de
negocio (workflows).
• Conectores: SOAP, REST, asíncronos.
SOA - SOLUCIÓN
Relaciones
• Relación de conexión (attachment) de los diferentes tipos de componentes con sus respectivos
conectores.
Restricciones
• Los consumidores de servicios se conectan a proveedores de servicios. Pueden usarse
componentes intermedios como ESB, registro de servicios, servidores de orquestación, etc.
Debilidades
• Sistemas basados en SOA son complejos de construir.
• Difícil controlar la evolución de los servicios independientes.
• Impacto en el rendimiento relacionado con el middleware o los servicios (cuellos de botella).
REGISTRO DE SERVICIOS
REGISTRO DE SERVICIOS
ORQUESTACIÓN
ENTERPRISE SERVICE BUS (ESB)
PRINCIPALES CONECTORES
SOAP: Protocolo estándar de comunicación para web services.
Mensajes XML sobre HTTP.
REST: Utiliza los cuatro comandos básicos HTTP: POST, GET, PUT,
DELETE para gestionar recursos.
Mensajes Asíncronos (“fire-and-forget”): Participantes no esperan
por confirmación, se asume que se dejó el mensaje exitosamente.
PRINCIPALES CONECTORES
SOA - EJEMPLO
PUBLICAR-SUSCRIBIR
• Contexto: Un número independiente de productores y
consumidores de datos deben interactuar. No está
determinado de antemano el número ni la naturaleza de
ellos, ni los datos que compartirán.
• Problema: Cómo crear mecanismos de integración que
soporten la habilidad de transmitir mensajes entre
productores y consumidores de forma que ninguno de ellos
esté enterado de la identidad del otro (o potencialmente de
su existencia).
PUBLICAR-SUSCRIBIR
• Solución:
• Componentes interactúan anunciando mensajes (o eventos).
• Los componentes se suscriben a un conjunto de eventos.
• La infraestructura detrás del esquema publicar-suscribir debe
asegurarse de que todos los suscriptores sean notificados cuando
se produce un evento.
• Asegurando que cada componente ignore la identidad de los otros
se pueden realizar modificaciones al sistema de forma más
sencilla (agregar o quitar productores o consumidores de datos).
PUBLICAR-SUSCRIBIR
PUBLICAR-SUSCRIBIR (SOLUCIÓN)
Visión General
• Los componentes publican y se suscriben a eventos. Cuando un evento es anunciado por un
componente, la infraestructura del conector dispara el evento a todos los suscriptores registrados.
Elementos
• Cualquier componente que posea por lo menos un puerto para publicar o suscribir.
• Los puntos por analizar incluyen qué eventos se publican y la granularidad de los mismos.
• El conector publicar-suscribir tendrá roles de anunciar y escuchar a los componentes que deseen
publicar y suscribirse a eventos.
PUBLICAR-SUSCRIBIR (SOLUCIÓN)
Relaciones
• Relación de conexión (attachment) entre los componentes y el conector publicar-suscribir al
prescribir qué componentes anuncian eventos y qué componentes están registrados para recibir
eventos.
Restricciones
• Qué componentes pueden recibir qué eventos.
• Cuántos conectores publicar-suscribir pueden existir en un sistema.
• Un componente puede publicar o puede suscribirse, teniendo puertos de ambos tipos.
Debilidades
• Incrementa la latencia y tiene un efecto negativo en la escalabilidad y predictibilidad del tiempo
de llegada del mensaje.
• Menor control sobre el orden de los mensajes; adicionalmente, la llegada de mensajes no está
garantizada.
PUBLICAR-SUSCRIBIR
Publicar-suscribir basado en listas: Cada productor maneja una lista de
suscriptores. Menos mantenible, mejor rendimiento.
Publicar-suscribir basado en transmisión (broadast): Productores no tienen
conocimiento de los suscriptores. Suscriptores determinan si los eventos
publicados son de interés.
Publicar-suscribir basado en contenido: Basado en tópicos. Tópicos son
eventos predefinidos o mensajes. Un componente se suscribe a todos los
elementos del tópico. A nivel de contenido se tiene una asociación con
características particulares del suscriptor, solo se recibirá el evento si hay
coincidencia
PUBLICAR-SUSCRIBIR (EJEMPLO)
PUBLICAR-SUSCRIBIR (EJEMPLO)
DATOS COMPARTIDOS
• Contexto: Varios componentes requieren manipular grandes
volúmenes de datos que no pertenecen de forma exclusiva a
ninguno de ellos.
• Problema: Cómo podemos almacenar y manipular datos
que son accedidos y procesados por múltiples componentes
independientes.
• Solución: Interacciones consisten en el intercambio de
datos entre componentes y por lo menos un repositorio de
datos compartidos.
DATOS COMPARTIDOS
• Solución:
• Se tienen conectores de lectura y escritura de datos.
• Los componentes (data accessors) realizar operaciones que
requieren datos del repositorio compartido y escriben los
resultados a uno o más repositorios de datos.
• En un sistema de datos compartidos “puro”, la única forma de
interacción entre los componentes es a través de los repositorios
compartidos.
• Los componentes de almacenamiento de datos proveen
persistencia, manejan acceso concurrente a través de la gestión
de transacciones, soportan control de acceso, etc.
DATOS COMPARTIDOS - SOLUCIÓN
Visión General
• Comunicación entre componentes se reliza a través de un repositorio de datos compartidos.
Elementos
• Repositorio de datos compartidos: Decisiones relacionadas a los tipos de datos almacenados,
propiedades relacionadas al rendimiento y número de componentes permitidos para la interacción.
• Componente de acceso a datos (data accessor).
• Conector de lectura y escritura de datos: Decisiones tienen que ver con si el componente es
transaccional o no, así como los lenguajes de lectura / escritura, protocolo, semántica, etc.
DATOS COMPARTIDOS - SOLUCIÓN
Relaciones
• Relación de conexión (attachment) entre los componentes de acceso a datos y los repositorios
de datos compartidos.
Restricciones
• Los componentes de acceso a datos interactúan con los repositorios de datos.
Debilidades
• El repositorio de datos compartidos puede ser un cuello de botella a nivel de rendimiento.
• El repositorio de datos compartidos puede llegar a ser el punto único de fallo del sistema.
• Productores y consumidores de datos pueden llegar a estar altamente acoplados.
DATOS COMPARTIDOS
• Datos compartidos: Sistema corporativo
de gestión de accesos.