Servicios Web. Capítulo 6: Tecnología Básica de los Servicios Web. Pedro Álvarez José Ángel Bañares

Transcripción

1 Servicios Web Capítulo 6: Tecnología Básica de los Servicios Web Pedro Álvarez José Ángel Bañares Departamento de Informática e Ingeniería de Sistemas

2 Índice - Capítulo 6 Infraestructura mínima para Servicios Web SOAP: Simple Access Protocol Objetivos de SOAP Estructura y contenidos de un mensaje SOAP Mapeo de SOAP a un protocolo de transporte RPC sobre SOAP SOAP asíncrono Ejemplo SOAP y Java WSDL:Web Service Description Language Objetivos de WSDL Estructura de una interface WSDL Implicaciones del modelo WSDL Utilización de WSDL UDDI: Universal Description Discovery and Integration Objetivos de UDDI Estructuras de dato UDDI Descripción del API UDDI Pasos para publicar un servicio Web 2

3 Infraestructura mínima de Servicios Web Para abordar el problema de la invocación de Servicios Web precisamos: Una sintaxis común para todas las especificaciones: Un mecanismo de interacción entre lugares remotos. La especificación de este mecanismo requiere 1. Un formato de datos común para los mensajes que se intercambian 2. Un acuerdo o norma para soportar formas de interacción específicas (p.e. mensajes o RPC) 3. Un conjunto de mapeos de mensajes en un protocolo de transporte En el contexto de los servicios Web se pueden usar diferentes protocolos de transporte: TCP/IP, HTTP para hacer tunneling, SMTP ( ) si se quiere mensajes asíncronos. Por lo tanto el mecanismo debe ser lo suficientemente general para trabajar con diferentes protocolos de transporte. El mecanismo de interacción debe permitir que las aplicaciones estén poco acopladas Por esta razón la unidad de comunicación básica será el mensaje Sin embargo, se pueden permitir también interacciones al estilo RPC, por ejemplo, cuando las dos aplicaciones fueron diseñadas originalmente sobre middlewares basados en RPC. 3

4 Infraestructura mínima de Servicios Web SOAP Lo servicios pueden intercambiar mensajes por medio de convenciones estandarizados para: Transformar una invocación en un mensaje XML Intercambiar mensajes Recuperar la invocación real al servicio desde un mensaje en XML 4

5 Infraestructura mínima de Servicios Web WDSL: Descripción de los servicios (especialmente sus interfaces) de forma estándar Cumple el papel de los IDLs en middleware convencionales, añadiendo lo necesario para tratar con la falta de un middleware centralizado que gestiona transporte y redirección de mensajes. El interface se especifica cada método, con sus parámetros de entrada y salida. Si el estilo de interacción es RPC, estos mensajes llevan los parámetros de entrada y salida del procedimiento invocado. Un fichero WSDL se puede compilar para el lenguaje de programación apropiado y generar los stubs y capas intermedias necesarias para hacer las llamadas Web de forma transparente. 5

6 Infraestructura mínima de Servicios Web cliente servicio objeto aplicación (cliente) proveedor servicio objeto aplicación (proveedor servicio) middleware basado en SOAP mensajes SOAP intercambiados sobre HTTP, SMTP, u otro transporte middleware basado en SOAP convierte llamadas de procedimiento a/de mensajes XML enviados a través de HTTP u otros protocolos. Copyright Springer Verlag Berlin Heidelberg

7 Infraestructura mínima de Servicios Web <operation name="ordergoods"> <input message = "OrderMsg"/> </operation> WSDL del proveedor del servicio La principal diferencia con middleware convencionales es la ausencia de una plataforma middleware común. Copyright Springer Verlag Berlin Heidelberg 2004 compilador WSDL (lado cliente) compilador WSDL (lado servidor) cliente servicio proveedor servicio Objeto de la aplicación (cliente) stub Objeto de la aplicación (proveedor servicio) skeleton middleware basado en SOAP mensajes SOAP middleware basado en SOAP 7

8 Infraestructura mínima de Servicios Web interface Purchasing { float getquote ( in long productid); float purchasegoods (in long productid, in long quantity) } compilador IDL (lado cliente) IDL del proveedor de servicios compilador IDL (lado servidor) objeto de la aplicación (cliente) stub objeto de la aplicación (proveedor servicio) skeleton Object Request Broker Copyright Springer Verlag Berlin Heidelberg

9 Infraestructura mínima de Servicios Web Cliente servicio Proveedor de servicio objeto aplicación (cliente) stub objeto aplicación (proveedor servicio) skeleton middleware basado en SOAP mensajes SOAP middleware basado en SOAP Sólo nos falta un servicio de nombres y directorio: Interfaces y URI en el que están disponibles los servicios mensajes SOAP (para buscar servicios) middleware basado en SOAP mensajes SOAP (para publicar descripciones de servicios) descripciones de servicio Copyright Springer Verlag Berlin Heidelberg 2004 registro UDDI 9

10 SOAP: Simple Access protocol Breve historia El W3C comienza a trabajar con SOAP en 1999 La primera versión 1.0 se basa enteramente en HTTP La siguiente revisión 1.1 (Mayo 2000) se reconvierte en un transporte genérico de información sobre una variedad de protocolos de transporte. Mayo de 2003, la nueva versión 1.2 clarifica y añade semántica adicional sobre SOAP 1.1 en términos de mapeos a protocolos y codificación XML. (Especificación en fase de revisión) Objetivos de SOAP: Como organizar la información utilizando XML de forma estructurada y tipada de forma que pueda ser intercambiada entre iguales. 10

11 SOAP especifica En concreto SOAP especifica: Un formato de mensaje para comunicaciones en una dirección, describiendo como se organiza la información en un documento XML. Un conjunto de normas para implementar interacciones al estilo RPC mediante mensajes SOAP, definiendo como los clientes pueden invocar un procedimiento remoto enviando un mensaje SOAP y como los servicios pueden replicar enviando otro mensaje al cliente. Un conjunto de reglas que cualquier entidad que procesa un mensaje SOAP debe seguir. Definen que elementos debería leer y comprender, y las acciones que deberían realizar sino entienden el contenido. Una descripción de cómo su mensaje SOAP se debería transportar sobre HTTP y SMTP. 11

12 SOAP Como protocolo de comunicación, SOAP no tiene estado Es una comunicación en una dirección. Ignora la semántica de los mensajes intercambiados. Soporta interacciones entre aplicaciones poco acopladas mediante intercambio de mensajes ASINCRONOS y en UNA DIRECCION. Cualquier complejidad posterior como mensajes síncronos y bidireccionales, o interacciones al estilo RPC requieren que SOAP se combine con un protocolo subyacente (o middleware) que tenga propiedades adicionales: Por ejemplo un protocolo de transporte síncrono como HTTP debería ser usado para transportar los dos mensajes: uno en la petición HTTP, y otro en la respuesta Como opuesto a una comunicación asíncrona con STMP. 12

13 Estructura y contenidos de un mensaje SOAP SOAP se basa en intercambio de mensajes Los mensajes son como sobres donde la aplicación encierra los datos que se van a enviar Un mensaje tiene dos partes: Header (cabecera): que se puede dividir en bloques Body (cuerpo): que se puede dividir en bloques SOAP no establece lo que hay que hacer con la cabecera y el cuerpo, solo establece que la cabecera es opcional. La cabecera es para el nivel de infraestructura. El cuerpo es para el nivel de aplicación. SOAP Envelope SOAP header Header Block SOAP Body Body Block Bloques: Cualquier primer nivel hijo. 13

14 Estructura y contenidos de un mensaje SOAP SOAP asume que cada mensaje tiene un remitente (sender) y un receptor (receiver), y un número arbitrario de intermediarios (llamados nodos) que procesan el mensaje y redirigen este al receptor. El núcleo de la información que envía el remitente al receptor está en el body. En el header, cualquier otra información para procesado intermedio o servicios de valor añadido.). Usos típicos del header son: información de coordinación, identificadores (p.e., transacciones), información de seguridad (p.e, certificados) La necesidad de los intermediarios es obvia si pensamos que el procedimiento invocado real es parte de una arquitectura de varias capas. 14

15 Estructura y contenidos de un mensaje SOAP SOAP no establece ninguna estructura posterior en el contenido de las cabecera o los mensajes. Pero existen formas comúnmente aceptadas de construir la cabecera y el cuerpo de los mensajes. Los aspectos que influyen en como se construyen el body y el header: El estilo de interacción: Estilo RPC, y estilo Documento. Si la interacción es síncrona o asíncrona es ortogonal al estilo de interacción, y no influye en la estructura. Reglas de codificación: Como se representa una estructura o dato en XML. 15

16 Estructura y contenidos de un mensaje SOAP: Estilo de interacción SOAP envelope SOAP body documento ordencompra -producto -cantidad SOAP envelope SOAP body documento Acknowledgement -id_de_orden Estilo de interacción Documento Copyright Springer Verlag Berlin Heidelberg

17 Estructura y contenidos de un mensaje SOAP: Estilo de interacción SOAP envelope SOAP body method name ordencompra input parameter 1 producto SOAP envelope SOAP body method return return value -id_de_orden input parameter 2 cantidad Estilo de interacción RPC Copyright Springer Verlag Berlin Heidelberg

18 Estructura y contenidos de un mensaje SOAP: Reglas de codificación <ProductItem> <name> </name> <type> </type> <make> </make> </ProductItem> <ProductItem name= type= make= /> <ProductItem name= <type> </type> <make> </make> </ProductItem> SOAP 1.2 no impone ninguna forma específica de codificar Si da recomendaciones (que se pueden ignorar) P.e. Codificaciones de arrays y estructuras que se pueden serializar en XML Copyright Springer Verlag Berlin Heidelberg

19 Ejemplo mensaje SOAP <?xml version= 1.0?> <SOAP:Envelope xmlns:soap=" xmlns:p = > <SOAP:Header> <p:prioridad> urgente </p:prioridad> <p:origen>cornelio@sicilia.it</p:origen> </SOAP-ENV:Header> <SOAP:Body> <p:encargo> <p:pizza nombre= Margarita > <p:tamaño> familiar </p: tamaño> <p:comentario> con mucho queso </p: comentario > </p:pizza> </p:encargo> </SOAP:Body> </SOAP:Envelope> 19

20 Estructura y contenidos de un mensaje SOAP: ejemplo <?xml version='1.0'?> <env:envelope xmlns:env=" > Ejemplo en estilo de interacción RPC envelope <env:header> <t:transactionid xmlns:t=" env:role=" env:mustunderstand="true" > </t:transactionid> </env:header> <env:body> <m:ordergoods env:encodingstyle=" xmlns:m=" <m:productitem> <name>acme Softener</name> </m:productitem> <m:quantity> 35 </m:quantity> </m:ordergoods> </env:body> header blocks body </env:envelope> Copyright Springer Verlag Berlin Heidelberg

21 Estructura y contenidos de un mensaje SOAP: cabecera SOAP permite especificar quien debería tratar la cabecera y que debería hacer con esta. Con este propósito incluye: El atributo actor SOAP: quien debería procesar el header o bloque particular. El nodo que procesa el mensaje puede jugar el papel: none, next, ultimatereceiver. None es para propagar información que no debe ser procesada. Next indica que un nodo que reciba el mensaje puede procesar este bloque. ultimatereceiver indica que la cabecera va dirigida al receptor final del mensaje. El atributio mustunderstand : con valores 1 o 0, para indicar si es obligatorio procesar el header. Si un nodo puede procesar el mensaje (como es indicado por el atributo actor), el atributo mustunderstand attribute determina si es obligatorio procesarlo. Si es obligatorio y no puede se detiene cualquier procesado posterior y se genera un fallo (fault). 21

22 <SOAP-ENV:Envelope xmlns:soap-env=" SOAP-ENV:encodingStyle=" <SOAP-ENV:Header> <t:transaction xmlns:t="some-uri" SOAP-ENV:mustUnderstand="1"> 5 </t:transaction> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:getlasttradeprice xmlns:m="some-uri"> <symbol>def</symbol> </m:getlasttradeprice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 22

23 Estructura y contenidos de un mensaje SOAP: cuerpo (body) El cuerpo es la información específica de la aplicación contenida en el mensaje Una entrada de cuerpo ( o bloque) es sintácticamente equivalente a una entrada de cabecera con atributos de actor= ultimatereceiver y mustunderstand = 1 A diferencia de las cabeceras, SOAP no especifica nada sobre el contenido de los bloques del cuerpo: Mapeo de RPC a una colección de bloques del cuerpo SOAP El bloque Fault (para representar errores en el procesamiento de un mensaje SOAP) El bloque fault tiene cuatro elementos (en v.1.1): fault code: indica la clase de error (version, mustunderstand, cliente, servidor) fault string: explicación legible del fallo fault actor: quien originó el fallo detail: información específica de la aplicación sobre la naturaleza del fallo 23

24 Estructura y contenidos de un mensaje SOAP: cabecera En la version 1.2, el bloque fault element se especifica en más detalle. Debe contener dos sub-elementos obligatoriamente: Code: Contiene un valor (el código del fallo) y probablemente un subcódigo (de información especifica de la aplicación) Reason: una cadena como en la v.1.1 Y puede contener algunos elementos adicionales: detail: como en la v.1.1 node: la identificación del nodo que produjo el fallo (si no aparece, por defecto es el receptor del mensaje) role: el role que juega el nodo que generó el fallo Errores en la comprensión de una cabecera obligatoria a procesar se responden con un bloque fault, pero también se incluye una cabecera especial que indica cual de las cabeceras originales no se comprendió.. 24

25 SOAP: Fault (ejemplo) <?xml version= 1.0?> <SOAP:Envelope xmlns:soap= > <SOAP:Body> <SOAP:Fault> <faultcode> soap: Receiver </faultcode> <faultstring> Error al procesar el mensaje </faultstring> <detail> <p:detalles xmlns:p > <mensaje>la pizza Barbacoa no puede llevar tanto queso </mensaje> </p:detalles> <detail> </SOAP:Fault> </SOAP:Body> </SOAP:Envelope> 25

26 Ejemplo mensajes SOAP Petición RPC SOAP Envelope SOAP header Contexto Transaccional Respuesta RPC (una de las dos) SOAP Envelope SOAP Envelope SOAP Body Nombre del procedimiento SOAP header Contexto Transaccional SOAP header Contexto Transaccional Input param 1 Input param 2 SOAP Body Return parameter SOAP Body Fault entry 26

27 Ejemplos de Codificación SOAP Tipos Simples <?xml version= 1.0?> <SOAP:Envelope xmlns:soap= xmlns:xsi= htpp://wwww.w3.org/2001/xmlschema encodingstyle= > <SOAP:Body> <p:pizza> <p:código xsi:type: soap:int >234</p:codigo> <p:tamaño xsi:type = soap:string >familiar</p:tamaño> </p:pizza> </SOAP:Body> </SOAP:Envelope> 27

28 Ejemplos de Codificación SOAP Estructuras Struct Pizza { int codigo; string nombre }; <Pizza xmlns= cualquier_uri > <codigo>234</codigo> <nombre>barbacoa</nombre> </Pizza> Arrays <pizzas xsi:type= soap:array soap:arraytype= p:pizzas[2] > <pizza> <codigo>234</codigo> <nombre>barbacoa</nombre> </pizza> <pizza><codigo>237</codigo> <nombre>barbacoa</nombre> </pizza> </pizzas> 28

29 Ejemplos de Codificación SOAP Arrays parciales <pizzas xsi:type= soap:array soap:arraytype= p:pizzas[10] soap:offser= [4] > <pizza> <codigo>234</codigo> <nombre>barbacoa</nombre> </pizza> <pizza><codigo>237</codigo> <nombre>barbacoa</nombre> </pizza> </pizzas> <pizzas xsi:type= soap:array soap:arraytype= p:pizzas[10] > <pizza soap:position= 2 > <codigo>234</codigo> <nombre>barbacoa</nombre> </pizza> < pizza soap:position= 5 ><codigo>237</codigo> <nombre>barbacoa</nombre> </pizza> </pizzas> 5º y 6º elemento 2º y 5º elemento 29

30 Mapeo de SOAP a un protocolo de transporte Un binding es una descripción de como se envía un mensaje SOAP utilizando un protocolo. El binding típico de SOAP es HTTP SOAP puede usar GET o POST. Con GET, la petición no es un mensaje SOAP pero la respuesta es un mensaje SOAP, con POST la petición y la respuesta son mensajes SOAP (en la versión 1.2, la versión 1.1 considera sobre todo el uso de POST). La dirección del servidor: En el caso de HTTP el URL, en el caso de SMTP la dirección to. NO FORMA parte del mensaje SOAP. HTTP POST SOAP Envelope SOAP header Transactional context SOAP Body Name of Procedure Input parameter 1 Input parameter 2 30

31 Una llamada RPC sobre SOAP HTTP Post SOAP envelope SOAP header transactional context SOAP body cliente servicio name of the procedure input parameter 1 proveedor servicio SOAP engine HTTP engine input parameter 2 HTTP engine SOAP engine Implementación cliente (otras capas) HTTP Post SOAP envelope SOAP header transactional context Implementación servicio (otras capas) SOAP body return parameter Copyright Springer Verlag Berlin Heidelberg

32 Una llamada RPC sobre SOAP cliente servicio proveedor servicio implementación cliente implementación del servicio invoca el servicio como una llamada local stub del cliente Invoca un procedimiento local que Implementa el servicio stub del servidor invoca el SOAP engine para construir el mensaje SOAP SOAP engine Mapea el mensaje SOAP en HTTP y lo pasa a un cliente HTTP que lo envía al proveedor HTTP engine El router parsea el mensaje, identifica el stup apropiado, y envía el mensaje parseado SOAP router pasa el contenido del mensaje HTTP al router HTTP server Copyright Springer Verlag Berlin Heidelberg

33 SOAP asíncrono El Estilo RPC da lugar a sistemas muy acoplados Muchos sistemas B2B utilizan interacciones estilo documento asíncronas. En lugar de interacciones directas, se usan colas. Una forma de de lograr interacciones asíncronas SOAP es mediante el protocolo STMP Otra forma es utilizar procesos separados (idéntico a como ser haría con sistemas basados en RPC para implementar RPC asíncronos) 33

34 SOAP como un protocolo sencillo SOAP no incluye nada sobre fiabilidad intercambio de mensajes complejos transacciones seguridad Como tal, no es adecuado por si solo para implementar aplicaciones industriales que incorporen características típicas de middlewares como transacciones o envío fiable de mensajes SOAP necesita que se estandaricen estas características: WS-security WS-Coordination WS-Transactions 34

35 Ejemplo SOAP sencillo 1 // Fig. 29.1: SimpleService.java 2 // Implementation for the requested method on the server 3 4 public class SimpleService { 5 6 public String getwelcome( String message ) throws Exception 7 { 8 String text = 9 "Welcome to SOAP!\nHere is your message: " + message; return text; // response 12 } 13 } La clase SimpleService reside en el servidor El método devuelve un String 35

36 Apache SOAP Disponible en: xml.apache.org/soap SOAP RPC requiere un servlet engine como Tomcat jakarta.apache.org y un parser como Xerces de Apache Xml.apache.org/xerces-j/index.html Axis (continuación) Herramienta de administración SOAP de Apache 36

37 Apache SOAP Descripción del servicio servido 37

38 1 // Fig : GetMessage.java 2 // Program that makes a SOAP RPC 3 4 // import Java packages 5 import java.io.*; 6 import java.net.*; 7 import java.util.*; 8 9 // import third-party packages 10 import org.apache.soap.*; 11 import org.apache.soap.rpc.*; public class GetMessage { // main method 16 public static void main( String args[] ) { 17 String encodingstyleuri = Constants.NS_URI_SOAP_ENC; 18 String message; if ( args.length!= 0 ) 21 message = args[ 0 ]; 22 else 23 message = "Thanks!"; // attempt SOAP remote procedure call 26 try { 27 URL url = new URL( 28 " ); // build call 31 Call remotemethod = new Call(); 32 remotemethod.settargetobjecturi( 33 "urn:xml-simple-message" ); APIs de la implementación SOAP Cliente RPC Especifica estilo de codificación de los mensajes SOAP Especifica URL del servidor Instancia objeto Call y establece su URI 38

39 35 // set name of remote method to be invoked 36 remotemethod.setmethodname( "getwelcome" ); 37 remotemethod.setencodingstyleuri( encodingstyleuri ); // set parameters for remote method 40 Vector parameters = new Vector(); parameters.addelement( new Parameter( "message", 43 String.class, message, null ) ); 44 remotemethod.setparams( parameters ); 45 Response response; // invoke remote method 48 response = remotemethod.invoke( url, "" ); // get response 51 if ( response.generatedfault() ) { 52 Fault fault = response.getfault(); System.err.println( "CALL FAILED:\nFault Code = " 55 + fault.getfaultcode()+ "\nfault String = " 56 + fault.getfaultstring() ); 57 } else { 60 Parameter result = response.getreturnvalue(); // display result of call 63 System.out.println( result.getvalue() ); 64 } 65 } 66 Construye parámetros utilizados para invocar método getwelcome de SimpleService Invoca método getwelcome y almacena el valor devuelto en el objeto Response Muestra un mensaje si ocurre un error Muestra el valor devuelto por el método si no hay error 39

40 67 // catch malformed URL exception 68 catch ( MalformedURLException malformedurlexception ) { 69 malformedurlexception.printstacktrace(); 70 System.exit( 1 ); 71 } // catch SOAPException 74 catch ( SOAPException soapexception ) { 75 System.err.println( "Error message: " + 76 soapexception.getmessage() ); 77 System.exit( 1 ); 78 } 79 } 80 } java GetMessage Welcome to SOAP! Here is your message: Thanks! java GetMessage "my message Welcome to SOAP! Here is your message: my message 40

41 Plataformas para servicios Web basados en Java Cada plataforma tiene diferentes formas de implementar los servicios Web SUN: Java Web Services Developer Pack (JWSDP) CapeConnect ( Glue Standard (www-themindelectric.com) IONA Orbix E3A XMLBus ( WASP Server for Java ( Axis (sucesor del Apache SOAP 2.2, xml.apache.org/axis) 41

42 WSDL: Web Services Description Language WSDL es equivalente a los IDLs, pero los Servicios Web son más complejos de describir Además de definir las operaciones, hay que definir los mecanismos de interacción (bindings). En middleware convencionales, siempre se usa el mismo middleware, por lo que el mecanismo de acceso es implícito al middleware Solo se aborda nombre de servicio y signatura En los servicios Web cada servicio se puede servir con distintos protocolos Hay que indicar la localización del servicio En middleware convencionales la localización del objeto es transparente (el middleware se encarga de localizar el objeto) La ausencia de una plataforma de servicios Web centralizada implica conocer la localización donde enviar el mensaje SOAP Cabe la posibilidad del mismo servicio con distintos protocolos de transporte y en diferentes localizaciones. 42

43 WDSL Las interacciones son con frecuencia asíncronas en Servicios Web: Los IDLs convencionales describen un único punto de entrada al servicio (una interacción RPC única) La invocación de un servicio Web suele conllevar el intercambio de varios mensajes asíncronos. WSDL incluye una colección de diferentes paradigmas de interacción, junto con la posibilidad de combinar operaciones o grupos de operaciones en un interface. 43

44 Estructura de un Interface WSDL Una especificación WSDL consta de: Una parte abstracta (analoga a un IDL) Se definen los tipos. Las estructuras de datos que se intercambian. Los esquemas XML tienen tipos de datos básicos, pero permiten definir estructuras. Se definen los mensajes. Cada mensaje es un documento tipado con partes. Cada parte se caracteriza por un nombre y un tipo. Por ejemplo, la invocación de un procedimiento con dos parámetros, un entero y un real se puede definir como un mensaje con dos partes Se definen las operaciones. Existen 4 tipos de operación: One-way: El cliente invoca un servicio enviando un único mensaje. (1 mensaje, asíncrono) Notificacions: El servidor envía un único mensaje (1 mensaje, asíncrono) Request-response: El servidor es invocado y responde (2 mensajes, síncrono) Solicit-response: El servidor invoca y espera respuesta (2 mensajes, síncrono) Se definen tipos de puerto, que agrupan operaciones. Una parte concreta:define el protocolo de transporte (binding) y otras informaciones especificación WSDL parte abstracta tipos mensajes operaciones tipos de puertos parte concreta bindings servicios y puertos Copyright Springer Verlag Berlin Heidelberg

45 Estructura de un Interface WSDL Para definir (concretar) una instancia de servicio real, se tiene que definir : El conjunto exacto de puertos que implementa Los protocolos de transporte usados en la implementación de los tipos de puertos Las direcciones en los que estas accesibles El mismo tipo de mensaje, puede ser codificado de distintas maneras. Una parte concreta consta de: 1. InterfaceBindings: Especifica la codificación del mensaje y el protocolo de transporte (protocol bindings) para todas las operaciones y mensajes definidos en un tipo de puerto. Por ejemplo: Una operación en estilo RPC o documento El mensaje de una operación tiene que utilizar SOAP como protocolo de aplicación, y HTTP como protocolo de transporte. Reglas de codificación utilizadas para serializar partes de un mensaje en XML. Dos opciones: literal (utilizado normalmente en document style, toma las definiciones de esquema XML) y encoding (utilizado normalmente en estilo RPC, utiliza reglas de codificación SOAP). especificación WSDL parte abstracta tipos mensajes operaciones tipos de puertos parte concreta bindings servicios y puertos Copyright Springer Verlag Berlin Heidelberg

46 Estructura de un Interface WSDL Una parte concreta consta de (cont.): 2. Ports (EndPoints): Combinan la información de los InterfaceBindings con direcciones de red (especificados por URI) en la que se puede acceder a la implementación del tipo de puerto. 3. Servicios: Agrupaciones lógicas de puertos. Un servicio específico WSDL podría estar accesible en diferentes direcciones (p.e. URIs de diferentes máquinas, una em Europa y otra en América) Normalmente un servicio WSDL agrupa puertos relacionados, disponibles con frecuencia en una misma dirección. Otra agrupación posible es utilizar diferentes ports que representan diferentes bindings del mismo tipo de puerto. Permiten, en definitiva, que la misma funcionalidad sea accesible en diferentes estilos de interacción y con diferentes protocolos de transporte. especificación WSDL parte abstracta tipos mensajes operaciones tipos de puertos parte concreta bindings servicios y puertos Copyright Springer Verlag Berlin Heidelberg

47 Estructura de un Interface WSDL Añadiendo InterfaceBindings, Ports y Services, la definición del interface se va concretando. Con la información de binding, los usuarios conocen que protocolos usar, como estructurar los mensajes XML, y que se espera al enviar el mensaje. WSDL 1.1 define en la actualidad extensiones binding para SOAP, HTTP GET y POST, y MIME. Con la información de port, el usuario conoce la dirección en la que se implementa un tipo de puerto. Con el service el usuario conoce todos los puertos que están implementados como un grupo. 47

48 <?xml version="1.0"?> <definitions name="procurement" targetnamespace=" xmlns:tns=" xmlns:xs=" xmlns:soap=" xmlns=" > <message name="ordermsg"> <part name="productname" type="xs:string"/> <part name="quantity" type="xs:integer"/> </message> Ejemplo WSDL abstract part messages <porttype name="procurementporttype"> <operation name="ordergoods"> <input message = "OrderMsg"/> </operation> </porttype> operation and port type <binding name="procurementsoapbinding" type="tns:procurementporttype"> <soap:binding style="document" transport=" <operation name="ordergoods"> <soap:operation soapaction=" <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> <service name="procurementservice"> <port name="procurementport" binding="tns:procurementsoapbinding"> <soap:address location=" </port> Postgrado </service> Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico </definitions> concrete part binding port and service Copyright Springer Verlag Berlin Heidelberg

49 Ejemplo WSDL <?xml version= 1.0 encoding= utf-8?> <definitions xmlns:s= <types> <s:schema <s:element name= suma > <s:complex Type> <s:sequence> <s:element minoccurs= 1 maxoccus= 1 name= a type= s:int /> <s:element minoccurs= 1 maxoccus= 1 name= b type= s:int /> </s:sequence> </s:complex Type> </s:element>. abstracta <message name= sumasoapin > <part name= parameters element= s0:suma /> </message> + 49

50 Ejemplo WSDL <porttype name= ServicioSumaSoap > <operation name= suma > <input message= so:sumasoapin/> <output message= so:sumasoapout /> </operation> </porttype> <binding name = ServicioSumaSoap type= so:serviciosumasoap > <soap:binding transport= style= document /> <operation name= suma > <soap:operationsoapaction= style= document /> <input> <soap:body use= literal /> </input> <output> <soap:body use= literal /> </output> </operation> </binding> <service name= ServicioSuma > <port name= ServicioSumaSoap binding= s0:serviciosumasoap > <soap:address location= /> <port> </service> Departamento </definitions> de Informática e Ingeniería de Sistemas (Univ. Zaragoza) abstracta concreta 50

51 Implicaciones del Modelo WSDL Los diferentes tipos de interacción: Suponen que un servidor puede invocar servicios (se comporta como un cliente). Típico en middlewares orientados a mensajes. La ventaja de la separación de la parte abstracta y concreta es que la primera puede reutilizarse Un WDSL puede importar otro WDSL. Por ejemplo, un WDSL puede importar la parte abstracta y concretar los bindings y las direcciones. Si los mensajes definido en WSDL se intercambian en SOAP, entonces el InterfaceBinding contiene toda la información necesaria para construir automáticamente los mensajes SOAP. 51

52 Utilización de WSDL El W3C ha identificado tres usos potenciales de WSDL: 1. Lenguaje de descripción de servicio tradicional (contrato que implementa un Servicio Web). El contrato indica como interactuar con el servicio, datos a enviar y devolver, operaciones involucradas y el formato y protocolo. 2. Entrada para compiladores de stub y otras herramientas: Las bases de datos comerciales han comenzado a ofrecer funcionalidad para generar automáticamente las descripciones WSDL de procedimientos almacenados Los servidores de aplicaciones dan facilidades para generar stubs de documento WSDL y para generar WSDL de clases (p.e. Clases java). 3. Uso no definido claramente por el W3C en referencia a la semántica. WSDL para capturar la información que permitirá a los diseñadores razonar sobre la semántica de los servicios. Pero la semántica está fuera en estos momentos de la especificación WSDL! 52

53 Utilización de WSDL compilador WSDL (lado del cliente) WSDL del proveedor del servicio 2 compilador WSDL (lado del servidor) 1 generador WSDL cliente servicio service provider objeto de aplicación (cliente) objeto de aplicación proveedor servicio) stub skeleton middleware basado en SOAP Mensajes SOAP middleware basado en SOAP Copyright Springer Verlag Berlin Heidelberg

54 UDDI: Universal Description Discovey and Integration Primera propuesta en Septiembre de 2000 (IBM, Ariba y Microsoft), desde la versión 3 (julio 2002) bajo el paraguas OASIS Objetivos UDDI: Especificar un framework para describir y descubrir servicios Web Todo gira alrededor de la noción de bussines registry (un servicio de nombres y directorio) La idea era registrar cada servicio desarrollado en el mundo UDDI define estructuras de datos y APIs para publicar descripciones de servicios y buscar servicios. Al ser a su vez un servicio Web, las APIs de UDDI están también especificadas en WSDL con SOAP. Permite dos cosas_ A los desarrolladores encontrar información para escribir los clientes de los servicios Permite dynamic binding, permitiendo a los clientes preguntar al registro y obtener las referencias a los servicios de interés. 54

55 UDDI Se clasifica en función de para que se usa la información (similar a directorio telefónico) Páginas blancas: Información de contacto.listados de organizaciones y servicios. Los cliente UDDI pueden encontrar servicios Web dados por una empresa. Páginas amarillas: Información de industria. clasificación de compañías y servicios Web de acuerdo a una taxonomía. Páginas Verdes: Información técnica y especificaciones. Describe como puede ser invocado un servicio Web. Punteros a descripciones de servicios (descripciones externas al registro UDDI). 55

56 Estructuras de datos UDDI Un registro UDDI contiene cuatro tipos de información: BusinessEntity:Describe la organización que ofrece el servicio. Nombre, dirección y otra información de contacto. BusinessService:Grupo de servicios Web relacionados ofrecido por una BusinessEntity (empresa), pero ofrecida en diferentes direcciones, versiones, y tecnologías. Al igual que las BusinessEntity, pueden incluir información de clasificación. Corresponde con una clase de servicio (p.e. Reserva de viaje) BusinessTemplate:Información técnica para utilizar el servicio. Dirección del servicio Referencias documentos (tmodels) describiendo el interface u otras propiedades. Como dar valor a los parámetros y valores por defecto tmodels (Technical model): Contenedor genérico para cualquier especificación. P.e. Puede representar un interface de servicio en WSDL, una clasificación, un protocolo de interacción, o la semántica de una operación. 56

57 businessentity nombre contactos descripción indentificadores categorías businessservice clave de servicio nombre descripción categorías bindingtemplate clave de binding descripción dirección información detallada referencia a tmodels tmodel keytmodel key name clave name description nombre description overviewdoc descripción overviewdoc identifiers identifiers categories indentificadores categories categorías tmodel tmodel key clave name nombre description descripción overviewdoc identifiers indentificadores categories categorías documento(overviewdoc) Documento (overviewdoc) Especificaciones almacenadas en el sitio del proveedor Almacenado en el registro UDDI Copyright Springer Verlag Berlin Heidelberg

58 modelo de datos UDDI Proveedor: Información sobre la entidad que ofrece el servicio 0..n La información clave sobre un servicio se especifica en un tmodel tmodel: Descripciones de especificaciones de servicios Servicio: Información sobre una familia particular de ofertas 0..n Binding: Información técnica sobre un punto De entrada a un servicio 0..n Bindings contienen referencias a tmodels. Estas referencias declaran las especificaciones del interface. 58

59 Ejemplo de un tmodel UDDI Descripción del API UDDI Especificación en WSDL overviewdoc (especificaciones en WSDL y del API) <tmodel tmodelkey= uddi:uddi.org:v3_publication > <name>uddi-org:publication_v3</name> <description>uddi Publication API V3.0</description> <overviewdoc> <overviewurl usetype= wsdlinterface > </overviewurl> </overviewdoc> <overviewdoc> <overviewurl usetype= text > </overviewurl> </overviewdoc> Especificación en lenguaje natural información de clasificación (especifica que este tmodel trata de especificaciones XML, WSDL, y SOAP) <categorybag> <keyedreference keyname= uddi-org:types:wsdl keyvalue="wsdlspec" tmodelkey="uddi:uddi.org:categorization:types /> <keyedreference keyname= uddi-org:types:soap keyvalue="soapspec" tmodelkey="uddi:uddi.org:categorization:types /> <keyedreference keyname= uddi-org:types:xml keyvalue="xmlspec" tmodelkey="uddi:uddi.org:categorization:types /> <keyedreference keyname= uddi-org:types:specification keyvalue="specification" tmodelkey="uddi:uddi.org:categorization:types /> </categorybag> Un tmodel puede hacer referencia a otros tmodels </tmodel> Copyright Springer Verlag Berlin Heidelberg

60 API del registro UDDI Tres tipos de clientes Los proveedores de servicio que publican Los clientes que buscan Otros registros que intercambian información Seis conjuntos de APIs 1. Pregunta/Búsqueda de servicio (UDDI Inquiry API): Para obtener información que satisfaga ciertos criterios find_business, find-services, find_binding, find_tmodel Para obtener detalles de una entidad específica get_bussinesdetail, getservicedetail, get_bindingdetail, get_tmodeldetail Este API es para browsers utilizados por desarrolladores, o por clientes que realizan dynamic binding 2. Publicación de servicio (UDDI Publishers API): Para proveedores de servicio. Permite añadir, modificar y eliminar entradas. Ejemplo operaciones: Save_business, save_service, save_binding,save_tmodel, delete_service, delete_binding, delete_tmodel 60

61 API del registro UDDI 3. Seguridad (UDDI Security API): Permite a los usuarios UDDI obtener y deshacerse de tokens para ser utilizados en posteriores comunicaciones con el registro: get_authtoken, discard_authtoken 4. Custodia y transferencia de pertenencia (UDDI Custody and Ownership Transfer API): Permite a los registros transferir la custodia de la información entre ellos, y transferir la posesión de estas estructuras de unos a otros: get_transfertoken, transfer_entities, transfer_custody 5. Suscripción (UDDI Suspscription API): Permite monitorizar los cambios en el registro suscribiéndose al seguimiento de nuevas entradas, modificaciones o eliminaciones de entradas delete subscription, get_subscriptionresults, get_subscription, save_subscription 6. Replica (UDDI Replication API): Soporta la replicación de información en distintos registros, de forma que se pueda sincronizar su información. 61

62 API del registro UDDI cliente servicio proveedor servicio Se mantiene diferentes puntos de acceso (URIs) para clientes, proveedores y Otros registros SOAP/HTTP SOAP/HTTPS Los clientes no precisan autentificación Los proveedores y los otros registros si API Búsqueda API Publicación API Búsqueda API Publicación interface Servicio Web interface Servicio Web descripciones de servicios Registro UDDI A APIs de Suscripción, replicación, y transferencia de custodia (SOAP/HTTPS) descripciones de servicios Registro UDDI B Copyright Springer Verlag Berlin Heidelberg

63 Ejemplo de trabajo Un usuario puede encontrar una descripción WSDL de la siguiente manera 1. Utiliza find_tmodel para recuperar una lista de claves tmodels (tmodel keys) corrrespondientes a entradas wsdlspec. En el ejemplo se pregunta por todos los servicios de precios de libros que estén en wsdl. <?xml version="1.0"?> <find_tmodel generic="1.0" xmlns="urn:uddi-org:api"> <categorybag> <keyedreference tmodelkey="uuid:c25893af b5-4192c2ab9e2c" keyname="uddi-org:types" keyvalue="wsdlspec"/> <keyedreference tmodelkey="uuid:a15019c5-ae14-236c-331c ae0221" keyname="book pricing" keyvalue=" "/> </categorybag> 63

64 Ejemplo de trabajo 2. Utiliza get_tmodeldetail para recuperar los tmodels especificados por las descripciones específicas de servicios. 3. Examina el campo overviewdoc para recuperar el contenido del documento WSDL que describe el interface. cliente servicio Proveedor servicio Descripciones WSDL del servicio SOAP/HTTP SOAP/HTTPS API Búsqueda API publicación interface servicio Web tmodel Copyright Springer Verlag Berlin Heidelberg 2004 Descripciones servicio Registro UDDI businessentity businessservice bindingtemplate 64

65 proveedor de servicio Pasos para publicar un servicio Web Implementación servicio server stub SOAP router HTTP engine Generador WSDL descripción del servicio en WSDL compilador WSDL Publicación en UDDI businessentity businessservice bindingtemplate tmodel API de búsqueda API publicación registro UDDI Copyright Springer Verlag Berlin Heidelberg

66 Bibliografía Material elaborado a partir del libro y del material que acompaña al libro en Web Services Concepts, Architectures and Applications Springer Verlag 2004 ISBN By Gustavo Alonso, Fabio Casati, Harumi Kuno, Vijay Machiraju y del libro: Advanced Java 2 Platform - How to program- y del material que lo acompaña en by Deitel, Deitel, Satry ISBN: