Arquitectura SOA orientada a servicios

El acrónimo SOA proviene del inglés Service-Oriented Architecture. Se trata de un modelo de arquitectura que caracteriza el procedimiento para crear y usar los diversos procesos, reunidos en forma de servicios.

Introducción a la arquitectura orientada a servicios (SOA).

El acrónimo SOA proviene del inglés Service-Oriented Architecture. Se trata de un modelo de arquitectura que caracteriza el procedimiento para crear y usar los diversos procesos, reunidos en forma de servicios, que configuran un determinado Proceso de Negocio (Un proceso de negocio se puede ver como un conjunto estructurado de tareas, que contribuyen colectivamente a lograr losobjetivos de una organización.)

Esta arquitectura define y proporciona la infraestructura necesaria para que el intercambio de información y la participación en los procesos de negocio se lleve a cabo con total independencia de la plataforma hardware-software sobre la que trabajan: sistema operativo, lenguaje de programación, características de los equipos, etc.

Antecedentes

En las últimas décadas los departamentos de Tecnologías de la Información de las empresas han construido una infraestructura que soporta en gran medida la operación de sus empresas y sus clientes. El resultado de este proceso ha sido la creación y mantenimiento de un número considerable de aplicaciones de uso interno, cada una responsable de sus propias tareas.

Los negocios exigen crear aplicaciones cada vez más complejas, en menos tiempo y con menorpresupuesto. En muchos casos crear estas aplicaciones requiere de funcionalidades ya antes implementadas como parte de otros sistemas. Ante esta situación los arquitectos de software se enfrentan a dos opciones:

• Tratar de reutilizar la funcionalidad ya implementada en otros sistemas. Una labor difícil de realizar, debido a que estos no fueron diseñados para integrarse o se elaboraron para plataformas y/o tecnologías incompatibles entre ellas.
• Re-implementar la funcionalidad requerida. Aunque implica más tiempo de desarrollo, es en a mayoría de los casos la más fácil y segura.

A pesar de que no sea la más acertada a largo plazo, la segunda opción es la más escogida. Esto trae como resultado:

• Funcionalidad replicada en varias aplicaciones.
• Dificultad de migración de los sistemas internos, al haber múltiples conexiones desde sistemas que dependen de estos para su funcionamiento.
• Al no haber una estrategia de integración de aplicaciones, se generan múltiples puntos de fallo, que pueden detener la operación de todos los sistemas muy fácilmente.
• Un modelo así, por lo general no escala muy bien.
• El inconveniente final es una pobre respuesta al cambio. Las aplicaciones siguen siendo concebidas desde un principio como islas independientes.

Aspectos básicos.

En la arquitectura SOA la funcionalidad deseada se descompone en unidades (servicios) que pueden ser distribuidos en diferentes nodos conectados a través de una red y que, asimismo, son combinados entre sí para alcanzar el resultado deseado. Estos servicios pueden proporcionar datos a otros o llevar a cabo actividades de coordinación entre uno o varios servicios.

Las aplicaciones necesarias para obtener los correspondientes procesos de negocio se logran mediante la combinación de colecciones de pequeños módulos llamados servicios. Estos módulos pueden ser empleados por grupos de usuarios provenientes de la propia organización o ajenos a la misma y las nuevas aplicaciones creadas del aprovechamiento de servicios presentes en un repositorio global muestran mayor flexibilidad y uniformidad. De este modo se consigue un ahorro en el esfuerzo de desarrollo pues se reaprovechan las funcionalidades comunes a las distintas aplicaciones además de favorecer la interacción entre organizaciones dado que se logra la homogeneización de la apariencia y del nivel y tipo de datos de entrada para la validación de los usuarios.

En este entorno de trabajo, las unidades básicas son los servicios. Los servicios son unidades de funcionalidad que desarrollan su actividad de forma independiente y que se aproxima al concepto que los humanos asocian a los mismos como puede ser la visualización del estado de una cuenta bancaria, o la emisión de una petición de un billete de avión o de tren. En lugar de que los servicios contengan en su código fuente llamadas a otros, se definen protocolos que describen cómo pueden comunicarse entre sí.

Colaboración entre servicios.

La concepción de los servicios web, como otros muchos entornos dependientes del estado de la tecnología y del uso que de ella hacen los usuarios, ha ido cambiando a lo largo del tiempo. Inicialmente éstos fueron creados para implementar interacciones simples e independientes, sin embargo, su adecuación para ser utilizadas en entornos empresariales obliga a que los servicios se coordinen y colaboren entre sí.

La colaboración entre servicios consiste en la determinación de la secuencia de operaciones que debe acontecer en la interacción entre clientes y servidores. La secuencia debe respetar el orden establecido para que pueda ser válida y, con el objeto de que esto resulte viable, se define un protocolo de coordinación que será, precisamente, el encargado de describir el conjunto de secuencias válidas.

Existen dos modelos de colaboración entre servicios: orquestación y coreografía.

• El modelo de orquestación se fundamenta en la existencia de un mecanismo de control centralizado que es el encargado de dirigir las actividades, siendo cada una de ellas una interacción entre servicios. Permite la definición de un modelo de interacción pero sólo desde el punto de vista del controlador. La orquestación define el comportamiento y la forma de llevarlo a cabo, y todos los eventos se supervisan de forma centralizada.

• El modelo de coreografía describe el comportamiento que debe observarse entre las partes que interactúan. Cada una de las organizaciones implicadas en este modelo desarrolla independientemente el papel que desea jugar en la colaboración, la única condición es que respeten el “contrato global” que supone la coreografía descrita. La ejecución y el control es responsabilidad de los propios participantes.

Metadatos

Los metadatos son elementos imprescindibles dentro de esta arquitectura. Deben presentar suficiente para describir tanto las características de los servicios como los datos que emplean.

El lenguaje XML suele ser el utilizado para crear los datos que conformarán el documento de descripción. Análogamente, los servicios suelen ser descritos mediante WSDL (Web Service Description Language) y los protocolos de comunicación mediante SOAP (Simple Object Access Protocol)

Que estos lenguajes de descripción sean los más adecuados para desempeñar estas funciones y se consolide su uso todavía no está claro. Lo que sí resulta evidente es que una Arquitectura Orientada al Servicio depende completamente de los datos y servicios descritos a través de los correspondientes metadatos, independientemente de cuál sea el mecanismo para su obtención, y que deben reunir 2 requisitos:

• los metadatos tienen que entregarse de forma que puedan ser utilizados directamente por los propios sistemas y,
• simultáneamente, permitir que los diseñadores puedan entenderlos y usarlos de la manera adecuada.

Objetivo de la arquitectura SOA

La finalidad de la arquitectura SOA es conseguir combinar distintos módulos funcionales para generar aplicaciones de carácter específico, proviniendo todos de servicios preexistentes Cuanto mayor sea la funcionalidad proporcionada por estos módulos menor será el número de interfaces necesarios para alcanzar el objetivo deseado y cada interfaz conlleva un gasto de procesamiento adicional; sin embargo, cuando los módulos son excesivamente grandes resulta complicada su reutilización. Consecuentemente es necesario alcanzar el nivel de granulación adecuado.
La expectativa creada por esta nueva arquitectura es que el coste marginal de creación de la enésima aplicación sea cero dado que el software requerido se encontrará ya disponible para satisfacer los requisitos; tan sólo se requerirá la coordinación entre los elementos.

Una de las claves de SOA es que no existen interacciones entre los módulos que se encuentren embebidas. La interacción entre los servicios, los cuales con independientes, es especificada por los usuarios. De ahí la necesidad de que los servicios presenten mayor funcionalidad que las tradicionales funciones o clases de los lenguajes de programación evitando la desbordante complejidad que la existencia de miles de objetos granulares supondría para el diseñador. Los servicios en sí mismos se desarrollan mediante el uso de lenguajes de programación como C, C++, Java, etc. Los servicios SOA presentan unacoplamiento bajoitalic text, en oposición a las funciones que componen un fichero ejecutable. Los servicios se ejecutan en el interior de un envoltorio (wrapper) como Java o .NET, que se encarga de la gestión de la memoria, las invocaciones de los servicios, y el uso de tipos de datos.

Cada vez existe un mayor número de compañías de software que están ofreciendo servicios a cambio del pago de alguna tasa. En el futuro, los sistemas basados en la arquitectura SOA podrán estar compuestos de los servicios ofertados por estas empresas en combinación con otros creados por la propia organización o institución. La gran ventaja es que se reparte el coste de desarrollo entre los participantes, y éstos disfrutan y promueven la estandarización tanto en la propia empresa como entre empresas. En particular, el sector vinculado a los viajes dispone de un amplio número de servicios y datos bien definidos y documentados, suficientes para que cualquier desarrollador pueda crear software para agencias de viajes usando únicamente servicios software ya existentes. Otros sectores como el financiero, están realizando grandes progresos en esta dirección.

La arquitectura SOA se erige sobre un principio fundamental, la orientación al servicio. En un entorno SOA, los servicios pueden ser utilizados sin conocimiento alguno de las características de la plataforma sobre la que se despliegan.

Elementos de SOA

Esta arquitectura presenta un modelo de construcción sistemas distribuidos en el que la funcionalidad demandada será entregada a la aplicación a través de servicios. En la siguiente figura se muestra el esquema de la arquitectura y los elementos que podrían observarse. Como puede observarse, el esquema se encuentra dividido en 2 zonas; una que abarca el ámbito funcional de la arquitectura y otra vinculada a la calidad de servicio.

Elementos de la arquitectura SOA

A continuación se describen brevemente los elementos representados en la figura anterior:

• Funciones:
  • Transporte: es el mecanismo utilizado para llevar las demandas de servicio desde un consumidor de servicio hacia un proveedor de servicio, y las respuestas desde el proveedor hacia el consumidor.
  • Protocolo de comunicación de servicios: es un mecanismo acordado a través del cual un proveedor de servicios y un consumidor de servicios comunican qué está siendo solicitado y qué está siendo respondido.
  • Descripción de servicio: es un esquema acordado para describir qué es el servicio, cómo debe invocarse, y qué datos requiere el servicio para invocarse con éxito.
  • Servicio: describe un servicio actual que está disponible para utilizar.
  • Procesos de Negocio: es una colección de servicios, invocados en una secuencia particular con un conjunto específico de reglas, para satisfacer un requisito de negocio.
  • Registro de Servicios: es un repositorio de descripciones de servicios y datos que pueden utilizar los proveedores de servicios para publicar sus servicios, así como los consumidores de servicios para descubrir o hallar servicios disponibles.

• Calidad de Servicio:
  • Política: es un conjunto de condiciones o reglas bajo las cuales un proveedor de servicio hace el servicio disponible para consumidores.
  • Seguridad: es un conjunto de reglas que pueden aplicarse para la identificación, autorización y control de acceso a consumidores de servicios.
  • Transacciones: es el conjunto de atributos que podrían aplicarse a un grupo de servicios para entregar un resultado consistente.
  • Administración: es el conjunto de atributos que podrían aplicarse para manejar los servicios proporcionados o consumidos.

Las colaboraciones en SOA siguen el paradigma descubrir, ligar e invocar, donde un consumidor de servicios realiza la localización dinámica de un servicio consultando el registro de servicios para hallar uno que cumpla con un determinado criterio. Si el servicio existe, el registro proporciona al consumidor la interfaz de contrato y la dirección del servicio proveedor. El siguiente diagrama ilustra las entidades (roles, operaciones y artefactos) en una arquitectura orientada a servicios donde éstas colaboran.

=Relación entre las entidades

Cada entidad puede tomar uno de los tres roles posibles correspondientes a consumidor, proveedor y/o registro:

• Un consumidor de servicios es una aplicación, un módulo de software u otro servicio que demanda la funcionalidad proporcionada por un servicio, y la ejecuta de acuerdo a un contrato de interfaz.
• Un proveedor de servicios es una entidad accesible a través de la red que acepta y ejecuta consultas de consumidores, y publica sus servicios y su contrato de interfaces en el registro de servicios para que el consumidor de servicios pueda descubrir y acceder al servicio.
• Un registro de servicios es el encargado de hacer posible el descubrimiento de servicios, conteniendo un repositorio de servicios disponibles y permitiendo visualizar las interfaces de los proveedores de servicios a los consumidores interesados.

Las operaciones que pueden llevar a cabo las entidades son:

• Publicar. Para poder acceder a un servicio se debe publicar su descripción para que un consumidor pueda descubrirlo e invocarlo.
• Descubrir. Un consumidor de servicios localiza un servicio que cumpla con un cierto criterio consultando el registro de servicios.
• Ligar e Invocar. Una vez obtenida la descripción de un servicio por parte de un consumidor, éste lo invoca haciendo uso de la información presente en la descripción del servicio.

Finalmente, los artefactos en una arquitectura orientada a servicios son:

• Servicio. Un servicio que está disponible para el uso a través de una interfaz publicada y que permite ser invocado por un consumidor de servicios.
• Descripción de servicio. Una descripción de servicio especifica la forma en que un consumidor de servicio interactuará con el proveedor de servicio, especificando el formato de consultas y respuestas desde el servicio. Esta descripción también puede especificar elconjunto de precondiciones, pos-condiciones y/o niveles de calidad de servicio (QoS).

Requisitos de una Arquitectura Orientada a Servicios

No existe una definición estándar de cuales son los Principios de la Orientación a Servicios, por lo tanto, lo único que se puede proporcionar es un conjunto de Principios que estén muy asociados con la Orientación a Servicios. Estos Principios según Thomas Erl son:

• Los Servicios deben ser reutilizables: Todo servicio debe ser diseñado y construido pensando en su reutilización dentro de la misma aplicación, dentro del dominio de aplicaciones de la empresa o incluso dentro del dominio público para su uso masivo.
• Los Servicios deben proporcionar un contrato formal: Todo servicio desarrollado, debe proporcionar un contrato en el cual figuren: el nombre del servicio, su forma de acceso, las funcionales que ofrece, los datos de entrada de cada una de las funcionalidades y los datos de salida. De esta manera, todo consumidor del servicio, accederá a este mediante el contrato, logrando así la independencia entre el consumidor y la implementación del propio servicio. En el caso de los Servicios Web, se logrará mediante la definición de interfaces con WSDL.
• Los Servicios deben tener bajo acoplamiento: Los servicios tienen que ser independientes los unos de los otros. Para lograr ese bajo acoplamiento, lo que se hará es que cada vez que se vaya a ejecutar un servicio, se accederá a él a través del contrato, logrando así la independencia entre el servicio que se va a ejecutar y el que lo llama. Si se consigue este bajo acoplamiento, entonces los servicios podrán ser totalmente reutilizables.
• Los Servicios deben permitir la composición: Todo servicio debe ser construido de tal manera que pueda ser utilizado para construir servicios genéricos de alto nivel a partir de servicios de bajo nivel. En el caso de los Servicios Web, esto se logrará mediante el uso de os protocolos para orquestación (WS-BPEL) y coreografía (WS-CDL).
• Los Servicios deben ser autónomos: Todo servicio debe tener su propio entorno de ejecución. De esta manera el servicio es totalmente independiente y nos podemos asegurar que así podrá ser reutilizable desde el punto de vista de la plataforma de ejecución.
• Los Servicios no deben tener estado: Un servicio no debe guardar ningún tipo de información. Esto es así porque una aplicación está formada por un conjunto de servicios, lo que implica que si un servicio almacena algún tipo de información, se pueden producir problemas de inconsistencia de datos. La solución, es que un servicio sólo contenga lógica, y que toda información esté almacenada en algún sistema de información sea del tipo que sea.
• Los Servicios deben poder ser descubiertos: Todo servicio debe poder ser descubierto de alguna forma para que pueda ser utilizado, consiguiendo así evitar la creación accidental de servicios que proporcionen las mismas funcionalidades. En el caso de los Servicios Web, el descubrimiento se logrará publicando sus interfaces en registros UDDI.

Si te ha gustado esta entrada, suscríbete para recibir las próximas entradas por correo electrónico. Por favor, apoya este blog.