La creciente recepción del protocolo SOAP (Simple Object Access Protocol), por parte de la industria tecnológica para orientar y desarrollar los "servicios web", indica que se está transformando en un estándar que ayuda a la productividad y eficiencia de las empresas en entornos virtuales.
En un mundo cada vez más interconectado y donde una gran cantidad de aplicaciones empresariales y de servicios corren a través de Internet, las corporaciones no se conforman con aplicaciones web simples o sistemas de transacciones online convencionales. De a poco, los "web services" están tomando cada vez más protagonismo, tanto para el manejo interno de una compañía, como para su relación con proveedores, clientes y la comunidad que los rodea.
Dentro de este contexto aparece SOAP (Simple Object Access Protocol), protocolo elaborado para facilitar la llamada remota de funciones a través de Internet, permitiendo que dos programas se comuniquen de una manera muy similar técnicamente a la invocación de páginas Web.
En un principio, este protocolo se utilizaba para realizar RPC o remote procedure calls, es decir, se podía 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 una multitud de protocolos creados para facilitar la comunicación entre aplicaciones, incluyendo RPC de Sun, DCE de Microsoft, RMI de Java y ORPC de CORBA.
¿Por qué se presta tanta atención a SOAP?
Una de las razones principales es que SOAP ha recibido un increíble apoyo por parte de la industria y es el primer protocolo de su tipo que ha sido aceptado prácticamente por todas las grandes compañías de software del mundo. Algunas de las mayores empresas que soportan SOAP son las ya nombradas Microsoft e IBM, además de otras como SUN Microsystems, SAP y Ariba.
El protocolo SOAP tiene diversas ventajas sobre otras maneras de llamar funciones de manera remota como DCOM, CORBA o el tan masivo TCP/IP. Independientemente de cómo se haga la solicitud, las respuestas siempre son en XML, que describe perfectamente los datos en tiempo de ejecución y evita los problemas ocasionados por cambios inadvertidos en las funciones, ya que los objetos llamados tienen la posibilidad de validar siempre los argumentos de las funciones, haciendo que el protocolo sea muy sólido.
Así mismo, SOAP define un estándar llamado WSDL, que describe perfectamente los objetos y métodos disponibles a través de páginas XML accesibles por la Web. La idea es la siguiente: quien publica un servicio, crea también estas páginas. Quien quiera llamar el servicio, puede utilizar estas páginas como "documentación" de la llamada y también utilizarlas antes de llamar las funciones para verificar si cambió algo.
SEGURIDAD
Actualmente, los web services están siendo ampliamente aceptados por las empresas para el desarrollo de software de uso interno. De este modo, los servicios pueden implementar toda su funcionalidad y permanecer seguros tras el cortafuegos de la compañía.
Debido a la tecnología que es usada por los web services, y en concreto al uso de SOAP, cada mensaje simple que se intercambia realiza múltiples saltos y es rutado a través de numerosos puntos antes de que alcance su destino final. Es por ello que los web services necesitan tecnologías que protejan los mensajes desde el principio hasta el final, las que se encuentran disponibles a la hora de implementar este tipo de servicios.
Existen un conjunto de técnicas que se pueden usar para garantizar la seguridad a nivel de mensaje. Estas son:
Encriptación XML: Evita que los datos se vean expuestos a lo largo de su recorrido.
Firma Digital XML: Asocia los datos del mensaje al usuario que emite la firma, de modo que este usuario es el único que puede modificar dichos datos.
XKMS y los Certificados: XKMS (XML Key Management Specification) define web services que se pueden usar para chequear la confianza de un certificado de usuario.
SAML y la Autorización: SAML (Security Assertion Mark-up Language) hace posible que los web services intercambien información de autentificación y autorización entre ellos, de modo que un web service confíe en un usuario autentificado por otro web service.
Validación de datos: Permite que los web services reciban datos dentro de los rangos esperados.
Además, hay técnicas que permiten mantener la seguridad a otros niveles. La seguridad en UDDI permite autentificar todas las entidades que toman parte en la publicación de un web service: proveedor, agente y consumidor del servicio. De este modo, nadie podrá registrar servicios en el papel de un proveedor o hacer uso de ellos sin contar con los permisos adecuados.
CALIDAD
Actualmente ya existen en el mercado algunas herramientas específicamente diseñadas para medir la calidad de los web services, pero sigue siendo necesaria una estandarización sobre este tema. Los resultados sobre la calidad de diferentes web services, servirán como parámetro de comparación y ayudarán al consumidor a decantarse por un servicio u otro.
Para que SOAP se ejecute con corrección y satisfaga las expectativas creadas, aparte del precio, habrá que tener en cuenta una serie de parámetros como por ejemplo, que los resultados obtenidos del mismo sean los esperados o que el entorno de uso sea amigable. Otro elemento a tener en cuenta es la integración. Aunque teóricamente los web services proporcionan conectividad con cualquier software de un modo transparente, cada proveedor de servicios puede adoptar soluciones diferentes que resultan más o menos adecuadas para el consumidor. Analizando la escalabilidad se comprobará el grado de modularidad y flexibilidad del servicio.
ANATOMÍA DE UN MENSAJE SOAP
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 sobre puede contener un elemento Header opcional que tiene información sobre el mensaje y un elemento body, que contiene la carga de datos del mensaje. En el ejemplo, el cuerpo posee una simple cadena de caracteres. Éste 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 poner en serie tipos de datos que no están totalmente definidos.
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. Los parámetros de retorno se clasifican 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.
Por último, también sería interesante analizar las características que ofrece el proveedor de web services. Actualmente no hay definidos estándares sobre este tema, pero la mayoría de las empresas ya está demandando algún tipo de acuerdo o contrato con los proveedores, de modo que se pueda garantizar la calidad y la fiabilidad de los servicios por los que se paga.
ALGUNAS VENTAJAS
No esta asociado con ningún lenguaje:
Si bien tiene como parámetro XML, los desarrolladores involucrados en nuevos proyectos pueden elegir desarrollar con el último y mejor lenguaje de programación que exista, pero los desarrolladores responsables de mantener antiguas aflicciones heredadas, podrían no 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 cómo 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 algunos de ellos ya lo están para admitir 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 transporte de los mensajes; los mensajes de SOAP 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 dichos 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 un PC, puede comunicarse con una aplicación del back-end ejecutándose en un mainframe capaz de enviar y recibir XML sobre HTTP.
POSIBLES RIESGOS
Las expectativas alrededor de esta tecnología son grandes, porque el mercado de aplicación es muy amplio. Pero también tiene sus puntos oscuros.
En primer lugar, los web services hacen uso de las mismas tecnologías que han sido atacadas en tantas ocasiones. Usando este tipo de servicios, la seguridad de una empresa puede verse comprometida. La ausencia de técnicas de seguridad estándar, es un obstáculo para la adopción de la tecnología.
Por otro lado, la calidad de un web service es un parámetro que no queda claro, pero cuya medida es fundamental a la hora de desarrollar un servicio maduro.
Además, esta tecnología aún no consigue su etapa de maduración total de desarrollo y muchos de los protocolos en que se basa (incluso XML) aún no son estándar.
Como sea, todo indica que no falta mucho para que se adapte a nivel masivo, en la medida que las corporaciones requieren un soporte robusto en sus servicios y transacciones en línea, bajo un mundo cada vez más interconectado.
