WSDL & UDDI

WSDL & UDDI

Taller de Sistemas de Información 1

InCo – Facultad de Ingeniería

Abril 2004


2

Resumen de pasos para poner a funcionar un WebService

1. El proveedor crea, compone y distribuye el web service utilizando el lenguaje de programación, el middleware y la plataforma que él mismo elija.

2. El proveedor describe el web service en un documento WSDL (“web services description language”).

3. El proveedor registra el servicio en el catálogo UDDI (Universal Description, Discovery and Integration). UDDI permite registrar y hacer búsquedas en su catalogo.

4. Un usuario necesitado, busca información de los servicios que necesita en el catálogo.

5. La aplicación del usuario engancha con el webservice y lo invoca utilizando SOAP.


3

WebServices Description Language (WSDL) Es una gramática XML, orientada a describir en forma

estructurada, la funcionalidad de un Web Service y la forma en que esa funcionalidad se hace disponible.

Describe un servicio, como una colección de “comunication endpoints” (puertos) capaces de intercambiar mensajes.

Cada port tiene un definición abstracta (port type) y una definición concreta (binding).

Permite describir en forma abstracta operaciones y mensajes, prescindiendo de las especificaciones de protocolo y tipos de datos.

Vincula las descripciones abstractas a una implementación concreta de protocolos y tipos de datos, permitiendo el reuso de las definiciones abstractas.

Es extensible tanto en lo que respecta a tipos de datos (XSD) como a protocolos y formatos de mensajes.

Provee documentación sobre el servicio que describe


4

Componentes de una Descripción de Servicio (1)

Service = Conjunto de “ports” relacionados que implementan el servicio.

Port = “Port type” + “Binding” Es un descripción abstracta de una acción soportada por el servicio. Cada operación se corresponde a un mensaje de input o de output

Port type = Colección de “operations” o “signatures” de los métodos que definen el intercambio ordenado de los mensajes.

Bindings = especifica los protocolos usa cada “port” y el “encoding”.

Message = descripción de los datos que van a ser transmitidos. Son una colección de “data values” de un tipo particular (utilizando XML Schema como mecanismo de tipación).


5

Componentes de una Descripción de Servicio (2)


6

Descripción de un Servicio

1. Data types <wsdl:type/>

2. Messages <wsdl:message/>

3. Interfaces <wsdl:portType/>

4. Services <wsdl:binding/> <wsdl:service/>


7

Prefijos para referenciar namespaces

prefix namespace URI definition wsdl http://schemas.xmlsoap.org/wsdl/ WSDL namespace for WSDL

framework. soap http://schemas.xmlsoap.org/wsdl/soap/ WSDL namespace for WSDL SOAP

binding. http http://schemas.xmlsoap.org/wsdl/http/ WSDL namespace for WSDL HTTP

GET & POST binding. Mime http://schemas.xmlsoap.org/wsdl/mime/ WSDL namespace for WSDL MIME

binding. soapenc http://schemas.xmlsoap.org/soap/encoding/ Encoding namespace as defined by

SOAP 1.1 Soapenv http://schemas.xmlsoap.org/soap/envelope/ Envelope namespace as defined by

SOAP 1.1 Xsi http://www.w3.org/2000/10/XMLSchema-instance Instance namespace as defined by

XSD Xsd http://www.w3.org/2000/10/XMLSchema Schema namespace as defined by

XSD Tns (various) El “this namespase” (tns) se usa como

convención para referirse al documento corriente.


8

ServiceSoap/http request

Soap/httpresponse

Port 1

Cliente

Port 2

Http get request

Http response


9

Definición de tipos y namespaces en un doc. WSDLUso de “import” para importar una referencia de un tipo de

definición:

<?xml version=“1.0” encoding=“UTF-8”?><wsdl:definitions name=“HelloWorldDescription”

targetNamespace=“urn:HelloWorld”xmlns:tns=“urn:HelloWorld”xmlns:types=“urn:MyDataTypes”xmlns:soap=“http://schemas.xmlsoap.org/wsdl/soap/”>xmlns:wsdl=“http://schemas.xmlsoap.org/wsdl/”><wsdl:import namespace=“urn:MyDataTypes”

location=“telephonenumber.xsd”/></wsdl:definitions>


10

Describiendo la interfase del WebService<definitions …>

<wsdl:message name=“sayHello_IN”><part name=“name” type=“xsd:string” />

</wsdl:message><wsdl:message name=“SayHello_Out”>

<part name=“greeting” type=“xsd:string” /></wsdl:message<wsdl:portType name=“HelloWorldInterface”>

<wsdl:operation name=“SayHello”><wsdl input message=“tns:sayHello_IN” /><wsdl:output message=“tns:sayHello_Out” />

</wsdl:operation></wsdl:portType>…

</definitions>

Hay 4 tipos de operaciones posibles: input, output, input output, output input


11

Haciendo el “binding” con la interfase del WebService

<wsdl:binding name=“HelloWorldBinding”type=“tns:HelloWorldInterface”>

<soap:binding style=“rpc” puede ser “rpc” o “document”

transport=“http://schemas.xmlsoap.org/soap/http”/><wsdl:operation name=“sayHello”>

<soap:operation soapAction=“urn:Hello” />

<wsdl:input><soap:body use=“encoded” namespace=“…”

encodingStyle=“…” /></wsdl:input><wsdl:output>

<soap:body use=“encoded” namespace=“…”encodingStyle=“…” />

</wsdl:output></wsdl:operation>

</wsdl:binding>


12

Binding de WSDL con HTTP-GET

<wsdl:binding name=“HelloWorldBinding”type=“HelloWorldInterface”>

<http:binding verb=“GET”/><wsdl:operation name=“sayHello”>

<http:operation location=“sayHello” /><wsdl:input>

<http:urlEncoded /></wsdl:input><wsdl:ouput>

<mime:content type=“text/plain” /><wsdl:output>

<wsdl:operation></wsdl:binding>

La invocación podría ser http://localhost/sayHello?name=John La respuesta es un string de datos en formato MIME.


13

Herramientas

Existen varias herramientas disponibles para generar automáticamente el documento WSDL correspondiente a un WebServices: VisualStudio.Net IBM Web Services Toolkit Apache Web Services Toolkit Microsoft Soap Toolkit V2 Rc 0.


14

Observaciones WSDL es sin duda el estándar para describir

servicios de web. Existen otros lenguajes que apuntan a resolver

el mismo problema en ambientes más especializados.

Uno de ellos es ebXML (orientado a transacciones comerciales) www.oasis.org

Desventajas: WSDL no proveen versionado. WSDL carece de la posibilidad de especificar

una secuencia de las operaciones necesarias en un intercambio de mensajes (por ejemplo, un login previo).


15

Seguridad, derechos de uso

No existen atributos para identificar al usuario Ni especificaciones que permitan portar claves en

forma segura. (SOAP) No existen normas de autenticación,

aparentemente queda librado a la aplicación que da el servicio


16

Seguridad de los datos

No existe una especificación para encriptar y autenticar los mensajes. (SOAP).

Existe una especificación de W3C, sobre encriptación en XML, pero no está adoptada.

Al utilizar Soap, pasa a través de los Firewalls


17

Universal Description, Discovery and Integration (UDDI)

Implementa la funcionalidad de “discovery” necesaria para poder encontrar la descripción WSDL del WebService que se necesita.

UDDI tiene 2 partes: Un directorio con la metadata de todos los

WebServices, incluyendo un puntero a la descripción WSDL de cada uno.

Las definiciones de “port types” WSDL para manipular y buscar en ese directorio.

El directorio o registro es definido como una jerarquía de entidades “business”, “service” y “binding” cuyas descripciones son expresadas en XML.


18

Business Entity Provee información de quien desarrollo

el WebService: la compañía, información de contacto en la misma, categorías de la industria, identificador de negocios y la lista de los servicios provistos

A continuación presentamos un ejemplo ...


19

<businessEntity businessKey="uuid:11111111-2222-3333-4444-555555555555"operator="http://www.ibm.com"authorizedName="John Doe">

<name>Acme Company</name> <description> We create cool WebServices </description> <contacts> <contact useType="general info"> <description>General Information</description> <personName>John Doe</personName> <phone>(123) 123-1234</phone> <email>[email protected]</email> </contact> </contacts> <businessServices> ... </businessServices> <identifierBag> <keyedReference ModelKey="UUID:11111111-2222-3333-4444-555555555556" name="D-U-N-S" value="123456789" /> </identifierBag> <categoryBag> <keyedReference ModelKey="UUID:11111111-2222-3333-4444-555555555557" name="NAICS" value="111336" /> </categoryBag><businessEntity>


20

Business Services

Representa un único WebService provisto por la “Business Entity”.

La descripción incluye: tipo de WebService y a que categorías pertenece.

La forma de identificar todas las “business entities” y los “business services” en UDDI es a través del UUID (“universally unique identifiers”).


21

Ejemplo de Business Service

<businessService serviceKey=“uuid:11111111-2222-4444-5555-666666666666”

businessKey=“uuid:11111111-2222-4444-5555-666666666667”>

<name>Hello World WebServices</name>

<description>A friendly WebService</description>

<bindingTemplates>

….

</bindingTemplates>

<categoryBag />

</businessService>


22

Binding Templates Son la descripción técnica de los WebServices

representados por la estructura “business service”.

Representan la implementación del WebService. Basicamente equivalen a el elemento “service”

descripto en WSDL. Como un mismo servicio puede estar

implementado de diferentes formas y puede ser asociado a múltiples protocolos o diferentes direcciones, puede haber varios binding templates para un mismo WebService

Veamos un ejemplo a continuación …


23

<bindingTemplate serviceKey=“uuid:11111111-2222-4444-5555-666666666666”

businessKey=“uuid:11111111-2222-4444-5555-666666666667”>

<description>Hello World SOAP Binding</description>

<accessPoint URLType="http">

http://localhost:8080

<accessPoint>

<TModelInstanceDetails>

<TModelInstanceInfo TModelKey=“uuid:11111111-2222-4444-5555-666666666668”>

<instanceDetails>

<overviewDoc>

<description>

references the description of the WSDL service definition

</description>

<overviewURL>

http://localhost/helloworld.wsdl

</overviewURL>

</overviewDoc>

</instanceDetails>

</TModelInstanceInfo>

</TModelInstanceDetails>

</bindingTemplate>


24

TModels Es una forma de describir varias

estructuras “business + service + template” dentro del directorio UDDI.

Sirven para representar los nuevos “port types” dentro de WSDL. Luego se puede especificar que un determinado business service implementa ese “port type”, asociando el TModel con uno de los “binding templates” del “business service”.


25

Ejemplo de TModel

<TModel TModelKey=“uuid:xyz987…” operator=“http://www.ibm.com” authorizeName=“John Doe”>

<name>HelloWorldInterface Port Type</name> <description> An interface for a friendly WebService </description> <overviewDoc> <overviewURL> http://localhost/helloworld.wsdl </overviewURL> </overviewDoc></TModel>


26

Federación de servicios UDDI Originalmente UDDI fue pensado como un conjunto

de directorios interconectados, a través de Internet, que implementan la misma interface basada en SOAP para publicar y ubicar WebServices.

No obstante una compañía o una industria puede implementar su propio directorio de servicios UDDI. Productos como Microsoft UDDI Services para W2K Server son ejemplos de herramientas que permiten implementar estas soluciones para una intranet.


27

Interface UDDI Ofrece 2 interfaces: una para los proveedores

de servicios y otra para quien consume los servicios.

Los proveedores utilizan PublishSOAP para publicar los servicios, y los consumidores utilizan InquireSOAP para consultar por un servicio. Estos mismos servicios son descriptos en WSDL también.

El tipos de datos manejados por las interfaces UDDI (por ej. businessDetails) está en las “UDDI XML Schema definitions”. Para importar las definiciones WSDL: <import namespace=“urn:uddi-org:api” location=“http://www.uddi.org/schema/2001/uddi_v1.xsd” />


28

Publisher Interface get_authToken discard_authToken save_business save_service save_binding save_Tmodel delete_business delete_service delete_binding delete_Tmodel get_registeredInfo


29

Inquiry Interface find_binding find_business find_ltservice (por ej. lista WebServices que

correponden a un criterio dado) find_TModel get_bindingDetail get_businessDetail get_businessDetailExt get_serviceDetail get_TModelDetail


30

Como registrar un WebService Primero es necesario autenticarse con el directorio

UDDI. Se transmite un envelope SOAP, con los datos del

nuevo servicio. La registración puede ser desde un lenguaje, como

Java, a algún UDDI particular al mismo o vía un envelope SOAP a cualquier servidor UDDI que no este atado a un lenguaje particular. Ver ejemplo a continuación ...


31

<SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"xml:xsd="http://www.w3.org/1999/XMLSchema">

<SOAP-ENV:Body> <save_business generic="1.0" xmlns="urn:uddi-org:api"> <authInfo>Test</authInfo> <businessEntity> <name>IBM</name> <businessServices> <businessService> <name>Hello World Service</name> <bindingTemplates> <bindingTemplate> <accessPoint urlType="HTTP">http://localhost:8080</accessPoint> </bindingTemplate> </bindingTemplates> </businessService> </businessServices> <identifierBag> <keyedReference keyName="D-U-N-S" keyValue="123456789" TModelKey="uuid:C089FE..." /> </identifierBag> <categoryBag> <keyedReference keyName="NAICS" keyValue="11194" TModelKey="uuid:C089FE..." /> </categoryBag> </businessEntity> </save_business> </SOAP-ENV:Body></SOAP-ENV:Envelope>


32

DISCO It is difficult to query UDDI to determine what WebServices are

exposed by a particular server. DISCO allows you to discover the WebServices running on a

particular computer by providing a browse paradigm for locating a particular Web service.

You can advertise a top-level index that contains references to specific WebServices or to other DISCO files.

Because DISCO does not require you to formally register with UDDI, you can quickly expose your WebServices to other developers. Developers can browse your development server to discover the URL of a particular Web service that they need to code against.

When Visual Studio .NET creates a WebServices project, it creates a DISCO file. This file is given the same name as the project and a .vsdisco extension.

Documents

WSDL & UDDI