Servicios Web

Servicios Web
Capítulo 6:
Tecnología Básica de los Servicios Web
Pedro Álvarez
[email protected]
José Ángel Bañares
[email protected]
http://diis.unizar.es/PostWeb/
Departamento de Informática e Ingeniería de Sistemas
Índice - Capítulo 6
o
o
o
o
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
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
2
Infraestructura mínima de Servicios Web
o
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.
2.
3.
Un formato de datos común para los mensajes que se intercambian
Un acuerdo o norma para soportar formas de interacción específicas (p.e.
mensajes o RPC)
Un conjunto de mapeos de mensajes en un protocolo de transporte
u
En el contexto de los servicios Web se pueden usar diferentes
protocolos de transporte: TCP/IP, HTTP para hacer tunneling, SMTP
(e-mail) si se quiere mensajes asíncronos.
s
•
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.
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
3
Infraestructura mínima de Servicios Web
o
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
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
4
Infraestructura mínima de Servicios Web
o
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.
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
5
Infraestructura mínima de Servicios Web
proveedor servicio
cliente servicio
objeto aplicación
(cliente)
objeto aplicación
(proveedor
servicio)
middleware
basado en SOAP
middleware
basado en SOAP
mensajes SOAP
intercambiados sobre
HTTP, SMTP, u otro
transporte
convierte llamadas de procedimiento
a/de mensajes XML enviados a través
de HTTP u otros protocolos.
Copyright Springer Verlag Berlin Heidelberg 2004
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
6
Infraestructura mínima de Servicios Web
<operation name="orderGoods">
<input message = "OrderMsg"/>
</operation>
Copyright Springer Verlag Berlin Heidelberg 2004
WSDL del
proveedor del
servicio
compilador WSDL
(lado cliente)
La principal diferencia con
middleware convencionales es
la ausencia de una plataforma
middleware común.
compilador WSDL
(lado servidor)
cliente servicio
proveedor servicio
Objeto de la
aplicación
(cliente)
Objeto de la
aplicación
(proveedor servicio)
stub
skeleton
middleware
basado en SOAP
middleware
basado en SOAP
mensajes SOAP
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
7
Infraestructura mínima de Servicios Web
IDL del
proveedor
de servicios
interface Purchasing {
float getQuote ( in long productId);
float purchaseGoods (in long productId, in long
quantity)
}
compilador IDL
(lado cliente)
compilador IDL
(lado servidor)
objeto de la
aplicación
(cliente)
objeto de la
aplicación
(proveedor servicio)
stub
skeleton
Object Request Broker
Copyright Springer Verlag Berlin Heidelberg 2004
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
8
Infraestructura mínima de Servicios Web
Cliente servicio
Proveedor de servicio
objeto aplicación
(cliente)
objeto aplicación
(proveedor
servicio)
stub
skeleton
middleware
basado en SOAP
middleware
basado en SOAP
mensajes SOAP
mensajes SOAP
(para buscar servicios)
Sólo nos falta un servicio de nombres
y directorio:
•Interfaces y URI en el que están
disponibles los servicios
mensajes SOAP
(para publicar descripciones de servicios)
middleware basado en SOAP
descripciones de servicio
Copyright Springer Verlag Berlin Heidelberg 2004
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
registro UDDI
9
SOAP: Simple Access protocol
o
o
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.
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
10
SOAP especifica
o
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.
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
11
SOAP
o
o
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.
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
12
Estructura y contenidos
de un mensaje SOAP
o
o
o
o
o
o
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.
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
13
Estructura y contenidos
de un mensaje SOAP
o
o
o
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.
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
14
Estructura y contenidos
de un mensaje SOAP
o
o
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.
u
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.
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
15
Estructura y contenidos
de un mensaje SOAP: Estilo de interacción
SOAP envelope
SOAP envelope
SOAP body
SOAP body
documento
ordenCompra
-producto
-cantidad
documento
Acknowledgement
-id_de_orden
Estilo de interacción Documento
Copyright Springer Verlag Berlin Heidelberg 2004
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
16
Estructura y contenidos
de un mensaje SOAP: Estilo de interacción
SOAP envelope
SOAP envelope
SOAP body
SOAP body
method name
ordenCompra
method return
input parameter 1
producto
return value
-id_de_orden
input parameter 2
cantidad
Estilo de interacción RPC
Copyright Springer Verlag Berlin Heidelberg 2004
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
17
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 2004
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
18
Ejemplo mensaje SOAP
<?xml version=‘1.0’ ?>
<SOAP:Envelope
xmlns:SOAP="http://www.w3c.org/2001/12/soap-envelop/"
xmlns:p =‘http://www.mafia.it/pizzas’>
<SOAP:Header>
<p:prioridad> urgente </p:prioridad>
<p:origen>[email protected]</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>
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
19
Estructura y contenidos
de un mensaje SOAP: ejemplo
Ejemplo en estilo de interacción RPC
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope" >
<env:Header>
<t:transactionID
xmlns:t="http://intermediary.example.com/procurement"
env:role="http://www.w3.org/2002/06/soap-envelope/role/next"
env:mustUnderstand="true" >
57539
</t:transactionID>
</env:Header>
envelope
header
blocks
<env:Body>
<m:orderGoods
env:encodingStyle="http://www.w3.org/2002/06/soap-encoding"
xmlns:m="http://example.com/procurement">
<m:productItem>
<name>ACME Softener</name>
</m:productItem>
<m:quantity>
35
</m:quantity>
</m:orderGoods>
</env:Body>
body
</env:Envelope>
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Copyright Springer Verlag Berlin Heidelberg 2004
20
Estructura y contenidos
de un mensaje SOAP: cabecera
o
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).
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
21
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<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>
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
22
Estructura y contenidos
de un mensaje SOAP: cuerpo (body)
o
o
o
o
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
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
23
Estructura y contenidos
de un mensaje SOAP: cabecera
o
o
o
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ó. .
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
24
SOAP: Fault (ejemplo)
<?xml version=‘1.0’ ?>
<SOAP:Envelope
xmlns:SOAP=‘http://www.w3c.org/2001/12/soap-envelop/’>
<SOAP:Body>
<SOAP:Fault>
<faultcode> soap: Receiver </faultcode>
<faultstring> Error al procesar el mensaje </faultstring>
<detail>
<p:detalles xmlns:p ‘http://www.mafia.it/pizzas’>
<mensaje>La pizza Barbacoa no puede llevar tanto queso </mensaje>
</p:detalles>
<detail>
</SOAP:Fault>
</SOAP:Body>
</SOAP:Envelope>
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
25
Ejemplo mensajes SOAP
Petición RPC
SOAP Envelope
SOAP header
Contexto
Transaccional
Respuesta RPC (una de las dos)
SOAP Envelope
SOAP header
SOAP Body
Nombre del
procedimiento
Input param 1
Input param 2
Contexto
Transaccional
SOAP Body
Return parameter
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
SOAP Envelope
SOAP header
Contexto
Transaccional
SOAP Body
Fault entry
26
Ejemplos de Codificación SOAP
Tipos Simples
<?xml version=‘1.0’ ?>
<SOAP:Envelope
xmlns:SOAP=‘http://www.w3.org/2001/12/soap-envelop/’
xmlns:xsi=“htpp://wwww.w3.org/2001/XMLSchema”
encodingStyle=‘http://www.w3.org/2001/12/soap-enconding’>
<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>
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
27
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>
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
28
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>
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
5º y 6º
elemento
2º y 5º
elemento
29
Mapeo de SOAP a un protocolo de
transporte
o
o
o
o
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.
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
HTTP POST
SOAP
SOAP Envelope
Envelope
SOAP header
Transactional
context
SOAP Body
Name of Procedure
Input parameter 1
Input parameter 2
30
Una llamada RPC sobre SOAP
HTTP Post
SOAP envelope
SOAP header
transactional
context
SOAP body
cliente servicio
SOAP
engine
HTTP
engine
Implementación cliente
(otras capas)
name of the
procedure
input parameter 1
input parameter 2
HTTP Post
SOAP envelope
proveedor servicio
HTTP
engine
SOAP
engine
Implementación servicio
(otras capas)
SOAP header
transactional
context
SOAP body
return
parameter
Copyright Springer Verlag Berlin Heidelberg 2004
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
31
Una llamada RPC sobre SOAP
proveedor servicio
cliente servicio
implementación
cliente
invoca el servicio
como una llamada local
stub del cliente
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
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
implementación
del servicio
Invoca un procedimiento local que
Implementa el servicio
stub del servidor
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 2004
32
SOAP asíncrono
o
o
o
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)
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
33
SOAP como un protocolo sencillo
o
o
o
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
Þ…
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
34
Ejemplo SOAP sencillo
1
2
3
4
5
6
7
8
9
10
11
12
13
// Fig. 29.1: SimpleService.java
// Implementation for the requested method on the server
public class SimpleService {
public String getWelcome( String message ) throws Exception
{
String text =
"Welcome to SOAP!\nHere is your message: " + message;
return text;
// response
La clase
SimpleService
reside en el servidor
El método devuelve un String
}
}
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
35
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)
http://ws.apache.org/
Herramienta de administración SOAP de Apache
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
36
Apache SOAP
Descripción del servicio servido
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
37
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
// Fig. 29.4 : GetMessage.java
// Program that makes a SOAP RPC
// import Java packages
import java.io.*;
import java.net.*;
import java.util.*;
// import third-party packages
import org.apache.soap.*;
import org.apache.soap.rpc.*;
APIs de la implementación
SOAP
public class GetMessage {
// main method
public static void main( String args[] ) {
String encodingStyleURI = Constants.NS_URI_SOAP_ENC;
String message;
if ( args.length != 0 )
message = args[ 0 ];
else
message = "Thanks!";
Cliente RPC
Especifica estilo
de codificación
de los mensajes
SOAP
Especifica URL del
servidor
// attempt SOAP remote procedure call
try {
URL url = new URL(
"http://localhost:8080/soap/servlet/rpcrouter" );
// build call
Call remoteMethod = new Call();
Postgrado Servicios
Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
remoteMethod.setTargetObjectURI(
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
"urn:xml-simple-message" );
Instancia objeto
Call y establece su
URI
38
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
// set name of remote method to be invoked
remoteMethod.setMethodName( "getWelcome" );
remoteMethod.setEncodingStyleURI( encodingStyleURI );
// set parameters for remote method
Vector parameters = new Vector();
parameters.addElement( new Parameter( "message",
String.class, message, null ) );
remoteMethod.setParams( parameters );
Response response;
// invoke remote method
response = remoteMethod.invoke( url, "" );
// get response
if ( response.generatedFault() ) {
Fault fault = response.getFault();
System.err.println( "CALL FAILED:\nFault Code = "
+ fault.getFaultCode()+ "\nFault String = "
+ fault.getFaultString() );
}
else {
Parameter result = response.getReturnValue();
// display result of call
System.out.println( result.getValue() );
}
Postgrado}Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
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
67
68
69
70
71
72
73
74
75
76
77
78
79
80
// catch malformed URL exception
catch ( MalformedURLException malformedURLException ) {
malformedURLException.printStackTrace();
System.exit( 1 );
}
// catch SOAPException
catch ( SOAPException soapException ) {
System.err.println( "Error message: " +
soapException.getMessage() );
System.exit( 1 );
}
}
}
java GetMessage
Welcome to SOAP!
Here is your message: Thanks!
java GetMessage "my message”
Welcome to SOAP!
Here is your message: my message
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
40
Plataformas para servicios Web basados
en Java
o
Cada plataforma tiene diferentes formas de implementar los servicios
Web
Þ SUN: Java Web Services Developer Pack (JWSDP)
Þ CapeConnect (www.capeclear.com)
Þ Glue Standard (www-themindelectric.com)
Þ IONA Orbix E3A XMLBus (www.iona.com)
Þ WASP Server for Java (www.systinet.com)
Þ Axis (sucesor del Apache SOAP 2.2, xml.apache.org/axis)
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
41
WSDL:
Web Services Description Language
o
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
u
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.
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
42
WDSL
o
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.
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
43
Estructura de un Interface WSDL
o
Una especificación WSDL consta de:
Þ Una parte abstracta (analoga a un IDL)
• Se definen los tipos. Las estructuras de datos que se
intercambian.
u
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.
u
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:
u
u
u
u
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)
especificación WSDL
parte abstracta
tipos
mensajes
operaciones
tipos de puertos
parte concreta
bindings
servicios y
puertos
• Se definen tipos de puerto, que agrupan operaciones.
Þ Una parte concreta:define el protocolo de transporte
(binding) y otras informaciones
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Copyright Springer Verlag Berlin Heidelberg 2004
44
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:
u
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
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Copyright Springer Verlag Berlin Heidelberg 2004
45
Estructura de un Interface WSDL
Þ Una parte concreta consta de (cont.):
2. Ports (EndPoints):
u 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:
u 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)
u Normalmente un servicio WSDL agrupa puertos
relacionados, disponibles con frecuencia en una
misma dirección.
u Otra agrupación posible es utilizar diferentes
ports que representan diferentes bindings del
mismo tipo de puerto.
u Permiten, en definitiva, que la misma
funcionalidad sea accesible en diferentes estilos
de interacción y con diferentes protocolos de
transporte.
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
especificación WSDL
parte abstracta
tipos
mensajes
operaciones
tipos de puertos
parte concreta
bindings
servicios y
puertos
Copyright Springer Verlag Berlin Heidelberg 2004
46
Estructura de un Interface WSDL
o
o
o
o
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.
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
47
<?xml version="1.0"?>
<definitions name="Procurement"
targetNamespace="http://example.com/procurement/definitions"
xmlns:tns="http://example.com/procurement/definitions"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/" >
Ejemplo
WSDL
<message name="OrderMsg">
<part name="productName" type="xs:string"/>
<part name="quantity" type="xs:integer"/>
</message>
<portType name="procurementPortType">
<operation name="orderGoods">
<input message = "OrderMsg"/>
</operation>
</portType>
abstract
part
messages
operation and
port type
<binding name="ProcurementSoapBinding" type="tns:procurementPortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="orderGoods">
<soap:operation soapAction="http://example.com/orderGoods"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
concrete
part
<service name="ProcurementService">
<port name="ProcurementPort" binding="tns:ProcurementSoapBinding">
<soap:address location="http://example.com/procurement"/>
</port>
</service>
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
</definitions>
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
port and
service
binding
Copyright Springer Verlag Berlin Heidelberg 2004
48
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>
…
+
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
49
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=“http://schemas.xmlsoap.org/soap/http” style=“document” />
<operation name=“suma”>
<soap:operationsoapAction=“http://tempuri.org/suma” 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=http://localhost/Suma/Service1.asmx“ />
<port>
</service>
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
</definitions>
Departamento
de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
abstracta
concreta
50
Implicaciones del Modelo WSDL
o
o
o
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.
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
51
Utilización de WSDL
o
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!
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
52
Utilización de WSDL
WSDL del
proveedor del
servicio
1
2
compilador WSDL
(lado del cliente)
generador
WSDL
compilador WSDL
(lado del servidor)
cliente servicio
service provider
objeto de aplicación
proveedor servicio)
objeto de aplicación
(cliente)
stub
skeleton
middleware
basado en SOAP
middleware
basado en SOAP
Mensajes SOAP
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Copyright Springer Verlag Berlin Heidelberg 2004
53
UDDI: Universal Description Discovey
and Integration
o
o
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.
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
54
UDDI
o
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
contacto
y servicios. Los cliente UDDI pueden encontrar servicios Web
dados por una empresa.
Þ Páginas amarillas: Información de industria.
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).
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
55
Estructuras de datos UDDI
o
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.
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
56
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
tModel
tModel
key
key
clave
name
name
nombre
description
description
descripción
overviewDoc
overviewDoc
Documento (overviewDoc)
identifiers
identifiers
indentificadores
categories
categories
categorías
tModel
tModel
key
clave
name
nombre
description
descripción
overviewDoc
documento(overviewDoc)
identifiers
indentificadores
categories
categorías
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Especificaciones
almacenadas en
el sitio del
proveedor
Almacenado en el registro UDDI Copyright Springer Verlag Berlin Heidelberg 2004
57
modelo de datos UDDI
io
vic
r
e
s
un del
e
r
o
sob tM
e
v
la
un
n c a en
ó
i
c
c
ma pecifi
r
o
inf se es
La
Proveedor: Información sobre la entidad que
ofrece el servicio
tModel: Descripciones de especificaciones
de servicios
0..n
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.
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
58
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”>
http://uddi.org/wsdl/uddi_api_v3_binding.wsdl#UDDI_Publication_SoapBinding
</overviewURL>
</overviewDoc>
<overviewDoc>
Especificación en lenguaje natural
<overviewURL useType=”text”>
http://uddi.org/pubs/uddi_v3.htm#PubV3
</overviewURL>
</overviewDoc>
información de
clasificación
(especifica que
este tModel trata
de especificaciones
XML, WSDL, y
SOAP)
<categoryBag>
Un tModel puede
<keyedReference keyName=”uddi-org:types:wsdl”
a otros tModels
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>
hacer referencia
</tModel>
Copyright Springer Verlag Berlin Heidelberg 2004
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
59
API del registro UDDI
o
o
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
•
§
Para obtener detalles de una entidad específica
•
§
2.
find_business, find-services, find_binding, find_tModel
get_bussinesDetail, getServiceDetail, get_bindingDetail,
get_tModelDetail
Este API es para browsers utilizados por desarrolladores, o por clientes que
realizan dynamic binding
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
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
60
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:
•
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:
•
5.
get_transferToken, transfer_entities, transfer_custody
Suscripción (UDDI Suspscription API):
§ Permite monitorizar los cambios en el registro suscribiéndose al seguimiento de
nuevas entradas, modificaciones o eliminaciones de entradas
•
6.
get_authToken, discard_authToken
delete__subscription, get_subscriptionResults,
get_subscription, save_subscription
Replica (UDDI Replication API):
§ Soporta la replicación de información en distintos registros, de forma que se
pueda sincronizar su información.
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
61
API del registro UDDI
cliente servicio
SOAP/HTTP
API Búsqueda
proveedor servicio
Se mantiene diferentes puntos de acceso
(URIs) para clientes, proveedores y
Otros registros
•Los clientes no precisan autentificación
•Los proveedores y los otros registros si
SOAP/HTTPS
API Publicación
API Publicación
interface Servicio Web
interface Servicio Web
descripciones de servicios
API Búsqueda
APIs de
Suscripción,
replicación, y
transferencia de
custodia
(SOAP/HTTPS)
Registro UDDI A
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
descripciones de servicios
Registro UDDI B
Copyright Springer Verlag Berlin Heidelberg 2004
62
Ejemplo de trabajo
o
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-1977-3528-36B5-4192C2AB9E2C"
keyName="uddi-org:types" keyValue="wsdlSpec"/>
<keyedReference tModelKey="UUID:A15019C5-AE14-236C-331C-650857AE0221"
keyName="book pricing"
keyValue="36611349"/>
</categoryBag>
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
63
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.
Proveedor servicio
cliente servicio
Descripciones
WSDL del
servicio
SOAP/HTTP
SOAP/HTTPS
API Búsqueda
API publicación
tModel
interface servicio Web
businessEntity
Copyright Springer Verlag Berlin Heidelberg 2004
Descripciones servicio
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Registro UDDI
businessService
bindingTemplate
64
proveedor de servicio
Implementación
servicio
Pasos para
publicar un
servicio
Web
server stub
1
Generador
WSDL
descripción del
servicio en WSDL
SOAP router
compilador
WSDL
HTTP engine
Publicación en
UDDI
2
3
businessEntity
businessService
bindingTemplate
API de búsqueda
tModel
API publicación
registro UDDI
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
Copyright Springer Verlag Berlin Heidelberg 2004
65
Bibliografía
o
Material elaborado a partir del libro y del material que acompaña al libro
en http://www2.inf.ethz.ch/~alonso/WebServicesBook.html
Web Services
Concepts, Architectures
and Applications
Springer Verlag 2004
ISBN 3-540-44008-9
By Gustavo Alonso, Fabio Casati, Harumi Kuno, Vijay Machiraju
o
y del libro: Advanced Java 2 Platform - How to program- y del material
que lo acompaña en http://www.deitel.com/books/downloads.html
by Deitel, Deitel, Satry ISBN: 0130895601
Postgrado Servicios Web, Seguridad Informática y Aplicaciones de Comercio Electrónico
Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
66