Nota de Traducción

Traducción al español: José Manuel Alonso, Oficina Española del W3C.

Este documento es una traducción al español de la recomendación del W3C, incluyendo las correcciones aparecidas en la errata del mismo y puede encontrarse en http://www.w3c.es/Traducciones/es/TR/2003/REC-soap12-part0-20030624/. El documento original del W3C es la única referencia oficial y normativa válida. Este documento fue finalizado el 28 de Enero de 2004.

Este documento puede contener errores de traducción, los cuales deben ser comunicados a José Manuel Alonso. En ocasiones aparecen aclaraciones entre corchetes y con el color de fondo de esta nota de traducción, por ejemplo, [aclaración], al lado del vocablo o expresión original del Inglés en su primera aparición. También se han omitido de forma voluntaria algunas tildes especialmente en la traducción de elementos del código con el fin de aumentar la legibilidad.

Lo que sigue es la traducción del documento original.

SOAP Versión 1.2 Parte 0: Fundamentos

Recomendación del W3C, 24 de Junio de 2003

Esta versión:: http://www.w3.org/TR/2003/REC-soap12-part0-20030624/
Última versión:: http://www.w3.org/TR/soap12-part0/
Versión anterior:: http://www.w3.org/TR/2003/PR-soap12-part0-20030507/
Editor:: Nilo Mitra (Ericsson)

Por favor, consulte las erratas de este documento, las cuales pueden incluir algunas correcciones normativas.

La versión en Inglés de esta especificación es la única versión normativa. También pueden estar disponibles traducciones no normativas.

Estado de este Documento

Esta sección describe el estado de este documento en el momento de su publicación. Otros documentos pueden reemplazar a este documento. El último estado de esta serie de documentos se mantiene en el W3C.

Este documento es una Recomendación del W3C. Este documento ha sido producido por el Grupo de Trabajo sobre Protocolo XML, que es parte de la Actividad de Servicios Web. Ha sido revisado por miembros del W3C y otras partes interesadas, y ha sido aprobado por el Director como una Recomendación del W3C. Es un documento estable y puede ser utilizado como material de referencia o citado como una referencia normativa en otro documento. El papel del W3C al crear una Recomendación es atraer la atención sobre la especificación y promover su amplio desarrollo. Esto aumenta la funcionalidad e interoperabilidad de la Web.

Son bienvenidos los comentarios sobre este documento. Por favor, envíense a la lista de correo de acceso público xmlp-comments@w3.org (archivo). No se considera apropiado el envío de mensajes de discusión a esa dirección de correo electrónico.

La información sobre las implementaciones relevantes para esta especificación puede encontrarse en el Informe de Implementación en: http://www.w3.org/2000/xp/Group/2/03/soap1.2implementation.html.

Las discusiones sobre Patentes relevantes para esta especificación pueden encontrarse en la página sobre discusiones de patente del Grupo de Trabajo, de acuerdo a la política del W3C.

Se puede encontrar una lista de las Recomendaciones actuales del W3C y otros informes técnicos en http://www.w3.org/TR.

Tabla de Contenidos

1. Introducción

SOAP Versión 1.2 Parte 0: Fundamentos es un documento no normativo que pretende proporcionar un tutorial fácilmente entendible sobre las características de SOAP Versión 1.2. Su propósito es ayudar a personas técnicamente competentes a entender cómo se puede utilizar SOAP, describiendo estructuras de mensajes y patrones de intercambio de mensaje SOAP representativos.

Se espera que el lector tenga algo de familiaridad con la sintaxis básica de XML, incluyendo el uso de espacios de nombres y Conjuntos de Información XML, y conceptos Web tales como los URIs y HTTP. Está destinado principalmente a usuarios de SOAP, tales como diseñadores de aplicaciones, más que a implementadores de las especificaciones SOAP, aunque estos últimos podrían encontrarle ciertos beneficios. Este documento de fundamentos tiene como objetivo resaltar las características esenciales de SOAP Versión 1.2, y no el describir por completo cada matiz y caso extremo. Por tanto, no existe sustituto alguno de las especificaciones principales para conseguir un conocimiento completo de SOAP. A este respecto, estos fundamentos proporcionan enlaces importantes a las especificaciones principales en aquellos lugares en los que se introducen o utilizan conceptos nuevos.

[SOAP Parte 1] define el sobre SOAP, que es una construcción que define una infraestructura para la representación de un mensaje SOAP, identificando quién debe ocuparse de todo o parte de él, y en qué casos el manejo de tales partes es opcional u obligatorio. También define una infraestructura para los enlaces entre protocolos, que describe cómo puede especificarse el vínculo de SOAP con otro protocolo.

[SOAP Parte 2] define un modelo de datos para SOAP, un esquema de codificación particular para tipos de datos que puede ser utilizado para comunicar llamadas a procedimientos remotos (RPC), así como una realización concreta de la infraestructura fundamental para los enlaces entre protocolos, definido en [SOAP Parte1]. Este enlace permite el intercambio de mensajes SOAP ya sean como carga útil de una petición y respuesta HTTP POST, o como un mensaje SOAP en respuesta a un HTTP GET.

Este documento (el de fundamentos) no es normativo, lo que significa que no proporciona la especificación definitiva de SOAP Versión 1.2. Los ejemplos aquí ofrecidos tienen como objetivo complementar las especificaciones formales y, en cualquier cuestión, la interpretación de las especificaciones formales tiene, naturalmente, preferencia. Los ejemplos mostrados aquí proporcionan un subconjunto de los usos que se esperan de SOAP. En escenarios de usos reales, SOAP será, seguramente, parte de una solución global, y no existirá duda sobre otros requisitos específicos de las aplicaciones que no han sido formulados en estos ejemplos.

1.1 Visión General

SOAP Versión 1.2 proporciona la definición de información basada en XML que puede ser utilizada para el intercambio de información estructurada y de tipos concretos entre puntos en un entorno descentralizado, distribuido. [SOAP Parte 1] explica está especificado formalmente por un [XML Infoset][Conjunto de Información XML], que proporciona una descripción abstracta de sus contenidos. Los Conjuntos de Información pueden tener diferentes representaciones a la hora de ser transmitidos, un ejemplo común el de un documento XML 1.0 [XML 1.0].

SOAP es fundamentalmente un paradigma de intercambio de mensajes en un sólo sentido, sin estado, pero las aplicaciones pueden crear patrones de interacción más complejos (por ejemplo, petición/respuesta, petición/respuestas múltiples, etc.) combinando tales intercambios de un solo sentido con características proporcionadas por el protocolo utilizado y/o información específica de la aplicación en cuestión. SOAP no interfiere en la semántica de cualesquiera datos específicos de aplicación que comunica, ni tampoco en asuntos tales como en enrutamiento de mensajes SOAP, transferencia de datos fiables, cortafuegos que atraviesa, etc. No obstante, SOAP proporciona el marco de trabajo por el que la información de aplicaciones específicas puede comunicarse de forma extensible. También, SOAP proporciona una descripción completa de las acciones que debe realizar un nodo SOAP al recibir un mensaje SOAP.

La Sección 2 de este documento proporciona una introducción a las características básicas de SOAP comenzando por los casos de uso más sencillos, concretamente por un mensaje SOAP de un solo sentido, seguidos de varios tipos de intercambio petición/respuesta, incluyendo RPCs. También se describen las situaciones de Error.

La Sección 3 proporciona una visión general del modelo de procesamiento de SOAP, en el que se describen las reglas para la construcción inicial de un mensaje, reglas por las que los mensajes son procesados cuando son recibidos en una estación intermedia o final y reglas por las que se pueden insertar, eliminar o modificar porciones del mensaje mediante las acciones de un intermediario.

La Sección 4 de este documento describe los modos en los que los mensajes SOAP pueden ser transportados para comprender varios escenarios de uso. Describe el enlace SOAP HTTP especificado en [SOAP Part2], así como un ejemplo de cómo los mensajes SOAP pueden ser comunicados mediante mensajes de correo electrónico. Como parte del enlace HTTP, presenta dos patrones para el intercambio de mensajes que están disponibles para las aplicaciones, uno de los cuales utiliza el método HTTP POST, mientras que el otro utiliza HTTP GET. También se proporcionan ejemplos acerca de cómo los RPCs, en particular aquellos que representan la recuperación de información "segura", pueden ser representados en intercambios de mensajes SOAP, de una forma que es compatible con los principios arquitectónicos de la World Wide Web.

La Sección 5 de este documento proporciona un tratamiento de varios aspectos de SOAP que pueden ser utilizados en escenarios de uso más complejos. Éstos incluyen el mecanismo de extensibilidad ofrecido a través del uso de elementos de cabecera, que pueden ser orientados hacia nodos intermediarios SOAP específicos para facilitar servicios de valor añadido en la comunicación de aplicaciones, y la utilización de varios esquemas de codificación para serializar los datos de aplicaciones específicas en mensajes SOAP.

Para facilitar las referencias, los términos y conceptos utilizados en estos fundamentos están hiperenlazados a su definición en las especificaciones principales.

1.2 Convenciones en la Notación

A lo largo de este documento de fundamentos, se muestran sobres y mensajes SOAP de ejemplo como documentos [XML 1.0]. [SOAP Parte 1] explica que un mensaje SOAP está especificado formalmente por un [XML InfoSet], que es una descripción abstracta de sus contenidos. No es probable que la distinción entre conjuntos de información SOAP XML y los documentos sea de interés para aquellos que utilicen este documento como una introducción a SOAP; para quienes les preocupe (típicamente a aquellos que porten SOAP a enlaces con nuevos protocolos en los que los mensajes puedan tener representaciones alternativas) deberían entender estos ejemplos como referidos a los correspondientes conjuntos de información XML. Este punto está más desarrollado en la Sección 4 de este documento.

Los prefijos de espacios de nombres "xs" y "xsi" utilizados en las secciones textuales de este documento, están asociados con los espacios de nombres "http://www.w3.org/2001/XMLSchema" y "http://www.w3.org/2001/XMLSchema-instance" respectivamente, los cuales están definidos en las especificaciones del Esquema XML [Esquema XML Parte 1], [Esquema XML Parte 2].

Nótese que la elección del prefijo de cualquier otro espacio de nombres es arbitraria y no es significativa semánticamente.

Los URIs de los espacios de nombres de la forma general "http://example.org/..." y "http://example.com/..." representan un URI con dependencia de aplicación o de contexto [RFC 2396].

2. Escenarios de Uso Básico

Un mensaje SOAP es fundamentalmente una transmisión en un solo sentido entre nodos SOAP, de un remitente SOAP a un destinatario SOAP, pero se espera que los mensajes SOAP sean combinados por las aplicaciones para implementar patrones de interacción más complejos desde la petición/respuesta a múltiples intercambios "conversacionales" de ida y vuelta.

Estos fundamentos comienzan con la exposición de la estructura de un mensaje SOAP y su intercambio en algunos escenarios de uso sencillos sobre la base de una aplicación de reservas de viajes. Se utilizarán varios aspectos del escenario de esta aplicación a lo largo del presente documento. En este escenario, la aplicación de reservas de viajes negocia la solicitud de reserva de un viaje planeado para un empleado de una empresa, con un servicio de reservas. La información intercambiada entre la aplicación de reservas de viajes y la aplicación del servicio de viajes se realiza en forma de mensajes SOAP.

El destinatario último de un mensaje SOAP enviado desde la aplicación de reservas de viajes es la aplicación del servicio de reservas, pero es posible que el mensaje SOAP pueda ser "encaminado" a través de uno ó más intermediarios SOAP que actúen de algún modo sobre el mensaje. Algunos ejemplos sencillos de tales intermediarios SOAP podrían ser aquellos que apuntan, auditan ó, posiblemente, enmiendan cada petición de viaje. Una discusión más detallada del comportamiento y papel de los intermediarios SOAP, así como ejemplos de los mismos, quedan pospuestos hasta la sección 5.1.

La Sección 2.1 describe una petición de reserva de viaje expresada como un mensaje SOAP, lo que ofrece la posibilidad de describir las diferentes partes de un mensaje SOAP.

La Sección 2.2.1 sigue en el mismo escenario para mostrar una respuesta desde el servicio de viajes en forma de otro mensaje SOAP, lo que forma parte de un intercambio conversacional de mensajes a medida que son negociadas las diferentes opciones presentadas que cumplen las restricciones de la petición de viaje.

La Sección 2.2.2 asume que los diferentes parámetros de la reserva de viaje han sido aceptados por el viajero, y un intercambio - modelado como una llamada a procedimiento remoto (RPC) - entre las aplicaciones de reserva de viajes y la de servicio de viajes, confirma el pago de la reserva.

2.1 Mensajes SOAP

El Ejemplo 1 muestra los datos de una reserva de viaje expresados en un mensaje SOAP.

Ejemplo 1

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 
 <env:Header>
  <m:reserva xmlns:m="http://empresaviajes.example.org/reserva" 
          env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
           env:mustUnderstand="true">
   <m:referencia>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:referencia>
   <m:fechaYHora>2001-11-29T13:20:00.000-05:00</m:fechaYHora>
  </m:reserva>
  <n:pasajero xmlns:n="http://miempresa.example.com/empleados"
          env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
           env:mustUnderstand="true">
   <n:nombre>Åke Jógvan Øyvind</n:nombre>
  </n:pasajero>
 </env:Header>
 <env:Body>
  <p:itinerario
    xmlns:p="http://empresaviajes.example.org/reserva/viaje">
   <p:ida>
     <p:salida>Nueva York</p:salida>
     <p:llegada>Los Angeles</p:llegada>
     <p:fechaSalida>2001-12-14</p:fechaLlegada>
     <p:horaSalida>última hora de la tarde</p:horaSalida>
     <p:preferenciaAsiento>pasillo</p:preferenciaAsiento>
   </p:ida>
   <p:vuelta>
     <p:salida>Los Angeles</p:salida>
     <p:llegada>Nueva York</p:llegada>
     <p:fechaSalida>2001-12-20</p:fechaSalida>
     <p:horaSalida>media-mañana</p:horaSalida>
     <p:preferenciaAsiento/>
   </p:vuelta>
  </p:itinerario>
  <q:alojamiento
   xmlns:q="http://empresaviajes.example.org/reserva/hoteles">
   <q:preferencia>ninguna</q:preferencia>
  </q:alojamiento>
 </env:Body>
</env:Envelope>

Ejemplo de mensaje SOAP para una reserva de viajes, con bloques de encabezado y cuerpo

El mensaje SOAP del Ejemplo 1 contiene dos subelementos específicos de SOAP dentro del elemento global env:Envelope

 
  [env:Sobre]

, denominados

env:Header 
  [env:Encabezado]

env:Body 
  [env:Cuerpo]

. Los contenidos de estos elementos son definidos por la aplicación y no son parte de las especificaciones SOAP, aunque el último de ellos tiene algo que decir acerca de cómo deben ser utilizados tales elementos.

El elemento SOAP header [encabezado SOAP] es opcional, pero ha sido incluido en el ejemplo para explicar ciertas características de SOAP. Un encabezado SOAP es un mecanismo de extensión que proporciona un modo de pasar información en mensajes SOAP que no es parte de la generada por la aplicación. Tal información de "control" incluye, por ejemplo, el paso de directivas o de información contextual relativa al proceso del mensaje. Esto permite extender el mensaje SOAP de una manera específica a cada aplicación. Los elementos hijos inmediatos del elemento env:Header son denominados bloques de encabezado, y representan un agrupamiento lógico de datos que, como se verá posteriormente, puede ser dirigido individualmente a nodos SOAP que podrían encontrarse en el camino de un mensaje desde un remitente hasta un destinatario final.

Los encabezados SOAP han sido diseñados en anticipación a varios usos de SOAP, muchos de los cuales implicarán la participación de otros nodos de proceso SOAP - llamados intermediarios SOAP - a lo largo del camino del mensaje desde el remitente SOAP inicial hasta el destinatario SOAP final. Esto permite a los intermediarios SOAP proporcionar servicios de valor añadido. Los encabezados, como se verá posteriormente, pueden ser inspeccionados, insertados, eliminados, o redirigidos por nodos SOAP encontrados a lo largo del camino de un mensaje SOAP. (Debe tenerse en cuenta, de todas formas, que las especificaciones SOAP no tratan con lo que son los contenidos de los elementos del encabezado en sí, o con la forma en la que los mensajes SOAP con enrutados entre los nodos, o con el modo en el que se determina la ruta y así sucesivamente. Éstos son parte de la aplicación global, y podrían ser objeto de otras especificaciones.)

El SOAP body [cuerpo SOAP] es el elemento obligatorio dentro del elemento SOAP env:Envelope, lo que implica que es aquí donde debe alojarse la información convenida en SOAP que se transporta de extremo a extremo.

En el Ejemplo 1, el encabezado contiene dos bloques de encabezado, cada uno de ellos se define en su propio espacio de nombres XML y representa algún aspecto perteneciente al proceso global del cuerpo del mensaje SOAP. Para esta aplicación de reservas, esa "meta" información perteneciente a la petición global son los bloques de encabezado reserva, que proporciona una referencia y una marca de tiempo para esta instancia de una reserva, y la identidad del viajero en el bloque pasajero.

Los bloques de encabezado reserva y pasajero deben ser procesados por el siguiente intermediario SOAP que se encuentre en el camino del mensaje o, si no existe tal intermediario, por el destinatario último del mensaje. El hecho de que es dirigido al siguiente nodo SOAP que se encuentre en ruta es indicado por la presencia del atributo

env:role 
  [env:papel]

con el valor "http://www.w3.org/2003/05/soap-envelope/role/next" (de ahora en adelante simplemente "next" ["siguiente"]), que es un role que todos los nodos SOAP deben estar dispuestos a jugar. La presencia de un atributo env:mustUnderstand [env:debeEntender] con el valor "true" ["cierto"] indica que el/los nodo(s) que procesan el encabezado deben procesar absolutamente esos bloques de encabezado de una forma consistente con sus especificaciones, o si no, no procesar el mensaje de ningún modo y lanzar un error. Nótese que cuando un bloque de encabezado es procesado es porque, o bien ha sido marcado con env:mustUnderstand="true" o por otra razón, el bloque debe ser procesado de acuerdo con las especificaciones para ese bloque. Tales especificaciones de los bloques de encabezado son definidas por la aplicación y no forman parte de SOAP. La Sección 3 detallará más el proceso de mensajes SOAP basados en los valores de esos atributos.

La elección de los datos que serán emplazados en un bloque de encabezado y los que van en el cuerpo SOAP son decisiones que se toman en el momento del diseño de la aplicación. El punto principal que hay que tener en cuenta es que los bloques de encabezado pueden ser dirigidos a varios nodos que podrían encontrarse a lo largo del camino de un mensaje que vaya desde un remitente a un destinatario final. Tales nodos intermediarios SOAP pueden proporcionar servicios de valor añadido basados en los datos de dichos encabezados. En el Ejemplo 1, los datos del pasajero se ubican en un bloque de encabezado para ilustrar el uso de estos datos en un intermediario SOAP que realice procesamiento adicional. Por ejemplo, como se verá más adelante en la sección 5.1, el mensaje saliente es alterado por el intermediario SOAP añadiendo otro bloque de encabezado al mensaje en el que especifica las preferencias de viaje de este pasajero.

El elemento env:Body y sus elementos hijos asociados, itinerario y alojamiento, están destinados al intercambio de información entre el remitente SOAP inicial y el nodo SOAP que asume el papel del destinatario SOAP final en el camino del mensaje, que es la aplicación del servicio de viajes. Por tanto, el env:Body y sus contenidos son dirigidos implícitamente y esperan ser entendidos por el destinatario último. Los medios por los que un nodo SOAP asume tal papel no están definidos por la especificación SOAP, y es determinado como parte de la semántica y el flujo de mensajes de la aplicación global.

Observe que un intermediario SOAP puede decidir realizar jugar el papel del destinatario SOAP final para una determinada transferencia de mensaje, y entonces procesar el env:Body. Sin embargo, aunque este tipo de comportamiento no puede prevenirse, no es algo que debiera hacerse a la ligera ya que puede distorsionar las intenciones del remitente del mensaje, y tener efectos laterales no deseados (como no procesar los bloques de encabezado que podrían estar dirigidos a intermediarios más allá del camino del mensaje).

Un mensaje SOAP como el del Ejemplo 1 puede ser transferido por diferentes protocolos y utilizado en una variedad de patrones de intercambio de mensajes. Por ejemplo, para un acceso a través de la Web a la aplicación del servicio de viajes, podría ser ubicado en el cuerpo de una petición HTTP POST. En otro enlace de protocolo, podría ser enviado en un mensaje de correo electrónico (véasesección 4.2). La Sección 4 describirá cómo los mensajes SOAP pueden ser transportados por una variedad de protocolos. Por ahora, se asume que existe un mecanismo para la transferencia de mensajes y el resto de esta sección se concentra en los detalles de los mensajes SOAP y en su procesamiento.

2.2 Intercambio de Mensajes SOAP

SOAP Versión 1.2 es una infraestructura de mensajería sencilla para la transferencia de información especificada en la forma de un conjunto de Información XML entre un remitente SOAP inicial y un destinatario SOAP final. Los escenarios más interesantes implican habitualmente el intercambio de múltiples mensajes entre estos dos nodos. El intercambio más simple de esta forma es el de un patrón petición-respuesta. Algunos de los primeros usos de [SOAP 1.1] enfatizaban el uso de este patrón como el medio para transportar llamadas a procedimientos remotos (RPC), pero es importante hacer notar que no todos los intercambios petición-respuesta SOAP pueden o necesitan ser modelados como RPC. Este último es utilizado cuando existe la necesidad de modelar cierto comportamiento programático, en el que los mensajes intercambiados conformen con una descripción predefinida de la llamada remota y se retorno.

Un conjunto de escenarios de uso mucho mayor que el cubierto por el patrón petición-prespuesta puede ser modelado simplemente como contenido basado en XML intercambiado en mensajes SOAP para formar una "conversación" de ida y vuelta, en la que la semántica esta al nivel de las aplicaciones que envian y reciben los mensajes. La Sección 2.2.1 cubre el caso de intercambio de contenido basado en XML mediante mensajes SOAP entre la aplicación de reserva de viajes y la aplicación del servicio de viajes en un patrón conversacional, mientras que la sección 2.2.2 proporciona un ejemplo de un intercambio modelado como una RPC.

2.2.1 Intercambio de Mensajes Conversacionales

Continuando con el escenario de reservas de viajes, el Ejemplo 2 muestra un mensaje SOAP devuelto por la aplicación del servicio de viajes en respuesta al mensaje de petición de reserva del Ejemplo 1. Esta respuesta busca la redefinición de parte de la información de la petición, concretamente la elección de aeropuertos en la ciudad de origen.

Ejemplo 2

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 
 <env:Header>
  <m:reserva xmlns:m="http://empresaviajes.example.org/reserva" 
      env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
           env:mustUnderstand="true">
   <m:referencia>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:referencia>
   <m:fechaYHora>2001-11-29T13:35:00.000-05:00</m:fechaYHora>
  </m:reserva>
  <n:pasajero xmlns:n="http://miempresa.example.com/empleados"
      env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
           env:mustUnderstand="true">
   <n:nombre>Åke Jógvan Øyvind</n:nombre>
  </n:pasajero>
 </env:Header>
 <env:Body>
  <p:aclaracionItinerario 
    xmlns:p="http://http://empresaviajes.example.org/reserva/viaje">
   <p:ida>
     <p:salida>
       <p:eleccionAeropuerto>
          JFK LGA EWR 
       </p:eleccionAeropuerto>
     </p:salida>
   </p:ida>
   <p:vuelta>
     <p:llegada>
       <p:eleccionAeropuerto>
         JFK LGA EWR 
       </p:eleccionAeropuerto>
     </p:llegada>
   </p:vuelta>  
  </p:aclaracionItinerario>
 </env:Body>
</env:Envelope>

mensaje SOAP enviado en respuesta al mensaje del Ejemplo 1

Como se había descrito anteriormente, el env:Body contiene el contenido principal del mensaje, que en este ejemplo incluye una lista de varias alternativas para la elección del aeropuerto, conforme a una definición de esquema XML en el espacio de nombres http://travelcompany.example.org/reservation/travel. En este ejemplo, los bloques de encabezado del Ejemplo 1 son devueltos (con algunos valores de subelementos alterados) en la respuesta. Esto podría permitir ala correlación de mensajes a nivel SOAP, pero es muy posible que tales encabezados tengan también otros usos específicos en la aplicación.

Los intercambios de mensajes de los Ejemplos 1 y 2 son casos en los que contenido basado en XML conforme a algún esquema definido por la aplicación se intercambia mediante mensajes SOAP. Una vez más, la discusión de los medios por los que se intercambian tales mensajes queda para la sección 4.

Es suficientemente sencillo ver como tales intercambios pueden acabar convirtiéndose en un patrón de intercambio de mensajes de ida y vuelta múltiple "conversacional". El Ejemplo 3 muestra como un mensaje SOAP enviado por la aplicación de reservas de viajes en respuesta al del Ejemplo 2 eligiendo uno de la lista de aeropuertos disponibles. El bloque de encabezado reserva se acompaña del mismo valor del subelemento referencia en esta conversación, ofreciendo por tanto, un camino, por si fuese necesario, para la correlacionar los mensajes intercambiados entre ellos a nivel de aplicación.

Ejemplo 3

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 
 <env:Header>
  <m:reserva 
     xmlns:m="http://empresaviajes.example.org/reserva" 
      env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
           env:mustUnderstand="true">
    <m:referencia>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:referencia>
    <m:fechaYHora>2001-11-29T13:36:50.000-05:00</m:fechaYHora>
  </m:reserva>
  <n:pasajero xmlns:n="http://miempresa.example.com/empleados"
      env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
           env:mustUnderstand="true">
   <n:nombre>Åke Jógvan Øyvind</n:nombre>
  </n:pasajero>
 </env:Header>
 <env:Body>
  <p:itinerario 
   xmlns:p="http://empresaviajes.example.org/reserva/viaje">
   <p:ida>
     <p:salida>LGA</p:salida>
   </p:ida>
   <p:vuelta>
     <p:llegada>EWR</p:llegada>
   </p:vuelta>
  </p:itinerario>
 </env:Body>
</env:Envelope>

Respuesta al mensaje del Ejemplo 2 continuando el intercambio conversacional de mensajes

2.2.2 Llamadas a Procedimientos Remotos

Uno de los objetivos de diseño de SOAP Version 1.2 es la encapsulación de la funcionalidad de las llamadas a procedimientos remotos utilizando la extensibilidad y funcionalidad de XML. En SOAP Parte 2 sección 4 se ha definido una representación uniforme para invocaciones y respuestas RPC a través de mensajes SOAP. Esta sección continua con el escenario de reservas de viajes para ilustrar el uso de mensajes SOAP como transporte de llamadas a procedimientos remotos y sus resultados.

Con ese fin, el siguiente ejemplo muestra el pago de un viaje utilizando una tarjeta de crédito. (Se asume que los intercambios conversacionales descritos en la sección 2.2.1 han resultado en un itinerario confirmado.) Aquí, también se asume que el pago tiene lugar en el contexto de una transacción global en la que sólo se realiza el cargo a la tarjeta de crédito cuando ambos, el viaje y el alojamiento (no mostrado en el ejemplo, pero reservado presumiblemente de una forma similar), han sido confirmados. La aplicación de reservas de viajes proporciona la información de la tarjeta de crédito y completar con éxito las diferentes actividades resulta en el cargo a la tarjeta de crédito y la devolución de un código de reserva. Esta interacción reserva-y-cargo entre la aplicación de reservas de viajes y la aplicación del servicio de viajes se modela como una SOAP RPC.

Tal información puede ser expresada de por diferentes medios, incluyendo Lenguajes de Definición de Interfaces formales (IDL). Nótese que SOAP no proporciona ningún IDL, formal o informal. Téngase en cuenta también que la información arriba expuesta difiere sutilmente de la información necesaria generalmente para invocar otras RPCs no-SOAP.

Si se recuerda el Elemento 1 aparecido anteriormente, existe, desde una perspectiva SOAP, un nodo SOAP que "contiene" o "soporta" el destino de la RPC. Es el nodo SOAP el que (apropiadamente) toma el papel del destinatario final SOAP. Como requiere el Elemento 1, el destinatario final puede identificar el destino del procedimiento llamado buscando su URI. El modo en que el destino URI se hace disponible depende del protocolo que transporta el mensaje. Una posibilidad es que el URI que identifica el destino sea transportado en un bloque de encabezado SOAP. Otros tipos de protocolos de transporte, tales como el SOAP HTTP definido en [SOAP Parte2], ofrecen un mecanismo de transporte del URI fuera del mensaje SOAP. En general, una de las propiedades de una especificación de enlace a un protocolo debe ser una descripción de cómo el destino URI es transportado como parte de ese enlace. La Sección 4.1 proporciona algunos ejemplos concretos de cómo se transporta el URI en el caso del enlace SOAP al protocolo HTTP, ya estandarizado.

Se requiere que el Elemento 4 y el Elemento 5 aparecidos anteriormente aseguren que las aplicaciones RPC que empleen SOAP lo hagan de forma que sea compatible con los principios arquitectónicos de la World Wide Web. La Sección 4.1.3 discute cómo se utiliza la información proporcionada por los elementos 4 y 5.

Para el resto de esta sección, se asume que la RPC transportada en un mensaje SOAP como se muestra en el Ejemplo 4 es dirigida y despachada de forma apropiada. El propósito de esta sección es resaltar los aspectos sintácticos de las peticiones y respuestas RPC transportadas en un mensaje SOAP.

Ejemplo 4

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
 <env:Header>
   <t:transaccion
           xmlns:t="http://terceraparte.example.org/transaccion"
           env:encodingStyle="http://example.com/codificacion"
           env:mustUnderstand="true" >5</t:transaccion>
 </env:Header>  
 <env:Body>
  <m:cargoReserva
      env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
         xmlns:m="http://empresaviajes.example.org/">
   <m:reserva xmlns:m="http://empresaviajes.example.org/reserva">
    <m:codigo>FT35ZBQ</m:codigo>
   </m:reserva>
   <o:tarjetaCredito xmlns:o="http://miempresa.example.com/financiera">
    <n:nombre xmlns:n="http://miempresa.example.com/empleados">
           Åke Jógvan Øyvind
    </n:nombre> 
    <o:numero>123456789099999</o:numero>
    <o:expira>2005-02</o:expira>
   </o:tarjetaCredito>
  </m:cargoReserva>
 </env:Body>
</env:Envelope>

Petición SOAP RPC con un encabezado obligatorio y dos parámetros de entrada

La RPC como tal se transporta como un hijo del elemento env:Body, y se modela como un struct [estructura] que toma el nombre del método o procedimiento, en este caso cargoReserva. (Un struct es un concepto del Modelo de Datos SOAP definido en [SOAP Parte2] que modela una estructura o tipo de registro que aparece en algunos lenguajes de programación comunes). El diseño de la RPC en el ejemplo (cuya descripción formal no ha sido proporcionada explícitamente) toma dos parámetros de entrada, la reserva correspondiente al viaje planeado está identificada por el codigo de reserva, y la información de la tarjetaCredito. Éste último también es un struct, que contiene tres elementos, el nombre titular de la tarjeta de crédito, el numero de la tarjeta y la fecha en que expira.

En este ejemplo, el atributo env:encodingStyle [env:estiloCodificacion] con el valor http://www.w3.org/2003/05/soap-encoding indica que los contenidos de la estructura cargoReserva han sido serializados de acuerdo a las reglas de codificación de SOAP, es decir, las reglas particulares definidas en SOAP Parte 2 sección 3. Incluso aunque SOAP especifique este esquema de codificación particular, su uso es opcional y la especificación deja claro que otros esquemas de codificación pueden ser utilizados para datos específicos de la aplicación en un mensaje SOAP. Es por esto que se proporciona el atributo env:encodingStyle para calificar bloques de encabezado y sub-elementos del cuerpo del mensaje. La elección del valor del atributo es una decisión propia de la aplicación y la habilidad del que llama y del que recibe la llamada para interoperar se asume que ha sido acordada "fuera-de-banda". La Sección 5.2 muestra un ejemplo del uso de otro esquema de codificación.

Como se vio en el Elemento 6 anterior, las RPCs también pueden requerir el transporte de información adicional, que puede ser importante para el proceso de la llamada en un entorno distribuido, pero que no son parte de la descripción del método o procedimiento formal. (Nótese, no obstante, que proporcionar tal información contextual adicional no es específico de las RPCs, sino que, en general, puede ser requerido para procesar cualquier aplicación distribuida.) En el ejemplo, la RPC se lleva a cabo en el contexto de una transacción global que implica varias acciones que deben completarse satisfactoriamente antes de que la llamada RPC retorne con éxito. El Ejemplo 4 muestra como un bloque de encabezado transaccion dirigido al destinatario final (implicado por la ausencia del atributo env:role) se utiliza para transportar dicha información. (El valor "5" es algún identificador de transacción fijado por y con significado para la aplicación. No se entra en más detalle de la semántica específica de la aplicación de este encabezado aquí, ya que su comentario no viene al caso en la discusión de los aspectos sintácticos de los mensajes SOAP RPC.)

Asumamos que la RPC en el ejemplo expuesto ha sido diseñado para tener la descripción del procedimiento que indica que existen dos parámetros de salida, uno que proporciona el código de referencia para la reserva y otro que es un URL donde se pueden ver los detalles de la reserva. La respuesta RPC se devuelve en el elemento env:Body de un mensaje SOAP, que es modelado como un struct tomando el nombre del procedimiento cargoReserva y, como convención, la palabra "Respuesta" añadida al final. Los dos parámetros de salida que acompañan a la respuesta son el codigo alfanumérico que identifica la reserva en cuestión, y un URI para la ubicación, verEn, desde el que se puede obtener la reserva.

Esto se muestra en el Ejemplo 5a, en el que el encabezado vuelve a identificar de nuevo la transacción dentro de la que se realiza la llamada RPC.

Las RPCs tienen a menudo descripciones en las que se distingue un parámetro de salida particular, el conocido como valor de "retorno". La convención SOAP RPC ofrece un modo de distinguir este valor de "retorno" de otros parámetros de salida en la descripción del procedimiento. Para ilustrar esto, el ejemplo del cargo se modifica para contener una descripción RPC que es casi la misma que la del Ejemplo 5a, es decir, con los mismos dos parámetros de salida, pero además también tiene un valor de "retorno", que puede contener los valores potenciales "confirmado" y "pendiente". La respuesta RPC de acuerdo a esta descripción se muestra en el Ejemplo 5b, en el que el encabezado SOAP, como antes, identifica la transacción dentro de la que se realiza la RPC.

En el Ejemplo 5b, el valor de retorno se identifica mediante el elemento rpc:result [rpc:resultado], y contiene el Nombre Calificado XML (de tipo xs:QName) de otro elemento dentro del struct que es m:estado. Y este contiene el valor real de retorno, "confirmado". Esta técnica permite que el valor real de retorno sea de un tipo concreto de acuerdo a un esquema concreto. Si el elemento rpc:result está ausente, como en el caso del Ejemplo 5a, el valor de retorno no está presente o es de tipo void [vacio].

Mientras que, en principio, la utilización de SOAP para RPC es independiente de la decisión de utilizar un medio particular para la transferencia de la llamada y respuesta RPC, ciertos enlaces con protocolos que soportan el patrón de Petición-Respuesta de intercambio de mensajes SOAP pueden ser los más naturalmente utilizados para este propósito. Un protocolo que soporte este patrón de intercambio de mensajes puede proporcionar una correlación entre una petición y una respuesta. Por supuesto, el diseñador de una aplicación basada en RPC podría elegir poner un identificador de correlación relativo a una llamada y su retorno en un encabezado SOAP, haciendo, por tanto, la RPC independiente de cualquier mecanismo de transporte. En cualquier caso, los diseñadores de aplicaciones deben conocer las características de los protocolos particulares elegidos para la transferencia de SOAP RPCs, tales como latencia, sincronía, etc.

En el caso común, estandarizado en SOAP Parte 2 sección 7, del uso de HTTP como el protocolo de transporte, una invocación RPC se asocia naturalmente a una petición HTTP y una respuesta RPC a una respuesta HTTP. La Sección 4.1 proporciona ejemplos del transporte de RPCs utilizando HTTP.

Sin embargo, merece la pena tener en cuenta que aunque la mayoría de ejemplos del uso de SOAP para RPC utilizan el protocolo HTTP, no está limitado en modo alguno a ese único medio.

2.3 Escenarios de Error

SOAP proporciona un modelo para la gestión de situaciones en las que surgen errores durante el proceso de un mensaje SOAP. SOAP distingue entre las condiciones que resultan en un error, y la habilidad de señalar el error al remitente del mensaje erróneo o a otro nodo. La habilidad de señalar el error depende del mecanismo de transferencia utilizado, y un aspecto de la especificación de enlace de SOAP a un protocolo es especificar como se señalan loe errores, si es que se señalan. El resto de esta sección asume que existe un mecanismo de transferencia para señalar los errores que se producen al procesar los mensajes recibidos, y se concentra en la estructura del mensaje SOAP de error.

El elemento SOAP env:Body tiene otro papel diferente en el que es el lugar en el cual se aloja la información de error propiamente dicha. El modelo de error SOAP (ver SOAP Parte 1, sección 2.6) requiere que todos los errores específicos de SOAP y específicos de la aplicación sean comunicados utilizando un único elemento diferenciador, env:Fault [env:Error], transportado dentro del elemento env:Body. El elemento env:Fault contiene dos subelementos obligatorios,

env:Code 
  [env:Codigo]

env:Reason 
  [env:Razon]

, y (opcionalmente) información específica de la aplicación en el sub-elemento

env:Detail 
  [env:Detalle]

. Otro sub-elemento opcional, el

 
  env:Node [env:Nodo]

, identifica a través de un URI el nodo SOAP que generó el error, su ausencia implica que fue el destinatario final del mensaje el que lo hizo. Aún existe otro subelemento opcional más,

env:Role 
  [env:Papel]

, que identifica el papel que juega el nodo que generó el error.

El subelemento env:Code de env:Fault está en sí mismo formado por un subelemento obligatorio

env:Value 
  [env:Valor]

, cuyo contenido está especificado en la especificación SOAP (ver SOAP Parte 1 sección 5.4.6) así como el subelemento opcional

env:Subcode 
  [env:Subcodigo]

El Ejemplo 6a muestra un mensaje SOAP devuelto en respuesta la petición RPC del Ejemplo 4, e indica un fallo en el proceso de la RPC.

Ejemplo 6a

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
            xmlns:rpc="http://www.w3.org/2003/05/soap-rpc">
  <env:Body>
   <env:Fault>
     <env:Code>
       <env:Value>env:Sender</env:Value>
       <env:Subcode>
        <env:Value>rpc:BadArguments</env:Value>
       </env:Subcode>
     </env:Code>
     <env:Reason>
      <env:Text xml:lang="es">Error en el proceso</env:Text>
      <env:Text xml:lang="en-US">Processing error</env:Text>
      <env:Text xml:lang="cs">Chyba zpracování</env:Text>
     </env:Reason>
     <env:Detail>
      <e:misDetallesError 
        xmlns:e="http://empresaviajes.example.org/errores">
        <e:mensaje>El nombre no concuerda con el número de tarjeta de crédito</e:mensaje>
        <e:codigoerror>999</e:codigoerror>
      </e:misDetallesError>
     </env:Detail>
   </env:Fault>
 </env:Body>
</env:Envelope>

Ejemplo de mensaje SOAP indicando fallo al procesar la RPC del Ejemplo 4

En el Ejemplo 6a, el elemento de mayor nivel env:Value utiliza un Nombre Calificado Estandarizado XML (del tipo xs:QName) para identificar que es un

env:Sender [env:Remitente]

de error, lo que indica que se refiere a algún tipo de error sintáctico o de información inapropiada en el mensaje. (Cuando un error de un env:Sender es recibido del remitente, se espera que se tome algún tipo de acción correctiva antes de enviar un mensaje similar de nuevo.) El sub-elemento env:Subcode es opcional, y, si está presente, como en este ejemplo, califica aún más el valor del padre. En el Ejemplo 6a, el env:Subcode denota que un error específico de RPC, rpc:BadArguments [rpc:ArgumentosMalos], definido en SOAP Parte 2 sección 4.4, es la causa del fallo al procesar la petición.

La estructura del elemento env:Subcode ha sido escogida de forma que sea jerárquica - cada elemento hijo

 
  env:Subcode

tiene un subelemento obligatorio env:Value y un subelemento opcional env:Subcode - para permitir el transporte de códigos específicos de la aplicación. Esta estructura jerárquica del elemento env:Code permite que exista un mecanismo uniforme para expresar múltiples niveles de códigos de error. El elemento de máximo nivel env:Value es una base de error que está especificado en las especificaciones SOAP Versión 1.2 (ver SOAP Parte 1 sección 5.4.6) y debe ser entendido por toos los nodos SOAP. Los env:Values anidados son específicos de la aplicación, y representan mayor elaboración o refinamiento de la base del error desde la perspectiva de la aplicación. Algunos de esos valores pueden estar bien estandarizados, como los códigos de error RPC estandarizados en SOAP 1.2 (ver SOAP Parte 2 sección 4.4), o en algún otro estándar que utilice SOAP como un protocolo de encapsulación. El único requisito para definir tales subcódigos específicos de la aplicación es que estén calificados mediante espacios de nombres diferentes a los del espacio de nombres SOAP env que define las clasificaciones principales para errores SOAP. No existe ningún requisito desde una perspectiva SOAP de que las aplicaciones necesiten entender, o ni siquiera atender en modo alguno a todos los niveles de los valores de subcódigos.

El subelemento env:Reason no pretende atender al proceso algorítmico, sino más bien a que sea legible por humanos; así, aunque este es un elemento obligatorio, el valor elegido no está estandarizado. Por tanto, todo lo que se requiere es que describa la situación de error de forma razonablemente precisa. Debe n existir uno o más sub-elementos env:Text, cada uno con un atributo xml:lang único, lo que permite a las aplicaciones hacer disponible la causa del error en múltiples idiomas. (Las aplicaciones podrían negociar el idioma del texto del error utilizando un mecanismo construido utilizando los encabezados SOAP; aunque esto se encuentra fuera del ámbito de las especificaciones SOAP.)

La ausencia de un subelemento env:Node dentro del env:Fault en el Ejemplo 6a implica que es generado por el destinatario último de la llamada. Los contenidos de env:Detail, como se muestran en el ejemplo, con específicos de la aplicación.

Durante el proceso de un mensaje SOAP, un error también puede generarse un error si un elemento obligatorio del encabezado no es entendido o si la información en él contenida no puede ser procesada. Los errores en el proceso de un bloque de encabezado también se señalan utilizando un elemento env:Fault dentro del env:Body, pero con un bloque de encabezado particularmente diferenciado,

env:NotUnderstood 
  [env:NoEntendido]

, que identifica al bloque de encabezado ofensivo.

El Ejemplo 6b muestra un ejemplo de una respuesta a la RPC del Ejemplo 4 indicando el fallo del proceso del bloque de encabezado t:transaccion. Fíjese en la presencia del código de error env:MustUnderstand en el env:Body, y la identificación del encabezado no entendido utilizando un atributo (no calificado), qname, en el bloque de encabezado especial (vacío) env:NotUnderstood.

Si existiesen varios bloques de encabezado obligatorios que no fuesen entendidos, entonces cada uno podría ser identificado mediante su atributo qname dentro de una serie de bloques de encabezado env:NotUnderstood.

3. Modelo de Procesamiento SOAP

Una vez establecidos varios aspectos sintácticos de un mensaje SOAP así como algunos patrones básicos de intercambio de mensajes, esta sección proporciona una visión general del modelo de procesamiento SOAP (especificado en SOAP Parte 1, sección 2). El modelo de procesamiento SOAP describe las acciones tomadas por un nodo SOAP el recibir un mensaje SOAP.

El Ejemplo 7a muestra un mensaje SOAP con varios bloques de encabezado (omitiendo sus contenidos por brevedad). Se utilizarán variaciones de este en el resto de esta sección para ilustrar varios aspectos del modelo de procesamiento.

El modelo de procesamiento de SOAP describe las acciones (lógicas) tomadas por un nodo SOAP al recibir un mensaje SOAP. Existe un requisito para el nodo que analice las partes de un mensaje que son específicas de SOAP, concretamente esos elementos del espacio de nombres SOAP "env". Tales elementos son el mismo sobre, el encabezado y el cuerpo. Un primer paso es, por supuesto, la comprobación global de que el mensaje SOAP es sintácticamente correcto. Esto es, que es conforme al conjunto de información SOAP XML, sujeto a las restricciones de uso de ciertas construcciones XML - Instrucciones de Procesamiento y Definiciones de Tipo de Documento - como se encuentran definidas en SOAP Parte 1, sección 5.

3.1 El Atributo "role" ["papel"]

El procesamiento posterior de los bloques de encabezado y el cuerpo depende del role(s) [rol(es) ó papel(es)] asumidos por el nodo SOAP para el procesamiento de un mensaje dado. SOAP define el atributo (opcional) env:role - sintácticamente, xs:anyURI - que puede estar presente en un bloque de encabezado, y que identifica el papel que juega el destinatario deseado de ese bloque de encabezado. Se requiere que un nodo SOAP procese un bloque de encabezado si asume el papel identificado por el valor del URI. La forma en que un nodo SOAP asume un papel particular no es parte de las especificaciones SOAP.

En el Ejemplo 7a, el bloque de encabezado unBloque está dirigido a cualquier nodo SOAP que juegue el papel del rol definido en la aplicación mediante el URI http://example.com/Log. Con el fin de ilustrar esto, se asume que la especificación para cada bloque de encabezado de ese tipo requiere que cualquier nodo SOAP que adopte ese rol anote el mensaje completo.

Cada nodo SOAP que reciba un mensaje con un bloque de encabezado que contenga un atributo env:role con el valor "next" debe ser capaz de procesar los contenidos del elemento, ya que ese es el rol estandarizado que cada nodo SOAP debe poder asumir. Un bloque de encabezado que contenga así ese atributo es aquel que se espera que sea examinado y (posiblemente) procesado por el siguiente nodo SOAP a lo largo del camino del mensaje, asumiendo que dicho encabezado no se haya eliminado como resultado del procesamiento en algún nodo previo en el camino del mensaje.

En el Ejemplo 7a, el bloque de encabezado otroBloque se dirige al siguiente nodo en el camino del mensaje. En este caso, el mensaje SOAP recibido por el nodo que juega el papel del rol definido por la aplicación en "http://example.com/Log", también debe poder jugar el papel del papel "next" definido por SOAP. Esto es también cierto para el nodo que es el destinatario final del mensaje, ya que obviamente (e implícitamente) también juega el papel de "next" por ser el siguiente en el camino del mensaje.

El tercer bloque de encabezado, unTercerBloque, en el Ejemplo 7a no tiene el atributo env:role. Está dirigido a un nodo SOAP que asuma el papel de "ultimateReceiver". El rol "ultimateReceiver" (que puede ser declarado explícitamente o implícito si el atributo env:role está no está presente en el bloque de encabezado) lo juega el nodo SOAP que asume el papel del destinatario último de un mensaje SOAP concreto. La ausencia de un atributo env:role en el bloque de encabezado unTercerBloque significa que este elemento de encabezado está dirigido al nodo SOAP que asume el papel de "ultimateReceiver".

Observe que el elemento env:Body no tiene un atributo env:role. El elemento body siempre está dirigido al nodo SOAP que asume el papel de "ultimateReceiver" role. En ese sentido, el cuerpo es sólo como un bloque de encabezado dirigido al destinatario final, pero ha sido diferenciado para permitir que los nodos SOAP (internediarios SOAP usualmente) puedan pasarlo por alto si asumen otros papeles diferentes al de destinatario final. SOAP no prescribe ninguna estructura para el elemento env:Body, excepto que recomienda que cualquier sub-elemento sea calificado mediante espacios de nombres XML. Algunas aplicaciones, tales como las del Ejemplo 1, pueden elegir organizar los sub-elementos de env:Body en bloques, pero esto no es lo que concierne al modelo de procesamiento SOAP.

El otro rol diferenciado para el elemento env:Body, es el de contenedor en el que se ubica la información sobre errores específicos del procesamiento SOAP, es decir, fallos en el proceso de elementos de un mensaje SOAP, y ha sido descrito anteriormente en la sección 2.3.

Si un elemento de encabezado contiene el atributo estandarizado env:role con el valor "none", significa que ningún nodo SOAP debería procesar los contenidos, aunque un nodo podría necesitar examinarlo si el contenido el contenido está formado por datos que son referenciados por otro elemento de encabezado que esté dirigido a un nodo SOAP particular.

Si el atributo env:role tiene un valor vacío, es decir, env:role="", significa que el URI relativo que identifica el rol se resuelve al URI base del mensaje SOAP en cuestión. SOAP Versión 1.2 no define un URI base para un mensaje SOAP, pero pospone a los mecanismos definidos en [XMLBase] la resolución del URI base, que puede ser utilizado para convertir cualquier URI relativo en absoluto. Uno de esos mecanismos sirve al enlace con el protocolo para establecer un URI base, posiblemente por referencia al protocolo en el que el mensaje SOAP se encapsula para su transporte. (De hecho, cuando los mensajes SOAP se transportan mediante HTTP, SOAP Parte 2 sección 7.1.2 define el URI base como el URI de respuesta de la respuesta HTTP, o el valor del encabezado HTTP Content-Location [Ubicación-Contenido].)

La siguiente tabla resume los roles estandarizados aplicables que pueden ser asumidos en varios nodos SOAP. ("Sí" y "No" significa que el correspondiente odo puede o no puede, respectivamente, jugar el papel determinado.)

3.2 El Atributo "mustUnderstand" ["debeEntender"]

El Ejemplo 7b extiende el ejemplo anterior introduciendo otro atributo (opcional) para bloques de encabezado, el atributo env:mustUnderstand.

Después de que un nodo SOAP haya identificado correctamente los bloques de encabezado (y posiblemente el cuerpo) que han sido destinados a él mismo utilizando el atributo env:role, el atributo adicional, env:mustUnderstand, en los elementos de encabezado determina acciones de procesamiento posteriores que deben tomarse. Para asegurar que los nodos SOAP no ignoran los bloques de encabezado que son importantes para el propósito general de la aplicación, los bloques de encabezado SOAP también proporcionan para el atributo adicional opcional, env:mustUnderstand, medios por los que, si el atributo tiene el valor "true", el nodo SOAP destinatario debe procesar el bloque de acuerdo a la especificación de ese bloque. Se denomina coloquialmente a ese bloque como un bloque de encabezado obligatorio. De hecho, el procesamiento del mensaje SOAP no debe ni siquiera comenzar hasta que el nodo haya identificado todos los bloques de encabezado obligatorios destinados a él mismo, y los haya "entendido". Entender un encabezado significa que el nodo debe estar preparado para hacer lo que sea que se describa en la especificación de ese bloque. (Recuerde que las especificaciones de bloques de encabezado no son parte de las especificaciones SOAP.)

En el Ejemplo 7b, se marca el bloque de encabezado unBloque con el valor de env:mustUnderstand a "true", lo que significa que el obligatorio procesar este bloque si el nodo SOAP juega el papel identificado por "http://example.com/Log". Los otros dos bloques de encabezado no están marcados de esa forma, lo que significa que el nodo SOAP al que están destinados no necesita procesarlos. (Presumiblemente las especificaciones de esos bloques permiten esto.)

Un valor "true" para el env:mustUnderstand significa que el nodo SOAP debe procesar el encabezado con la semántica descrita en la especificación del encabezado en sí, o si no generar un error SOAP. El procesamiento del encabezado de forma apropiada puede incluir la eliminación del encabezado de cualquier mensaje SOAP generado, reinsertando el encabezado con el mimo u otro valor, o insertando un nuevo encabezado. La incapacidad de procesar un encabezado obligatorio requiere que todo proceso posterior del mensaje SOAP se interrumpa, y que se genere un error SOAP. El mensaje no se envía más allá.

El elemento env:Body no tiene atributo env:mustUnderstand pero debe ser procesado por el destinatario final. En el Ejemplo 7b, el destinatario final del mensaje - el nodo SOAP que juega el papel del "ultimateReceiver" - debe procesar el env:Body y puede procesar el bloque de encabezado unTercerBloque. También puede procesar el bloque de encabezado otroBloque, ya que está dirigido a él (en el rol de "next") pero no es obligatorio hacerlo así si las especificaciones para el procesamiento de los bloques no lo requieren. (Si la especificación para otroBloque requiere que sea procesado en el siguiente destinatario, habría requerido que fuese marcado con un env:mustUnderstand="true".)

El rol(es) que un nodo SOAP juega al procesar un mensaje SOAP pueden ser determinados por muchos factores. El rol podría ser conocido a priori, o establecido por medios fuera-de-banda, o un nodo puede inspeccionar todas las partes de un mensaje recibido para determinar que roles asumirá, antes de procesar el mensaje. Surge un caso interesante cuando un nodo SOAP, durante el transcurso del procesamiento de un mensaje, decide que existen roles adicionales que necesita adoptar. No importa cuando se realice esta determinación, externamente debe parecer que se ha adherido al modelo de procesamiento. Esto es, debe parece que se ha conocido el rol desde el inicio del procesamiento del mensaje. En particular, la apariencia externa debe ser tal que la comprobación de los env:mustUnderstand de cualquiera de los encabezados, cuyos roles adicionales se asumen, se ha realizado antes del inicio del procesamiento. Además, si un nodo SOAP asume tales roles adicionales, debe asegurar que está preparado para hacer todo lo que requieran las especificaciones de esos roles.

La siguiente tabla resume como las acciones de procesamiento para un bloque de encabezado son calificadas por el atributo env:mustUnderstand con respecto a un nodo al que han sido dirigidas apropiadamente (mediante el atributo env:role).

Como resultado del proceso de un mensaje SOAP, un nodo SOAP puede generar un error SOAP sencillo si falla al procesar un mensaje, o, dependiendo de la aplicación, generar mensajes SOAP adicionales para que sean consumidos por otros nodos SOAP. SOAP Parte 1 sección 5.4 describe la estructura del mensaje de error mientras que el modelo de procesamiento SOAP define las condiciones bajo las que es generado. Como se ilustró previamente en la sección 2.3, un error SOAP es un mensaje SOAP con un sub-elemento estandarizado de env:Body llamado env:Fault.

SOAP realiza una distinción entre generar un error y asegurar que el error es devuelto al remitente del mensaje o a otro nodo apropiado que pueda beneficiarse de esta información. Sin embargo, el que un error generado pueda ser propagado apropiadamente depende del enlace al protocolo de transporte elegido para el intercambio de mensajes SOAP. La especificación no define lo que ocurre si los errores son generados durante la propagación de mensajes de trayecto único. El único enlace con protocolo normativo, que es el enlace SOAP HTTP, ofrece la respuesta HTTP como medio para informar de los errores en el mensaje SOAP de entrada. (Ver la Sección 4 para más detalles sobre los enlaces SOAP con protocolos.)

3.3 El Atributo "relay" ["transmitir"]

SOAP Versión 1.2 define otro atributo opcional para bloques de encabezado, env:relay de tipo xs:boolean,que indica si un bloque de encabezado dirigido a un intermediario SOAP debe ser transmitido si no es procesado.

Recuérdese que si un bloque de encabezado es procesado, las reglas de procesamiento SOAP (ver SOAP Parte 1 sección 2.7.2) requiere que sea eliminado del mensaje de salida. (Sin embargo, puede ser reinsertado, ya sea sin cambiarse o alterándose sus contenidos, si el procesamiento de otros bloques de encabezado determinan que el bloque de encabezado debe ser retenido en el mensaje reenviado.) El comportamiento por defecto para un bloque de encabezado no procesado dirigido a un rol interpretado por un intermediario SOAP es que debe ser eliminado antes de distribuir el mensaje.

La razón de este comportamiento por defecto es quedarse en el lado seguro asegurando que el intermediario SOAP no hace asume nada acerca de la supervivencia de un bloque de encabezado que reciba dirigido a un rol que él asume, y que representa alguna característica de valor añadido, en particular si elige no procesar el bloque de encabezado, es muy probablemente porque no lo "entiende". Eso es porque ciertos bloques de encabezado representan características de salto-en-salto, y pueden no tener sentido propagarlas sin conocerlas de principio a fin. Como un intermediario puede no estar en posición de tomar esta determinación, se pensó en que sería más seguro que los bloques de encabezado no procesados fuesen eliminados antes de distribuir el mensaje.

Sin embargo, hay instancias en las que un diseñador de aplicaciones podría desear introducir una característica nueva, manifestada mediante un bloque de encabezado SOAP, dirigido a cualquier intermediario capaz de encontrarse en el camino del mensaje SOAP. Tal bloque de encabezado estaría disponible para aquellos internediario que lo "entendiesen", pero sería ignorado y distribuido de ahí en adelante por aquellos que no lo hiciesen. Al ser una característica nueva, podría implementarse el software que diese soporte a este bloque de encabezado, al menos inicialmente, en algunos, pero no en todos, los nodos SOAP. Obviamente, es necesario marcar ese bloque de encabezado con env:mustUnderstand = "false", de forma que los intermediarios que no hayan implementado la característica no produzcan un error. Para saltarse el rol por defecto del modelo de procesamiento, marcar el bloque de encabezado con el atributo adicional env:relay con su valor a "true" permite al intermediario redirigir el bloque de encabezado dirigido a él en el caso de que decida no procesarlo.

Dirigir el bloque de encabezado al rol "next" junto con el atributo env:relay a "true" siempre puede servir para asegurarse de que cada intermediario tiene la oportunidad de examinar el encabezado, porque uno de los usos anticipados del rol "next" es con bloques de encabezado que transportan información que se espera que sea persistente a lo largo del camino de un mensaje SOAP. Por supuesto, el diseñador de la aplicación siempre puede definir un rol personalizado que permita dirigirse a intermediarios específicos que asuman este rol. Sin embargo, no hay restricción en el uso del atributo env:relay con cualquier rol excepto, por supuesto, los roles "none" y "ultimateReceiver", para los que no tiene ningún sentido.

El bloque de encabezado q:otroBloque, dirigido al nodo siguiente "next" en el camino del mensaje, tiene el atributo adicional env:relay="true". Un nodo SOAP que reciba este mensaje puede procesar este bloque de encabezado si lo "entiende", pero si lo hace, las reglas de procesamiento requieren que este bloque de encabezado sea eliminado antes de redirigir el mensaje. Sin embargo, si el nodo SOAP decide ignorar este bloque de encabezado, cosa que puede hacer porque no es obligatorio procesarlo como indica la ausencia del atributo env:mustUnderstand, entonces debe redirigirlo.

Procesar el bloque de encabezado p:unBloque es obligatorio y las reglas de procesamiento SOAP requieren que no sea transportado de nuevo, a no ser que el procesamiento de algún otro bloque de encabezado requiera que esté presente en el mensaje de salida. El bloque de encabezado r:unTercerBloque no tiene un atributo env:relay, que es lo mismo que si lo tuviese con el valor env:relay="false". Por tanto, este encabezado no es redirigido si no es procesado.

SOAP 1.2 Parte 1 Tabla 3 resume las condiciones que determinan cuando se permite a un intermediario SOAP que asume un papel determinado la redirección de bloques de encabezado no procesados.

4. Uso de Vínculos con Varios Protocolos

Los mensajes SOAP pueden intercambiarse utilizando una variedad de protocolos, incluyendo las capas de protocolos de otras aplicaciones. La especificación sobre como deben transmitirse los mensajes SOAP de un nodo a otro utilizando el protocolo de transmisión, se denomina Vínculo SOAP. [SOAP Parte1] define un mensaje SOAP en la forma de un [XML Infoset], p.e., en términos de información de atributos y elementos de un documento "abstracto" denominado env:Envelope (ver SOAP Parte 1, sección 5). Cualquier env:Envelope SOAP representado en forma de conjunto de información se concretará a través de un vínculo con un protocolo, cuya tarea, entre otras cosas, es proporcionar una representación serializada del conjunto de información que puede enviarse al siguiente nodo SOAP en el camino del mensaje de un modo tal que el conjunto de información pueda ser reconstruido sin pérdida de información. En ejemplos típicos de mensajes SOAP y, ciertamente en todos los ejemplos de este documento de fundamentos, la serialización que se muestra es la de un documento [XML 1.0] bien formado. No obstante, puede haber otros vínculos con protocolos - por ejemplo un vínculo de protocolo entre dos nodos SOAP sobre un interfaz de ancho de banda limitado - donde pudiera elegirse una serialización alternativa, comprimida del mismo conjunto de información. Otro vínculo, elegido con un propósito diferente, puede proporcionar una serialización que sea una estructura encriptada representando el mismo conjunto de información.

Además de proporcionar una comprensión concreta de un conjunto de información SOAP entre nodos SOAP adyacentes a lo largo del camino de un mensaje SOAP, con un protocolo proporciona los mecanismos que dan soporte a las características que necesita una aplicación SOAP. Una característica es una especificación de una cierta funcionalidad proporcionada por un vínculo. Una descripción de característica se identifica mediante un URI, de forma que todas las aplicaciones que la referencien se aseguren la misma semántica. Por ejemplo, un escenario de uso típico podría requerir muchos intercambios petición-respuesta concurrentes entre nodos SOAP adyacentes, en cuyo caso la característica que se requiere es la habilidad de correlacionar una respuesta con una petición. Otros ejemplos incluyen una característica de "canal encriptado", o una característica de "canal de entrega fiable", o una característica de patrón de intercambio de mensajes SOAP particular.

Una especificación de vínculo SOAP (ver SOAP Parte 1 sección 4) describe, entre otras cosas, aquellas (si existen) características que proporciona. Alguna características pueden ser proporcionadas de forma nativa por el protocolo que lo soporta. Si la característica no está disponible a través del vínculo, podría ser implementada dentro del sobre SOAP, utilizando bloques de encabezado SOAP. La especificación de una característica implementada utilizando bloques de encabezado SOAP se denomina módulo SOAP.

Por ejemplo, si los intercambios de mensajes SOAP fuesen transportados directamente sobre un protocolo de paquetes como UDP, obviamente la característica de correlación del mensaje debería ser proporcionado en cualquier otra parte, ya sea directamente por la aplicación o más probablemente como parte de los conjuntos de información SOAP que se intercambian. En este último caso, la unión con el vínculo de la característica de correlación de mensajes está determinada específicamente dentro del sobre SOAP, p.e., como un bloque de encabezado SOAP, definido en un módulo de "Correlación Petición-Respuesta" identificado por un URI. No obstante, si los conjuntos de información SOAP se fuesen intercambiados utilizando un protocolo que en sí mismo fuera petición/respuesta, la aplicación podría "heredar" implícitamente esta característica proporcionada por el vínculo, y no sería necesario dar más soporte a nivel SOAP o al de la aplicación. (De hecho, el vínculo HTTP para SOAP saca provecho de esta característica de HTTP.)

Sin embargo, un mensaje SOAP puede viajar dando varios saltos entre un remitente y el destinatario último, donde cada salto puede utilizar un vínculo con el protocolo diferente. En otras palabras, una característica (p.e., correlación de mensajes, fiabilidad, etc.) del vínculo con el protocolo de uno de los saltos, podría no tenerla otro vínculo de los que componen el camino del mensaje. SOAP en sí mismo no proporciona ningún mecanismo para ocultar las diferencias de características proporcionadas por diferentes protocolos. No obstante, cualquier característica que necesite una aplicación particular, que pudiera no estar disponible en la infraestructura de soporte, a lo largo del camino del mensaje anticipado, puede ser compensada al ser transportada como parte del conjunto de información del mensaje SOAP, p.e., como un bloque de encabezado SOAP especificado en algún módulo.

Por tanto, parece que existe un número de cuestiones a las que debe enfrentarse un diseñador de aplicaciones para cumplir la semántica de una aplicación particular, incluyendo como sacar provecho de las características nativas de los protocolos de apoyo disponibles en el entorno elegido. SOAP Parte 1 sección 4.2 proporciona una infraestructura general para describir la manera en la que aplicaciones basadas en SOAP pueden elegir la utilización de características proporcionadas por el vínculo con el protocolo en el que se apoyan para intercambiar mensajes SOAP.

Entre otras cosas, una especificación de vínculo debe definir una característica particular, el patrón(es) de intercambio de mensajes que soporta. [SOAP Part2] define dos patrones de intercambio, un patrón de intercambio de mensajes Petición-Respuesta SOAP donde un mensaje SOAP es intercambiado en cada dirección entre dos nodos SOAP adyacentes, y un patrón de intercambio de mensajes SOAP de Respuesta que consiste en un mensaje no-SOAP que actúa como una petición seguida de un mensaje SOAP incluido como parte de la respuesta.

[SOAP Parte2] también ofrece al diseñador de aplicaciones una característica general denominada la característica de método Web SOAP que permite a las aplicaciones control total sobre la elección del, así llamado, "método Web" - uno de GET, POST, PUT, DELETE cuya semántica se define en las especificaciones [HTTP 1.1] - que pueden ser utilizadas encima del vínculo. Esta característica está definida para asegurar que las aplicaciones que utilicen SOAP puedan hacerlo de forma que sea compatible con los principios arquitectónicos de la World Wide Web. (Muy brevemente, la simplicidad y escalabilidad de la Web se debe en gran parte al hecho de que existan algunos métodos genéricos (GET, POST, PUT, DELETE) que se pueden utilizar para interactuar con cualquier recurso disponible en la Web a través de un URI.) La característica de método Web SOAP es soportada por el vínculo SOAP HTTP, aunque, en principio, está disponible para todos los vínculos de SOAP con protocolos.

SOAP Parte 2 sección 7 especifica un vínculo de protocolo estandarizado utilizando la infraestructura de [SOAP Parte1], en concreto como se utiliza SOAP junto con HTTP como el protocolo de apoyo. SOAP Versión 1.2 se restringe a sí mismo a la definición de un vínculo HTTP al que sólo permite el uso del método POST en conjunción con el patrón de intercambio de mensajes Petición-Respuesta. Otras especificaciones futuras podrían definir vínculos SOAP con HTTP o con otros medios de transporte que hagan uso de otros métodos Web (p.e., PUT, DELETE).

Las siguientes secciones muestran ejemplos de dos vínculos con protocolos diferentes, concretamente con [HTTP 1.1] y correo electrónico. Debería enfatizarse de nuevo que el único vínculo normativo para mensajes SOAP 1.2 es con [HTTP 1.1]. Los ejemplos de la sección 4.2 que muestran al correo electrónico como mecanismo de transporte para SOAP sirven simplemente para sugerir otras elecciones para la transferencia de mensajes SOAP que son posibles, aunque no se encuentran estandarizadas en este momento. Una Nota del W3C [SOAP Email Binding] [Vínculo de SOAP con el Correo Electrónico], ofrece una aplicación de la infraestructura del vínculo SOAP de [SOAP Parte1] mediante la descripción de un vínculo experimental de SOAP con el transporte por correo electrónico, específicamente, el transporte de mensajes basado en [RFC 2822].

4.1 El Vínculo SOAP HTTP

HTTP tiene un modelo bien conocido y un patrón de intercambio de mensajes. El cliente identifica al servidor mediante un URI, se conecta a él utilizando la red TCP/IP, envía un mensaje de petición HTTP y recibe un mensaje de respuesta HTTP sobre la misma conexión TCP. HTTP correlaciona implícitamente su mensaje de petición con su mensaje de respuesta; por tanto, una aplicación que utilice este vínculo puede elegir inferir una correlación entre el mensaje SOAP enviado en el cuerpo de un mensaje de petición HTTP y el mensaje SOAP devuelto en una respuesta HTTP. De forma similar, HTTP identifica el punto de destino en el servidor mediante un URI, el Request-URI [URI-Solicitado], que también puede servir como el identificador de un nodo SOAP en el servidor.

HTTP permite múltiples intermediarios entre el cliente inicial y el servidor de origen identificado por el Request-URI, en cuyo caso el modelo petición/respuesta es una serie de esos pares. Obsérvese, no obstante, que los intermediarios SOAP son diferentes de los intermediarios HTTP.

El vínculo con HTTP de [SOAP Parte2] hace uso de una característica de método Web SOAP para permitir a las aplicaciones elegir el, así llamado, método Web - restringiéndolo a un GET o un POST - para utilizar encima del intercambio de mensajes HTTP. Además, hace uso de dos patrones de intercambio de mensajes que ofrecen a las aplicaciones dos maneras de intercambiar mensajes SOAP vía HTTP: 1) el uso del método HTTP POST para transportar mensajes SOAP en los cuerpos de los mensajes de peticiones y respuestas HTTP, y 2) el uso del método HTTP GET en una petición HTTP para devolver un mensaje SOAP en el cuerpo de una respuesta HTTP. El primer patrón de uso es la instanciación de HTTP-específica de una característica del vínculo llamada patrón de intercambio de mensajes petición-respuesta SOAP, mientras que el segundo utiliza una característica denominada patrón de intercambio de mensajes de respuesta SOAP.

El propósito de facilitar estos dos tipos de usos es el de acomodar los dos paradigmas de interacción que está bien establecidos en la World Wide Web. El primer tipo de interacción permite el uso de datos en el cuerpo de un HTTP POST para crear o modificar el estado de un recurso identificado por el URI al que se dirige la petición HTTP. El segundo tipo de patrón de interacción ofrece la posibilidad de utilizar una petición HTTP GET para obtener una representación de un recurso sin alterar su estado en modo alguno. En el primer caso, el aspecto de interés específico SOAP es que el cuerpo de la petición HTTP es un mensaje SOAP que tiene que ser procesado (por el modelo de procesamiento SOAP) como una parte del procesamiento específico de la aplicación requerido para ajustarse a la semántica de POST. En el segundo caso, el uso típico que se prevé es el caso en el que la representación del recurso que se pide no sea devuelto como HTML, ni como un documento genérico XML, sino como un mensaje SOAP. Esto es, el encabezado del tipo de contenido en el mensaje de respuesta lo identifica como del tipo "application/soap+xml". Presumiblemente, habrá editores de recursos en la Web que determinen que tales recursos se harán disponibles y serán obtenidos mejor en la forma de mensajes SOAP. Obsérvese, no obstante, que los recursos pueden, en general, hacerse disponibles en múltiples representaciones, y la representación preferida o deseada y la aplicación que realiza la petición indica la representación preferida o deseada utilizando el encabezado HTTP Accept.

Un aspecto más del vínculo SOAP HTTP es la cuestión de como una aplicación determina cual de esos dos tipos de patrones de mensaje utilizar. [SOAP Parte 2] sirve de guía en las circunstancias en las que las aplicaciones pueden utilizar uno de los dos patrones de intercambio de mensajes. (Es consejo - aunque muy fuerte - como el descrito en la forma de un " SHOULD" ["DEBERÍA"] en las especificaciones más que un requisito absoluto identificado por la palabra "MUST" ["DEBE"], interpretándose esas palabras según se encuentran definidas en IETF [RFC 2119].) el patrón de intercambio de respuesta SOAP con el método HTTP GET es utilizado cuando una aplicación asegura que el intercambio de mensajes es con el propósito de obtención de información, en el que el recurso de información permanece "intocable" como resultado de la interacción. A tales interacciones se les refiere como seguras y idempotentes en la especificación HTTP. Como el uso de HTTP SOAP GET no permite un mensaje SOAP en la petición, las aplicaciones que necesiten características en la interacción de ida que sólo puedan ser soportadas por una expresión específica al vínculo dentro del conjunto de información SOAP (p.e., como bloques de encabezado SOAP), no pueden hacer, obviamente, uso de este patrón de intercambio de mensajes. Observe que el vínculo HTTP POST está disponible para ser utilizado en todos los casos.

Las siguientes subsecciones proporcionan ejemplos del uso de estos dos patrones de intercambio de mensajes para el vínculo HTTP.

4.1.1. Uso de SOAP HTTP GET

El uso del vínculo HTTP con el patrón de intercambio de mensajes de Respuesta SOAP se encuentra restringido al método HTTP GET. Esto significa que la respuesta a una petición HTTP GET desde un nodo SOAP solicitante es un mensaje SOAP en la respuesta HTTP.

El Ejemplo 8a muestra un HTTP GET dirigido por la aplicación del viajero (continuando en el escenario de reservas de viajes) al URI


 http://empresaviajes.example.org/reservas?codigo=FT35ZBQ

en el que puede visualizarse el itinerario del viajero. (Puede ver como se hizo disponible este URL en el Ejemplo 5a.)

El encabezado HTTP Accept se utiliza par indicar la representación preferida del recurso que se solicita, que en este ejemplo es de tipo "application/soap+xml" para ser consumido por una máquina cliente, en vez de tipo "text/html" para ser mostrado por un navegador cliente y consumido por un humano.

El Ejemplo 8b muestra la respuesta HTTP al GET del Ejemplo 8a. El cuerpo de la respuesta HTTP contiene un mensaje SOAP que muestra los detalles del viaje. Una discusión sobre los contenidos del mensaje SOAP queda pospuesta hasta la sección 5.2 , ya que no es relevante, en este punto, entender el manejo del vínculo HTTP GET.

Ejemplo 8b

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 
 <env:Header>
  <m:reserva xmlns:m="http://empresaviajes.example.org/reserva" 
       env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
           env:mustUnderstand="true">
   <m:referencia>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:referencia>
   <m:fechaYHora>2001-11-30T16:25:00.000-05:00</m:fechaYHora>
  </m:reserva>
 </env:Header>
 <env:Body>
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
            xmlns:x="http://empresaviajes.example.org/vocab#"
     env:encodingStyle="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
   <x:PeticionReserva 
 rdf:about="http://empresaviajes.example.org/reservas?codigo=FT35ZBQ">
      <x:pasajero>Åke Jógvan Øyvind</x:pasajero>
      <x:ida>
       <x:PeticionViaje>
        <x:hasta>LAX</x:hasta>
        <x:desde>LGA</x:desde>
        <x:fecha>2001-12-14</x:fecha>
       </x:PeticionViaje>
      </x:ida>
      <x:vuelta>
       <x:PeticionViaje>
        <x:hasta>JFK</x:hasta>
        <x:desde>LAX</x:desde>
        <x:fecha>2001-12-20</x:fecha>
       </x:PeticionViaje>
      </x:vuelta>
    </x:PeticionReserva>
  </rdf:RDF>
 </env:Body>
</env:Envelope>

mensaje SOAP devuelto como respuesta al HTTP GET del Ejemplo 8a

Observe que los detalles de la reserva podrían muy bien haber sido devueltos como un documento (X)HTML, pero este ejemplo quería mostar un caso en el que la aplicación de reservas devuelve el estado del recurso (la reserva) en un formato centrado-en-los-datos (un mensaje SOAP) que puede ser procesado por una máquina, en ves de (X)HTML que sería procesado por un navegador. Ciertamente, en los usos más esperados de SOAP, la aplicación consumidora, no será un navegador.

También, como se muestra en el ejemplo, el uso de SOAP en el cuerpo de la respuesta HTTP, ofrece la posibilidad de expresar algunas características específicas de la aplicación mediante el uso de encabezados SOAP. Utilizando SOAP, se proporciona a la aplicación una infraestructura útil y consistente y un modelo de procesamiento para expresar tales características.

4.1.2 Uso de SOAP HTTP POST

El uso del vínculo HTTP con el patrón de intercambio de mensajes Petición-Respuesta SOAP está restringido al método HTTP POST. Obsérvese que el uso de este patrón de intercambio de mensajes en el vínculo SOAP HTTP se encuentra disponible para todas las aplicaciones, ya estén envueltas en el intercambio de datos generales en XML, o RPCs (como en los siguientes ejemplos) encapsulados en mensajes SOAP.

Los ejemplos 9 y 10 muestran un ejemplo de un vínculo HTTP usando el patrón de intercambio de mensajes Petición-Respuesta SOAP, utilizando el mismo escenario que aquel del Ejemplo 4 y Ejemplo 5a, respectivamente, concretamente transportando una RPC y su respuesta en el cuerpo de un mensaje SOAP. Los ejemplos y discusión en esta sección sólo se concentran en los encabezados HTTP y su papel.

Ejemplo 9

POST /Reservas HTTP/1.1
Host: empresaviajes.example.org
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
 <env:Header>
   <t:transaccion
         xmlns:t="http://terceraparte.example.org/transaccion"
         env:encodingStyle="http://example.com/encoding"
         env:mustUnderstand="true" >5</t:transaccion>
 </env:Header>  
 <env:Body>
   <m:cargoReserva
      env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
      xmlns:m="http://empresaviajes.example.org/">
      <m:reserva xmlns:m="http://empresaviajes.example.org/reserva">
        <m:codigo>FT35ZBQ</m:codigo>
      </m:reserva>      
      <o:tarjetaCredito xmlns:o="http://miempresa.example.com/financiera">
        <n:nombre xmlns:n="http://miempresa.example.com/empleados">
           Åke Jógvan Øyvind
        </n:nombre>
        <o:numero>123456789099999</o:numero>
        <o:caducidad>2005-02</o:caducidad>
      </o:tarjetaCredito >
   </m:cargoReserva>
  </env:Body>
</env:Envelope>

La RPC del Ejemplo 4 transportada en una Petición HTTP POST

El Ejemplo 9 muestra una petición RPC dirigida a la aplicación del servicio de viajes. El mensaje SOAP es enviado en el cuerpo de un método HTTP POST dirigido al URI que identifica el recurso "Reservas" en el servidor empresaviajes.example.org. Cuando se utiliza HTTP, el Request-URI indica el recurso al que se "destina" la invocación. Aparte de la exigencia de que sea un URI válido, SOAP no impone ninguna restricción formal en la forma del URI solicitado (ver [RFC 2396] para más información sobre URIs). Sin embargo, uno de los principios de la arquitectura Web es que todos los recursos importantes sean identificados mediante URIs. Esto implica que la mayoría de los servicio SOAP con buena arquitectura serán expresados como un gran número de recursos, cada uno con su propio URI. Ciertamente, muchos de esos recursos tienden a ser creados dinámicamente durante la operación del servicio, tales como, por ejemplo, la reserva de viaje específica mostrada en el ejemplo. Así, una aplicación del servicio de viajes con buena arquitectura debería tener URIs diferentes para cada reserva, y las peticiones SOAP para recuperar o manipular esas reservas serán dirigidas a sus URIs para cada una de las reservas, y no a un URI de "Reservas" único y monolítico, como se muestra en el Ejemplo 9. El Ejemplo 13 en la sección 4.1.3 muestra el modo preferido para dirigir recursos tales como los de una reserva de viaje concreta. Por tanto, posponemos hasta la sección 4.1.3 mayor discusión sobre el uso de SOAP/HTTP compatible con la arquitectura Web.

Cuando se ubican mensajes SOAP en cuerpos HTTP, el encabezado HTTP Content-type debe tener el valor "application/soap+xml". (El parámetro opcional charset [juego de caracteres], que puede tomar los valores "utf-8" o "utf-16", se muestra en este ejemplo, pero sin que las reglas independientes de juegos de caracteres de [XML 1.0] se apliquen al cuerpo de la petición HTTP.)

El Ejemplo 10 muestra una respuesta a una RPC (con detalles omitidos) enviados por la aplicación del servicio de viajes en la respuesta HTTP correspondiente a la petición del Ejemplo 5a. SOAP, utilizando el transporte HTTP, sigue la semántica de los códigos de estado HTTP para comunicar información de estado en HTTP. Por ejemplo, la serie de códigos de estado HTTP 2xx indica que la petición del cliente (incluyendo el componente SOAP) fue recibida con éxito, entendida, y aceptada, etc.

Si existen errores en el procesamiento de la petición, la especificación del vínculo HTTP requiere que se utilice un HTTP 500 "Error Interno del Servidor" con un mensaje SOAP embebido que contenga un error SOAP indicando el error de procesamiento en el lado del servidor.

El Ejemplo 11 es el mismo mensaje de error SOAP del Ejemplo 6a, pero en esta ocasión con los encabezados HTTP añadidos.

Ejemplo 11

HTTP/1.1 500 Internal Server Error
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
  <env:Body>
    <env:Fault>
     <env:Code>
       <env:Value>env:Sender</env:Value>
       <env:Subcode>
        <env:Value>rpc:BadArguments</env:Value>
       </env:Subcode>
     </env:Code>
     <env:Reason>
      <env:Text xml:lang="en-US">Processing error</env:Text>
      <env:Text xml:lang="cs">Chyba zpracování</env:Text>

      <env:Text xml:lang="es">Error de Procesamiento</env:Text>
     </env:Reason>
     <env:Detail>
      <e:myFaultDetails 
        xmlns:e="http://empresaviajes.example.org/errores" >
        <e:mensaje>El Nombre no concuerda con el número de tarjeta</e:mensaje>
        <e:codigoerror>999</e:codigoerror>
      </e:myFaultDetails>
     </env:Detail>
   </env:Fault>
 </env:Body>
</env:Envelope>

Mensaje de muestra SOAP en una Respuesta SOAP indicando un fallo al operar con el Cuerpo SOAP del Ejemplo 4

La Tabla 16 en SOAP Parte 2 proporciona comportamiento detallado para el manejo de las diferentes códigos de error HTTP posibles, p.e., el2xx (éxito), 3xx (redirección), 4xx (error del cliente) y 5xx (error del servidor).

4.1.3 Uso de SOAP Compatible con la Arquitectura Web

Uno de los conceptos esenciales de la World Wide Web es aquel del URI como identificador de recursos. Los servicios SOAP que utilizan el vínculo HTTP y desea interoperar con otro software Web deberían utilizar URIs para indicar todos los recursos importantes en su servicio. Por ejemplo, un uso muy importante - verdaderamente predominante - de la World Wide Web es la pura obtención de información, en la que la representación de un recurso disponible, identificado por un URI, se obtiene utilizando una petición HTTP GET sin afectar al recurso en modo alguno. (Esto se llama un método seguro e idempotente en terminología HTTP.) El punto clave es que el editor del recurso hace disponible su URI, que los consumidores pueden "GET" ["OBTENER"].

Hay muchos casos en los que los mensajes SOAP se diseñan para usos que son puramente de obtención de información, como aquellas en las que se solicita el estado de algún recurso (o objeto, en términos de programación), opuestamente a usos en los que se realiza manipulación del recurso. En tales casos, el uso de un cuerpo SOAP para transportar la petición del estado, con un elemento del cuerpo representando al objeto en cuestión, es visto como contrario al espíritu de la Web porque el recurso no está identificado por el Request-URI del HTTP GET. (En algunas implementaciones SOAP/RPC, el Request-URI de HTTP no suele ser el identificador del recurso en sí, sino de alguna entidad intermedia que tiene que evaluar el recurso SOAP para identificar el recurso.)

Para destacar los cambios necesarios, el Ejemplo 12a muestra la forma no recomendada para realizar la obtención segura de información en la Web. Este es un ejemplo de una RPC transportada en un mensaje SOAP, utilizando de nuevo el tema de reservas de viajes, en el que la petición sirve para obtener el itinerario de una reserva en particular identificada por uno de los parámetros, reservationCode, de la RPC. (Para el propósito de esta discusión, se asume que la aplicación que utiliza esta petición RPC no necesita características que requieran el uso de encabezados SOAP.)

Observe que el recurso que se solicita no está identificado por el URI de destino en la petición HTTP sino que debe ser obtenido mirando dentro del sobre SOAP. De este modo, no es posible, como sería el caso de otros URIs "obtenibles" en la Web, hacer esto disponible sólo vía HTTP para consumidores en la World Wide Web.

La sección 4.1 de SOAP Parte 2 ofrece recomendaciones sobre como las RPCs que realizan solicitudes seguras e idempotentes pueden ser definidas de un modo Web-amigable. Lo hace así distinguiendo aspectos del método y parámetros específicos en una definición RPC que sirven para identificar recursos, de otros que sirven para otros propósitos. En el Ejemplo 12a, el recurso que se solicita se identifica por dos cosas: la primera es que es un itinerario (parte del nombre del método), y la segunda es la referencia a una instancia específica (un parámetro para el método). En tal caso, la recomendación es que estas partes que identifican recursos estén disponibles en el Request-URI de HTTP que identifica el recurso, como por ejemplo, del siguiente modo: http://empresaviajes.example.org/reservas/itinerario?codigoReserva=FT35ZBQ.

Además, cuando una definición RPC es tal que todas las partes de la descripción de su método pueden ser descritas como identificadoras del recurso, el objetivo total de la RPC debe estar identificado por un URI. En este caso, si el proveedor del recurso también puede asegurar que la petición para obtenerlo es segura, entonces SOAP Versión 1.2 recomienda que la elección de la propiedad del sea el método Web GET y el uso del patrón de intercambio de mensajes de Respuesta SOAP se realice según se encuentra descrito en la sección 4.1.1. Esto asegurará que la SOAP RPC será realizada de un modo compatible con la arquitectura Web. El Ejemplo 12b muestra la forma preferida para que un nodo SOAP realice una petición para la obtención segura de un recurso.

Debería observarse que SOAP Versión 1.2 no especifica ningún algoritmo sobre como computar un URI a partir de la definición de una RPC que haya sido determinada como de obtención pura de información.

Nótese, sin embargo, que si la aplicación requiere el uso de características que sólo pueden tener una expresión específica según el vínculo dentro del conjunto de información SOAP, es decir, utilizando bloques de encabezado SOAP, entonces la aplicación debe elegir el método HTTP POST con un mensaje SOAP en el cuerpo de la petición.

También se requiere el uso del patrón de intercambio de mensajes Petición-Respuesta SOAP implementado mediante un HTTP POST si la descripción RPC incluye datos (parámetros) que no identifican recursos. Incluso en este caso, el HTTP POST con un mensaje SOAP puede ser representado de una manera Web-amigable. Como ocurre con el uso de GET, [SOAP Parte 2] recomienda para el caso general en el que cualquier parte del mensaje SOAP que sirva para identificar el recurso al que la petición es enviada sea identificada en el Request-URI de HTTP. Los mismos parámetros pueden, por supuesto, ser retenidos en el elemento SOAP env:Body. (Los parámetros deben quedarse en el Cuerpo en caso de una SOAP RPC ya que esos son relativos a la descripción del procedimiento/método que espera la aplicación receptora.)

El Ejemplo 13 es el mismo que el Ejemplo 9, excepto que el Request-URI de HTTP ha sido modificado para incluir el codigo de reserva, que sirve para identificar el recurso (la reserva en cuestión, que está siendo confirmada y pagada).

Ejemplo 13

POST /Reservas?codigo=FT35ZBQ HTTP/1.1
Host: empresaviajes.example.org
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<?xml version='1.0'?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
 <env:Header>
   <t:transaccion
           xmlns:t="http://terceraparte.example.org/transaccion"
           env:encodingStyle="http://example.com/encoding"
           env:mustUnderstand="true" >5</t:transaccion>
 </env:Header>  
 <env:Body>
  <m:cargoReserva
      env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
         xmlns:m="http://empresaviajes.example.org/">
   <m:reserva xmlns:m="http://empresaviajes.example.org/reserva">
    <m:codigo>FT35ZBQ</m:codigo>
   </m:reserva> 
   <o:tarjetaCredito xmlns:o="http://miempresa.example.com/financiera">
    <n:nombre xmlns:n="http://miempresa.example.com/empleados">
           Åke Jógvan Øyvind
    </n:nombre>   
    <o:numero>123456789099999</o:numero>
    <o:caducidad>2005-02</o:caducidad>
   </o:tarjetaCredito>
  </m:cargoReserva >
 </env:Body>
</env:Envelope>

RPC del Ejemplo 4 transportada en una Petición HTTP POST Request de un modo Web-amigable

En el Ejemplo 13, el recurso a manipular se identifica por dos cosas: la primera es la de la reserva (parte del nombre del método) y la segunda es la instancia específica de la reserva (que es el valor del parámetro code que se pasa al método). El resto de parámetros en la RPC tales como el número de la tarjetaCredito no identifican ningún recurso, pero son datos auxiliares que serán procesados por el recurso. Es recomendación de [SOAP Parte2] que los recursos que puedan ser accedidos mediante llamadas RPC a través de SOAP deberían, donde sea práctico, ubicar cualquier información relativa a la identificación del recurso como parte del URI que identifica el destino de la RPC. Debería observarse, sin embargo, que [SOAP Parte 2] no ofrece ningún algoritmo para hacerlo de esa manera. Tales algoritmos podrían ser desarrollados en el futuro. Observe, sin embargo, que todos los elementos que identifican recursos han sido mantenidos en su forma codificada en el elemento SOAP env:Body como en el Ejemplo 9.

En otras palabras, como se puede apreciar en los ejemplos anteriores, la recomendación en las especificaciones SOAP es utilizar URIs de un modo compatible con la arquitectura Web - esto es, como identificadores de recursos - sin importar si se utiliza GET o POST.

4.2 SOAP Sobre Correo Electrónico

Los desarrolladores de aplicaciones pueden utilizar la infraestructura de correo electrónico de Internet para transmitir mensajes SOAP ya sean como mensajes de correo electrónico de texto o como adjuntos. Los ejemplos que se muestran a continuación muestran un modo de transmitir mensajes SOAP, y deben ser tomados como el modo estándar de hacerlo. Las especificaciones SOAP Versión 1.2 no especifican tal vínculo. Sin embargo, existe una Nota W3C no-normativa [SOAP Email Binding] que describe un vínculo de SOAP con el correo electrónico, su propósito principal es comenzar a demostrar la aplicación de la Infraestructura general de Vínculos con el Protocolo SOAP descrita en [SOAP Part 1].

El Ejemplo 14 muestra el mensaje de petición de reserva de viaje del Ejemplo 1 transportado como un mensaje de correo electrónico entre un agente de usuario remitente y un agente de usuario destinatario. Se implica que el nodo destinatario tiene capacidad para entender SOAP, por lo que el mensaje de correo electrónico se le envía para su procesamiento. (Se asume que también el nodo remitente puede manejar errores SOAP que pudiera recibir en la respuesta, o correlacionar cualesquiera mensajes SOAP recibidos en respuesta a este.)

Ejemplo 14

De: a.oyvind@miempresa.example.com
A: reservas@empresaviajes.example.org
Asunto: Viaje a LA
Fecha: Thu, 29 Nov 2001 13:20:00 EST
Message-Id: <EE492E16A090090276D208424960C0C@miempresa.example.com>
Content-Type: application/soap+xml 

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 
 <env:Header>
  <m:reserva xmlns:m="http://empresaviajes.example.org/reserva" 
      env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
         env:mustUnderstand="true">
   <m:referencia>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</referencia>
   <m:fechaYHora>2001-11-29T13:20:00.000-05:00</m:fechaYHora>
  </m:reserva>
  <n:pasajero xmlns:n="http://miempresa.example.com/empleados"
      env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
         env:mustUnderstand="true">
   <n:nombre>Åke Jógvan Øyvind</n:nombre>
  </n:pasajero >
 </env:Header>
  <env:Body>
  <p:itinerario
    xmlns:p="http://empresaviajes.example.org/reserva/viaje">
   <p:ida>
     <p:salida>Nueva York</p:salida>
     <p:llegada>Los Angeles</p:llegada>
     <p:fechaSalida>2001-12-14</p:fechaLlegada>
     <p:horaSalida>última hora de la tarde</p:horaSalida>
     <p:preferenciaAsiento>pasillo</p:preferenciaAsiento>
   </p:ida>
   <p:vuelta>
     <p:salida>Los Angeles</p:salida>
     <p:llegada>Nueva York</p:llegada>
     <p:fechaSalida>2001-12-20</p:fechaSalida>
     <p:horaSalida>media-mañana</p:horaSalida>
     <p:preferenciaAsiento/>
   </p:vuelta>
  </p:itinerario>
  <q:alojamiento
   xmlns:q="http://empresaviajes.example.org/reserva/hoteles">
   <q:preferencia>ninguna</q:preferencia>
  </q:alojamiento>
 </env:Body>
</env:Envelope>

Mensaje SOAP del Ejemplo 1 transportado como un mensaje SMTP

El encabezado del Ejemplo 14 tiene la forma estándar de [RFC 2822] para mensajes de correo electrónico.

Aunque el correo electrónico es un intercambio de mensajes en un solo sentido, y no se da ninguna garantía de entrega, infraestructuras como la de la especificación Simple Mail Transport Protocol (SMTP) [Protocolo para el Transporte de Correo Simple] [SMTP] ofrecen un mecanismo de notificación de entrega que, en el caso de SMTP, se denominan Delivery Status Notification (DSN) [Notificación de Estado de Entrega] y Message Disposition Notification (MDN) [Notificación de Disposición de Mensaje]. Estas notificaciones toman la forma de mensajes de correo electrónico enviados a la dirección de correo electrónico especificada en el encabezamiento del mensaje de correo. Las aplicaciones, así como los usuarios finales del correo, pueden utilizar estos mecanismos para proporcionar el estado de una transmisión de correo electrónico, pero estos, si se existiesen, serían notificaciones al nivel SMTP. El desarrollador de aplicaciones debe comprender completamente las capacidad y limitaciones de estas notificaciones de entrega o el riesgo de asumir que haya existido una entrega del mensaje con éxito cuando podría no haberse producido.

Los mensajes de estado de entrega SMTP son separados del procesamiento del mensaje en la capa SOAP. Las respuestas SOAP resultantes a los datos SOAP serán devueltas a través de un mensaje de correo electrónico nuevo que podría tener o no un enlace con el mensaje de la petición original al nivel SMTP. El uso del encabezado In-reply-to: [En-respuesta-a] según [RFC 2822] puede conseguir una correlación al nivel SMTP, pero no implica necesariamente una correlación al nivel SOAP.

El Ejemplo 15 es exactamente el mismo escenario descrito para el Ejemplo 2, en el que se muestra un mensaje SOAP (se han omitido los detalles del cuerpo del mensaje por brevedad) enviado desde la aplicación del servicio de viajes a la aplicación de reservas de viajes solicitando la aclaración de algunos detalles de la reserva, excepto que en este caso es transportada en un mensaje de correo electrónico. En este ejemplo, el Message-Id [Identificador de Mensaje] del correo electrónico original se transporta en el encabezado adicional In-reply-to:, que correlaciona mensajes a nivel SMTP, pero que no puede proporcionar una correlación SOAP específica. En este ejemplo, la aplicación confia en el bloque de encabezado reserva para correlacionar los mensajes SOAP. De nuevo, la consecución de tal correlación se debe conseguir al nivel de la aplicación, y no se encuentra dentro del ámbito de SOAP.

Example 15

De: reservas@empresaviajes.example.org
A: a.oyvind@miempresa.example.com
Asunto: ¿Qué aeropuerto de NY?
Fecha: Thu, 29 Nov 2001 13:35:11 EST
Message-Id: <200109251753.NAA10655@travelcompany.example.org>
In-reply-to:<EE492E16A090090276D208424960C0C@mycompany.example.com>
Content-Type: application/soap+xml

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 
 <env:Header>
  <m:reserva xmlns:m="http://empresaviajes.example.org/reserva" 
      env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
           env:mustUnderstand="true">
   <m:referencia>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:referencia>
   <m:fechaYHora>2001-11-29T13:35:00.000-05:00</m:fechaYHora>
  </m:reserva>
  <n:pasajero xmlns:n="http://miempresa.example.com/empleados"
      env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
           env:mustUnderstand="true">
   <n:nombre>Åke Jógvan Øyvind</n:nombre>
  </n:pasajero>
 </env:Header>
 <env:Body>
  <p:aclaracionItinerario 
    xmlns:p="http://http://empresaviajes.example.org/reserva/viaje">

...

     ...
  </p:aclaracionItinerario>
 </env:Body>
</env:Envelope>

Mensaje SOAP del Ejemplo 2 transportado en un mensaje de correo electrónico con un encabezado que lo correlaciona con un mensaje anterior.

5. Escenarios de Uso Avanzado

5.1 Utilización de Intermediarios SOAP

El escenario de reservas de viajes utilizado a lo largo de este documento ofrece una oportunidad de exponer algunos de los usos de los intermediarios SOAP. Recuerde que el intercambio básico era el intercambio de una petición de reserva de viaje entre una aplicación de reservas de viajes y una aplicación de servicios de viajes. SOAP no especifica como debe determinarse y seguirse tal camino de mensaje. Eso está fuera del alcance de la especificación SOAP. Aunque describir como un nodo SOAP debería comportarse si recibe un mensaje SOAP para el que no es el destinatario último. SOAP Versión 1.2 describe dos tipos de intermediarios: intermediarios redirectores y intermediarios activos.

Un intermediario redirector es un nodo SOAP que, basándose en la semántica de un bloque de encabezado de un mensaje SOAP recibido o basándose en el patrón de intercambio de mensajes en uso, redirige el mensaje SOAP a otro nodo SOAP. Por ejemplo, al procesar un encabezado de "enrutamiento" que describe una característica del camino en un mensaje SOAP de entrada, puede decidir que el mensaje SOAP sea redirigido a otro nodo SOAP identificado por los datos del bloque de encabezado. El formato del encabezado SOAP en el mensaje de salida, es decir, el lugar en el que se inserten o reinserten bloques de encabezado, es determinado por el procesamiento general en en este intermediario redirector basándose en la semántica de los bloques de encabezado procesados.

Un intermediario activo es aquel que realiza procesamiento adicional del mensaje SOAP de entrada antes de redirigir el mensaje utilizando criterios que no están descritos en los bloques de encabezado del mensaje entrante, o por el patrón de intercambio de mensajes en uso. Algunos ejemplos de tal intervención activa en un nodo SOAP podrían ser, por ejemplo, la encriptación de algunas partes del mensaje SOAP y la provisión de información sobre la clave de cifrado en un bloque de encabezado, o la inclusión de información adicional en un nuevo bloque de encabezado en el mensaje de salida que proporcione alguna marca de tiempo o una anotación, por ejemplo, para que sea interpretada de forma apropiada por nodos subsiguientes en el camino.

Un mecanismo por el que un intermediario activo puede describir las modificaciones realizadas en un mensaje es mediante la inserción de bloques de encabezado en el mensaje SOAP de salida. Estos bloques de encabezado pueden informar a los nodos subsiguientes en el camino del mensaje SOAP cuyo papel y correcta operación depende de recibir tal notificación. en este caso, la semántica de tales nodos de encabezado insertados debería también advertir de la (re)inclusión de los mismos u otros bloques de encabezado en los intermediarios subsiguientes según sea necesario para asegurar que el mensaje pueda seguir siendo procesado por otros nodos en el resto del camino. Por ejemplo, si un mensaje con bloques de encabezado eliminados por la encriptación pasa a través de un segundo intermediario (sin que los bloques de encabezado originales sean desencriptados y reconstruidos), entonces la indicación de que la encriptación ha tenido lugar debe retenerse en el segundo mensaje SOAP enviado.

En el siguiente ejemplo, un nodo SOAP se introduce en el camino del mensaje entre las aplicaciones del servicio de viajes y la de reservas, e intercepta el mensaje mostrado en el Ejemplo 1. Un ejemplo de un nodo SOAP así es aquel apunta todas las peticiones de viajes para que sean revisadas off-line por personal de la oficina de la empresa. Observe que los bloques de encabezado reserva y pasajero en aquel mensaje van dirigidos al nodo(s) que asumen el papel "next" que significa que va dirigido al siguiente nodo SOAP en el camino del mensaje que reciba el mensaje. Los bloques de encabezado son obligatorios (el atributo mustUnderstand tiene el valor "true") lo que significa que el nodo debe tener conocimiento de lo que hacer (a través de una especificación externa de la semántica de los bloques de encabezado). Una especificación para la toma de apuntes para tales bloques de encabezado podría simplemente requerir que varios detalles del mensaje fuesen anotados en cada nodo que recibiese el mensaje, y que el mensaje fuese enviado por el camino sin cambios. (Observe que las especificaciones de los bloques de encabezado deben requerir que los mismos bloques de encabezado sean reinsertados en el mensaje saliente, porque de otra manera, el modelo de procesamiento de SOAP requeriría que fuesen eliminados.) En este caso, el nodo SOAP actúa como el intermediario redirector.

Un escenario más complejo es aquel en el que el mensaje SOAP recibido se corrige de alguna manera de algún modo no contemplado por el remitente inicial. En el siguiente ejemplo, se asume que una aplicación empresarial de viajes añade un bloque de encabezado al mensaje del Ejemplo 1 en un nodo intermediario SOAP, antes de reenviarlo por el resto del camino del mensaje hacia la aplicación del servicio de viajes - el destinatario último. El bloque de encabezado contiene restricciones impuestas por una política de viajes para este viaje solicitado. La especificación de tal bloque de encabezado debería requerir que el destinatario último (y sólo el destinatario último, como se implica por la ausencia del atributo role) hiciese uso de la información transportada por él al procesar el cuerpo del mensaje.

El Ejemplo 16 muestra un intermediario activo que inserta un bloque de encabezado adicional, politicaViaje, destinado al destinatario último, que incluye información para permitir el procesamiento a nivel de aplicación de esta petición de viaje.

Example 16

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 
 <env:Header>
  <m:reserva xmlns:m="http://empresaviajes.example.org/reserva" 
          env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
           env:mustUnderstand="true">
   <m:referencia>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:referencia>
   <m:fechaYHora>2001-11-29T13:20:00.000-05:00</m:fechaYHora>
  </m:reserva>
  <n:pasajero xmlns:n="http://miempresa.example.com/empleados"
          env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
           env:mustUnderstand="true">
   <n:nombre>Åke Jógvan Øyvind</n:nombre>
  </n:pasajero>
  <z:politicaViaje
    xmlns:z="http://miempresa.example.com/politicas"
      env:mustUnderstand="true">
   <z:clase>económica</z:clase>
   <z:tipoTarifa>no-reembolsable<z:tipoTarifa>
   <z:excepciones>ninguna</z:excepciones>
  </z:politicaViaje>

 </env:Header>
 <env:Body>
  <p:itinerario
    xmlns:p="http://empresaviajes.example.org/reserva/viaje">
   <p:ida>
     <p:salida>Nueva York</p:salida>
     <p:llegada>Los Angeles</p:llegada>
     <p:fechaSalida>2001-12-14</p:fechaLlegada>
     <p:horaSalida>última hora de la tarde</p:horaSalida>
     <p:preferenciaAsiento>pasillo</p:preferenciaAsiento>
   </p:ida>
   <p:vuelta>
     <p:salida>Los Angeles</p:salida>
     <p:llegada>Nueva York</p:llegada>
     <p:fechaSalida>2001-12-20</p:fechaSalida>
     <p:horaSalida>media-mañana</p:horaSalida>
     <p:preferenciaAsiento/>
   </p:vuelta>
  </p:itinerario>
  <q:alojamiento
   xmlns:q="http://empresaviajes.example.org/reserva/hoteles">
   <q:preferencia>ninguna</q:preferencia>
  </q:alojamiento>
 </env:Body>
</env:Envelope>

Mensaje SOAP del Ejemplo 1 para una reserva de viaje después de que un intermediario activo le haya insertado un encabezado obligatorio dirigido al destinatario último del mensaje

5.2 Utilización de Otros Esquemas de Codificación

Incluso aunque SOAP Versión 1.2 define un esquema particular de codificación (ver la SOAP Parte 2 sección 3), su uso es opcional y la especificación deja claro que otros esquemas de codificación pueden utilizarse para incluir datos específicos de la aplicación en un mensaje SOAP. Con este propósito se facilita el atributo env:encodingStyle


[env:estiloCodificacion]

, del tipo

xs:anyURI
[xs:cualquierURI]

, para calificar bloques de encabezado, cualquier elemento hijo del env:Body SOAP, y cualesquiera elementos hijo del elemento env:Detail [env:Detalle] y sus descendientes. Señala un esquema de serialización para sus contenidos, o al menos el que está en vigor hasta que se encuentre otro elemento que indique que se utiliza un esquema diferente para sus contenidos anidados. La elección del valor del atributo env:encodingStyle es una decisión específica de la aplicación y la habilidad de interoperar se asume que ha sido acordada "fuera-de-banda". Si el atributo no está presente, entonces no puede haber reclamaciones acerca de la codificación que está siendo utilizada.

El uso de un esquema alternativo de codificación se ilustra en el Ejemplo 17. Continuando con el tema de reservas de viajes, este ejemplo muestra un mensaje SOAP que es enviado al pasajero desde el servicio de viajes una vez que se ha confirmado la reserva, mostrando los detalles del viaje. (El mismo mensaje se utilizó en el Ejemplo 8b en otro contexto.)

Example 17

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 
 <env:Header>
  <m:reserva xmlns:m="http://empresaviajes.example.org/reserva" 
       env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
           env:mustUnderstand="true">
   <m:referencia>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:referencia>
   <m:fechaYHora>2001-11-30T16:25:00.000-05:00</m:fechaYHora>
  </m:reserva>
 </env:Header>
 <env:Body>
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
            xmlns:x="http://empresaviajes.example.org/vocab#"
    env:encodingStyle="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
   <x:PeticionReserva 
 rdf:about="http://empresaviajes.example.org/reservas?codigo=FT35ZBQ">
      <x:pasajero>Åke Jógvan Øyvind</x:pasajero>
      <x:ida>
       <x:PeticionViaje>
        <x:hasta>LAX</x:hasta>
        <x:desde>LGA</x:desde>
        <x:fecha>2001-12-14</x:fecha>
       </x:PeticionViaje>
      </x:ida>
      <x:vuelta>
       <x:PeticionViaje>
        <x:hasta>JFK</x:hasta>
        <x:desde>LAX</x:desde>
        <x:fecha>2001-12-20</x:fecha>
       </x:PeticionViaje>
      </x:vuelta>
    </x:PeticionReserva>
  </rdf:RDF>
 </env:Body>
</env:Envelope>

Mensaje SOAP que muestra el uso de una codificación alternativa para el elemento Body

En el Ejemplo 17, el cuerpo del mensaje SOAP contiene una descripción del itinerario usando la codificación de un grafo de recursos y sus propiedades utilizando la sintaxis de Resource Description Framework (RDF) [Infraestructura para la Descripción de Recursos] [RDF]. (Muy brevemente, ya que la sintaxis o el uso de RDF no son tema de este documento, un grafo RDF relaciona recursos - tales como la reserva de viaje disponible en http://empresaviajes.example.org/reservas?codigo=FT35ZBQ - con otros recursos (o valores) a través de propiedades, tales como el pasajero, la fecha de ida y vuelta del viaje. la codificación RDF para el itinerario debería haber sido escogida, por ejemplo, de forma que permitiese a la aplicación de viajes del pasajero almacenarlo en una aplicación capaz de manejar calendarios con propiedades RDF, y entonces podría ser consultado de múltiples formas.)

6. Cambios Entre SOAP 1.1 y SOAP 1.2

SOAP Versión 1.2 tiene un número de cambios en la sintaxis y proporciona semántica adicional (o clarificadora) de la descrita en [SOAP 1.1]. La siguiente es una lista de características en las que ambas especificaciones difieren. El propósito de esta lista es proporcionar al lector un resumen rápido y fácilmente accesible de las diferencias entre las dos especificaciones. Las características han sido puestas en categorías simplemente para facilitar su referencia, y en algunos casos, algún elemento podría haber sido colocado igualmente en otra categoría.

SOAP Parte 1 Apéndice A proporciona reglas de gestión de versiones para un nodo SOAP que pueda soportar la transición de versión de [SOAP 1.1] a SOAP Versión 1.2. En concreto, define un bloque de encabezado env:Upgrade que puede ser utilizado por un nodo SOAP 1.2 al recibir un mensaje [SOAP 1.1], para enviar un mensaje de error SOAP al remitente indicando la versión de SOAP que soporta.

7. Referencias

[SOAP Parte 1] Recomendación W3C "SOAP 1.2 Parte 1: Infraestructura de Mensajes", Martin Gudgin, Marc Hadley, Jean-Jacques Moreau, Henrik Frystyk Nielsen, 24 de Junio 2003 (Ver http://www.w3.org/TR/2003/REC-soap12-part1-20030624/.)

[SOAP Parte 2] Recomendación W3C "SOAP 1.2 Parte 2: Adjuntos", Martin Gudgin, Marc Hadley, Jean-Jacques Moreau, Henrik Frystyk Nielsen, 24 de Junio 2003 (Ver http://www.w3.org/TR/2003/REC-soap12-part2-20030624.)

[RFC 2396] IETF "RFC 2396: Identificadores de Recursos Uniformes (URI): Sintaxis Genérica", T. Berners-Lee, R. Fielding, L. Masinter, Agosto de 1998. (Ver http://www.ietf.org/rfc/rfc2396.txt.)

[HTTP 1.1] IETF "RFC 2616: Protocolo de Transferencia de Hipertexto -- HTTP/1.1", R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, T. Berners-Lee, Enero de 1997. (Ver http://www.ietf.org/rfc/rfc2616.txt.)

[XML 1.0] Recomendación W3C "Lenguaje de Marcas Extensible (XML) 1.0 (Segunda Edición)", Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, 6 de Octubre de 2000. (Ver http://www.w3.org/TR/2000/REC-xml-20001006.

[Espacios de Nombres en XML] Recomendación W3C "Espacios de Nombres en XML", Tim Bray, Dave Hollander, Andrew Layman, 14 de Enero de 1999. (Ver http://www.w3.org/TR/1999/REC-xml-names-19990114/.)

[Esquema XML Parte 1] Recomendación W3C "Esquema XML Parte 1: Estructuras", Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn, 2 de Mayo de 2001. (See http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ )

[Esquema XML Parte 2] Recomendación W3C "Esquema XML Parte 2: Tipos de Datos", Paul V. Biron, Ashok Malhotra, 2 de Mayo 2001. (See http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ )

[SMTP] SMTP se define en una serie de RFCs:

RFC 2822 Formato de Mensaje en Internet. (Ver http://www.ietf.org/rfc/rfc2822.txt.)
RFC 2045 Extensiones Multipropósito al Correo de Internet (MIME) Parte Uno: Formato de los Cuerpos de Mensajes en Internet. (Ver http://www.ietf.org/rfc/rfc2045.txt.)
RFC 2046 Extensiones Multipropósito al Correo de Internet (MIME) Parte Dos: Tipos de Medios. (Ver http://www.ietf.org/rfc/rfc2046.txt.)
RFC 1894 Un Formato de Mensaje Extensible para Notificaciones de Estado de Entrega. (Ver http://www.ietf.org/rfc/rfc1894.txt.)
RFC 2852 Extensión al Servicio de Entrega por SMTP. (Ver http://www.ietf.org/rfc/rfc2852.txt.)
RFC 2298 Un Formato de Mensaje Extensible para Notificaciones de Disposición. (See http://www.ietf.org/rfc/rfc2298.txt.)

[RDF] Recomendación W3C "Especifiación del Modelo y la Sintaxis de la Infraestructura de Descripción de Recursos (RDF)", O. Lassila y R. Swick, Editores. World Wide Web Consortium. 22 de Febrero de 1999. (Ver http://www.w3.org/TR/REC-rdf-syntax.)

[SOAP 1.1] Nota del W3C "Protocolo Simple de Acceso a Objetos (SOAP) 1.1", Don Box et al., 8 de Mayo, 2000 (Ver http://www.w3.org/TR/2000/NOTE-SOAP-20000508/)

[XML Infoset] Recomendación W3C "XML Information Set", John Cowan, Richard Tobin, 24 de Octubre de 2001. (Ver http://www.w3.org/TR/xml-infoset/)

[SOAP MediaType] Borrador IETF "El tipo de medio 'application/soap+xml'", M. Baker, M. Nottingham, "draft-baker-soap-media-reg-03.txt", 29 de Mayo de 2003. (Ver http://www.ietf.org/internet-drafts/draft-baker-soap-media-reg-03.txt, obsérvese que este Borrador expira en Noviembre de 2003)

[SOAP Email Binding] Nota W3C "SOAP Versión 1.2 Vínculo con el Correo Electrónico", Highland Mary Mountain et al, borrador de 13 de Junio de 2002. (Ver http://www.w3.org/TR/2002/NOTE-soap12-email-20020626.)

[XML Base] Recomendación W3C "XML Base", Jonathan Marsh, 27 de Junio de 2001. (Ver http://www.w3.org/TR/2001/REC-xmlbase-20010627/)

[RFC 2119] IETF "RFC 2119: Palabras clave para utilizar en RFCs indicando los Niveles de Requisito", S. Bradner, Marzo de 1997. (Ver http://www.ietf.org/rfc/rfc2119.txt.)

A. Reconocimientos

Highland Mary Mountain (Intel) proporcionó el material inicial para la sección sobre el vínculo SMTP. Paul Denning proporcionó material para un escenario de uso, que ha sido desde entonces trasladado al Borrador de Trabajo de Escenarios de Uso de SOAP Versión 1.2. Stuart Williams, Oisin Hurley, Chris Ferris, Lynne Thompson, John Ibbotson, Marc Hadley, Yin-Leng Husband y Jean-Jacques Moreau facilitaron comentarios detallados sobre versiones previas de este documento, así como hicieron muchos otros durante la revisión de la Última Llamada del Borrador de Trabajo. Jacek Kopecky facilitó una lista de los cambios en la codificación de RPC y SOAP.

Este documento es el trabajo del Grupo de Trabajo sobre el Protocolo XML del W3C.

Los participantes en el Grupo de Trabajo son (en el momento de escribir, y por órden alfabético): Carine Bournez (W3C), Michael Champion (Software AG), Glen Daniels (Macromedia, anteriormente de Allaire), David Fallside (IBM, Chair), Dietmar Gaertner (Software AG), Tony Graham (Sun Microsystems), Martin Gudgin (Microsoft Corporation, anteriormente de DevelopMentor), Marc Hadley (Sun Microsystems), Gerd Hoelzing (SAP AG), Oisin Hurley (IONA Technologies), John Ibbotson (IBM), Ryuji Inoue (Matsushita Electric), Kazunori Iwasa (Fujitsu Limited), Mario Jeckle (DaimlerChrysler R. & Tech), Mark Jones (AT&T), Anish Karmarkar (Oracle), Jacek Kopecky (Systinet/Idoox), Yves Lafon (W3C), Michah Lerner (AT&T), Noah Mendelsohn (IBM, anteriormente de Lotus Development), Jeff Mischkinsky (Oracle), Nilo Mitra (Ericsson), Jean-Jacques Moreau (Canon), Masahiko Narita (Fujitsu Limited), Eric Newcomer (IONA Technologies), Mark Nottingham (BEA Systems, anteriormente de Akamai Technologies), David Orchard (BEA Systems, anteriormente de Jamcracker), Andreas Riegg (DaimlerChrysler R. & Tech), Hervé Ruellan (Canon), Jeff Schlimmer (Microsoft Corporation), Miroslav Simek (Systinet/Idoox), Pete Wenzel (SeeBeyond), Volker Wiechers (SAP AG).

Participantes anteriores fueron: Yasser alSafadi (Philips Research), Bill Anderson (Xerox), Vidur Apparao (Netscape), Camilo Arbelaez (WebMethods), Mark Baker (Idokorro Mobile (Planetfred), anteriormente de Sun Microsystems), Philippe Bedu (EDF (Electricité de France)), Olivier Boudeville (EDF (Electricité de France)), Don Box (Microsoft Corporation, anteriormente de DevelopMentor), Tom Breuel (Xerox), Dick Brooks (Group 8760), Winston Bumpus (Novell), David Burdett (Commerce One), Charles Campbell (Informix Software), Alex Ceponkus (Bowstreet), David Chappell (Sonic Software), Miles Chaston (Epicentric), David Clay (Oracle), David Cleary (Progress Software), Conleth O'Connell (Vignette), Ugo Corda (Xerox), Paul Cotton (Microsoft Corporation), Fransisco Cubera (IBM), Jim d'Augustine (eXcelon), Ron Daniel (Interwoven), Dug Davis (IBM), Ray Denenberg (Library of Congress), Paul Denning (MITRE), Frank DeRose (Tibco), Mike Dierken (DataChannel), Andrew Eisenberg (Progress Software), Brian Eisenberg (DataChannel), Colleen Evans (Sonic Software), John Evdemon (XMLSolutions), David Ezell (Hewlett-Packard), Eric Fedok (Active Data Exchange), Chris Ferris (Sun Microsystems), Daniela Florescu (Propel), Dan Frantz (BEA Systems), Michael Freeman (Engenia Software), Scott Golubock (Epicentric), Rich Greenfield (Library of Congress), Hugo Haas (W3C), Mark Hale (Interwoven), Randy Hall (Intel), Bjoern Heckel (Epicentric), Erin Hoffman (Tradia), Steve Hole (MessagingDirect Ltd.), Mary Holstege (Calico Commerce), Jim Hughes (Fujitsu Software Corporation), Yin-Leng Husband (Hewlett-Packard, anteriormente de Compaq), Scott Isaacson (Novell), Murali Janakiraman (Rogue Wave), Eric Jenkins (Engenia Software), Jay Kasi (Commerce One), Jeffrey Kay (Engenia Software), Richard Koo (Vitria Technology Inc.), Alan Kropp (Epicentric), Julian Kumar (Epicentric), Peter Lecuyer (Progress Software), Tony Lee (Vitria Technology Inc.), Amy Lewis (TIBCO), Bob Lojek (Intalio), Henry Lowe (OMG), Brad Lund (Intel), Matthew MacKenzie (XMLGlobal Technologies), Murray Maloney (Commerce One), Richard Martin (Active Data Exchange), Highland Mary Mountain (Intel), Alex Milowski (Lexica), Kevin Mitchell (XMLSolutions), Ed Mooney (Sun Microsystems), Dean Moses (Epicentric), Don Mullen (TIBCO), Rekha Nagarajan (Calico Commerce), Raj Nair (Cisco), Mark Needleman (Data Research Associates), Art Nevarez (Novell), Henrik Nielsen (Microsoft Corporation), Kevin Perkins (Compaq), Jags Ramnaryan (BEA Systems), Vilhelm Rosenqvist (NCR), Marwan Sabbouh (MITRE), Waqar Sadiq (Vitria Technology Inc.), Rich Salz (Zolera), Krishna Sankar (Cisco), George Scott (Tradia), Shane Sesta (Active Data Exchange), Lew Shannon (NCR), John-Paul Sicotte (MessagingDirect Ltd.), Simeon Simeonov (Allaire), Simeon Simeonov (Macromedia), Aaron Skonnard (DevelopMentor), Nick Smilonich (Unisys), Soumitro Tagore (Informix Software), James Tauber (Bowstreet), Lynne Thompson (Unisys), Patrick Thompson (Rogue Wave), Jim Trezzo (Oracle), Asir Vedamuthu (WebMethods), Randy Waldrop (WebMethods), Fred Waskiewicz (OMG), David Webber (XMLGlobal Technologies), Ray Whitmer (Netscape), Stuart Williams (Hewlett-Packard), Yan Xu (DataChannel), Amr Yassin (Philips Research), Susan Yee (Active Data Exchange), Jin Yu (Martsoft).

También deseamos agradecer a toda la gente que ha contribuido a las discusiones en xml-dist-app@w3.org.

Nodo	intermediario	destinatario final
mustUnderstand
"true"	debe procesarlo	debe procesarlo
"false"	debe procesarlo	debe procesarlo
ausente	debe procesarlo	debe procesarlo

Rol	ausente	"none"	"next"	"ultimateReceiver"
Nodo
remitente inicial	no aplicable	no aplicable	no aplicable	no aplicable
intermediario	no	no	sí	no
destinatario final	sí	no	sí	sí