Soap Parte1

download Soap Parte1

of 32

Transcript of Soap Parte1

  • 7/22/2019 Soap Parte1

    1/32

    Intercambiar con un servicio- Formato del mensaje

    Objetos, servicios, documentos

    El 10 de febrero de 1998, el World Wide Web Consortium (W3C) publica una

    notable: Extensible Markup Language (XML) 1.0. A partir de su salida,

    XML demuestra una enorme polivalencia, utilizndose en aplicaciones que probablemente

    nunca haban pasado por la imaginacin de sus primeros diseadores. Se convierte

    rpidamente en el lenguaje universal de descripcin de datos, estructurados y no

    estructurados. En la actualidad, las iniciativas de normalizacin en XML de los datos y

    documentos propios en los distintos sectores econmicos, conducidos por las organizaciones

    profesionales y de los organismos de normalizacin, se cuentan por centenares. En la lneas

    de los grandes estndares Internet (IP, TCP, SMTP, HTTP, HTML), XML se vuelve

    inevitable.

    Inmediatamente despus de la publicacin de la recomendacin, cuatro arquitectos de

    software: Dave Winer (UserLand Software, Don Box (DevelopMentor), Bob Atkinson y

    Mohsen Al-Ghosein (colaboradores de Microsoft) elaboran un protocolo de llamada de

    procedimiento distante (de tipo RPC) que utiliza HTTP como protocolo de transporte y XML

    como formato de mensaje. El resultado del trabajo es publicado por Dave Winer en marzo de

    1998 (apenas un mes despus de la publicacin de la norma XML!) bajo el nombre de XML-

    RPC. Al mismo tiempo, nacen y se desarrollan en los laboratorios de R&D ms de una decena

    de experiencias similares, a menudo en la esfera de influencia .

    Para ms detalles de XML-RPC, consultar la siguiente referencia: http://www.xmlrpc.com/

    SOAP

    A partir de la publicacin de XML-RPC, la actividad en torno a las especificaciones y

    tecnologas que constituyen hoy el conjunto de los , se acelera y se

    diversifica.

    XML alcanza rpidamente una enorme popularidad y se vuelve cada vez ms equipado:

    por analizadores sintcticos cada vez ms rpidos; por la disponibilidad, en varios lenguajes de programacin, de bibliotecas destinadas a

    manipulacin de los documentos en memoria cuyo interfaz programtica se ajusta al

    estndar DOM (Document Object Model), recomendacin W3C del 10 de octubre de

    1998;

    por la disponibilidad de herramientas complementarias, pero esenciales, como XSLT.

    Por otra parte, HTTP presenta la enorme ventaja de ser aceptado universalmente. Es en

    particular, plebiscitado por una poblacin profesional que tiene un rol clave: los

    administradores de redes. En efecto, stos controlan las tcnicas y las herramientas de

    seguridad y, obviamente, las reservan para una recepcin mitigada a la utilizacin, a travs decortafuegos, otros protocolos IP (como el protocolo Internet Inter ORB o el IIOP especificado

  • 7/22/2019 Soap Parte1

    2/32

    por el OMG y adoptado por el IETF, y como el Remote Method Invocation o RMI, el

    protocolo utilizado para la comunicacin entre aplicaciones Java distribuidas).

    HTTP es un protocolo simple, robusto y adaptado al mundo abierto de Internet. Obviamente,

    su facilidad de utilizacin y su difusin tienen por corolario la apertura, que es propio de la

    Web y expone cualquier aplicacin, al menos, al riesgo de la saturacin delas llamadas (denial of service). Por a otra parte, si SSL ofrece una solucin simple al

    problema de la confidencialidad de los intercambios sobre HTTP (HTTPS), las soluciones

    generalizadas a los problemas de seguridad (autenticacin, autorizacin, confidencialidad,

    integridad, no repudio) estn hoy en desarrollo.

    XML-RPC es la fuente de inspiracin de SOAP (Simple Object Acces Protocol), definido por

    un equipo proveniente de Microsoft, con la participacin de Dave Winer y Don Box. SOAP

    1.0 se presenta bajo la forma de Internet Draft, en noviembre de 1999, a la Internet

    Engineering Task Force (ver http://www.scripting.com/misc/soap1.txt). La iniciativa parece

    permanecer confinada en la esfera de influencia Microsoft, pero a principios del 2000 seopera, en el mercado de la tecnologa, una dislocacin de mucha importancia: IBM y su filial

    Lotus Development deciden trabajar con Microsoft con el fin de desarrollar juntos la versin

    1.1 de la especificacin SOAP, que es inscrita a continuacin como una nota W3C en mayo

    de 2000 (ver http://www.w3.org/TR/SOAP).

    Adems Microsoft, IBM y su filial Lotus, un gran nmero de empresas apoyan esta oferta

    entre cules estn: Ariba Inc., Commerce One Inc., Compaq Computer Corporation,

    DevelopMentor Inc., Hewlett Packard Company, IONA Technologies, SAP AG, UserLand

    Software Inc. El W3C nota del 8 de mayo de 2000: Simple Object Acces Protocol (SOAP)

    1.1, est completado por una nota suplementaria del 11 de diciembre de 2000: SOAP

    Messages with Attachments, que trata de la inclusin de partes adjuntadas a los mensajes

    SOAP por la utilizacin de la estructura multi-partes MIME (multipart), utilizada sobre

    Internet para transportar documentos heterogneos (ver http://www.w3.org/TR/SOAP-

    attachments).

    Esta evolucin permite el verdadero inicio de la tecnologa de los servicios Web. IBM, uno de

    protagonistas principales de la industria informtica, est obviamente muy interesado en la

    normalizacin y la aplicacin del lenguaje Java, de las arquitecturas basadas en este lenguaje

    y, en particular, de Java 2 Enterprise Edition (J2EE). La arquitectura J2EE se destina

    claramente al desarrollo de sistemas e-negocios e informtica de gestin y constituye la punta

    de lanza tecnolgica de una coalicin heterognea cuyo objetivo estratgico reconocidoconsiste en contradecir la expansin de Microsoft en el mbito de las tecnologas informticas

    relativas a los servidores.

    Ahora, IBM coopera, con su competidor histrico Microsoft, sobre la definicin de un

    estndar de intercambio e interoperabilidad en la Web entre aplicaciones informticas,

    desarrolladas sobre tecnologas que son, por construccin, heterogneas. La presencia de

    IBM, que apuesta mucho sobre a la tecnologa Java, a los lados de Microsoft, que va a

    proponer un mes despus de la nueva arquitectura de aplicaciones .NET - a su vez concebida

    y presentada como la respuesta de Microsoft a J2EE - credibilidad a la promesa de

    interoperabilidad entre servicios Web construidos sobre arquitecturas y tecnologasradicalmente diferentes y concurrentes.

  • 7/22/2019 Soap Parte1

    3/32

    En efecto, el simple hecho de que un protocolo de intercambio entre aplicaciones Web se base

    en dos estndares universalmente aceptados, como XML y HTTP, no basta sin embargo a

    garantizar la independencia de este protocolo de las tecnologas aplicadas en el desarrollo de

    aplicaciones que lo utilizan. SOAP 1.1 permite el intercambio entre aplicaciones construidas

    sobre tecnologas heterogneas, porque se concibi para eso.

    Por otra parte, los propios lmites de interoperabilidad del protocolo SOAP, que resultan de

    derivados propietarios de interpretacin de especificaciones, a los cuales mencionaremos

    posteriormente, muestran bien la dificultad paradjica de garantizar el comportamiento del

    compromiso de interoperabilidad por una tecnologa, en cuestin, de all el postulado

    principal. Estos lmites dan la medida de distancia que separa la publicacin de un documento

    de especificacin, de su aplicacin a grande escala.

    La diferencia con las tentativas pasadas de normalizacin reside en el hecho de que la

    tecnologa de servicios Web indica como nico objetivo fundamental y prcticamente nico

    de garantizar la interoperabilidad de las aplicaciones. La ampliacin del mercado de losservicios Web pasa pues por el comportamiento de esta promesa: de ah la necesidad, por

    parte de los proveedores de tecnologas de protegerse contra toda la tentacin de cierre y de

    consagrar un esfuerzo importante y especfico para lograr el objetivo. La instauracin, en

    febrero de 2002, de la iniciativa Web Service Interoperability (WS-I) por parte de IBM,

    Microsoft, BEA, Intel, y otros muestra la importancia y la urgencia de velar permanentemente

    por la convergencia hacia este objetivo para permitir el despegue del mercado de los servicios

    Web.

    SOAP es la causa, el acrnimo de Simple Object Acces Protocol, el protocolo de

    acceso a los objetos. El nombre no corresponde al objeto nombrado y es incluso mal

    entendido: SOAP no es en ningn caso un protocolo de dilogo entre objetos distribuidos. No

    permite ir dirigido directamente a un objeto distante, incluso si puede obviamente utilizarse

    indirectamente para que se consiga este resultado.

    SOAP no es pues un protocolo : esta opcin tcnica no es un accidente, ni el

    producto de la ignorancia u hostilidad para el enfoque , sino una voluntad precisa

    de los diseadores de SOAP, los cuales son todos expertos de las arquitecturas orientadas a

    objetos distribuidos. En realidad, la de SOAP es una caracterstica

    indispensable para garantizar las caractersticas esenciales de independencia de las

    implementaciones y de la interoperabilidad de los servicios Web.

    Objetos por referencia

    Para enviar un mensaje a un objeto distante, el emisor debe en primer lugar conocer el

    identificador nico de este objeto en la red. A partir del momento en que la referencia a un

    objeto existente en la memoria de un proceso sale del espacio de direccionamiento del

    proceso para difundirse en una red, comienza una serie de problemas cuya solucin , por otro

    lado tcnicamente delicada, depende ineludiblemente de la caractersticas del lenguaje

    utilizado, as como de las estrategias de los compiladores y de los ambientes de ejecucin

    (interpretes, gestores de memoria) en uso. En una palabra, ellos dependen de la

    implementacin de los interlocutores del intercambio.

  • 7/22/2019 Soap Parte1

    4/32

    Por otra parte, la exportacin de la referencia de un objeto fuera de su espacio de

    direccionamiento provoca problemas prcticamente insolubles en una arquitectura abierta. En

    qu momento liberar la memoria asignada a un objeto, cuando su identificador viaja en la red?

    En qu momento decidir que la retencin del identificador en la red no se ha olvidado, un

    abuso o un acto hostil, sino la necesidad de una transaccin larga? Obviamente, estas

    preguntas tienen respuestas ms o menos fciles para un sistema cuya distribucin en una redlocal cerrada se imagin con todo detalle por el diseador y es estrictamente controlada en

    ejecucin por el administrador, pero cul es el detalle en el mundo abierto de Internet?

    En cualquier caso, incluso en una red local, en un mundo cerrado y controlado, estos

    problemas y otro conexos se presentan con frecuencia, en la prctica, difcilmente solubles.

    La mayor parte de las aplicaciones distribuidas se han implantado sobre la base de un enfoque

    que llamamos servicio. Los dos enfoques se enfrentaron en el desarrollo de aplicaciones que

    se basaban en la arquitectura cliente a servidor:

    El enfoque objeto puro pretende que la aplicacin cliente obtenga el identificadortcnico(un IOR: Internet Object Reference, en el mundo CORBA/IIOP) de la copia en

    memoria del servidor de la instancia de la clase Contrato, por ejemplo, teniendo como

    valor del atributo numeroContrato el valor 123456 (numeroContrato es la llave

    aplicativa del contrato).

    A continuacin, la aplicacin cliente puede aplicar directamente al objeto distante

    mediante su identificador los mtodos como obtenerElNombreDelContratante.

    El enfoque servicio, consiste en llamar, sobre el identificador tcnico de una instancia

    de la clase GestionDelosContratos (singleton), que funge como

    representante del servicio de gestin de contratos en ejecucin del mtodo

    obtenerElNombreDelContratante, con argumento el valor 23456, identificador de

    negocio del contrato en cuestin. Nada impide a la implementacin de la aplicacin

    que delegue la peticin a la instancia del objeto contrato conveniente, o que elija

    cualquier otra organizacin alternativa. El identificador del servicio (de la instancia

    singular de la clase GestionDelosContratos que representa al servicio) se utiliza en

    este contexto como el punto de entrada del servicio.

    En el uso, es el segundo enfoque que ms se ha utilizado en las aplicaciones cliente/servidor

    implementadas con lenguajes orientados a objeto. Est claro que llamar esta organizacin

    , aunque el lenguaje de programacin es orientado a

    objetos, es un abuso del lenguaje: se trata de la prctica usual de invocacin de

    procedimientos distantes (RPC o Remote Procedure Call) entre aplicaciones que desempeanrespectivamente los papeles de cliente y servidor sobre dos nodos distantes de la red. El hecho

    de que las aplicaciones implicadas sean o no desarrolladas al utilizar lenguajes orientados a

    objeto es transparente con relacin al protocolo de intercambio.

    Sobrepasar la granulosidad de despliegue del objeto Contrato a la del servicio Gestin de los

    contratos simplifica el despliegue y la explotacin, ya que eso coloca una capa de abstraccin

    que oculta a los clientes de la aplicacin de gestin de los contratos el conocimiento de los

    detalles de implementacin (por ejemplo, la gestin de las instancias de la clase Contrato, de

    sus identificadores tcnicos, de la memoria asignada y de su liberacin). Por estas razones,

    una gran parte de las aplicaciones cliente/servidor desarrolladas con lenguajes orientados aobjetos eligi exponer como interlocutor de la llamada distante una granularidad de tipo

  • 7/22/2019 Soap Parte1

    5/32

    ms bien que . Por otra parte, cuando el lenguaje de implementacin

    no es , el enfoque se impone naturalmente.

    Objetos por valor y documentos

    La dificultad de tratar los objetos por referencia en las arquitecturas distribuidas es la causa deevolucin desarrollada para permitir el paso de los objetos por valor. A partir del momento en

    que, por razones de desempeo, de fiabilidad y de robustez de la aplicacin, no se aconseja

    manipular un objeto distante por una secuencia de operaciones de granularidad fina, es

    tentador transferir el objeto directamente con el fin de manipularlo a nivel local. Por ejemplo,

    cuando se negocia un contrato, parece natural transferir entre contratantes la copia del

    contrato, cada uno aporta sus modificaciones, hasta la convergencia sobre un objeto comn.

    Para responder a esta exigencia de transferencia entre aplicaciones distribuidas, es

    indispensable definir, adems del convenio de codificacin de tipos atmicos (entero,

    cadenas, etc.) necesario para transferir los valores de los argumentos de la llamada del mtodosobre objetos distantes, una regla de de estructuras complejas.

    Lo que se transporta es, a primera vista, una estructura de datos y no un objeto. Un objeto es,

    por definicin, una estructura de datos y un conjunto de tratamientos asociados. La aplicacin

    efectiva de la invocacin de mtodos distantes con paso de objetos por valor, requiere al

    menos dos requisitos previos:

    que el cliente y el servidor sean capaces de cifrar y descifrar en un mensaje de

    peticin/respuesta la estructura de datos que representa al objeto pasado en argumento;

    que el cliente y el servidor sean capaces de manipular el objeto reconstruido, es decir

    que el cdigo de mtodos de manipulacin del objeto les sea tambin accesibles.

    Estos dos requisitos previos no pueden cumplirse enteramente sin dos condiciones:

    El cliente y el servidor deben implementarse utilizando el mismo lenguaje de

    programacin y el mismo ambiente de compilacin y ejecucin de este lenguaje. Es

    solamente a este precio que el paso de objetos por valor toma todo su sentido.

    El cliente y el servidor deben ser capaces de compartir en la red los cdigos de los

    mtodos aplicables al objeto.

    Estas dos condiciones son ms restringidas que las necesarias para la invocacin de los

    mtodos distantes con paso de objetos por referencia, que se limitan:

    a la codificacin de la llamada;

    a la codificacin de los identificadores universales de los objetos;

    a la codificacin de los datos atmicos.

    El paso de objetos por referencia puede efectuarse entre programas implementados por

    lenguajes de programacin diferentes (por ejemplo utilizando el mismo ORB en una

    arquitectura CORBA).

  • 7/22/2019 Soap Parte1

    6/32

    El paso de objetos por valor requiere la homogeneidad de los ambientes de desarrollo y la

    comparticin de cdigo entre el cliente y el servidor. Sin estas dos condiciones, la estructura

    pasada es una estructura de datos, y los procedimientos de cifrado/descifrado y los mtodos

    de manipulacin son diferentes entre cliente y servidor.

    Este ltimo enfoque se llama enfoque documento: la estructura de datos en la peticin y larespuesta es un que se cifra, descifra, manipulado de forma independiente

    por el cliente y el servidor. Indudablemente, el cliente y el servidor comparten (o tienen la

    impresin de compartir) la semntica informal del documento (un pedido, una factura, etc.)

    aunque las semnticas operativas son diferentes.

    SOAP y el uso de XML para el contenido de los mensajes normalizar el enfoque documento.

    Service Oriented Access Protocol?

    Un protocolo de intercambio en la Web debe exhibir al menos tres propiedades paragarantizar la interoperabilidad de las aplicaciones en implementaciones heterogneas:

    Debe ser completamente compatible con las tecnologas, las herramientas y las

    prcticas comunes en Internet. El protocolo debe ser tambin evolutivo, por lo tanto

    compatible, pero relativamente independiente de las tecnologas y prcticas de la red

    actual, y capaz de integrar fcilmente sus evoluciones.

    Debe ser completamente independiente de las especificidades de la implementacin de

    las aplicaciones. En particular, el protocolo debe ser independiente de los sistemas

    operativos, de los lenguajes de programacin, ambientes de ejecucin, posibles

    modelos de componentes de software utilizados.

    Debe ser o, ms concretamente, . No solamente las

    implementaciones de las aplicaciones que participan en el intercambio no se ven

    obligadas nunca a conocer las implementaciones de sus interlocutores, pero, adems,

    ninguna instalacin de tecnologa dependiente de las elecciones de implementacin de

    los interlocutores no debe requerirse para corresponder con ellos. Lo que es necesario

    para intercambiar es la tecnologa de software que permite cifrar, emitir, recibir y

    descifrar mensajes que tienen un formato universal y normalizado. Esta tecnologa es

    obviamente especfica, o incluso propietaria, para cada ambiente o lenguaje de

    implementacin, pero sigue siendo completamente independiente de las tecnologas de

    implementacin de las aplicaciones interlocutoras.

    SOAP 1.1, as como los trabajos en desarrollo sobre su sucesor SOAP 1.2, satisfacen

    globalmente estas exigencias. Ms concretamente, SOAP 1.1 es una tecnologa actualmente

    perfectamente utilizable y de sobra implementada.

    A la oferta de SOAP 1.1 sigui la inicializacin, en septiembre de 2000, de un grupo de

    trabajo del W3C (XML Protocol) que hoy se encarga de normalizar el conjunto creciente de

    las tecnologas de intercambio entre aplicaciones distribuidas que se basan en XML. Este

    grupo de trabajo se dedica, entre otras cosas, a la especificacin SOAP 1.2.

    En enero de 2002, empez en el W3C la actividad Web Services, que cubre el conjunto de lastecnologas y protocolos de interaccin de las aplicaciones distribuidas en la Web. Esta

  • 7/22/2019 Soap Parte1

    7/32

    actividad absorbe al grupo de trabajo XML Protocol y contina los trabajos de normalizacin

    de SOAP 1.2, y empieza por otro lado otros trabajos que afectan otras tecnologas de servicios

    Web, ms all del intercambio, y, en particular, el nivel descripcin con WSDL (Web

    Services Description Language).

    Validacin y comprobacin de la interoperabilidad

    La interoperabilidad terica de SOAP y las otras tecnologas de servicios Web no deja lugar a

    duda. La interoperabilidad prctica demanda actividades de validacin y comprobacin de las

    distintas implementaciones. Es lo que haba faltado en las implementaciones CORBA, y estas

    actividades forman parte integrante de la tarea que se da en el WS-I (Web Services

    Interoperability Organization), consorcio de industriales y usuarios.

    El mtodo adoptado por el WS-I es trabajar por . Un perfil es un conjunto

    coherente de tecnologas de servicios Web en un determinado nivel de versin. A partir del

    inicio de la organizacin, se define un perfil bsico (Basic Profile), incluyendo las cuatrotecnologas a las cuales se consagra una curso normal de servicios Web: XML Schema 1.0,

    SOAP 1.1, WSDL 1.1 et UDDI 2.0.

    El 8 de octubre de 2002, el WS-I public a Basic Profile Version 1.0- Working Group Draft

    (http://www.ws-i.org/Profiles/Basic/2002-10/BasicProfile-1.0-WGD.pdf), un documento que

    contiene ciento de recomendaciones que permiten garantizar la interoperabilidad del uso de

    las tecnologas de servicios Web conformes a este perfil bsico.

    Los principios del protocolo SOAP 1.1

    SOAP 1.1 proporciona un mecanismo que permite intercambiar informacin estructurada y

    con tipos entre aplicaciones en un ambiente distribuido y descentralizado. No transporta

    modelo de programacin o implementacin, sino proporciona las herramientas necesarias para

    definir modelos operativos de intercambio (estilos de intercambio) tambin diversificados que

    los sistemas de servicio de mensajera asncronos y la llamada de procedimiento distante

    (RPC).

    SOAP 1.1 especifica la utilizacin de documentos XML como mensajes. Para ello, posee un

    determinado nmero de caractersticas:

    una gramtica para definir el formato y la estructura de los mensajes (en trminos de

    documentos XML);

    un convenio para designar los agentes de software habilitados a tratar las distintas

    partes del mensaje as como el carcter obligatorio u opcional del tratamiento;

    una representacin cifrada para transportar los datos atmicos y estructurados

    manipulados por los lenguajes de programacin (estilo de codificacin);

    un conjunto de consignas (conexin ) para transportar los mensajes

    sobre el protocolo de transporte HTTP;

    una representacin de la peticin y la respuesta de una llamada de procedimiento

    distante (RPC);

  • 7/22/2019 Soap Parte1

    8/32

    un conjunto de consignas suplementarias para transportar mensajes acompaados de

    documentos heterogneos en documentos adjuntos.

    Todas estas caractersticas forman parte de SOAP 1.1, pero son funcionalmente modulares y

    ortogonales. Es necesario tener en cuenta que SOAP 1.1 es redefinible, ya que contiene los

    mecanismos necesarios para la definicin de especificaciones alternativas para estascaractersticas, y extensible, ya que permite definir y aadir caractersticas suplementarias al

    mecanismo bsico.

    Examinaremos en esta parte del curso, la gramtica del mensaje y los convenios de

    tratamiento, as como el estilo de intercambio por mensaje unidireccional, con eventualmente

    intermediarios en la cadena de transporte.

    La problemtica de la codificacin de los datos, de los estilos de codificacin, as como la

    transmisin de documentos heterogneos (objetos multimedia) como documentos adjuntos se

    expone por lo regular en cursos ms avanzados.

    Igualmente, abordaremos la problemtica de los estilos de intercambio (mensaje de direccin

    nica, peticin/respuesta, llamada de procedimiento distante), as como la conexin

    SOAP/HTTP.

    La estructura de la especificacin SOAP 1.1

    La estructura de la especificacin SOAP 1.1 est representada en la figura 1. La

    especificacin puede organizarse en varios niveles (intercambio, formato, contenido,

    conexin). Esta prev una pluralidad de estilos de intercambioposibles, que se basan todos en

    un nico y slo uno (aunque extensible) formatode mensaje: el formato XML del envelope

    SOAP 1.1 y de sus elementos descendentes.

    El mensaje con formato nico puede albergar un contenido literal(del XML bien formado o

    vlido en relacin esquemas XML Schema) o cifrado (siguiendo una pluralidad de estilos de

    codificacin) y ser objeto de un conjunto de convenios de conexin (binding) con una

    pluralidad de protocolos de transporte.

    Las partes en gris de la figura 1 constituyen el objeto de la especificacin SOAP 1.1.

    El formato de mensaje constituye el pivote de la especificacin. El mensaje puede sertransferido por varios protocolos de transporte y en el marco de varios estilos de intercambio

    entre aplicaciones. Algunos protocolos de transporte pueden especialmente adaptarse para

    algunos estilos de intercambio. Es el caso tpicamente del estilo RPC, que se basa en una

    especializacin del formato de mensaje, eventualmente en un estilo de codificacin.

    El estilo RPC da consignas de conexin particulares que vinculan directamente el

    funcionamiento llamada/retorno del estilo de intercambio RPC con el funcionamiento

    peticin/respuesta del protocolo de transporte HTTP.

  • 7/22/2019 Soap Parte1

    9/32

    Figura 1: Estructura de la especificacin por niveles de SOAP 1.1.

    Los usos estndar y extendidos de SOAP 1.1 se muestran en la figura 2.

    Figura 2: Los usos de base y extendidos de SOAP 1.1.

  • 7/22/2019 Soap Parte1

    10/32

    Las bases de SOAP 1.1

    Habamos visto con anterioridad que los estilos de intercambio propuestos por SOAP 1.1 son

    el mensaje de direccin nica y la peticin/respuesta, con sus dos alternativas documento y

    RPC.

    El mensaje de direccin nica se presenta en esta parte del curso, mientras que el estilo

    peticin/respuesta (documento y RPC) se presentaran posteriormente. Un mensaje de

    direccin nica SOAP 1.1 parte de un nudo expeditor para alcanzar un nodo destinatario

    (figura 3).

    Figura 3: Estilo de intercambio de mensaje en sentido nico.

    Consideremos el siguiente ejemplo:

    Ciao !

    Un mensaje puede transferirse directamente del expeditor al destinatario, o bien transitar por

    un nmero ilimitado de nodos intermediosque forman una cadena de transporte (figura 4).

    Cada nodo intermedio es receptor del mensaje emitido del nodo anterior en la cadena y

    emisor del mensaje para el nodo siguiente. En una cadena de transporte, el expeditor es el

    primer emisor y el destinatario es el ltimo receptor. Un nodo intermedio es una aplicacin

    SOAP 1.1 capaz de recibir y emitir mensajes SOAP 1.1.

    Figura 4: Una cadena de transporte.

    La utilidad del mecanismo de la cadena de transporte es a la vez tcnica y funcional. Desde el

    punto de vista tcnico, el mecanismo normaliza el rol y la funcin del routeador aplicativo.

    Desde el punto de vista funcional, las posibilidades ofrecidas por este mecanismo son

    mltiples. Permite componer servicios de capas (tiers) sobre la base de funciones distribuidas

  • 7/22/2019 Soap Parte1

    11/32

    sobre la cadena de transporte, como la anotacin de los mensajes, la suscripcin, la

    confidencialidad por codificacin, la colocacin del cache o almacenamiento intermedio

    (caching), el no repudio.

    Los diferentes elementos de un mensaje SOAP 1.1 son producidos y consumidos por los

    nodos de la cadena de transporte. Producir un elemento de un mensaje equivale a constituirlo.Consumir un elemento de un mensaje equivale a tratarlo y, para los intermediarios, a remitir

    el mensaje despus de haber suprimido el elemento consumido. Elproductorde un elemento

    de un mensaje SOAP 1.1 es el nodo (expeditor o intermediario) que produce el elemento en

    cuestin (as como todos sus subelementos). El consumidorde un elemento de un mensaje

    SOAP 1.1 es el nodo (intermediario o destinatario) que consume el elemento en cuestin (as

    como todos sus subelementos).

    El expeditor del mensaje es el primer productor del mensaje. El receptor del mensaje, ya sea

    el intermediario o destinatario, debe exhibir un comportamiento normalizado, que puede

    resumirse as:

    1. Debe examinar el mensaje para buscar la informacin que se le destina.

    2. Entre las partes del mensaje que le van dirigidas, all tiene algunas cuyo consumo por

    parte del nodo es obligatorio: si el nodo es de efectuar este consumo, debe

    efectuarlo, y si no es , debe rechazar el mensaje.

    3. Si se trata de un intermediario, entonces debe suprimir del mensaje las partes que

    consume, y puede as producir nuevos elementos, colocados en los lugares del

    mensaje destinados a este efecto, luego debe emitir de nuevo el mensaje hacia el nodo

    siguiente de la cadena de transporte.

    SOAP 1.1 y XML

    El mensaje SOAP 1.1 es un documento XML 1.0. Esto implica que un documento XML 1.0

    no puede no insertarse tal cual en un mensaje SOAP 1.1 (un documento XML no puede

    insertarse sin cambio en otro documento XML). La especificacin SOAP 1.1 no confirma

    explcitamente si un mensaje SOAP 1.1 debe comenzar por la declaracin de uso:

    La especificacin SOAP 1.1 establece que un mensaje SOAP 1.1:

    no debe contener DTD (Document Type Definition), esto esencialmente por la razn

    tcnica que la sintaxis de los DTD no est en el formato XML;

    no debe contener instrucciones ejecutables, cuya presencia es aceptada en los

    documentos basados en XML 1.0.

    La utilizacin generalizada de los vocabularios XML (XML Namespaces) y de los nombres

    calificados es fuertemente aconsejada por la especificacin SOAP 1.1, aunque no obligatorio

    para una aplicacin que desempea solamente el rol de expeditor de mensajes. En cambio, las

    aplicaciones que pretenden desempear el rol de destinatario deben ser capaces de tratar

    correctamente los vocabularios XML de los mensajes que reciben. Estas aplicaciones deben

  • 7/22/2019 Soap Parte1

    12/32

    rechazar los mensajes que utilizan los vocabularios XML de manera incorrecta o que utilizan

    vocabularios XML incorrectos.

    La especificacin SOAP 1.1 define un vocabulario XML SOAP 1.1 para los elementos y los

    atributos propios al formato del mensaje. El identificador del vocabulario XML SOAP 1.1 se

    asocia al URI http://schemas.xmlsoap.org/soap/envelope/.

    La declaracin del vocabulario XML http://schemas.xmlsoap.org/soap/envelope/ es

    obligatoria para todo mensaje SOAP 1.1. Esta declaracin designa la versin de SOAP

    reivindicada por el mensaje.

    El prefijo asociado al vocabulario XML http://schemas.xmlsoap.org/soap/envelope/ en la

    especificacin SOAP 1.1 es SOAP-ENV. El buen uso de los vocabularios XML (cuando un

    prefijo es utilizado por una especificacin cuyos elementos se utilizan en un documento, es

    preferible utilizar el mismo prefijo que la especificacin) sugiere que en el elemento raz

    (SOAP-ENV: Envelope) de todo mensaje SOAP 1.1 aparezca la declaracin:

    xmlns: SOAP-ENV=" http://schemas.xmlsoap.org/soap/envelope/"

    Un mensaje SOAP 1.1 puede integrar declaraciones de vocabularios XML aplicativos

    cualesquiera. El ejemplo presentado en el apartado anterior, cuando integra las declaraciones

    de vocabularios XML y el uso de los nombres calificados, toma el paso siguiente (el

    vocabulario XML designado por el prefijo g es un vocabulario aplicativo):

    Ciao !

    Se normaliza tambin la utilizacin de los atributos. Se admite introducir atributos en los

    elementos de un mensaje SOAP 1.1. Estos atributos pueden integrarse directamente en las

    ocurrencias de los elementos de un mensaje o pueden especificarse en un esquema XS o en unDTD accesible tanto al expeditor como al destinatario. En ese caso, los valores, por defecto o

    fijos, definidos en el esquema XS o el DTD deben tomarse como si aparecan directamente en

    las instancias. Los atributos SOAP-ENV:mustUnderstand y SOAP-ENV:actor son

    introducidos por la especificacin SOAP 1.1 y desempean un papel particular que se

    examinar ms tarde.

    La estructura del mensaje SOAP 1.1

    Un mensaje SOAP 1.1 presenta una estructura normalizada (ver figura 5). Se constituye

    siempre de un elemento (raz), es decir el envelope (SOAP-ENV:Envelope),

  • 7/22/2019 Soap Parte1

    13/32

    que contiene un elemento encabezado (SOAP-ENV:Header) opcionaly un elemento cuerpo

    (SOAP-ENV:Body) obligatorio, seguidos de posibles elementos aplicativos especficos.

    Figura 5: La estructura del mensaje SOAP 1.1.

    El envelope

    El envelope es el elemento (raz) de todo mensaje SOAP 1.1.

    En el envelope de un mensaje SOAP 1.1, la presencia de la declaracin del vocabulario XMLSOAP 1.1 es obligatoria:

    xmlns: SOAP-ENV=" http://schemas.xmlsoap.org/soap/envelope/"

    o, eventualmente:

    xmlns=" http://schemas.xmlsoap.org/soap/envelope/"

    Esta declaracin se utiliza para sealar la versin SOAP (SOAP 1.1) a la cual el mensaje hace

    referencia. El mensaje se espera as ser tratado por todo receptor (intermediario o destinatario)segn la versin del protocolo que exhibe. Si no presenta ninguna versin del protocolo o

  • 7/22/2019 Soap Parte1

    14/32

  • 7/22/2019 Soap Parte1

    15/32

    El URI reservado por la especificacin SOAP 1.1 http://schemas.xmlsoap.org/soap/actor/next

    designa como consumidor de la entrada del encabezad el primer nodo SOAP 1.1 segn el

    emisor en la cadena de transporte.

    La regla de designacin del consumidor para las entradas del encabezado de un mensaje

    SOAP 1.1 es finalmente simple:

    El consumidor designado de una entrada del encabezado que contiene el atributo

    SOAP-ENV:actor, as como de todos sus subelementos, es el nodo cuyo URI es el

    valor del atributo.

    El consumidor designado de una entrada del encabezado que contiene el atributo

    SOAP-ENV:actor que tiene como valor el URI

    http://schemas.xmlsoap.org/soap/actor/next es el primer nodo siguiente al emisor del

    mensaje en la cadena de transporte.

    El consumidor designado de una entrada del encabezado que no contiene atributo

    SOAP-ENV:actor, as como de todos sus subelementos, no puede ser sino eldestinatario del mensaje.

    La figura 6 presenta una cadena de transporte con un nico intermediario: nice.guy.net quiere

    enviar un mensaje a pretty.girl.net por medio del intermediario office.postalservice.com.

    Figura 6: Una cadena de transporte con un solo intermediario (I).

    La designacin absoluta del consumidor

    Veamos el mensaje A (figura 6) emitido por nice.guy.net en la intencin de

    office.postalservice.com:

    http://www.postalstandards.org/send

    http://nice.guy.net/

    http://pretty.girl.net/

    http://pretty.girl.net/home.asp

  • 7/22/2019 Soap Parte1

    16/32

    Ciao !

    El mensaje se recibido de forma correcta por office.postalservice.com que:

    1. recorre el encabezado del mensaje;

    2. identifica el valor de SOAP-ENV:actor en la entrada pbs:postmark como su propio

    URI;

    3. notamos que la accin solicitada es el envo simple del mensaje (designada por el URI

    http://www .postalstandards.org/send);

    4. notamos el valor del elemento pbs:receiverPort;

    5. ignora el elemento SOAP-ENV:Body;

    6. construye un nuevo mensaje en el cual la entrada pbs:postmark es modificada: elatributo SOAP-ENV:actor y el elemento pbs:acction se retiran, adems los elementos

    pbs:sender y pbs:receiver, su propio URI as como la fecha y la hora de recepcin del

    mensaje (a la hora de Greenwitch, segn el formato ISO 8601) igualmente se aaden;

    7. enva el nuevo mensaje sobre el puerto de recepcin http://pretty.girl.net/home.asp.

    Se muestra el mensaje A' (figura 6) emitido por office.postalservice.com para pretty.girl.net:

    http://office.postalservice.com/

    2010-06-30T23:59:59http://www.postalstandards.org/send

    http://nice.guy.net/

    http://pretty.girl.net/

    http://pretty.girl.net/home.asp

  • 7/22/2019 Soap Parte1

    17/32

    En la recepcin, pretty.girl.net trata no solamente el cuerpo del mensaje, sino tambin las

    entradas de encabezado. pretty.girl.net considera el identificador (URI) del expeditor, y

    tambin debido a que la pequea palabra recibida pas por office.postalservice.com,

    considerando la fecha y hora.

    La designacin relativa del consumidor

    En efecto, en esta cadena de transporte, nice.guy.net no tiene que especificar el

    URI del intermediario como valor del atributo SOAP-ENV:actor: el URI especial

    http://schemas.xmlsoap .org /soap/actor/next puede convenir.

    El mensaje A (figura 6) producido y emitido por nice.guy.net puede ser el siguiente:

    La ventaja de este enfoque es evidente: el mensaje el servicio Web que lo

    transporta. Una vez preparado el mensaje, nice.guy.net puede decidir en los ltimos minutos

    del prestador de servicios postales Web que el va a solicitar para enviar su pequea palabra a

    pretty.girl.net, sobre la base de diferentes criterios como el precio, la calidad de servicio, etc.

    Queda claro que, para obtener este resultado, es necesario que una serie de prestadores de

    servicios postales Wen se hayan puesto de acuerdo sobre el formato y sobre un tratamiento de

    las entradas de los encabezados, cuyo vocabulario XML es:

    http://www.postalstandards.org/basicservices/.

    El atributo SOAP-ENV:mustUnderstand

    El atributo SOAP 1.1 SOAP-ENV:mustUnderstand se utiliza para indicar que el consumo de

    la entrada del encabezado por el consumidor potencial designado es obligatorio (valor " 1") o

    facultativo (valor " 0" , valor por defecto).

    La lnea de conducta que los nodos que participan deben tener en una cadena de transporte de

    un mensaje SOAP 1.1 es la siguiente:

    El consumidor designado de un elemento del encabezado con SOAP-

    ENV:mustUnderstand=" 1" debe consumir el elemento en cuestin. Si es

  • 7/22/2019 Soap Parte1

    18/32

    (el sentido de esta se precisar en la seccin consagrada a la gestin

    de los errores), debe rechazar el mensaje.

    El consumidor designado de un elemento del encabezado con SOAP-

    ENV:mustUnderstand=" 1" , que es de consumir el mensaje, debe no

    solamente rechazarlo pero puede decidir enviar un mensaje de error al emisor del

    mensaje que acaba de recibir. Este tratamiento slo puede ser aplicable si el receptores capaz de emitir mensajes SOAP 1.1.

    El consumidor designado de la entrada del encabezado con SOAP-ENV:

    mustUnderstand=" 0" puede consumir o no esta entrada. Si decide no consumirla,

    debe re-emitir el mensaje tal cual hacia el prximo nodo de la cadena de transporte

    (aunque el valor de SOAP-ENV:actor lo designa directamente, por lo tanto como

    consumidor exclusivo). En ese caso, el elemento en cuestin no se consumir por

    ningn nodo intermedio y fallar en el destinatario, quien, en teora, no tiene el

    derecho a consumirlo tampoco.

    Vamos a suponer, por ejemplo, que nice.guy.net quiere enviar siempre la misma pequeapalabra a pretty.girl.net, pero que desea un servicio de envo recomendado (garantizado).

    Desea en realidad que el servicio postal Web utilice un protocolo de transporte garantizado

    para transmitir su mensaje al destinatario. Si el servicio postal Web no llega por una razn

    cualquiera a hacer llegar el mensaje al destinatario, debe informar al expeditor. El envo

    recomendado es un servicio normalizado por www.postalstandards.org (cuyo vocabulario

    XML se define por http://www .postalstandards.org/smartservices/, relativo a la nueva versin

    de servicios postales) ofrecido, entre otras cosas, por office.smartpservice.com. Por otra parte,

    nice.guy.net desea que el servicio est prestado por office.smartpservice.com.

    Figura 7: Una cadena de transporte con un solo intermediario (II).

    A continuacin, se muestra el mensaje A en este nuevo contexto (figura 7, que se distingue de

    la figura 6 solo por el nombre del intermediario).

    http://www.postalstandards.org/reliableSend

    http://nice.guy.net/letter#000001

    http://nice.guy.net/http://nice.guy.net/home.jsp

  • 7/22/2019 Soap Parte1

    19/32

    http://pretty.girl.net/

    http://pretty.girl.net/home.asp

    Tenemos en cuenta inmediatamente que, para obtener tal servicio, nice.guy.net debe marcar el

    mensaje con un nico identificador que debe recordarse en caso de problemas. Utiliza para

    esto el URI http://nice .guy.net/letter#000001 como valor del elemento pss:id.

    office.smartpservice.com es efectivamente capaz de garantizar el servicio y en consecuencia:

    1. recorre el encabezado del mensaje;

    2. define el valor de SOAP-ENV:actor en la entrada pss: postmark como su propio URI;

    3. notemos que la accin solicitada es el envo recomendado del mensaje (designada por

    el URI http://www .postalstandards.org/reliableSend);

    4. notemos tambin el identificador del mensaje, valor del elemento pss: id;

    5. el valor del elemento pss:receiverPort;

    6. ignora el elemento SOAP-ENV: Body;

    7. construye un nuevo mensaje en el cual la entrada pss:postmark es modificada: los

    atributos SOAP-ENV:actor y SOAP-ENV:mustUnderstand, as como el elemento pss:

    acction y pss: senderPort son suprimidos. En cambio, los elementos pss: sender y pss:

    receiver, su propio URI as como la fecha y la hora de recepcin del mensaje se

    aaden;

    8. enva el nuevo mensaje sobre el puerto de recepcin http://pretty.girl.net/home.asp

    utilizando su protocolo garantizado.

    El mensaje A' (figura 7), transmitido por office.smartpservice.com a pretty.girl.net,

    transportado por su protocolo garantizado, es pues el siguiente:

    http://office.smartpservice.com/

  • 7/22/2019 Soap Parte1

    20/32

    2010-06-30T23:59:59

    http://www.postalstandards.org/reliableSend

    http://nice.guy.net/

    http://pretty.girl.net/http://pretty.girl.net/home.asp

    Vamos a suponer que, si office.smartpservice.com est en condiciones de garantizar el

    servicio de envo recomendado, office.postalservice.com an no implemento los nuevos

    servicios de intercambio fiable (http://www.postalstandards.org/smartservices/), especificados

    por la organizacin interprofesional a la cual se adhiere con office.smartpservice.com. Si un

    mensaje como el precedente le era enviado por nice.guy.net, la especificacin SOAP 1.1 lo

    obligara a rechazar el mensaje y, eventualmente, a devolver un mensaje de error al

    (expeditor) remitente.

    Se encuentra que office.postalservice.com est en relacin de asociacin conoffice.smartpservice.com, que garantiza el servicio de envo recomendado. En efecto,

    office.postalservice.com reenva los mensajes a su socio en caso de peticin de envo

    recomendado.

    Una cadena de transporte ms tolerante puede implementarse segn el esquema de la figura 8.

    Figura 8: Cadena de transporte con recodo.

    Para implementar esta cadena de transporte, es necesario operar dos cambios:

    para evitar la restriccin SOAP-ENV:mustUnderstand=" 1" : basta para esto retirar elatributo SOAP-ENV: mustUnderstand;

  • 7/22/2019 Soap Parte1

    21/32

    sustituir como valor de SOAP-ENV: actor el URI http://office.smartpservice.com/ por

    el URI genrico http://schemas.xmlsoap.org/soap/actor/next.

    A continuacin se muestra el mensaje emitido por nice.guy.net para office.postalservice.com:

    http://www.postalstandards.org/reliableSendhttp://nice.guy.net/letter#000001

    http://nice.guy.net/

    http://nice.guy.net/home.jsp

    http://pretty.girl.net/http://pretty.girl.net/home.asp

    office.postalservice.com recibe pues este mensaje enviado por nice.guy.net.

    office.postalservice.com es destinatario de la entrada de encabezad pss: postmark, pero

    se da cuenta de que no es capaz de tratar esta entrada del encabezado que se le destina.

    En vez de rechazar el mensaje y devolver un mensaje de error al expeditor (se forzara

    a actuar as con SOAP-ENV: mustUnderstand=" 1" en la entrada del encabezado), esta

    vez, enva exactamente el mismo mensaje a office.smartpservice.com que se comporta

    exactamente como lo describimos anteriormente.

    El cuerpo

    El cuerpo de un mensaje SOAP 1.1 es producido por el expeditor del mensaje y

    consumido obligatoriamente por el destinatario, independientemente del nmero de

    nodos intermedios que son susceptibles de transportar el mensaje. Lo mismo ocurre

    con los elementos facultativos y que siguen el cuerpo.

    El elemento cuerpo est obligatoriamente presente en un mensaje SOAP 1.1 como

    descendiente directo del elemento envelope, siguiendo inmediatamente el elemento

    encabezado (presente) y seguido eventualmente por los elementos proprietarios.

  • 7/22/2019 Soap Parte1

    22/32

    El elemento cuerpo puede contener un conjunto de elementos descendientes, que

    pueden ser calificados por la referencia a uno o a ms espacios de nombres. Estos

    elementos se llaman entradas del cuerpo.

    El elemento cuerpo puede tambin contener un elemento SOAP 1.1 error (SOAP-ENV:

    Fault), que es definido por la especificacin, para tratar los casos de error.

    La especificacin SOAP 1.1 sugiere considerar el cuerpo como semnticamente equivalente a

    una entrada del encabezado sin atributo SOAP-ENV:actor (y en consecuencia destinado al

    consumo del destinatario) y con el atributo SOAP-ENV:mustUnderstand=" 1". Esto quiere

    decir, entre otras cosas, que si el destinatario no est en condiciones de consumir el cuerpo,

    debe rechazar el mensaje y, si l tiene la posibilidad, debe devolver un mensaje de error al

    emisor.

    La gestin de los errores en SOAP 1.1

    El error SOAP 1.1 se produce siempre debido a una incapacidad del nodo receptor del

    mensaje SOAP 1.1 que debe consumir el mensaje o la parte del mensaje que se le destina.

    Esta incapacidad puede deberse:

    ya sea a un defecto sintctico o semntico del mensaje;

    o a un fallo del nodo receptor en el tratamiento del mensaje.

    El mensaje recibido implicado en una situacin de error se llamar mensaje en error(faulty

    message). Un mensaje en error es pues o un mensaje sintctica o semnticamente incorrecto,

    o bien un mensaje correcto cuyo tratamiento fall debido a un fallo del nodo receptor.

    La especificacin SOAP 1.1 menciona las circunstancias en las cuales el receptor de un

    mensaje SOAP 1.1 reconoce una situacin de errorasociada al mensaje recibido (mensaje en

    error), as como las circunstancias en las cuales el receptor de un mensaje en error indica una

    situacin de error. Esta descripcin personal puede tomar la forma de la transmisin de un

    mensaje de error (fault message) a la intencin del emisor inicial. El mensaje de error

    contiene siempre informacin sobre la naturaleza del error para el emisor del mensaje en

    error. La especificacin SOAP precisa el formato y el contenido del mensaje de error.

    La gestin de los errores SOAP 1.1 incluye pues tres etapas distintas:

    1. el tratamiento del mensaje en error por su receptor;

    2. la descripcin personal del error y la produccin y la emisin del mensaje de error

    correlacionado al mensaje en error;

    3. la recepcin del mensaje de error por parte del emisor del mensaje en error.

    El tratamiento del mensaje en error

    La incapacidad por parte del receptor que debe consumir el mensaje en error (las partes que se

    le destinan para consumo) debe traducirse, en casos puntuales (ver la descripcin de los tipos

    de errores SOAP 1.1 en la seccin ), en el rechazo del mensaje porparte del receptor o en el fracaso de su tratamiento.

  • 7/22/2019 Soap Parte1

    23/32

    Sin embargo, la especificacin SOAP 1.1 no precisa la semntica operativa del rechazo del

    mensaje o el fracaso del tratamiento. El emisor del mensaje en error no est autorizado a

    obtener ciertas conclusiones sobre el tratamiento total o parcial del mensaje en error y sobre

    sus consecuencias. Es pues posible que los cambios de estado y/o efectos de borde se hayan

    producido a raz del tratamiento del mensaje en error por el receptor.

    La situacin ideal sera que:

    El receptor del mensaje en error completa el anlisis sintctico y semntico del

    mensaje en error antes de desencadenar todo tratamiento que produce los cambios de

    estado y las consecuencias de los efectos de borde del consumo del mensaje.

    El receptor implementa una gestin transaccional de los tratamientos que producen los

    cambios de estado y las consecuencias de los efectos de borde del consumo del

    mensaje. La gestin transaccional permite tratar correctamente los casos de fallo

    (panne franche) del receptor.

    El sealamiento del error

    El receptor debe indicar la situacin de error consiguiente a la recepcin de un mensaje en

    error por todos los medios a su disposicin (levantamiento de una excepcin, visualizacin

    sobre una consola de usuario o administrador, produccin de un diario de navegacin, etc.).

    La emisin de un mensaje de error para el emisor del mensaje en error es uno de estos

    medios. La especificacin SOAP 1.1 define las modalidades de este medio de sealamiento y

    deja la implementacin de los nodos SOAP las otras modalidades.

    Las capacidades de emisin y recepcin de los mensajes SOAP 1.1

    El receptor puede ser incapaz de emitir mensajes SOAP 1.1 (es un puro receptor UDP, por

    ejemplo) o puede ser capaz de emitir mensajes SOAP 1.1 solamente en circunstancias

    particulares (es un servidor sobre un protocolo de transporte bidireccional como HTTP, capaz

    de recibir peticiones y emitir respuestas correlacionadas: en ese caso, puede utilizar la

    respuesta para transportar el mensaje de error).

    El punto determinante es por lo tanto la capacidad de emisin de mensajes SOAP 1.1, y en

    consecuencia de mensajes de error, por parte del receptor del mensaje en error. Podemos

    distinguir cuatro clases bsicas para los nodos SOAP 1.1, con relacin a sus capacidades deemisin/recepcin de mensajes SOAP 1.1:

    Emisor SOAP 1.1 es un nodo que tiene una capacidad de emisin de mensajes de

    direccin nica SOAP 1.1.

    ReceptorSOAP 1.1 es un nodo que tiene una capacidad de recepcin de mensajes de

    direccin nica SOAP 1.1.

    ClienteSOAP 1.1 es un nodo que tiene una capacidad de emisin de peticiones SOAP

    1.1 y de recepcin de respuestas SOAP 1.1 correlacionadas a las peticiones emitidas.

    Servidor SOAP 1.1 es un nodo que tiene una capacidad de recepcin de peticiones

    SOAP 1.1 y de emisin de respuestas SOAP 1.1 correlacionadas a la peticin recibida.

  • 7/22/2019 Soap Parte1

    24/32

    Las capacidades de emisin/recepcin de un nodo SOAP 1.1 resultan de la combinacin de

    estas clases bsicas.

    La correlacin entre mensaje en error y mensaje de error

    La correlacin entre mensaje en error y mensaje de error es un elemento esencial delmecanismo de gestin de los errores SOAP: un mensaje de error es una herramienta

    computacional y slo cumple su rol si se correlaciona de manera no ambigua al mensaje en

    error que lo caus.

    Por otra parte, la correlacin directa e implcita entre un mensaje en error y un mensaje de

    error slo es posible entre un cliente y un servidor SOAP 1.1, en el estilo de intercambio

    peticin/respuesta, cuando el mensaje en error es la peticin SOAP. En ese caso, el mensaje

    de error sustituye a la respuesta al mensaje (peticin) en error y la correlacin est garantizada

    por el estilo de intercambio.

    Aparte de este caso preciso, la correlacin mensaje en error y mensaje de error, como aquella

    entre los mensajes en una , no puede ser obtenida ms que por un protocolo

    aplicativo que permite dotar cada mensaje de un nico identificador. Se recuerda este

    identificador explcitamente cada vez que es necesario establecer una correlacin con otro

    mensaje.

    Por otra parte, aunque en la especificacin, la emisin de un mensaje de error parece siempre

    vinculada al acto previo de un error, no excluye emitir un mensaje de error

    independientemente de una situacin de error, para indicar un estado (notificacin de status).

    La notificacin de status sirve para indicar una situacin corriente (status) de fallo de un

    nodo, sobre iniciativa del propio nodo. Se podra uno imaginar, por ejemplo, que

    office.postalservice.com enva a sus clientes, a su iniciativa, un mensaje de error sobre la no

    disponibilidad temporal de sus servicios y, a continuacin, sobre el restablecimiento del

    funcionamiento normal. La tabla 1 resume las actitudes de los nodos con relacin a la

    recepcin y al tratamiento de un mensaje en error y al envo de un mensaje.

  • 7/22/2019 Soap Parte1

    25/32

    Gestin de

    error

    SOAP 1.1

    Nodo SOAP

    1.1

    Capacidad de

    recepcin mensaje

    en error

    Tratamiento

    mensaje

    en error

    Capacidad de emisin

    mensaje de error

    correlacionado

    Capacidad

    de emisin

    mensaje de error

    no

    correlacionado

    (status)

    Emisor NO (no aplicable) (no aplicable) SI (emisin de

    un

    mensaje de

    error)

    Receptor SI Rechaza mensaje

    o

    tratamiento de

    fracaso

    NO NO

    Cliente SI (mensaje en

    error en unarespuesta)

    Rechaza mensaje

    otratamiento de

    fracaso

    SI (inclusin del mensaje

    de error correlacionado enla respuesta al mensaje en

    error)

    NO

    Servidor SI (mensaje en

    error en una peticin

    explcitamente

    correlacionada con

    un mensaje de un

    intercambio anterior.

    Rechaza mensaje

    o tratamiento de

    fracaso

    SI (inclusin del mensaje

    de error correlacionado en

    la respuesta al mensaje en

    error)

    NO

    Tabla 1: Resumen de las capacidades de emisin/recepcin de un menaje de error por losnodos SOAP 1.1.

    El elemento error (SOAP-ENV:fault)

    El elemento error (SOAP-ENV:Fault) del cuerpo de un mensaje SOAP 1.1 est destinado a

    transportar una informacin de error o de estado.

    La especificacin SOAP 1.1 precisa que el elemento error es obligatoriamente una entrada del

    cuerpo. Esta entrada puede estar presente a lo ms una vez en el cuerpo de un mensaje SOAP

    1.1. Puede ser la nica entrada o estar acompaada de otras entradas del cuerpo.

    La especificacin SOAP 1.1 define cuatro subelementos de la entrada error (SOAP-

    ENV:Fault):

    el elemento cifrado de error (faultcode);

    el elemento expresado de error (faultstring);

    el elemento expeditor del mensaje de error (faultactor);

    el elemento detalle de error (detail).

    La especificacin SOAP 1.1 no excluye la presencia de elementos aplicativos cuyos nombres

    pertenecen a los vocabularios XML aplicativos como descendientes directos de SOAP-ENV:Fault.

  • 7/22/2019 Soap Parte1

    26/32

    El elemento cifrado de error (faultcode)

    El elemento cifrado de error (faultcode) transporta una informacin sobre el error encontrado

    que se destina tpicamente a la explotacin por programa. El elemento faultcode est

    obligatoriamente presente en el elemento SOAP-ENV:Fault y su valor debe ser un nombre

    calificado.

    SOAP 1.1 define cuatro tipos de errores, cada uno designado por un , bajo el

    formato de un nombre calificado por el vocabulario XML:

    http://schemas.xmlsoap.org/soap/envelope/.

    Los cdigos de errores SOAP 1.1 son:

    SOAP-ENV:VersionMismatch: el cdigo indica que el vocabulario XML de las

    balizas (marcas) de estructura (Envelope, Header, Body, Fault) del mensaje en error

    no es el de SOAP 1.1 (http://schemas .xmlsoap.org/soap/envelope/); SOAP-ENV:MustUnderstand: el cdigo indica que el emisor del mensaje de error

    recibi como mensaje en error un mensaje que se ve obligado a tratar (SOAP-ENV:

    mustUnderstand=" 1") y que no es funcionalmente capaz de tratar;

    SOAP-ENV:Client: el cdigo indica que el mensaje en error est sintctica y/o

    semnticamente incorrecto: ya sea mal formado, o no contiene la informacin

    apropiada para estar convenientemente tratado;

    SOAP-ENV:Server: el mensaje en error no pudo tratarse debido a un fallo tcnico o

    aplicativo del nodo receptor: este ltimo cdigo puede tambin utilizarse para

    notificaciones de status.

    Los cdigos de errores SOAP 1.1 pueden ser, segn la especificacin, especializados por un

    sufijo (separado por un punto), por ejemplo: SOAP-ENV:Client.Authentication.

    El cdigo de error de arriba indica que el error es un error SOAP 1.1, de la clase Client, con

    una especialidad Authentication. El sentido de este cdigo, resultante de un acuerdo privado

    entre los interlocutores, es que el error viene de un problema de autenticacin del nodo emisor

    del mensaje en error.

    El elemento expresado de error (faultstring)

    El elemento expresado de error (faultstring) est destinado tpicamente a proporcionar una

    explicacin del error comprensible por los actores humanos (generalmente, los diseadores y

    los administradores de servicios Web). Est obligatoriamente presente en el elemento SOAP-

    ENV:Fault.

    El elemento expeditor del mensaje de error (faultactor)

    El elemento expeditor del mensaje de error (faultactor) est destinado a proporcionar

    informacin sobre el nodo expeditor del mensaje de error. Su valor es un URI.

  • 7/22/2019 Soap Parte1

    27/32

    La presencia de tal elemento es obligatoria si el expeditor del mensaje de error es un nodo

    intermediario en la cadena de transporte del mensaje. Si tal elemento est ausente, eso quiere

    decir que el expeditor del mensaje de error es el destinatario del mensaje en error.

    El elemento detalle de error (detalle)

    El elemento detalle del error (detail) est destinado a proporcionar informacin de origen

    aplicativo sobre el error ocurrido. Si el error ocurri en el tratamiento del cuerpo del mensaje

    en error, el elemento detailest obligatoriamente presente en el mensaje de error. En cambio,

    la ausencia de este elemento indique que el error no ocurri en el tratamiento del cuerpo del

    mensaje en error.

    Por otra parte, detail no debe utilizarse para transportar informacin sobre los errores

    ocurridos en el tratamiento de las entradas del encabezado.

    El elemento detailpuede contener sub-elementos llamados entradas del detalle. Cada entrada

    del detalle es independiente de las otras, posee un nombre calificado, y el atributo SOAP 1.1SOAP-ENV:encodingStyle puede utilizarse para indicar el estilo de codificacin de las

    entradas del detalle.

    Los tipos de errores

    Vamos a ilustrar el uso de los cdigos de errores mediante un ejemplo en el cual el mensaje

    en error se presenta a un intermediario en la cadena de transporte (ver la figura 9). En efecto,

    el destinatario del mensaje en error A es, en todos los casos de errores tratados, pretty.girl.net.

    Esto nos permite dar ms generalidad y completes al ejemplo. Hay que sealar que el uso del

    elementofaultactores obligatorio en tal situacin ya que el expeditor del mensaje de error no

    es el destinatario del mensaje en error.

    Figura 9: La cadena interrumpida por un error (I).

    El cdigo SOAP-ENV:VersionMismatch

    El valor SOAP-ENV:VersionMismatch de faultcode indica que el vocabulario XML de las

    marcas de estructura del mensaje en error no es http://schemas.xmlsoap.org/soap/envelope/.

    En SOAP 1.1, el vocabulario http://schemas.xmlsoap.org/soap/envelope/ es el nico aceptable

    para las marcas de estructura (Envelope, Header, Body, Fault) e indica que el mensaje se

    ajusta a la especificacin SOAP 1.1.

    En el ejemplo presentado en la figura 9, nice.guy.net enva a office.postalservice.com elmensaje A siguiente, teniendo como destinatario pretty.girl.net:

  • 7/22/2019 Soap Parte1

    28/32

    El vocabulario XML para los nombres de las marcas de estructura es el asociado a la

    especificacin SOAP 1.0. office.postalservice.com es un nodo SOAP 1.1, y reacciona pues

    por el rechazo del mensaje A (y en consecuencia la negativa a transportarlo hacia

    pretty.girl.net) y el envo a nice.guy.net del mensaje de error siguiente B (ver figura 9):

    SOAP-ENV:VersionMismatchSoap 1.0 is not supported.

    http://office.postalservice.com/

    El cdigo SOAP-ENV:MustUndestand

    El cdigo SOAP-ENV:MustUnderstand de faultcode indica que el emisor del mensaje de

    error recibi como mensaje en error un mensaje que contiene un elemento:

    que se designa a consumidor (el valor explcito o por defecto de SOAP-ENV: actor lo

    designa);

    que tiene la obligacin de tratar (SOAP-ENV:mustUnderstand=" 1") ;

    y que no es funcionalmente capaz de tratar () el elemento en

    cuestin.

    Recordamos que si este elemento es:

    una entrada del encabezado, el consumidor designado es ya sea un nodo en la cadena

    de transporte explcitamente designada por SOAP-ENV:actor, o ya sea, a falta de

    SOAP-ENV:actor, el destinatario;

    el cuerpo (o uno de sus descendientes), el consumidor designado es el destinatario, con

    obligacin de siempre el elemento (lo que es equivalente, para las

    entradas del encabezado, a SOAPENV:mustUnderstand=" 1").

  • 7/22/2019 Soap Parte1

    29/32

  • 7/22/2019 Soap Parte1

    30/32

    http://www.postalstandards.org/send

    http://nice.guy.net/

    office.postalservice.com no puede proporcionar la prestacin:

    http://www.postalstandards.org/send ya que los datos del destinatario:

    http://pretty.girl.net/

    http://pretty.girl.net/home.asp

    no se especifican en el mensaje. Rechaza pues el mensaje A y enva a nice.guy.net el mensaje

    de error B (ver figura 9):

    SOAP-ENV:Client

    Missing routing datahttp://office.postalservice.com/

    Missing last receivers name and address

    El cdigo SOAP-ENV:Server

    El cdigo SOAP-ENV:Server de faultcode indica que el mensaje en error no pudo tratarse

    debido a un fallo tcnico o aplicativo del nodo receptor. El fallo puede ocurrir en cualquier

    momento del tratamiento: si el receptor considera que es pertinente correlacionar el fallo con

    la recepcin del mensaje en error, este responde con un mensaje de error.

  • 7/22/2019 Soap Parte1

    31/32

    Vamos a reconsiderar el ejemplo de nice.guy.net que solicita un envo recomendado, por

    medio de office.smartpservice.com, a pretty.girl.net (figura 10, la cual se distingue de la

    figura 9 solamente por el URI del intermediario).

    Figura 10: La cadena interrumpida por un error (II).

    nice.guy.net transmite el mensaje A (figura 10) siguiente a office.smartpservice.com con una

    peticin de envo recomendado del mensaje a pretty.girl.net:

    http://www.postalstandards.org/reliableSend

    El servicio de envo recomendado de oficce.smartpservice.com se construye sobre una

    arquitectura de colas persistentes de mensajes. El servidor que debe efectuar la transferencia

    del mensaje hacia pretty.girl.net est temporalmente fuera de servicio debido al

    desbordamiento de la cola de espera de los mensajes que deben transportarse.

    office.smartpservice .com rechaza el mensaje A y enva a nice.guy.net el mensaje de errorsiguiente B (figura 10):

    SOAP-ENV:Server Message queue overflow

    http://office.smartpservice.com/

    Try later

  • 7/22/2019 Soap Parte1

    32/32

    La gestin de las situaciones de error de tipo VersionMismatch, MustUnderstand y Client nosignifica un problema particular, ya que estas situaciones son detectables con el simple

    anlisis del mensaje en error. Es posible que el receptor del mensaje en error siga

    estrictamente las consignas del perfil de base WS-I, es decir rechazar el mensaje (y enviar

    eventualmente un mensaje de error) inmediatamente despus de anlisis y antes de todo

    tratamiento. El acto de comunicacin transportado por el mensaje est en fracaso y no hay

    efectos del acto sobre el receptor, excepto los efectos tcnicos de tipo inscripcin en el diario

    de explotacin.

    En cambio, la gestin de las situaciones de error de tipo Server puede revelarse mucho ms

    delicada. En estas situaciones, se realizan las condiciones de xitodel acto de comunicacin y

    son las condiciones de satisfaccindel mismo acto que no lo son. El ejemplo anterior no tienealgn problema particular ya que la situacin despus de levantamiento del error es lo mismo

    que antes del envo del mensaje A.

    Pero en el caso ms general, el pragmtico (los efectos sobre el receptor) del acto de

    comunicacin transportado por el mensaje puede implicar cambios de estados y efectos de

    borde que se efectan como consecuencias de la recepcin del mensaje en error, pero antes de

    que la situacin de error Server se declara.

    Cul es el estatuto de estos cambios de estado y estos efectos de borde despus del fallo y

    reconocimiento por parte del receptor de la situacin de error Server correlacionada con el

    mensaje en error? La gestin de los tratamientos asociados a la recepcin de un mensaje como

    una unidad de trabajo transaccional permite solucionar el problema. La gestin transaccional

    de los tratamientos asociados a la recepcin de los mensajes traen la situacin de

    insatisfaccin del acto de comunicacin a la situacin de fracaso del mismo acto: es como si

    el acto no se haba efectuado nunca.