HERRAMIENTAS Y ENTORNOS DE...

1

HERRAMIENTAS Y ENTORNOS DE PROGRAMACIÓN

Tema 4. Tecnologías de Servicios Web

Escuela Superior de Informática

2

Herramientas y Entornos de Programación Tema 4. Tecnologías de Servicios Web

Tecnologías de Servicios Web (~ 3 horas)

Introducción a los Servicios Web SOAP: Simple Object Access Protocol WSDL: Web Services Description Language WSIL: Web Services Inspection Language Proceso de funcionamiento

3

Herramientas y Entornos de Programación Tema 4. Servicios Web. Introducción

Conceptos básicos Los servicios web son módulos de software que realizan tareas o conjuntos

de tareas discretas, a los que se accede y se llama a través de una red, sobre todo la World Wide Web.

El desarrollador puede crear una aplicación cliente que llama a una serie de servicios web mediante llamadas a procedimientos remotos (RPC) o un servicio de mensajes en los que se proporciona un fragmento o la mayor parte de la lógica de la aplicación.

Los servicios web publicados se describen de forma que los desarrolladores pueden localizarlos y determinar si se ajustan a sus necesidades.

Por ejemplo, una empresa puede proporcionar a sus clientes un servicio web por el cual se comprueba el inventario de productos antes de realizar un pedido.

Otro ejemplo es el servicio de seguimiento de paquetes de la empresa de mensajería Federal Express, mediante el cual los clientes pueden examinar el estado de sus envíos.

4


Conceptos básicos Desde hace no pocos años existen múltiples mecanismos que hacen posible el acceso

a funciones discretas (componentes, servicios…), de manera distribuida.

Esto significa que la aplicación que ofrece ese servicio se estará ejecutando, respecto al cliente que lo consume, en cualquier punto de una red.

Algunos de esos mecanismos son: CORBA (Common Object Request Broker Architecture)

Java RMI (Remote Method Invocation)

Microsoft DCOM (Distributed Component Object Model).

El concepto de “servicio web” es bastante más reciente y, básicamente, se diferencia de las soluciones mencionadas en los protocolos empleados para hacer posible la comunicación entre servidor y cliente o, usando la denominación mas correcta a este contexto, el servicio y el consumidor.

Los citados CORBA, RMI y DCOM se basan en canales y protocolos de conversación que, en principio, no fueron diseñados con la WWW en mente. Esto explica que encuentren problemas con dispositivos de encauzamiento y seguridad.

5


Conceptos básicos Los servicios web utilizan SOAP (Simple Object Access Protocol)

para la carga XML y utiliza un transporte del tipo HTTP para llevar los mensajes SOAP de un lado a otro.

En realidad, los mensajes SOAP son los documentos XML que se envían entre el servicio web y la aplicación que efectúa la llamada.

Los servicios web se pueden escribir en cualquier lenguaje, y se ejecutan en todas las plataformas.

Los clientes de servicios web también se pueden escribir en cualquier lenguaje, y se ejecutan en todas las plataformas.

Por ejemplo, un cliente escrito en Delphi que se ejecuta en Windows puede llamar a un servicio web escrito en Java que se ejecuta en Linux.

6


Arquitectura La arquitectura de los servicios web permite desarrollar servicios que

encapsulan todos los niveles de funcionalidad empresarial.

En otras palabras, un servicio web puede ser muy simple, como, por ejemplo, uno que informe sobre la temperatura actual, o una aplicación compleja.

Esta arquitectura también permite la combinación de varios servicios web con el fin de crear nuevas funciones.

La arquitectura de servicios web tiene tres cometidos: proporcionar datos, solicitarlos y hacer de intermediario.

Como proveedor, crea el servicio web y lo pone a disposición de los clientes que desean utilizarlo.

El solicitante realiza la petición de las aplicaciones clientes que consumen el servicio web. Este servicio solicitado también puede ser un cliente/proveedor de otros servicios web.

El intermediario, como un registro de servicio, permite interaccionar a la aplicación cliente y al proveedor.

7


Arquitectura Estos tres cometidos interaccionan por medio de las operaciones de publicación,

búsqueda y enlace.

El proveedor utiliza la interfaz de publicación del intermediario para comunicarle la existencia del servicio web, con el fin de ponerlo a disposición de los clientes.

La información publicada describe el servicio e indica dónde se encuentra.

La aplicación que hace la solicitud consulta al intermediario para que busque los servicios web publicados.

Con la información obtenida del intermediario, la aplicación cliente puede enlazarse al servicio web (llamarlo).

Las normas en las que se basa el desarrollo de servicios web son tecnologías en proceso de evolución. Las principales son SOAP (Simple Access Protocol, Protocolo de acceso a objetos sencillos), WSDL (Web Services Description Language, Lenguaje de descripción de servicios web), UDDI (Universal Description, Discovery, and Integration, Descripción, detección e integración universales) y WSIL (Web Services Inspection Language, Lenguaje de inspección de servicios web).

8


Arquitectura Llamada a procedimientos remotos

9


Arquitectura

10


Interacción entre Servicios Web

11


Interacción entre Servicios Web Según el ejemplo del gráfico, un usuario (que juega el papel de cliente dentro

de los Servicios Web), a través de una aplicación, solicita información sobre un viaje que desea realizar haciendo una petición a una agencia de viajes que ofrece sus servicios a través de Internet.

La agencia de viajes ofrecerá a su cliente (usuario) la información requerida.

Para proporcionar al cliente la información que necesita, esta agencia de viajes solicita a su vez información a otros recursos (otros Servicios Web) en relación con el hotel y la línea aérea.

La agencia de viajes obtendrá información de estos recursos, lo que la convierte a su vez en cliente de esos otros Servicios Web que le van a proporcionar la información solicitada sobre el hotel y la línea aérea.

Por último, el usuario realizará el pago del viaje a través de la agencia de viajes que servirá de intermediario entre el usuario y el servicio Web que gestionará el pago.

12




13

Herramientas y Entornos de Programación Tema 4. Servicios Web. SOAP

SOAP: Simple Object Access Protocol SOAP es un protocolo de mensajes independiente del transporte.

Los mensajes SOAP son documentos XML.

SOAP utiliza mensajes unidireccionales, aunque es posible combinar mensajes en secuencias de solicitud y respuesta.

La especificación SOAP define el formato del mensaje XML, pero no su contenido ni la forma en que se envía.

No obstante, SOAP especifica la forma en que los mensajes SOAP se encaminan por medio de HTTP.

Todos los documentos SOAP tienen un elemento raíz <Envelope>. El elemento raíz es el primero de un documento XML, y contiene los demás elementos del documento. Este “envelope” consta de dos partes: la cabecera (header) y el cuerpo (body). La cabecera contiene los datos de encaminado o contexto, y puede estar vacía. El cuerpo contiene el mensaje propiamente dicho. También puede estar vacío.

14


SOAP: Simple Object Access Protocol

15



16



17



Modelos de procesamiento

18


SOAP: Simple Object Access Protocol Ejemplo de un mensaje SOAP sencillo enviado por HTTP que solicita el precio actual de

las acciones de Google:

POST /StockQuote HTTP/1.1 Host: www.stockquoteserver.com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "urn:stock-quote-services"

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m="Some-URI"> <symbol>GGLE</symbol> </m:GetLastTradePrice> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Mas: http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383528

19


SOAP: Simple Object Access Protocol SOAP proporciona un mecanismo estándar de empaquetar un mensaje. Un mensaje

SOAP se compone de un sobre que contiene el cuerpo del mensaje y cualquier información de cabecera que se utiliza para describir le mensaje

20


SOAP: Simple Object Access Protocol El elemento raíz del documento es el elemento Envelope. El ejemplo contiene dos

subelementos, Body y Header. Un ejemplo de SOAP valido también puede contener otros elementos hijo en el sobre.

El sobre puede contener un elemento Header opcional que contiene información sobre el mensaje. En el ejemplo anterior, la cabecera contiene dos elementos que describen a quien compuso el mensaje, y posible receptor del mismo.

El sobre debe contener un elemento body el elemento body (cuerpo) contiene la carga de datos del mensaje. En el ejemplo el cuerpo contiene una simple cadena de caracteres.

Un mensaje debe estar dentro de sobre de SOAP bien construido. Un sobre se compone de un único elemento envelope el sobre puede contener un elemento Header y puede contener un elemento body.

Si existe, la cabecera debe ser el elemento hijo inmediato del sobre, con el cuerpo siguiendo inmediatamente a la cabecera.

El cuerpo contiene la carga de datos del mensaje y la cabecera contiene los datos adicionales que no pertenecen necesariamente al cuerpo del mensaje.

21


SOAP: Simple Object Access Protocol La especificación de SOAP también proporciona un patrón de mensaje estándar para

facilitar el comportamiento de tipo RPC. Se emparejan dos mensajes de SOAP para facilitar la asociación de un mensaje de petición con un mensaje de respuesta.

La llamada a un método y sus parámetros se serializan en el cuerpo del mensaje de petición en forma de una estructura. El elemento raíz tiene el mismo nombre que el método objetivo (añadiendo “response”), con cada uno de los parámetros codificado como un subelemento.

El mensaje de respuesta puede contener los resultados de la llamada al método o una estructura de fallo bien definida (En caso de encontrarse un error el cuerpo del mensaje)

Caso de Estudio: Tecnología .NET Cuando escribe una aplicación cliente de Visual Studio 2005 para enviar solicitudes SOAP, no es

necesario que conozca el contenido de los mensajes de respuesta y solicitud SOAP que se intercambian.

Visual Studio 2005 crea la clase de proxy necesaria y el usuario solicita una operación SOAP como lo haría para cualquier otro método. Una llamada al método desde un cliente de Visual Studio 2005 genera automáticamente la solicitud SOAP adecuada. La instancia de SQL Server 2005 procesa internamente la solicitud y devuelve los resultados adecuados, como una matriz de objetos o un solo objeto DataSet.

22


SOAP: Simple Object Access Protocol Estructura de los mensajes de solicitud

POST /url HTTP/1.1 Host: HostServerName Content-type: text/xml; charset=utf-8 Content-length: 350 SoapAction: http://tempUri.org/GetCustomerInfo …

<?xml version="1.0" encoding="utf-8" ?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<soap:Body> <GetCustomerInfo xmlns="http://tempUri.org/"> <CustomerID>1</CustomerID> <OutputParam /> </GetCustomerInfo>

</soap:Body> </soap:Envelope>

23



Introducción a los Servicios Web SOAP: Simple Object Access Protocol WSDL: Web Services Description Language

WSIL: Web Services Inspection Language

Proceso de funcionamiento

24

Herramientas y Entornos de Programación Tema 4. Servicios Web. WSDL

WSDL: Web Services Description Language Los servicios web sólo resultan útiles si otras aplicaciones pueden reconocer qué hacen

y la forma de llamarlos.

Los desarrolladores deben estar suficientemente informados sobre un servicio web para poder escribir un programa cliente que lo llame.

WSDL es un lenguaje basado en XML que se utiliza para definir servicios web y describe la forma de acceder a ellos. Concretamente, describe los contratos de datos y mensajes que ofrece un servicio web.

Los desarrolladores deben examinar el documento WSDL de los servicios web para averiguar qué métodos hay disponibles y cómo se realizan las llamadas con los parámetros adecuados

25


WSDL: Web Services Description Language Este documento se puede dividir en dos grupos de secciones. El grupo superior está compuesto por

las definiciones abstractas, mientras que el inferior lo forman descripciones concretas.

Las secciones abstractas definen los mensajes SOAP de una forma independiente de la plataforma y del lenguaje; no contienen elementos específicos ni del lenguaje ni del equipo. De este modo, facilita la definición de un conjunto de servicios que pueden implementar varios sitios Web distintos.

Las cuestiones específicas del sitio, como la serialización, se relegan a las secciones inferiores, que contienen descripciones concretas.

Definiciones abstractas

Tipos (type): contenedor de definiciones del tipo de datos que utiliza algún sistema de tipos (por ejemplo XSD).

Mensajes (message): definición abstracta y escrita de los datos que se están comunicando.

Operation: descripción abstracta de una acción admitida por el servicio

Tipos de puerto (portType) conjunto abstracto de operaciones admitidas por uno o más puntos finales.

Descripciones concretas

Enlaces (binding) especificación del protocolo y del formato de datos para un tipo de puerto determinado.

Port: punto final único que se define como la combinación de un enlace y una dirección de red

Servicios (service) colección de puntos finales relacionados.

WSDL: Web Services Description Language Elemento types

El elemento Types contiene información de esquema de tipos referenciado en el documento WSDL. El sistema de tipos predeterminado que admite WSDL es de esquema de XML.

Se pueden utilizar otros sistemas de tipo tipos por extensión. Si desea utilizar otro sistema de tipo debe aparecer un elemento de extensibilidad bajo el elemento Types. El nombre de este elemento debería identificar el sistema de tipos utilizados.

Elemento message El elemento Message proporciona una abstracción común para el paso de

mensajes entre el cliente y el servidor. Es posible utilizar múltiples formatos de definición de esquema en documento

WSDL , por lo que es necesario disponer de un mecanismo común de identificar los mensajes.

Puede aparecer, y normalmente aparecerán, múltiples elementos Message en un documento WSDL, uno para cada mensaje que se comunica entre el cliente y el servidor. Cada mensaje contiene uno o más elementos "Part" que describen las piezas del contenido del mensaje.

26


27

WSDL: Web Services Description Language Elemento portType

El elemento porType contiene un conjunto de operaciones abstractas que representan los tipos de correspondencia que pueden producirse entre el cliente y el servidor. Para los Servicios Web de estilo RPC se pude pensar en un portType como una definición de internas en donde cada método se pude definir como una operación.

WSDL define cuatro tipos de operaciones denominadas tipo operaciones: Request-response(petición-respuesta) comunicación del tipo RPC en la que

le cliente realiza una petición y el servidor envía la correspondiente respuesta.

One-way (un-sentido) Comunicación del estilo documento en la que el cliente envía un mensaje pero no recibe una respuesta del servidor indicando el resultado del mensaje procesado.

Solicit-response(solicitud-respuesta) La contraria a la operación petición-respuesta. El servidor envía una petición y el cliente le envía de vuelta una respuesta.

Notification (Notificación) La contraria a la operación un-sentido el servidor envía una comunicación del estilo documento al cliente.


28

WSDL: Web Services Description Language Elemento binding

El elemento binding contiene las definiciones de la asociación de un protocolo como SOAP a un determinado bindingType. Las definiciones binding especifican detalles de formatos del mensaje y el protocolo. Por ejemplo, la información de asociación especifica si se puede acceder a una instancia de un portType de forma RPC.

Las definiciones binding también indican el número de comunicaciones de red que se requieren para realizar una determinada acción. Por ejemplo, una llamada RPC de SOAP sobre HTTP podría involucrar un intercambio de comunicación HTTP, pero esa misma llamada sobre SMTP podría involucrar dos intercambios de comunicaciones de SMTP discretas.

Elemento service Un servicio es un grupo de puertos relacionados y se definen en el elemento

service. Un puerto es un extremo concreto de un Servicio Web al que se hace referencia por una dirección única. Los puertos que se definen en determinado servicio son independientes. Por ejemplo, la salida de un puerto que no puede utilizarse como una entrada de otro.


29


WSDL: Web Services Description Language

La sección de mensajes utiliza definiciones de la sección de tipos; la de tipos de puerto usa definiciones de la sección de mensajes; la sección de enlaces hace referencia a la sección de tipos de puerto y la de servicios a la sección de enlaces

Las secciones de tipos de puerto y enlaces contienen elementos de operación mientras que la sección de servicios incluye elementos de puerto. Los elementos de operación de la sección de enlaces modifican o describen con mayor profundidad los elementos de operación de la sección de tipos de puerto.

Asimismo, puede que el contenido esté formado por uno o varios elementos, de una forma recursiva. El elemento raíz es el que se encuentra más arriba y al que pertenecen todos los demás elementos del documento. El elemento secundario pertenece siempre a otro, el elemento principal.

30


WSDL: Web Services Description Language Ejemplo

<?xml version="1.0" encoding="UTF-8" ?> <definitions name="FooSample" targetNamespace="http://tempuri.org/wsdl/" xmlns:wsdlns="http://tempuri.org/wsdl/" xmlns:typens="http://tempuri.org/xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:stk="http://schemas.microsoft.com/soap-toolkit/wsdl-extension" xmlns="http://schemas.xmlsoap.org/wsdl/">

<types> <schema targetNamespace="http://tempuri.org/xsd" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" elementFormDefault="qualified" >

</schema>

</types>

31


WSDL: Web Services Description Language Ejemplo (continuación)

<message name="Simple.foo"> <part name="arg" type="xsd:int"/>

</message>

<message name="Simple.fooResponse"> <part name="result" type="xsd:int"/>

</message>

<portType name="SimplePortType"> <operation name="foo" parameterOrder="arg" > <input message="wsdlns:Simple.foo"/> <output message="wsdlns:Simple.fooResponse"/> </operation>

</portType>

32



<binding name="SimpleBinding" type="wsdlns:SimplePortType"> <stk:binding preferredEncoding="UTF-8" /> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="foo"> <soap:operation soapAction="http://tempuri.org/action/Simple.foo"/> <input> <soap:body use="encoded" namespace="http://tempuri.org/message/" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" /> </input> <output> <soap:body use="encoded" namespace="http://tempuri.org/message/" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" /> </output> </operation> </binding>

33



<service name="FOOSAMPLEService"> <port name="SimplePort“ binding="wsdlns:SimpleBinding"> <soap:address location="http://carlos:8080/FooSample/FooSample.asp"/> </port> </service> </definitions>

34



La segunda línea es el elemento raíz del documento WSDL: <definitions>. Existen varios atributos de espacio de nombre (declaraciones de espacio de nombre) conectados al elemento raíz, al igual que en el elemento secundario <schema> del elemento <types>

El elemento <types> comprende la sección de tipos. Esta sección se puede omitir si no hay tipos de datos que necesiten ser declarados. En el ejemplo WSDL, no hay declarados tipos específicos de aplicaciones pero utilizo la sección de tipos de todos modos para declarar espacios de nombre de esquema utilizados en el documento.

Los elementos <message> constituyen la sección de mensajes. Si consideramos las operaciones como funciones, el elemento <message> define los parámetros en dicha función.

Cada elemento secundario <part> del elemento <message> se corresponde a un parámetro. Los parámetros de entrada se definen en un solo elemento <message>, separado de los parámetros de salida, que se encuentran en su propio elemento <message>. Los parámetros que son tanto de entrada como de salida tienen sus correspondientes elementos <part> en los dos elementos <message> de entrada y salida.

35



El nombre del elemento <message> de salida termina en "Response", como en "fooResponse", por convención. Cada elemento <part> tiene un nombre y un atributo de tipo, al igual que un parámetro de función tiene tanto un nombre como un tipo.

Cuando se utilizan para el intercambio de documentos, WSDL permite el uso de elementos <message> para describir el documento que se intercambiará.

El tipo de un elemento <part> puede ser un tipo base XSD, un tipo definido de SOAP (soapenc), un tipo definido de WSDL (wsdl) o un tipo definido de la sección de tipos.

En la sección de tipos de puertos puede que no haya ningún elemento <portType> o bien, uno o varios. Debido a que las definiciones abstractas de los tipos de puerto se pueden ubicar en un archivo distinto, puede que no se tengan elementos <portType> en un archivo WSDL.

El ejemplo anterior muestra sólo un elemento <portType>. Como se puede observar, el elemento <portType> define una o varias operaciones en los elementos <operation>.

En el ejemplo se muestra sólo un elemento <operation>, denominado "foo". Este nombre es equivalente a un nombre de función

36



El elemento <operation> puede tener uno, dos o tres elementos secundarios: <input>, <output>, y <fault>.

El atributo de mensaje de cada elemento <input> y <output> hace referencia al elemento <message> relevante en la sección de mensajes. Por tanto, todo el elemento <portType> del ejemplo es equivalente a la siguiente declaración de función en C: int foo(int arg);

La sección de enlaces puede tener ninguno, uno o varios elementos <binding>. Su objetivo es especificar el modo en el que se envía con conexión cada llamada y respuesta de <operation>.

La sección de servicios puede tener ninguno, uno o varios elementos <service>. Contiene elementos <port>, y cada uno de éstos hace referencia al elemento <binding> de la sección de enlaces. Tanto la sección de enlaces como la de servicios incluyen descripciones concretas de un documento WSDL

37



Una forma de considerar el archivo WSDL es que, para los clientes y servidores que lo utilizan, determina lo que se envía por conexión.

Dada una operación, por ejemplo "echoInt", que simplemente devuelve un entero de entrada, el recuento de parámetros, el tipo de cada parámetro y cómo se envían éstos a través de la conexión (serialización) forma un protocolo específico de la aplicación.

Si lo miramos desde esta perspectiva, WSDL no es sólo un "contrato de interfaz"; es también un lenguaje de especificación de protocolos. Y esto es precisamente lo que necesitamos si vamos más allá de los protocolos "fijos" como IP y HTTP hacia protocolos específicos de aplicaciones.

WSDL puede especificar si los mensajes SOAP cumplen los estilos de documento o rpc. El mensaje de estilo rpc, como se utiliza en el ejemplo, es similar a una llamada a función con ningún o varios parámetros. El mensaje de estilo de documento es más plano y requiere menos niveles de anidación.

38



Los mensajes XML a continuación se envían y reciben como resultado del análisis del archivo WSDL de ejemplo utilizando el objeto SoapClient en MS SOAP Toolkit 2.0 (MSTK2).

Enviado desde el cliente para realizar una llamada a función "foo(5131953)":

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP- ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <m:foo xmlns:m="http://tempuri.org/message/"> <arg>5131953</arg> </m:foo> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

39



Recibido desde el servidor (respuesta):

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <SOAPSDK1:fooResponse xmlns:SOAPSDK1="http://tempuri.org/message/"> <result>5131953</result> </SOAPSDK1:fooResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Mas… http://es.wikipedia.org/wiki/WSDL

40



Introducción a los Servicios Web SOAP: Simple Object Access Protocol WSDL: Web Services Description Language

WSIL: Web Services Inspection Language Proceso de funcionamiento

41

Herramientas y Entornos de Programación Tema 4. Servicios Web. WSIL

WSIL: Web Services Inspection Language WSIL, proporciona un método de descubrimiento de servicios para servicios web.

WSIL utiliza un modelo descentralizado y distribuido, en lugar de un modelo centralizado (UDDI).

Los documentos WSIL son, básicamente, punteros de listas de servicios que permiten a los clientes de servicios web examinar los servicios disponibles.

La norma WSIL establece la forma de utilizar documentos con formato XML estándar para inspeccionar sitios web en busca de servicios y series de reglas que determinan la forma en que se proporciona la información.

El proveedor del servicio aloja el documento WSIL de forma que los consumidores pueden encontrar los servicios disponibles.

42




43

Herramientas y Entornos de Programación Tema 4. Servicios Web. Proceso

Localización de Servicios

Para que un servicio web sea útil, y cumpla su función, es necesario que los potenciales consumidores puedan localizarlo, identificar los métodos que expone y usarlos.

Esto implica la existencia de un canal de comunicación y el uso de una serie de protocolos y lenguajes de conversación entre ambos extremos.

Todo comienza cuando el desarrollador del programa que va a consumir el servicio tiene que localizarlo previamente, usando para ello, por regla general, un servicio de directorio UDDI (Universal Discovery, Description and Integration).

Éste puede ser local a la empresa, en caso de existir un servidor propio con el registro de servicios disponibles, o bien externo y público.

Un registro UDDI contiene meta-información sobre servicios web, incluyendo el URL donde están alojados.

UDDI es un registro público diseñado para almacenar de forma estructurada información sobre empresas y los servicios que éstas ofrecen.

44


Localización de Servicios

A través de UDDI, se puede publicar y descubrir información de una empresa y de sus servicios. Se puede utilizar sistemas taxonómicos estándar para clasificar estos datos y poder encontrarlos posteriormente en función de la categorización.

Lo más importante es que UDDI contiene información sobre las interfaces técnicas de los servicios de una empresa. A través de un conjunto de llamadas a API XML basadas en SOAP, se puede interactuar con UDDI tanto en tiempo de diseño como de ejecución para descubrir datos técnicos de los servicios que permitan invocarlos y utilizarlos.

De este modo, UDDI sirve como infraestructura para una colección de software basado en servicios Web.

La información de UDDI se aloja en nodos de operador, empresas que se han comprometido a ejecutar un nodo público conforme a la especificación que rige el consorcio UDDI.org.

45


Descripción del servicio Una vez que se dispone de la información relativa a la localización del servicio, obtenida

del registro UDDI, el siguiente paso será obtener una descripción completa de ese servicio. Aquí es donde entra en escena el lenguaje WSDL.

Es importante saber cómo colaboran UDDI y WSDL y por qué la idea de interfaces frente implementaciones forma parte de cada protocolo.

WSDL y UDDI se diseñaron para diferenciar claramente los metadatos abstractos y las implementaciones concretas. Para entender cómo funcionan WSDL y UDDI resulta esencial comprender las consecuencias de esta división.

WSDL distingue claramente los mensajes de los puertos: los mensajes (la sintaxis y semántica que necesita un servicio Web) son siempre abstractos, mientras que los puertos (las direcciones de red en las que se invoca al servicio Web) son siempre concretos.

No es necesario que un archivo WSDL incluya información sobre el puerto. Un archivo WSDL puede contener simplemente información abstracta de interfaz, sin facilitar datos de implementación concretos, y ser válido. De este modo, los archivos WSDL se separan de las implementaciones.

46


Descripción del servicio Una de las consecuencias más interesantes de esto es que pueden existir varias

implementaciones de una única interfaz WSDL.

Si tres empresas diferentes implementan el mismo archivo WSDL y una parte del software de cliente crea el código auxiliar/proxy a partir de esa interfaz, dicho software se podrá comunicar con las tres implementaciones con el mismo código de base.

UDDI establece una distinción similar entre la abstracción y la implementación con el concepto de tModels. La estructura tModel, abreviatura de "Technology Model" (modelo de tecnología), representa huellas digitales técnicas, interfaces y tipos abstractos de metadatos.

El resultado de los tModels son las plantillas de enlace, que son la implementación concreta de uno o más tModels. Dentro de una plantilla de enlace se registra el punto de acceso de una implementación particular de un tModel.

Del mismo modo que el esquema de WSDL permite separar la interfaz y la implementación, UDDI ofrece un mecanismo que permite publicar por separado los tModels de las plantillas de enlace que hacen referencia a ellos.

47


Llamada a los métodos Partiendo de la descripción del servicio, el consumidor llamará a los métodos que

exponga el servicio usando mensajes SOAP (Simple Object Access Protocol).

SOAP proporciona un mecanismo estándar de empaquetar mensajes y facilita una comunicación del estilo RPC (remote procedure calls) entre un cliente y un servidor remoto. Algunas de las ventajas SOAP son:

No esta asociado con ningún lenguaje: los desarrolladores involucrados en nuevos proyectos pueden elegir desarrollar con el último y mejor lenguaje de programación que exista pero los desarrolladores responsables de mantener antiguas aflicciones heredadas podrían no poder hacer esta elección sobre el lenguaje de programación que utilizan. SOAP no especifica una API, por lo que la implementación de la API se deja al lenguaje de programación, como en Java, y la plataforma como Microsoft .Net.

No se encuentra fuertemente asociado a ningún protocolo de transporte: La especificación de SOAP no describe como se deberían asociar los mensajes de SOAP con HTTP. Un mensaje de SOAP no es más que un documento XML, por lo que puede transportarse utilizando cualquier protocolo capaz de transmitir texto.

48


Llamadas a métodos No está atado a ninguna infraestructura de objeto distribuido La mayoría de

los sistemas de objetos distribuidos se pueden extender, y ya lo están alguno de ellos para que admitan SOAP.

• Aprovecha los estándares existentes en la industria: Los principales contribuyentes a la especificación SOAP evitaron, intencionadamente, reinventar las cosas. Optaron por extender los estándares existentes para que coincidieran con sus necesidades. Por ejemplo, SOAP aprovecha XML para la codificación de los mensajes, en lugar de utilizar su propio sistema de tipo que ya están definidas en la especificación esquema de XML.

• Permite la interoperabilidad entre múltiples entornos: SOAP se desarrollo sobre los estándares existentes de la industria, por lo que las aplicaciones que se ejecuten en plataformas con dicho estándares pueden comunicarse mediante mensaje SOAP con aplicaciones que se ejecuten en otras plataformas. Por ejemplo, una aplicación de escritorio que se ejecute en una PC puede comunicarse con una aplicación del back-end ejecutándose en un mainframe capaz de enviar y recibir XML sobre HTTP.

49


Proceso Toda la comunicación entre el servicio y el consumidor, ya sea para obtener

la descripción WSDL o efectuar la invocación a métodos, se efectuará normalmente usando como canal de comunicación el protocolo HTTP (HiperText Transfer Protocol), el mismo que se utiliza de forma habitual para navegar por la web. Esto hace posible la superación de elementos que, como los citados cortafuegos, suponen un obstáculo al utilizarse vías de transmisión diferentes.

HERRAMIENTAS Y ENTORNOS DE...

Documents

Transcript of HERRAMIENTAS Y ENTORNOS DE...