21/04/2015. Componentes. SOAP vs REST

Transcripción

1 Oriented Architecture (SOA) Definición La funcionalidad es realizada por un conjunto de componentes cooperando que proveen o consumen servicios sobre una red. La funcionalidad es, en algunos casos, descripta a través de un lenguaje de workflows. SOA describe una colección de componentes distribuidos que proveen y/o consumen servicios. Los componentes proveedores de servicios y los componentes consumidores de servicios pueden usar diferentes lenguajes y plataformas de implementación. Los servicios son, en gran medida, instalados independientemente Los servicios pertenecen, frecuentemente, a diferentes sistemas y organizaciones. Oriented Architecture Componentes Provider Son componentes independientes con una interfaz en la que describen qué operaciones proveen. Corren sobre su propio thread y/o proceso. Pueden estar implementados en distintas plataformas/tecnologías También pueden ser consumidores Consumer Componentes que requieren el uso de otros servicios para cumplir su propósito. Intermediario Intermediario Componente especializado que actúa como mediador entre los providers y los consumers. Buscar Publicar Consumer Llamar Contrato del Servicio Provider Arquitectura y Diseño de Sistemas 86 Arquitectura y Diseño de Sistemas 87 Oriented Architecture Conectores Protocolo estándar de Web s Consumers y providers interactúan intercambiando mensajes XML del tipo requerimiento/respuesta sobre HTTP Está acompañado por un conjunto de estándares (WS*): WS-Transaction, UDDI, WS-Reliability, BPEL Representational State Transfer () El consumer envía requerimientos HTTP no bloqueantes 4 comandos básicos: POST (crear), GET (recuperar), PUT (actualizar), DELETE (eliminar) Mensajes asincrónicos Intercambio a través de eventos. Los participantes no tienen que esperar un reconocimiento de recepción. Se asume que la infraestructura entregará el mensajes exitosamente. Pueden ser del tipo point-to-point o publish-subscriber Implementaciones: IBM s WebSphere MQ, Microsoft MSMQ, Apache ActiveMQ Oriented Architecture vs Origen Transmisión de Mensajes Restricciones Sistema de tipos Semántica Tradeoffs QoS Modelo RPC de llamadas entre aplicaciones HTTP y RPC Otros protocolo posibles. Muchos aspectos a resolver: seguridad, transacciones, interpretación de mensaje, esquema de direccionamiento Simple, comparable al de muchos lenguajes de programación Las aplicaciones interactuando necesitan acordar cómo interpretar los mensajes Completitud Estandarización de la Interoperabilidad Mensajes estructurados WS* tiene soporte para seguridad, disponibilidad, transaccionalidad, etc. Modelo client-server sobre HTTP HTTP Pocas. Único esquema de direccionamiento (URI), operaciones limitadas (CRUD) No tiene Si bien la sintaxis es bastante autodescriptiva, no está garantizada Simplicidad Overhead mínimo Performance No brinda soporte intrínseco. Apropiado para operaciones read-only Arquitectura y Diseño de Sistemas 88 Arquitectura y Diseño de Sistemas 89 Oriented Architecture vs Ejemplo Servicio de agenda que permite encontrar a una persona a partir de un identificador <?xml version="1.0"?> <soap:envelope xmlns:soap= soap:encodingstyle=" <soap:body pb=" <pb:getuserinfo> <pb:useridentifier>99999</pb:useridentifier> </pb:getuserinfo> </soap:body> </soap:envelope> Oriented Architecture Intermediarios Enterprise Server Bus (ESB) Rutea mensajes entre proveedores y consumidores. Además: Convierte mensajes de un protocolo (o tecnología) a otro Realiza transformaciones sobre los datos Realizar chequeos de seguridad Maneja transacciones Promueve interoperabilidad, seguridad y modificabilidad Servicio 1 Servicio 2 Servicio 3 Enterprise Bus (ESB) RMI/IIOP MQ/JMS Servicio 1 Servicio 2 Servicio 3 Arquitectura y Diseño de Sistemas 90 Arquitectura y Diseño de Sistemas 91 1

2 Oriented Architecture Oriented Architecture Registry Orchestration Server Componente que permite que los servicios se registren en ejecución, mejorando la independencia de los proveedores de servicio Permite el descubrimiento en ejecución de los servicios Promueve la modificabilidad y el ocultamiento de la identidad y ubicación del service provider. Puede permitir múltiples versiones del mismo servicio Orquesta la interacción entre varios consumers y providers de servicios. Ejecuta scripts ante la ocurrencia de un evento específico (BPEL, BPMN, etc) Permite crear nuevos servicios a partir de otros más granulares. Útil para aplicaciones con procesos de negocio bien definidos o workflows que involucran interacciones con componentes o sistemas distribuidos Favorecen la modificabilidad, interoperabilidad y confiabilidad Ejemplos: jbpm, Mule Enterprise, BizTalk, Oracle BPM, Orchestra Registry Obtiene la información del servicio Registra la descripción y ubicación del servicio Consumer Usa el servicio Provider Arquitectura y Diseño de Sistemas 92 Arquitectura y Diseño de Sistemas 93 Oriented Architecture Oriented Architecture Beneficios Interoperabilidad: Permite comunicar sistemas implementados en distintas plataformas, incluyendo sistemas a través de Internet. Reconfiguración dinámica: Permite reemplazar o agregar versiones de componentes sin interrupción (registry y ESB) Ejemplo: Adventure Builder Potenciales Problemas Complejidad en el diseño e implementación, debido al binding dinámico y el uso de metadata. Overhead en la performance del middleware (intermediario) que se interpone entre servicios y clientes Carencia de garantía de performance, ya que los servicios se comparten y no están bajo el control del cliente. OPC: Order Processing Center Arquitectura y Diseño de Sistemas 94 Arquitectura y Diseño de Sistemas 95 Oriented Architecture Ejemplo: Migración a SOA Map-Reduce Motivación En la actualidad, las organizaciones necesitan analizar rápidamente grandes volúmenes de datos que generan en un orden de petabytes. Interacciones en redes sociales Repositorios de datos o documentos masivos Pares <origen, destino> para un motor de búsqueda. Se debe asegurar eficiencia y resiliencia con respecto a fallas en el hw. Arquitectura y Diseño de Sistemas 96 Arquitectura y Diseño de Sistemas 97 2

3 Map-Reduce Map-Reduce provee un framework para analizar un conjunto de datos grande y distribuido, que se ejecutará en paralelo sobre un conjunto de procesadores. Este paralelismo permite baja latencia y alta disponibilidad Partes requeridas Una infraestructura especializada que se encargue de: Alocar los componentes de sw a los nodos de hw en un ambiente de computación masivamente parelelo, asegurando disponibilidad y failover. Manejar el ordenamiento de los datos como se necesite Dos funciones: map y reduce, definidas en términos de tuplas Map-Reduce Funcionamiento Función Map Map(k1,v1) -> list(k2,v2) Toma una lista de pares en un dominio de datos y devuelve una lista de pares en un dominio diferente (datos intermedios). Su propósito es filtrar el data set, determinando si un registro va a estar involucrado en el procesamiento posterior. k2 es importante ya que será usada para ordenar (agrupar) los datos de salida de esta función Es aplicada en paralelo a cada ítem (o lote de ítems) de la entrada de datos El resultado de esta función es tomado por la infraestructura que junta los pares con la misma clave y los agrupa, creando un grupo por c/u de las claves. Arquitectura y Diseño de Sistemas 98 Arquitectura y Diseño de Sistemas 99 Map-Reduce Map-Reduce Funcionamiento (cont) Funcionamiento (cont) Reduce(k2, list (v2)) -> list(v3) Es aplicada en paralelo a cada grupo, produciendo una colección de valores para cada dominio El conjunto de datos de salida es siempre mucho más chico que el de entrada Arquitectura y Diseño de Sistemas 100 Arquitectura y Diseño de Sistemas 101 Map-Reduce Map-Reduce Ejemplo: Contador de palabras Objetivo: Contar las ocurrencias de cada palabra en un conjunto de documentos Función Map map(string name, String document): // clave: nombre del documento // valor: contenido del documento for each word w in document: Emit(w, 1); reduce(string word, Iterator partialcounts): // word: una palabra // partialcounts: una [[Iterador (patrón de // diseño) lista parcial]] para realizar cuentas // agregadas int result = 0; for each v in partialcounts: result += ParseInt(v); Emit(word,result); Divide un documento en palabras (mediante el empleo de un analizador léxico) y emite una serie de tuplas <clave, valor> donde: Clave: palabra Valor: 1 Ejemplo: "La casa de la pradera < la,1> < casa,1> < de,1> < la,1> < pradera,1> La infraestructura reúne todos los pares con la misma clave y alimenta a la función Reduce La función realiza el conteo de las ocurrencias de una palabra Arquitectura y Diseño de Sistemas 102 Arquitectura y Diseño de Sistemas 103 3

4 Map-Reduce Ejemplo: Contador de palabras (cont.) Map-Reduce Ejemplo: Contactos por edad Objetivo: Imaginemos una BD de 1.100M de personas de una red social y queremos obtener la cantidad de contactos promedio por edad. Función Map function Map is input: integer K1 between 1 and 1100, representing a batch of 1 million social.person records for each social.person record in the K1 batch do let Y be the person's age let N be the number of contacts the person has produce one output record (Y,(N,1)) repeat end function function Reduce is input: age (in years) Y for each input record (Y,(N,C)) do Accumulate in S the sum of N*C Accumulate in Cnew the sum of C repeat let A be S/Cnew produce one output record (Y,(A,Cnew)) end function Arquitectura y Diseño de Sistemas 104 Arquitectura y Diseño de Sistemas 105 Map-Reduce Ejemplo: Contactos por edad (cont) 1100 procesadores Map producirán M de registros (Y,(N,1)), donde Y va entre 8 y procesadores Reduce Ordenarán los resultados por edad Cada Reduce recibirá millones de registros correspondientes a la edad que procesa Como resultado, se producirán 96 registries (Y,A), donde A es el promedio de contactos para las persona de edad Y. Equivalente SQL (no escala) SELECT age, AVG(contacts) FROM social.person GROUP BY age ORDER BY age Map-Reduce Arquitectura Organización Existe un cluster de máquinas que oficiarán de workers dentro de la solución Map-Reduce Generalmente la cantidad instancias a utilizar es configurable Uno de los workers toma el rol de master, encargándose de: Recopilar los workers en reposo (sin tarea asignada) Asignar tareas a los workers, ya sea de map() o de reduce() El worker puede tener 3 estados: reposo, trabajando, completo Tolerancia a fallos El master monitorea el estado de los workers a través de un ping periódico Si un worker no responde, se lo considera desactivado Si ya había terminado una tarea map(), esta vuelve a se elegible para procesamiento, ya que su resultado fue escrito a disco local y sería inaccesible. En este caso, las tareas reduce() son notificadas para que descarten datos del worker fallido. Si estaba ejecutando una tarea map() o reduce(), se resetea su estado para que sea reasignada Arquitectura y Diseño de Sistemas 106 Arquitectura y Diseño de Sistemas 107 Map-Reduce Cuándo NO es apropiado este patrón? Si no existen grandes volúmenes de datos El overhead de Map-Reduce no se justifica Si no se puede dividir el conjunto de datos inicial en subconjuntos de tamaño uniforme Las ventajas del paralelismo se diluyen Si se tienen operaciones que requieren múltiples reduces Aunque es posible, también es más difícil de orquestar. Implementaciones Apache Hadoop Couchdb Infinispan MongoDB Arquitectura y Diseño de Sistemas 108 Multi-Tier Motivación En un deployment distribuido, frecuentemente existe la necesidad de distribuir la infraestructura de un sistema en subconjuntos distintos. Esto puede ser por razones operativas o de negocio Las estructuras de ejecución de muchos sistemas están organizadas como agrupaciones lógicas de componentes. A cada agrupación se la denomina tier Cada tier puede estar basado en distintos criterios: Tipo de componente Compartir el mismo ambiente de ejecución Tener el mismo propósito en ejecución Introducen restricciones topológicas que indican qué componentes pueden comunicarse con otros Conexión entre componentes dentro de un mismo tier Conexión entre componente de tiers adyacentes Por ejemplo: call-return en una dirección, pero notificaciones basadas en eventos en la otra. Arquitectura y Diseño de Sistemas 109 4

5 Multi-Tier Fortalezas Seguridad Disponibilidad Modificabilidad Multi-Tier Ejemplo: Generic multi-tier Debilidades Costo y complejidad Para sistemas simples, los beneficios pueden no justificar sus costos iniciales y de mantenimiento Hardware, software y complejidad de diseño e implementación Component & Conector o Alocación? Depende del criterio usado para definir los tiers. Ejemplos: Los tiers agrupan componentes de similar funcionalidad (C&C) Un client tier en un sistema empresarial no correrá en el mismo host que la base de datos. (alocación) Arquitectura y Diseño de Sistemas 110 Arquitectura y Diseño de Sistemas 111 Multi-Tier Multi-Tier Ejemplo: Generic JEE application tiers Ejemplo: Multi-tiered Consumer Website en JEE Arquitectura y Diseño de Sistemas 112 Arquitectura y Diseño de Sistemas 113 5