Intercambiar con un servicio- Formato del mensaje

Transcripción

1 Intercambiar con un servicio- Formato del mensaje Objetos, servicios, documentos El 10 de febrero de 1998, el World Wide Web Consortium (W3C) publica una <<recomendación>> notable: Extensible Markup Language (XML) 1.0. A partir de su salida, XML demuestra una enorme polivalencia, utilizándose en aplicaciones que probablemente nunca habían pasado por la imaginación de sus primeros diseñadores. Se convierte rápidamente en el lenguaje universal de descripción de datos, estructurados y no estructurados. En la actualidad, las iniciativas de normalización en XML de los datos y documentos propios en los distintos sectores económicos, conducidos por las organizaciones profesionales y de los organismos de normalización, se cuentan por centenares. En la líneas de los grandes estándares Internet (IP, TCP, SMTP, HTTP, HTML ), XML se vuelve inevitable. Inmediatamente después de la publicación de la recomendación, 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 después de la publicación de la norma XML!) bajo el nombre de XML- RPC. Al mismo tiempo, nacen y se desarrollan en los laboratorios de R&D más de una decena de experiencias similares, a menudo en la esfera de influencia <<RPC en Internet por XML sobre HTTP>>. Para más detalles de XML-RPC, consultar la siguiente referencia: SOAP A partir de la publicación de XML-RPC, la actividad en torno a las especificaciones y tecnologías que constituyen hoy el conjunto de los <<servicios Web>>, se acelera y se diversifica. XML alcanza rápidamente una enorme popularidad y se vuelve cada vez más equipado : por analizadores sintácticos cada vez más rápidos; por la disponibilidad, en varios lenguajes de programación, de bibliotecas destinadas a manipulación de los documentos en memoria cuyo interfaz programática se ajusta al estándar DOM (Document Object Model), recomendación 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 población profesional que tiene un rol clave: los administradores de redes. En efecto, éstos controlan las técnicas y las herramientas de seguridad y, obviamente, las reservan para una recepción mitigada a la utilización, a través de cortafuegos, otros protocolos IP (como el protocolo Internet Inter ORB o el IIOP especificado

2 por el OMG y adoptado por el IETF, y como el Remote Method Invocation o RMI, el protocolo utilizado para la comunicación entre aplicaciones Java distribuidas). HTTP es un protocolo simple, robusto y adaptado al mundo abierto de Internet. Obviamente, su facilidad de utilización y su difusión tienen por corolario la apertura, que es propio de la Web <<por defecto>> y expone cualquier aplicación, al menos, al riesgo de la saturación de las llamadas (denial of service). Por a otra parte, si SSL ofrece una solución simple al problema de la confidencialidad de los intercambios sobre HTTP (HTTPS), las soluciones generalizadas a los problemas de seguridad (autenticación, autorización, confidencialidad, integridad, no repudio) están hoy en desarrollo. XML-RPC es la fuente de inspiración de SOAP (Simple Object Acces Protocol), definido por un equipo proveniente de Microsoft, con la participación 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 La iniciativa parece permanecer confinada en la esfera de influencia Microsoft, pero a principios del 2000 se opera, en el mercado de la tecnología, una dislocación de mucha importancia: IBM y su filial Lotus Development deciden trabajar con Microsoft con el fin de desarrollar juntos la versión 1.1 de la especificación SOAP, que es inscrita a continuación como una nota W3C en mayo de 2000 (ver Además Microsoft, IBM y su filial Lotus, un gran número de empresas apoyan esta oferta entre cuáles están: 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 inclusión de partes adjuntadas a los mensajes SOAP por la utilización de la estructura multi-partes MIME (multipart), utilizada sobre Internet para transportar documentos heterogéneos (ver Esta evolución permite el verdadero inicio de la tecnología de los servicios Web. IBM, uno de protagonistas principales de la industria informática, está obviamente muy interesado en la normalización y la aplicación 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 informática de gestión y constituye la punta de lanza tecnológica de una coalición heterogénea cuyo objetivo estratégico reconocido consiste en contradecir la expansión de Microsoft en el ámbito de las tecnologías informáticas relativas a los servidores. Ahora, IBM coopera, con su competidor histórico Microsoft, sobre la definición de un estándar de intercambio e interoperabilidad en la Web entre aplicaciones informáticas, desarrolladas sobre tecnologías que son, por construcción, heterogéneas. La presencia de IBM, que apuesta mucho sobre a la tecnología Java, a los lados de Microsoft, que va a proponer un mes después 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 tecnologías radicalmente diferentes y concurrentes.

3 En efecto, el simple hecho de que un protocolo de intercambio entre aplicaciones Web se base en dos estándares universalmente aceptados, como XML y HTTP, no basta sin embargo a garantizar la independencia de este protocolo de las tecnologías aplicadas en el desarrollo de aplicaciones que lo utilizan. SOAP 1.1 permite el intercambio entre aplicaciones construidas sobre tecnologías heterogéneas, porque se concibió para eso. Por otra parte, los propios límites de interoperabilidad del protocolo SOAP, que resultan de derivados propietarios de interpretación de especificaciones, a los cuales mencionaremos posteriormente, muestran bien la dificultad paradójica de garantizar el comportamiento del compromiso de interoperabilidad por una tecnología, en cuestión, de allí el postulado principal. Estos límites dan la medida de distancia que separa la publicación de un documento de especificación, de su aplicación a grande escala. La diferencia con las tentativas pasadas de normalización reside en el hecho de que la tecnología de servicios Web indica como único objetivo fundamental y prácticamente único de garantizar la interoperabilidad de las aplicaciones. La ampliación del mercado de los servicios Web pasa pues por el comportamiento de esta promesa: de ahí la necesidad, por parte de los proveedores de tecnologías de protegerse contra toda la tentación de cierre y de consagrar un esfuerzo importante y específico para lograr el objetivo. La instauración, 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 acrónimo 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 ningún caso un protocolo de diálogo 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 opción técnica no es un accidente, ni el producto de la ignorancia u hostilidad para el enfoque <<objeto>>, sino una voluntad precisa de los diseñadores de SOAP, los cuales son todos expertos de las arquitecturas orientadas a objetos distribuidos. En realidad, la <<no objetividad>> de SOAP es una característica indispensable para garantizar las características 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 solución, por otro lado técnicamente delicada, depende ineludiblemente de la características del lenguaje utilizado, así como de las estrategias de los compiladores y de los ambientes de ejecución (interpretes, gestores de memoria) en uso. En una palabra, ellos dependen de la implementación de los interlocutores del intercambio.

4 Por otra parte, la exportación de la referencia de un objeto fuera de su espacio de direccionamiento provoca problemas prácticamente 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 retención del identificador en la red no se ha olvidado, un abuso o un acto hostil, sino la necesidad de una transacción larga? Obviamente, estas preguntas tienen respuestas más o menos fáciles para un sistema cuya distribución en una red local cerrada se imaginó con todo detalle por el diseñador y es estrictamente controlada en ejecución por el administrador, pero cuál 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 práctica, difícilmente 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 aplicación cliente obtenga el identificador técnico (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 (numerocontrato es la llave aplicativa del contrato). A continuación, la aplicación cliente puede aplicar directamente al objeto distante mediante su identificador los métodos como obtenerelnombredelcontratante. El enfoque servicio, consiste en llamar, sobre el identificador técnico de una instancia de la clase GestionDelosContratos (singleton), <<componente>> que funge como representante del servicio de gestión de contratos en ejecución del método obtenerelnombredelcontratante, con argumento el valor 23456, identificador de negocio del contrato en cuestión. Nada impide a la implementación de la aplicación que delegue la petición a la instancia del objeto contrato conveniente, o que elija cualquier otra organización 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 más se ha utilizado en las aplicaciones cliente/servidor implementadas con lenguajes orientados a objeto. Está claro que llamar esta organización <<arquitectura de objetos distribuidos>>, aunque el lenguaje de programación es orientado a objetos, es un abuso del lenguaje: se trata de la práctica usual de invocación de procedimientos distantes (RPC o Remote Procedure Call) entre aplicaciones que desempeñan 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 relación al protocolo de intercambio. Sobrepasar la granulosidad de despliegue del objeto Contrato a la del servicio Gestión de los contratos simplifica el despliegue y la explotación, ya que eso coloca una capa de abstracción que oculta a los clientes de la aplicación de gestión de los contratos el conocimiento de los detalles de implementación (por ejemplo, la gestión de las instancias de la clase Contrato, de sus identificadores técnicos, de la memoria asignada y de su liberación). 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

5 <<servicio>> más bien que <<objeto>>. Por otra parte, cuando el lenguaje de implementación 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 evolución desarrollada para permitir el paso de los objetos por valor. A partir del momento en que, por razones de desempeño, de fiabilidad y de robustez de la aplicación, 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 común. Para responder a esta exigencia de transferencia entre aplicaciones distribuidas, es indispensable definir, además del convenio de codificación de tipos atómicos (entero, cadenas, etc.) necesario para transferir los valores de los argumentos de la llamada del método sobre objetos distantes, una regla de <<serialización>> de estructuras complejas. Lo que se transporta es, a primera vista, una estructura de datos y no un objeto. Un objeto es, por definición, una estructura de datos y un conjunto de tratamientos asociados. La aplicación efectiva de la invocación de métodos 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 petición/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 código de métodos de manipulación del objeto les sea también accesibles. Estos dos requisitos previos no pueden cumplirse enteramente sin dos condiciones: El cliente y el servidor deben implementarse utilizando el mismo lenguaje de programación y el mismo ambiente de compilación y ejecución 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 códigos de los métodos aplicables al objeto. Estas dos condiciones son más restringidas que las necesarias para la invocación de los métodos distantes con paso de objetos por referencia, que se limitan: a la codificación de la llamada; a la codificación de los identificadores universales de los objetos; a la codificación de los datos atómicos. El paso de objetos por referencia puede efectuarse entre programas implementados por lenguajes de programación diferentes (por ejemplo utilizando el mismo ORB en una arquitectura CORBA).

6 El paso de objetos por valor requiere la homogeneidad de los ambientes de desarrollo y la compartición de código 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 métodos de manipulación son diferentes entre cliente y servidor. Este último enfoque se llama enfoque documento: la estructura de datos en la petición 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 impresión de compartir) la semántica informal del documento (un pedido, una factura, etc.) aunque las semánticas 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 heterogéneas: Debe ser completamente compatible con las tecnologías, las herramientas y las prácticas comunes en Internet. El protocolo debe ser también evolutivo, por lo tanto compatible, pero relativamente independiente de las tecnologías y prácticas de la red actual, y capaz de integrar fácilmente sus evoluciones. Debe ser completamente independiente de las especificidades de la implementación de las aplicaciones. En particular, el protocolo debe ser independiente de los sistemas operativos, de los lenguajes de programación, ambientes de ejecución, posibles modelos de componentes de software utilizados. Debe ser <<ligero>> o, más 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, además, ninguna instalación de tecnología dependiente de las elecciones de implementación de los interlocutores no debe requerirse para corresponder con ellos. Lo que es necesario para intercambiar es la tecnología de software que permite cifrar, emitir, recibir y descifrar mensajes que tienen un formato universal y normalizado. Esta tecnología es obviamente específica, o incluso propietaria, para cada ambiente o lenguaje de implementación, pero sigue siendo completamente independiente de las tecnologías de implementación de las aplicaciones interlocutoras. SOAP 1.1, así como los trabajos en desarrollo sobre su sucesor SOAP 1.2, satisfacen globalmente estas exigencias. Más concretamente, SOAP 1.1 es una tecnología actualmente perfectamente utilizable y de sobra implementada. A la oferta de SOAP 1.1 siguió la inicialización, en septiembre de 2000, de un grupo de trabajo del W3C (XML Protocol) que hoy se encarga de normalizar el conjunto creciente de las tecnologías de intercambio entre aplicaciones distribuidas que se basan en XML. Este grupo de trabajo se dedica, entre otras cosas, a la especificación SOAP 1.2. En enero de 2002, empezó en el W3C la actividad Web Services, que cubre el conjunto de las tecnologías y protocolos de interacción de las aplicaciones distribuidas en la Web. Esta

7 actividad absorbe al grupo de trabajo XML Protocol y continúa los trabajos de normalización de SOAP 1.2, y empieza por otro lado otros trabajos que afectan otras tecnologías de servicios Web, más allá del intercambio, y, en particular, el nivel descripción con WSDL (Web Services Description Language). Validación y comprobación de la interoperabilidad La interoperabilidad teórica de SOAP y las otras tecnologías de servicios Web no deja lugar a duda. La interoperabilidad práctica demanda actividades de validación y comprobación de las distintas implementaciones. Es lo que había 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 método adoptado por el WS-I es trabajar por <<perfiles>>. Un perfil es un conjunto coherente de tecnologías de servicios Web en un determinado nivel de versión. A partir del inicio de la organización, se define un perfil básico (Basic Profile), incluyendo las cuatro tecnologías 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 Working Group Draft ( un documento que contiene ciento de recomendaciones que permiten garantizar la interoperabilidad del uso de las tecnologías de servicios Web conformes a este perfil básico. Los principios del protocolo SOAP 1.1 SOAP 1.1 proporciona un mecanismo que permite intercambiar información estructurada y con tipos entre aplicaciones en un ambiente distribuido y descentralizado. No transporta modelo de programación o implementación, sino proporciona las herramientas necesarias para definir modelos operativos de intercambio (estilos de intercambio) también diversificados que los sistemas de servicio de mensajería asíncronos y la llamada de procedimiento distante (RPC). SOAP 1.1 especifica la utilización de documentos XML como mensajes. Para ello, posee un determinado número de características: una gramática para definir el formato y la estructura de los mensajes (en términos de documentos XML); un convenio para designar los agentes de software habilitados a tratar las distintas partes del mensaje así como el carácter obligatorio u opcional del tratamiento; una representación cifrada para transportar los datos atómicos y estructurados manipulados por los lenguajes de programación (estilo de codificación); un conjunto de consignas (conexión <<genérica>>) para transportar los mensajes sobre el protocolo de transporte HTTP; una representación de la petición y la respuesta de una llamada de procedimiento distante (RPC);

8 un conjunto de consignas suplementarias para transportar mensajes acompañados de documentos heterogéneos en documentos adjuntos. Todas estas características 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 definición de especificaciones alternativas para estas características, y extensible, ya que permite definir y añadir características suplementarias al mecanismo básico. Examinaremos en esta parte del curso, la gramática 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 problemática de la codificación de los datos, de los estilos de codificación, así como la transmisión de documentos heterogéneos (objetos multimedia) como documentos adjuntos se expone por lo regular en cursos más avanzados. Igualmente, abordaremos la problemática de los estilos de intercambio (mensaje de dirección única, petición/respuesta, llamada de procedimiento distante), así como la conexión SOAP/HTTP. La estructura de la especificación SOAP 1.1 La estructura de la especificación SOAP 1.1 está representada en la figura 1. La especificación puede organizarse en varios niveles (intercambio, formato, contenido, conexión). Esta prevé una pluralidad de estilos de intercambio posibles, que se basan todos en un único y sólo 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 válido en relación esquemas XML Schema) o cifrado (siguiendo una pluralidad de estilos de codificación) y ser objeto de un conjunto de convenios de conexión (binding) con una pluralidad de protocolos de transporte. Las partes en gris de la figura 1 constituyen el objeto de la especificación SOAP 1.1. El formato de mensaje constituye el pivote de la especificación. 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 típicamente del estilo RPC, que se basa en una especialización del formato de mensaje, eventualmente en un estilo de codificación. El estilo RPC da consignas de conexión particulares que vinculan directamente el funcionamiento llamada/retorno del estilo de intercambio RPC con el funcionamiento petición/respuesta del protocolo de transporte HTTP.

9 Figura 1: Estructura de la especificación por niveles de SOAP 1.1. Los usos estándar y extendidos de SOAP 1.1 se muestran en la figura 2. Figura 2: Los usos de base y extendidos de SOAP 1.1.

10 Las bases de SOAP 1.1 Habíamos visto con anterioridad que los estilos de intercambio propuestos por SOAP 1.1 son el mensaje de dirección única y la petición/respuesta, con sus dos alternativas documento y RPC. El mensaje de dirección única se presenta en esta parte del curso, mientras que el estilo petición/respuesta (documento y RPC) se presentaran posteriormente. Un mensaje de dirección ú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=" <Body> <Greeting> <text>ciao!</text> </Greeting> </Body> </Envelope> Un mensaje puede transferirse directamente del expeditor al destinatario, o bien transitar por un número 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 aplicación 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 técnica y funcional. Desde el punto de vista técnico, el mecanismo normaliza el rol y la función del routeador aplicativo. Desde el punto de vista funcional, las posibilidades ofrecidas por este mecanismo son múltiples. Permite componer servicios de capas (tiers) sobre la base de funciones distribuidas

11 sobre la cadena de transporte, como la anotación de los mensajes, la suscripción, la confidencialidad por codificación, la colocación 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 después 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 cuestión (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 cuestión (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 información 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 especificación SOAP 1.1 no confirma explícitamente si un mensaje SOAP 1.1 debe comenzar por la declaración de uso: <?xml version= 1.0?> La especificación SOAP 1.1 establece que un mensaje SOAP 1.1: no debe contener DTD (Document Type Definition), esto esencialmente por la razón técnica 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 utilización generalizada de los vocabularios XML (XML Namespaces) y de los nombres calificados es fuertemente aconsejada por la especificación SOAP 1.1, aunque no obligatorio para una aplicación que desempeña solamente el rol de expeditor de mensajes. En cambio, las aplicaciones que pretenden desempeñar el rol de destinatario deben ser capaces de tratar correctamente los vocabularios XML de los mensajes que reciben. Estas aplicaciones deben

12 rechazar los mensajes que utilizan los vocabularios XML de manera incorrecta o que utilizan vocabularios XML incorrectos. La especificación 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 La declaración del vocabulario XML es obligatoria para todo mensaje SOAP 1.1. Esta declaración designa la versión de SOAP reivindicada por el mensaje. El prefijo asociado al vocabulario XML en la especificación SOAP 1.1 es SOAP-ENV. El buen uso de los vocabularios XML (cuando un prefijo es utilizado por una especificación cuyos elementos se utilizan en un documento, es preferible utilizar el mismo prefijo que la especificación) sugiere que en el elemento raíz (SOAP-ENV: Envelope) de todo mensaje SOAP 1.1 aparezca la declaración: xmlns: SOAP-ENV=" 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=" <SOAP-ENV:Body> <g:greeting xmlns:g=" <g:text>ciao!</g:text> </g:greeting> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Se normaliza también la utilización 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 aparecían directamente en las instancias. Los atributos SOAP-ENV:mustUnderstand y SOAP-ENV:actor son introducidos por la especificación SOAP 1.1 y desempeñan un papel particular que se examinará más 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>> (raíz), es decir el envelope (SOAP-ENV:Envelope),

13 que contiene un elemento encabezado (SOAP-ENV:Header) opcional y un elemento cuerpo (SOAP-ENV:Body) obligatorio, seguidos de posibles elementos aplicativos específicos. El envelope Figura 5: La estructura del mensaje SOAP 1.1. El envelope es el elemento <<documento>> (raíz) de todo mensaje SOAP 1.1. <?xml version="1.0" encoding="utf-8"?> <SOAP-ENV:Envelope xmlns:soap-env=" > </SOAP-ENV:Envelope> En el envelope de un mensaje SOAP 1.1, la presencia de la declaración del vocabulario XML SOAP 1.1 es obligatoria: xmlns: SOAP-ENV=" o, eventualmente: xmlns=" Esta declaración se utiliza para señalar la versión SOAP (SOAP 1.1) a la cual el mensaje hace referencia. El mensaje se espera así ser tratado por todo receptor (intermediario o destinatario) según la versión del protocolo que exhibe. Si no presenta ninguna versión del protocolo o

14 muestra una versión 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. (código de error SOAP-ENV: VersionMismatch - la gestión de los errores se enumerará en la sección <<la gestión 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 calificación por el identificador de un espacio de nombres es, en cambio, obligatoria; se sitúan otros subelementos cuya presencia es facultativa, pero su calificación por el identificador de un espacio de nombres es obligatoria y su posición obligatoriamente después 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 añadir nuevas y especializadas características a un mensaje SOAP 1.1. Estas adiciones pueden efectuarse dinámicamente, mediante la adición de elementos del encabezado, de manera descentralizada y modular, sin acuerdo preventivo de los participantes en la cadena de transporte, durante el ciclo de transmisión de un mensaje. Dos atributos reservados por la especificación 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 especificación SOAP 1.1 considera explícitamente que las entradas del encabezado se destinan a la aplicación de capas superiores y transversales de la tecnología de los servicios Web, como la gestión de las cadenas de transporte, la gestión de las transacciones, la gestión de la seguridad, etc La especificación recomienda la utilización sistemática 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.

15 El URI reservado por la especificación SOAP designa como consumidor de la entrada del encabezad el primer nodo SOAP 1.1 según el emisor en la cadena de transporte. La regla de designación 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 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 designación absoluta del consumidor Veamos el mensaje A (figura 6) emitido por nice.guy.net en la intención de office.postalservice.com: <?xml version="1.0" encoding="utf-8"?> <SOAP-ENV:Envelope xmlns:soap-env=" <SOAP-ENV:Header> <pbs:postmark xmlns:pbs=" SOAP-ENV:actor=" <pbs:action> <pbs:sender> <pbs:senderuri> </pbs:sender> <pbs:receiver> <pbs:receiveruri> <pbs:receiverport> </pbs:receiver> </pbs:postmark> </SOAP-ENV:Header>

16 <SOAP-ENV:Body> <g:greeting xmlns:g=" <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 acción solicitada es el envío simple del mensaje (designada por el URI 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, además los elementos pbs:sender y pbs:receiver, su propio URI así como la fecha y la hora de recepción del mensaje (a la hora de Greenwitch, según el formato ISO 8601) igualmente se añaden; 7. envía el nuevo mensaje sobre el puerto de recepción 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=" > <SOAP-ENV:Header> <pbs:postmark xmlns:pbs=" <pbs:postmarker> <pbs:postmarkeruri> </pbs:postmarkeruri> </pbs:postmarker> <pbs:datetime> t23:59:59</pbs:datetime> <pbs:action> <pbs:sender> <pbs:senderuri> </pbs:sender> <pbs:receiver> <pbs:receiveruri> <pbs:receiverport> </pbs:receiver> </pbs:postmark> </SOAP-ENV:Header> <SOAP-ENV:Body> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

17 En la recepción, pretty.girl.net trata no solamente el cuerpo del mensaje, sino también las entradas de encabezado. pretty.girl.net considera el identificador (URI) del expeditor, y también debido a que la pequeña palabra recibida pasó por office.postalservice.com, considerando la fecha y hora. La designación 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 /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=" > <SOAP-ENV:Header> <pbs:postmark xmlns:pbs=" SOAP-ENV:actor=" </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 pequeña 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: 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 línea 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 cuestión. Si es <<incapaz>>

18 (el sentido de esta <<incapacidad>> se precisará en la sección consagrada a la gestión de los errores), debe rechazar el mensaje. El consumidor designado de un elemento del encabezado con SOAP- ENV: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 sólo 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 próximo 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 cuestión no se consumirá por ningún nodo intermedio y fallará en el destinatario, quien, en teoría, no tiene el derecho a consumirlo tampoco. Vamos a suponer, por ejemplo, que nice.guy.net quiere enviar siempre la misma pequeña palabra a pretty.girl.net, pero que desea un servicio de envío 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 razón cualquiera a hacer llegar el mensaje al destinatario, debe informar al expeditor. El envío recomendado es un servicio normalizado por (cuyo vocabulario XML se define por relativo a la nueva versión 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 continuación, 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=" > <SOAP-ENV:Header> <pss:postmark xmlns:pss=" SOAP-ENV:actor=" SOAP-ENV:mustUnderstand="1"> <pss:action> <pss:id> <pss:sender> <pss:senderuri> <pss:senderport>

19 </pss:sender> <pss:receiver> <pss:receiveruri> <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 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 acción solicitada es el envío recomendado del mensaje (designada por el URI 4. notemos también 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 recepción del mensaje se añaden; 8. envía el nuevo mensaje sobre el puerto de recepción 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=" > <SOAP-ENV:Header> <pss:postmark xmlns:pss=" <pss:postmarker> <pss:postmarkeruri>

20 </pss:postmarkeruri> </pss:postmarker> <pss:datetime> t23:59:59</pss:datetime> <pss:action> <pss:sender> <pss:senderuri> </pss:sender> <pss:receiver> <pss:receiveruri> <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 envío recomendado, office.postalservice.com aún no implemento los nuevos servicios de intercambio fiable ( especificados por la organización interprofesional a la cual se adhiere con office.smartpservice.com. Si un mensaje como el precedente le era enviado por nice.guy.net, la especificación SOAP 1.1 lo obligaría a rechazar el mensaje y, eventualmente, a devolver un mensaje de error al (expeditor) remitente. Se encuentra que office.postalservice.com está en relación de asociación con office.smartpservice.com, que garantiza el servicio de envío recomendado. En efecto, office.postalservice.com reenvía los mensajes a su socio en caso de petición de envío recomendado. Una cadena de transporte más tolerante puede implementarse según 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 restricción SOAP-ENV:mustUnderstand=" 1" : basta para esto retirar el atributo SOAP-ENV: mustunderstand;

21 sustituir como valor de SOAP-ENV: actor el URI por el URI genérico A continuación 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=" > <SOAP-ENV:Header> <pss:postmark xmlns:pss=" SOAP-ENV:actor=" <pss:action> <pss:id> <pss:sender> <pss:senderuri> <pss:senderport> </pss:sender> <pss:receiver> <pss:receiveruri> <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 forzaría a actuar así con SOAP-ENV: mustunderstand=" 1" en la entrada del encabezado), esta vez, envía 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 número 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.

22 El elemento cuerpo puede contener un conjunto de elementos descendientes, que pueden ser calificados por la referencia a uno o a más espacios de nombres. Estos elementos se llaman entradas del cuerpo. El elemento cuerpo puede también contener un elemento SOAP 1.1 error (SOAP-ENV: Fault), que es definido por la especificación, para tratar los casos de error. La especificación SOAP 1.1 sugiere considerar el cuerpo como semánticamente 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 gestión 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 sintáctico o semántico del mensaje; o a un fallo del nodo receptor en el tratamiento del mensaje. El mensaje recibido implicado en una situación de error se llamará mensaje en error (faulty message). Un mensaje en error es pues o un mensaje sintáctica o semánticamente incorrecto, o bien un mensaje correcto cuyo tratamiento falló debido a un fallo del nodo receptor. La especificación SOAP 1.1 menciona las circunstancias en las cuales el receptor de un mensaje SOAP 1.1 reconoce una situación 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 situación de error. Esta descripción personal puede tomar la forma de la transmisión de un mensaje de error (fault message) a la intención del emisor inicial. El mensaje de error contiene siempre información sobre la naturaleza del error para el emisor del mensaje en error. La especificación SOAP precisa el formato y el contenido del mensaje de error. La gestión de los errores SOAP 1.1 incluye pues tres etapas distintas: 1. el tratamiento del mensaje en error por su receptor; 2. la descripción personal del error y la producción y la emisión del mensaje de error correlacionado al mensaje en error; 3. la recepción 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 descripción de los tipos de errores SOAP 1.1 en la sección <<los tipos de errores>>), en el rechazo del mensaje por parte del receptor o en el fracaso de su tratamiento.

23 Sin embargo, la especificación SOAP 1.1 no precisa la semántica 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 raíz del tratamiento del mensaje en error por el receptor. La situación ideal sería que: El receptor del mensaje en error completa el análisis sintáctico y semántico 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 gestión transaccional de los tratamientos que producen los cambios de estado y las consecuencias de los efectos de borde del consumo del mensaje. La gestión transaccional permite tratar correctamente los casos de fallo (panne franche) del receptor. El señalamiento del error El receptor debe indicar la situación de error consiguiente a la recepción de un mensaje en error por todos los medios a su disposición (levantamiento de una excepción, visualización sobre una consola de usuario o administrador, producción de un diario de navegación, etc.). La emisión de un mensaje de error para el emisor del mensaje en error es uno de estos medios. La especificación SOAP 1.1 define las modalidades de este medio de señalamiento y deja la implementación de los nodos SOAP las otras modalidades. Las capacidades de emisión y recepción 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 emisión de mensajes SOAP 1.1, y en consecuencia de mensajes de error, por parte del receptor del mensaje en error. Podemos distinguir cuatro clases básicas para los nodos SOAP 1.1, con relación a sus capacidades de emisión/recepción de mensajes SOAP 1.1: Emisor SOAP 1.1 es un nodo que tiene una capacidad de emisión de mensajes de dirección única SOAP 1.1. Receptor SOAP 1.1 es un nodo que tiene una capacidad de recepción de mensajes de dirección única SOAP 1.1. Cliente SOAP 1.1 es un nodo que tiene una capacidad de emisión de peticiones SOAP 1.1 y de recepción de respuestas SOAP 1.1 correlacionadas a las peticiones emitidas. Servidor SOAP 1.1 es un nodo que tiene una capacidad de recepción de peticiones SOAP 1.1 y de emisión de respuestas SOAP 1.1 correlacionadas a la petición recibida.

24 Las capacidades de emisión/recepción de un nodo SOAP 1.1 resultan de la combinación de estas clases básicas. La correlación entre mensaje en error y mensaje de error La correlación entre mensaje en error y mensaje de error es un elemento esencial del mecanismo de gestión de los errores SOAP: un mensaje de error es una herramienta computacional y sólo cumple su rol si se correlaciona de manera no ambigua al mensaje en error que lo causó. Por otra parte, la correlación directa e implícita entre un mensaje en error y un mensaje de error sólo es posible entre un cliente y un servidor SOAP 1.1, en el estilo de intercambio petición/respuesta, cuando el mensaje en error es la petición SOAP. En ese caso, el mensaje de error sustituye a la respuesta al mensaje (petición) en error y la correlación está garantizada por el estilo de intercambio. Aparte de este caso preciso, la correlación mensaje en error y mensaje de error, como aquella entre los mensajes en una <<conversación>>, no puede ser obtenida más que por un protocolo aplicativo que permite dotar cada mensaje de un único identificador. Se recuerda este identificador explícitamente cada vez que es necesario establecer una correlación con otro mensaje. Por otra parte, aunque en la especificación, la emisión de un mensaje de error parece siempre vinculada al acto previo de un error, no excluye emitir un mensaje de error independientemente de una situación de error, para indicar un estado (notificación de status). La notificación de status sirve para indicar una situación corriente (status) de fallo de un nodo, sobre iniciativa del propio nodo. Se podría uno imaginar, por ejemplo, que office.postalservice.com envía a sus clientes, a su iniciativa, un mensaje de error sobre la no disponibilidad temporal de sus servicios y, a continuación, sobre el restablecimiento del funcionamiento normal. La tabla 1 resume las actitudes de los nodos con relación a la recepción y al tratamiento de un mensaje en error y al envío de un mensaje.

25 Gestión de error SOAP 1.1 Nodo SOAP 1.1 Capacidad de recepción mensaje en error Tratamiento mensaje en error Capacidad de emisión mensaje de error correlacionado Capacidad de emisión mensaje de error no correlacionado (status) Emisor NO (no aplicable) (no aplicable) SI (emisión de un mensaje de error) Receptor SI Rechaza mensaje o NO NO tratamiento de fracaso Cliente Servidor SI (mensaje en error en una respuesta) SI (mensaje en error en una petición explícitamente correlacionada con un mensaje de un intercambio anterior. Rechaza mensaje o tratamiento de fracaso Rechaza mensaje o tratamiento de fracaso SI (inclusión del mensaje de error correlacionado en la respuesta al mensaje en error) SI (inclusión del mensaje de error correlacionado en la respuesta al mensaje en error) NO NO Tabla 1: Resumen de las capacidades de emisión/recepción 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 información de error o de estado. La especificación SOAP 1.1 precisa que el elemento error es obligatoriamente una entrada del cuerpo. Esta entrada puede estar presente a lo más una vez en el cuerpo de un mensaje SOAP 1.1. Puede ser la única entrada o estar acompañada de otras entradas del cuerpo. La especificación 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 especificación 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.

26 El elemento cifrado de error (faultcode) El elemento cifrado de error (faultcode) transporta una información sobre el error encontrado que se destina típicamente a la explotación 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 <<código>>, bajo el formato de un nombre calificado por el vocabulario XML: Los códigos de errores SOAP 1.1 son: SOAP-ENV:VersionMismatch: el código 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 ( SOAP-ENV:MustUnderstand: el código 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 código indica que el mensaje en error está sintáctica y/o semánticamente incorrecto: ya sea mal formado, o no contiene la información apropiada para estar convenientemente tratado; SOAP-ENV:Server: el mensaje en error no pudo tratarse debido a un fallo técnico o aplicativo del nodo receptor: este último código puede también utilizarse para notificaciones de status. Los códigos de errores SOAP 1.1 pueden ser, según la especificación, especializados por un sufijo (separado por un punto), por ejemplo: SOAP-ENV:Client.Authentication. El código 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 código, resultante de un acuerdo privado entre los interlocutores, es que el error viene de un problema de autenticación del nodo emisor del mensaje en error. El elemento expresado de error (faultstring) El elemento expresado de error (faultstring) está destinado típicamente a proporcionar una explicación del error comprensible por los actores humanos (generalmente, los diseñadores 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 información sobre el nodo expeditor del mensaje de error. Su valor es un URI.

27 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 información 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 información 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 codificación de las entradas del detalle. Los tipos de errores Vamos a ilustrar el uso de los códigos 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 más generalidad y completes al ejemplo. Hay que señalar que el uso del elemento faultactor es obligatorio en tal situación ya que el expeditor del mensaje de error no es el destinatario del mensaje en error. El código SOAP-ENV:VersionMismatch Figura 9: La cadena interrumpida por un error (I). El valor SOAP-ENV:VersionMismatch de faultcode indica que el vocabulario XML de las marcas de estructura del mensaje en error no es En SOAP 1.1, el vocabulario es el único aceptable para las marcas de estructura (Envelope, Header, Body, Fault) e indica que el mensaje se ajusta a la especificación SOAP 1.1. En el ejemplo presentado en la figura 9, nice.guy.net envía a office.postalservice.com el mensaje A siguiente, teniendo como destinatario pretty.girl.net:

28 <?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 especificación 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 envío 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=" <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>soap-env:versionmismatch</faultcode> <faultstring>soap 1.0 is not supported.</faultstring> <faultactor> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope> El código SOAP-ENV:MustUndestand El código 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 explícito o por defecto de SOAP-ENV: actor lo designa); que tiene la obligación de tratar (SOAP-ENV:mustUnderstand=" 1") ; y que no es funcionalmente capaz de tratar (<<no comprende>>) el elemento en cuestión. Recordamos que si este elemento es: una entrada del encabezado, el consumidor designado es ya sea un nodo en la cadena de transporte explícitamente 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 obligación de <<incluir>> siempre el elemento (lo que es equivalente, para las entradas del encabezado, a SOAPENV:mustUnderstand=" 1").

29 Consideremos el ejemplo, siempre ilustrado por la figura 9, en el cual nice.guy.net envía 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=" > <SOAP-ENV:Header> <pss:postmark xmlns:pss=" SOAP-ENV:actor=" SOAP-ENV:mustUnderstand="1"> <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 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 envía 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=" <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>soap-env:mustunderstand</faultcode> <faultstring>misunderstood header entry</faultstring> <faultactor> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope> El código SOAP-ENV:Client El código SOAP-ENV:Client de faultcode indica que ya sea que el mensaje en error está mal formado, o no contiene la información apropiada para estar convenientemente tratado (error sintáctico o semántico). En el ejemplo siguiente, nice.guy.net envía a office.postalservice.com el mensaje A (ver figura 9), para que sea transportado a pretty.girl.net:

30 <?xml version="1.0" encoding="utf-8"?> <SOAP-ENV:Envelope xmlns:soap-env=" > <SOAP-ENV:Header> <pbs:postmark xmlns:pbs=" SOAP-ENV:actor=" <pbs:action> <pbs:sender> <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 prestación: ya que los datos del destinatario: <pbs:receiver> <pbs:receiveruri> <pbs:receiverport> </pbs:receiver> no se especifican en el mensaje. Rechaza pues el mensaje A y envía 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=" <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>soap-env:client</faultcode> <faultstring>missing routing data</faultstring> <faultactor> <detail xmlns:d=" <d:reason>missing last receiver s name and address</d:reason> </detail> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope> El código SOAP-ENV:Server El código SOAP-ENV:Server de faultcode indica que el mensaje en error no pudo tratarse debido a un fallo técnico 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 recepción del mensaje en error, este responde con un mensaje de error.

31 Vamos a reconsiderar el ejemplo de nice.guy.net que solicita un envío 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 petición de envío recomendado del mensaje a pretty.girl.net: <?xml version="1.0" encoding="utf-8"?> <SOAP-ENV:Envelope xmlns:soap-env=" > <SOAP-ENV:Header> <pss:postmark xmlns:pss=" SOAP-ENV:actor=" <pss:action> </pss:postmark> </SOAP-ENV:Header> <SOAP-ENV:Body> </SOAP-ENV:Body> </SOAP-ENV:Envelope> El servicio de envío 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 envía 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=" <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>soap-env:server</faultcode> <faultstring> Message queue overflow</faultstring> <faultactor> <detail xmlns:d=" <d:suggestion>try later</d:suggestion>