Simple Object Access Protocol
| ||||
Simple Object Access Protocol (SOAP). Es un camino para un programa que se ejecuta en un tipo de sistema operativo (como Windows 2000) para comunicarse con un progama en el mismo o en otro tipo de un sistema operativo (como Linux) mediante el uso de la World Wide Web de transferencia de hipertexto y su lenguaje de marcado extensible (XML) como los mecanismos para el intercambio de información.
Sumario
Generalidades
Este protocolo deriva de un protocolo creado por David Winer, XML–RPC en 1998, el primero en comunicación bajo http mediante XML. Con este protocolo se podían realizar Remote Procedure Calls (RPC), es decir, se podía bien en cliente o servidor realizar peticiones mediante http a un servidor web. Los mensajes debían tener un formato determinado empleando XML para encapsular los parámetros de la petición. Con el paso del tiempo el proyecto iniciado por David Winer interesó a importantes multinacionales entre las que se encuentran IBM y Microsoft y de este interés por XML–RPC se desarrolló "SOAP".
En el núcleo de los servicios Web se encuentra el protocolo simple de acceso a datos SOAP, que proporciona un mecanismo estándar de empaquetar mensajes. SOAP ha recibido gran atención debido a que facilita una comunicación del estilo RPC entre un cliente y un servidor remoto. Pero existen multitud de protocolos creados para facilitar la comunicación entre aplicaciones, incluyendo RPC de Sum, DCE de Microsoft, RMI de Java y ORPC de CORBA.
SOAP ha recibido un increíble apoyo por parte de la industria. Es el primer protocolo de su tipo que ha sido aceptado prácticamente por todas las grandes compañías de software del mundo. Compañías que en raras ocasiones cooperan entre sí están ofreciendo su apoyo a este protocolo. Algunas de las mayores Compañías que soportan SOAP son Microsoft, IBM, SUN, Microsystems, SAP y Ariba.
Algunas ventajas
- No esta asociado con ningún lenguaje: los desarrolladores involucrados en nuevos proyectos pueden elegir desarrollar con el ultimo y mejor lenguaje de programación que exista pero los desarrolladores responsables de mantener antiguas aflicciones heredadas podrían no poder hacer esta elección sobre el lenguaje de programación que utilizan. SOAP no especifica una API, por lo que la implementación de la API se deja al lenguaje de programación, como en Java, y la plataforma como Microsoft .Net.
- No se encuentra fuertemente asociado a ningún protocolo de transporte: La especificación de SOAP no describe como se deberían asociar los mensajes de SOAP con HTTP. Un mensaje de SOAP no es más que un documento XML, por lo que puede transportarse utilizando cualquier protocolo capaz de transmitir texto. No está atado a ninguna infraestructura de objeto distribuido. La mayoría de los sistemas de objetos distribuidos se pueden extender, y ya lo están alguno de ellos para que admitan SOAP.
- Aprovecha los estándares existentes en la industria: Los principales contribuyentes a la especificación SOAP evitaron, intencionadamente, reinventar las cosas. Optaron por extender los estándares existentes para que coincidieran con sus necesidades. Por ejemplo, SOAP aprovecha XML para la codificación de los mensajes, en lugar de utilizar su propio sistema de tipo que ya están definidas en la especificación esquema de XML. Y como ya se ha mencionado SOAP no define un medio de trasporte de los mensajes; los mensajes se pueden asociar a los protocolos de transporte existentes como HTTP y SMTP.
- Permite la interoperabilidad entre múltiples entornos: SOAP se desarrolló sobre los estándares existentes de la industria, por lo que las aplicaciones que se ejecuten en plataformas con dicho estándares pueden comunicarse mediante mensaje SOAP con aplicaciones que se ejecuten en otras plataformas. Por ejemplo, una aplicación de escritorio que se ejecute en una PC puede comunicarse con una aplicación del back–end ejecutándose en un mainframe capaz de enviar y recibir XML sobre HTTP.
Desventajas
- Debido a la detallada en formato XML, SOAP puede ser considerablemente más lento que la competencia tecnologías middleware.
- Cuando se depende en HTTP como protocolo de transporte y no mediante WS-Addressing o un ESB, los roles de las partes que interactúan son fijos. Sólo una de las partes (el cliente) puede utilizar los servicios de la otra. Los desarrolladores deben utilizar el sondeo en lugar de la notificación en estos casos comunes.
- La mayoría de los usos de HTTP como un protocolo de transporte se realizan en la ignorancia de cómo la operación se inspirarían en HTTP. Esto es por diseño (con analogía a la forma en diferentes protocolos se sientan en la parte superior de cada uno en la pila IP), pero la analogía es imperfecta (ya que los protocolos de aplicación que se utiliza como protocolos de transporte no son realmente los protocolos de transporte).
Mensajería SOAP
Proporciona un mecanismo estándar de empaquetar un mensaje. Un mensaje SOAP se compone de un sobre que contiene el cuerpo del mensaje y cualquier información de cabecera que se utiliza para describir le mensaje. El elemento raíz del documento es el elemento Envelope. El ejemplo contiene dos subelementos, Body y Header. Un ejemplo de SOAP valido también puede contener otros elementos hijo en el sobre. El sobre puede contener un elemento Header opcional que contiene información sobre el mensaje.
Un mensaje debe estar dentro de sobre de SOAP bien construido. Un sobre se compone de un único elemento envelope el sobre puede contener un elemento Header y puede contener un elemento body. Si existe, la cabecera debe ser el elemento hijo inmediato del sobre, con el cuerpo siguiendo inmediatamente a la cabecera. El cuerpo contiene la carga de datos del mensaje y la cabecera contiene los datos adicionales que no pertenecen necesariamente al cuerpo del mensaje. Además de definir un sobre de SOAP, la especificación de SOAP define una forma de codificar los datos contenidos en un mensaje.
La codificación de SOAP proporciona un mecanismo estándar para serialisar tipos de datos no definidos en la parte 1 de la especificación del esquema de XML. La especificación de SOAP también proporciona un patrón de mensaje estándar para facilitar el comportamiento de tipo RPC. Se emparejan dos mensajes de SOAP para facilitar la asociación de un mensaje de petición con un mensaje de respuesta.
La llamada a un método y sus parámetros se serializan en el cuerpo del mensaje de petición en forma de una estructura. El elemento raíz tiene el mismo nombre que el método objetivo, con cada uno de los parámetros codificado como un subelemento. El mensaje de respuesta puede contener los resultados de la llamada al método o una estructura de fallo bien definida. Los resultados de la llamada a un método se serializan en el cuerpo de la petición como una estructura. Por convenio, el elemento raíz tiene el mismo nombre que el método original al que se añade el resultado. Los parámetros de retorno se serializan como elementos hijo, con el parámetro de retorno en primer lugar. Si se encuentra un error el cuerpo del mensaje de respuesta contendrá una estructura de fallo bien definida.
SOAP sobre correo electrónico
Hoy en día los desarrolladores de aplicaciones, pueden utilizar la infraestructura de correo electrónico de Internet para transmitir mensajes SOAP ya sean como mensajes de correo electrónico de texto o como adjuntos. Las especificaciones SOAP Versión 1.2 no especifican tal vínculo. Sin embargo, existe una Nota W3C no-normativa SOAP Email Binding que describe un vínculo de SOAP con el correo electrónico, su propósito principal es comenzar a demostrar la aplicación de la Infraestructura general de Vínculos con el Protocolo SOAP.
