parte_11.txt

Sara Blanc Clavero 6 TEMARIO OPOSICIONES COIICV | TEMA 25 1.3. La relación entre consumidor y proveedor La relación entre un consumidor y un proveedor se e stablece a través de un contrato en el que se describen las características del servicio subscrit o. Una relación implica que va a existir un in...

Sara Blanc Clavero 6 TEMARIO OPOSICIONES COIICV | TEMA 25 1.3. La relación entre consumidor y proveedor La relación entre un consumidor y un proveedor se e stablece a través de un contrato en el que se describen las características del servicio subscrit o. Una relación implica que va a existir un intercambio de mensajes entre proveedor y consumidor. Pero el responsable del contrato puede ser una tercera entidad implicada: el proveedor con tractual o bróker (Figura 4). A modo de gestor o agente, esta entidad es la que establece las relaci ones contractuales y asume la responsabilidad de publicación del servicio y del intercambio de me nsajes. Está claro, además, que para que exista una relación entre servicios los mensajes deben ase gurar la interoperabilidad sintáctica en sus formatos, y la semántica en sus contenidos. Servicio Consumidor Servicio Proveedor del contrato Servicio Proveedor Figura 4. La figura del proveedor contractual (o br óker del servicio) El consumidor de un servicio es, por su parte, quie n debe descubrir el servicio o servicios que le interesan e invocarlos para iniciar el intercambio de mensajes cara a establecer el contrato. Hay tres principios sobre la relación proveedor-consumi dor en la arquitectura SOA: • Independencia de dominios. Tanto proveedor como con sumidor pueden ser parte del mismo sistema o de diferentes sistemas. El principi o de interoperabilidad previene la falta de entendimiento en caso de la deslocalización de l os servicios. • Independencia de plataformas de desarrollo. Cada se rvicio actúa como una caja negra de cara al resto de servicios siendo transparente al c onsumidor la plataforma, lenguaje y otros componentes relacionados con la implementación que sustenten el servicio. • Independencia de protocolos de mensajería. De nuevo , el principio de interoperabilidad establecido en la arquitectura debe proveer de meca nismos para la transformación de los mensajes a los formatos adecuados sin que esto corr esponda a los propios servicios, pudiendo así un proveedor establecer un contrato co n distintos consumidores que actúen sobre distintas plataformas. Entonces ¿cuál es la diferencia entre servicios SOA y servicios Web? (14) Si bien los protocolos y estándares existentes para servicios web se pueden aplicar y se ha aplicado en numerosas ocasiones al desarrollo de servicios SOA por sus fa cilidades en la publicación e invocación de servicios así como en la interoperabilidad entre pl ataformas, no todos los servicios web se han Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Arquitectura SOA TEMARIO OPOSICIONES COIICV | TEMA 25 7 diseñado atendiendo a todos los principios SOA. No existe una reciprocidad directa, pero sí comparten muchos principios fundamentales. Siguiendo con el tándem proveedor-consumidor, para que un consumidor pueda descubrir servicios sobre un sistema, el registro de servicios es una parte fundamental de la arquitectura SOA (Figura 5). Un servicio se registra utilizando su descripción. El mantenimiento de este registro es parte de las obligaciones del gobierno de TI qui en deberá establecer los mecanismos tanto de control de acceso al registro como sobre las accion es de gestión del registro incluyendo la definición de la forma descriptiva, el aseguramient o en la coherencia y cohesión de los descriptores, la inclusión de nuevos servicios, su clasificación e eliminación del registro o la modificación y actualización de su descripción. Servicio Consumidor Servicio Proveedor Registro de servicios Descubrimiento (petición) Descubrimiento (respuesta) Registro (petición) Registro (respuesta) Figura 5. El concepto de Registro de Servicios Por tanto, ¿qué componentes tendrá un servicio? Par a ser compatible con la arquitectura SOA un servicio se compone de tres partes fundamentales qu e son: su lógica, su descripción y su interfaz . 1) La lógica siempre es única e identifica plenamen te al servicio. A la lógica le podríamos añadir también, y deberíamos, la calidad de servicio hacie ndo referencia así no sólo a su funcionalidad (o alcance funcional) sino a la globalidad de sus requ isitos, tanto funcionales como no funcionales. Un requisito no funcional especifica características r elativas a la operación de un sistema como, por ejemplo, características de usabilidad, disponibili dad, seguridad, fiabilidad, etc. (ver ISO/IEC 9126) . 2) Por otra parte, la descripción de un servicio po dría y debería ser única: una descripción identific a a un único servicio. Esta característica está vincu lada a los principios de reutilización y de lógica agnóstica. Quiere decir, que la lógica define el pr opósito del servicio, despojándose de cualquier referencia a tecnologías o “detalles técnicos”. Cua nto mayor sea el nivel de abstracción en la lógica del servicio más potenciaremos dos ventajas. Primer a, será posible modificar la componente tecnológica del servicio (protocolos, lenguajes, et c.) sin modificar su descripción. Segunda, mayor provecho se le podrá dar a este servicio ya que con la misma descripción será útil para una multiplicidad de consumidores potenciales. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Sara Blanc Clavero 8 TEMARIO OPOSICIONES COIICV | TEMA 25 3) En cuanto a la interfaz, está claro que en algún sitio debe residir la convergencia entre protocolos. Es recomendable que esta convergencia o curra en una capa de integración, transversal a toda la arquitectura, aunque está cla ro que siempre existirá una vinculación entre las interfaces de los servicios y los principios de int egridad. Por encima de los servicios, ya sean simples o comp uestos, y de sus relaciones se definen las tareas. Una tarea es una acción atómica realizada n ormalmente a instancias de un actor humano. La composición de tareas implementa procesos de neg ocio, a veces simples como una secuenciación de tareas, a veces complejos con bifu rcaciones condicionales. En el estándar ISO 18384 se diferencian tres estilos de composición de tareas: orquestación, coreografía y colaboración. • La orquestación implica un flujo de tareas (workflo w) gestionada por un elemento externo a la composición, el orquestador. Este “director de l a orquesta” es el encargado de establecer la secuencia orquestada de ejecución de tareas que puede estar condicionada a variables como el tiempo o la ocurrencia de eventos externos o de la propia secuencia. • La coreografía no orquesta flujos de tareas sino es tablece relaciones entre tareas mediante patrones de intercambio de datos. Por ejemplo, a mo do de diagrama de relaciones, los datos generados por una tarea pueden identificarse de un tipo determinado establecido como tipo de entrada de otras tareas relacionadas p ero sin que esto suponga necesariamente una secuencialización entre la tarea generadora y la receptora. Al igual que antes, la coreografía también es gestionada por un elemento externo al proceso. • Finalmente, la colaboración no es gestionada por ni ngún elemento externo sino que se define como la compatibilidad entre tareas, dejando que estas se ejecuten de manera independiente estableciéndose relaciones puntuales, si fuera necesario, entre algunas de ellas si tienen capacidad para ello. Esta relación es la más alejada de un buen planteamiento SOA. 2. Modelo de referencia SOA El modelo de referencia de la arquitectura SOA es i ndependiente de cualquier implementación tecnológica. Aunque más adelante veremos que hay te ndencias, cualquier implementación debería seguir el modelo que aquí estudiamos: un modelo en 9 capas. 2.1. Arquitectura de capas En la Figura 6 vemos que hay 5 capas que se sostien en de forma vertical, mientras que las otras 4 son transversales a toda la arquitectura. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Arquitectura SOA TEMARIO OPOSICIONES COIICV | TEMA 25 9 Capa de operatividad Capa de componentes Capa de servicios Capa de los procesos de negocio Capa del consumidor Integración Información QoS Gobierno Figura 6. Capas de la arquitectura SOA Capa 1 o de operatividad . Esta capa incluye los sistemas operacionales que existan o puedan existir ya en el entorno TI empresarial. Incluye si stemas empresariales, sistemas transaccionales, bases de datos, sistemas industriales, sistemas de sensorización, etc. Capa 2 de componentes . Es la capa de abstracción de los sistemas operaci onales a la capa de servicios. Transforma el operativo en lógica, desvi nculando el servicio de la tecnología concreta, protocolo o técnica del sistema operacional. Esta c apa debe de prevenir la redundancia de componentes, pudiendo agrupar un mismo componente ( que realmente ya es un servicio) la lógica de varios sub-sistemas. Como ventaja, los sistemas de la capa 1 podrán mejorarse, cambiarse y sufrir transformaciones sin que los servicios exist entes deban modificarse. Si el cambio además supone agregar una nueva funcionalidad, se podrán d efinir nuevos servicios en esta capa para integrar dicha funcionalidad en los procesos de neg ocio. Capa 3 de servicios . Esta capa puede verse como un conjunto de sub-cap as, tal como se representa en la Figura 1. Los servicios pueden sub ir en complejidad en función del tratamiento y procesamiento de la información. Por ejemplo, los s ervicios más bajos en esta capa pueden explotar las funcionalidades derivadas de la capa 2 de manera atómica, mientras que en servicios superiores se procesa la información agregando, cru zando o combinando datos de servicios del entorno empresarial y externos. Capa 4 de procesos de negocio . Un proceso de negocio es una representación TI de varias actividades (tareas) coordinadas con un objetivo de negocio. En esta capa los procesos pueden ser orquestados o coreografiados. Los datos y la in formación fluye en etapas y genera respuestas que interesan al consumidor: la capa por encima de ésta. Capa 5 del consumidor . Algunos autores la identifican como de visualizac ión, aunque el estándar es más amplio y generaliza a cualquier aplicación e specializada sobre los procesos de negocio. El objetivo de esta capa es normalizar el método de ac ceso a los datos procesados con el fin de poder generar rápidamente los front-end de visualiz ación, interacción y explotación de resultados. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Sara Blanc Clavero 10 TEMARIO OPOSICIONES COIICV | TEMA 25 Capa 6 de integración . Esta capa debe implementar en la arquitectura la capacidad de proveer. Se basa en tres principios: mediación, enrutamiento y transformación (de datos/formatos). Además, es en esta capa donde se mantiene el registro de se rvicios. La capa de integración también controla aspectos no funcionales de la transferenci a entre capas tales como la latencia. Una representación de esta capa es el ESB (Enterprise S ervice Bus o Bus de Servicio Empresarial) que proporciona facilidades para la implementación de l a arquitectura. Aunque no necesariamente complejo, este middleware debe estar orientado a ag ilizar la creación de servicios y contratos y reducir el acoplamiento entre el servicio provisto y el medio de transporte para que los mensajes sean unidades independientes del servicio. Capa 7 de QoS . Esta capa proporciona las facilidades necesarias para sostener los requisitos no funcionales de la arquitectura conocidos también po r requisitos de calidad. Si ponemos algunos ejemplos de estos requisitos podemos nombrar la seg uridad, fiabilidad, robustez, estabilidad, usabilidad, testabilidad, mantenimiento, documentac ión, escalabilidad, etc. Capa 8 de información . Esta capa debe asegurar la representación y trata miento de datos e información bajo las directrices de la arquitectura SOA. Por eso, en cada capa de las que hemos visto hasta ahora hay una pieza de esta capa que se extiende transversalmente. Capa 9 de gobierno . Es la capa de responsabilidad sobre la definición de la arquitectura, su diseño, creación e implementación de servicios, man tenimiento y sostenibilidad del sistema empresarial resultante. A modo de referencia, el estándar propone una relac ión entre competencias y requisitos que definen las capas que hemos descrito y bloques de i mplementación que las soportan (Figura 7). Adoptar SOA debe ser estratégico y no un capricho. La adopción de SOA viene motivada unas necesidades organizativas claramente identificadas. Por tanto, el alcance de la solución SOA que se plantee se podrá definir en base a los requisito s identificados en respuesta a esas necesidades. La capacidad empresarial y tecnológica de la organi zación restringen o limitan la adopción de soluciones. Soluciones que describen las capacidade s esperadas de la arquitectura a implantar. Siguiendo con la figura, estas capacidades se model an en elementos concretos sobre las capas de la Figura 6: los bloques a construir por capa. Los bloques de implementación son los distintos módulos que soportan las expectativas definidas en cada capa así como las interfaces de conexión entre capas. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Arquitectura SOA TEMARIO OPOSICIONES COIICV | TEMA 25 11 Capacidades TI Capacidades empresariales Necesidades (requisitos) Capacidades de la arquitectura Capas de la arquitectura Bloques a construir por capa Soportadas por las Definición de Asumir Consolidadas sobre Diseño de Implementación de Figura 7. Relación entre competencias, requisitos, capas y bloques de implementación. 2.2. Ciclo de vida de un servicio SOA El ciclo de vida SOA de un servicio tiene varias et apas que se asemejan al waterflow de las fases del desarrollo de software, por ejemplo, podrían se r: definición, modelado, implementación, verificación del servicio, ensamblaje con el sistem a, validación sobre el sistema y mantenimiento. Sin embargo, el ciclo de vida no se define con una temporalidad finita, sino como un ciclo vivo y enlazado con el ciclo de mejora continua del sistem a empresarial. Extendiendo este modelo reducido del ciclo de vida, el SOA School (15) propone 10 etapas concretas gestionadas por el gobierno de SOA. Las e tapas son: • Análisis de inventario. Cuál es el alcance de nuest ro inventario actual, cuáles son las prioridades y cómo evitamos desde el inicio la dupl icidad, redundancia o ambigüedad de servicios para ahorrar tiempo y costes en las sigui entes etapas. • Análisis y modelado del servicio, incluyendo la ide ntificación de composiciones y utilidad del servicio. • Diseño del contrato que se asociará a la provisión de este servicio. • Diseño de la lógica del servicio, incluyendo el con trol del acceso al servicio. • Desarrollo o implementación del servicio. • Testeo de los requerimientos funcionales y no funci onales del servicio. • Revisión del desarrollo, validación sobre la arquit ectura, certificación y aseguramiento de las reglas de mantenimiento. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Sara Blanc Clavero 12 TEMARIO OPOSICIONES COIICV | TEMA 25 • Lanzamiento de la monitorización del servicio. • Publicación del servicio en el registro de servicio s. • Revisión de versiones y mejora continua. 2.3. Ecosistemas SOA La participación en ecosistemas SOA se centra en có mo las organizaciones empresariales atienden sus necesidades (Figura 7) en un sistema p lural con múltiples dominios, donde cada dominio puede ser una empresa independiente, una di visión, un área comercial, un conjunto de usuarios (desligados de la empresa), etc. El objetivo de un servicio SOA es el de dar una sol ución efectiva a una necesidad dentro del ecosistema. Cualquier tecnología o infraestructura creada para soportar este servicio es parte del ecosistema SOA. Los actores SOA son aquellos que interactúan intern amente con el sistema y participan en la identificación de necesidades y nuevos requisitos, desde usuarios y TI hasta gobierno. Pero además de los actores, cualquier “stakeholder” o in teresado toma parte en la identificación de necesidades y soluciones a través de su implicación como proveedor, contratista, mediador, socio, cliente, etc. y por tanto, es parte también de la e structura social SOA. El diseño del ecosistema potencia las relaciones entre clientes y proveedore s, mejora la productividad de los empleados y soporta eficientemente la toma de decisiones. La visión del ecosistema SOA se puede centrar en un a única organización empresarial o en una malla con más de una organización o una pluralidad de individuos. Por ejemplo, imaginemos cualquier asociación, empresa, corporación empresar ial o agencia gubernamental. Cualquiera de estas estructuras (u otros muchos ejemplos) interac túan con otras estructuras a través de acuerdos, contratos, negociados o reglas de mercado para obtener un beneficio mutuo. Bajo la misma perspectiva, un ecosistema SOA incluye esta d iversidad de dominios que interactúan a través de agentes software a cambio de un beneficio mutuo. Por ejemplo, como expone Microsoft en una de sus pu blicaciones al respecto de SOA (11), imaginemos una empresa cuya gestión de pedidos invo lucra a los departamentos de ventas, almacén y logística. Vayamos más lejos y supongamos también que tanto el almacenaje como el transporte de los pedidos están externalizados. Ten emos tres dominios internos implicados (los departamentos) y tres dominios empresariales. Sumem os también que en la cadena de transporte desde que un cliente realiza un pedido hasta que el producto llega a su destino contiene un alto número de pasos manuales. El resultado final de est e puzle puede estar muy lejos de las expectativas más pesimistas en cuanto a eficiencia. En un escenario como este, construir un ecosistema basado en la aceptación de contratos y l a generación de servicios facilitará el flujo automatizado de la información, sin retrasos, pérdi das o réplicas debidas al factor humano. Todas las partes ganan ya que redunda en un beneficio mut uo. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019