![Cerrar [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Entender SOAP
Ahora que ya instaló el software, puede comenzar a ver el servicio web propiamente dicho. Ahora que ya instaló el software, puede comenzar a ver el servicio web propiamente dicho. Como mencioné en Other kinds of Web services (Otros tipos de servicios web), usted dispone de diversos formatos para elegir. En esta serie, usará SOAP.
Un breve comentario acerca de XML
Todos estos mensajes que van y vienen están basados en Extensible Markup Language (Lenguaje de marcado extensible) o XML. Si no está familiarizado con XML, investigue un poco al respecto antes de entrar en profundidad en los temas de los servicios web. Sin embargo, aquí aparecen los fundamentos que debe conocer antes de seguir adelante con este tutorial.
XML es un lenguaje de “marcado ampliable”, lo que significa que proporciona una forma de suministrar información adicional sobre el contenido. Esta información tiene la forma de “tags” (“etiquetas”), las que denotan “elements” (“elementos”). Por ejemplo, tome en cuenta este documento XML sencillo que aparece en el Listado 5:
Listado 5. Archivo XML que muestra los fundamentos
<article articleId="88271" categoryId="classifieds" subcategoryId="forsale"> <articleHeadline>Fun, fun, fun</articleHeadline> <articleText>Vintage 1963 T-Bird. Less than 300 miles. Driven by my daughter until I took it away. Serious inquires only. 555-3264 after 7 PM.</articleText> </article> |
Observe un par de cosas acerca de este texto. Ante todo, es texto. Eso lo hace legible por casi cualquiera, o por casi cualquier cosa. Segundo, las etiquetas están indicadas con > y <, con una etiqueta “open” (de apertura) que contiene un nombre, y atributos posibles, como la ID del artículo, y una etiqueta de cierre con una barra (/). Los elementos deben estar auto-contenidos y anidados correctamente. En otras palabras, usted no podría tener un documento XML similar al del Listado 6.
Listado 6. Muestra no válida de un documento XML
<article articleId="88271" categoryId="classifieds" subcategoryId="forsale"> <articleHeadline>Fun, fun, fun <articleText></articleHeadline>Vintage 1963 T-Bird. Less than 300 miles. Driven by my daughter until I took it away. Serious inquires only. 555-3264 after 7 PM.</articleText> </article> |
XML también proporciona una forma de separar el contenido en diferentes "espacios de nombres”, para que pueda ser tratado de otra manera por una aplicación. Por ejemplo, un mensaje SOAP puede parecerse al siguiente, del Listado 7.
Listado 7. Ejemplo de mensaje SOAP
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/SOAP-envelope">
<env:Header>
</env:Header>
<env:Body>
<cms:getNumberOfArticles xmlns:cms="http://www.daily-moon.com/cms">
<cms:category>classifieds</cms:category>
<cms:subcategory>forsale</cms:subcategory>
</cms:getNumberOfArticles>
</env:Body>
</env:Envelope>
|
No se preocupe por la estructura del mensaje, pero observe que hay dos “prefijos” distintos, cada uno de los cuales corresponde a un espacio de nombres en particular. En este caso, diferenciamos el “sobre” SOAP de la carga útil real.
Reitero, hay mucho para aprender acerca de XML, pero esos son los fundamentos que debe conocer para este tutorial.
La unidad básica de un mensaje de servicio web es el sobre SOAP. Se trata de un documento XML que incluye toda la información necesaria para procesar el mensaje (ver Listado 8).
Listado 8. Ejemplo de mensaje SOAP
<?xml version='1.0' ?> <env:Envelope
xmlns:env="http://www.w3.org/2003/05/SOAP-envelope">
<env:Header> </env:Header> <env:Body>
</env:Body> </env:Envelope> |
En este caso,
usted tiene un Envelope (Sobre) sencillo, con el
espacio de nombres especificado como SOAP versión 1.2. Incluye los dos
sub-elementos, un Header (Encabezado) y un Body (Cuerpo). Veamos qué hacen cada uno de estos
elementos.
El Header (Encabezado) de un mensaje
SOAP tiene la finalidad de proporcionar información acerca del mensaje en sí
mismo, contrariamente a la información destinada a la aplicación. Por ejemplo,
el Header (Encabezado) puede incluir información de
ruteo, tal como lo hace en este ejemplo que aparece en el Listado 9.
Listado 9. Información de ruteo en el
Header (Encabezado)
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/SOAP-envelope">
<env:Header>
<wsa:ReplyTo xmlns:wsa=
"http://schemas.xmlSOAP.org/ws/2004/08/addressing">
<wsa:Address>
http://schemas.xmlSOAP.org/ws/2004/08/addressing/role/anonymous
</wsa:Address>
</wsa:ReplyTo>
<wsa:From>
<wsa:Address>
http://localhost:8080/axis2/services/MyService</wsa:Address>
</wsa:From>
<wsa:MessageID>ECE5B3F187F29D28BC11433905662036</wsa:MessageID>
</env:Header>
<env:Body>
</env:Body>
</env:Envelope>
|
En
este caso usted ve un elemento de WS-Addressing, que incluye información acerca
del destino del mensaje y del destino de las respuestas. El Header (Encabezado) y puede incluir todo tipo de información sobre el
mensaje en sí mismo. En realidad, la especificación SOAP insume mucho tiempo en
elementos que pueden ir en el Header (Encabezado), y
cómo deben ser tratados por los "intermediarios SOAP”. En otras palabras, la
especificación SOAP no infiere de manera alguna que el mensaje irá directamente
de un punto a otro, desde el cliente al servidor. Permite la idea de que un
mensaje SOAP puede ser procesado en efecto por diversos intermediarios, en su
ruta al destino final, y la especificación es muy clara en cuanto a la forma en
que deberán tratar esos intermediarios la información del Header (Encabezado). No obstante, esa discusión está más allá del
alcance de este tutorial. Por lo que, por ahora, simplemente comprenda que
el Header (Encabezado) le puede proporcionar una
funcionalidad mucho mayor si la necesitara.
Ahora veamos la carga útil.
The SOAP body (El cuerpo SOAP)
Cuando usted envía un mensaje SOAP, lo hace con un motivo en mente.
Usted trata de decirle al destinatario que haga algo, o trata de impartir
información al servidor. Esta información se llama "carga útil". La carga útil
va en el Body del Envolope.
También tiene su propio espacio de nombres, en este caso el que corresponde al
sistema de gestión de contenidos. En este caso, la elección del espacio de
nombres, es completamente arbitraria. Sólo tiene que ser diferente del espacio
de nombres de SOAP (ver Listado 10).
Listado 10. Ejemplo de una carga útil
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/SOAP-envelope">
<env:Header>
...
</env:Header>
<env:Body>
<cms:addArticle xmlns:cms="http://www.daily-moon.com/cms">
<cms:category>classifieds</category>
<cms:subcategory>forsale</cms:subcategory>
<cms:articleHeadline></cms:articleHeadline>
<cms:articleText>Vintage 1963 T-Bird. Less than 300 miles.
Driven by my daughter until I took it away. Serious inquires only.
555-3264 after 7 PM.</cms:articleText>
</cms:addArticle>
</env:Body>
</env:Envelope>
|
En este caso, usted tiene una carga útil simple, que incluye instrucciones para agregar un artículo al sistema de gestión de contenidos para el Daily Moon.
La selección de la estructura de la carga útil incluye el estilo y la codificación.
Este tema lo verá con mayor profundidad en la parte dos, que habla del Web Services Description Language (Lenguaje de descripción de los servicios web, WSDL), pero cuando cree su aplicación, necesitará decidir la estructura de la carga útil que enviará una y otra vez. A tal fin, tomemos unos instantes para hablar de la programación del estilo y de la codificación.
Dicho de manera sencilla, predominan dos estilos de programación diferentes para los mensajes SOAP. El primero es el estilo RPC, que se basa en el concepto de usar mensajes SOAP para crear Remote Procedure Calls (Llamadas a procedimientos remotos). En este estilo, la idea es que usted enviará un comando al servidor, como por ejemplo “agregar un artículo”, e incorporará los parámetros para ese comando, como por ejemplo el artículo que se agregará y la categoría a la que deberá ser incorporado, como elementos secundarios del método en general, según el Listado 11. Listado 11.
Listado 11. Estilo RPC
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/SOAP-envelope">
<env:Header> |
La alternativa al estilo RPC implica que usted tenga solamente sus datos como contenido del cuerpo SOAP, e incluye la información relativa al procedimiento o función a la que ésta pertenece en el ruteo del mensaje por parte del servidor de aplicaciones (ver Listado 12).
Listado 12. Datos como contenido en el cuerpo SOAP
|
Una variante del estilo RPC es RPC/encoded (RPC/codificado), a diferencia de RPC/literal, como podemos ver arriba. En aquel caso, el mensaje incluye información de tipo, tal como aparece en el Listado 13.
Listado 13. Ejemplo de RPC/codificado
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/SOAP-envelope">
<env:Header>
</env:Header>
<env:Body>
<cms:addArticle xmlns:cms="http://www.daily-moon.com/cms">
<cms:category xsi:type="xsd:string">classifieds</category>
<cms:subcategory xsi:type="xsd:string">forsale
</cms:subcategory>
<cms:articleHeadline xsi:type="xsd:string" />
<cms:articleText xsi:type="xsd:string">Vintage 1963
T-Bird. Less than 300 miles. Driven by my daughter until
I took it away. Serious inquires only. 555-3264 after 7
PM.</cms:articleText>
</cms:addArticle>
</env:Body>
</env:Envelope>
|
Al segundo estilo se lo conoce como estilo document/literal, que implica únicamente la incorporación de los datos apropiados en el mensaje, como el que se muestra en el Listado14.
Listado 14. Ejemplo de estilo document/literal
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/SOAP-envelope">
<env:Header>
</env:Header>
<env:Body>
<category>classifieds</category>
<subcategory>forsale</subcategory>
<articleHeadline></articleHeadline>
<articleText>Vintage 1963 T-Bird. Less than 300 miles.
Driven by my daughter until I took it away. Serious
inquires only. 555-3264 after 7 PM.</articleText>
</env:Body>
</env:Envelope>
|
En este caso, el mensaje propiamente dicho no incluye información acerca del proceso del destino a donde deberán ser enviados los datos; eso lo maneja el software de ruteo. Por ejemplo, todos los llamados a una URL o punto final en particular deben apuntar a una operación en particular. Usted también podría usar el estilo documento/codificado técnicamente, pero nadie lo hace, así que, por el momento, olvídelo.
Cada uno de estos estilos implica concesiones mutuas y, reitero, la parte dos de esta serie los abarca con más detalle. Sin embargo, es importante saber que hay un tercer estilo, "document wrapped," que no está especificado formalmente en ninguna parte, pero que se ha hecho popular por diversos motivos de interoperabilidad. En este caso, el contenido de la carga útil está ajustado en un único documento, pero ese elemento no puede llevar el mismo nombre de la aplicación o procedimiento al que pertenecen los datos. Para el ojo humano, estos mensajes son virtualmente idénticos a los mensajes RPC/literales.
Patrones de intercambio de mensajes
Cuando se trata del envío de mensajes, usted cuenta con una amplia variedad de opciones, que van desde el envío de una solicitud y la espera de una respuesta, al envío de una solicitud y olvidarse de ella, hasta el envío de una solicitud y hacerla pasar a través de intermediarios múltiples antes de que llegue a su destino final No obstante, al final, sólo tiene dos opciones:
- Solicitud/Respuesta: Según el patrón Solicitud/Respuesta, usted envía una solicitud con forma de mensaje SOAP y simplemente espera la llegada de una respuesta. La solicitud puede ser sincrónica o asincrónica.
- Mensajería unidireccional: Este caso, también conocido como método “dispare y olvídese”, implica el envío de la solicitud para después olvidarse directamente de ella. Esto lo puede usar en situaciones en las que simplemente imparte información, o en alguna otra en la que, en realidad, no le importa lo que el destinatario pueda decir de ella.
Ahora, observe la falta de los términos “cliente” y “servidor”. Esto se explica porque estos patrones de intercambio de mensajes pueden usarse básicamente para crear cualquier cantidad de alternativas diferentes, tal cual las mencionadas un poco más arriba. Por ejemplo, usted puede crear una situación en la cual envía una solicitud, y cuenta con que el destinatario se ocupará de ella, enviando un mensaje en algún momento futuro cuando esté listo lo que se supone que debe hacer. Para hacerlo, usted usará una combinación de mensajes unidireccionales, por lo que no tiene sentido hablar del "cliente" y del "servidor", porque cada mensaje tiene un remitente y un destinatario, y los así llamados cliente y servidor, cambian de lugar.
