Tema 3 0

Servicios Web

Programación de Red.
Ingeniería en Informática

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

Servicios Web

 Concepto de Servicio Web.
 SOAP.
 WSDL.
 UDDI (WSIL).
 Orquestación de Servicios Web.
 Seguridad

3

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

 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

 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

Escenario general

7

Servicios Web

 Concepto de Servicio Web.
 SOAP.
 WSDL.
 UDDI (WSIL).
 Orquestación de Servicios Web.
 Seguridad

8

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

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

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

SOAP
Funcionamiento de SOAP

12

SOAP
Funcionamiento de SOAP

13

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

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

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

SOAP
Ejemplo de mensaje SOAP (Respuesta)
<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

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

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

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

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

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

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

SOAP
Ejemplo de mensaje SOAP
<SOAP-ENV:Header>
43
</h:transaction>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:id>EF453</m:id>
</m:getPrecio>
</SOAP-ENV:Body>

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

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

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

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

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

SOAP
<SOAP-ENV:Header>
<h:transaction xmlns:h="http://www.Ejemplos.com/cabeceras"
SOAP-ENV:mustUnderstand=“1”>
43
</h:transaction>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:id>EF453</m:id>
</m:getPrecio>
</SOAP-ENV:Body>
30

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

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

SOAP
<SOAP-ENV:Header>
43
</h:transaction>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:id>EF453</m:id>
</m:getPrecio>
</SOAP-ENV:Body>

SOAP

34

SOAP
<SOAP-ENV:Header>
43
</h:transaction>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:id>EF453</m:id>
</m:getPrecio>
</SOAP-ENV:Body>

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

SOAP
ENV=”http://schemas.xmlsoap.org/soap/envelope” SOAP-
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:MustUnderstand</faultcode>
<faultstring>Cabecera obligatoria?</faultstring>
<faultactor>http://Ejemplos.com/receptor</faultactor>
<detail>
<m:info xmlns:m=”http://www.Ejemplos.com/pedidos/”>
<puntoAcceso>Servidor2</puntoAcceso>
<hora>22:30</hora>
</m:info>
</detail>
</SOAP-ENV:Fault>
<SOAP-ENV:Body>
<SOAP-ENV:Envelope> 37

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

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

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

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

SOAP
<?xml version=‘1.0’ ?>
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>
42

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

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

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

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

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

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>

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:CheckTelefono>
<m:insertarBaseDatos xmlns:n=“urn:miURL”>
</m:insertarBaseDatos>
49

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

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

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>

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]

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>
</elementoCompuesto>
<elementoCompuesto xsi:type=“SOAP-ENC:Array” SOAP-ENC:arrayType=“xsd:string[2]”>
</matriz>

 Tenemos un array de dos elementos, cada uno de los
cuales contiene una array sin límite de elementos 54

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]”>
<elementoCompuesto id=“ec3_4” xsi:type=“SOAP-ENC:Array” SOAP-
ENC:arrayType=“xsd:string[2]”>
55

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

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>

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

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

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

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

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

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-
<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
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

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"
<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
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

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

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
<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
Transporte
 Ejemplos de mensajes SOAP vistos en prácticas

69

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

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

SOAP
 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

SOAP
 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

SOAP
Estructura y contenido de un mensaje SOAP para estilo
de interacción RPC

74

SOAP

75

SOAP
SOAP para RPC está pensado para trabajar sobre HTTP
⇒ HTTP modela perfectamente el modelo de intercambio
síncrono de mensajes utilizado para RPC

76

SOAP
 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>

SOAP
 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>

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

SOAP
SOAP con datos adjuntos (atachments)
MIME-Version: 1.0
Content-Type: Multipart/Related; boundary=SEPARACION_MIME;
type=text/xml; start="<foto33434.xml>“
Content-Description: Descripción opcional del mensaje.
--SEPARACION_MIME
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <foto33434.xml>
Content-Location: foto33434.xml
<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
...
<fotoPersonal href="http://EjemploAttachment.com/foto33434.jpeg"/>
...
</SOAP-ENV:Body>
--SEPARACION_MIME
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <http://EjemploAttachment.com/foto33434.jpeg>
Content-Location: http://EjemploAttachment.com/foto33434.jpeg
...Aquí iría la imagen jpeg... 80
--SEPARACION_MIME

Tema 3 0

Más contenido relacionado

La actualidad más candente (20)

Similar a Tema 3 0 (20)

Último (20)

Tema 3 0