Arquitecturas Orientadas a Servicios

INTRODUCCIN

Manuel Lama Penn

manuel.lama@usc.es

Grupo de Sistemas Inteligentes Departamento de Electrnica e Computacin Universidade de Santiago de Compostela

Descripcin del problema Un mtodo invoca la ejecucin de otros mtodos para obtener algo que no puede alcanzar por s mismo.
public class Hello { public helloBuddy(String message){ System.out.println(message); } } Devuelve algo (opcional) Importa otra clase
import Hello; public class SaySomething { public static void main(String[] args) { Hello hello= new Hello(); hello.helloBuddy(I say: Hello World!); } }

Llama a un mtodo de la clase

Descripcin del problema Una clase usa los mtodos que ofrece otra clase para completar su funcionalidad.
public class Hello { public helloBuddy(String message){ System.out.println(message); } } Esta clase ofrece el servicio

import Hello; public class SaySomething { public static void main(String[] args) { Hello hello= new Hello(); hello.helloBuddy(I say: Hello World!); } }

Esta clase usa el servicio

Descripcin del problema Qu ocurre si las dos clases no estn en la misma mquina? Dnde estn las clases?
Cmo se pueden localizar o descubrir las clases con la funcionalidad que se necesita?

De qu modo se enva informacin entre clases?

Cmo se "entienden" las clases entre s y qu protocolo de comunicacin siguen?

Qu sucede si no se encuentra ninguna clase con la funcionalidad necesaria?

Se puede combinar la funcionalidad de varias clases?

INFORMTICA DISTRIBUIDA

Posibles soluciones Soluciones basadas en llamadas a procedimientos remotos (RPC).

Distributed Component Object Model (DCOM). Common Object Request Broker Architecture (CORBA). Remote Method Invocation (RMI).

Soluciones basadas en la Web como una capa software adicional.

CGIs. Servlets. Servicios Web.

RPC RPC esconde los detalles de comunicacin e interaccin a la hora de invocar la ejecucin de un mtodo que se encuentra en una mquina diferente.
El mtodo del cliente hace una invocacin de un mtodo que est implementado en un servidor. El intercambio de datos tiene lugar a travs de los parmetros de entrada y salida del mtodo invocado.

Los mtodos se describen en un lenguaje IDL que hace al mecanismo RPC independiente del lenguaje de programacin. RPC
SOCKETS

TCP, UDP IP

RPC
A travs de un compilador se genera automticamente el cdigo del cliente y del servidor que facilita la invocacin entre los mtodos. Operaciones de codificacin y decodificacin de parmetros (marshalling / unmarshalling). El mtodo del cliente hace una invocacin de un mtodo que est implementado en un servidor. Los mtodos se dan de alta en un registro en el que se les asigna una direccin IP y un puerto.
Los clientes conocen de antemano la definicin del mtodo (parmetros de entrada/salida y nombre).
CLIE T call to remote procedure Client process

CLIE T stub procedure Bind Marshalling Send

Communication module

SERVER stub procedure Unmarshalling Return

Communication module

SERVER remote procedure

Dispatcher (select stub) Server process

DCOM

Mquina A Mquina A

IDL IDL

Mquina B Mquina B

peticin
IDL proxy

NDR NDR RPC

1

respuesta

IDL stub

Windows Registry Windows Registry 4

Windows Registry Windows Registry

Inspeccin mquina B

1 2 3 4

Protocolo de comunicaciones Formato de mensaje Lenguaje de descripcin Mecanismo de localizacin

CORBA

Mquina A Mquina A

OMG IDL OMG IDL

Mquina B Mquina B

peticin
IDL Stub

CDR CDR IIOP (TCP)

1

respuesta

IDL Skeleton

Naming Service Naming Service 4

Naming Service Naming Service

Inspeccin mquina B

1 2 3 4

Protocolo de comunicaciones Formato de mensaje Lenguaje de descripcin Mecanismo de localizacin

RMI

Mquina A Mquina A

Java Interfaces Java Interfaces

Mquina B Mquina B

peticin
stub

Java Ser. Java Ser. Format Format IIOP || JRMP

1

Skeleton

respuesta
Registry Service Registry Service

Registry Service Registry Service 4

Inspeccin mquina B

1 2 3 4

Protocolo de comunicaciones Formato de mensaje Lenguaje de descripcin Mecanismo de localizacin

Comparativa entre tecnologas

DCOM RPC Protocol Message Format Description Discovery RPC NDR IDL Windows Registry CORBA IIOP CDR OMG IDL Naming Service Java RMI IIOP or JRMP Java Ser. Format Java RMI Registry or JNDI

PROBLEMAS

Estas tecnologas no interoperan entre s. Es necesaria una arquitectura independiente Del lenguaje, De la plataforma, De las caractersticas de los objetos, y Del mecanismo de llamada.

Servlets: Web como capa software Aade una capa adicional a las soluciones basadas en RPC (servidor de aplicaciones)

Servlet call

Servlet call

Servlets: Web como capa software

Servlets: Problemas La interaccin entre los mtodos tiene lugar a travs de documentos o cadenas de texto.
No se manejan tipos de datos.

Los mtodos que se pueden invocar estn predefinidos (POST y GET) y no es posible indicar parmetros de entrada/salida que no sean cadenas de texto.
La ejecucin de otros mtodos requiere de un parmetro de entrada en el que vaya codificado un lenguaje de invocacin de los mtodos. (solucin ad hoc) No es lo suficientemente flexible para la integracin de aplicaciones o para la reutilizacin de la funcionalidad ofrecida por el servlet.

Solucin: Arquitectura SOA El trmino arquitectura orientada a servicio (SOA) no est ligado a ninguna tecnologa o a lenguajes de descripcin de protocolos de interaccin y de componentes.
Una arquitectura SOA no tiene por qu estar implementada con servicios web. No todo servicio es un servicio web.

Elementos de una SOA: Servicios

son componentes software bajamente acoplados (loosely decoupled) por lo que se podran ser: Reutilizados por otros componentes de la misma arquitectura. (independientes) Combinados entre s para proporcionar las funcionalidades requeridas por los clientes. (orquestacin)

Solucin: Arquitectura SOA Elementos de una SOA: Proveedor

Componente que ofrece un conjunto de servicios con una funcionalidad dada. Los servicios son directamente accesibles a travs de Internet, es decir, estn expuestos a travs de URLs. Utiliza un lenguaje de descripcin estndar de servicios.

Elementos de una SOA: Consumidor

Componente que invoca o consume la funcionalidad de los servicios ofrecidos por el proveedor. Utiliza un protocolo de invocacin.

Elementos de una SOA: Registro

Componente que contiene los servicios ofrecidos por el proveedor.

Solucin: Arquitectura SOA / Servicios Web Los servicios web son interfaces que describen las caractersticas de una coleccin de operaciones (o mtodos). que son accesibles a travs de la red usando protocolos Web estandarizados que estn basados en formatos XML. (invocacin) y cuyas propiedades estn representadas usando un lenguaje estndar basado en un formato XML. (descripcin) Los formatos XML describen la estructura de los protocolos de invocacin y de la descripcin de los servicios.

Solucin: Arquitectura SOA / Servicios Web La institucin que se encarga de estandarizar los lenguajes y protocolos en la Web es el Consorcio W3C. En la tecnologa de servicios Web se hace uso de los siguientes estndares que estn representados en XML: Protocolo de comunicaciones: HTTP
(http://www.w3.org/Protocols)

Formato del mensaje: SOAP

(http://www.w3.org/TR/soap)

Estndares del Consorcio W3C

Descripcin de los servicios: WSDL

(http://www.w3.org/TR/wsdl)

Protocolo y registro: UDDI

(http://www.uddi.org)

Solucin: Arquitectura SOA / Servicios Web La arquitectura SOA "recuerda" a las soluciones basadas en la tecnologa RPC
Las principales diferencias se encuentran en la estandarizacin de protocolos y en el nfasis en la composicin de servicios.
Servicios publicados Servicios publicados

Descubrimiento mediante UDDI

Servicio 1 Servicio 1 Servicio

Publicacin mediante UDDI

Registro UDDI

Aplicacin Aplicacin Cliente Cliente

Descripcin mediante WSDL

XML XML Schema Schema WSDL WSDL

Servicio Servicio Web Web

Invocacin y acceso mediante SOAP Transporte mediante HTTP / Otros

Mensaje Mensaje SOAP SOAP

Solucin: Arquitectura SOA / Servicios Web El proveedor despliega el conjunto de operaciones que desea hacer accesibles a travs de Internet.
Son accesibles como direcciones URL que apuntan a recursos (ficheros) descritos en el lenguaje WSDL. Con WSDL solamente se describen las capacidades funcionales de cada una de las operaciones. Es decir: WSDL contiene interfaces en los que se indica el nombre, las entradas, y las salidas de las operaciones. WSDL tambin indica de qu modo se invocarn las operaciones. Estas operaciones son realmente accesibles por parte de los programas cliente? Lo sern si el cliente conoce las URLs.

Solucin: Arquitectura SOA / Servicios Web El proveedor publica a travs del protocolo UDDI las caractersticas de los servicios en un registro que puede ser consultado por los clientes (registro UDDI):
En el registro se indican las caractersticas no funcionales de los servicios, tales como la descripcin de la empresa que los ofrece, la categora a la que pertenecen, etc. En el registro tambin se indica la URL correspondiente al fichero WSDL que contiene las caractersticas funcionales del servicio deseado por el cliente. Para acceder al registro UDDI se utilizan un conjunto de APIs que permiten dar de alta y de baja los servicios que ofrece el proveedor. Un registro UDDI es a los servicios Web lo que los DNS a las direcciones Web.

Solucin: Arquitectura SOA / Servicios Web El consumidor busca los servicios en el registro UDDI los servicios que tienen las caractersticas deseadas:
La bsqueda se realiza indicando palabras clave que hacen referencia a las caractersticas funcionales y no funcionales de los servicios. Se pueden indicar las entradas y salidas que deben tener los servicios (TModel). Como resultado de la bsqueda se devuelve una URL apuntando al fichero WSDL que contiene la descripcin de las operaciones y la forma en la que pueden ser invocadas.

UDDI no es un estndar del Consorcio W3C por lo que es uno de los componentes de menor implantacin en el mercado.

Solucin: Arquitectura SOA / Servicios Web El consumidor obtiene el fichero WSDL y genera automticamente el cdigo necesario para realizar la invocacin de las operaciones descritas.
Se generan las clases que representan los tipos de datos de los parmetros de entrada/salida. Se generan las clases que codifican y decodifican los parmetros de entrada/salida de las operaciones.

El consumidor usa el protocolo SOAP para invocar la ejecucin de una de las operaciones definidas en el fichero WSDL que ha sido localizado en el registro UDDI.

Ventajas: Arquitectura SOA / Servicios Web El uso de formatos XML para describir e invocar las operaciones permite la integracin de aplicaciones que: Estn implementadas en lenguajes de programacin diferentes.
(Traduccin del formato XML al lenguaje de programacin)

Utilizan modelos de datos diferentes.

(Traduccin del modelo representado en el formato XML al modelo de la aplicacin)

El uso de servicios como componentes bajamente acoplados permite a los consumidores: Reutilizar las operaciones en diferentes aplicaciones. Combinar las operaciones entre s para obtener nuevas funcionalidades.