Introduciendonos en el mundo del .NET (2º Parte)

Hoy definiremos un aspecto de vital importancia para el funcionamiento del .NET. El SOAP (Simple Object Access Protocol) es un protocolo estándar creado por Microsoft, IBM y otros, está actualmente bajo el auspicio de la W3C que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML.

SOAP es el protocolo de comunicaciones para los servicios XML Web Services. Cuando se describe SOAP como un protocolo de comunicaciones, muchas personas piensan en DCOM o CORBA y se preguntan "¿Cómo realiza SOAP la activación de objetos?" o "¿Qué servicio de nombres utiliza SOAP?" Mientras es posible que una implementación SOAP incluya estos datos, el estándar SOAP no los especifica. SOAP define el formato XML para mensajes. Si tiene un fragmento creado correctamente en XML e incluido en un par de elementos SOAP, dispondrá ya de un mensaje SOAP. Sencillo, ¿verdad? Existen otras partes en la especificación SOAP que describen cómo representar los datos de un programa como XML y cómo utilizar SOAP para realizar llamadas a procedimiento remoto (RPC). Estas partes opcionales de la especificación se utilizan para implementar aplicaciones estilo RPC en las que el cliente envía un mensaje SOAP que contiene una función a la que se puede llamar, además de los parámetros para pasar a la función. El servidor, por su parte, devuelve un mensaje con los resultados de la función ejecutada. Casi todas las implementaciones actuales de SOAP admiten aplicaciones RPC porque los programadores que trabajan con aplicaciones COM o CORBA conocen el estilo RPC. SOAP admite también aplicaciones con estilo de documento en las que los mensajes SOAP cubren un documento XML. Las aplicaciones SOAP con estilo de documento son muy flexibles. Muchos nuevos servicios XML Web Services aprovechan esta flexibilidad para diseñar servicios que sería difícil implementar mediante RPC. La última parte opcional de la especificación SOAP define los contenidos de un mensaje HTTP que contiene un mensaje SOAP. Este enlace HTTP es importante porque casi todos los sistemas operativos actuales, y otros no tan actuales, admiten HTTP. Este enlace es opcional pero casi todas las implementaciones SOAP lo admiten porque es el único protocolo estandarizado para SOAP. Por esta razón, existe la falsa idea general de que SOAP necesita HTTP. Algunas implementaciones admiten MSMQ, series MQ, SMTP o TCP/IP. Sin embargo, la mayoría de los servicios XML Web Services utilizan HTTP porque es ubicuo. Dado que HTTP es un protocolo imprescindible para el medio Web, muchas empresas disponen de infraestructuras de redes que lo admiten y personal con conocimientos y experiencia para gestionarlo. En la actualidad ya se encuentran disponibles la seguridad, el control y la infraestructura de equilibrio de cargas para HTTP. A la hora de empezar a trabajar con SOAP, es importante entender la diferencia entre la especificación SOAP y la variedad de implementaciones de esta especificación. Muchos programadores que utilizan SOAP no escriben mensajes SOAP directamente, sino que utilizan un SOAP Toolkit para crear y analizar mensajes SOAP. Generalmente, estos kits de herramientas traducen llamadas de función de algún tipo de lenguaje a un mensaje SOAP. Por ejemplo, Microsoft SOAP Toolkit 2.0 traduce llamadas de función COM a SOAP y el kit de herramientas de Apache traduce funciones de llamadas JAVA a SOAP. Los tipos de llamadas de función y los tipos de datos de los parámetros admitidos varían en cada implementación SOAP, de forma que es posible que una función que trabaja con un kit de herramientas no funcione con otro. Esto no es una limitación de SOAP, sino de la implementación específica que utilice en cada caso.La característica más notable de SOAP es que se ha implementado en diferentes plataformas de hardware y software, lo que significa que puede utilizarse para enlazar sistemas dispares dentro y fuera de su empresa. En el pasado se realizaron muchos intentos para conseguir un protocolo de comunicaciones común que pudiera usarse en la integración de sistemas. Sin embargo, ningún intento se ha generalizado tanto como SOAP. ¿Por qué? Porque SOAP es más pequeño y sencillo de implementar que muchos de los protocolos anteriores. Por ejemplo, se tardaron años en implementar DCE y CORBA, de modo que sólo unas pocas implementaciones llegaron a comercializarse. Por su parte, SOAP utiliza analizadores XML y bibliotecas HTTP existentes para realizar la mayor parte del trabajo más complicado; por ello, una implementación SOAP puede estar terminada en cuestión de meses. Ésta es la razón por la que hay disponibles más de 70 implementaciones SOAP. No obstante, SOAP no consigue los mismos resultados que DCE o CORBA pero su sencillez y características posibilitan que esté disponible rápidamente.La ubicuidad de HTTP y la sencillez de SOAP los convierte en una base perfecta para implementar servicios XML Web Services que pueden llamarse desde prácticamente cualquier entorno. Para obtener más información sobre SOAP, consulte la página principal de SOAP en MSDN.Aspectos sobre la seguridadUna de las primeras preguntas que se cuestiona un usuario nuevo es cómo protege SOAP la seguridad. En los primeros momentos de su desarrollo, SOAP era considerado como un protocolo basado en HTTP y, por tanto, se asumía que la seguridad de HTTP sería adecuada para SOAP. Además, existen miles de aplicaciones Web que se ejecutan actualmente utilizando la seguridad de HTTP. Por esta razón, el estándar SOAP actual supone que la seguridad es un problema de transporte y no comenta nada sobre los problemas de seguridad. La seguridad empezó a ser un problema en el momento en que SOAP se convirtió en un protocolo más generalizado que se ejecutaba en múltiples medios de transporte. Por ejemplo, HTTP proporciona diferentes modos de autenticar qué usuario realiza una llamada SOAP. Pero, ¿cómo se propaga esa identidad al dirigirse el mensaje desde HTTP a un transporte SMTP? SOAP se diseñó como un protocolo de base; afortunadamente existen especificaciones en los textos para diseñar en SOAP que proporcionan más características de seguridad para servicios Web. El artículo sobre la especificación WS-Security define sistemas de cifrado completos y el artículo WS-License define técnicas que protegen la identidad de la persona que llama y aseguran que sólo usuarios autorizados puedan utilizar un servicio Web.

Lo dejamos aca....saludos.

servido por Christian 4 comentarios compártelo