SOA Resumen de lo más importante sobre las arquitecturas orientadas a servicios.

Definición

Por la propia traducción del término anglosajón SOA:

“Un paradigma de arquitectura software que cuenta con la orientación a servicios como su principio fun-damental de diseño”

El elemento a destacar es la característica de “orientación a servicios” que es la que conforma una arquitectura que utiliza servicios débilmente acoplados para cubrir los requisitos de procesos de negocio y requisitos de usuario.

SOA significa diferentes cosas para diferentes personas, según el perfil profesional que se esté ejerciendo en el contexto de una organización.

Así, para un arquitecto de desarrollo de proyectos TIC, SOA significa la definición de la arquitectura corporativa
los procesos que permiten a los Sistemas de Información desarrollar y desplegar funcionalidades de negocio rápidamente.

Para los responsables de la explotación de los Sistemas de Información de una línea de actividad, SOA aporta la gober-nabilidad, la organización y el proceso para la gestión de aplicaciones así como “bloques de negocio constitu-yentes”, para su reutilización en otros proyectos con el fin de reducir costes.

A otro nivel de carácter más estratégico, las arquitecturas SOA se han convertido en una estrategia de negocio para mejorar los flujos de información y alcanzar los objetivos de la organización, en términos de incremento de los ingresos, mejorar la satisfacción del cliente, mejora la calidad de los productos, potenciar la agilidad, etc.

La relación entre los flujos de negocio y las arquitecturas SOA es uno de los aspectos que más están influyendo en su aceptación, y que veremos más adelante al comentar la relación entre BPM y SOA.

Principios de SOA

Los siguientes principios guía definen las reglas básicas para el desarrollo, mantenimiento y uso de las arquitecturas SOA:

 Reutilización

 Interoperabilidad

 Granularidad

 Modularidad

 Composición

 Componentización

 Conformidad con estándares (tanto de ámbito común como específicos de la industria).

 Identificación de servicios, categorización, provisión y entrega, y monitorización y traza.

Los siguientes principios arquitectónicos de diseño se derivan de la definición y diseño de servicios, y son intrínse-camente aplicables a las arquitecturas SOA por su carácter de “orientación a servicios”:

 Encapsulación: los servicios ocultan el código y la forma en la que implementan las funcionalidades que ofrecen hacia fuera, exponiendo una interfaz con dicha funcionalidad accesible.

 Débil acoplamiento: los servicios mantienen una relación entre sí que minimiza las dependencias entre ambos.

 Contrato: los servicios se adscriben a un acuerdo de comunicaciones, definido colectivamente por uno o más documentos de descripción del servicio.

 Abstracción: al margen de lo descrito en el contrato de servicio, los servicios ocultan la lógica al exterior.

 Reutilización: la lógica se divide en servicios con la intención de promover la reutilización.

 Composición: un conjunto de servicios puede ensamblarse y coordinarse para conformar servicios compuestos.

 Autonomía: los servicios tienen control sobre la lógica que encapsulan

 Optimización: en igualdad de circunstancias, los servicios de mayor calidad se consideran preferibles sobre los de baja calidad.

 Descubrimiento: los servicios se diseñan para ser descriptivos “hacia afuera” de forma que puedan ser localizados y accedidos a través de mecanismos de descubrimiento.

Finalmente, a la hora de considerar la implementación de una arquitectura SOA, deberán tenerse en cuenta los siguientes aspectos:

 Arquitectura de referencia SOA, que proporcione diagramas detallados de la arquitectura, requisitos detallados, patrones de diseño, opciones tecnológicas y opiniones sobre los estándares utilizados, etc.

 Gestión del Ciclo de Vida en SOA, que describe el ciclo de vida completo de los servicios y proporciona un proceso detallado de gestión de los mismos desde su creación a su retirada/eliminación o su reposición por nuevas versiones.

 Grado y Modelo de Madurez, cuyo objetivo es acelerar la adopción y disminuir el riesgo de implantar arquitecturas SOA en una empresa u organización, modelando para ello el nivel de madurez de la arquitectura de Tecnologías de la Información de la empresa u organización.

Beneficios de SOA

En el contexto empresarial, el cambio es esencial para adaptarse a factores internos como adquisiciones o reestructura-ciones, o externos como fuerzas competitivas o requisitos de cliente.

Para ello, la infraestructura de los Sistemas de Información que dan el soporte de las actividades de las organizaciones debe ser eficiente en costes, y es ahí donde las arquitecturas SOA ofrecen varios beneficios a considerar en el dinámico entorno en el que nos movemos.

Los principales beneficios que ofrece SOA son:

 Permite potenciar los activos preexistentes

Las arquitecturas SOA proporcionan un nivel de abstracción que permite a una organización potenciar la inver-sión realizada en Tecnologías de la Información y las Comunicaciones, ofreciendo sus activos como servicios que proporcionan funcionalidades de negocio. De esta forma, las organizaciones pueden potencialmente conti-nuar obteniendo valor de los recursos existentes.



 Facilita la integración

El punto de integración en las arquitecturas SOA es la especificación del servicio, no su implementación. De es-ta forma, se proporciona transparencia de la implementación y de la tecnología subyacente, y se minimiza el impacto de los cambios. La integración 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 organización ser más ágil a la hora de responder a las demandas de las necesidades de ne-gocio y de sus clientes.



 Reducir costes e incrementar la reutilización

Al disponer de los servicios básicos de negocio expuestos de forma que se promueve el débil acoplamiento, es posible la combinación y utilización de los mismos para cubrir las diferentes necesidades de negocio que van surgiendo, lo que supone a su vez menor duplicación de recursos, mayor potencial de reutilización y menor coste.



Es importante apuntar, no obstante, que las arquitecturas SOA no son el “santo grial” que solventa todos los problemas, y además la migración a una arquitectura SOA es una tarea muy compleja y comprometida, no exenta de riesgos.

Es preferible, por ello, migrar un conjunto parcial de funcionalidades de negocio de carácter sectorial en lugar de toda la infraestructura TI de la organización, y de forma paulatina ir incrementando dichas funcionalidades conforme surgen nuevas necesidades de negocio.

Arquitecturas orientadas a servicios --> flexibilidad y gran ahorro de costes en las cuantiosas inversiones realizadas en Tecnologías de la Información y las Comunicaciones.

Metodología para la definición y reutilización de componentes software y procesos de negocio, que en la mayoría de los casos se encuentran ya desarrollados e implementados mediante Tec-nologías de la Información en las organizaciones.

Los retos principales que debe afrontar la tecnología SOA debido a su inmadurez comprenden:

 Todos los principales proveedores del mercado afirman haber adoptado el paradigma SOA y publican y promue-ven su propia visión y referencia. Sin embargo, muchos grandes proveedores en realidad lo que han realizado es absorber a pequeñas y volátiles empresas con incipientes iniciativas SOA exitosas.

 Las arquitecturas SOA vinculan el “mundo TIC” con la “visión de negocio”, dos perspectivas que no se comuni-can de forma efectiva en muchas ocasiones y que a menudo tienen objetivos y motivaciones contrapuestas (coste reducido, énfasis en calidad, mayor agilidad, mantenibilidad, etc.)

 Existen diversos cuerpos de estandarización y organismos detrás de la definición y las líneas guía de las arqui-tecturas SOA, lo que añade una mayor confusión, problemas de interoperabilidad, y adopción más lenta de las mismas.

 Las actuales metodologías de desarrollo más extendidas (por ejemplo, la orientación a objetos) carecen del en-foque necesario para la definición de los elementos clave en las arquitecturas SOA: servicios, flujos de negocio y componentes que implementan servicios.

 La recurrente falta de un vocabulario común e interpretaciones incorrectas sobre lo que las arquitecturas SOA significan. Como veremos más adelante, es corriente asociar unívocamente los Web Services con las arquitectu-ras SOA, fuente común de confusión.