Resumen Tema 18 - Arquitecturas Orientadas a Servicios. Tecnologas, protocolos y arquitectura. Comparativa y ventaja frente a otras arquitecturas. Web Services.

Elementos, roles y ciclo de vida

Se han convertido en la promesa para dotar de flexibilidad y conseguir un gran ahorro de costes en las cuantiosas inversiones realizadas en Tecnologas de la Informacin y las Comunicaciones. Metodologa para la definicin y reutilizacin de componentes software y procesos de negocio. Requieren de un proceso de aprendizaje para aprovechar adecuadamente sus capacidades. Retos principales:

Vinculan el mundo TIC con la visin de negocio, dos perspectivas que no se comunican de forma efectiva en muchas ocasiones y que a menudo tienen objetivos y motivaciones contrapuestas (coste reducido, nfasis en calidad, mayor agilidad, mantenibilidad, etc.) Diversos cuerpos de estandarizacin y organismos detrs de la definicin y las lneas gua de las arquitecturas SOA, lo que aade una mayor confusin, problemas de interoperabilidad, y adopcin ms lenta de las mismas. Las actuales metodologas de desarrollo ms extendidas (por ejemplo, la orientacin a objetos) carecen del enfoque necesario para la definicin de sus elementos clave: servicios, flujos de negocio y componentes que implementan servicios. Falta de un vocabulario comn e interpretaciones incorrectas sobre lo que significan. Es corriente asociar unvocamente los Web Services con las arquitecturas SOA. Paradigma de arquitectura software que cuenta con la orientacin a servicios como su principio fundamental de diseo Proporciona un mecanismo de armonizar las necesidades de consumidores de servicios con las capacidades ofrecidas por proveedores de servicios. Estilo arquitectural para una comunidad de consumidores y proveedores de servicios para alcanzar valor mutuo, de forma que: Se permite a los participantes de la comunidad, el trabajo conjunto con mnima codependencia o dependencia tecnolgica. Especifica los contratos a los que las organizaciones, personas y tecnologas deben adherirse para participar en la comunidad. Garantiza que el valor y los procesos de negocio son aportados por la comunidad. Permite el uso de una gran variedad de tecnologas para facilitar las interacciones dentro de la comunidad. En la prctica, SOA significa diferentes cosas para diferentes personas.

Los recursos de una red en un entorno SOA se ponen a disposicin como servicios independientes que pueden ser accedidos sin el conocimiento de la implementacin de la plataforma subyacente, de forma que estos conceptos pueden aplicarse a sistemas software, sistema de negocio y otros muchos tipos de sistemas informticos productores/consumidores. Se han convertido en una estrategia de de negocio para mejorar los flujos de informacin y alcanzar los objetivos de la organizacin, en trminos de incremento de los ingresos, mejorar la satisfaccin del cliente, mejora la calidad de los productos, potenciar la agilidad, etc. Principios gua (8) que definen las reglas bsicas para el desarrollo, mantenimiento y uso de las arquitecturas SOA: Reutilizacin Interoperabilidad Granularidad Modularidad Composicin Componentizacin Conformidad con estndares (tanto de mbito comn como especficos de la industria). Identificacin de servicios, categorizacin, provisin y entrega, y monitorizacin y traza Principios arquitectnicos de diseo que se derivan de la definicin y diseo de servicios, y son intrnsecamente aplicables a las arquitecturas SOA por su carcter de orientacin a servicios: Encapsulacin: los servicios ocultan el cdigo y la forma en la que implementan las funcionalidades que ofrecen hacia fuera, exponiendo una interfaz con dicha funcionalidad accesible. Dbil acoplamiento: los servicios mantienen una relacin entre s que minimiza las dependencias entre ambos. Contrato: los servicios se adscriben a un acuerdo de comunicaciones, definido colectivamente por uno o ms documentos de descripcin del servicio. Abstraccin: al margen de lo descrito en el contrato de servicio, los servicios ocultan la lgica al exterior. Reutilizacin: la lgica se divide en servicios con la intencin de promover la reutilizacin. Composicin: un conjunto de servicios puede ensamblarse y coordinarse para conformar servicios compuestos. Autonoma: los servicios tienen control sobre la lgica que encapsulan Optimizacin: en igualdad de circunstancias, los servicios de mayor calidad se consideran preferibles sobre los de baja calidad. Descubrimiento: los servicios se disean para ser descriptivos hacia afuera de forma que puedan ser localizados y accedidos a travs de mecanismos de descubrimiento.

A la hora de considerar la implementacin de una arquitectura SOA, debern tenerse en cuenta los siguientes aspectos: Arquitectura de referencia SOA, que proporcione diagramas detallados de la arquitectura, requisitos detallados, patrones de diseo, opciones tecnolgicas y opiniones sobre los estndares utilizados, etc. Gestin del Ciclo de Vida en SOA, que describe el ciclo de vida completo de los servicios y proporciona un proceso detallado de gestin de los mismos desde su creacin a su retirada/eliminacin o su reposicin por nuevas versiones. Grado y Modelo de Madurez, cuyo objetivo es acelerar la adopcin y disminuir el riesgo de implantar arquitecturas SOA en una empresa u organizacin, modelando para ello el nivel de madurez de la arquitectura de Tecnologas de la Informacin de la empresa u organizacin Principales beneficios que ofrece SOA son: Permite potenciar los activos preexistentes Las arquitecturas SOA proporcionan un nivel de abstraccin que permite a una organizacin potenciar la inversin realizada en TICs, ofreciendo sus activos como servicios que proporcionan funcionalidades de negocio. De esta forma, las organizaciones pueden potencialmente continuar obteniendo valor de los recursos existentes. Facilita la integracin El punto de integracin en las arquitecturas SOA es la especificacin del servicio, no su implementacin. De esta forma, se proporciona transparencia de la implementacin y de la tecnologa subyacente, y se minimiza el impacto de los cambios. La integracin se simplifica y la complejidad se gestiona mejor, aislando los posibles problemas de la cadena de valor. Mayor capacidad de respuesta La habilidad de componer nuevos servicios a partir de servicios existentes proporciona una ventaja significativa que permite a una organizacin ser ms gil a la hora de responder a las demandas de las necesidades de negocio y de sus clientes. Reducir costes e incrementar la reutilizacin Al disponer de los servicios bsicos de negocio expuestos de forma que se promueve el dbil acoplamiento, es posible la combinacin y utilizacin de los mismos para cubrir las diferentes necesidades de negocio que van surgiendo, lo que supone a su vez menor duplicacin de recursos, mayor potencial de reutilizacin y menor coste. Las arquitecturas SOA no son el santo grial que solventa todos los problemas, y adems la migracin a una arquitectura SOA es una tarea muy compleja y comprometida, no exenta de riesgos. Podemos definir un servicio como: Un recurso que representa una capacidad de realizar tareas y una funcionalidad coherente desde el punto de vista de las entidades proveedoras y solicitantes del mismo. De un servicio, en trminos ms informticos, podemos decir que existe una lgica, una pieza de software, que hace algo de utilidad y que es invocada por otra pieza de software

que se constituye en el consumidor. Para dicha invocacin, debe existir un mecanismo o tecnologa de invocacin y un contrato que defina el proceso. Adems, se aportan unos datos de entrada y la lgica devuelve algn tipo de resultado al consumidor y, normalmente, unos datos de salida. La unidad mnima de lgica invocable y que hace algo til es lo que denominaremos operacin. En general, en una cierta rea de trabajo, existen una serie de operaciones que forman un conjunto coherente y autocontenido. Esas agrupaciones coherentes es lo que denominaremos servicio. Un servicio es un conjunto coherente de funcionalidad, constituido por una o ms operaciones, autocontenido e independiente, que acepta llamadas y devuelve respuestas mediante un contrato definido de forma inequvoca. Un servicio en el marco de una arquitectura SOA, es una funcionalidad empaquetada como un componente reutilizable para su utilizacin en un proceso de negocio. Lo importante para el modelo SOA no es la tecnologa usada para implementar el servicio, sino que responda a las peticiones que se le realizan y ofrezca la calidad del servicio necesaria segn el contrato que ofrece. La orientacin a servicios ofrece un modo de conseguir la llamada separacin de conceptos, mediante la que problemas de gran tamao se descomponen en una serie de problemas individualmente identificables que son llamados conceptos. Orientacin a Servicios frente a Orientacin a Objetos: El paradigma informtico ms extendido y reconocido es el de orientacin a objetos, en el que se utilizan un conjunto de objetos para disear aplicaciones software, y en el que se utilizan tcnicas de diseo como la herencia, la modularidad, el polimorfismo o la encapsulacin. Su importancia en el contexto de la ingeniera software ha sido capital, y de hecho puede decirse que la orientacin a servicios le debe su existencia a la orientacin a objetos. Las arquitecturas SOA estn basadas en un modelo en el que la lgica de la solucin se encuentra distribuida, y por tanto, como ocurre con la orientacin a objetos, conceptos como la encapsulacin, abstraccin, y reutilizacin son fundamentales para el diseo de unidades de lgica distribuida. Las principales diferencias en ambos enfoques se concentran en cmo se relacionan unas entidades (objetos o servicios) con otras, y en el mbito en el que se aplican los respectivos paradigmas. Es importante considerar que ambos paradigmas, proporcionan formas de descomposicin de la lgica de una solucin a diferentes niveles de abstraccin, o si se prefiere, segn diferentes criterios. Podemos decir que el paradigma de la orientacin a servicios es una evolucin de anteriores aproximaciones, aumentado y extendido para soportar las caractersticas y objetivos perseguidos con las arquitecturas SOA. Para que un proyecto SOA tenga xito, los desarrolladores de software deben orientarse ellos mismos a la mentalidad de crear servicios comunes que son orquestados a travs de un middleware para implementar los procesos de negocio.

Ser, una decisin de diseo la eleccin de cubrir la lgica de un proceso de negocio mediante varios servicios de grano fino interrelacionados entre s o mediante un servicio que centralice la definicin de todo el proceso. La relacin entre lgica de procesos de negocio y servicios ha potenciado la sinergia entre la Gestin de Procesos de Negocio (BPM) y las arquitecturas SOA. Centrndonos en el proceso de diseo y desarrollo orientado a servicios destacan los siguientes pasos fundamentales: Identificacin de Servicios: El proceso de identificacin de servicios consiste en la combinacin de tres tcnicas de descomposicin de dominios de aplicacin: Enfoque top-down. En el enfoque top-down, un diagrama de los casos de uso de negocio proporciona la especificacin para definir los servicios de negocio. De esta forma, se abstraen las reas funcionales y subsistemas presentes en el dominio de negocio, pudiendo bajar de nivel hasta alcanzar la descomposicin en flujos, procesos, subprocesos, etc. Enfoque bottom-up. En el enfoque bottom-up, los sistemas y aplicaciones preexistentes de la organizacin son analiza-dos, y como resultado del anlisis, aquellos que sean considerados candidatos viables para proporcionar la implementacin de la funcionalidad de los servicios que compondrn el proceso de negocio, son seleccionados. En este proceso, las aplicaciones empaquetadas y heredadas tienden a verse como un todo, aunque en ocasiones es necesario remodularizarlas para ofrecer la funcionalidad de servicio necesaria. Enfoque middle-out. Finalmente, el enfoque middle-out consiste en modelar y definir aquellos servicios no identificados mediante los dos enfoques anteriores Clasificacin o categorizacin de servicios: Una vez identificados los servicios, comienza esta actividad de clasificacin de los servicios en una jerarqua y estructura que refleje su naturaleza compuesta y fractal. Cada servicio tiene diferentes usos y propsitos, de forma que podemos distinguir entre servicios bsicos de negocio, servicios de infraestructura software, servicios sectoriales de negocio, etc. A partir de ellos, considerados como servicios atmicos, es posible componer y orquestar otros servicios de ms alto nivel, de forma que algunos servicios se componen de servicios y componentes de grano ms fino, escenario en el que la clasificacin ayuda a determinar las interdependencias al tiempo que evita la proliferacin innecesaria de servicios con funcionalidad no reutilizable. Anlisis de subsistemas: Como se ha comentado, dentro de la primera fase de identificacin de servicios, se alcanza una descomposicin en subsistemas al aplicar el enfoque top-down. La presenta actividad toma los subsistemas identificados en la primera fase y especifica las interdependencias y los flujos entre los mismos. Asimismo, los casos de uso identificados como servicios son expuestos en la interfaz de los subsistemas identificados. De esta forma, el anlisis de subsistemas consiste en crear modelos de objetos para representar el funciona-miento interno de los subsistemas y el diseo de los servicios que se exponen que llevarn a efecto dicho funcionamiento. Especificacin de componentes

En esta actividad se especifican los componentes que implementan los servicios y sus detalles: Informacin Reglas de negocio Servicios que implementa Perfil configurable Las especificaciones sobre los eventos y el intercambio de mensajes y la gestin de los componentes tambin se realizan en esta fase. Asignacin de servicios: La asignacin de servicios consiste en vincular los servicios a los subsistemas previamente identificados, vinculando los servicios y componentes que los implementan. Implementacin del servicio : Finalmente, esta fase reconoce que el software que implementa un servicio dado deber ser seleccionado o bien construido a medida. Las opciones de implementacin de un servicio incluyen la integracin, transformacin o suscripcin de funcionalidades implementadas bajo diferentes tecnologas, paradigmas y/o sistemas (servicios web, objetos Java, objetos CORBA, sistemas heredados legacy systems, etc.). As, en este paso, se toma la decisin de qu sistema heredado ser utilizado para dar un servicio dado, qu servicios sern implementados desde cero, qu aspectos de seguridad debern tenerse en cuenta, etc. Se aprovechan de nuevo aqu los esfuerzos realizados en la primera fase de identificacin de servicios, sacando provecho de las descomposiciones top-down y bottom-up realizadas, de forma que se alinean los servicios con su funcionalidad de negocio. La eleccin tecnolgica conlleva la seleccin de estndares, protocolos, lenguajes de programacin, infraestructura especfica, etc., que permiten llevar el paradigma a la prctica. Caractersticas de los Web Services: Una de las tecnologas ms destacadas y que con ms xito est llevando a la prctica el paradigma conceptual de SOA son los Web Services. Un servicio web es un sistema software diseado para soportar la interaccin mquina-a-mquina a travs de una red y de forma interoperable. Un servicio web cuenta con una interfaz descrita en un formato procesable por un equipo informtico (especficamente en WSDL), a travs de la que es posible interactuar con el mismo mediante el intercambio de mensajes SOAP, tpicamente transmitidos usando serializacin XML sobre HTTP conjuntamente con otros estndares web. Un error muy comn relacionado con las arquitecturas SOA es la vinculacin directa que se realiza con la tecnologa de Web Services: los Web Services/Servicios Web NO son SOA. Una arquitectura SOA puede llegar a ser implementada, sin que para ello exista un solo Servicio Web, o de forma inversa, se pueden implementar Servicios Web sin que exista una plataforma o infraestructura SOA que los soporte por detrs.

La diferencia entre ambos trminos es conceptual: mientras que SOA define el qu, los Servicios Web definen el cmo. O dicho de otro modo, al igual que es posible aplicar el paradigma de orientacin a objetos con Java o C++, el paradigma de orientacin a servicios no es exclusivo de los servicios web. El concepto de servicio en SOA se basa en que los servicios desarrollados son Servicios de Negocio, sean desarrollados mediante una tecnologa como servicios web o bien en otras tecnologas disponibles para ello. En una arquitectura SOA, el foco de inters se pone en el modelado de procesos a partir de piezas reutilizables que configuran servicios de negocio, abstrayndose de la tecnologa y forma en la que esos servicios son implementados. Aclarada la diferencia entre los servicios web y las arquitecturas SOA, no obstante hay que dejar claro que los servicios web, por sus especiales caractersticas de interoperabilidad, reutilizacin, modularidad, etc., se ajustan perfectamente a las necesidades y principios de las arquitecturas SOA, lo que, aadido a la universalizacin de los web services, implementados por la mayora de empresas de software para un enorme espectro de plataformas y sistemas operativos, lo han convertido en la aproximacin ms extendida de implementar arquitecturas SOA. Principales estndares y protocolos en relacin a los Web Services representados en la figura, y que se incluyen de forma resumida a continuacin por completitud: XML (eXtensible Markup Language), estndar de W3C (http://www.w3.org/xml/) actualmente en su versin 1.1, es un lenguaje de marcado que permite describir informacin o contenido de forma completamente sepa-rada de su presentacin o formato. Junto a l, hay un amplio conjunto de estndares para la definicin de lenguajes y validacin de documentos (DTD, XSD) y para la transformacin y presentacin de los mismos (XSL-FO, XSLT). SOAP (Simple Object Access Protocol), estndar del W3C (http://www.w3.org/TR/soap/) actualmente en su versin 1.2, que define una gramtica XML que describe el formato de los documentos XML a intercambiar entre el solicitante y el proveedor del servicio, en concreto, el formato en el que se ensobran las peticiones y respuestas entre solicitante y proveedor. WSDL (Web Services Description Language), actualmente en su versin 2.0 y tambin estndar del W3C (), que define una gramtica XML que permite describir la interfaz de un servicio web, es decir, las funciones y parmetros de entrada y salida necesarios para la invocacin de los servicios. UDDI (Universal Description Discovery and Integration), en su versin 3.0 y perteneciente a OASIS (http://www.uddi.org), que configura un servicio de registro o servicio de directorio donde los proveedores de servicios publican sus servicios web y los solicitantes de servicios buscan y encuentran los servicios web acordes a sus necesidades, de forma parecida a como funciona un servicio de pginas amarillas. Un proceso de negocio no es ms que un conjunto de tareas o actividades relacionadas lgicamente que permiten crear valor transformando una entrada en una salida logrando as un resultado de negocio definido. Las entradas son prerrequisitos que deben tenerse antes de que una funcin pueda ser aplicada.

La Gestin de Procesos de Negocio en una organizacin es, por tanto, el rea o campo de conocimiento interseccin de la Gestin y las Tecnologas de la Informacin, que abarca las tcnicas, mtodos y herramientas para disear, representar, controlar y analizar los procesos de negocio operacionales que involucran a personas, organizaciones, aplicaciones y documentos en el contexto de una organizacin. Desde un punto de vista de negocio, la combinacin de BPM y SOA beneficia de forma conjunta a los profesionales de Tecnologas de la Informacin y a los usuarios Gestores de Negocio: 1. Los profesionales TIC cuentan con un nuevo paradigma que permite la reusabilidad y el bajo acoplamiento, mejorando la calidad y mantenibilidad del software y las aplicaciones desarrolladas. 2. Los Gestores de Negocio utilizan una tecnologa que les permite agilizar y gestionar de forma ms eficiente los procesos de negocio de la organizacin. A travs de BPM, se modelan procesos de negocio como un conjunto de tareas de procesamiento individuales, tpica-mente implementadas como servicios en el contexto de una organizacin. Las arquitecturas SOA aportan al modelado de procesos un nuevo concepto denominado composicin de servicios, que no slo permite modelar el proceso de negocio sino que tambin maximiza las potencialidades que las arquitecturas SOA brindan a travs de la integracin de datos y aplicaciones en forma de servicios. El papel de la arquitectura de referencia SOA es identificar los aspectos fundamentales a considerar y las soluciones abstractas que conforman los principales problemas a la hora de afrontar un proyecto de implementacin e implantacin de una arquitectura SOA. Una arquitectura de referencia nos permite establecer un patrn general de implementacin, que tome en consideracin las funcionalidades necesarias en una correcta arquitectura SOA y sea el resultado de un conjunto de deducciones lgicas basadas en el estado del arte de las infraestructuras y proyectos software La arquitectura de referencia abordar, entre otras, las siguientes problemticas: Paradigmas (modelos de invocacin) de servicios aplicables Comunicacin Sncrona versus Asncrona o Comunicacin Bloqueante versus No Bloqueante o Request/Reply versus Publish/Suscribe Tecnologas y estndares o Web Services o Mensajera basada en MOM (JMS, MSMQ) o APIs nativas (bien en local por invocacin directa de mtodos de objetos, o en red conforme a modelo DOM) RMI RMI-IIOP DCOM o Conectores Definicin de servicios y establecimiento de contratos y SLAs Modelos de informacin de intercambio Registro y descubrimiento de servicios

Anatoma de servicios y operaciones (elementos constituyentes) Normalizacin de servicios Problemticas de coordinacin de servicios Transacciones Seguridad Errores Trazas El punto de comienzo para construir una arquitectura de referencia es considerar los servicios. Una arquitectura SOA est construida en torno al concepto de servicios de negocio, como piezas lgicas reutilizables diseadas para ejecutar una tarea o parte de un proceso de negocio, y que cuenta con interfaces de acceso y de invocacin claramente establecidos. Un aspecto importante de los servicios SOA es que estn claramente relacionados como piezas de una funcionalidad de negocio, ms all de ser piezas de cdigo. Esto permite que sean ensamblados en un proceso de negocio utilizando tcnicas de orquestacin o coreografa a travs de la definicin de reglas y polticas de negocio que controlen el flujo. Podemos representar nuestra arquitectura de referencia SOA como una arquitectura en diferentes niveles: Nivel 1: Capa de recursos Consiste en las aplicaciones existentes ya construidas, ya sea mediante sistemas legados o heredados (legacy systems), que incluyen habitualmente sistemas CRM y ERP, como mediante otras aplicaciones de negocio y sistemas implementados con diferentes paradigmas y tecnologas. Las arquitecturas SOA permiten potenciar estos sistemas y desarrollos existentes e integrarlos utilizando tcnicas de integracin orientadas a servicios. Nivel 2: Capa de componentes Esta es la capa de los componentes de la organizacin que son responsables de implementar la funcionalidad y mantener la calidad de servicio de los servicios expuestos, as como los acuerdos a nivel de servicio de la aplicacin en su conjunto. En este nivel tpicamente podemos ubicar los servidores de aplicaciones y cuales-quiera otras plataformas de ejecucin de componentes software que ofrecen alta disponibilidad, balanceo de carga, tolerancia a fallos, etc. Nivel 3: Capa de Servicios Los servicios que se exponen para la construccin de procesos de negocio se exponen en este nivel, pudiendo ser descubiertos o directamente invocados, as como compuestos ya sea por orquestacin o coreografa o bien utilizados individualmente. A este nivel tambin se ubica la infraestructura de integracin que permite la integracin de servicios a travs de la utilizacin de un conjunto de capacidades como son el enrutado de mensajes, mecanismos de transformacin de informacin, protocolos de mediacin, garanta de SLAs, etc., que son ofrecidos por infraestructuras como los ESB, de los que hablaremos en el prximo apartado. Es a este nivel donde se exponen en algn mecanismo de registro (UDDI, ebXML RS) las descripciones de los servicios (mediante WSDL o el lenguaje de definicin de servicios considerado), que indicarn donde se localiza el servicio proporcionado, o bien mediante un ESB se proporcionar un mecanismo de integracin independiente de la localizacin.

Nivel 4: Composicin de procesos de negocio Las composiciones y coreografas de servicios expuestos en el anterior nivel se definen en este, de forma que los servicios se agregan a un flujo de ejecucin mediante un mecanismo de orquestacin o coreografa, de forma que conforman una nica aplicacin. Es en este nivel donde se ubica la infraestructura de BPM (y tienen aplicacin los estndares BPEL, XPDL, WS-CDL, etc.), infraestructura que permite la definicin de casos de uso y procesos de negocio, el uso de herramientas de simulacin, as como el motor de ejecucin que controla el flujo de tareas y actividades. Nivel 5: Capa de acceso o presentacin Esta capa queda fuera del mbito de las arquitecturas SOA, pero se ha convertido gradualmente en un nivel cada vez ms relevante. El motivo de su creciente importancia es la convergencia de estndares. Por un lado hacia el mundo Web Service con el estndar WSRP (Web Services for Remote Portlets), que potencia el uso de servicios web para la interfaz de la aplicacin. Por otro lado, la tendencia hacia el desacople del nivel de presentacin, con infraestructuras de multicanalidad y multimodalidad que permiten abstraer la interfaz de usuario final al tiempo que convergen los medios, proporcionando independencia de la composicin de servicios y construccin de procesos de negocio del canal de acceso que utilizar el usuario para su consumo. Nivel 6: Calidad de Servicio, Seguridad y Gestin Esta capa de carcter horizontal proporciona las capacidades necesarias para monitorizar, gestionar y mantener la calidad de servicio en trminos de seguridad, transaccionalidad, prestaciones y disponibilidad. Para ello, existirn procesos en segundo plano que actan de sensores y herramientas que monitorizan la salud de las aplicaciones SOA, incluyendo entre ellas las implementaciones de estndares de gestin y otros protocolos que implementan calidad de servicio en arquitecturas SOA. En este nivel debern considerarse las diferentes alternativas de securizacin de los servicios as como la transaccionalidad de las invocaciones a los mismos desde el nivel 4 de procesos de negocio al nivel 3 de servicios, mediante los estndares correspondientes. Nivel 7: Gobernanza SOA Por encima de los aspectos generales de gestin y control de la seguridad y la transaccionaldiad, la Gobernanza SOA es el mecanismo que permite asegurar que la correcta y adecuada relacin entre los servicios y el resto de los elementos que conforman la arquitectura SOA, de forma que se asegure el cumplimiento de leyes, polticas, estndares y procedimientos con los que la organizacin opera. Mediante la Gobernanza, quedan definidos: Los roles relativos a la toma de decisiones y las tareas de implementacin y despliegue. Las tareas asignadas a cada uno de los perfiles implicados El ciclo de vida de los servicios El control de las versiones de los servicios que pueden utilizarse en el diseo de los procesos de negocio Elementos y medidas de evaluacin del proceso

10

La cartera de proyectos SOA desarrollados Etc Enterprise Service Bus (ESB) es el concepto de moda de infraestructura para la creacin de arquitecturas SOA, que permite la integracin de servicios y abordando problemas reservados tpicamente a aplicaciones EAI. El concepto ESB ni es slo un producto ni es slo una tecnologa, sino un nuevo concepto: es la definicin de una infraestructura de integracin para la construccin de arquitecturas SOA. Las denominadas arquitecturas orientadas a servicios son una tendencia actual en arquitecturas software e interconexin de sistemas heterogneos. Estas arquitecturas estn formadas por servicios de aplicacin dbilmente acoplados y altamente interoperables. Para comunicarse entre s, estos servicios se basan en una definicin formal independiente de la plataforma subyacente y del lenguaje de programacin (por ejemplo, WSDL). Con esta arquitectura, se pretende que los componentes software desarrollados sean muy reutilizables y los servicios puedan ser utilizados una y otra vez en diferentes contextos. Es de destacar que los servicios suelen no tener estado persistente (stateless) y se suelen basar en tecnologas web abiertas (SOAP y WSDL), aunque no es obligatorio. Los servicios web pueden utilizarse de varias maneras: Tipo RPC (XML-RPC) Tipo SOA Tipo REST (Representational State Transfer) Basan su interfaz en un conjunto de operaciones estndar (GET, PUT, DELETE) Manejan un estado intrnseco. Distinguimos tres roles fundamentales implicados en SOA: Analista de negocio - Conoce el funcionamiento de la organizacin y sus necesidades de SSII. Su visin de stos es a muy alto nivel: a partir de un modelo de servicios disponible disea composiciones y flujos (orquestaciones) entre los mismos para definir los procesos de negocio de la organizacin, los cuales dependen de los requisitos y sus variaciones. Analista de TI / programador - Desarrolla los SSII. Es quien construye y mantiene la capa de abstraccin entre los servicios y la tecnologa subyacente. Arquitecto SOA - Debe entender la relacin dinmica entre las necesidades del negocio y los servicios disponibles, as como sus restricciones tcnicas. Es el responsable de ese modelo de servicios que comparten analistas de negocio y programadores: se sita como interlocutor para servir de puente entre las visiones tan dispares que unos y otros tienen del negocio. Ciclo de vida tpico de un servicio:

11

Estndares definidos en la arquitectura SOA que intervienen en este ciclo de vida: WSDL UDDI SOAP

12