Web Services Addressing 1.0

1. Introducción

La especificación Web Services Addressing 1.0 - Core (WS-Addressing) define dos entidades (las propiedades de direccionamiento de mensajes y las referencias de extremo) que normalizan la información que normalmente proporcionan los protocolos de transporte y los sistemas de mensajería, independientemente de cualquier sistema de transporte o de mensajería específico.

Un extremo de un servicio web es una entidad, un procesador o un recurso (referenciables) a los cuales pueden remitirse mensajes correspondientes al servicio web. Las referencias de extremo transmiten la información que se necesita para direccionar un extremo de un servicio web. Obsérvese que WSDL 2.0 incluye un componente Endpoint [WSDL 2.0 Core Language, Sección 2.15 Endpoint] que, junto con otros componentes de WSDL 2.0, se puede usar para describir el extremo de un servicio web. De hecho, un extremo de un servicio web puede tener más de una de esas descripciones. Asimismo, para transmitir la información necesaria para direccionar un extremo específico de un servicio web se pueden usar varias referencias de extremo. El propósito de una referencia de extremo es transmitir la información necesaria para direccionar un extremo de un servicio web, mientras que las descripciones WSDL 2.0 están diseñadas para describir un servicio web.

Esta especificación define una familia de propiedades de direccionamiento de mensajes capaces de transportar características de los mensajes de un extremo a otro, incluidas las referencias para los extremos de origen y de destino y la identidad del mensaje, lo cual permite un modo uniforme de direccionamiento de los mensajes independientemente de la capa de transporte subyacente.

El diseño de ambas entidades admite su extensión y reutilización, de modo que otras especificaciones puedan aprovechar las referencias de extremo y las propiedades de direccionamiento de mensajes y reelaborarlas.

El ejemplo siguiente ilustra el uso de estos mecanismos en un mensaje SOAP 1.2 que se envía de http://example.com/business/client1 a http://example.com/fabrikam/Purchasing (en el enlace Web Services Addressing 1.0 - SOAP [Enlace WS-Addressing SOAP] encontrará más información sobre el uso de WS-Addressing en SOAP):

Ejemplo 1.1. Uso de propiedades de direccionamiento de mensajes en un mensaje SOAP 1.2.

(01) <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"      
                xmlns:wsa="http://www.w3.org/2005/08/addressing">
(02)   <S:Header>
(03)    <wsa:MessageID>http://example.com/6B29FC40-CA47-1067-B31D-00DD010662DA</wsa:MessageID>
(04)    <wsa:ReplyTo>
(05)      <wsa:Address>http://example.com/business/client1</wsa:Address>
(06)    </wsa:ReplyTo>
(07)    <wsa:To>http://example.com/fabrikam/Purchasing</wsa:To>
(08)    <wsa:Action>http://example.com/fabrikam/SubmitPO</wsa:Action>
(09)   </S:Header>
(10)   <S:Body>
(11)     ...
(12)   </S:Body>
(13) </S:Envelope>

Las líneas (02) a (09) representan la cabecera del mensaje SOAP, donde se utilizan los mecanismos definidos en la especificación. El cuerpo está representado por las líneas (10) a (12).

Las líneas (03) a (08) contienen los bloques de cabecera de direccionamiento de mensaje. En concreto, la línea (02) especifica el identificador del mensaje y las líneas (04) a (06) especifican, en la forma de una referencia de extremo, el extremo al cual se deberían enviar las respuestas a este mensaje. La línea (07) especifica la dirección URI del receptor final del mensaje. La línea (08) especifica un URI de acción que identifica la semántica esperada.

1.1 Convenciones de notación

Las palabras clave "DEBE" ("MUST"), "NO DEBE" ("MUST NOT"), "OBLIGATORIO" ("REQUIRED"), "DEBERÁ" ("SHALL"), "NO DEBERÁ" ("SHALL NOT"), "DEBERÍA" ("SHOULD"), "NO DEBERÍA" ("SHOULD NOT"), "RECOMENDADO" ("RECOMMENDED"), "PUEDE" ("MAY") y "OPCIONAL" ("OPTIONAL") en esta especificación deben interpretarse según se describe en RFC 2119 [IETF RFC 2119].

Para describir modelos de datos abstractos, esta especificación emplea la convención de notación usada por el conjunto de información XML [Conjunto de información XML]. En concreto, los nombres de propiedades abstractas aparecerán siempre entre corchetes (por ej., [una propiedad]).

Para la descripción de esquemas XML concretos [Estructuras de esquemas XML, Tipos de datos de esquemas XML], esta especificación emplea la convención de notación de WS-Security [WS-Security 2004]. En concreto, cada miembro de la propiedad [children] (hijos) o [attributes] (atributos) de un ítem de información de elemento se describe con una notación de tipo XPath (por ej., /x:LaCabecera/x:UnaPropiedad/@valor1). El uso de {any} (cualquiera) indica la presencia de un comodín de elemento (<xs:any/>). El uso de @{any} indica la presencia de un comodín de atributo (<xs:anyAttribute/>).

Cuando se indiquen seudoesquemas para un componente, se usarán convenciones del estilo de BNF para los atributos y los elementos: "?" indica una parte opcional (es decir, cero o una apariciones), "*" indica cero o más apariciones, "+" una o más apariciones, "[" and "]" ("y") se emplea para crear grupos y "|" representa una alternativa. A los atributos se les asigna convencionalmente un valor que se corresponde con su tipo, según se define en el esquema normativo. A los elementos con contenido simple se les asigna convencionalmente un valor que se corresponde con el tipo de su contenido, según se define en el esquema normativo. Para mayor concisión, los seudoesquemas no incluyen puntos de extensibilidad.

Para definir la cardinalidad de las propiedades de referencia de extremo y de direccionamiento de mensajes, esta especificación emplea la notación siguiente: (n..m), donde n es la cantidad mínima permitida de apariciones de la propiedad y m es la cantidad máxima permitida. Cuando n tiene el mismo valor que m entonces la propiedad debe aparecer exactamente esa cantidad de veces en la referencia de extremo o el mensaje asociados.

1.2 Espacios de nombres

A lo largo de esta especificación se emplean diversos prefijos de espacio de nombres, que se indican en el Cuadro 1.1. Obsérvese que la elección de un prefijo de espacio de nombres cualquiera es arbitraria y no es significativa desde un punto de vista semántico (véase [Espacios de nombres XML]).

Cuadro 1.1. Prefijos y espacios de nombres usados en esta especificación
Prefijo	Espacio de nombres
wsa	http://www.w3.org/2005/08/addressing
S	http://www.w3.org/2003/05/soap-envelope
xs	http://www.w3.org/2001/XMLSchema

WS-Addressing se puede usar con SOAP [Infraestructura de mensajería SOAP 1.2, SOAP 1.1] según se describe en el enlace de Web Services Addressing 1.0 con SOAP [Enlace WS-Addressing SOAP]. WS-Addressing se puede usar con WSDL [WSDL 2.0 Core Language, WSDL 1.1] según se describe en el enlace de Web Services Addressing 1.0 con WSDL [Enlace WS-Addressing WSDL]. Los ejemplos que se incluyen en esta especificación emplean una representación XML 1.0 [XML 1.0], pero esto no es obligatorio.

Todos los ítems de información definidos por esta especificación están identificados por el URI de espacio de nombres XML [Espacios de nombres XML] http://www.w3.org/2005/08/addressing. Resolviendo la referencia del URI de espacio de nombres XML se puede obtener un documento normativo para el esquema XML [Estructuras de esquemas XML , Tipos de datos de esquemas XML].

2. Referencias de extremo

En esta sección se definen el modelo de información y la sintaxis de las referencias de extremo.

Esta especificación introduce una entidad llamada referencia de extremo, cuyo diseño tiene en vista los siguientes usos posibles:

Generación dinámica y personalización de descripciones de extremos de servicios.

Referenciamiento y descripción de instancias concretas de servicios que se crean como resultado de interacciones con estado.

Intercambio flexible y dinámico de información sobre los extremos, en entornos estrechamente interconectados donde las partes que se comunican comparten un conjunto de supuestos comunes sobre las políticas o protocolos específicos que se emplean durante la interacción.

2.1 Modelo de información de las referencias de extremo

Una referencia de extremo es una colección de propiedades abstractas. Esta especificación define un conjunto básico de propiedades, pero otras especificaciones pueden extender estas propiedades y/o añadir otras. La semántica y la representación como conjunto de información XML de todas esas propiedades de extensión se describirán en las especificaciones que las definan. Una referencia de extremo está formada por las siguientes propiedades abstractas:

[address]: IRI (1..1)

Un IRI absoluto [IETF RFC 3987] que representa la dirección del extremo. Esta especificación introduce dos valores predefinidos para [address], que se indican en el Cuadro 2.1.

Cuadro 2.1. Valores predefinidos para [address]
URI	Descripción
"http://www.w3.org/2005/08/addressing/anonymous"	Puesto que algunos extremos no admiten su localización mediante un IRI significativo, en esos casos se emplea este URI para permitir a esos extremos enviar y recibir mensajes. El significado preciso de este URI lo definirán el enlace de esta especificación de direccionamiento con un protocolo concreto y/o el contexto en el que se use la referencia de extremo.
"http://www.w3.org/2005/08/addressing/none"	Los mensajes enviados a referencias de extremo cuya propiedad [address] tenga este valor DEBEN descartarse (es decir, no se deben enviar). Este URI normalmente se emplea en referencias de extremo que designan un extremo de respuesta o de error (véase la sección 3.1 Definición de propiedades abstractas) para indicar que no se debería enviar un mensaje de respuesta o de error.

[reference parameters]: xs:any (0..ilimitado).

Una referencia puede contener una cierta cantidad de parámetros individuales que están asociados con el extremo para facilitar una interacción específica. Los parámetros de las referencias son ítems de información con cualificación de espacio de nombres, cuya presencia es obligatoria para lograr una interacción adecuada con el extremo. Los parámetros de las referencias los suministra el emisor de la referencia de extremo y se supone que son opacos en relación con los otros usuarios de la referencia de extremo. El enlace de los parámetros de referencias con los mensajes depende del enlace de protocolo empleado para interactuar con el extremo; el enlace Web Services Addressing 1.0 - SOAP [Enlace WS-Addressing SOAP] describe el enlace predeterminado para el protocolo SOAP.

Los parámetros de las referencias no están ordenados. No se le puede atribuir significado alguno al orden en que aparezcan, ya que puede que su enlace con un mensaje no preserve dicho orden.

[metadata]: xs:any (0..ilimitado)

Una referencia puede contener metadatos que describan el comportamiento, las políticas y las capacidades del extremo. En una referencia de extremo se pueden incluir metadatos para facilitar el procesamiento por parte del usuario de la referencia de extremo o porque los metadatos se generaron dinámicamente.

Los metadatos incluidos en una referencia de extremo no enuncian necesariamente todos los metadatos correspondientes al extremo. Además, aunque los metadatos incluidos en la referencia de extremo sean necesariamente válidos en el momento inicial de la creación de la referencia de extremo, pueden caducar en un momento posterior.

Para resolver los conflictos que surjan entre los metadatos incluidos en dos referencias de extremo con la misma propiedad [address] o entre los metadatos incluidos en una referencia y los metadatos obtenidos de otra fuente, o para determinar la validez actual de los metadatos incluidos en una referencia, se DEBERÍAN emplear mecanismos que exceden el alcance de esta especificación, tales como información sobre el ciclo de vida de la referencia de extremo (véase 2.4 Ciclo de vida de las referencias de extremo) o recuperación de los metadatos de una fuente oficial.

2.2 Representación de la referencia de extremo como conjunto de información XML

En esta sección se define una representación de las referencias de extremo en dos formas basadas en conjuntos de información XML: como un tipo XML (wsa:EndpointReferenceType) y como un elemento XML (<wsa:EndpointReference>). Para mayor concisión, se empleará la terminología de XML (por ejemplo, "elemento" en vez de "ítem de información de elemento"), pero no se pretende con esto limitar el uso de las entidades definidas en esta sección a su representación en XML textual.

El tipo wsa:EndpointReferenceType se emplea siempre que se hace referencia al extremo de un servicio web. Se describe a continuación el contenido de este tipo:

<wsa:EndpointReference>
    <wsa:Address>xs:anyURI</wsa:Address>
    <wsa:ReferenceParameters>xs:any*</wsa:ReferenceParameters> ?
    <wsa:Metadata>xs:any*</wsa:Metadata>?
</wsa:EndpointReference>

Se describen a continuación los atributos y los elementos incluidos en el resumen del esquema anterior:

/wsa:EndpointReference: Esto representa un elemento de tipo wsa:EndpointReferenceType. En este ejemplo se emplea el elemento predefinido <wsa:EndpointReference>, pero se puede usar cualquier elemento del tipo wsa:EndpointReferenceType.
/wsa:EndpointReference/wsa:Address: Este elemento OBLIGATORIO (cuyo contenido es de tipo xs:anyURI) indica la propiedad [address] de la referencia de extremo.
/wsa:EndpointReference/wsa:Address/@{any}: Esto es un mecanismo de extensibilidad que permite indicar atributos adicionales.
/wsa:EndpointReference/wsa:ReferenceParameters: Este elemento OPCIONAL puede contener elementos pertenecientes a cualquier espacio de nombres, que forman la propiedad [reference parameters] de la referencia.
/wsa:EndpointReference/wsa:ReferenceParameters/@{any}: Esto es un mecanismo de extensibilidad que permite indicar atributos adicionales.
/wsa:EndpointReference/wsa:ReferenceParameters/{any}: Cada ítem de información de elemento incluido en la propiedad [reference parameters] (entre ellos, todos los elementos en [children], [attributes] e [in-scope namespaces]) se representa tal cual es.
/wsa:EndpointReference/wsa:Metadata: Este elemento OPCIONAL puede contener elementos pertenecientes a cualquier espacio de nombres, que forman los metadatos pertinentes a la interacción con el extremo.
/wsa:EndpointReference/wsa:Metadata/{any}: Cada elemento hijo de Metadata representa un componente individual de los metadatos.
/wsa:EndpointReference/wsa:Metadata/{@any}: Esto es un mecanismo de extensibilidad que permite indicar atributos adicionales. Algunos ejemplos incluidos en esta especificación emplean este mecanismo de extensibilidad para incluir un atributo wsdlLocation [WSDL 2.0 Core Language] cuyo objetivo es indicar el lugar donde puede hallarse una descripción WSDL del servicio implementado en el extremo.
/wsa:EndpointReference/{any}: Esto es un mecanismo de extensibilidad que permite indicar elementos adicionales.
/wsa:EndpointReference/@{any}: Esto es un mecanismo de extensibilidad que permite indicar atributos adicionales.

Observación:

Los efectos que puedan tener sobre las propiedades abstractas los elementos o atributos añadidos al modelo indicado anteriormente se explicarán en las especificaciones que describan dichas extensiones. Pueden resultar afectadas tanto las propiedades básicas como las añadidas, según se define en 2.1 Modelo de información de las referencias de extremo.

A continuación, se muestra un ejemplo de referencia de extremo, que hace referencia al extremo situado en el URI "http://example.com/fabrikam/acct".

Ejemplo 2.1. Ejemplo de referencia de extremo.

<wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing">
   <wsa:Address>http://example.com/fabrikam/acct</wsa:Address>
</wsa:EndpointReference>

2.3 Comparaciones entre referencias de extremo

Puesto que esta especificación no define ningún concepto de identidad entre extremos, tampoco ofrece mecanismos para determinar la igualdad o desigualdad de dichas referencias ni indica las consecuencias que puedan derivarse de su igualdad o desigualdad. Sin embargo, obsérvese que otras especificaciones pueden ofrecer una función de comparación que sea aplicable dentro de un ámbito limitado.

2.4 Ciclo de vida de las referencias de extremo

Esta especificación no define un modelo de ciclo de vida para las referencias de extremo y no se ocupa de la cuestión de su tiempo de vida. Otras especificaciones que se basen en la especificación WS-Addressing o la empleen pueden definir un modelo de ciclo de vida para las referencias de extremo creadas según esas especificaciones.

2.5 Extensibilidad de las referencias de extremo

Como se ha señalado en 2.2 Representación de la referencia de extremo como conjunto de información XML, las referencias de extremo son extensibles. Cuando una referencia de extremo incluya atributos o elementos de extensión, el modelo de procesamiento de dichas extensiones será el definido por su correspondiente especificación. El software que procesa las referencias de extremo puede ignorar con total seguridad todas las extensiones que no reconozca o comprenda.

Los elementos y atributos de extensión PUEDEN añadir a las referencias de extremo propiedades adicionales además de las indicadas en 2.1 Modelo de información de las referencias de extremo. Las extensiones de las referencias de extremo PUEDEN modificar el valor de una o más de las propiedades existentes de una referencia de extremo. Las extensiones PUEDEN modificar las reglas para el enlace de las propiedades de las referencias de extremo con las propiedades de direccionamiento de los mensajes o indicar de algún otro modo el uso de un enlace diferente.

Obsérvese que la capacidad de modificar las propiedades existentes y el comportamiento del enlace, combinada con la posibilidad del software de ignorar las extensiones desconocidas o no reconocidas, puede dar lugar a un comportamiento diferente cuando la misma referencia de extremo extendida sea procesada por un software que sí entienda dichas extensiones. Los diseñadores de extensiones de las referencias de extremo deberían considerar que en aquellos casos en que sus extensiones no sean reconocidas o comprendidas, prevalecerá el procesamiento normal indicado por esta especificación.

2.6 Identificación de recursos en una referencia de extremo

En Architecture of the World Wide Web, Volumen Uno, [AoWWW] se recomienda [AoWWW, Sección 2] identificar los recursos mediante URI. El empleo de otras propiedades abstractas de una referencia de extremo aparte de [destination] para identificar recursos es contrario a esta recomendación. En algunas circunstancias, el uso de propiedades adicionales puede ser conveniente o beneficioso; sin embargo, en la construcción de los sistemas se deberían sopesar cuidadosamente los beneficios o la conveniencia de usar parámetros de las referencias para identificar los recursos y compararlos con los beneficios de hacerlo exclusivamente mediante URI, como se explica en [AoWWW, Sección 2.1] de la recomendación indicada.

3. Propiedades de direccionamiento de mensajes

En esta sección se define el modelo de información y la sintaxis de las propiedades de direccionamiento de mensajes.

Las propiedades de direccionamiento de mensajes proveen de referencias para los extremos involucrados en una interacción. En general, el uso de estas propiedades en el contexto de interacciones específicas se define tanto por la semántica de las propiedades mismas como por el contrato implícito o explícito del que depende el intercambio de mensajes. Cuando este contrato es explícito, puede adoptar formas diferentes, entre ellas pautas de intercambio de mensajes de WSDL, interfaces y otras; también pueden definirse contratos explícitos entre las partes mediante procesos de negocios y especificaciones de comercio electrónico.

En una pauta de interacción unidireccional, una fuente envía un mensaje a un destino, y la definición de la interacción termina allí. Otra pauta de interacción común es la de "petición-respuesta", donde un extremo fuente envía un mensaje inicial (la petición) y el destino reenvía a la fuente un mensaje subsiguiente (la respuesta). En este caso, la respuesta puede ser un mensaje de aplicación, un error o cualquier otro mensaje. Pero cabe señalar que también pueden enviarse mensajes de respuesta como parte de otros intercambios de mensajes y que el envío de respuestas no se limita a la pauta usual "una petición, una respuesta" o a determinadas operaciones primitivas de transmisión o pautas de intercambio de mensajes particulares de WSDL. El contrato entre las partes que interactúan puede indicar el envío de más de una respuesta, e incluso de un número variable de respuestas.

El conjunto de propiedades de direccionamiento de mensajes que se define en esta especificación es suficiente para muchas variantes sencillas de las pautas de intercambio de mensajes unidireccional y de petición-respuesta. Otras pautas más avanzadas pueden requerir propiedades de direccionamiento de mensajes adicionales que amplíen las posibilidades provistas por esta especificación.

3.1 Definición de propiedades abstractas

Las propiedades de direccionamiento de mensajes en conjunto amplían un mensaje con las siguientes propiedades abstractas, en función de pautas de interacción unidireccional, de petición-respuesta y otras:

[destination]: IRI (1..1)

Un IRI absoluto que representa la dirección del receptor al que esta destinado este mensaje.

[source endpoint]: referencia de extremo (0..1)

Referencia del extremo fuente en el cual se originó el mensaje.

[reply endpoint]: referencia de extremo (0..1)

Referencia al extremo al cual deben enviarse las respuestas a este mensaje.

[fault endpoint]: referencia de extremo (0..1)

Referencia de extremo para el receptor al que deben enviarse los errores relacionados con este mensaje.

[action]: IRI (1..1)

Un IRI absoluto que identifica unívocamente la semántica implicada por este mensaje.

Se RECOMIENDA que el valor de la propiedad [action] sea un IRI que identifique una entrada, una salida o un mensaje de error dentro de una interfaz o un tipo de puerto de WSDL. Una acción puede estar asociada explícita o implícitamente con la definición WSDL correspondiente. En el enlace Web Services Addressing 1.0 - WSDL [Enlace WS-Addressing WSDL] se describen los mecanismos de asociación.

[message id]: IRI (0..1)

Un IRI absoluto que identifica unívocamente el mensaje. Cuando esta propiedad está presente, es responsabilidad del emisor asegurarse de que cada mensaje esté identificado unívocamente. Esta especificación no impone ningún comportamiento específico al receptor cuando éste recibe un mensaje con el mismo valor para la propiedad [message id] que un mensaje recibido con anterioridad.

[relationship]: (IRI, IRI) (0..ilimitado)

Un par de valores que indican la relación de este mensaje con otro mensaje. El tipo de la relación se identifica mediante un IRI absoluto. El mensaje relacionado se identifica mediante un IRI absoluto que se corresponde con su propiedad [message id]. El IRI que identifica el mensaje puede referirse a un mensaje específico o, en su defecto, puede ser el URI predefinido que se indica a continuación, cuyo significado es "mensaje no especificado": "http://www.w3.org/2005/08/addressing/unspecified".

Esta especificación tiene un tipo de relación predefinido que se indica en el Cuadro 3.1.

Cuadro 3.1. Valores predefinidos para [relationship]
URI	Descripción
"http://www.w3.org/2005/08/addressing/reply"	Indica que este mensaje es una respuesta al mensaje identificado por el IRI [message id].

[reference parameters]: xs:any (0..ilimitado).

Corresponde al valor de la propiedad [reference parameters] de la referencia de extremo a la cual se dirige el mensaje.

Las propiedades [destination] y [action] indican la ubicación de procesamiento de destino y la acción o el propósito del mensaje, respectivamente. Los valores de estas propiedades pueden usarse para facilitar el despacho de los mensajes.

Un enlace de las propiedades de direccionamiento de mensajes de WS-Addressing DEBE reflejar la cardinalidad mostrada anteriormente para la propiedad. El enlace Web Services Addressing 1.0 - SOAP [Enlace WS-Addressing SOAP] define un enlace para el protocolo SOAP [Infraestructura de mensajería SOAP 1.2, SOAP 1.1].

3.2 Representación de las propiedades de direccionamiento de mensajes como conjunto de información XML

A continuación se muestra la representación como conjunto de información XML de las propiedades de direccionamiento de mensajes definidas en 3.1 Definición de propiedades abstractas:

<wsa:To>xs:anyURI</wsa:To> ?
<wsa:From>wsa:EndpointReferenceType</wsa:From> ?
<wsa:ReplyTo>wsa:EndpointReferenceType</wsa:ReplyTo> ?
<wsa:FaultTo>wsa:EndpointReferenceType</wsa:FaultTo> ?
<wsa:Action>xs:anyURI</wsa:Action>
<wsa:MessageID>xs:anyURI</wsa:MessageID> ?
<wsa:RelatesTo RelationshipType="xs:anyURI"?>xs:anyURI</wsa:RelatesTo> *
<wsa:ReferenceParameters>xs:any*</wsa:ReferenceParameters> ?

Se describen a continuación los atributos y los elementos incluidos en el resumen del esquema anterior:

/wsa:To: Este elemento OPCIONAL (cuyo contenido es del tipo xs:anyURI) proporciona el valor para la propiedad [destination]. Si este elemento NO está presente, entonces el valor de la propiedad [destination] será "http://www.w3.org/2005/08/addressing/anonymous".
/wsa:From: Este elemento OPCIONAL (de tipo wsa:EndpointReferenceType) proporciona el valor para la propiedad [source endpoint].
/wsa:ReplyTo: Este elemento OPCIONAL (de tipo wsa:EndpointReferenceType) proporciona el valor para la propiedad [reply endpoint]. Si este elemento NO está presente, entonces el valor de la propiedad [address] de la referencia de extremo [reply endpoint] será "http://www.w3.org/2005/08/addressing/anonymous".
/wsa:FaultTo: Este elemento OPCIONAL (de tipo wsa:EndpointReferenceType) proporciona el valor para la propiedad [fault endpoint].
/wsa:Action: Este elemento OBLIGATORIO (de tipo xs:anyURI) proporciona el valor para la propiedad [action].
/wsa:MessageID: Este elemento OPCIONAL (cuyo contenido es del tipo xs:anyURI) transmite la propiedad [message id].
/wsa:RelatesTo: Este ítem de información de elemento (repetido) OPCIONAL aporta un valor de propiedad abstracta [relationship], en la forma de un par (IRI, IRI). El contenido de este elemento OPCIONAL (de tipo xs:anyURI) transmite la propiedad [message id] del mensaje relacionado.
/wsa:RelatesTo/@RelationshipType: Este atributo OPCIONAL (de tipo xs:anyURI) transmite el tipo de relación como un IRI. Si no está presente, el valor implícito de este atributo será "http://www.w3.org/2005/08/addressing/reply".
/[reference parameters]*: Cada ítem de información de elemento incluido en [reference parameters] (entre ellos, todos los elementos en [children], [attributes] e [in-scope namespaces]) se representa tal cual es.

Obsérvese que por razones de futura extensibilidad, cada uno de los ítems de información de elemento descritos anteriormente permite comodines de atributos. Un procesador de mensajes puede ignorar con total seguridad todos los atributos de extensión que no reconozca. La extensibilidad de atributos permite usar xml:id[xml:id] para la identificación de estos elementos, si así se desea.

3.2.1 Comparación de IRI

Los valores de las propiedades de direccionamiento de mensajes [action], [message id] y [relationship] son IRI absolutos. El propósito principal de estos IRI es la identificación, no la recuperación de recursos. Por ello, para determinar la equivalencia de estos IRI basta la simple comparación de cadenas, según se indica en Internationalized Resource Identifiers IETF RFC 3987 sección 5.3.1.

La comparación de los valores de la propiedad [destination] excede el alcance de esta especificación, excepto por el uso de la comparación simple de cadenas para detectar la presencia de un valor anónimo, es decir, si el valor de [destination] es "http://www.w3.org/2005/08/addressing/anonymous".

3.3 Envío de un mensaje a una referencia de extremo

En esta sección se describe el proceso de construcción de un mensaje que sea adecuado para una referencia de extremo.

Si la propiedad [address] de la referencia de extremo es "http://www.w3.org/2005/08/addressing/none" se descartará el mensaje; de lo contrario, se llenarán las propiedades de direccionamiento de mensaje:
- [action]: esta propiedad es obligatoria, pero su valor no se obtiene de la referencia de extremo.
- [destination]: para esta propiedad se copia el valor de la propiedad [address] de la referencia de extremo.
- [reference parameters]: para esta propiedad se copia el valor de la propiedad [reference parameters] de la referencia de extremo seleccionada.

3.4 Creación de mensajes de respuesta

Esta sección especifica las reglas específicas de WS-Addressing para la creación de un mensaje de respuesta o de error en relación con otro mensaje.

Seleccionar la referencia de extremo que corresponda:
- Si la respuesta es un mensaje normal, seleccione la referencia de extremo a partir de la propiedad de direccionamiento de mensaje [reply endpoint] del mensaje relacionado.
  
  Observación:
  
  La propiedad de direccionamiento de mensaje [reply endpoint] siempre estará presente cuando se use la representación como conjunto de información XML, puesto que en caso de no haber un elemento wsa:ReplyTo, la propiedad [reply endpoint] adopta como valor predeterminado una referencia de extremo cuya propiedad [address] es "http://www.w3.org/2005/08/addressing/anonymous" (véase la sección 3.2 Representación de las propiedades de direccionamiento de mensajes como conjunto de información XML).
  
  Si la propiedad de direccionamiento de mensaje [reply endpoint] no está presente, el procesador DEBE generar un error. Esto sólo puede ocurrir cuando se use otra representación para las propiedades de direccionamiento de mensajes.
- De lo contrario, si la respuesta es un mensaje de error y la propiedad de direccionamiento de mensaje [fault endpoint] del mensaje relacionado no está vacía, seleccione la referencia de extremo a partir de dicha propiedad. Si la propiedad [fault endpoint] está vacía, seleccione la referencia de extremo a partir de la propiedad de direccionamiento de mensaje [reply endpoint] del mensaje relacionado. De lo contrario, si la propiedad [reply endpoint] está vacía, esta especificación no impondrá ningún comportamiento específico al receptor del mensaje relacionado.
- En cualquiera de los casos anteriores, si el mensaje relacionado no tiene propiedad [message id], el procesador DEBE generar un error.
Envíe el mensaje según se describe en la sección anterior, pero se deben incluir también:
- [relationship]: esta propiedad DEBE incluir un par de IRI de la forma siguiente: el tipo de la relación será el URI de respuesta predefinido "http://www.w3.org/2005/08/addressing/reply" y el identificador del mensaje relacionado será el valor de la propiedad [message id] del mensaje al cual se responde; además, en esta propiedad se PUEDEN expresar otras relaciones.

El ejemplo siguiente presenta un mensaje que contiene propiedades de direccionamiento de mensajes serializadas como bloques de cabecera en un mensaje SOAP 1.2:

Ejemplo 3.1. Ejemplo de mensaje.

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
  xmlns:wsa="http://www.w3.org/2005/08/addressing">
  <S:Header> 
  <wsa:MessageID>http://example.com/someuniquestring</wsa:MessageID>
    <wsa:ReplyTo>
      <wsa:Address>http://example.com/business/client1</wsa:Address>
    </wsa:ReplyTo>
    <wsa:To>mailto:fabrikam@example.com</wsa:To>
    <wsa:Action>http://example.com/fabrikam/mail/Delete</wsa:Action>
  </S:Header>
  <S:Body>
    <f:Delete xmlns:f="http://example.com/fabrikam">     
       <maxCount>42</maxCount>
    </f:Delete>
  </S:Body>
</S:Envelope>

Los valores de las propiedades de este mensaje serían los siguientes:

[destination]: "mailto:fabrikam@example.com"
[reply endpoint]: El extremo con propiedad [address] "http://example.com/business/client1"
[action]: "http://example.com/fabrikam/mail/Delete"
[message id]: "http://example.com/someuniquestring"

El ejemplo siguiente muestra una respuesta al mensaje anterior:

Ejemplo 3.2. Ejemplo de mensaje de respuesta.

<S:Envelope
  xmlns:S="http://www.w3.org/2003/05/soap-envelope" 
  xmlns:wsa="http://www.w3.org/2005/08/addressing">
  <S:Header>
    <wsa:MessageID>http://example.com/someotheruniquestring</wsa:MessageID>
    <wsa:RelatesTo>http://example.com/someuniquestring</wsa:RelatesTo>
    <wsa:To>http://example.com/business/client1</wsa:To>
    <wsa:Action>http://example.com/fabrikam/mail/DeleteAck</wsa:Action>
  </S:Header>
  <S:Body>
    <f:DeleteAck xmlns:f="http://example.com/fabrikam"/>
  </S:Body>
</S:Envelope>

Los valores de las propiedades de este mensaje serían los siguientes:

[destination]: "http://example.com/business/client1"
[action]: "http://example.com/fabrikam/mail/DeleteAck"
[message id]: "http://example.com/someotheruniquestring"
[relationship]: ("http://www.w3.org/2005/08/addressing/reply", "http://example.com/someuniquestring")

4. Consideraciones relativas a la seguridad

La conformidad con esta especificación no obliga al receptor de un mensaje a obedecer a las entidades de WS-Addressing presentes en un mensaje si el receptor no tiene la certeza de que el procesamiento del mensaje es seguro.

WS-Addressing admite capacidades que le permiten al emisor de un mensaje pedirle al receptor el envío de otros mensajes no solicitados a otros receptores de su elección. Hasta cierto punto, el contenido de esos mensajes no solicitados también puede controlarse mediante parámetros de referencia provistos por el emisor inicial del mensaje. Debido a estas capacidades, es fundamental garantizar la seguridad de las comunicaciones que emplean WS-Addressing y establecer un nivel de confianza suficiente entre las partes antes de que un receptor procese las entidades WS-Addressing presentes en un mensaje. La seguridad de los mensajes incluye diversos aspectos:

Debería asegurarse la integridad de las referencias de extremo y de las propiedades de direccionamiento de mensajes para protegerlas contra la adulteración. Dicha protección de la integridad puede ser provista por el transporte, por una firma en el nivel del mensaje o por el uso de una firma digital XML dentro de las referencias de extremo.
Los usuarios de las referencias de extremo deberían verificar si éstas son confiables antes de usarlas, para lo cual deberían considerar los siguientes aspectos:
1. si la referencia de extremo se obtuvo de una fuente de confianza;
2. si la referencia de extremo se obtuvo de una fuente con autoridad para representar la propiedad [address] de dicha referencia de extremo;
3. si la propiedad [address] de la referencia de extremo es un destino de confianza.

Por ejemplo, el receptor de un mensaje podría exigir que las propiedades de direccionamiento de mensajes lleven la firma verificable de una entidad de confianza para estar seguro de que la procedencia del mensaje es confiable, y requerir además que las propiedades [reply endpoint] y [fault endpoint] estén firmadas por una fuente con autoridad para representar la propiedad [address] de aquellas referencias de extremo, a fin de impedir el envío de mensajes no solicitados. Alternativamente, se puede emplear algún mecanismo "fuera de banda" de establecimiento de confianza para determinar si una referencia de extremo particular es digna de confianza.

4.1 Otras consideraciones relativas a la seguridad

Para impedir la divulgación de información, los emisores de referencias de extremo no deberían incluir información confidencial en las propiedades [address] o [reference parameters], a menos que se hayan tomado medidas de protección adecuadas contra la divulgación arbitraria.

Algunos procesadores pueden usar la propiedad [message id] como parte de un método de comprobación de unicidad para detectar la repetición de mensajes. Se deberían tomar los debidos recaudos para asegurar que, a los efectos de la detección de repetición, la propiedad [message id] esté compuesta por datos tales que la retransmisión legítima de un mensaje no se confunda con un ataque de repetición; por ejemplo, emplear como identificador una marca temporal. También es recomendable que los valores de la propiedad [message id] sean impredecibles, para impedirles a los atacantes que construyan y envíen respuestas no solicitadas a un mensaje sin necesidad de ver el mensaje real.

5. Referencias

5.1 Referencias normativas

[IETF RFC 2119]: Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. Internet Engineering Task Force, junio de 1999. Disponible en http://www.ietf.org/rfc/rfc2119.txt.
[IETF RFC 3987]: Internationalized Resource Identifiers (IRIs) M. Duerst y M. Suignard. Internet Engineering Task Force, enero de 2005. Disponible en http://www.ietf.org/rfc/rfc3987.txt.
[XML 1.0]: Extensible Markup Language (XML) 1.0 (Third Edition), T. Bray, J. Paoli, C. M. Sperberg-McQueen y E. Maler, editores. World Wide Web Consortium, 4 de febrero de 2004. Esta versión de la Recomendación XML 1.0 es http://www.w3.org/TR/2004/REC-xml-20040204. La última versión de XML 1.0 está disponible en http://www.w3.org/TR/REC-xml.
[Espacios de nombres XML]: Namespaces in XML, T. Bray, D. Hollander y A. Layman, editores. World Wide Web Consortium, 14 de enero de 1999. Esta versión de la Recomendación Namespaces in XML es http://www.w3.org/TR/1999/REC-xml-names-19990114. La última versión de Namespaces in XML está disponible en http://www.w3.org/TR/REC-xml-names.
[Conjunto de información XML]: XML Information Set (Second Edition), J. Cowan y R. Tobin, editores. World Wide Web Consortium, 4 de febrero de 2004. Esta versión de la Recomendación XML Information Set es http://www.w3.org/TR/2004/REC-xml-infoset-20040204. La última versión de la Recomendación XML Information Set está disponible en http://www.w3.org/TR/xml-infoset.
[Estructuras de esquemas XML]: XML Schema Part 1: Structures Second Edition, H. Thompson, D. Beech, M. Maloney y N. Mendelsohn, editores. World Wide Web Consortium, 28 de octubre de 2004. Esta versión de la Recomendación XML Schema Part 1 es http://www.w3.org/TR/2004/REC-xmlschema-1-20041028. La última versión de la Recomendación XML Schema Part 1 está disponible en http://www.w3.org/TR/xmlschema-1.
[Tipos de datos de esquemas XML]: XML Schema Part 2: Datatypes Second Edition, P. Byron y A. Malhotra, editores. World Wide Web Consortium, 28 de octubre de 2004. Esta versión de la Recomendación XML Schema Part 2 es http://www.w3.org/TR/2004/REC-xmlschema-2-20041028. La última versión de la Recomendación XML Schema Part 2 está disponible en http://www.w3.org/TR/xmlschema-2.

5.2 Otras referencias

[AoWWW]: Architecture of the World Wide Web, Volume One, I. Jacobs y N. Walsh, editores. World Wide Web Consortium, 15 de diciembre de 2004. Esta versión de la Recomendación Architecture of the World Wide Web, Volume One está disponible en http://www.w3.org/TR/2004/REC-webarch-20041215/. La última versión está disponible en http://www.w3.org/TR/webarch/.
[SOAP 1.1]: Simple Object Access Protocol (SOAP) 1.1, D. Box, et al, editores. World Wide Web Consortium, 8 de mayo de 2000. Disponible en http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.
[Infraestructura de mensajería SOAP 1.2]: SOAP Version 1.2 Part 1: Messaging Framework, M. Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau y H. Frystyk Nielsen, editores. Recomendación del World Wide Web Consortium, 24 de junio de 2003. Esta versión de la Recomendación SOAP Version 1.2 Part 1: Messaging Framework es http://www.w3.org/TR/2003/REC-soap12-part1-20030624/. La última versión de SOAP Version 1.2 Part 1: Messaging Framework está disponible en http://www.w3.org/TR/soap12-part1/.
[Enlace WS-Addressing SOAP]: Web Services Addressing 1.0 - SOAP Binding, M. Gudgin, M. Hadley y T. Rogers, editores. World Wide Web Consortium, 9 de mayo de 2006. Esta versión de la Recomendación WS-Addressing SOAP Binding es http://www.w3.org/TR/2006/REC-ws-addr-soap-20060509. La última versión de la Recomendación WS-Addressing SOAP Binding está disponible en http://www.w3.org/TR/ws-addr-soap.
[Enlace WS-Addressing WSDL]: Web Services Addressing 1.0 - WSDL Binding, M. Gudgin, M. Hadley, T. Rogers y Ü. Yalçinalp, editores. World Wide Web Consortium, 16 de febrero de 2006. Esta versión de la Recomendación WS-Addressing WSDL Binding es http://www.w3.org/TR/2006/WD-ws-addr-wsdl-20060216. La última versión de la Recomendación WS-Addressing WSDL Binding está disponible en http://www.w3.org/TR/ws-addr-wsdl.
[WSDL 1.1]: Web Services Description Language (WSDL) 1.1, E. Christensen et al. World Wide Web Consortium, marzo de 2001. Disponible en http://www.w3.org/TR/2001/NOTE-wsdl-20010315.
[WSDL 2.0 Core Language]: Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, R. Chinnici, J. J. Moreau, A. Ryman y S. Weerawarana, editores. World Wide Web Consortium, 27 de marzo de 2006. Esta versión de la especificación WSDL 2.0 es http://www.w3.org/TR/2006/CR-wsdl20-20060327. La última versión de WSDL 2.0 está disponible en http://www.w3.org/TR/wsdl20.
[WS-Security 2004]: Web Services Security: SOAP Message Security 1.0 (WS-Security 2004), A. Nadalin, C. Kaler, P. Hallam-Baker y R. Monzillo, editores. Organization for the Advancement of Structured Information Standards, marzo de 2004. Disponible en http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf.
[xml:id]: xml:id Version 1.0, J. Marsh, D. Veillard y N. Walsh, editores. World Wide Web Consortium, 9 de septiembre de 2005. Esta versión de la Recomendación xml:id versión 1.0 es http://www.w3.org/TR/2005/REC-xml-id-20050909/. La última versión de xml:id está disponible en http://www.w3.org/TR/xml-id/.

Spanish Translation by Trusted Translations, Inc.

Otras Traducciones de W3 en Spanish Translator Services