1. Servicios Web
Programación de Red.
Ingeniería en Informática
2. Servicios Web
Objetivos:
Conocer el concepto de Servicios Web y toda
la tecnología asociada
Conocer los protocolos más importantes
asociados a Servicios Web
Estudiar SOAP, WSDL y UDDI (WSIL)
Dar un visión general sobre orquestación de
Servicios Web
Conocer algunos aspectos de seguridad en
Servicios Web 2
3. Servicios Web
Concepto de Servicio Web.
SOAP.
WSDL.
UDDI (WSIL).
Orquestación de Servicios Web.
Seguridad
3
4. Concepto de Servicio Web
¿Qué son los Servicios Web?
Los Servicios Web son un mecanismo de
comunicación distribuida que permiten que las
aplicaciones compartan información y que
además invoquen funciones de otras
aplicaciones, independientemente de cómo se
hayan creado las mismas, de cuál sea el
sistema operativo o la plataforma en la que se
ejecuten, y cuales los dispositivos utilizados
para obtener acceso a ellas
Sistema software diseñado para soportar la
interacción máquina-máquina en la red 4
5. Concepto de Servicio Web
¿Qué son los Servicios Web?
En realidad son componente software que
ejecutan procesos o funciones de negocio
significativas, con una interfaz bien definida y
accesible desde la red (Internet), basada en el
intercambio de documentos en XML, y que
pueden ser combinados entre sí
Son una buena tecnología para la integración
de sistemas en Internet ⇒ Todos los firewalls
reconocen http y todos los fabricantes de
tecnología venden APIs y herramientas para
invocación e implementación de servicios web 5
6. Concepto de Servicio Web
¿Qué son los Servicios Web?
Un Servicio Web es un componente software
independiente de la plataforma e implementación y
que puede ser:
Descrito mediante un lenguaje de definición de servicios
(WSDL)
Publicado en un registro público de servicios (UDDI)
Encontrado por un cliente de forma automática
mediante métodos estándar
Invocado mediante interfaces estándar (API) a través
de una red informática sobre el protocolo SOAP
Combinado con otros Servicios Web para formar un
componente más complejo (WSEL, WSFL) 6
8. Servicios Web
Concepto de Servicio Web.
SOAP.
WSDL.
UDDI (WSIL).
Orquestación de Servicios Web.
Seguridad
8
9. SOAP
¿Qué es SOAP (Simple Access Object Protocol)?
Un protocolo para el intercambio de información
en un entorno descentralizado y distribuido. Está
basado en XML y consta de tres partes:
Un envoltorio (SOAP envelope) que define una
estructura para describir qué contiene un mensaje y
cómo procesarlo,
Un conjunto de reglas de codificación SOAP
(mecanismo de serialización) para expresar
instancias de tipos de datos definidos por las
aplicaciones, y
Una forma de representar llamadas remotas a
procedimientos y sus respuestas (SOAP RPC) 9
10. SOAP
Objetivos de SOAP
Establecer un protocolo estándar de
invocación a servicios remotos que esté
basado en protocolos estándares de uso
frecuente en Internet, como son HTTP (Hiper
Text Transport Protocol) para la transmisión y
XML (eXtensible Markup Language) para la
codificación de los datos (XML messaging)
Independencia de plataforma hardware,
lenguaje de programación e implementación
del Servicio Web 10
11. SOAP
SOAP especifica:
Un formato de mensaje para comunicaciones en una
dirección, describiendo cómo se organiza la información en
un documento XML
Un conjunto de normas para implementar interacciones al
estilo RPC mediante mensajes SOAP, definiendo cómo los
clientes pueden invocar un procedimiento remoto enviando
un mensaje SOAP y cómo los servicios pueden responder
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 si no entienden el contenido
Una descripción de cómo su mensaje SOAP se debería
11
transportar sobre HTTP y SMTP
14. SOAP
SOAP como protocolo de comunicaciones
SOAP no tiene estado, abierto, modular y extensible
(sintaxis (header), datos (método para serializar los
datos, transporte (no indica cómo se transportarán los
mensajes, sino cómo se podrán transportar sobre
HTTP), propósito (no define el contenido de los
mensajes ⇒ no restringe su uso))
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
asíncronos y en una dirección (unidireccionales) 14
15. SOAP
SOAP como protocolo de comunicaciones
Cualquier complejidad adicional 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 utilizado 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
15
STMP
16. SOAP
Ejemplo de mensaje SOAP (Petición)
<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-
ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-
ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding”>
<SOAP-ENV:Header>
<h:transaction xmlns:h="http://www.Ejemplos.com/cabeceras">
43
</h:transaction>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:getPrecio xmlns:m="http://www.Ejemplos.com/pedidos">
<m:id>EF453</m:id>
</m:getPrecio>
Consulta del precio del producto con id EF453
</SOAP-ENV:Body>
</SOAP-ENV:Envelope> 16
17. SOAP
Ejemplo de mensaje SOAP (Respuesta)
<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-
ENV="http://schemas.xmlsoap.org/soap/envelope/“
SOAP-
ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encodi
ng/">
<SOAP-ENV:Body>
<Precio xmlns:m="http://www.Ejemplos.com/pedidos">
<Valor>4.12</Valor>
</Precio>
El precio del producto con id EF453 es 4.12
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
17
18. SOAP
Tipos de mensaje
Un documento de petición no implica un
documento de respuesta
Tipos de transacciones de mensajes (según
respuestas recibidas):
Petición ⇒ No se espera contestación
Petición-Respuesta ⇒ Emisión-Procesado-Resp.
Tipos de transacciones de mensajes (según
contenido de los mensajes):
EDI ⇒ Información administrativa
RPC ⇒ Petición de ejecución de procedimientos
(síncronas o asíncronas) 18
19. SOAP
Estructura y contenido de un mensaje SOAP
SOAP se basa en intercambio
de mensajes
Los mensajes son como sobres
(Envelope) donde la aplicación
encierra los datos que se van a
enviar
Mensaje tiene dos partes:
Header (cabecera) ⇒ nivel de
infraestructura
Body (cuerpo) ⇒ nivel de
aplicación 19
20. SOAP
Estructura y contenido de un mensaje SOAP
Envelope ⇒ es el elemento más importante y
de mayor jerarquía dentro del documento XML
(puede contener declaraciones de espacios de
nombre y atributos) y representa al mensaje
SOAP que lleva almacenado dicho documento
Además, sirve como contenedor para el resto
de elementos de un mensaje
Envelope ⇒ Elemento raíz del documento, es
obligatorio y contiene un elemento o ninguno
<Header> y un y sólo un bloque <Body> 20
21. SOAP
Estructura y contenido de un mensaje SOAP
Envelope ⇒ tiene que estar identificado
usando namespaces, al igual que todos los
atributos que contenga
Envelope ⇒ atributo más importante =
encodingStyle se utiliza para indicar las reglas
de serialización (empaquetado) utilizadas en el
mensaje SOAP ⇔ cómo se representan los
tipos de datos (como entero, array, etc.) dentro
del mensaje. encodingStyle ⇒ No existe un
formato de codificación por defecto, sino que
existen una serie de posibles formatos a
utilizar 21
22. SOAP
Estructura y contenido de un mensaje SOAP
Envelope ⇒ Todo mensaje SOAP debe tener
un elemento Envelope asociado al espacio de
nombres (xmlns:SOAP-ENV=)
http://schemas.xmlsoap.org/soap/envelope/. Si
un mensaje recibido por una aplicación SOAP
contiene en este elemento un valor distinto al
anterior la aplicación trataría dicho mensaje
como erróneo
Versiones SOAP 1.1 y 1.2:
http://schemas.xmlsoap.org/soap/envelope/
http://www.w3c.org/2001/06/soap-envelope/ 22
23. SOAP
Estructura y contenido de un mensaje SOAP
encodingStyle ⇒ El valor de este atributo es
una lista ordenada de una o más URIs que
identifican la regla o reglas de serialización
que pueden ser utilizadas en el mensaje, y en
el orden en el que se han de aplicar
De entre todas las posibles URIs, las más
utilizadas son:
http://schemas.xmlsoap.org/soap/encoding/
http://my.host/encoding/restricted
http://my.host/encoding/
23
25. SOAP
Estructura y contenido de un mensaje SOAP
Header ⇒ es un mecanismo genérico que se
utiliza para añadir características adicionales
(nuevas funcionalidades) al mensaje SOAP
(control de transacciones, seguridad y
autenticación, etc.). No es obligatorio, pero es
aconsejable (pero si aparece debe ser el
primero después de Envelope) para completar
la información referente a la transmisión
Header ⇒ permite introducir variantes en el
mensaje SOAP, como rutas, autentificación,
etc. siendo procesados antes que cualquier
elemento del cuerpo <Body> 25
26. SOAP
Estructura y contenido de un mensaje SOAP
Header ⇒ puede contener ningún o varios
bloques hijos de información y todos ellos
tienen que estar identificados mediante un
namespace
Header ⇒ se debe utilizar un estilo de
codificación (mediante el atributo
encodingStyle), en todos los bloques o bien
definir un estilo en el bloque raíz
Header ⇒ atributos asociados:
mustUnderstand
actor o role
26
encodingStyle
27. SOAP
Estructura y contenido de un mensaje SOAP
mustUnderstand ⇒ atributo booleano que
indica si un elemento de la cabecera puede ser
pasado por alto (opcional = 0) o no (obligatorio
= 1) por el receptor
Si al procesar un elemento se produce un
error, el mensaje de respuesta debería
devolver “MustUnderstand fault” (SOAP 1.1).
En SOAP 1.2 se define un elemento para el
bloque de cabecera denominado
<NotUnderstood> y en el que se especifica el
bloque que propició el rechazo del mensaje
por no poder procesarse (entenderse) 27
28. SOAP
Estructura y contenido de un mensaje SOAP
Un mensaje SOAP no tiene por que ser
entregado directamente al destinatario, sino
que es posible que pueda pasar por varios
intermediarios (recibir y transmitir)
actor (1.1) y role (1.2) ⇒ se puede usar para
indicar a qué punto terminal (destinos
intermedios) va dirigida una cabecera
concreta. El valor de este atributo es una URI
que identifica dicho destinatario
actor ⇒ este atributo puede ponerse como
global en la cabecera o como local en alguno
de los elementos de la misma 28
29. SOAP
Estructura y contenido de un mensaje SOAP
Si el valor de actor es
http://schemas.xmlsoap.org/soap/actor/next
entonces el receptor de la cabecera es el
primer intermediario que reciba el mensaje
Omitir el atributo significa que la cabecera va
destinada al receptor final, es decir, el mismo
que procesará la carga del mensaje
Si uno de los intermediarios detecta un
elemento en el que esté él como actor no debe
volver a transmitir, sino que debe quedarse
con el y atenderlo, y en su caso (si procede)
seguir con la transmisión (eliminar su element.)
29
31. SOAP
Estructura y contenido de un mensaje SOAP
Body ⇒ es un contenedor de información en
el cual se almacenarán los datos que se
quieran transmitir de lado a lado de la
comunicación. Es decir, contiene la carga del
mensaje (llamada a un procedimiento remoto,
orden de compra o cualquier documento XML)
Body ⇒ la carga del mensaje se representa
como elementos hijos del Body, y está
serializada según la codificación elegida. El
elemento puede contener varios bloques, y
todos ellos deben de estar cualificados con un
namespace 31
32. SOAP
Estructura y contenido de un mensaje SOAP
Body ⇒ El contenido del Body puede ser
básicamente cualquier cosa, no está
restringido en la especificación. Sin embargo,
sí se define una entrada, que es el elemento
Fault que se utiliza para informar de errores
ocurridos en el servidor dentro del mensaje
SOAP ⇔ excepciones en los servicios Web
Body ⇒ Presencia dentro del elemento
<Envelope> es de carácter obligatorio y único,
es decir, tiene que haber un y solamente un
elemento <Body> dentro de <Envelope>, y
además tiene que se descendiente directo 32
36. SOAP
Estructura y contenido de un mensaje SOAP
Fault ⇒ elemento asociado al mensaje
respuesta que se utiliza para informar de
errores ocurridos en el servidor dentro del
mensaje SOAP ⇔ excepciones en los
servicios Web
Fault ⇒ los errores en SOAP son
denominados faults, que se representan en el
elemento Fault dentro del elemento Body, y
debe aparecer como máximo una vez
Fault ⇒ define a su vez cuatro subelementos:
faultcode, faultstring, faultactor y detail36
38. SOAP
Estructura y contenido de un mensaje SOAP
faultcode ⇒ es utilizado por el software como
mecanismo para identificar el origen del fallo.
Subelemento obligatorio y tiene que estar
definido mediante namespaces. Significado
orientado a las máquinas
faultstring ⇒ contiene una cadena que
describe brevemente el error que ocurrió de
forma que tenga sentido para el usuario
faultactor ⇒ indica en qué intermediario (URI)
ocurrió el error (generador del error). Si fallo en
el receptor final, se puede omitir 38
39. SOAP
Estructura y contenido de un mensaje SOAP
detail ⇒ nos permite incluir información
adicional sobre el error ocurrido. Por lo que
tiene que estar presente si y solo si el error se
produce dentro del <Body>
detail ⇒ La especificación SOAP define un
caso en el que el intermediario que origina el
elemento Fault debe devolver obligatoriamente
información en el elemento detail: cuando un
error ocurre debido a que el servidor no pudo
procesar el mensaje correctamente
detail ⇒ puede definir nuevos bloques 39
40. SOAP
Estructura y contenido de un mensaje SOAP
SOAP 1.1 define cuatro faultcode:
VersionMismatch ⇒ este valor indica que el
espacio de nombres del elemento Envelope no era
http://schemas.xmlsoap.org/soap/envelope/
MustUnderstand ⇒ este valor es devuelto cuando
un intermediario encuentra una cabecera obligatoria
(con el atributo mustUnderstand = 1) y no puede
procesarla
Client ⇒ este valor indica que había un error en el
mensaje recibido
Server ⇒ este valor indica que ocurrió un problema
durante el procesamiento del mensaje que no está
directamente relacionado con el contenido del 40
mismo
41. SOAP
Estructura y contenido de un mensaje SOAP
En la versión SOAP 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 versión 1.1
Y puede contener elementos adicionales:
detail ⇒ como en la versión 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
41
42. SOAP
Ejemplo de mensaje SOAP
<?xml version=‘1.0’ ?>
<SOAP-ENV:Envelope xmlns:SOAP-
ENV=‘http://www.w3c.org/2001/12/soap-envelop/’>
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Receiver</faultcode>
<faultstring>Error al procesar el mensaje</faultstring>
<detail>
<p:detalles xmlns:p=‘http://www.Ejemplos.com/receptor’>
<mensaje>El receptor está caido</mensaje>
</p:detalles>
<detail>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
42
43. SOAP
Serialización (Codificación) de un mensaje SOAP
A la hora de introducir los datos en un mensaje
SOAP existen una serie de normas a tener en
cuenta
De esta forma SOAP define una serie de tipos
básicos que serán empaquetados de forma
directa y una serie de mecanismos para
empaquetar tipos complejos y estructurados
formados por elementos simples
SOAP consideró un conjunto de tipos como
tipos simples con el fin de realizar un mapeo
directo entre el propio documento SOAP y
tipos básicos de Java 43
44. SOAP
Serialización de un mensaje SOAP
Mapeo entre tipos SOAP y JAVA
Tipos básicos SOAP Tipos JAVA
SOAP-ENC:int Java.lang.Integer
SOAP-ENC:long Java.lang.Long
SOAP-ENC:short Java.lang.Short
SOAP-ENC:string Java.lang.String
SOAP-ENC:boolean Java.lang.Boolean
SOAP-ENC:float Java.lang.Float
SOAP-ENC:double Java.lang.Double
SOAP-ENC:byte Java.lang.Byte
Tipos básicos que se pueden codificar, son los
definidos por XML Schema
44
45. SOAP
Serialización de un mensaje SOAP
Las declaraciones se pueden hacer en línea,
indicando el tipo de dato a la vez que su valor
<SOAP-ENC:int id =“pisos”>11</SOAP-ENC:int>
Cadenas de texto
<empleado xsi:type=“xsi:string”>Antonio Corral</empleado>
Arrays de bytes. Como arrays de bytes se
consideran datos de tipo binario como
serializaciones de objetos, beans, etc. o
proporciones de archivos como imágenes, etc.
Codificación base64 usada en empaquetados
MIME 45
46. SOAP
Serialización de un mensaje SOAP
Enumeraciones ⇒ permiten definir un conjunto de
datos del mismo tipo (si no se especifica el tipo →
string) y con distinto valor. Ejemplo: enumeración con
los pisos de un edificio
<element name=“Calle” type=“xsd:string”/>
<element name=“Piso”>
<simpleType base=“xsd:int”>
<enumeration value=“1”/>
<enumeration value=“2”/>
<enumeration value=“3”/> <direccion>
<enumeration value=“4”/> <Calle>Altamira</Calle>
</simpleType> <Piso>3</Piso>
</element> <Puerta>B</Puerta>
<element name=“Puerta”> </direccion>
<simpleType base=“xsd:string”>
<enumeration value=“A”/>
<enumeration value=“B”/>
<enumeration value=“C”/>
</simpleType>
</element>
… 46
47. SOAP
Serialización de un mensaje SOAP
Estructuras ⇒ es una colección de valores
que son accedidos mediante distintos
nombres. Además, cada uno de los elementos
puede tener distinto tipo (no es obligatorio). Es
decir, no es más que un elemento que
contiene un conjunto de elementos hijos
almacenados cada uno de ellos en un campo
propio. Un ejemplo podría ser:
<Quote xmlns="http://namespaces.cafeconleche.org/xmljava/ch2/">
<Symbol>RHAT</Symbol>
<Price>4.12</Price>
</Quote>
47
48. SOAP
Serialización de un mensaje SOAP
Referencias ⇒ representa punteros a otros datos
(href). Este tipo se utiliza normalmente para la
generación de datos complejos. Las referencias
apuntan al identificador del elemento referenciado
<m:RestoDomicilio id=“add_2”>
<Portal>69</Portal> href ⇒ permite utilizar elementos
<Piso>5</Piso> definidos en otras partes del
<Puerta>F</Puerta>
</m:RestoDomicilio>
documento, en otros documentos, e
<m:Direccion id=“add_1”> incluso en documentos que no
<Tipo>Avenida</Tipo> estén alojados en la misma
<Calle>Federico Garcia Lorca</Calle> máquina, usando HTTP, valdrá con
<RestoDomicilio href=“#add_2”/>
indicar la URL del documento que
</m:Direccion>
… contenga la información
<m:Socio>
<Nombre>Pedro Perez</Nombre>
<Direccion href=“#add_1”/>
48
</m:Socio>
49. SOAP
Serialización de un mensaje SOAP
Referencias ⇒ también se utiliza para evitar la
escritura redundante. Además, este tipo de referencias
se utiliza en el caso de que un mismo dato se necesite
llamar desde varios lugares del documento
<m:persona xmlns:m=“urn:miURL” id=“persona_1”>
<m:nombre xsi:type=“xsd:string”>Joaquin Martinez</m:nombre>
<m:direccion xsi:type=“xsd:string”>Calle Real</direccion>
<m:ciudad xsi:type=“xsd:string”>Almeria</ciudad>
<m:telefono xsi:type=“xsd:string”>950-123123</telefono>
</m:personal>
…
<m:CheckCodigoPostal xmlns:n=“urn:miURL”>
<m:persona href=“#persona_1”/>
</m:CheckCodigoPostal>
<m:CheckTelefono xmlns:n=“urn:miURL”>
<m:persona href=“#persona_1”/>
</m:CheckTelefono>
<m:insertarBaseDatos xmlns:n=“urn:miURL”>
<m:persona href=“#persona_1”/>
</m:insertarBaseDatos>
49
50. SOAP
Serialización de un mensaje SOAP
Arrays ⇒ colecciones de datos del mismo tipo
y bajo el mismo nombre, y son accedidos a
través de su número de colocación en la
estructura. Un array en un mensaje SOAP es
representado mediante un elemento cuyo tipo
es SOAP-ENC:Array. Se construyen por
secuencias de elementos enumerados. Un
ejemplo sería los hijos de una familia
<hijos xsi:type=“SOAP-ENC:Array” SOAP-ENC:arrayType=“xsd:string[4]”>
<hijo xsi:type=“xsd:string”>Manuel</hijo>
<hijo xsi:type=“xsd:string”>Sandra</hijo>
<hijo xsi:type=“xsd:string”>Nuria</hijo>
<hijo xsi:type=“xsd:string”>Antonio</hijo>
</hijos>
50
51. SOAP
Serialización de un mensaje SOAP
Arrays ⇒ para transmitir arrays se pueden
utilizar dos tipos de codificaciones
Anónima
Con nombre
La diferencia radica en el primer caso
(anónima) los elementos irán sin nombre en su
transmisión y simplemente se accederán en el
orden en que aparecen en el documento
SOAP. Mientras que en el segundo caso (con
nombre), se especifica un nombre en el
elemento.
51
52. SOAP
Serialización de un mensaje SOAP
Arrays ⇒ Ejemplo: datos sobre poblaciones
compuestas por un array de dos elementos
(provincia, municipio)
Con nombre
<poblacion>
<provincia xsi:type=“xsd:int”>47</provincia>
<municipio xsi:type=“xsd:int”>123</municipio>
</poblacion>
Anónima ⇒ acceder a los datos de la población
por orden → uso en llamadas a funciones
<poblacion>
<xsi:type=“xsd:int”>47</xsi:type=“xsd:int”>
<xsi:type=“xsd:int”>123</xsi:type=“xsd:int”>
52
</poblacion>
53. SOAP
Serialización de un mensaje SOAP
Arrays ⇒ También se pueden definir arrays
sin tener que indicar el tipo en cada uno de los
elementos que lo componen
<hijos xsi:type=“SOAP-ENC:Array” SOAP-ENC:arrayType=“xsd:string[2]”>
<hijo>Manuel</hijo>
<hijo>Sandra</hijo>
</hijos>
Arrays de arrays ⇒ Arrays
multidimensionales, es decir, arrays que sus
elementos contienen a su vez otros arrays
<matriz xsi:type=“SOAP-ENC:Array” SOAP-ENC:arrayType=“xsd:int[2, 2]”>
<elemento>13</elemento>
<elemento>2</elemento> Hay que tener en cuenta la forma en
<elemento>26</elemento> que se llenan los elementos del array
<elemento>69</elemento> ⇒ primer elemento [1,1], segundo
</matriz> 53
[1,2], tercero [2,1], y último [2,2]
54. SOAP
Serialización de un mensaje SOAP
Arrays sin límites ⇒ En muchas ocasiones es
muy difícil o incluso imposible conocer el
tamaño de un array, para ello se utilizan los
arrays sin límites, indicado por []
<matriz xsi:type=“SOAP-ENC:Array” SOAP-ENC:arrayType=“xsd:string[2][]”>
<elementoCompuesto xsi:type=“SOAP-ENC:Array” SOAP-ENC:arrayType=“xsd:string[2]”>
<elementoSimple>dato1</elementoSimple>
<elementoSimple>dato2</elementoSimple>
</elementoCompuesto>
<elementoCompuesto xsi:type=“SOAP-ENC:Array” SOAP-ENC:arrayType=“xsd:string[2]”>
<elementoSimple>dato3</elementoSimple>
<elementoSimple>dato4</elementoSimple>
</elementoCompuesto>
</matriz>
Tenemos un array de dos elementos, cada uno de los
cuales contiene una array sin límite de elementos 54
55. SOAP
Serialización de un mensaje SOAP
Arrays sin límites ⇒ Muchas veces no se
utiliza este tipo de representación, sino que se
usan referencias a los elementos compuestos,
haciendo uso de atributo href
<matriz xsi:type=“SOAP-ENC:Array” SOAP-ENC:arrayType=“xsd:string[2][]”>
<elementoCompuesto href=“#ec1_2”/>
<elementoCompuesto href=“#ec3_4”/>
</matriz>
…
<elementoCompuesto id=“ec1_2” xsi:type=“SOAP-ENC:Array” SOAP-
ENC:arrayType=“xsd:string[2]”>
<elementoSimple>dato1</elementoSimple>
<elementoSimple>dato2</elementoSimple>
</elementoCompuesto>
<elementoCompuesto id=“ec3_4” xsi:type=“SOAP-ENC:Array” SOAP-
ENC:arrayType=“xsd:string[2]”>
<elementoSimple>dato3</elementoSimple>
<elementoSimple>dato4</elementoSimple>
55
</elementoCompuesto>
56. SOAP
Serialización de un mensaje SOAP
Arrays sin límites ⇒ Ejemplo: array que
contiene a su vez dos arrays cada uno de los
cuales contiene a su vez un array de strings
<SOAP-ENC:Array SOAP-ENC:arrayType="xsd:string[][2]">
<item href="#array-1"/>
<item href="#array-2"/>
</SOAP-ENC:Array>
<SOAP-ENC:Array id="array-1" SOAP-ENC:arrayType="xsd:string[3]">
<item>r1c1</item>
<item>r1c2</item>
<item>r1c3</item>
</SOAP-ENC:Array>
<SOAP-ENC:Array id="array-2“ SOAP-ENC:arrayType="xsd:string[2]">
<item>r2c1</item>
<item>r2c2</item>
</SOAP-ENC:Array>
56
57. SOAP
Serialización de un mensaje SOAP
Arrays parciales ⇒ Para transmisiones
incompletas de arrays, SOAP permite la
transmisión parcial de arrays, ya que puede
interesar transmitir sólo una parte del array sin
perder la posición que ocupan los datos dentro
del mismo. Ejemplo de carrera de coches (100
participantes), donde al final se obtiene un
array ordenado según la clasificación obtenido
en la línea de meta. Un periódico solicita el
podium (los tres primeros)
<corredores xsi:type=“SOAP-ENC:Array” SOAP-ENC:arrayType=“xsd:string[100]”>
<nombre m:dorsal=“15”>Antonio</nombre>
<nombre m:dorsal=“8”>Juan</nombre>
<nombre m:dorsal=“54”>Carlos</nombre> 57
</corredores>
58. SOAP
Serialización de un mensaje SOAP
Arrays parciales ⇒ Para los tres primeros, no
hay problema, ya que es posible acceder a los
elementos según el orden en el que se han
definido en la estructura. Pero … qué sucede
su solicitan los tres últimos de una lista?.
Solución: atributo SOAP-ENC:offset, que
muestra el número de elementos que hay que
contar hasta el primer elemento transmitido
<corredores xsi:type=“SOAP-ENC:Array” SOAP-ENC:arrayType=“xsd:string[100]” SOAP-
ENC:offset=“[97]”>
<nombre m:dorsal=“15”>Antonio</nombre>
<nombre m:dorsal=“8”>Juan</nombre>
<nombre m:dorsal=“54”>Carlos</nombre>
</corredores> 58
59. SOAP
Serialización de un mensaje SOAP
Arrays referenciados elemento a elemento
⇒ Si ahora se solicitan los tres primeros
corredores que empiezan por la J, entonces se
tiene que transmitir parte del array. Solución:
atributo SOAP-ENC:position, atributo que
indica la posición que ocupa dentro del array
<corredores xsi:type=“SOAP-ENC:Array” SOAP-ENC:arrayType=“xsd:string[100]”>
<nombre m:dorsal=“15” SOAP-ENC:position=“[10]”>Jorge</nombre>
<nombre m:dorsal=“8” SOAP-ENC:position=“[22]”>Juan</nombre>
<nombre m:dorsal=“54” SOAP-ENC:position=“[67]”>Jose</nombre>
</corredores>
También es posible indicar la posición en
arrays multidimensionales (elemento(6,7))
<item SOAP-ENC:position=“[5,6]”>Elemento (6,7)</item> 59
60. SOAP
Serialización de un mensaje SOAP
Elementos nulos ⇒ Muchas veces no se
tratan de la misma forma un elemento nulo que
un elemento vacío (cadena vacía), ya que
realmente no son lo mismo. Atributo nil =
elemento nulo
<elementoNulo xsi:type=“xsd:string” xsi:nil=“true”/>
Elementos defecto ⇒ Al analizar un
documento podemos encontrarnos con que no
existe ningún elemento específico. En tal caso,
puede tomar su valor por defento, el cual
depende de la situación y del tipo de dato a
recuperar (booleano (false), int (0), etc. 60
61. SOAP
Serialización (Codificación) SOAP. Resumen
En la codificación SOAP, los tipos simples se
representan como elementos simples
La codificación SOAP incluye todos los tipos simples
definidos en la especificación de XML schema ⇒ si
usamos un tipo simple con la codificación SOAP, tiene
que ser un tipo que pertenezca a los esquemas XML o
que esté derivado de alguno de ellos
Los espacios de nombres asociados con los tipos de
datos de los esquemas XML son
http://www.w3.org/2001/XMLSchema (prefijo xsd) y
http://www.w3.org/2001/XMLSchema-instance (xsi)
La especificación SOAP proporciona un atributo con el
cual podemos indicar el tipo de un elemento ⇒ atributo
xsd:type 61
62. SOAP
Serialización (Codificación) SOAP. Resumen
Ejemplo de codificación SOAP
<soap:Envelope
xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope”
soap:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>
<soap:Body>
<m:mensajeEjemplo xmlns:m=”http://www.ejemplo.org/mensaje”>
<param1 xsi:type=”xsd:int”>765</param1>
<param2 xsi:type=”xsd:string”>Esto es una prueba</param2>
</m:mensajeEjemplo>
</soap:Body>
</soap:Envelope>
El tipo base64 convierte los datos binarios a texto
utilizando el algoritmo de codificación a base64 de los
esquemas XML. Como tipos compuestos la codificación
SOAP permite definir: arrays, registros y enumerados 62
63. SOAP
Transporte
El transporte es el método por el que un mensaje
SOAP viaja del emisor al receptor
La especificación SOAP no obliga a usar un método
concreto de transporte, aunque sí incluye una
recomendación sobre como transportar mensajes
SOAP sobre HTTP (binding típico de SOAP = HTTP)
Aspecto de un mensaje SOAP sobre HTTP:
POST http://www.ejemplo.org/servlet/ServletPuntoTerminal HTTP/1.1
Content-Type: text/xml
Content-Length: nnnn
SOAPAction: “http://www.ejemplo.org/Binding”
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-
ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding”>
<SOAP-ENV:Header>
<h:transaccion xmlns:h="http://www.misEjemplos.com/cabeceras">
43
</h:transaccion>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:validarPedido xmlns:m="http://www.misEjemplos.com/pedidos">
<m:id>EF453</m:id>
</m:validarPedido>
</SOAP-ENV:Body> 63
</SOAP-ENV:Envelope>
64. SOAP
Transporte
SOAPAction es específica del protocolo SOAP. Esta
cabecera cumple dos funciones
Por un lado proporciona una forma de que los servidores
sepan que la petición HTTP POST contiene un mensaje SOAP
Por otro lado, el valor de la cabecera es una URI que indica el
propósito del mensaje SOAP
Esto permite a los firewalls y a servidores web tomar
medidas (filtrados de mensajes SOAP) basadas en la
presencia y valor de esta cabecera. Un valor vacío (“”)
significa que el propósito del mensaje SOAP es
indicado por la URI de la petición HTTP
Una cabecera SOAPAction vacía en un mensaje HTTP
POST significa que la intención del mensaje se puede
deducir de la URI objetivo del mensaje POST 64
65. SOAP
Transporte
Ejemplo que lanza una petición HTTP de tipo
POST contra un Servlet que corre en la
dirección Web www.ibiblio.org bajo el control
del usuario de nombre pepe
POST /xml/cgi-bin/SOAPHandler HTTP/1.1
Content-Type: text/xml; charset="utf-8"
Content-Length: 267
SOAPAction: "http://www.ibiblio.org/#pepe"
<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" >
<SOAP-ENV:Body>
<getQuote xmlns="http://namespaces.cafeconleche.org/xmljava/ch2/">
<symbol>RHAT</symbol>
</getQuote>
</SOAP-ENV:Body>
65
</SOAP-ENV:Envelope>
66. SOAP
Transporte
Mapeo de SOAP a un
protocolo de transporte
Un binding es una
descripción de cómo
se envía un mensaje
SOAP utilizando un
protocolo
El binding típico de
SOAP es HTTP
66
67. SOAP
Transporte
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) 67
68. SOAP
Transporte
El servidor envía la respuesta al cliente y después
cierra la conexión. Como cualquier otra respuesta
HTTP el mensaje SOAP empieza con el código de
retorno HTTP. Suponiendo que la petición tuvo
éxito y no ocurrió ningún error en el servidor:
HTTP/1.0 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: 260
<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<Quote xmlns="http://namespaces.cafeconleche.org/xmljava/ch2/">
<Price>4.12</Price>
</Quote>
</SOAP-ENV:Body>
68
</SOAP-ENV:Envelope>
70. SOAP
Transporte
HTTP no permite implementar mecanismos de
comunicación asíncronos de forma eficiente ⇒
utilizar el protocolo SMTP
Existen maneras de transportar mensajes SOAP
sobre SMTP. De esta manera un servidor podría
almacenar mensajes SOAP para su posterior
procesamiento, y el cliente no tendría que quedar
esperando una respuesta
SMTP presenta algunas carencias, como la falta
de garantía de entrega
Otra forma posible de transportar mensajes SOAP
es sobre el protocolo FTP ⇒ FTP anónimo como
transporte → envío anónimo de mensajes SOAP 70
71. SOAP
SOAP para RPC (Remote Procedure Call)
SOAP (estandarizado por W3C) es un protocolo basado en
XML para el intercambio de mensajes en un entorno
distribuido ⇒ Originalmente acrónimo y en una dirección,
aunque hoy ya no se considera acrónimo
Los mensajes SOAP se envían encapsulados en otros
protocolos TCP/IP de nivel de aplicación como HTTP o
SMTP ⇒ HTTP (protocolo de transporte síncrono) es el
usado habitualmente → buena elección para atravesar
firewalls
SOAP organiza la información utilizando XML de forma
estructurada y tipada de manera que puede ser
intercambiada entre emisor y receptor 71
72. SOAP
SOAP para RPC (Remote Procedure Call)
Con SOAP, un servicio se compone de puertos, y cada
puerto ofrece un conjunto de operaciones ⇒ Cada
operación tiene: nombre, parámetros (entrada, salida,
entrada/salida), valor de retorno y posibles “faults”
(excepciones)
Las operaciones pueden ser ⇒ Síncronas(RPC) → en las
que el cliente envía la petición y se queda bloqueado hasta
que llegue la respuesta (esta alternativa síncrona es la más
usada hoy en día) y Asíncronas → el cliente envía la
petición, continúa con su ejecución, y más adelante puede
comprobar si llegó la respuesta
SOAP estandariza la manera de enviar un mensaje para
invocar una operación del servicio y cómo enviar la
respuesta (Envelope + Header + Body) ⇒ Misma estructura
de mensaje para petición y respuesta 72
73. SOAP
SOAP para RPC (Remote Procedure Call)
En la especificación SOAP se define un conjunto
de reglas para realizar llamadas RPC sobre SOAP
⇒ convenio RPC
El convenio RPC se puede definir como una forma
de serializar las llamadas a procedimientos
remotos y las respuestas como mensajes SOAP
Llamada a un procedimiento remoto (RPC) con
SOAP ⇒ construir un mensaje que representa la
llamada remota y enviarlo al destinatario. Este
punto terminal de destino se procesa el mensaje y
devuelve la respuesta en otro mensaje SOAP ⇒
intercambio de mensaje siguiendo el paradigma
petición/respuesta 73
74. SOAP
SOAP para RPC (Remote Procedure Call)
Estructura y contenido de un mensaje SOAP para estilo
de interacción RPC
74
76. SOAP
SOAP para RPC (Remote Procedure Call)
SOAP para RPC está pensado para trabajar sobre HTTP
⇒ HTTP modela perfectamente el modelo de intercambio
síncrono de mensajes utilizado para RPC
76
77. SOAP
SOAP para RPC (Remote Procedure Call)
El mensaje SOAP que contiene la llamada llevará
en su carga una estructura que representa la
llamada al método remoto serializada.
subelementos de esta estructura = parámetros de
entrada del método. La estructura que representa
la llamada debe tener el mismo nombre que el
método, y lo mismo para los parámetros
Ejemplo de método
double convertirPesetasEuros([in] int pesetas)
Serialización de la llamada en un mensaje SOAP
<m:convertirPesetasEuros
xmlns:m=”http://EjemploRPC.com/Euroconversor”>
<m:pesetas xsi:type=”xsd:integer”>5350</m:pesetas>
77
</m:convertirPesetasEuros>
78. SOAP
SOAP para RPC (Remote Procedure Call)
En el caso de la respuesta a una llamada remota,
también tenemos una estructura dentro de la carga
del mensaje SOAP que la encapsula
El nombre de esta estructura puede ser cualquiera,
pero se suele añadir la palabra response al nombre
del método al que se llamó
Si el método devuelve un valor (nombre
irrelevante), éste debe ser el primer subelemento
de la estructura que representa la respuesta
La respuesta al procedimiento remoto sería:
<m:convertirPesetasEurosResponse
xmlns:m=”http://ejemploRPC.com/EuroConversor”>
<m:respuesta>32.15</m:respuesta> 78
</m:convertirPesetasEurosResponse>
79. SOAP
SOAP con datos adjuntos (atachments)
Puede ser necesario enviar datos adjuntos con un
mensaje SOAP y que no puedan representarse en
XML (imágenes, sonido o cualquier formato
binario). Para solucionar este problema SOAP
aprovecha el estándar MIME (Multipurpose Internet
Mail Extensions) para transmisión de datos
adjuntos en correo electrónico
En la especificación se define el concepto de
paquete SOAP. Un paquete SOAP es un
documento MIME Multipart que tendrá como raíz el
mensaje SOAP y podrá incluir partes adicionales
con los datos adjuntos. Un ejemplo de paquete
SOAP sería el siguiente: 79