Download - Soap Parte1
-
7/22/2019 Soap Parte1
1/32
Intercambiar con un servicio- Formato del mensaje
Objetos, servicios, documentos
El 10 de febrero de 1998, el World Wide Web Consortium (W3C) publica una
notable: Extensible Markup Language (XML) 1.0. A partir de su salida,
XML demuestra una enorme polivalencia, utilizndose en aplicaciones que probablemente
nunca haban pasado por la imaginacin de sus primeros diseadores. Se convierte
rpidamente en el lenguaje universal de descripcin de datos, estructurados y no
estructurados. En la actualidad, las iniciativas de normalizacin en XML de los datos y
documentos propios en los distintos sectores econmicos, conducidos por las organizaciones
profesionales y de los organismos de normalizacin, se cuentan por centenares. En la lneas
de los grandes estndares Internet (IP, TCP, SMTP, HTTP, HTML), XML se vuelve
inevitable.
Inmediatamente despus de la publicacin de la recomendacin, cuatro arquitectos de
software: Dave Winer (UserLand Software, Don Box (DevelopMentor), Bob Atkinson y
Mohsen Al-Ghosein (colaboradores de Microsoft) elaboran un protocolo de llamada de
procedimiento distante (de tipo RPC) que utiliza HTTP como protocolo de transporte y XML
como formato de mensaje. El resultado del trabajo es publicado por Dave Winer en marzo de
1998 (apenas un mes despus de la publicacin de la norma XML!) bajo el nombre de XML-
RPC. Al mismo tiempo, nacen y se desarrollan en los laboratorios de R&D ms de una decena
de experiencias similares, a menudo en la esfera de influencia .
Para ms detalles de XML-RPC, consultar la siguiente referencia: http://www.xmlrpc.com/
SOAP
A partir de la publicacin de XML-RPC, la actividad en torno a las especificaciones y
tecnologas que constituyen hoy el conjunto de los , se acelera y se
diversifica.
XML alcanza rpidamente una enorme popularidad y se vuelve cada vez ms equipado:
por analizadores sintcticos cada vez ms rpidos; por la disponibilidad, en varios lenguajes de programacin, de bibliotecas destinadas a
manipulacin de los documentos en memoria cuyo interfaz programtica se ajusta al
estndar DOM (Document Object Model), recomendacin W3C del 10 de octubre de
1998;
por la disponibilidad de herramientas complementarias, pero esenciales, como XSLT.
Por otra parte, HTTP presenta la enorme ventaja de ser aceptado universalmente. Es en
particular, plebiscitado por una poblacin profesional que tiene un rol clave: los
administradores de redes. En efecto, stos controlan las tcnicas y las herramientas de
seguridad y, obviamente, las reservan para una recepcin mitigada a la utilizacin, a travs decortafuegos, otros protocolos IP (como el protocolo Internet Inter ORB o el IIOP especificado
-
7/22/2019 Soap Parte1
2/32
por el OMG y adoptado por el IETF, y como el Remote Method Invocation o RMI, el
protocolo utilizado para la comunicacin entre aplicaciones Java distribuidas).
HTTP es un protocolo simple, robusto y adaptado al mundo abierto de Internet. Obviamente,
su facilidad de utilizacin y su difusin tienen por corolario la apertura, que es propio de la
Web y expone cualquier aplicacin, al menos, al riesgo de la saturacin delas llamadas (denial of service). Por a otra parte, si SSL ofrece una solucin simple al
problema de la confidencialidad de los intercambios sobre HTTP (HTTPS), las soluciones
generalizadas a los problemas de seguridad (autenticacin, autorizacin, confidencialidad,
integridad, no repudio) estn hoy en desarrollo.
XML-RPC es la fuente de inspiracin de SOAP (Simple Object Acces Protocol), definido por
un equipo proveniente de Microsoft, con la participacin de Dave Winer y Don Box. SOAP
1.0 se presenta bajo la forma de Internet Draft, en noviembre de 1999, a la Internet
Engineering Task Force (ver http://www.scripting.com/misc/soap1.txt). La iniciativa parece
permanecer confinada en la esfera de influencia Microsoft, pero a principios del 2000 seopera, en el mercado de la tecnologa, una dislocacin de mucha importancia: IBM y su filial
Lotus Development deciden trabajar con Microsoft con el fin de desarrollar juntos la versin
1.1 de la especificacin SOAP, que es inscrita a continuacin como una nota W3C en mayo
de 2000 (ver http://www.w3.org/TR/SOAP).
Adems Microsoft, IBM y su filial Lotus, un gran nmero de empresas apoyan esta oferta
entre cules estn: Ariba Inc., Commerce One Inc., Compaq Computer Corporation,
DevelopMentor Inc., Hewlett Packard Company, IONA Technologies, SAP AG, UserLand
Software Inc. El W3C nota del 8 de mayo de 2000: Simple Object Acces Protocol (SOAP)
1.1, est completado por una nota suplementaria del 11 de diciembre de 2000: SOAP
Messages with Attachments, que trata de la inclusin de partes adjuntadas a los mensajes
SOAP por la utilizacin de la estructura multi-partes MIME (multipart), utilizada sobre
Internet para transportar documentos heterogneos (ver http://www.w3.org/TR/SOAP-
attachments).
Esta evolucin permite el verdadero inicio de la tecnologa de los servicios Web. IBM, uno de
protagonistas principales de la industria informtica, est obviamente muy interesado en la
normalizacin y la aplicacin del lenguaje Java, de las arquitecturas basadas en este lenguaje
y, en particular, de Java 2 Enterprise Edition (J2EE). La arquitectura J2EE se destina
claramente al desarrollo de sistemas e-negocios e informtica de gestin y constituye la punta
de lanza tecnolgica de una coalicin heterognea cuyo objetivo estratgico reconocidoconsiste en contradecir la expansin de Microsoft en el mbito de las tecnologas informticas
relativas a los servidores.
Ahora, IBM coopera, con su competidor histrico Microsoft, sobre la definicin de un
estndar de intercambio e interoperabilidad en la Web entre aplicaciones informticas,
desarrolladas sobre tecnologas que son, por construccin, heterogneas. La presencia de
IBM, que apuesta mucho sobre a la tecnologa Java, a los lados de Microsoft, que va a
proponer un mes despus de la nueva arquitectura de aplicaciones .NET - a su vez concebida
y presentada como la respuesta de Microsoft a J2EE - credibilidad a la promesa de
interoperabilidad entre servicios Web construidos sobre arquitecturas y tecnologasradicalmente diferentes y concurrentes.
-
7/22/2019 Soap Parte1
3/32
En efecto, el simple hecho de que un protocolo de intercambio entre aplicaciones Web se base
en dos estndares universalmente aceptados, como XML y HTTP, no basta sin embargo a
garantizar la independencia de este protocolo de las tecnologas aplicadas en el desarrollo de
aplicaciones que lo utilizan. SOAP 1.1 permite el intercambio entre aplicaciones construidas
sobre tecnologas heterogneas, porque se concibi para eso.
Por otra parte, los propios lmites de interoperabilidad del protocolo SOAP, que resultan de
derivados propietarios de interpretacin de especificaciones, a los cuales mencionaremos
posteriormente, muestran bien la dificultad paradjica de garantizar el comportamiento del
compromiso de interoperabilidad por una tecnologa, en cuestin, de all el postulado
principal. Estos lmites dan la medida de distancia que separa la publicacin de un documento
de especificacin, de su aplicacin a grande escala.
La diferencia con las tentativas pasadas de normalizacin reside en el hecho de que la
tecnologa de servicios Web indica como nico objetivo fundamental y prcticamente nico
de garantizar la interoperabilidad de las aplicaciones. La ampliacin del mercado de losservicios Web pasa pues por el comportamiento de esta promesa: de ah la necesidad, por
parte de los proveedores de tecnologas de protegerse contra toda la tentacin de cierre y de
consagrar un esfuerzo importante y especfico para lograr el objetivo. La instauracin, en
febrero de 2002, de la iniciativa Web Service Interoperability (WS-I) por parte de IBM,
Microsoft, BEA, Intel, y otros muestra la importancia y la urgencia de velar permanentemente
por la convergencia hacia este objetivo para permitir el despegue del mercado de los servicios
Web.
SOAP es la causa, el acrnimo de Simple Object Acces Protocol, el protocolo de
acceso a los objetos. El nombre no corresponde al objeto nombrado y es incluso mal
entendido: SOAP no es en ningn caso un protocolo de dilogo entre objetos distribuidos. No
permite ir dirigido directamente a un objeto distante, incluso si puede obviamente utilizarse
indirectamente para que se consiga este resultado.
SOAP no es pues un protocolo : esta opcin tcnica no es un accidente, ni el
producto de la ignorancia u hostilidad para el enfoque , sino una voluntad precisa
de los diseadores de SOAP, los cuales son todos expertos de las arquitecturas orientadas a
objetos distribuidos. En realidad, la de SOAP es una caracterstica
indispensable para garantizar las caractersticas esenciales de independencia de las
implementaciones y de la interoperabilidad de los servicios Web.
Objetos por referencia
Para enviar un mensaje a un objeto distante, el emisor debe en primer lugar conocer el
identificador nico de este objeto en la red. A partir del momento en que la referencia a un
objeto existente en la memoria de un proceso sale del espacio de direccionamiento del
proceso para difundirse en una red, comienza una serie de problemas cuya solucin , por otro
lado tcnicamente delicada, depende ineludiblemente de la caractersticas del lenguaje
utilizado, as como de las estrategias de los compiladores y de los ambientes de ejecucin
(interpretes, gestores de memoria) en uso. En una palabra, ellos dependen de la
implementacin de los interlocutores del intercambio.
-
7/22/2019 Soap Parte1
4/32
Por otra parte, la exportacin de la referencia de un objeto fuera de su espacio de
direccionamiento provoca problemas prcticamente insolubles en una arquitectura abierta. En
qu momento liberar la memoria asignada a un objeto, cuando su identificador viaja en la red?
En qu momento decidir que la retencin del identificador en la red no se ha olvidado, un
abuso o un acto hostil, sino la necesidad de una transaccin larga? Obviamente, estas
preguntas tienen respuestas ms o menos fciles para un sistema cuya distribucin en una redlocal cerrada se imagin con todo detalle por el diseador y es estrictamente controlada en
ejecucin por el administrador, pero cul es el detalle en el mundo abierto de Internet?
En cualquier caso, incluso en una red local, en un mundo cerrado y controlado, estos
problemas y otro conexos se presentan con frecuencia, en la prctica, difcilmente solubles.
La mayor parte de las aplicaciones distribuidas se han implantado sobre la base de un enfoque
que llamamos servicio. Los dos enfoques se enfrentaron en el desarrollo de aplicaciones que
se basaban en la arquitectura cliente a servidor:
El enfoque objeto puro pretende que la aplicacin cliente obtenga el identificadortcnico(un IOR: Internet Object Reference, en el mundo CORBA/IIOP) de la copia en
memoria del servidor de la instancia de la clase Contrato, por ejemplo, teniendo como
valor del atributo numeroContrato el valor 123456 (numeroContrato es la llave
aplicativa del contrato).
A continuacin, la aplicacin cliente puede aplicar directamente al objeto distante
mediante su identificador los mtodos como obtenerElNombreDelContratante.
El enfoque servicio, consiste en llamar, sobre el identificador tcnico de una instancia
de la clase GestionDelosContratos (singleton), que funge como
representante del servicio de gestin de contratos en ejecucin del mtodo
obtenerElNombreDelContratante, con argumento el valor 23456, identificador de
negocio del contrato en cuestin. Nada impide a la implementacin de la aplicacin
que delegue la peticin a la instancia del objeto contrato conveniente, o que elija
cualquier otra organizacin alternativa. El identificador del servicio (de la instancia
singular de la clase GestionDelosContratos que representa al servicio) se utiliza en
este contexto como el punto de entrada del servicio.
En el uso, es el segundo enfoque que ms se ha utilizado en las aplicaciones cliente/servidor
implementadas con lenguajes orientados a objeto. Est claro que llamar esta organizacin
, aunque el lenguaje de programacin es orientado a
objetos, es un abuso del lenguaje: se trata de la prctica usual de invocacin de
procedimientos distantes (RPC o Remote Procedure Call) entre aplicaciones que desempeanrespectivamente los papeles de cliente y servidor sobre dos nodos distantes de la red. El hecho
de que las aplicaciones implicadas sean o no desarrolladas al utilizar lenguajes orientados a
objeto es transparente con relacin al protocolo de intercambio.
Sobrepasar la granulosidad de despliegue del objeto Contrato a la del servicio Gestin de los
contratos simplifica el despliegue y la explotacin, ya que eso coloca una capa de abstraccin
que oculta a los clientes de la aplicacin de gestin de los contratos el conocimiento de los
detalles de implementacin (por ejemplo, la gestin de las instancias de la clase Contrato, de
sus identificadores tcnicos, de la memoria asignada y de su liberacin). Por estas razones,
una gran parte de las aplicaciones cliente/servidor desarrolladas con lenguajes orientados aobjetos eligi exponer como interlocutor de la llamada distante una granularidad de tipo
-
7/22/2019 Soap Parte1
5/32
ms bien que . Por otra parte, cuando el lenguaje de implementacin
no es , el enfoque se impone naturalmente.
Objetos por valor y documentos
La dificultad de tratar los objetos por referencia en las arquitecturas distribuidas es la causa deevolucin desarrollada para permitir el paso de los objetos por valor. A partir del momento en
que, por razones de desempeo, de fiabilidad y de robustez de la aplicacin, no se aconseja
manipular un objeto distante por una secuencia de operaciones de granularidad fina, es
tentador transferir el objeto directamente con el fin de manipularlo a nivel local. Por ejemplo,
cuando se negocia un contrato, parece natural transferir entre contratantes la copia del
contrato, cada uno aporta sus modificaciones, hasta la convergencia sobre un objeto comn.
Para responder a esta exigencia de transferencia entre aplicaciones distribuidas, es
indispensable definir, adems del convenio de codificacin de tipos atmicos (entero,
cadenas, etc.) necesario para transferir los valores de los argumentos de la llamada del mtodosobre objetos distantes, una regla de de estructuras complejas.
Lo que se transporta es, a primera vista, una estructura de datos y no un objeto. Un objeto es,
por definicin, una estructura de datos y un conjunto de tratamientos asociados. La aplicacin
efectiva de la invocacin de mtodos distantes con paso de objetos por valor, requiere al
menos dos requisitos previos:
que el cliente y el servidor sean capaces de cifrar y descifrar en un mensaje de
peticin/respuesta la estructura de datos que representa al objeto pasado en argumento;
que el cliente y el servidor sean capaces de manipular el objeto reconstruido, es decir
que el cdigo de mtodos de manipulacin del objeto les sea tambin accesibles.
Estos dos requisitos previos no pueden cumplirse enteramente sin dos condiciones:
El cliente y el servidor deben implementarse utilizando el mismo lenguaje de
programacin y el mismo ambiente de compilacin y ejecucin de este lenguaje. Es
solamente a este precio que el paso de objetos por valor toma todo su sentido.
El cliente y el servidor deben ser capaces de compartir en la red los cdigos de los
mtodos aplicables al objeto.
Estas dos condiciones son ms restringidas que las necesarias para la invocacin de los
mtodos distantes con paso de objetos por referencia, que se limitan:
a la codificacin de la llamada;
a la codificacin de los identificadores universales de los objetos;
a la codificacin de los datos atmicos.
El paso de objetos por referencia puede efectuarse entre programas implementados por
lenguajes de programacin diferentes (por ejemplo utilizando el mismo ORB en una
arquitectura CORBA).
-
7/22/2019 Soap Parte1
6/32
El paso de objetos por valor requiere la homogeneidad de los ambientes de desarrollo y la
comparticin de cdigo entre el cliente y el servidor. Sin estas dos condiciones, la estructura
pasada es una estructura de datos, y los procedimientos de cifrado/descifrado y los mtodos
de manipulacin son diferentes entre cliente y servidor.
Este ltimo enfoque se llama enfoque documento: la estructura de datos en la peticin y larespuesta es un que se cifra, descifra, manipulado de forma independiente
por el cliente y el servidor. Indudablemente, el cliente y el servidor comparten (o tienen la
impresin de compartir) la semntica informal del documento (un pedido, una factura, etc.)
aunque las semnticas operativas son diferentes.
SOAP y el uso de XML para el contenido de los mensajes normalizar el enfoque documento.
Service Oriented Access Protocol?
Un protocolo de intercambio en la Web debe exhibir al menos tres propiedades paragarantizar la interoperabilidad de las aplicaciones en implementaciones heterogneas:
Debe ser completamente compatible con las tecnologas, las herramientas y las
prcticas comunes en Internet. El protocolo debe ser tambin evolutivo, por lo tanto
compatible, pero relativamente independiente de las tecnologas y prcticas de la red
actual, y capaz de integrar fcilmente sus evoluciones.
Debe ser completamente independiente de las especificidades de la implementacin de
las aplicaciones. En particular, el protocolo debe ser independiente de los sistemas
operativos, de los lenguajes de programacin, ambientes de ejecucin, posibles
modelos de componentes de software utilizados.
Debe ser o, ms concretamente, . No solamente las
implementaciones de las aplicaciones que participan en el intercambio no se ven
obligadas nunca a conocer las implementaciones de sus interlocutores, pero, adems,
ninguna instalacin de tecnologa dependiente de las elecciones de implementacin de
los interlocutores no debe requerirse para corresponder con ellos. Lo que es necesario
para intercambiar es la tecnologa de software que permite cifrar, emitir, recibir y
descifrar mensajes que tienen un formato universal y normalizado. Esta tecnologa es
obviamente especfica, o incluso propietaria, para cada ambiente o lenguaje de
implementacin, pero sigue siendo completamente independiente de las tecnologas de
implementacin de las aplicaciones interlocutoras.
SOAP 1.1, as como los trabajos en desarrollo sobre su sucesor SOAP 1.2, satisfacen
globalmente estas exigencias. Ms concretamente, SOAP 1.1 es una tecnologa actualmente
perfectamente utilizable y de sobra implementada.
A la oferta de SOAP 1.1 sigui la inicializacin, en septiembre de 2000, de un grupo de
trabajo del W3C (XML Protocol) que hoy se encarga de normalizar el conjunto creciente de
las tecnologas de intercambio entre aplicaciones distribuidas que se basan en XML. Este
grupo de trabajo se dedica, entre otras cosas, a la especificacin SOAP 1.2.
En enero de 2002, empez en el W3C la actividad Web Services, que cubre el conjunto de lastecnologas y protocolos de interaccin de las aplicaciones distribuidas en la Web. Esta
-
7/22/2019 Soap Parte1
7/32
actividad absorbe al grupo de trabajo XML Protocol y contina los trabajos de normalizacin
de SOAP 1.2, y empieza por otro lado otros trabajos que afectan otras tecnologas de servicios
Web, ms all del intercambio, y, en particular, el nivel descripcin con WSDL (Web
Services Description Language).
Validacin y comprobacin de la interoperabilidad
La interoperabilidad terica de SOAP y las otras tecnologas de servicios Web no deja lugar a
duda. La interoperabilidad prctica demanda actividades de validacin y comprobacin de las
distintas implementaciones. Es lo que haba faltado en las implementaciones CORBA, y estas
actividades forman parte integrante de la tarea que se da en el WS-I (Web Services
Interoperability Organization), consorcio de industriales y usuarios.
El mtodo adoptado por el WS-I es trabajar por . Un perfil es un conjunto
coherente de tecnologas de servicios Web en un determinado nivel de versin. A partir del
inicio de la organizacin, se define un perfil bsico (Basic Profile), incluyendo las cuatrotecnologas a las cuales se consagra una curso normal de servicios Web: XML Schema 1.0,
SOAP 1.1, WSDL 1.1 et UDDI 2.0.
El 8 de octubre de 2002, el WS-I public a Basic Profile Version 1.0- Working Group Draft
(http://www.ws-i.org/Profiles/Basic/2002-10/BasicProfile-1.0-WGD.pdf), un documento que
contiene ciento de recomendaciones que permiten garantizar la interoperabilidad del uso de
las tecnologas de servicios Web conformes a este perfil bsico.
Los principios del protocolo SOAP 1.1
SOAP 1.1 proporciona un mecanismo que permite intercambiar informacin estructurada y
con tipos entre aplicaciones en un ambiente distribuido y descentralizado. No transporta
modelo de programacin o implementacin, sino proporciona las herramientas necesarias para
definir modelos operativos de intercambio (estilos de intercambio) tambin diversificados que
los sistemas de servicio de mensajera asncronos y la llamada de procedimiento distante
(RPC).
SOAP 1.1 especifica la utilizacin de documentos XML como mensajes. Para ello, posee un
determinado nmero de caractersticas:
una gramtica para definir el formato y la estructura de los mensajes (en trminos de
documentos XML);
un convenio para designar los agentes de software habilitados a tratar las distintas
partes del mensaje as como el carcter obligatorio u opcional del tratamiento;
una representacin cifrada para transportar los datos atmicos y estructurados
manipulados por los lenguajes de programacin (estilo de codificacin);
un conjunto de consignas (conexin ) para transportar los mensajes
sobre el protocolo de transporte HTTP;
una representacin de la peticin y la respuesta de una llamada de procedimiento
distante (RPC);
-
7/22/2019 Soap Parte1
8/32
un conjunto de consignas suplementarias para transportar mensajes acompaados de
documentos heterogneos en documentos adjuntos.
Todas estas caractersticas forman parte de SOAP 1.1, pero son funcionalmente modulares y
ortogonales. Es necesario tener en cuenta que SOAP 1.1 es redefinible, ya que contiene los
mecanismos necesarios para la definicin de especificaciones alternativas para estascaractersticas, y extensible, ya que permite definir y aadir caractersticas suplementarias al
mecanismo bsico.
Examinaremos en esta parte del curso, la gramtica del mensaje y los convenios de
tratamiento, as como el estilo de intercambio por mensaje unidireccional, con eventualmente
intermediarios en la cadena de transporte.
La problemtica de la codificacin de los datos, de los estilos de codificacin, as como la
transmisin de documentos heterogneos (objetos multimedia) como documentos adjuntos se
expone por lo regular en cursos ms avanzados.
Igualmente, abordaremos la problemtica de los estilos de intercambio (mensaje de direccin
nica, peticin/respuesta, llamada de procedimiento distante), as como la conexin
SOAP/HTTP.
La estructura de la especificacin SOAP 1.1
La estructura de la especificacin SOAP 1.1 est representada en la figura 1. La
especificacin puede organizarse en varios niveles (intercambio, formato, contenido,
conexin). Esta prev una pluralidad de estilos de intercambioposibles, que se basan todos en
un nico y slo uno (aunque extensible) formatode mensaje: el formato XML del envelope
SOAP 1.1 y de sus elementos descendentes.
El mensaje con formato nico puede albergar un contenido literal(del XML bien formado o
vlido en relacin esquemas XML Schema) o cifrado (siguiendo una pluralidad de estilos de
codificacin) y ser objeto de un conjunto de convenios de conexin (binding) con una
pluralidad de protocolos de transporte.
Las partes en gris de la figura 1 constituyen el objeto de la especificacin SOAP 1.1.
El formato de mensaje constituye el pivote de la especificacin. El mensaje puede sertransferido por varios protocolos de transporte y en el marco de varios estilos de intercambio
entre aplicaciones. Algunos protocolos de transporte pueden especialmente adaptarse para
algunos estilos de intercambio. Es el caso tpicamente del estilo RPC, que se basa en una
especializacin del formato de mensaje, eventualmente en un estilo de codificacin.
El estilo RPC da consignas de conexin particulares que vinculan directamente el
funcionamiento llamada/retorno del estilo de intercambio RPC con el funcionamiento
peticin/respuesta del protocolo de transporte HTTP.
-
7/22/2019 Soap Parte1
9/32
Figura 1: Estructura de la especificacin por niveles de SOAP 1.1.
Los usos estndar y extendidos de SOAP 1.1 se muestran en la figura 2.
Figura 2: Los usos de base y extendidos de SOAP 1.1.
-
7/22/2019 Soap Parte1
10/32
Las bases de SOAP 1.1
Habamos visto con anterioridad que los estilos de intercambio propuestos por SOAP 1.1 son
el mensaje de direccin nica y la peticin/respuesta, con sus dos alternativas documento y
RPC.
El mensaje de direccin nica se presenta en esta parte del curso, mientras que el estilo
peticin/respuesta (documento y RPC) se presentaran posteriormente. Un mensaje de
direccin nica SOAP 1.1 parte de un nudo expeditor para alcanzar un nodo destinatario
(figura 3).
Figura 3: Estilo de intercambio de mensaje en sentido nico.
Consideremos el siguiente ejemplo:
Ciao !
Un mensaje puede transferirse directamente del expeditor al destinatario, o bien transitar por
un nmero ilimitado de nodos intermediosque forman una cadena de transporte (figura 4).
Cada nodo intermedio es receptor del mensaje emitido del nodo anterior en la cadena y
emisor del mensaje para el nodo siguiente. En una cadena de transporte, el expeditor es el
primer emisor y el destinatario es el ltimo receptor. Un nodo intermedio es una aplicacin
SOAP 1.1 capaz de recibir y emitir mensajes SOAP 1.1.
Figura 4: Una cadena de transporte.
La utilidad del mecanismo de la cadena de transporte es a la vez tcnica y funcional. Desde el
punto de vista tcnico, el mecanismo normaliza el rol y la funcin del routeador aplicativo.
Desde el punto de vista funcional, las posibilidades ofrecidas por este mecanismo son
mltiples. Permite componer servicios de capas (tiers) sobre la base de funciones distribuidas
-
7/22/2019 Soap Parte1
11/32
sobre la cadena de transporte, como la anotacin de los mensajes, la suscripcin, la
confidencialidad por codificacin, la colocacin del cache o almacenamiento intermedio
(caching), el no repudio.
Los diferentes elementos de un mensaje SOAP 1.1 son producidos y consumidos por los
nodos de la cadena de transporte. Producir un elemento de un mensaje equivale a constituirlo.Consumir un elemento de un mensaje equivale a tratarlo y, para los intermediarios, a remitir
el mensaje despus de haber suprimido el elemento consumido. Elproductorde un elemento
de un mensaje SOAP 1.1 es el nodo (expeditor o intermediario) que produce el elemento en
cuestin (as como todos sus subelementos). El consumidorde un elemento de un mensaje
SOAP 1.1 es el nodo (intermediario o destinatario) que consume el elemento en cuestin (as
como todos sus subelementos).
El expeditor del mensaje es el primer productor del mensaje. El receptor del mensaje, ya sea
el intermediario o destinatario, debe exhibir un comportamiento normalizado, que puede
resumirse as:
1. Debe examinar el mensaje para buscar la informacin que se le destina.
2. Entre las partes del mensaje que le van dirigidas, all tiene algunas cuyo consumo por
parte del nodo es obligatorio: si el nodo es de efectuar este consumo, debe
efectuarlo, y si no es , debe rechazar el mensaje.
3. Si se trata de un intermediario, entonces debe suprimir del mensaje las partes que
consume, y puede as producir nuevos elementos, colocados en los lugares del
mensaje destinados a este efecto, luego debe emitir de nuevo el mensaje hacia el nodo
siguiente de la cadena de transporte.
SOAP 1.1 y XML
El mensaje SOAP 1.1 es un documento XML 1.0. Esto implica que un documento XML 1.0
no puede no insertarse tal cual en un mensaje SOAP 1.1 (un documento XML no puede
insertarse sin cambio en otro documento XML). La especificacin SOAP 1.1 no confirma
explcitamente si un mensaje SOAP 1.1 debe comenzar por la declaracin de uso:
La especificacin SOAP 1.1 establece que un mensaje SOAP 1.1:
no debe contener DTD (Document Type Definition), esto esencialmente por la razn
tcnica que la sintaxis de los DTD no est en el formato XML;
no debe contener instrucciones ejecutables, cuya presencia es aceptada en los
documentos basados en XML 1.0.
La utilizacin generalizada de los vocabularios XML (XML Namespaces) y de los nombres
calificados es fuertemente aconsejada por la especificacin SOAP 1.1, aunque no obligatorio
para una aplicacin que desempea solamente el rol de expeditor de mensajes. En cambio, las
aplicaciones que pretenden desempear el rol de destinatario deben ser capaces de tratar
correctamente los vocabularios XML de los mensajes que reciben. Estas aplicaciones deben
-
7/22/2019 Soap Parte1
12/32
rechazar los mensajes que utilizan los vocabularios XML de manera incorrecta o que utilizan
vocabularios XML incorrectos.
La especificacin SOAP 1.1 define un vocabulario XML SOAP 1.1 para los elementos y los
atributos propios al formato del mensaje. El identificador del vocabulario XML SOAP 1.1 se
asocia al URI http://schemas.xmlsoap.org/soap/envelope/.
La declaracin del vocabulario XML http://schemas.xmlsoap.org/soap/envelope/ es
obligatoria para todo mensaje SOAP 1.1. Esta declaracin designa la versin de SOAP
reivindicada por el mensaje.
El prefijo asociado al vocabulario XML http://schemas.xmlsoap.org/soap/envelope/ en la
especificacin SOAP 1.1 es SOAP-ENV. El buen uso de los vocabularios XML (cuando un
prefijo es utilizado por una especificacin cuyos elementos se utilizan en un documento, es
preferible utilizar el mismo prefijo que la especificacin) sugiere que en el elemento raz
(SOAP-ENV: Envelope) de todo mensaje SOAP 1.1 aparezca la declaracin:
xmlns: SOAP-ENV=" http://schemas.xmlsoap.org/soap/envelope/"
Un mensaje SOAP 1.1 puede integrar declaraciones de vocabularios XML aplicativos
cualesquiera. El ejemplo presentado en el apartado anterior, cuando integra las declaraciones
de vocabularios XML y el uso de los nombres calificados, toma el paso siguiente (el
vocabulario XML designado por el prefijo g es un vocabulario aplicativo):
Ciao !
Se normaliza tambin la utilizacin de los atributos. Se admite introducir atributos en los
elementos de un mensaje SOAP 1.1. Estos atributos pueden integrarse directamente en las
ocurrencias de los elementos de un mensaje o pueden especificarse en un esquema XS o en unDTD accesible tanto al expeditor como al destinatario. En ese caso, los valores, por defecto o
fijos, definidos en el esquema XS o el DTD deben tomarse como si aparecan directamente en
las instancias. Los atributos SOAP-ENV:mustUnderstand y SOAP-ENV:actor son
introducidos por la especificacin SOAP 1.1 y desempean un papel particular que se
examinar ms tarde.
La estructura del mensaje SOAP 1.1
Un mensaje SOAP 1.1 presenta una estructura normalizada (ver figura 5). Se constituye
siempre de un elemento (raz), es decir el envelope (SOAP-ENV:Envelope),
-
7/22/2019 Soap Parte1
13/32
que contiene un elemento encabezado (SOAP-ENV:Header) opcionaly un elemento cuerpo
(SOAP-ENV:Body) obligatorio, seguidos de posibles elementos aplicativos especficos.
Figura 5: La estructura del mensaje SOAP 1.1.
El envelope
El envelope es el elemento (raz) de todo mensaje SOAP 1.1.
En el envelope de un mensaje SOAP 1.1, la presencia de la declaracin del vocabulario XMLSOAP 1.1 es obligatoria:
xmlns: SOAP-ENV=" http://schemas.xmlsoap.org/soap/envelope/"
o, eventualmente:
xmlns=" http://schemas.xmlsoap.org/soap/envelope/"
Esta declaracin se utiliza para sealar la versin SOAP (SOAP 1.1) a la cual el mensaje hace
referencia. El mensaje se espera as ser tratado por todo receptor (intermediario o destinatario)segn la versin del protocolo que exhibe. Si no presenta ninguna versin del protocolo o
-
7/22/2019 Soap Parte1
14/32
-
7/22/2019 Soap Parte1
15/32
El URI reservado por la especificacin SOAP 1.1 http://schemas.xmlsoap.org/soap/actor/next
designa como consumidor de la entrada del encabezad el primer nodo SOAP 1.1 segn el
emisor en la cadena de transporte.
La regla de designacin del consumidor para las entradas del encabezado de un mensaje
SOAP 1.1 es finalmente simple:
El consumidor designado de una entrada del encabezado que contiene el atributo
SOAP-ENV:actor, as como de todos sus subelementos, es el nodo cuyo URI es el
valor del atributo.
El consumidor designado de una entrada del encabezado que contiene el atributo
SOAP-ENV:actor que tiene como valor el URI
http://schemas.xmlsoap.org/soap/actor/next es el primer nodo siguiente al emisor del
mensaje en la cadena de transporte.
El consumidor designado de una entrada del encabezado que no contiene atributo
SOAP-ENV:actor, as como de todos sus subelementos, no puede ser sino eldestinatario del mensaje.
La figura 6 presenta una cadena de transporte con un nico intermediario: nice.guy.net quiere
enviar un mensaje a pretty.girl.net por medio del intermediario office.postalservice.com.
Figura 6: Una cadena de transporte con un solo intermediario (I).
La designacin absoluta del consumidor
Veamos el mensaje A (figura 6) emitido por nice.guy.net en la intencin de
office.postalservice.com:
http://www.postalstandards.org/send
http://nice.guy.net/
http://pretty.girl.net/
http://pretty.girl.net/home.asp
-
7/22/2019 Soap Parte1
16/32
Ciao !
El mensaje se recibido de forma correcta por office.postalservice.com que:
1. recorre el encabezado del mensaje;
2. identifica el valor de SOAP-ENV:actor en la entrada pbs:postmark como su propio
URI;
3. notamos que la accin solicitada es el envo simple del mensaje (designada por el URI
http://www .postalstandards.org/send);
4. notamos el valor del elemento pbs:receiverPort;
5. ignora el elemento SOAP-ENV:Body;
6. construye un nuevo mensaje en el cual la entrada pbs:postmark es modificada: elatributo SOAP-ENV:actor y el elemento pbs:acction se retiran, adems los elementos
pbs:sender y pbs:receiver, su propio URI as como la fecha y la hora de recepcin del
mensaje (a la hora de Greenwitch, segn el formato ISO 8601) igualmente se aaden;
7. enva el nuevo mensaje sobre el puerto de recepcin http://pretty.girl.net/home.asp.
Se muestra el mensaje A' (figura 6) emitido por office.postalservice.com para pretty.girl.net:
http://office.postalservice.com/
2010-06-30T23:59:59http://www.postalstandards.org/send
http://nice.guy.net/
http://pretty.girl.net/
http://pretty.girl.net/home.asp
-
7/22/2019 Soap Parte1
17/32
En la recepcin, pretty.girl.net trata no solamente el cuerpo del mensaje, sino tambin las
entradas de encabezado. pretty.girl.net considera el identificador (URI) del expeditor, y
tambin debido a que la pequea palabra recibida pas por office.postalservice.com,
considerando la fecha y hora.
La designacin relativa del consumidor
En efecto, en esta cadena de transporte, nice.guy.net no tiene que especificar el
URI del intermediario como valor del atributo SOAP-ENV:actor: el URI especial
http://schemas.xmlsoap .org /soap/actor/next puede convenir.
El mensaje A (figura 6) producido y emitido por nice.guy.net puede ser el siguiente:
La ventaja de este enfoque es evidente: el mensaje el servicio Web que lo
transporta. Una vez preparado el mensaje, nice.guy.net puede decidir en los ltimos minutos
del prestador de servicios postales Web que el va a solicitar para enviar su pequea palabra a
pretty.girl.net, sobre la base de diferentes criterios como el precio, la calidad de servicio, etc.
Queda claro que, para obtener este resultado, es necesario que una serie de prestadores de
servicios postales Wen se hayan puesto de acuerdo sobre el formato y sobre un tratamiento de
las entradas de los encabezados, cuyo vocabulario XML es:
http://www.postalstandards.org/basicservices/.
El atributo SOAP-ENV:mustUnderstand
El atributo SOAP 1.1 SOAP-ENV:mustUnderstand se utiliza para indicar que el consumo de
la entrada del encabezado por el consumidor potencial designado es obligatorio (valor " 1") o
facultativo (valor " 0" , valor por defecto).
La lnea de conducta que los nodos que participan deben tener en una cadena de transporte de
un mensaje SOAP 1.1 es la siguiente:
El consumidor designado de un elemento del encabezado con SOAP-
ENV:mustUnderstand=" 1" debe consumir el elemento en cuestin. Si es
-
7/22/2019 Soap Parte1
18/32
(el sentido de esta se precisar en la seccin consagrada a la gestin
de los errores), debe rechazar el mensaje.
El consumidor designado de un elemento del encabezado con SOAP-
ENV:mustUnderstand=" 1" , que es de consumir el mensaje, debe no
solamente rechazarlo pero puede decidir enviar un mensaje de error al emisor del
mensaje que acaba de recibir. Este tratamiento slo puede ser aplicable si el receptores capaz de emitir mensajes SOAP 1.1.
El consumidor designado de la entrada del encabezado con SOAP-ENV:
mustUnderstand=" 0" puede consumir o no esta entrada. Si decide no consumirla,
debe re-emitir el mensaje tal cual hacia el prximo nodo de la cadena de transporte
(aunque el valor de SOAP-ENV:actor lo designa directamente, por lo tanto como
consumidor exclusivo). En ese caso, el elemento en cuestin no se consumir por
ningn nodo intermedio y fallar en el destinatario, quien, en teora, no tiene el
derecho a consumirlo tampoco.
Vamos a suponer, por ejemplo, que nice.guy.net quiere enviar siempre la misma pequeapalabra a pretty.girl.net, pero que desea un servicio de envo recomendado (garantizado).
Desea en realidad que el servicio postal Web utilice un protocolo de transporte garantizado
para transmitir su mensaje al destinatario. Si el servicio postal Web no llega por una razn
cualquiera a hacer llegar el mensaje al destinatario, debe informar al expeditor. El envo
recomendado es un servicio normalizado por www.postalstandards.org (cuyo vocabulario
XML se define por http://www .postalstandards.org/smartservices/, relativo a la nueva versin
de servicios postales) ofrecido, entre otras cosas, por office.smartpservice.com. Por otra parte,
nice.guy.net desea que el servicio est prestado por office.smartpservice.com.
Figura 7: Una cadena de transporte con un solo intermediario (II).
A continuacin, se muestra el mensaje A en este nuevo contexto (figura 7, que se distingue de
la figura 6 solo por el nombre del intermediario).
http://www.postalstandards.org/reliableSend
http://nice.guy.net/letter#000001
http://nice.guy.net/http://nice.guy.net/home.jsp
-
7/22/2019 Soap Parte1
19/32
http://pretty.girl.net/
http://pretty.girl.net/home.asp
Tenemos en cuenta inmediatamente que, para obtener tal servicio, nice.guy.net debe marcar el
mensaje con un nico identificador que debe recordarse en caso de problemas. Utiliza para
esto el URI http://nice .guy.net/letter#000001 como valor del elemento pss:id.
office.smartpservice.com es efectivamente capaz de garantizar el servicio y en consecuencia:
1. recorre el encabezado del mensaje;
2. define el valor de SOAP-ENV:actor en la entrada pss: postmark como su propio URI;
3. notemos que la accin solicitada es el envo recomendado del mensaje (designada por
el URI http://www .postalstandards.org/reliableSend);
4. notemos tambin el identificador del mensaje, valor del elemento pss: id;
5. el valor del elemento pss:receiverPort;
6. ignora el elemento SOAP-ENV: Body;
7. construye un nuevo mensaje en el cual la entrada pss:postmark es modificada: los
atributos SOAP-ENV:actor y SOAP-ENV:mustUnderstand, as como el elemento pss:
acction y pss: senderPort son suprimidos. En cambio, los elementos pss: sender y pss:
receiver, su propio URI as como la fecha y la hora de recepcin del mensaje se
aaden;
8. enva el nuevo mensaje sobre el puerto de recepcin http://pretty.girl.net/home.asp
utilizando su protocolo garantizado.
El mensaje A' (figura 7), transmitido por office.smartpservice.com a pretty.girl.net,
transportado por su protocolo garantizado, es pues el siguiente:
http://office.smartpservice.com/
-
7/22/2019 Soap Parte1
20/32
2010-06-30T23:59:59
http://www.postalstandards.org/reliableSend
http://nice.guy.net/
http://pretty.girl.net/http://pretty.girl.net/home.asp
Vamos a suponer que, si office.smartpservice.com est en condiciones de garantizar el
servicio de envo recomendado, office.postalservice.com an no implemento los nuevos
servicios de intercambio fiable (http://www.postalstandards.org/smartservices/), especificados
por la organizacin interprofesional a la cual se adhiere con office.smartpservice.com. Si un
mensaje como el precedente le era enviado por nice.guy.net, la especificacin SOAP 1.1 lo
obligara a rechazar el mensaje y, eventualmente, a devolver un mensaje de error al
(expeditor) remitente.
Se encuentra que office.postalservice.com est en relacin de asociacin conoffice.smartpservice.com, que garantiza el servicio de envo recomendado. En efecto,
office.postalservice.com reenva los mensajes a su socio en caso de peticin de envo
recomendado.
Una cadena de transporte ms tolerante puede implementarse segn el esquema de la figura 8.
Figura 8: Cadena de transporte con recodo.
Para implementar esta cadena de transporte, es necesario operar dos cambios:
para evitar la restriccin SOAP-ENV:mustUnderstand=" 1" : basta para esto retirar elatributo SOAP-ENV: mustUnderstand;
-
7/22/2019 Soap Parte1
21/32
sustituir como valor de SOAP-ENV: actor el URI http://office.smartpservice.com/ por
el URI genrico http://schemas.xmlsoap.org/soap/actor/next.
A continuacin se muestra el mensaje emitido por nice.guy.net para office.postalservice.com:
http://www.postalstandards.org/reliableSendhttp://nice.guy.net/letter#000001
http://nice.guy.net/
http://nice.guy.net/home.jsp
http://pretty.girl.net/http://pretty.girl.net/home.asp
office.postalservice.com recibe pues este mensaje enviado por nice.guy.net.
office.postalservice.com es destinatario de la entrada de encabezad pss: postmark, pero
se da cuenta de que no es capaz de tratar esta entrada del encabezado que se le destina.
En vez de rechazar el mensaje y devolver un mensaje de error al expeditor (se forzara
a actuar as con SOAP-ENV: mustUnderstand=" 1" en la entrada del encabezado), esta
vez, enva exactamente el mismo mensaje a office.smartpservice.com que se comporta
exactamente como lo describimos anteriormente.
El cuerpo
El cuerpo de un mensaje SOAP 1.1 es producido por el expeditor del mensaje y
consumido obligatoriamente por el destinatario, independientemente del nmero de
nodos intermedios que son susceptibles de transportar el mensaje. Lo mismo ocurre
con los elementos facultativos y que siguen el cuerpo.
El elemento cuerpo est obligatoriamente presente en un mensaje SOAP 1.1 como
descendiente directo del elemento envelope, siguiendo inmediatamente el elemento
encabezado (presente) y seguido eventualmente por los elementos proprietarios.
-
7/22/2019 Soap Parte1
22/32
El elemento cuerpo puede contener un conjunto de elementos descendientes, que
pueden ser calificados por la referencia a uno o a ms espacios de nombres. Estos
elementos se llaman entradas del cuerpo.
El elemento cuerpo puede tambin contener un elemento SOAP 1.1 error (SOAP-ENV:
Fault), que es definido por la especificacin, para tratar los casos de error.
La especificacin SOAP 1.1 sugiere considerar el cuerpo como semnticamente equivalente a
una entrada del encabezado sin atributo SOAP-ENV:actor (y en consecuencia destinado al
consumo del destinatario) y con el atributo SOAP-ENV:mustUnderstand=" 1". Esto quiere
decir, entre otras cosas, que si el destinatario no est en condiciones de consumir el cuerpo,
debe rechazar el mensaje y, si l tiene la posibilidad, debe devolver un mensaje de error al
emisor.
La gestin de los errores en SOAP 1.1
El error SOAP 1.1 se produce siempre debido a una incapacidad del nodo receptor del
mensaje SOAP 1.1 que debe consumir el mensaje o la parte del mensaje que se le destina.
Esta incapacidad puede deberse:
ya sea a un defecto sintctico o semntico del mensaje;
o a un fallo del nodo receptor en el tratamiento del mensaje.
El mensaje recibido implicado en una situacin de error se llamar mensaje en error(faulty
message). Un mensaje en error es pues o un mensaje sintctica o semnticamente incorrecto,
o bien un mensaje correcto cuyo tratamiento fall debido a un fallo del nodo receptor.
La especificacin SOAP 1.1 menciona las circunstancias en las cuales el receptor de un
mensaje SOAP 1.1 reconoce una situacin de errorasociada al mensaje recibido (mensaje en
error), as como las circunstancias en las cuales el receptor de un mensaje en error indica una
situacin de error. Esta descripcin personal puede tomar la forma de la transmisin de un
mensaje de error (fault message) a la intencin del emisor inicial. El mensaje de error
contiene siempre informacin sobre la naturaleza del error para el emisor del mensaje en
error. La especificacin SOAP precisa el formato y el contenido del mensaje de error.
La gestin de los errores SOAP 1.1 incluye pues tres etapas distintas:
1. el tratamiento del mensaje en error por su receptor;
2. la descripcin personal del error y la produccin y la emisin del mensaje de error
correlacionado al mensaje en error;
3. la recepcin del mensaje de error por parte del emisor del mensaje en error.
El tratamiento del mensaje en error
La incapacidad por parte del receptor que debe consumir el mensaje en error (las partes que se
le destinan para consumo) debe traducirse, en casos puntuales (ver la descripcin de los tipos
de errores SOAP 1.1 en la seccin ), en el rechazo del mensaje porparte del receptor o en el fracaso de su tratamiento.
-
7/22/2019 Soap Parte1
23/32
Sin embargo, la especificacin SOAP 1.1 no precisa la semntica operativa del rechazo del
mensaje o el fracaso del tratamiento. El emisor del mensaje en error no est autorizado a
obtener ciertas conclusiones sobre el tratamiento total o parcial del mensaje en error y sobre
sus consecuencias. Es pues posible que los cambios de estado y/o efectos de borde se hayan
producido a raz del tratamiento del mensaje en error por el receptor.
La situacin ideal sera que:
El receptor del mensaje en error completa el anlisis sintctico y semntico del
mensaje en error antes de desencadenar todo tratamiento que produce los cambios de
estado y las consecuencias de los efectos de borde del consumo del mensaje.
El receptor implementa una gestin transaccional de los tratamientos que producen los
cambios de estado y las consecuencias de los efectos de borde del consumo del
mensaje. La gestin transaccional permite tratar correctamente los casos de fallo
(panne franche) del receptor.
El sealamiento del error
El receptor debe indicar la situacin de error consiguiente a la recepcin de un mensaje en
error por todos los medios a su disposicin (levantamiento de una excepcin, visualizacin
sobre una consola de usuario o administrador, produccin de un diario de navegacin, etc.).
La emisin de un mensaje de error para el emisor del mensaje en error es uno de estos
medios. La especificacin SOAP 1.1 define las modalidades de este medio de sealamiento y
deja la implementacin de los nodos SOAP las otras modalidades.
Las capacidades de emisin y recepcin de los mensajes SOAP 1.1
El receptor puede ser incapaz de emitir mensajes SOAP 1.1 (es un puro receptor UDP, por
ejemplo) o puede ser capaz de emitir mensajes SOAP 1.1 solamente en circunstancias
particulares (es un servidor sobre un protocolo de transporte bidireccional como HTTP, capaz
de recibir peticiones y emitir respuestas correlacionadas: en ese caso, puede utilizar la
respuesta para transportar el mensaje de error).
El punto determinante es por lo tanto la capacidad de emisin de mensajes SOAP 1.1, y en
consecuencia de mensajes de error, por parte del receptor del mensaje en error. Podemos
distinguir cuatro clases bsicas para los nodos SOAP 1.1, con relacin a sus capacidades deemisin/recepcin de mensajes SOAP 1.1:
Emisor SOAP 1.1 es un nodo que tiene una capacidad de emisin de mensajes de
direccin nica SOAP 1.1.
ReceptorSOAP 1.1 es un nodo que tiene una capacidad de recepcin de mensajes de
direccin nica SOAP 1.1.
ClienteSOAP 1.1 es un nodo que tiene una capacidad de emisin de peticiones SOAP
1.1 y de recepcin de respuestas SOAP 1.1 correlacionadas a las peticiones emitidas.
Servidor SOAP 1.1 es un nodo que tiene una capacidad de recepcin de peticiones
SOAP 1.1 y de emisin de respuestas SOAP 1.1 correlacionadas a la peticin recibida.
-
7/22/2019 Soap Parte1
24/32
Las capacidades de emisin/recepcin de un nodo SOAP 1.1 resultan de la combinacin de
estas clases bsicas.
La correlacin entre mensaje en error y mensaje de error
La correlacin entre mensaje en error y mensaje de error es un elemento esencial delmecanismo de gestin de los errores SOAP: un mensaje de error es una herramienta
computacional y slo cumple su rol si se correlaciona de manera no ambigua al mensaje en
error que lo caus.
Por otra parte, la correlacin directa e implcita entre un mensaje en error y un mensaje de
error slo es posible entre un cliente y un servidor SOAP 1.1, en el estilo de intercambio
peticin/respuesta, cuando el mensaje en error es la peticin SOAP. En ese caso, el mensaje
de error sustituye a la respuesta al mensaje (peticin) en error y la correlacin est garantizada
por el estilo de intercambio.
Aparte de este caso preciso, la correlacin mensaje en error y mensaje de error, como aquella
entre los mensajes en una , no puede ser obtenida ms que por un protocolo
aplicativo que permite dotar cada mensaje de un nico identificador. Se recuerda este
identificador explcitamente cada vez que es necesario establecer una correlacin con otro
mensaje.
Por otra parte, aunque en la especificacin, la emisin de un mensaje de error parece siempre
vinculada al acto previo de un error, no excluye emitir un mensaje de error
independientemente de una situacin de error, para indicar un estado (notificacin de status).
La notificacin de status sirve para indicar una situacin corriente (status) de fallo de un
nodo, sobre iniciativa del propio nodo. Se podra uno imaginar, por ejemplo, que
office.postalservice.com enva a sus clientes, a su iniciativa, un mensaje de error sobre la no
disponibilidad temporal de sus servicios y, a continuacin, sobre el restablecimiento del
funcionamiento normal. La tabla 1 resume las actitudes de los nodos con relacin a la
recepcin y al tratamiento de un mensaje en error y al envo de un mensaje.
-
7/22/2019 Soap Parte1
25/32
Gestin de
error
SOAP 1.1
Nodo SOAP
1.1
Capacidad de
recepcin mensaje
en error
Tratamiento
mensaje
en error
Capacidad de emisin
mensaje de error
correlacionado
Capacidad
de emisin
mensaje de error
no
correlacionado
(status)
Emisor NO (no aplicable) (no aplicable) SI (emisin de
un
mensaje de
error)
Receptor SI Rechaza mensaje
o
tratamiento de
fracaso
NO NO
Cliente SI (mensaje en
error en unarespuesta)
Rechaza mensaje
otratamiento de
fracaso
SI (inclusin del mensaje
de error correlacionado enla respuesta al mensaje en
error)
NO
Servidor SI (mensaje en
error en una peticin
explcitamente
correlacionada con
un mensaje de un
intercambio anterior.
Rechaza mensaje
o tratamiento de
fracaso
SI (inclusin del mensaje
de error correlacionado en
la respuesta al mensaje en
error)
NO
Tabla 1: Resumen de las capacidades de emisin/recepcin de un menaje de error por losnodos SOAP 1.1.
El elemento error (SOAP-ENV:fault)
El elemento error (SOAP-ENV:Fault) del cuerpo de un mensaje SOAP 1.1 est destinado a
transportar una informacin de error o de estado.
La especificacin SOAP 1.1 precisa que el elemento error es obligatoriamente una entrada del
cuerpo. Esta entrada puede estar presente a lo ms una vez en el cuerpo de un mensaje SOAP
1.1. Puede ser la nica entrada o estar acompaada de otras entradas del cuerpo.
La especificacin SOAP 1.1 define cuatro subelementos de la entrada error (SOAP-
ENV:Fault):
el elemento cifrado de error (faultcode);
el elemento expresado de error (faultstring);
el elemento expeditor del mensaje de error (faultactor);
el elemento detalle de error (detail).
La especificacin SOAP 1.1 no excluye la presencia de elementos aplicativos cuyos nombres
pertenecen a los vocabularios XML aplicativos como descendientes directos de SOAP-ENV:Fault.
-
7/22/2019 Soap Parte1
26/32
El elemento cifrado de error (faultcode)
El elemento cifrado de error (faultcode) transporta una informacin sobre el error encontrado
que se destina tpicamente a la explotacin por programa. El elemento faultcode est
obligatoriamente presente en el elemento SOAP-ENV:Fault y su valor debe ser un nombre
calificado.
SOAP 1.1 define cuatro tipos de errores, cada uno designado por un , bajo el
formato de un nombre calificado por el vocabulario XML:
http://schemas.xmlsoap.org/soap/envelope/.
Los cdigos de errores SOAP 1.1 son:
SOAP-ENV:VersionMismatch: el cdigo indica que el vocabulario XML de las
balizas (marcas) de estructura (Envelope, Header, Body, Fault) del mensaje en error
no es el de SOAP 1.1 (http://schemas .xmlsoap.org/soap/envelope/); SOAP-ENV:MustUnderstand: el cdigo indica que el emisor del mensaje de error
recibi como mensaje en error un mensaje que se ve obligado a tratar (SOAP-ENV:
mustUnderstand=" 1") y que no es funcionalmente capaz de tratar;
SOAP-ENV:Client: el cdigo indica que el mensaje en error est sintctica y/o
semnticamente incorrecto: ya sea mal formado, o no contiene la informacin
apropiada para estar convenientemente tratado;
SOAP-ENV:Server: el mensaje en error no pudo tratarse debido a un fallo tcnico o
aplicativo del nodo receptor: este ltimo cdigo puede tambin utilizarse para
notificaciones de status.
Los cdigos de errores SOAP 1.1 pueden ser, segn la especificacin, especializados por un
sufijo (separado por un punto), por ejemplo: SOAP-ENV:Client.Authentication.
El cdigo de error de arriba indica que el error es un error SOAP 1.1, de la clase Client, con
una especialidad Authentication. El sentido de este cdigo, resultante de un acuerdo privado
entre los interlocutores, es que el error viene de un problema de autenticacin del nodo emisor
del mensaje en error.
El elemento expresado de error (faultstring)
El elemento expresado de error (faultstring) est destinado tpicamente a proporcionar una
explicacin del error comprensible por los actores humanos (generalmente, los diseadores y
los administradores de servicios Web). Est obligatoriamente presente en el elemento SOAP-
ENV:Fault.
El elemento expeditor del mensaje de error (faultactor)
El elemento expeditor del mensaje de error (faultactor) est destinado a proporcionar
informacin sobre el nodo expeditor del mensaje de error. Su valor es un URI.
-
7/22/2019 Soap Parte1
27/32
La presencia de tal elemento es obligatoria si el expeditor del mensaje de error es un nodo
intermediario en la cadena de transporte del mensaje. Si tal elemento est ausente, eso quiere
decir que el expeditor del mensaje de error es el destinatario del mensaje en error.
El elemento detalle de error (detalle)
El elemento detalle del error (detail) est destinado a proporcionar informacin de origen
aplicativo sobre el error ocurrido. Si el error ocurri en el tratamiento del cuerpo del mensaje
en error, el elemento detailest obligatoriamente presente en el mensaje de error. En cambio,
la ausencia de este elemento indique que el error no ocurri en el tratamiento del cuerpo del
mensaje en error.
Por otra parte, detail no debe utilizarse para transportar informacin sobre los errores
ocurridos en el tratamiento de las entradas del encabezado.
El elemento detailpuede contener sub-elementos llamados entradas del detalle. Cada entrada
del detalle es independiente de las otras, posee un nombre calificado, y el atributo SOAP 1.1SOAP-ENV:encodingStyle puede utilizarse para indicar el estilo de codificacin de las
entradas del detalle.
Los tipos de errores
Vamos a ilustrar el uso de los cdigos de errores mediante un ejemplo en el cual el mensaje
en error se presenta a un intermediario en la cadena de transporte (ver la figura 9). En efecto,
el destinatario del mensaje en error A es, en todos los casos de errores tratados, pretty.girl.net.
Esto nos permite dar ms generalidad y completes al ejemplo. Hay que sealar que el uso del
elementofaultactores obligatorio en tal situacin ya que el expeditor del mensaje de error no
es el destinatario del mensaje en error.
Figura 9: La cadena interrumpida por un error (I).
El cdigo SOAP-ENV:VersionMismatch
El valor SOAP-ENV:VersionMismatch de faultcode indica que el vocabulario XML de las
marcas de estructura del mensaje en error no es http://schemas.xmlsoap.org/soap/envelope/.
En SOAP 1.1, el vocabulario http://schemas.xmlsoap.org/soap/envelope/ es el nico aceptable
para las marcas de estructura (Envelope, Header, Body, Fault) e indica que el mensaje se
ajusta a la especificacin SOAP 1.1.
En el ejemplo presentado en la figura 9, nice.guy.net enva a office.postalservice.com elmensaje A siguiente, teniendo como destinatario pretty.girl.net:
-
7/22/2019 Soap Parte1
28/32
El vocabulario XML para los nombres de las marcas de estructura es el asociado a la
especificacin SOAP 1.0. office.postalservice.com es un nodo SOAP 1.1, y reacciona pues
por el rechazo del mensaje A (y en consecuencia la negativa a transportarlo hacia
pretty.girl.net) y el envo a nice.guy.net del mensaje de error siguiente B (ver figura 9):
SOAP-ENV:VersionMismatchSoap 1.0 is not supported.
http://office.postalservice.com/
El cdigo SOAP-ENV:MustUndestand
El cdigo SOAP-ENV:MustUnderstand de faultcode indica que el emisor del mensaje de
error recibi como mensaje en error un mensaje que contiene un elemento:
que se designa a consumidor (el valor explcito o por defecto de SOAP-ENV: actor lo
designa);
que tiene la obligacin de tratar (SOAP-ENV:mustUnderstand=" 1") ;
y que no es funcionalmente capaz de tratar () el elemento en
cuestin.
Recordamos que si este elemento es:
una entrada del encabezado, el consumidor designado es ya sea un nodo en la cadena
de transporte explcitamente designada por SOAP-ENV:actor, o ya sea, a falta de
SOAP-ENV:actor, el destinatario;
el cuerpo (o uno de sus descendientes), el consumidor designado es el destinatario, con
obligacin de siempre el elemento (lo que es equivalente, para las
entradas del encabezado, a SOAPENV:mustUnderstand=" 1").
-
7/22/2019 Soap Parte1
29/32
-
7/22/2019 Soap Parte1
30/32
http://www.postalstandards.org/send
http://nice.guy.net/
office.postalservice.com no puede proporcionar la prestacin:
http://www.postalstandards.org/send ya que los datos del destinatario:
http://pretty.girl.net/
http://pretty.girl.net/home.asp
no se especifican en el mensaje. Rechaza pues el mensaje A y enva a nice.guy.net el mensaje
de error B (ver figura 9):
SOAP-ENV:Client
Missing routing datahttp://office.postalservice.com/
Missing last receivers name and address
El cdigo SOAP-ENV:Server
El cdigo SOAP-ENV:Server de faultcode indica que el mensaje en error no pudo tratarse
debido a un fallo tcnico o aplicativo del nodo receptor. El fallo puede ocurrir en cualquier
momento del tratamiento: si el receptor considera que es pertinente correlacionar el fallo con
la recepcin del mensaje en error, este responde con un mensaje de error.
-
7/22/2019 Soap Parte1
31/32
Vamos a reconsiderar el ejemplo de nice.guy.net que solicita un envo recomendado, por
medio de office.smartpservice.com, a pretty.girl.net (figura 10, la cual se distingue de la
figura 9 solamente por el URI del intermediario).
Figura 10: La cadena interrumpida por un error (II).
nice.guy.net transmite el mensaje A (figura 10) siguiente a office.smartpservice.com con una
peticin de envo recomendado del mensaje a pretty.girl.net:
http://www.postalstandards.org/reliableSend
El servicio de envo recomendado de oficce.smartpservice.com se construye sobre una
arquitectura de colas persistentes de mensajes. El servidor que debe efectuar la transferencia
del mensaje hacia pretty.girl.net est temporalmente fuera de servicio debido al
desbordamiento de la cola de espera de los mensajes que deben transportarse.
office.smartpservice .com rechaza el mensaje A y enva a nice.guy.net el mensaje de errorsiguiente B (figura 10):
SOAP-ENV:Server Message queue overflow
http://office.smartpservice.com/
Try later
-
7/22/2019 Soap Parte1
32/32
La gestin de las situaciones de error de tipo VersionMismatch, MustUnderstand y Client nosignifica un problema particular, ya que estas situaciones son detectables con el simple
anlisis del mensaje en error. Es posible que el receptor del mensaje en error siga
estrictamente las consignas del perfil de base WS-I, es decir rechazar el mensaje (y enviar
eventualmente un mensaje de error) inmediatamente despus de anlisis y antes de todo
tratamiento. El acto de comunicacin transportado por el mensaje est en fracaso y no hay
efectos del acto sobre el receptor, excepto los efectos tcnicos de tipo inscripcin en el diario
de explotacin.
En cambio, la gestin de las situaciones de error de tipo Server puede revelarse mucho ms
delicada. En estas situaciones, se realizan las condiciones de xitodel acto de comunicacin y
son las condiciones de satisfaccindel mismo acto que no lo son. El ejemplo anterior no tienealgn problema particular ya que la situacin despus de levantamiento del error es lo mismo
que antes del envo del mensaje A.
Pero en el caso ms general, el pragmtico (los efectos sobre el receptor) del acto de
comunicacin transportado por el mensaje puede implicar cambios de estados y efectos de
borde que se efectan como consecuencias de la recepcin del mensaje en error, pero antes de
que la situacin de error Server se declara.
Cul es el estatuto de estos cambios de estado y estos efectos de borde despus del fallo y
reconocimiento por parte del receptor de la situacin de error Server correlacionada con el
mensaje en error? La gestin de los tratamientos asociados a la recepcin de un mensaje como
una unidad de trabajo transaccional permite solucionar el problema. La gestin transaccional
de los tratamientos asociados a la recepcin de los mensajes traen la situacin de
insatisfaccin del acto de comunicacin a la situacin de fracaso del mismo acto: es como si
el acto no se haba efectuado nunca.