Intercambiar con un servicio- Formato del mensaje

Objetos, servicios, documentos El 10 de febrero de 1998, el World Wide Web Consortium (W3C) publica una <<recomendacin>> 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 XMLRPC. 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 <<RPC en Internet por XML sobre HTTP>>. 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 <<servicios Web>>, 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 de cortafuegos, otros protocolos IP (como el protocolo Internet Inter ORB o el IIOP especificado

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 <<por defecto>> y expone cualquier aplicacin, al menos, al riesgo de la saturacin de las 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 se opera, 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/SOAPattachments). 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 reconocido consiste 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 tecnologas radicalmente diferentes y concurrentes.

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 los servicios 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 <<simple>> 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 <<objeto>>: esta opcin tcnica no es un accidente, ni el producto de la ignorancia u hostilidad para el enfoque <<objeto>>, sino una voluntad precisa de los diseadores de SOAP, los cuales son todos expertos de las arquitecturas orientadas a objetos distribuidos. En realidad, la <<no objetividad>> 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.

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 red local 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 identificador tcnico (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), <<componente>> 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 <<arquitectura de objetos distribuidos>>, 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 desempean respectivamente 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 a objetos eligi exponer como interlocutor de la llamada distante una granularidad de tipo

<<servicio>> ms bien que <<objeto>>. Por otra parte, cuando el lenguaje de implementacin no es <<objeto>>, el enfoque <<servicio>> se impone naturalmente. Objetos por valor y documentos La dificultad de tratar los objetos por referencia en las arquitecturas distribuidas es la causa de evolucin 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 mtodo sobre objetos distantes, una regla de <<serializacin>> 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).

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 la respuesta es un <<documento>> 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 para garantizar 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 <<ligero>> o, ms concretamente, <<no intrusivo>>. 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 las tecnologas y protocolos de interaccin de las aplicaciones distribuidas en la Web. Esta

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 <<perfiles>>. 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 cuatro tecnologas 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 <<genrica>>) 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);

 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 estas caractersticas, 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 intercambio posibles, que se basan todos en un nico y slo uno (aunque extensible) formato de 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 ser transferido 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.

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.

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: <?xml version="1.0" encoding="UTF-8"?> <Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/"> <Body> <Greeting> <text>Ciao !</text> </Greeting> </Body> </Envelope> Un mensaje puede transferirse directamente del expeditor al destinatario, o bien transitar por un nmero ilimitado de nodos intermedios que 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

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. El productor de 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 consumidor de 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 <<capaz>> de efectuar este consumo, debe efectuarlo, y si no es <<capaz>>, 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: <?xml version=1.0 ?> 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

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): <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <g:Greeting xmlns:g="http://www.greetings.org/greetings/"> <g:text>Ciao !</g:text> </g:Greeting> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 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 un DTD 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 <<documento>> (raz), es decir el envelope (SOAP-ENV:Envelope),

que contiene un elemento encabezado (SOAP-ENV:Header) opcional y 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 <<documento>> (raz) de todo mensaje SOAP 1.1. <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" > </SOAP-ENV:Envelope> En el envelope de un mensaje SOAP 1.1, la presencia de la declaracin del vocabulario XML SOAP 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

muestra una versin del protocolo diferente de SOAP 1.1, un nodo SOAP 1.1 se debe rechazarlo y eventualmente enviar inmediatamente un mensaje de error SOAP 1.1. (cdigo de error SOAP-ENV: VersionMismatch - la gestin de los errores se enumerar en la seccin <<la gestin de los errores en SOAP 1.1>>). El envelope puede contener: otras declaraciones de espacios de nombres; otros atributos, cuya presencia es obviamente facultativa, pero su calificacin por el identificador de un espacio de nombres es, en cambio, obligatoria; se sitan otros subelementos cuya presencia es facultativa, pero su calificacin por el identificador de un espacio de nombres es obligatoria y su posicin obligatoriamente despus del elemento cuerpo (ver 5). El encabezado El encabezado es un elemento opcional. Si est presente en un mensaje SOAP 1.1, debe ser un descendiente directo del elemento envelope y colocado como el primero de la secuencia de los descendientes directos. Puede contener varios elementos descendientes directos que se llaman entradas del encabezado. Todas las balizas (marcas) de las entradas del encabezado deben ser nombres calificados. El encabezado proporciona el mecanismo general y flexible que permite aadir nuevas y especializadas caractersticas a un mensaje SOAP 1.1. Estas adiciones pueden efectuarse dinmicamente, mediante la adicin de elementos del encabezado, de manera descentralizada y modular, sin acuerdo preventivo de los participantes en la cadena de transporte, durante el ciclo de transmisin de un mensaje. Dos atributos reservados por la especificacin SOAP 1.1 (atributos de encabezado) permiten indicar: el participante en la cadena de transporte que es el consumidor designado del elemento del encabezado del mensaje (atributo SOAP-ENV:actor); si el consumo del elemento es obligatorio o facultativo para el consumidor designado (atributo SOAP-ENV:mustUnderstand). La especificacin SOAP 1.1 considera explcitamente que las entradas del encabezado se destinan a la aplicacin de capas superiores y transversales de la tecnologa de los servicios Web, como la gestin de las cadenas de transporte, la gestin de las transacciones, la gestin de la seguridad, etc La especificacin recomienda la utilizacin sistemtica de los atributos SOAP-ENV:actor et SOAPENV:mustUnderstand. El atributo SOAP-ENV:actor El atributo SOAP 1.1 SOAP-ENV:actor en una entrada del encabezado se utiliza para designar el consumidor de la entrada del encabezado. El valor del atributo SOAP-ENV:actor es un URI.

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 el destinatario 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: <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header> <pbs:postmark xmlns:pbs="http://www.postalstandards.org/basicservices/" SOAP-ENV:actor="http://office.postalservice.com/"> <pbs:action>http://www.postalstandards.org/send</pbs:action> <pbs:sender> <pbs:senderURI>http://nice.guy.net/</pbs:senderURI> </pbs:sender> <pbs:receiver> <pbs:receiverURI>http://pretty.girl.net/</pbs:receiverURI> <pbs:receiverPort>http://pretty.girl.net/home.asp</pbs:receiverPort> </pbs:receiver> </pbs:postmark> </SOAP-ENV:Header>

<SOAP-ENV:Body> <g:Greeting xmlns:g="http://www.greetings.org/greetings/"> <g:text>Ciao !</g:text> </g:Greeting>

</SOAP-ENV:Body> </SOAP-ENV:Envelope>

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: el atributo 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: <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" > <SOAP-ENV:Header> <pbs:postmark xmlns:pbs="http://www.postalstandards.org/basicservices/"> <pbs:postmarker> <pbs:postmarkerURI> http://office.postalservice.com/ </pbs:postmarkerURI> </pbs:postmarker> <pbs:dateTime>2010-06-30T23:59:59</pbs:dateTime> <pbs:action>http://www.postalstandards.org/send</pbs:action> <pbs:sender> <pbs:senderURI>http://nice.guy.net/</pbs:senderURI> </pbs:sender> <pbs:receiver> <pbs:receiverURI>http://pretty.girl.net/</pbs:receiverURI> <pbs:receiverPort>http://pretty.girl.net/home.asp</pbs:receiverPort> </pbs:receiver> </pbs:postmark> </SOAP-ENV:Header> <SOAP-ENV:Body> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

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 <<en duro>> 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: <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" > <SOAP-ENV:Header> <pbs:postmark xmlns:pbs="http://www.postalstandards.org/basicservices/" SOAP-ENV:actor="http://schemas.xmlsoap.org/soap/actor/next"> </pbs:postmark> </SOAP-ENV:Header> <SOAP-ENV:Body> </SOAP-ENV:Body> </SOAP-ENV:Envelope> La ventaja de este enfoque es evidente: el mensaje <<no conoce>> 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 SOAPENV:mustUnderstand=" 1" debe consumir el elemento en cuestin. Si es <<incapaz>>

(el sentido de esta <<incapacidad>> 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 SOAPENV:mustUnderstand=" 1" , que es <<incapaz>> 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 receptor es 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 pequea palabra 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). <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" > <SOAP-ENV:Header> <pss:postmark xmlns:pss="http://www.postalstandards.org/smartservices/" SOAP-ENV:actor="http://office.smartpservice.com/" SOAP-ENV:mustUnderstand="1"> <pss:action>http://www.postalstandards.org/reliableSend</pss:action> <pss:id>http://nice.guy.net/letter#000001</pss:id> <pss:sender> <pss:senderURI>http://nice.guy.net/</pss:senderURI> <pss:senderPort>http://nice.guy.net/home.jsp</pss:senderPort>

</pss:sender> <pss:receiver> <pss:receiverURI>http://pretty.girl.net/</pss:receiverURI> <pss:receiverPort>http://pretty.girl.net/home.asp</pss:receiverPort> </pss:receiver> </pss:postmark> </SOAP-ENV:Header> <SOAP-ENV:Body> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 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: <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" > <SOAP-ENV:Header> <pss:postmark xmlns:pss="http://www.postalstandards.org/smartservices/"> <pss:postmarker> <pss:postmarkerURI> http://office.smartpservice.com/

</pss:postmarkerURI> </pss:postmarker> <pss:dateTime>2010-06-30T23:59:59</pss:dateTime> <pss:action>http://www.postalstandards.org/reliableSend</pss:action> <pss:sender> <pss:senderURI>http://nice.guy.net/</pss:senderURI> </pss:sender> <pss:receiver> <pss:receiverURI>http://pretty.girl.net/</pss:receiverURI> <pss:receiverPort>http://pretty.girl.net/home.asp</pss:receiverPort> </pss:receiver> </pss:postmark> </SOAP-ENV:Header> <SOAP-ENV:Body> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 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 con office.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 el atributo SOAP-ENV: mustUnderstand;

 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: <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" > <SOAP-ENV:Header> <pss:postmark xmlns:pss="http://www.postalstandards.org/smartservices/" SOAP-ENV:actor="http://schemas.xmlsoap.org/soap/actor/next"> <pss:action>http://www.postalstandards.org/reliableSend</pss:action> <pss:id>http://nice.guy.net/letter#000001</pss:id> <pss:sender> <pss:senderURI>http://nice.guy.net/</pss:senderURI> <pss:senderPort>http://nice.guy.net/home.jsp</pss:senderPort> </pss:sender> <pss:receiver> <pss:receiverURI>http://pretty.girl.net/</pss:receiverURI> <pss:receiverPort>http://pretty.girl.net/home.asp</pss:receiverPort> </pss:receiver> </pss:postmark> </SOAP-ENV:Header> <SOAP-ENV:Body> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

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 <<proprietarios>> 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.

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 error asociada 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 <<los tipos de errores>>), en el rechazo del mensaje por parte del receptor o en el fracaso de su tratamiento.

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 de emisin/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. Receptor SOAP 1.1 es un nodo que tiene una capacidad de recepcin de mensajes de direccin nica SOAP 1.1. Cliente SOAP 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.

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 del mecanismo 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 <<conversacin>>, 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.

Gestin de error SOAP 1.1 Nodo SOAP 1.1 Emisor

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) SI (emisin de un mensaje de error) NO

NO

(no aplicable)

(no aplicable)

Receptor

SI

Cliente

SI (mensaje en error en una respuesta) SI (mensaje en error en una peticin explcitamente correlacionada con un mensaje de un intercambio anterior.

Servidor

Rechaza mensaje o tratamiento de fracaso Rechaza mensaje o tratamiento de fracaso Rechaza mensaje o tratamiento de fracaso

NO

SI (inclusin del mensaje de error correlacionado en la respuesta al mensaje en error) SI (inclusin del mensaje de error correlacionado en la respuesta al mensaje en error)

NO

NO

Tabla 1: Resumen de las capacidades de emisin/recepcin de un menaje de error por los nodos 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 (SOAPENV: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 SOAPENV:Fault.

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 <<cdigo>>, 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 SOAPENV: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.

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 detail est 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 detail puede 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.1 SOAP-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 elemento faultactor es 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 el mensaje A siguiente, teniendo como destinatario pretty.girl.net:

<?xml version="1.0" encoding="UTF-8"?> <SOAP10:Envelope xmlns:SOAP10="urn:schemas-xmlsoap-org:soap.v1"> <SOAP10:Header> </SOAP10:Header> <SOAP10:Body> </SOAP10:Body> </SOAP10:Envelope> 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): <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>SOAP-ENV:VersionMismatch</faultcode> <faultstring>Soap 1.0 is not supported.</faultstring> <faultactor>http://office.postalservice.com/</faultactor> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 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 (<<no comprende>>) 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 <<incluir>> siempre el elemento (lo que es equivalente, para las entradas del encabezado, a SOAPENV:mustUnderstand=" 1").

Consideremos el ejemplo, siempre ilustrado por la figura 9, en el cual nice.guy.net enva el mensaje A siguiente a office.postalservice.com (el destinatario es siempre pretty.girl.net): <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" > <SOAP-ENV:Header> <pss:postmark xmlns:pss="http://www.postalstandards.org/smartservices/" SOAP-ENV:actor="http://office.postalservice.com/" SOAP-ENV:mustUnderstand="1"> <pss:action>http://www.postalstandards.org/reliableSend</pss:action> </pss:postmark> </SOAP-ENV:Header> <SOAP-ENV:Body> </SOAP-ENV:Body> </SOAP-ENV:Envelope> En este mensaje, nice.guy.net solicita a office.postalservice.com tratar imperativamente el encabezado pss:postmark, calificado por el vocabulario XML http://www.postalstandars.org/smartservices, que designa las prestaciones de los servicios postales Web que no sabe proporcionar. (en particular, el envi certificado). office.postalservice.com rechaza el mensaje A (no lo transporta a pretty.girl.net) y enva a nice.guy.net el mensaje de error siguiente B (ver figura 9): <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>SOAP-ENV:MustUnderstand</faultcode> <faultstring>Misunderstood header entry</faultstring> <faultactor>http://office.postalservice.com/</faultactor> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope> El cdigo SOAP-ENV:Client El cdigo SOAP-ENV:Client de faultcode indica que ya sea que el mensaje en error est mal formado, o no contiene la informacin apropiada para estar convenientemente tratado (error sintctico o semntico). En el ejemplo siguiente, nice.guy.net enva a office.postalservice.com el mensaje A (ver figura 9), para que sea transportado a pretty.girl.net:

<?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" > <SOAP-ENV:Header> <pbs:postmark xmlns:pbs="http://www.postalstandards.org/basicservices/" SOAP-ENV:actor="http://office.postalservice.com/"> <pbs:action>http://www.postalstandards.org/send</pbs:action> <pbs:sender> <pbs:senderURI>http://nice.guy.net/</pbs:senderURI> </pbs:sender> </pbs:postmark> </SOAP-ENV:Header> <SOAP-ENV:Body> </SOAP-ENV:Body> </SOAP-ENV:Envelope> office.postalservice.com no puede proporcionar la prestacin: http://www.postalstandards.org/send ya que los datos del destinatario: <pbs:receiver> <pbs:receiverURI>http://pretty.girl.net/</pbs:receiverURI> <pbs:receiverPort>http://pretty.girl.net/home.asp</pbs:receiverPort> </pbs:receiver> 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): <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>SOAP-ENV:Client</faultcode> <faultstring>Missing routing data</faultstring> <faultactor>http://office.postalservice.com/</faultactor> <detail xmlns:d="http://office.postalservice.com/details"> <d:reason>Missing last receivers name and address</d:reason> </detail> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 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.

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: <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" > <SOAP-ENV:Header> <pss:postmark xmlns:pss="http://www.postalstandards.org/smartservices/" SOAP-ENV:actor="http://schemas.xmlsoap.org/soap/actor/next"> <pss:action>http://www.postalstandards.org/reliableSend</pss:action> </pss:postmark> </SOAP-ENV:Header> <SOAP-ENV:Body> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 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 error siguiente B (figura 10): <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>SOAP-ENV:Server</faultcode> <faultstring> Message queue overflow</faultstring> <faultactor>http://office.smartpservice.com/</faultactor> <detail xmlns:d="http://office.postalservice.com/details"> <d:suggestion>Try later</d:suggestion>

</detail> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope> La gestin de las situaciones de error de tipo VersionMismatch, MustUnderstand y Client no significa 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 xito del acto de comunicacin y son las condiciones de satisfaccin del mismo acto que no lo son. El ejemplo anterior no tiene algn 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.