• Save
Tema 3 0
Upcoming SlideShare
Loading in...5
×
 

Tema 3 0

on

  • 987 views

 

Statistics

Views

Total Views
987
Views on SlideShare
981
Embed Views
6

Actions

Likes
1
Downloads
0
Comments
0

2 Embeds 6

http://localhost 5
http://www.ieei.ual.es:81 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Tema 3 0 Tema 3 0 Presentation Transcript

  • Servicios Web Programación de Red. Ingeniería en Informática
  • Servicios WebObjetivos: 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 View slide
  • 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 View slide
  • 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
  • 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
  • Concepto de Servicio WebEscenario 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
  • SOAPObjetivos 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
  • SOAPSOAP 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
  • SOAPFuncionamiento de SOAP 12
  • SOAPFuncionamiento de SOAP 13
  • SOAPSOAP 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
  • SOAPSOAP 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
  • SOAPEjemplo 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
  • SOAPEjemplo 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
  • SOAPTipos 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
  • SOAPEstructura 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
  • SOAPEstructura 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
  • SOAPEstructura 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
  • SOAPEstructura 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
  • SOAPEstructura 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
  • SOAPEjemplo de mensaje SOAP <?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> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 24
  • SOAPEstructura 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
  • SOAPEstructura 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
  • SOAPEstructura 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
  • SOAPEstructura 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
  • SOAPEstructura 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
  • SOAPEjemplo de mensaje SOAP <?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" SOAP-ENV:mustUnderstand=“1”> 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> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 30
  • SOAPEstructura 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
  • SOAPEstructura 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
  • SOAPEjemplo de mensaje SOAP <?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> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 33
  • SOAPEjemplo de mensaje SOAP 34
  • SOAPEjemplo de mensaje SOAP <?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> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 35
  • SOAPEstructura 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
  • SOAPEjemplo de mensaje SOAP <SOAP-ENV:Envelope xmlns:SOAP- ENV=”http://schemas.xmlsoap.org/soap/envelope” SOAP- ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding”> <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
  • SOAPEstructura 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
  • SOAPEstructura 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
  • SOAPEstructura 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
  • SOAPEstructura 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
  • SOAPEjemplo 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
  • SOAPSerializació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
  • SOAPSerializació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
  • SOAPSerializació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
  • SOAPSerializació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
  • SOAPSerializació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
  • SOAPSerializació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>
  • SOAPSerializació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
  • SOAPSerializació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
  • SOAPSerializació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
  • SOAPSerializació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>
  • SOAPSerializació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]
  • SOAPSerializació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
  • SOAPSerializació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>
  • SOAPSerializació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
  • SOAPSerializació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>
  • SOAPSerializació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
  • SOAPSerializació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
  • SOAPSerializació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
  • SOAPSerializació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
  • SOAPSerializació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
  • SOAPTransporte  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>
  • SOAPTransporte  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
  • SOAPTransporte  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>
  • SOAPTransporte  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
  • SOAPTransporte  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
  • SOAPTransporte  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>
  • SOAPTransporte  Ejemplos de mensajes SOAP vistos en prácticas 69
  • SOAPTransporte  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
  • SOAPSOAP 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
  • SOAPSOAP 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
  • SOAPSOAP 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
  • SOAPSOAP para RPC (Remote Procedure Call) Estructura y contenido de un mensaje SOAP para estilo de interacción RPC 74
  • SOAPSOAP para RPC (Remote Procedure Call) 75
  • SOAPSOAP 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
  • SOAPSOAP 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>
  • SOAPSOAP 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>
  • SOAPSOAP 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
  • SOAPSOAP 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> </SOAP-ENV:Envelope> --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