(Transmisi n de im genes de v deo mediante Servicios...

4. Servicios Web XML

Francisco Prieto Donate 83

4 SERVICIOS WEB XML

4.1 Introducción

Los Servicios Web son aplicaciones autodescriptivas que se publican, se ubican y

se invocan desde cualquier lugar de la Web, con el fin de simplificar el desarrollo de

complejas aplicaciones distribuidas.

Estos servicios permiten invocar funciones software a través de Internet,

permitiendo que programas basados en PHP, ASP, JSP, JavaBeans y otros muchos

puedan hacer peticiones a servicios que se estén ejecutando en una máquina remota y

obtener la respuesta para que pueda ser integrada en una página web, un servicio WAP

o cualquier otra aplicación.

El concepto de servicio web comienza a extenderse impulsado por los grandes

gigantes de la informática como Sun, Oracle, HP, Microsoft e IBM. No aporta muchas

novedades en cuanto a implementación, pero sí en cuanto a concepto, facilitando y

simplificando el acceso a software a través de la red.

La estandarización de los servicios web se realiza a través de dos comités: OASIS

(Organization for the Advancement of Structured Information Standards) y W3C

(World Wide Web Consortium). Para mejorar la interoperabilidad entre distintas

implementaciones de servicios web surgió la organización WS-I (Web Services

Interoperatibility Organization), que ha desarrollado una serie de perfiles para definir

mejor los estándares implicados.

4.1.1 Evolución de los Servicios Web

En los años 80, los protocolos de comunicación no ocupaban un lugar demasiado

importante para los desarrolladores, ya que conseguir que las aplicaciones se

comunicaran entre sí ya era un reto más que suficiente. Es a partir de los años 90 cuando

empiezan a sugir algunas estructuras de objetos, como COM (Modelo de Objeto

Componente, desarrollado por Microsoft) y CORBA (Arquitectura de negociación de

petición de objetos comunes), que permitían a los programadores invocar desde una

aplicación la ejecución de código binario de otra aplicación que se ejecutaba en la

misma máquina.

Transmisión de Imágenes de Vídeo mediante Servicios Web XML sobre J2ME

84 Francisco Prieto Donate

Una vez que las redes locales empezaron a extenderse en los años 90 se hizo

imprescindible la comunicación entre equipos. Se creó IIOP (Internet Inter-ORB

Protocol) como protocolo de CORBA, DCOM (Distributed COM) como protocolo de

COM y posteriormente RMI (Remote Method Invocation) para los usuarios de Java.

Mediante el uso de cualquiera de estos protocolos, una aplicación compatible

puede invocar componentes que residan en otros ordenadores de la red. El problema

radica en que estos protocolos no son interoperables, es decir, los usuarios que utilizan

DCOM únicamente pueden llamar a servidores compatibles con DCOM. Por otro lado

las soluciones anteriores tienen un requisito de simetría, de modo que no existe el

paradigma cliente-servidor y por tanto es obligatoria la implantación del mismo modelo

de distribución de objetos en ambos extremos de la comunicación. Esto no se puede

garantizar en un entorno tan abierto como Internet.

Tras la aparición de XML a mediados de los 90 nació la posibilidad de estructurar

la información de una manera uniforme y autodescriptiva, lo que dio pie a utilizar este

lenguaje para aplicar un formato a los mensajes intercambiados entre sistemas. Se

implementó un protocolo llamado XML-RPC que permitía llamar a procedimientos de

equipos remotos sin tener en cuanta los detalles de sus sistemas operativos o entornos

de lenguaje. La evolución del protocolo XML-RPC dio origen al actual SOAP (Simple

Object Access Protocol).

4.1.2 Conceptos básicos

Muchas de las ideas detrás de los servicios web son asombrosamente simples y no

son una novedad en el mundo de las redes e Internet:

• El proveedor de servicios web define un formato para las peticiones a un servicio

y de las respuestas que generará.

• Un ordenador realiza una petición a través de una red.

• El servicio web realiza la acción solicitada y devuelve la respuesta

Esta acción puede consistir en buscar un valor actual de la bolsa, encontrar el

mejor precio para un producto determinado, guardar una reunión en una agenda,

traducir un fragmento de texto a cualquier lenguaje o validar el número de una tarjeta de

crédito.



La razón del repentino crecimiento de los servicios web es la incorporación de

protocolos estándar para invocar servicios y transmitir datos, como son SOAP y WSDL,

ambos basados en XML.

4.2 XML

4.2.1 Introducción

XML es un Lenguaje de Etiquetado Extensible muy simple y a la vez estricto, que

juega un papel fundamental en el intercambio de una gran variedad de datos. Es un

lenguaje que puede parecer muy similar a HTML pero su función principal es describir

y estructurar datos y no mostrarlos como es el caso de HTML. XML permite la lectura

de datos a través de diferentes aplicaciones. En definitiva, sirve para estructurar,

almacenar e intercambiar información.

La especificación XML define un procedimiento estándar para añadir etiquetas

(también llamadas marcas) a los documentos; de hecho XML es un meta-lenguaje para

definir lenguajes de marcas. En otras palabras, XML ofrece unas reglas para definir

etiquetas y relaciones estructurales entre ellas. Al no haber etiquetas predefinidas no

existe una semántica a priori; toda la semántica de un documento XML debe ser

definida bien por la aplicación que lo procesa o bien por hojas de estilo.

Un documento XML tiene dos estructuras, una lógica y otra física.

• Físicamente, el documento está compuesto por unidades llamadas entidades.

Cada documento comienza con una entidad documento, también llamada raíz.

• Lógicamente, el documento está compuesto de declaraciones, elementos,

comentarios, referencias a caracteres e instrucciones de procesamiento, todos los

cuales están indicados por una marca explícita.

Las estructuras lógica y física deben encajar de manera adecuada.

Existen dos tipos de documentos XML: válidos y bien formados.

• Bien formados: son todos los que cumplen las especificaciones del lenguaje

respecto a las reglas sintácticas.



• Válidos: Además de estar bien formados, siguen una estructura y una semántica

determinada por un fichero de definición (que es una especie de definición de la

gramática del documento). Existen distintas formas de definir estos ficheros de

definición, entre ellas DTD y XML Schema.

4.2.2 Reglas sintácticas

A continuación se expone un ejemplo muy simple de un archivo XML.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<Alumno><nombre>Fernando Jaime</nombre><apellido>Pérez Borrero</apellido><direccion>C\Gardenia 15</direccion></Alumno>

En la primera línea se indica que lo que la sigue es XML. Puede tener varios

atributos (los campos que van dentro de la declaración), algunos obligatorios y otros no:

• version: indica la versión de XML usada en el documento. La versión actual es la

1.0. Su uso es obligatorio, a no ser que sea un documento externo a otro que ya lo

incluía.

• encoding: es la forma en que se ha codificado el documento. Por defecto es UTF-

8, aunque podrían utilizarse otras, como UTF-16, US-ASCII, ISO-8859-1, etc.

No es obligatorio salvo que sea un documento externo a otro principal.

• standalone: indica si el documento va acompañado de un DTD

(standalone=”no”), o no lo necesita (standalone=”yes”); en principio no hay

por qué ponerlo, porque más adelante se indica el DTD si se necesita.

En cuanto a la sintaxis del documento se han de resaltar las siguientes reglas:

• Los documentos XML son sensibles a mayúsculas, esto es, en ellos se diferencia

las mayúsculas de las minúsculas. Por ello <alumno> sería una etiqueta diferente

a <Alumno>.

• Todos los espacios y retornos de carro se tienen en cuenta (dentro de las

etiquetas, en los elementos).



• Hay algunos caracteres especiales reservados, que forman parte de la sintaxis de

XML: <, >, &, " y '. En su lugar cuando queramos representarlos deberemos usar

las entidades < , > , & , " y ' respectivamente.

• Los valores de los atributos de todas las etiquetas deben ir siempre

entrecomillados. Son válidas las dobles comillas (") y la comilla simple (').

Observando el contenido del ejemplo se puede diferenciar entre elementos y

etiquetas: los elementos son las entidades en sí, lo que tiene contenido, mientras que las

etiquetas sólo describen a los elementos. Un documento XML está compuesto por

elementos, y en su sintaxis éstos se nombran mediante etiquetas.

Hay dos tipos de elementos: los vacíos y los no vacíos. Hay varias

consideraciones importantes a tener en cuenta al respecto:

• Toda etiqueta no vacía debe tener una etiqueta de cerrado: <etiqueta> debe tener

su correspondiente </etiqueta>

• Todos los elementos deben estar perfectamente anidados, es decir, las etiquetas

deben ser cerradas en orden inverso al que se abrieron.

<Alumno><nombre>Fernando Jaime</Alumno></nombre> -- > INCORRECTO

<Alumno><nombre>Fernando Jaime</nombre></Alumno> -- > CORRECTO

• Los elementos vacíos son aquellos que no tienen contenido dentro del

documento. Un ejemplo en HTML son los saltos de línea (<br>). La sintaxis

correcta para estos elementos implica que la etiqueta tenga siempre esta forma:

<etiqueta/>.

4.2.3 DTD (Definición de Tipos de Documentos)

Un DTD no es más que un conjunto de definiciones de los elementos que puede

incluir un documento XML, de la forma en que deben hacerlo (qué elementos van

dentro de otros) y los atributos que se les puede dar.

Hay varios modos de referenciar un DTD en un documento XML:



• Incluir dentro del documento una referencia al documento DTD en forma de URI

(Universal Resource Identifier, o identificador universal de recursos) mediante la

siguiente sintaxis:

<!DOCTYPE Alumno SYSTEM "http://www.esi.us.es/~fprieto/DTD/Alumno.dtd >

En este caso la palabra SYSTEM indica que el DTD se obtendrá a partir de un

elemento externo al documento e indicado por el URI que lo sigue.

• O bien incluir dentro del propio documento el DTD de este modo:

<?xml version="1.0"?><!DOCTYPE Alumno [<!ELEMENT Alumno (nombre+, apellido+, direccion+, foto?)><!ELEMENT nombre (#PCDATA)><!ATTLIST nombre sexo (masculino|femenino) #IMPLIED><!ELEMENT apellido (#PCDATA)><!ELEMENT direccion (#PCDATA)><!ELEMENT foto EMPTY>]><Alumno><nombre>Fernando Jaime</nombre><apellido>Pérez Borrero</apellido><direccion>C\Lagunilla 15</direccion></ficha>

La forma de incluir el DTD directamente como en este ejemplo pasa por añadir a

la declaración <!DOCTYPE y después del nombre del nombre del tipo de documento,

en vez de la URI del DTD, el propio DTD entre los símbolos '[' y ']'. Todo lo que hay

entre ellos será considerado parte del DTD.

En cuanto a la definición de los elementos, es bastante intuitiva: después de la

cláusula <!ELEMENT se incluye el nombre del elemento (el que luego se indicará en la

etiqueta), y después diferentes opciones en función del elemento:

• Entre paréntesis, si el elemento es no vacío, se indica el contenido que puede

tener el elemento: la lista de elementos hijos o que descienden de él si los tiene,

separados por comas; o el tipo de contenido, normalmente #PCDATA, indicando

datos de tipo texto, que son los más habituales.

• Si es un elemento vacío, se indica con la palabra EMPTY.



A la hora de indicar los elementos descendientes (los que están entre paréntesis)

vemos que van seguidos de unos caracteres especiales: '+', '*', '?' y '|'. Sirven para indicar

qué tipo de uso se permite hacer de esos elementos dentro del documento:

• + : uso obligatorio y múltiple; permite uno o más elementos de ese tipo dentro del

elemento padre, pero como mínimo uno.

• * : opcional y múltiple; puede no haber ninguna ocurrencia, una o varias.

• ? : opcional y singular; puede no haber ninguno o como mucho uno.

• | : equivale a un OR, es decir, da la opción de usar un elemento de entre los que

forman la expresión, y solo uno.

De este modo, si por ejemplo encontramos en un DTD la siguiente declaración:

<!ELEMENT Alumno (nombre+, apellido+, direccion*, foto?,telefono*|fax*)>

Indica que elemento Alumno puede contener los siguientes elementos: un nombre

y un apellido como mínimo, pero puede tener más de uno de cada; opcionalmente puede

incluirse una o varias direcciones, pero no es obligatorio; opcionalmente también se

puede incluir una única foto; y por fin, pueden incluirse, aunque no es obligatorio en

ninguno de los dos casos, uno o más teléfonos o uno o más números de fax.

4.2.4 XML Schema

XML Schema es algo similar a un DTD, es decir, que define qué elementos puede

contener un documento XML, cómo están organizados, y qué atributos y de qué tipo

pueden tener sus elementos.

Las ventajas de XML Schema con respecto a los DTDs son:

• Usan sintaxis de XML, al contrario que los DTDs.

• Permiten especificar los tipos de datos.



• Son extensibles.

Por ejemplo, XML Schema permite definir el tipo del contenido de un elemento o

de un atributo, y especificar si debe ser un número entero, o una cadena de texto, o una

fecha, etc. Los DTDs no nos permiten llegar a tal grado de concreción.

Veamos un ejemplo de un documento XML, y su Schema correspondiente:

<documento xmlns="x-schema:personaSchema.xml"><persona id="Fernando Jaime"><nombre>Fernando Jaime Pérez Borrero</nombre></persona></documento>

Como se puede ver en el documento XML anterior, se hace referencia a un

espacio de nombres llamado "x-schema:personaSchema.xml". Es decir, le estamos

diciendo al analizador sintáctico XML que valide el documento contra el Schema

"personaSchema.xml".

El Schema sería algo parecido a esto:

<Schema xmlns="urn:schemas-microsoft-com:xml-data"xmlns:dt="urn:schemas-microsoft-com:datatypes"><AttributeType name='id' dt:type='string' required='yes'/><ElementType name='nombre' content='textOnly'/><ElementType name='persona' content='mixed'><attribute type='id'/><element type='nombre'/></ElementType><ElementType name='documento' content='eltOnly'><element type='persona'/></ElementType></Schema>

El primer elemento del Schema define dos espacios de nombres. El primero, xml-

data, le dice al analizador que esto es un Schema y no otro documento XML cualquiera.

El segundo, datatypes, nos permite definir el tipo de elementos y atributos utilizando el

prefijo dt.

En la siguiente tabla se muestra el significado de cada uno de las etiquetas

contenidas en el XML Schema.



Nombre Significado

ElementType Define el tipo y contenido de un elemento, incluyendo

los sub-elementos que pueda contener.

AttributeType Asigna un tipo y condiciones a un atributo.

Attribute Declara que un atributo previamente definido por

AttributeType puede aparecer como atributo de un

elemento determinado.

Element Declara que un elemento previamente definido por

ElementType puede aparecer como contenido de otro

elemento.

Tabla 4.1: Significado de las etiquetas contenidas en el XML Schema

Es necesario empezar el Schema definiendo los elementos más profundamente

anidados dentro de la estructura jerárquica de elementos del documento XML. Las

declaraciones de tipo ElementType y AttributeType deben preceder a las declaraciones

de contenido Element y Attribute correspondientes.

4.2.5 Espacios de nombres XML

Los XML Namespaces (Espacios de nombres XML) proporcionan un método

para evitar conflictos en los nombres de los elementos. Como los elementos en XML no

están predefinidos, podría ocurrir un conflicto de nombres cuando dos elementos

diferentes usan los mismos nombres de elementos

El siguiente documento XML lleva información sobre una tabla:

<table>



<tr><td>Apples</td><td>Bananas</td></tr>

</table>

Y el documento que viene a continuación lleva información sobre una mesa:

<table><name>African Coffee Table</name><width>80</width><length>120</length>

</table>

Si estos dos documentos se unieran en uno solo, habría un conflicto en los

nombres de elementos, ya que cada uno contiene un elemento <table> diferente con

distinto contenido y definición.

Una forma de resolver el conflicto es usando un prefijo que se incluiría dentro de

cada etiqueta, precediendo al nombre:

Para el caso de la tabla utilizaríamos el prefijo h:

<h:table><h:tr><h:td>Apples</h:td><h:td>Bananas</h:td></h:tr>

</h:table>

Y para el caso de la mesa utilizaríamos el prefijo f:

<f:table><f:name>African Coffee Table</f:name><f:width>80</f:width><f:length>120</f:length>

</f:table>

Ahora no habrá conflictos de nombres porque los dos documentos usan un

nombre diferente para su elemento <table>.

Según la especificación, las etiquetas deben ser Namespaces identificados por un

URI (Uniform Resource Identifier). Este Identificador de Recursos Uniforme es un

método que combina URNs y URLs, y que sirve para identificar de forma universal



recursos de todo tipo existentes en la World Wide Web. Para asociar una etiqueta con

un URI se utiliza el atributo xmlns.

Para el caso de la tabla utilizaríamos el espacio de nombres:

http://www.w3.org/TR/html4/.

<h:table xmlns:h="http://www.w3.org/TR/html4/"><h:tr><h:td>Apples</h:td><h:td>Bananas</h:td></h:tr>

</h:table>

Para el caso de la mesa utilizaríamos el espacio de nombres:

http://www.w3schools.com/furniture.

<f:table xmlns:f="http://www.w3schools.com/furniture"><f:name>African Coffee Table</f:name><f:width>80</f:width><f:length>120</f:length>

</f:table>

Cuando se define un Namespace en la etiqueta inicial de un elemento, todos los

elementos hijo con el mismo prefijo se asocian al mismo espacio de nombres. Cabe

resaltar que la dirección usada para identificar al Namespace no va a ser usada por el

parser de XML para buscar información; su único propósito es establecer un nombre

único para el prefijo.

4.2.6 Analizadores XML

Los analizadores XML son un elemento clave en los servicios web, ya que se

encargan de interpretar los datos contenidos en el documento y hacerlos accesibles a la

aplicación. En dispositivos con baja capacidad de procesamiento son un factor decisivo,

ya que suelen tener un gran tamaño y consumen mucha memoria.

Existen tres tipos principales de analizadores XML, cada uno con sus ventajas e

inconvenientes:

• Analizador de modelo: Lee el documento XML completamente y crea en la

memoria una representación estructurada de los datos. Su gran ventaja es que el

análisis se realiza al principio y luego se pueden tratar los datos como una



estructura cualquiera. Su desventaja principal es el alto consumo de memoria. El

analizador DOM se basa en esta idea.

• Analizador push: Se define un conjunto de eventos que pueden aparecer en un

documento XML, como pueden ser el comienzo de una etiqueta o la presencia de

datos de texto, y al encontrar uno de estos eventos llama a un método que lo

procese adecuadamente. El analizador SAX, usado por JSR-172, es de este tipo.

• Analizador pull: El documento XML se va recorriendo poco a poco mediante un

método que pide el siguiente elemento. El analizador kXML, usado por kSOAP,

es de este tipo.

4.3 SOAP

El protocolo de acceso a objetos simples (Simple Object Access Protocol, SOAP)

en un estándar de W3C que define el formato de las peticiones para los servicios web.

Los mensajes SOAP son enviados entre los dos extremos de la comunicación en

los llamados sobres SOAP para hacer una petición o enviar una respuesta. Estos sobres

están formateados en XML y son muy fáciles de descodificar.

Actualmente un sin fin de empresas se han decantado por el desarrollo de

aplicaciones que puedan trabajar sobre Internet porque permite la distribución global de

la información. Las tecnologías más usadas para el desarrollo de estas aplicaciones han

sido hasta hace poco CORBA, COM y EJB. Cada una proporciona un marco de trabajo

basado en la activación de objetos remotos mediante la solicitud de ejecución de

servicios a un servidor de aplicaciones.

Estas tecnologías han demostrado ser muy efectivas para el establecimiento de

sitios Web, sin embargo presentan una serie de desventajas, como son la total

incompatibilidad e interoperabilidad entre ellas y la dependencia de la plataforma sobre

la que corren, así como del lenguaje de programación.

Esto ha llevado a la necesidad de considerar un nuevo modelo de computación

distribuida de objetos que no sea dependiente de plataformas, modelos de desarrollo ni

lenguajes de programación. Por todos estos motivos surge el concepto de SOAP

(Simple Object Access Protocol).



4.3.1 Concepto de SOAP

La ventaja que aporta SOAP es la de proporcionar un mecanismo simple y ligerode intercambio de información entre dos puntos mediante documentos XML. SOAP noes más que un sencillo protocolo capaz de expresar la información mediante un modelode empaquetado de datos modular y una serie de mecanismos de codificación de datos.Esto permite que SOAP sea utilizado en un amplio rango de servidores de aplicacionesque trabajen mediante el modelo de comunicación RPC (Remote Procedure Call).

La especificación SOAP consta de tres partes:

• El SOAP envelope, que define el marco de trabajo que determina qué se puedeintroducir en un mensaje, quién debería hacerlo y si esa operación es opcional uobligatoria.

• Las reglas de codificación SOAP que definen el mecanismo de serialización queserá usado para encapsular en los mensajes los distintos tipos de datos.

• La representación SOAP RPC que define un modo de funcionamiento a la horade realizar llamadas a procedimientos remotos y la obtención de sus resultados.

4.3.2 Objetivos de SOAP

A la hora de realizar el diseño de SOAP se han tenido en cuenta una serie deconsideraciones con el fin de cumplir una serie de objetivos claros, objetivos que ledarán el potencial que reside en SOAP y que le harán tan atractivo. Éstos son:

• 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 MarkupLanguage) para la codificación de los datos.

• Establecer un protocolo abierto y extensible, de modo que no existenrestricciones en cuanto a datos o medio de transporte (la especificación define lamanera en que los mensajes se intercambian por HTTP, pero no obliga a utilizareste protocolo).



• Independencia de plataforma hardware, lenguaje de programación eimplementación del servicio Web.

El logro de estos objetivos ha hecho de SOAP un protocolo extremadamente útil,ya que el protocolo de comunicación HTTP es el empleado para la conexión sobreInternet, por lo que se garantiza que cualquier cliente con un navegador estándar puedaconectarse con un servidor remoto. Además, los datos en la transmisión se empaquetano serializan con el lenguaje XML, que se ha convertido en algo imprescindible en elintercambio de datos ya que es capaz de salvar las incompatibilidades que existían en elresto de protocolos de representación de datos de la red.

Por otra parte, los servidores Web pueden procesar las peticiones de usuarioempleando tecnologías tales como Servlets, páginas ASP (Active Server Pages) opáginas JSP (Java Server Pages).

La especificación SOAP 1.1 indica que las aplicaciones deben ser independientesdel lenguaje de desarrollo, por lo que las aplicaciones cliente y servidor pueden estarescritas con HTML, DHTML, Java, Visual Basic o cualquier otra herramienta olenguaje disponibles.

4.3.3 Un ejemplo sencillo de mensajes SOAP

Supongamos un servicio web que permita comprobar si un código postal esválido y pertenece realmente al país especificado. Este servicio web sería muy útil paraasegurar la validez en un formulario de una página web. El código relativo a la peticiónSOAP sería:

<env:Envelope

xmlns:env="http://www.w3.org/2001/06/soap-envelope">

<env:Body>

<m:ValidatePostcode

env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"

xmlns:m="http://www.somesite.com/Postcode">

<Postcode>

WC1A8GH

</Postcode>

<Country>

UK

</Country>



</m:ValidatePostcode>

</env:Body>

</env:Envelope>

Esta petición tiene dos parámetros (postcode y country) contenidos en unelemento llamado ValidatePostcode, que sería el nombre del servicio web al queestamos haciendo la petición. El resto de los datos del sobre, como la versión de SOAPy la codificación del texto, ayuda al servicio web a procesar la petición.

La respuesta al mensaje anterior tendría el siguiente formato:

<env:Envelope

xmlns:env="http://www.w3.org/2001/06/soap-envelope" >

<env:Body>

<m:ValidatePostcodeResponse

env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"

xmlns:m="http://www.somesite.com/Postcode">

<Valid>

Yes

</Valid>

</m:ValidatePostcodeResponse>

</env:Body>

</env:Envelope>

El elemento ValidatePostcodeResponse contesta al elemento ValidatePostcode dela petición, conteniendo un único elemento, Valid, que indica si el código postalintroducido es válido o no.

4.3.4 Partes de un mensaje SOAP

Un mensaje SOAP no es más que un documento en formato XML que estáconstituido por tres partes bien definidas: el SOAP envelope, el SOAP header, decarácter opcional, y el SOAP body.



Figura 4.1: Partes de un mensaje SOAP

Cada uno de estos elementos se detalla a continuación:

• El envelope es el elemento más importante y de mayor jerarquía dentro deldocumento XML y representa al mensaje que lleva almacenado dichodocumento. Todo mensaje SOAP 1.1 debe tener un elemento envelope asociadoal espacio de nombres http://schemas.xmlsoap.org/soap/envelope/. Si unmensaje recibido por una aplicación SOAP contiene en este elemento un valordistinto al anterior la aplicación trataría dicho mensaje como erróneo.

• El header es un mecanismo genérico que se utiliza para añadir característicasadicionales al mensaje SOAP sin tener que modificar su estructura. El modo en laque se añadan cada uno de los campos dependerá exclusivamente del servicioimplementado, de forma que cliente y servidor deberán estar de acuerdo con lajerarquía con la que se hayan añadido los distintos campos. De esta forma serásencillo separar entre sí los distintos datos a transmitir dentro del mensaje.

Un ejemplo de uso del header, donde se indica un cierto parámetro útil para elservicio Web que le indica como debe procesar el mensaje, sería:

<?xml version="1.0"?>

<SOAP-Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">

SOAP-ENV:encodingStyle=

"http://schemas.xmlsoap.org/soap/encoding/"/>



<SOAP-ENV:Header>

<t:Transaction xmlns:t="some-URI"

SOAP-ENV:mustUnderstand="1">

5

</t:Transaction>

</SOAP-ENV:Header>

<SOAP-ENV:Body>

<getQuote

xmlns="http://namespaces.cafeconleche.org/xmljava/ch2/">

<symbol>

RHAT

</symbol>

</getQuote>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

• El body es un contenedor de información en el cual se almacenarán los datos quese quieran transmitir de lado a lado de la comunicación. Es aquí donde se aloja lacarga útil del mensaje, de forma que para una comunicación RPC el body

contendrá, entre otros, los datos referidos a la ubicación del servidor, nombre delmétodo a invocar y parámetros necesarios. Debe depender únicamente delelemento envelope, y se sitúa inmediantamente después del elemento header enel caso de que exista. Dentro de este campo, SOAP define un elemento de usoopcional denominado Fault utilizado en los mensajes de respuesta para indicar alcliente algún error ocurrido en el servidor. Un ejemplo de uso de este nuevoelemento sería el siguiente, en el que se ha detectado un error en la aplicaciónque corre sobre el servidor que provoca que no opere convenientemente, por loque se le indica al cliente:

<?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:Body>



<SOAP-ENV:Fault>

<faultcode>

SOAP-ENV:Server

</faultcode>

<faultstring>

Server Error

</faultstring>

<detail>

<e:myfaultdetails xmlns:e="Some-URI">

<message>

My application didn't work

</message>

<errorcode>

1001

</errorcode>

</e:myfaultdetails>

</detail>

</SOAP-ENV:Fault>

</SOAP-ENV:Body>


El atributo encodingStyle se utiliza para indicar las reglas de serializaciónutilizadas en el mensaje SOAP. No existe un formato de codificación por defecto, sinoque existen una serie de posibles formatos a utilizar. El valor de este atributo es una listaordenada de una o más URIs que identifican la regla o reglas de serialización quepueden ser utilizadas en el mensaje, en el orden en el que se han de aplicar. De entretodas las posibles, las más utilizadas son: http://schemas.xmlsoap.org/soap/encoding/ yhttp://my.host/encoding/ .



4.3.5 Enlaces SOAP (bindings)

Podría pensarse que SOAP consiste en un documento XML transmitido porHTTP. Lo cierto es que la norma no especifica nada respecto al medio de transporte delos mensajes. Dicho de otra manera, se pueden utilizar otros protocolos de transporte(SMTP, FTP) o cualquier otro mecanismo que se nos ocurra (ficheros de texto). En elcaso de elegir HTTP como transporte de SOAP, es necesario cumplir algunas reglasbásicas:

• Los mensajes se deben enviar mediante el mecanismo HTTP POST.

• El tipo de contenido debe ser text/xml.

• En la cabecera de HTTP aparecerá un nuevo encabezamiento llamadoSOAPAction, cuya misión es hacer saber el propósito del mensaje SOAP a losservidores que lo reciban, sin tener que acceder al cuerpo del mensaje paraobtener dicha información.

• Si el mensaje de respuesta contiene un fallo, el código del estado de la respuestaHTTP debe ser 500.

Como curiosidad cabe citar que, debido a la flexibilidad que otorga la norma encuanto al método de transmisión, hasta una paloma mensajera podría ser el mecanismode transporte de nuestros mensajes SOAP.

4.3.6 SOAP 1.2

En Junio de 2003 el W3C publicó la especificación SOAP 1.2. Esta nueva versiónestablece algunas modificaciones y aporta muchas novedades tanto en la sintaxis comoen la codificación con respecto a SOAP 1.1.

La librería que implementa el protocolo SOAP en este proyecto, kSOAP2, sebasa en la especificación SOAP 1.1, por ello vamos a nombrar solamente los cambiosmás significativos que aporta la versión 1.2:

• Sintaxis

� No se permite ningún elemento detrás de body.



� El atributo env:encodingStyle no debe aparecer en el envelope.

� En el elemento opcional Fault se ha sustituido client y server por Sender

y Receiver. Asimismo los nombres de elementos faultcode y faultstring

han sido renombrados por env:Code y env:Reason, respectivamente.

� Se define el nuevo elemento de cabecera env:NotUnderstood, utilizadocuando la información marcada con env:MustUnderstand no ha podidoser procesada.

� Los valores del atributo de la cabecera env:mustUnderstand toma losvalores lógicos true o false, en lugar de 1 o 0.

• Enlace SOAP HTTP

� La cabecera Content-type debe ser application/soap+xml en lugar detext/xml.

• Codificaciones

� La sintaxis para la serialización de los arrays ha sido modificada.

� Se han eliminado valores compuestos genéricos del SOAP Data Model.

4.4 WSDL

WSDL (Web Services Definition Language) es un lenguaje basado en XML queusamos para describir un servicio web. Al publicar nuestro servicio es recomendablepublicar conjuntamente un archivo WSDL que indique los métodos, dirección yestructura de éste. Cuando un cliente quiera consumir nuestro servicio bastará con queinterprete el contenido del archivo WSDL, de modo que no es necesario conocer losdetalles de la implementación, la plataforma o el sistema operativo sobre el que se estáejecutando.



4.4.1 Elementos de un documento WSDL

Un documento WSDL está compuesto por definiciones. Éstas definen un serviciocomo un conjunto de una o más redes de puntos extremos o puertos. Cada puerto estáasociado a un enlace específico que se encarga de definir la manera en que un conjuntoabstracto de operaciones y mensajes está enlazado a un puerto de acuerdo a unprotocolo específico. Un enlace asigna un protocolo específico a un tipo de puerto. Eltipo de puerto está compuesto por una o más operaciones, que representan un conjuntoabstracto de posibilidades que el servicio puede llevar a cabo. Cada operación estácompuesta por un conjunto de mensajes abstractos que representan los datoscomunicados durante una operación. Cada mensaje contiene una o más partes de datos,que se definen como tipos.

La siguiente figura muestra de forma esquematizada la estructura que sigue undocumento WSDL:

��

�

��

�

�

��

�

��

�

�

��

�

��

�

�

��

�

��

�

�

→

nPuerto

Puerto

nOperación

Operación

nMensaje

Mensaje

nTipo

Tipo

Tipo

Mensaje

Operación

EnlacePuerto

Servicio

_

...

2_

_

...

2_

_

...

2_

_

...

2_

1_

1_

1_

1_1_

Figura 4.2: Estructura esquematizada de un documento WSDL

Detallamos a continuación cada una de las partes:

• <definitions>: Dentro de este elemento se definirán los servicios asociados aldocumento. Generalmente cada documento WSDL describe un solo servicio, ysuele seguir la siguiente estructura:



<definitions>

<documentation>

Comentarios del servicio.....

</documentation>

<types>

Definición de tipos....

</types>

<message>

Definición de mensaje....

</message>

<portType>

Definición de operaciones....

</portType>

<binding>

Definición de invocación....

</binding>

<service>

Ubicación del servicio....

</service>

</definitions>

• <documentation>: Se utiliza para comentarios

• <types>: Define los tipos de datos contenidos en los mensajes. Ejemplo:

<types>

<complexType name="request">

<sequence>

<element name="String_1" type="string"/>

<element name="String_2" type="string"/>

</sequence>



</complexType>

</types>

Aquí se define un tipo complejo llamado request formado por dos cadenas decaracteres, String_1 y String_2.

• <message>: Un mensaje es un contenedor de tipos de datos. Es importante saberque estos mensajes son abstractos, de manera que no hay que confundirlos conlos mensajes físicos que se enviarán vía SOAP. Ejemplo:

<message name="Interface_request">

<part name="parameters" element="ns2:request"/>

</message>

Aquí se define el mensaje Interface_request, cuyo parámetro es un elemento deltipo request, anteriormente definido en <types>.

• <portType>: Define las operaciones que realiza el servicio y los mensajescorrespondientes. Ejemplo:

<portType name="Interface">

<operation name="request">

<input message="tns:Interface_request"/>

<output message="tns:Interface_requestResponse"/>

</operation>

</portType>

Aquí define la operación request dentro del puerto Interface cuyo mensaje deentrada es Interface_request y el de salida es Interface_requestResponse.

• <binding>: Se traduce como enlace. Define el formato y detalles del protocolopara cada operación. Ejemplo:

<binding name="InterfaceBinding" type="tns:Interface">

<soap:binding

transport="http://schemas.xmlsoap.org/soap/http"



style="document"/>

<operation name="request">

<soap:operation soapAction=""/>

<input>

<soap:body use="literal"/>

</input>

<output>

<soap:body use="literal"/>

</output>

</operation>

</binding>

Aquí se especifica que los mensajes van a seguir el estilo document/literal.

• <service>: Define la ubicación del servicio. Ejemplo:

<service name="Serverscript">

<port name="InterfacePort" binding="tns:InterfaceBinding">

<soap:address location="http://localhost:8080/server/">

</port>

</service>

Se indica que el servicio estará situado en la direcciónhttp://localhost:8080/server.

Cabe resaltar que los elementos de un documento WSDL siguen un orden tal queel primer elemento, types, se corresponde con el nivel más bajo de la estructurarepresentada anteriormente. De la misma forma el último elemento, service, secorresponde con el nivel más alto de la estructura jerárquica representada en la figuraanterior.

4.4.2 Estilo y uso de un documento WSDL

Un archivo WSDL puede tener un estilo de llamada a procedimiento remoto(RPC) o un estilo documento (document), que afectará al formato de los datos en dichoarchivo y en los mensajes SOAP que se intercambien. Será el atributo opcional style elque indicará el estilo del mensaje.



Un valor RPC indica que el mensaje utiliza una codificación de tipo RPC, cuyoobjetivo es representar una llamada de método y una lista de parámetros. Un valordocument indica que el mensaje tiene un estilo de tipo documento, esto es, el mensajerepresenta un solo documento. En el caso de no especificar ningún estilo, se asumedocument por defecto.

Un archivo WSDL con estilo RPC tendría la siguiente forma:

<message name="myMethodRequest">

<part name="x" type="xsd:int"/>

<part name="y" type="xsd:float"/>

</message>

<message name="empty"/>

<portType name="PT">

<operation name="myMethod">

<input message="myMethodRequest"/>

<output message="empty"/>

</operation>

</portType>

Define dos mensajes: El primero de petición, llamado myMethodRequest querecibe dos parámetros numéricos, uno entero y otro flotante. El segundo mensaje estávacío. Por último especifica la operación myMethod que recibe el mensajemyMethodRequest y devuelve el mensaje vacío empty. Este mismo ejemplo en estilodocumento sería así:

<types>

<schema>

<element name="xElement" type="xsd:int"/>

<element name="yElement" type="xsd:float"/>

</schema>

</types>


<part name="x" element="xElement"/>

<part name="y" element="yElement"/>



</message>

<message name="empty"/>





</operation>

</portType>

En este caso se crea un esquema con los elementos xElement e yElement de tiposentero y flotante respectivamente, y en el mensaje se especifican estos elementos enlugar de los tipos. RPC tiene la ventaja de ser más simple, pero el estilo documento esmás correcto, ya que el archivo WSDL podría validarse con un analizador XML yademás cumple con las especificaciones de WS-I, que promueve la interoperabilidad deservicios web.

Otro factor que afecta a los mensajes SOAP del servicio es el uso, que puede sercodificado (encoded) o literal. Un mensaje SOAP RPC/encoded tendría la siguienteforma:

<soap:envelope>

<soap:body>

<myMethod>

<x xsi:type="xsd:int">

5

</x>

<y xsi:type="xsd:float">

5.0

</y>

</myMethod>

</soap:body>

</soap:envelope>



Como se puede apreciar en el propio mensaje se identifica el tipo del parámetro.Esto hace al mensaje más legible, aunque en realidad no aporta información ya que elque recibe el mensaje ya sabe el tipo de los parámetros, por lo que es poco eficiente.Además no es compatible con WS-I.

Un mensaje RPC/literal sería así:

<soap:envelope>

<soap:body>

<myMethod>

<x>

5

</x>

<y>

5.0

</y>

</myMethod>

</soap:body>

</soap:envelope>

En este caso no se envía el tipo en el mensaje lo que mejora la eficiencia, ademáseste modo sí es compatible con WS-I. Sin embargo sigue sin poder validarse confacilidad.

Un mensaje document/literal tendría este aspecto:

<soap:envelope>

<soap:body>

<xElement>

5

</xElement>

<yElement>



5.0

</yElement>

</soap:body>

</soap:envelope>

Este modo sí es validado fácilmente, y es compatible con WS-I siempre que elelemento soap:body tenga un sólo hijo. Esto provoca el problema de que en ocasioneses imposible distinguir a qué método remoto está dirigido el mensaje.

Para evitar los problemas de cada tipo Microsoft creó el modo document/literal

wrapped, que no está definido en ningún sitio. Este modo complica mucho el archivoWSDL, que tendría el siguiente aspecto:

<types>

<schema>

<element name="myMethod">

<complexType>

<sequence>

<element name="x" type="xsd:int"/>

<element name="y" type="xsd:float"/>

</sequence>

</complexType>

</element>

<element name="myMethodResponse">

<complexType/>

</element>

</schema>

</types>


<part name="parameters" element="myMethod"/>

</message>

<message name="empty">

<part name="parameters" element="myMethodResponse"/>

</message>







</operation>

</portType>

En este caso los elementos que se definen en el esquema no son los parámetrospor separado, sino el conjunto de parámetros para cada mensaje. Ahora, el mensajeSOAP sí contendrá un elemento con el nombre de la operación

<soap:envelope>

<soap:body>

<myMethod>

<x>

5

</x>

<y>

5.0

</y>

</myMethod>

</soap:body>

</soap:envelope>

La diferencia entre document y wrapped podría verse de la siguiente forma: elmensaje document se mapearía en un método así:

public void method (myMethod m);

Es decir, myMethod se considera como un objeto que contiene dos elementos. Encambio, el mensaje wrapped sería:

public void myMethod (int x, int y);



4.4.3 Generación del documento WSDL

La mayoría de aplicaciones de desarrollo de servicios web cuentan con unaherramienta de generación automática del archivo WSDL, por ejemplo, Java2WSDL. Siejecutamos esta aplicación desde la línea de comandos basta pasar como parámetro laclase principal de nuestro servicio y obtenemos un documento WSDL perfectamenteviable. En otros casos es el propio servidor web XML el que crea automáticamente eldocumento WSDL a partir del servicio web desplegado.

4.4.4 Interpretación del documento WSDL

El esquema general de un servicio web se muestra en la siguiente figura:

Figura 4.3: Esquema de un servicio web

El cliente obtendría el documento WSDL, generalmente de la dirección delservicio o por medio del descubrimiento UDDI, y a partir de ahí se comunicaría con elservicio mediante mensajes SOAP. Sin embargo los dispositivos móviles no tienen lacapacidad suficiente como para interpretar el documento WSDL, por lo que el esquemade servicio web para móviles es ligeramente distinto. En el caso de kSOAP se debetener en cuenta el formato de la comunicación a nivel de código, ya que la peticiónSOAP se crea añadiendo los parámetros necesarios a un objeto SOAP y enviándololuego al servidor.

La aproximación kSOAP pierde mucha flexibilidad, ya que sería necesario retocarel código en caso de pequeños cambios en el servicio. El caso de JSR-172 es diferente ysigue el siguiente esquema:



Figura 4.4: Esquema de un servicio web JSR-172

En este caso antes de incorporar la aplicación al dispositivo móvil es necesarioobtener un stub a partir del documento WSDL. Una vez creado, el cliente puede llamaral servicio web a través del stub. Así el formato de la comunicación es totalmentetransparente, ya que basta con invocar un método del stub para que se realice la peticióny se reciba la respuesta.

4.5 UDDI

4.5.1 Concepto de UDDI

Ya tenemos desplegado nuestro Servicio Web y hemos determinado la forma deinvocarlo mediante su correspondiente archivo WSDL. Lógicamente, el siguiente pasoconsiste en definir cómo se dará a conocer el servicio para que los clientes interesadospuedan descubrirlo fácilmente y utilizarlo en sus aplicaciones. En la actualidad existe unmecanismo de descubrimiento que cumple estos requisitos: UDDI (UniversalDescription, Discovery and Integration), una iniciativa que permite hacer compatible eldescubrimiento de servicios Web con todo tipo de tecnologías y plataformas.

Tres empresas, IBM, Microsoft y Ariba empezaron con la iniciativa UDDI. Suobjetivo era definir criterios para permitir que las empresas se descubriesen las unas alas otras, que interactuasen y compartieran información en un registro global. Esteregistro, llamado UBR (UDDI Business Register), era distribuido por las empresas



IBM, Microsoft, y SAP. Desde Enero de 2006 ninguna de estas empresas publica ya elregistro global de UDDI, aunque han implementado la especificación en sus productos.

UDDI es un registro público diseñado para almacenar de forma estructuradainformación sobre empresas y los servicios que éstas ofrecen. A través de UDDI sepuede publicar y descubrir información de una empresa y de sus servicios. Se puedeutilizar sistemas taxonómicos para clasificar estos datos y poder encontrarlosposteriormente en función de la categorización. Por tanto, UDDI puede responder atodas estas preguntas:

• ¿Qué interfaces de servicios Web basadas en WSDL se han publicado yestablecido para un sector determinado?

• ¿Qué empresas han escrito una implementación basada en una de estasinterfaces?

• ¿Qué servicios Web, categorizados de algún modo, se ofrecen actualmente?

• ¿Qué servicios Web ofrece una empresa determinada?

• ¿Con quién se debe poner en contacto el usuario para utilizar los servicios Webde una empresa?

• ¿Cuáles son los detalles de implementación de un servicio Web concreto?

4.5.2 Datos almacenados en el registro

UDDI almacena en su registro tres tipos de datos publicados por las empresas. Sepuede hacer una analogía con las guías de teléfonos, ya que se ofrecen PáginasBlancas, Páginas Amarillas y Páginas Verdes.

• Las Páginas Blancas contienen información del tipo de nombre de la empresa,información para contactar y descripción de la compañía.

• Las Páginas Amarillas contienen información que clasifica a la empresa. Estainformación se basa en mecanismos de clasificación de criterios industrialescomo la NAICS (North American Industry Classification System) oclasificaciones geográficas.



• Las Páginas Verdes ofrecen información técnica sobre los servicios que ofrecela empresa.

4.5.3 Publicación en UDDI

La publicación en UDDI es un proceso relativamente sencillo. El primer pasoconsiste en determinar información básica sobre cómo definir la empresa y los serviciosen UDDI. El siguiente paso, una vez determinada esta información, consiste en llevar acabo el registro. Por último, se debe probar la entrada para asegurar que se registrócorrectamente y que aparece tal y como se esperaba en diferentes tipos de búsquedas yherramientas.

Partiendo del modelo de datos descrito anteriormente, la información necesariapara establecer una entrada de UDDI es la siguiente:

• Archivos WSDL que utilizan las implementaciones del servicio Web.

• Nombre de la empresa y una breve descripción de la misma en varios idiomas, sies necesario, así como los contactos principales para los servicios Web queofrece.

• Las categorías e identificaciones adecuadas para la empresa.

• Los servicios Web que la empresa ofrece a través de UDDI.

• Las categorías adecuadas para los servicios.

Una vez recopilada esta información, se debe proceder al registro del servicioweb. Actualmente cada compañía ofrece sus implementaciones de la especificaciónUDDI, de modo que cada una de ellas contará con un modo distinto de llevar a cabo elregistro.

4.5.4 Búsqueda en UDDI

Anteriormente la búsqueda en UDDI consistía en acudir a cualquiera de las websque los operadores UDDI ponían a disposición para la consulta de servicios web en elregistro global. Tras la decisión tomada por estos operadores de cesar el servicio de



registro global, la búsqueda en UDDI implica tener que conocer nodos en los que setenga la certeza que están publicando algún registro UDDI.

4.6 Servicios Web XML para dispositivos

móviles

El uso de SOAP para transferir datos en lugar de otras tecnologías tiene susventajas. En primer lugar SOAP define más de 40 tipos de datos estándar a transmitirmediante lenguaje XML. En segundo lugar permite distintos esquemas de comunicacióncomo pueden ser llamadas a procedimientos remotos (RPC), mensajes asíncronos,multicast, etc. En último lugar, y debido a que SOAP ha ganado tanta popularidad enlos servicios Web, otros muchos protocolos han enfocado sus esfuerzos a poderinteractuar con éste, como es el caso de WSDL o UDDI.

4.6.1 kSOAP

kSOAP es una API SOAP diseñada para ser utilizada con Java 2 Microedition.Está basado en kXML, un parser XML de tipo pull que funciona en todas lasplataformas Java, incluida J2ME. Debido a su reducido tamaño y consumo de memoria,se suele utilizar en Applets de Java en PDAs o en dispositivos móviles con soporteMIDP.

kSOAP implementa un subconjunto de la especificación SOAP 1.1. La razón parano incluir todas las características se debe a las reducidas capacidades de memoria conque cuentan los dispositivos J2ME.

4.6.1.1 SOAP parsers

Una vez que se tenga un mensaje SOAP se pueden extraer de él los distintos datosque tenga almacenados mediante un parser XML, pero será más cómodo hacerlomediante un parser SOAP ya que, con el primero habría que extraer la información enforma de texto para después pasarla a un objeto Java que la contenga, mientras que conel parser SOAP la extracción de datos es directa. En el caso concreto de este proyecto,el parser SOAP será kSOAP.

Un parser SOAP se construye sobre un parser genérico XML al cual se le añadeuna serie de mecanismos específicos con los cuales realizar el “mapeo” de datos. Dichoparser SOAP es capaz de comprender los tipos de datos de la información almacenada



en el mensaje XML y de forma automática convertir texto en objetos Java, lo cual esuna gran ventaja para el programador. Solo es necesario pasar los datos a un SOAP

writer y quedarse a la espera de la respuesta del SOAP parser.

Un ejemplo de todo esto puede verse en el siguiente mensaje SOAP en el que seha almacenado un String que contenga el típico ejemplo “Hola Mundo”.

<SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<SOAP-ENV:Body>

<message xsi:type="xsd:string">

Hola Mundo

</message>

</SOAP-ENV:Body>


Si a este mensaje SOAP le pasamos un parser SOAP podremos obtener fácilmenteel String almacenado. Supongamos que el mensaje anterior se encuentra en el String“mesg”:

ByteArrayInputStream bis =

new ByteArrayInputStream (mesg.getBytes ());

InputStreamReader reader = new InputStreamReader (bis);

XmlParser xp = new XmlParser (reader);

// Se realiza un mapeo directo entre objetos Java

// y elementos Soap

SoapEnvelope envelope =

new SoapEnvelope (new ClassMap (Soap.VER12));

envelope.parse (xp);

// Obtenemos el texto almacenado

String result = (String) envelope.getBody();



En un mensaje SOAP el atributo xsi:type especifica el tipo de dato de un elementodel mensaje, por ejemplo <midato xsi:type="xsd:int">123</midato> especifica unentero de valor 123, en cambio <midato xsi:type="xsd:string">123</midato>

especifica un string de valor “123”. Es decir, kSOAP es capaz de mapear de formadirecta ciertos tipos de datos Java, concretamente:

Tipo SOAP Tipo Java

xsd:int java.lang.Integer

xsd:long java.lang.Long

xsd:string java.lang.String

xsd:boolean java.lang.Boolean

Tabla 4.2: Tipos de datos Java mapeados por kSOAP

A la hora de obtener los distintos datos almacenados en un mensaje SOAP elSOAP parser lee elemento a elemento cado uno de los elementos XML que hay en elmensaje y que contienen un dato y realiza el mapeo a un objeto Java de acuerdo con lassiguientes reglas:

1. Si el elemento SOAP es uno de los elementos primitivos indicados en la tablaanterior el mapeo se hace directamente.

2. Si el elemento es un tipo primitivo pero no es uno de los de la tabla anterior, loconvierte a un objeto SoapPrimitive. De éste se puede obtener o bien informaciónmediante los métodos SoapPrimitive.getNamespace() y SoapPrimitive.getName()

o bien su valor mediante el método SoapPrimitive.toString().



3. Si el elemento SOAP es un tipo complejo con varios subcampos, se convierte aun objeto de tipo KvmSerializable, concretamente al objeto SoapObject quepertenece a la interfaz KvmSerializable, y de este SoapObject se obtiene lainformación con los métodos SoapObject.getNamespace() ySoapObject.getName().

4.6.1.2 Composición/Descomposición de un mensaje SOAP

Supongamos que queremos montar un mensaje XML mediante los métodos quefacilita kSOAP. Para ello utilizaremos una serie de métodos que montarán un mensajeque después almacenaremos en un String y que posteriormente transmitiremos por lared. Supongamos que el mensaje que queremos crear es el siguiente:

<SOAP-ENV:Envelope

xmlns:SOAP-ENC="http://www.w3.org/2001/12/soap-encoding"




<SOAP-ENV:Body

SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<StockOrderParameters

id="o0"

SOAP-ENC:root="1">

<Symbol

xsi:type="xsd:string">

XYZ

</Symbol>

<From

xsi:type="xsd:string">

Michael Yuan

</From>

<Shares

xsi:type="xsd:int">

1000

</Shares>



<Buy

xsi:type="xsd:boolean">

true

</Buy>

<LimitPrice

xsi:type="xsd:float">

123.45

</LimitPrice>

</StockOrderParameters>

</SOAP-ENV:Body>


Para montar todo este mensaje sencillamente tenemos que usar una serie demétodos Java proporcionados por la librería de kSOAP de forma que el código obtenidosería:

// Creamos el objetos SOAP que almacene el mensaje

SoapObject method = new SoapObject("", "StockOrderParameters");

//Añadímos cada uno de los parámetros

method.addProperty("Symbol", "XYZ");

method.addProperty("From", "Michael Yuan");

method.addProperty("Shares", new Integer (1000));

method.addProperty("Buy", new Boolean (true));

method.addProperty("LimitPrice", new SoapPrimitive

("http://www.w3.org/2001/XMLSchema", "float", "123.4"));

// Ensamblamos el mensaje pasándolo por un SoapEnvelope

// Después lo almacenamos en un String

ByteArrayOutputStream bos = new ByteArrayOutputStream ();

XmlWriter xw = new XmlWriter (new OutputStreamWriter (bos));

// En este caso el mapeo es directo

SoapEnvelope envelope = new SoapEnvelope (new ClassMap (Soap.VER12));



envelope.setBody (method);

envelope.write (xw);

xw.flush ();

bos.write ('\r');

bos.write ('\n');

byte [] requestData = bos.toByteArray ();

String requestSOAPmesg = String (requestData);

Supongamos ahora el caso contrario, queremos extraer de un mensaje SOAP, quenos ha llegado como respuesta a una petición anterior, una serie de parámetros. Si elmensaje SOAP es el siguiente:

<SOAP-ENV:Envelope




<SOAP-ENV:Body>

<result>

<OrderStatus>

<CustomerName xsi:type="xsd:string">

Michael Yuan

</CustomerName>

<Symbol xsi:type="xsd:string">

XYZ

</Symbol>

<Share xsi:type="xsd:int">

1000

</Share>

<Buy xsi:type="xsd:boolean">

true

</Buy>

<Price xsi:type="xsd:float">

123.45



</Price>

<ExecTime xsi:type="xsd:dateTime">

2002-07-18T23:20:50.52Z

</ExecTime>

</OrderStatus>

</result>

</SOAP-ENV:Body>


Para extraer de este mensaje todos los parámetros, suponiendo que todo elmensaje está en el String soapRespMesg, el código que habría que ejecutar es:

ByteArrayInputStream bis = new ByteArrayInputStream

(soapRespMesg.getBytes ());



// El mapeo en este caso es directo



// Obtenemos la estructura de datos.

SoapObject orderStatus = (SoapObject) envelope.getResult();

// Pasamos los datos a su correspondiente tipo Java

String customerName = (String) orderStatus.getProperty("CustomerName");

String symbol = (String) orderStatus.getProperty ("Symbol");

Integer share = (Integer) orderStatus.getProperty ("Share");

Boolean buy = (Boolean) orderStatus.getProperty ("Buy");

// Puesto que MIDP no tiene tipo "Float" no existe correspondencia

// entre el tipo objeto Java y "xsd:float" tipo SOAP. Por lo que

// este elemento es mapeado a un objeto "SoapPrimitive".



SoapPrimitive price = (SoapPrimitive) orderStatus.getProperty("Price");

SoapPrimitive execTime = (SoapPrimitive) orderStatus.getProperty("ExecTime");

4.6.1.3 Datos complejos en un mensaje SOAP

La importancia de SOAP reside en la facilidad que ofrece de poder representardatos de tipos con estructuras complejas, como pueden ser arrays, o incluso estructurasde datos que nosotros mismos definamos.

De esta forma, si queremos incluir en un mensaje SOAP un array con una serie deelementos, podemos hacerlo sin más problemas. Supongamos que un servicio Webrealiza una serie de operaciones que le hemos solicitado y nos devuelve el siguientemensaje SOAP en el que ha incluido un array:

<SOAP-ENV:Envelope


xmlns:SOAP-ENC="http://www.w3.org/2001/12/soap-encoding"


xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:n="http://www.javaworld.com/ksoap/test">

<SOAP-ENV:Body>

<result>

<OrderStatus xsi:type="n:orderStatus">

<CustomerName xsi:type="xsd:string">

Michael Yuan

</CustomerName>

<Transactions xsi:type="SOAP-ENC:Array"

SOAP-ENC:arrayType="n:transaction[2]">

<Transaction xsi:type="n:transaction">


ABC

</Symbol>




500

</Share>


true

</Buy>


43.21

</Price>

</Transaction>

<Transaction xsi:type="n:transaction">


XYZ

</Symbol>


1000

</Share>


true

</Buy>


123.45

</Price>

</Transaction>

</Transactions>

</OrderStatus>

</result>

</SOAP-ENV:Body>




Al recibirse este mensaje, kSOAP lee el array y lo introduce en un objeto de tipojava.util.Vector y mediante el método Vector.elementAt(i) extrae de dicho array elelemento i-ésimo de entre todos los elementos que lo componen. Dependiendo del tipodel arrayType este objeto será almacenado en un SoapObject, en un SoapPrimitive, enun tipo por defecto Java, etc. Si suponemos que todo este mensaje SOAP se encuentradentro del String arraySoapRespMesg, el código que realizaría la extracción del array

sería:

ByteArrayInputStream bis = new ByteArrayInputStream

(arraySoapRespMesg.getBytes ());





SoapObject orderStatus = (SoapObject) envelope.getResult();

String customerName = (String) orderStatus.getProperty("CustomerName");

Vector transactions = (Vector) orderStatus.getProperty("Transactions");

// Primer elemento del array

SoapObject transaction0 = (SoapObject) transactions.elementAt(0);

String symbol0 = (String) transaction0.getProperty ("Symbol");

Integer share0 = (Integer) transaction0.getProperty ("Share");

Boolean buy0 = (Boolean) transaction0.getProperty ("Buy");

SoapPrimitive price0 = (SoapPrimitive) transaction0.getProperty("Price");

// Segundo elemento del array

SoapObject transaction1 = (SoapObject) transactions.elementAt(1);

String symbol1 = (String) transaction1.getProperty ("Symbol");

Integer share1 = (Integer) transaction1.getProperty ("Share");

Boolean buy1 = (Boolean) transaction1.getProperty ("Buy");

SoapPrimitive price1 = (SoapPrimitive) transaction1.getProperty("Price");



4.6.1.4 Protocolo HTTP mediante SOAP

El gran potencial que tiene SOAP a la hora de serializar datos para transmitirlos através de una red se complementa con una funcionalidad extremadamente útil, que es eluso del protocolo HTTP de forma directa. Dicho de otra manera, no vamos a tener quecontrolar HTTP explícitamente sino que esta tarea se deja en manos del API queimplementa SOAP.

kSOAP cuenta con la clase HttpTransport que es la que aporta la funcionalidad deenvío y recepción de mensajes SOAP vía HTTP. La forma de conexión que ofrece esuna llamada a procedimiento remoto (RPC), tal que el método HttpTransport.call()

toma como entrada un objeto KvmSerializable, lo serializa introduciéndolo en unmensaje SOAP completo que él mismo monta, envía dicho mensaje al servicio Webcuya dirección se haya indicado y recibe el mensaje respuesta que venga de vuelta. Trasesto pasa el mensaje recibido por un parser SOAP, llama al métodoSoapEnvelope.getResult() para que le devuelva el objeto Java correspondiente y décomo resultado este objeto. Y todo esto de forma automática.

La forma de utilizar este método es muy sencilla, lo vemos con el siguienteejemplo:

// Resultado de la llamada al servicio Web

String result = null;

// Dato a transmitir al servicio Web

int dato = 100;

// Creamos el objeto SOAP para la llamada al servicio

SoapObject rpc = new SoapObject

("urn:nombre del método", "nombre del método");

// Introducimos el parámetro en el mensaje SOAP

rpc.addProperty ("dato", dato);

// Configuramos la llamada al servicio Web

HttpTransport ht = new HttpTransport("URL destino", nombre delmétodo);

// Llamamos al servicio Web y recibimos su respuesta



result = ht.call (rpc);

4.6.2 JSR-172

4.6.2.1 Introducción

Las APIs de servicios web (WSA) para J2ME se definen en la Java SpecificationRequest 172 (JSR-172). Son dos paquetes independientes y opcionales, uno dedicado ala invocación de servicios remotos y otro dedicado al análisis XML. Están centrados enla CDC y las CLDC 1.0 y CLDC 1.1. La importancia de esto estriba en que laespecificación JSR-172 proporciona servicios de invocación remota y análisis XML anivel de dispositivo, evitando así que los desarrolladores de software tengan queincorporar dichas funcionalidades en sus aplicaciones.

Los servicios web en la J2ME, definidos por la JSR-172, siguen las mismasespecificaciones, arquitectura y modelo de invocación que los servicios web estándar, esdecir:

• SOAP 1.1 (Simple Object Access Protocol), que define el transporte ycodificación de datos.

• XML 1.0, que define el lenguaje XML.

Hay una cantidad importante de especificaciones que cubren las distintastecnologías relacionadas con servicios web, y su número continúa creciendo. Por ello laOrganización para la Interoperabilidad de Servicios Web (WS-I) ha definido el WS-IBasic Profile 1.0, que establece las especificaciones mínimas y las reglas que todos losproveedores de servicios web básicos deben seguir. La especificación JSR-172 se hadesarrollado de acuerdo al WS-I Basic Profile, aunque no soporta la especificaciónUDDI.

4.6.2.2 Invocación remota

La WSA de JSR-172 afronta los servicios web desde el punto de vista del clientedel servicio: WSA proporciona la API de invocacion remota (JAX-RPC) y el entorno deejecución que permite a las aplicaciones J2ME consumir servicios en la web, pero nofuncionar como productores de servicios. Aparte de esta diferencia, el resto de laarquitectura sigue la estructura y organización estándar de los servicios web.



Esta arquitectura de alto nivel está estructurada en:

• Un cliente, el consumidor de los servicios web. Consta de una aplicación J2ME,como MIDP, un stub de JSR-172 con las clases necesarias y la ejecución de JSR-172.

• La red: Hace referencia a la red inalámbrica y a los protocolos de comunicación.JSR-172 no impone el uso de XML en el propio dispositivo; permite otrasimplementaciones (siempre que sean transparentes al cliente y al servidor) parausar codificaciones más eficientes, como el uso de protocolos binarios entre eldispositivo y la pasarela inalámbrica.

• El servidor: Productor de servicios web. Es un servidor web, típicamente detrásde un firewall o una pasarela Proxy, que puede tener acceso a recursos derespaldo.

Las aplicaciones J2ME invocan servicios remotos a través de los stubs y de laejecución de JSR-172, típicamente sobre HTTP y SOAP. Dichos stubs esconden toda lacomplejidad asociada a la invocación del servicio remoto, incluyendo cómo se van acodificar y decodificar los parámetros de la solicitud y la respuesta, y todo lorelacionado con la red de comunicaciones. La invocación de métodos sigue el modelosíncrono de petición-respuesta, como se ve en la figura:

Figura 4.5: Modelo de invocación de JSR-172

Para consumir un servicio web antes hay que crear stubs de invocación deservicio. Estos stubs realizan tareas como la codificación y descodificación de losvalores enviados y recibidos, y actúan de interfaz de la ejecución de JSR-172 parainvocar un punto de servicio remoto. Los stubs interactúan con la ejecución a través delInterfaz de Proveedor de Servicio (SPI), que abstrae los detalles de implementación ypermite portabilidad de stubs entre distintas implementaciones.



Los stubs son generados usando una herramienta que lee el documento WSDLrelacionado con el servicio web. Desde el punto de vista del dispositivo móvil, eldocumento WSDL que queremos consumir por lo general suele existir a priori, así quelo único que hay que hacer es generar los stubs JSR-172 WSA, usando una herramientacomo el generador de stubs incluído en J2ME Wireless Toolkit 2.1.

Figura 4.6: Generación del stub de JSR-172

Esto genera los ficheros Java del stub y las clases necesarias. También se ocupadel mapeado del tipo de datos de WSDL a Java, como se describirá con detalle másadelante.

Una vez se han generado los stubs y las clases necesarias, y la aplicación hayasido compilada e instalada en un dispositivo compatible con JSR-172, consumir losservicios web deseados es muy sencillo, y casi transparente. La invocación de métodosremotos se hace tan sencilla como la de métodos locales.

La API de invocación remota de métodos de JSR-172 está basada en unsubconjunto de JAX-RPC 1.1 (API Java para RPC basada en XML). También estádesarrollada según el WS-I Basic Profile. Soporta las siguientes características:

• SOAP 1.1

• Cualquier transporte que pueda entregar mensajes SOAP, como HTTP 1.1

• La representación literal de un mensaje SOAP que represente una petición orespuesta RPC

• Los siguientes tipos de datos y su correspondencia en Java:

� xsd:boolean a boolean o Boolean.



� xsd:byte a byte o Byte.

� xsd:short a short o Short.

� xsd:int a int o Integer.

� xsd:long a long o Long.

� xsd:float a float, o Float. Para plataformas basadas en CLDC 1.0, estetipo de datos se mapea a String.

� xsd:double a double, o Double. Para plataformas basadas en CLDC 1.0,este tipo de datos se mapea a String.

� xsd:string a String.

� xsd:base64Binary a byte[].

� xsd:hexBinary a byte[].

� xsd:complexType a Sequence de tipos primitivos.

� xsd:QName a javax.xml.namespace.QName.

� Vectores de tipos primitivos y complejos (estructuras que contengantipos primitivos y complejos) basados en el esquema de vector XML.

Las siguientes características no son soportadas:

• Mensajes SOAP con adjuntos.

• Manejadores (handlers) de mensaje SOAP.

• Representación codificada de mensajes SOAP.



• Puntos de servicio (productor de servicio web).

• Soporte de descubrimiento de servicios (UDDI).

La codificación en XML no es obligatoria en el dispositivo. Así se puede reducirel tráfico de la red permitiendo que las implementaciones usen más eficientemente lacodificación de los datos, como un protocolo binario entre el dispositivo y la pasarelainalámbrica, siempre que dicha codificación sea transparente tanto para el productor delservicio web como para el consumidor.

Una vez se hayan generado, compilado e instalado en el dispositivo el stub y losficheros relacionados, consumir servicios remotos es muy simple. Si no contamos lainicialización específica dede JAX-RPC e importar RemoteException, el código de unaaplicación que se desarrolle para consumir servicios web parece igual que el de unaaplicación que no lo use. Esta simplicidad es posible gracias a que los stubs, como yahemos mencionado, ocultan los detalles relacionados con la invocación remota.

4.6.2.3 Análisis XML

La API de JSR-172 para el análisis XML de J2ME se basa en un subconjunto dela API JAXP 1.2 de J2SE y la API simple para análisis XML (SAX) 2.0. El hecho deque sea un subconjunto se explica por la limitada memoria disponible en losdispositivos J2ME.

JAXP para J2ME proporciona las clases, interfaces y excepciones necesarias paraanalizar documentos XML. Debe ser compatible con XML 1.0, y puede validar (usandoDTD) o no; el analizador seguirá las reglas de validación indicadas en la especificaciónde XML 1.0. Esta validación es una operación que consume muchos recursos, por eso ladecisión de incluirla dependerá del fabricante del dispositivo y se basará en laslimitaciones de almacenamiento y procesado del dispositivo. Para saber si el analizadorestá validando se puede llamar al método SAXParser.isValidating().

Los analizadores de JAXP para J2ME deben soportar espacios de nombre deXML, tal y como se define en la recomendación W3C XML Namespaces 1.0,codificación UTF-8 y UTF-16, y DTDs. No están soportados, debido a las causas yacomentadas, el Modelo de Objetos de Documento (DOM) y el Lenguaje deTransformación basado en Plantillas de Estilo (XSLT).

El uso de JAXP consiste en tres fases:



• Definir el manejador específico para la aplicación, una subclase deDefaultHandler.

• Usar SAXParserFactory para crear una instancia del analizador SAX(SAXParser).

• Analizar el documento XML de entrada invocando el métodoSAXParser.parse().

El analizador SAX invoca las llamadas del manejador de eventosstartDocument(), endDocument(), startElement(), endElement(), y characters() alprocesar las distintas partes del documento XML.

Una vez se ha iniciado el análisis, SAXParser invoca las llamadas al manejador deeventos así:

• startDocument(): Se llama al principio del documento.

• startElement(): Se llama cuando se encuentra un nuevo elemento. Esta llamadatambién incluye los atributos del elemento, si hay alguno.

• characters(): Se llama cuando se encuentran caracteres de algún elemento.

• endElement(): Se llama cuando se cierra un elemento.

• endDocument(): Se llama al finalizar el análisis del documento.

4.7 Consideraciones finales

La aparición de los Servicios Web XML marcó un antes y un después en elámbito de las aplicaciones distribuidas. En este capítulo hemos podido comprobar quegran parte de este éxito se debe a la utilización de protocolos estándar basados en XMLpara invocar servicios y transmitir datos, como SOAP y WSDL.



Por ello se ha prestado una especial atención a XML, del que hemos detallado suestructura y reglas sintácticas, así como los dos métodos que existen para definir estetipo de documentos: DTD y Schema.

A continuación hemos descrito el protocolo SOAP, estándar del W3C pararealizar peticiones a los servicios web. El apartado dedicado a este protocolo nos haservido para conocer las partes de las que se compone y la función de cada una de ellas.Los ejemplos adjuntos de mensajes SOAP facilitan en gran medida la comprensión desu estructura.

Decimos que los Servicios Web XML son aplicaciones autodescriptivas que sepublican, se ubican y se invocan desde cualquier lugar de la web. Esa autodescripciónviene dada gracias a los documentos WSDL, también basados en XML, que ofrecentoda la información necesaria para utilizar un servicio web sin dar a conocer suimplementación, sistema operativo o lenguaje de programación.

La forma de dar a conocer un nuevo servicio web pasa por incluirlo en una listadel tipo “Páginas Amarillas”. Existe un registro especialmente diseñado para losservicios web denominado UDDI. En los apartados anteriores hemos explicado elfundamento de publicación y búsqueda de servicios web en este tipo de registros.

Por último se han contemplado dos tecnologías que permiten implementarServicios Web XML en dispositivos móviles: el paquete kSOAP y la especificaciónJSR-172. Hemos estudiado las características de cada uno de ellos y sus diferenciasprincipales. Al igual que con SOAP, los ejemplos utilizados permiten asimilarfácilmente muchos de los conceptos que se han tratado.

(Transmisi n de im genes de v deo mediante Servicios...

Documents

Transcript of (Transmisi n de im genes de v deo mediante Servicios...