Universidad de Talca Facultad de Ingeniera Ingeniera Civil en Computacin

Arquitectura SOA

Mario Berardinucci

Arquitectura SOA
Arquitectura SOA El acrnimo SOA proviene del ingls Service-OrientedArchitecture. 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 organizacin.) Esta arquitectura define y proporciona la infraestructura necesaria para que el intercambio de informacin y la participacin 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 programacin, caractersticas de los equipos, etc. Antecedentes En las ltimas dcadas los departamentos de Tecnologas de la Informacin de las empresas han construido una infraestructura que soporta en gran medida la operacin de sus empresas y sus clientes. El resultado de este proceso ha sido la creacin y mantenimiento de un nmero considerable de aplicaciones de uso interno, cada una responsable de sus propias tareas. Los negocios exigen crear aplicaciones cada vez ms 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 situacin los arquitectos de software se enfrentan a dos opciones:
y

Tratar de reutilizar la funcionalidad ya implementada en otros sistemas. Una labor difcil de realizar, debido a que estos no fueron diseados para integrarse o se elaboraron para plataformas y/o tecnologas incompatibles entre ellas. Re-implementar la funcionalidad requerida. Aunque implica ms tiempo de desarrollo, es en a mayora de los casos la ms fcil y segura.

A pesar de que no sea la ms acertada a largo plazo, la segunda opcin es la ms escogida. Esto trae como resultado:
y y y y y

Funcionalidad replicada en varias aplicaciones. Dificultad de migracin de los sistemas internos, al haber mltiples conexiones desde sistemas que dependen de estos para su funcionamiento. Al no haber una estrategia de integracin de aplicaciones, se generan mltiples puntos de fallo, que pueden detener la operacin de todos los sistemas muy fcilmente. 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 bsicos.

Arquitectura SOA
En la arquitectura SOA la funcionalidad deseada se descompone en unidades (servicios) que pueden ser distribuidos en diferentes nodos conectados a travs 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 coordinacin entre uno o varios servicios. Las aplicaciones necesarias para obtener los correspondientes procesos de negocio se logran mediante la combinacin de colecciones de pequeos mdulos llamados servicios. Estos mdulos pueden ser empleados por grupos de usuarios provenientes de la propia organizacin 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 adems de favorecer la interaccin entre organizaciones dado que se logra la homogeneizacin de la apariencia y del nivel y tipo de datos de entrada para la validacin de los usuarios. En este entorno de trabajo, las unidades bsicas 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 visualizacin del estado de una cuenta bancaria, o la emisin de una peticin de un billete de avin o de tren. En lugar de que los servicios contengan en su cdigo fuente llamadas a otros, se definen protocolos que describen cmo pueden comunicarse entre s. Colaboracin entre servicios. La concepcin de los servicios web, como otros muchos entornos dependientes del estado de la tecnologa 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 adecuacin para ser utilizadas en entornos empresariales obliga a que los servicios se coordinen y colaboren entre s. La colaboracin entre servicios consiste en la determinacin de la secuencia de operaciones que debe acontecer en la interaccin entre clientes y servidores. La secuencia debe respetar el orden establecido para que pueda ser vlida y, con el objeto de que esto resulte viable, se define un protocolo de coordinacin que ser, precisamente, el encargado de describir el conjunto de secuencias vlidas. Existen dos modelos de colaboracin entre servicios: orquestacin y coreografa.
y

El modelo de orquestacin 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 interaccin entre servicios. Permite la definicin de un modelo de interaccin pero slo desde el punto de vista del controlador. La orquestacin define el comportamiento y la forma de llevarlo a cabo, y todos los eventos se supervisan de forma centralizada.

Arquitectura SOA

El modelo de coreografa describe el comportamiento que debe observarse entre las partes que interactan. Cada una de las organizaciones implicadas en este modelo desarrolla independientemente el papel que desea jugar en la colaboracin, la nica condicin es que respeten el contrato global que supone la coreografa descrita. La ejecucin 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 caractersticas de los servicios como los datos que emplean. El lenguaje XML suele ser el utilizado para crear los datos que conformarn el documento de descripcin. Anlogamente, los servicios suelen ser descritos mediante WSDL (Web ServiceDescriptionLanguage) y los protocolos de comunicacin mediante SOAP (Simple Object Access Protocol) Que estos lenguajes de descripcin sean los ms adecuados para desempear estas funciones y se consolide su uso todava no est claro. Lo que s resulta evidente es que una Arquitectura Orientada al Servicio depende completamente de los datos y servicios descritos a travs de los correspondientes metadatos, independientemente de cul sea el mecanismo para su obtencin, y que deben reunir 2 requisitos:
y y

los metadatos tienen que entregarse de forma que puedan ser utilizados directamente por los propios sistemas y, simultneamente, permitir que los diseadores puedan entenderlos y usarlos de la manera adecuada.

Objetivo de la arquitectura SOA La finalidad de la arquitectura SOA es conseguir combinar distintos mdulos funcionales para generar aplicaciones de carcter especfico, proviniendo todos de servicios preexistentes Cuanto mayor sea la funcionalidad proporcionada por estos mdulos menor ser el nmero de interfaces necesarios para alcanzar el objetivo deseado y cada interfaz conlleva un gasto de procesamiento adicional; sin embargo, cuando los mdulos son excesivamente grandes resulta complicada su reutilizacin. Consecuentemente es necesario alcanzar el nivel de granulacin adecuado.

Arquitectura SOA
La expectativa creada por esta nueva arquitectura es que el coste marginal de creacin de la ensima aplicacin sea cero dado que el software requerido se encontrar ya disponible para satisfacer los requisitos; tan slo se requerir la coordinacin entre los elementos. Una de las claves de SOA es que no existen interacciones entre los mdulos que se encuentren embebidas. La interaccin 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 programacin evitando la desbordante complejidad que la existencia de miles de objetos granulares supondra para el diseador. Los servicios en s mismos se desarrollan mediante el uso de lenguajes de programacin como C, C++, Java, etc. Los servicios SOA presentan un acoplamiento bajoitalictext, en oposicin 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 gestin de la memoria, las invocaciones de los servicios, y el uso de tipos de datos. Cada vez existe un mayor nmero de compaas de software que estn ofreciendo servicios a cambio del pago de alguna tasa. En el futuro, los sistemas basados en la arquitectura SOA podrn estar compuestos de los servicios ofertados por estas empresas en combinacin con otros creados por la propia organizacin o institucin. La gran ventaja es que se reparte el coste de desarrollo entre los participantes, y stos disfrutan y promueven la estandarizacin tanto en la propia empresa como entre empresas. En particular, el sector vinculado a los viajes dispone de un amplio nmero 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, estn realizando grandes progresos en esta direccin. La arquitectura SOA se erige sobre un principio fundamental, la orientacin al servicio. En un entorno SOA, los servicios pueden ser utilizados sin conocimiento alguno de las caractersticas de la plataforma sobre la que se despliegan. Elementos de SOA Esta arquitectura presenta un modelo de construccin sistemas distribuidos en el que la funcionalidad demandada ser entregada a la aplicacin a travs de servicios. En la siguiente figura se muestra el esquema de la arquitectura y los elementos que podran 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.

Arquitectura SOA

Elementos de la arquitectura SOA A continuacin se describen brevemente los elementos representados en la figura anterior:
y

Funciones: o 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. o Protocolo de comunicacin de servicios: es un mecanismo acordado a travs del cual un proveedor de servicios y un consumidor de servicios comunican qu est siendo solicitado y qu est siendo respondido. o Descripcin de servicio: es un esquema acordado para describir qu es el servicio, cmo debe invocarse, y qu datos requiere el servicio para invocarse con xito. o Servicio: describe un servicio actual que est disponible para utilizar. o Procesos de Negocio: es una coleccin de servicios, invocados en una secuencia particular con un conjunto especfico de reglas, para satisfacer un requisito de negocio. o 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: o Poltica: es un conjunto de condiciones o reglas bajo las cuales un proveedor de servicio hace el servicio disponible para consumidores. o Seguridad: es un conjunto de reglas que pueden aplicarse para la identificacin, autorizacin y control de acceso a consumidores de servicios.

Arquitectura SOA
o o

Transacciones: es el conjunto de atributos que podran aplicarse a un grupo de servicios para entregar un resultado consistente. Administracin: es el conjunto de atributos que podran 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 localizacin dinmica 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 direccin del servicio proveedor. El siguiente diagrama ilustra las entidades (roles, operaciones y artefactos) en una arquitectura orientada a servicios donde stas colaboran.

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

Un consumidor de servicios es una aplicacin, un mdulo 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 travs 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.

Arquitectura SOA
Las operaciones que pueden llevar a cabo las entidades son:
y y y

Publicar. Para poder acceder a un servicio se debe publicar su descripcin 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 descripcin de un servicio por parte de un consumidor, ste lo invoca haciendo uso de la informacin presente en la descripcin del servicio.

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

y y

Servicio. Un servicio que est disponible para el uso a travs de una interfaz publicada y que permite ser invocado por un consumidor de servicios. Descripcin de servicio. Una descripcin 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 descripcin tambin puede especificar elconjunto de precondiciones, poscondiciones y/o niveles de calidad de servicio (QoS).

Requisitos de una Arquitectura Orientada a Servicios No existe una definicin estndar de cuales son los Principios de la Orientacin a Servicios, por lo tanto, lo nico que se puede proporcionar es un conjunto de Principios que estn muy asociados con la Orientacin a Servicios. Estos Principios segn Thomas Erl son:
y

Los Servicios deben ser reutilizables: Todo servicio debe ser diseado y construido pensando en su reutilizacin dentro de la misma aplicacin, dentro del dominio de aplicaciones de la empresa o incluso dentro del dominio pblico 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 implementacin del propio servicio. En el caso de los Servicios Web, se lograr mediante la definicin 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 travs 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 podrn ser totalmente reutilizables. Los Servicios deben permitir la composicin: Todo servicio debe ser construido de tal manera que pueda ser utilizado para construir servicios genricos 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 orquestacin (WS-BPEL) y coreografa (WS-CDL). Los Servicios deben ser autnomos: Todo servicio debe tener su propio entorno de ejecucin. 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 ejecucin. Los Servicios no deben tener estado: Un servicio no debe guardar ningn tipo de informacin. Esto es as porque una aplicacin est formada por un conjunto de servicios, lo que implica que si un servicio almacena algn tipo de informacin, se pueden producir problemas de inconsistencia de datos. La solucin, es que un servicio slo contenga lgica, y que toda informacin est almacenada en algn sistema de informacin sea del tipo que sea.

Arquitectura SOA
y

Los Servicios deben poder ser descubiertos: Todo servicio debe poder ser descubierto de alguna forma para que pueda ser utilizado, consiguiendo as evitar la creacin 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.