Hoy en día existe una tendencia muy marcada en las empresas por el desarrollo de aplicaciones que trabajen sobre Internet, principalmente por la ventaja de la distribución global de la información. Las tecnologías más usadas para el desarrollo de estas aplicaciones, han sido CORBA, COM y EJB. Cada una de estas tecnologías proporciona un marco de trabajo para la activación de objetos remotos, mediante la solicitud a un servidor de aplicaciones o mediante un servidor Web para la ejecución de servicios de aplicación. Estas tecnologías han probado ser efectivas para el establecimiento de sitios Web corporativos; sin embargo, presentan algunas desventajas como la falta de interoperabilidad, la dependencia a la arquitectura de trabajo, así como el lenguaje de programación.

Esto ha llevado a la industria a considerar un nuevo modelo de computación distribuida de objetos, sin tener la dependencia de plataformas, modelos de desarrollo y lenguajes de programación usados y como una medida de solución nace SOAP(Simple Object Access Protocol) que es una estrategia de desarrollo de aplicaciones distribuidas usando tecnologías diversas adoptada por las diferentes organizaciones del mundo para resolver los problemas de falta de interoperabilidad entre las tecnologías anteriormente mencionadas, tomando como base protocolos ya establecidos y con gran aceptación en Internet, como HTML y XML.

SOAP no es más que un protocolo estándar que permite la comunicación y la interoperabilidad entre diversas aplicaciones Web desarrolladas bajo tecnologías diferentes.

• Conocer la historia del protocolo SOAP
• Identificar a SOAP como un protocolo para promover la interoperabilidad entre aplicaciones Web.
• Comprender el funcionamiento de SOAP.
• Mostrar la utilidad de SOAP en las organizaciones
• Conocer las ventajas y desventajas que implican la utilización de SOAP.

La evolución tecnológica y búsqueda de soluciones a la computación distribuida no es un problema reciente, es por ello que desde el año 1980 se dieron los inicios en este tema aunque los protocolos de comunicación no era objeto de interés de los desarrolladores en ese momento; realizar aplicaciones que dentro de una misma máquina se comunicaran entre sí, era suficiente.

Posteriormente en el año de 1990 alcanzaron popularidad objetos como COM (Componet Object Model) introducido por Microsoft y CORBA (Common Object Request Broker Architecture) introducido por OMG (Object Management Group).

En general, COM y CORBA son modelos para escribir y encapsular código binario. Estos son componentes que pueden ser fácilmente llamados desde cualquier aplicación que soporte COM o CORBA. Sin embargo estos modelos no son fácilmente interoperables, de tal manera que COM puede solamente llamar a COM, y lo mismo ocurre con CORBA.

Conectar una maquina a otra se transformó en una prioridad cuando las redes locales se generalizaron, fue entonces que OMG estableció IIOP (Internet Inter-ORB Protocol) como el protocolo de comunicación para CORBA. Microsoft creo DCOM (Distributed COM), más tarde Sun Microsystems lanzo al mercado RMI (Remote Method Invocation).

Con estos protocolos se pueden llamar componentes que se encuentren en otras computadoras a través de la red. Estas llamadas se realizan bajo la forma de RPC (Remote Procedure Call). Es necesario aclarar que estos protocolos no son interoperables.

La solución está disponible para tener comunicación entre aplicaciones desde cualquier máquina a cualquier otra sin importar el sistema operativo, entorno de lenguajes, modelos de objetos distribuidos y usando los estándares de Internet.

Para resolver estas dificultades de interoperabilidad se desarrolló SOAP, el cual se dio a conocer en 1999 y fue un resultado de desarrolladores de Microsoft Corp., DevelopMentor Inc. y Userland Software Inc. SOAP 1.1 fue liberada el 8 de Mayo del 2000, por W3C, con la contribución de las siguientes empresas: Ariba Inc., Commerce One Inc., Compaq Computer Corp, Hewlett-Packard Co., IBM Corp., IONA Technologies PLC, Lotus Development Corp., y SAP AG.

Esto fue un buen signo de la industria para aceptar e implementar estándares basados en protocolo interoperables. Actualmente este protocolo esta siendo desarrollado por el XML Protocol Working Group de la W3C, en la versión 1.2.

2. SOAP

SOAP (Simple Object Access Protocol, Protocolo Simple de Acceso a Objetos) es un protocolo de mensajes entre computadores. SOAP especifica el formato de mensaje que accede e invoca a los objetos, mas que un objeto en particular.

La idea detrás de SOAP es la misma que RPC. También define un protocolo para llamadas a métodos remotos, sin embargo SOAP contiene:

• Información adicional incluida en el documento XML (lenguaje de marcado extensible), que describe el contenido y como podría ser procesada.
• Definición de la especificación de algunas estructuras en XML, tales como arrays.
• El modelo descentralizado, esto significa que puede ser procesado por varios intermediarios.
• Características especificas para operaciones clásicas de RPC con parámetros in/out, etc.

a) Establecer un protocolo estándar de invocación de servicios remotos, basado en protocolos estándares de Internet: HTTP (Protocolo de transporte de Hipertexto) para la transmisión y XML (lenguaje de marcado extensible) para la codificación de datos.

b) Independencia de plataforma, lenguaje de desarrollo e implementación (modelo de objetos).

El protocolo de comunicación HTTP es el empleado intrínsecamente para la conexión sobre Internet. Garantiza que cualquier cliente con un navegador estándar pueda conectarse con un servidor remoto. La transmisión de datos se empaqueta con XML, que se ha convertido en el estándar del intercambio de datos, salvando las incompatibilidades entre otros protocolos, tales como el NDR (Network Data Representation) o el CDR (Common Data Representation).

Por otra parte, los servidores Web pueden procesar las peticiones de usuario, empleando las tecnologías de Servlets, paginas ASP (Active Server Pages) o JSP (Java Server Pages), o un servidor de aplicaciones, invocando objetos de tipos CORBA, COM o EJB.

Como SOAP circunscribe información adicional incluida en el documento XML a continuación se presentará la descripción de dicho documento.

XML esta interesado en describir el contenido de los documentos que están almacenados en un formato electrónico, de forma tal que sea legible y comprensible tanto para las personas como para el software, un archivo en formato XML contiene una mezcla del documento y etiquetas XML, las cuales organizan y definen los componentes del documento.

La clase más simple de documento es un archivo de texto, el archivo es considerado como un flujo de datos, una secuencia lineal de caracteres las cuales son leídas y procesadas por el software en un estricto orden.

En un sistema tradicional, las etiquetas son consideradas como instrucciones que son interpretadas, por ejemplo, para ejecutar cambios en el estilo del tipo de fuente que pueden significar un salto de línea, pero que no deberán aparecer ni estar presentes en el texto.

Un documento basado en XML esta formado de dos piezas esencialmente, una estructura lógica y una estructura física, la estructura lógica le permite a un documento dividirse en unidades y sub-unidades llamadas elementos. La estructura física contiene los componentes del documento, llamadas entidades, algunas veces almacenadas separadamente en otros archivos, así que la información puede ser reutilizada, también pueden incluirse por referencia datos que no tiene un formato XML como son las imágenes.

La estructura de un documento XML se puede definir a partir de dos estándares. El primero es la especificación de XML, que define las reglas predeterminadas para la construcción de todos los documentos XML, cualquier documento que se ajuste a las reglas básicas definidas en la especificación se denominan documentos XML bien formados debido a que XML actualmente es un meta-lenguaje (un lenguaje que describe a otros lenguajes), ya que no hay una lista predefinida de elementos, el usuario puede llamar usar sus elementos como desee, sin embargo, el segundo estándar (que es opcional), lo crean los autores del documento y se especifica en una definición de tipo de documento DTD (Document Type Definition), que explica cuales elementos son permitidos en un documento en particular.

XML tiene un alto grado de control sobre la estructura lógica del documento, cada documento puede ser comparado con las reglas de su DTD lo que determina si es valido, cuando el documento XML se ajusta a las reglas definidas en la DTD, se denomina documento XML valido. Los esquemas son similares a los DTD, pero utilizan un formato diferente, los DTD y los esquemas resultan bastante útiles cuando el contenido de un grupo de documentos comparten un conjunto de reglas común y deben ser analizados para determinar su valides.

Un documento XML contiene instrucciones especiales llamadas tags, las cuales usualmente encierran las partes identificables de un documento. SOAP define 3 formas distintas de expresar los tipos de datos de un tag:

• Utilizar el atributo ‘xsi: type’ en cada tag, explícitamente referenciando el tipo de datos de acuerdo con la especificación del esquema XML.
• Referenciar un esquema XML que defina particularmente ese tipo de datos exacto.
• Referenciar otro esquema que defina el tipo de datos de un tipo de elemento dentro del cual se declara.

Las etiquetas XML no directamente especifican el estilo de presentación, pero en lugar de esto dan nombre a los objetos, estas usualmente ordenan e identifican un objeto en un flujo de datos. Una etiqueta de inicio, una etiqueta de fin, junto con los datos encerrados por estos, componen un elemento; el tag de inicio es delimitado usando los caracteres ‘<’ y ‘>’, el tag de fin es delimitado por los caracteres ‘</’ y ‘>’:

Adicionalmente un elemento XML puede contener elementos embebidos, y todo un documento debe estar encerrado por un solo elemento documento, la estructura jerárquica de un documento puede ser visualizada como una caja dentro de cajas ó como una estructura en árbol.

Los nombres de los elementos son sensibles a minúsculas y mayúsculas, de esta forma ‘descripción’, ‘DESCRIPCION’ y ‘Descripción’, pueden hacer referencia a elementos diferentes, el nombre que aparece en el tag de inicio debe ser exactamente igual con el nombre del tag de finalización para los elementos.

Cada elemento debe estar completamente encerrado por otro elemento, (cualquier documento XML que se componga apropiadamente, es decir que sus elementos estén adecuadamente anidados uno dentro del otro, es determinado un documento XML bien formado), excepto por el elemento padre de todos los elementos (root ó raíz del documento).

Algunas estructuras jerárquicas pueden ser recursivas. Un elemento puede directamente o indirectamente contener instancias de si mismo. En una estructura anidada no hay un limite establecido para el nivel de anidación en los elementos.

Los símbolos ‘<’ y ‘>’ son caracteres que tienen el rol de delimitadores de las marcas para los tags XML, estos no pueden aparecer como datos o caracteres a causa de la ambigüedad y confusión que pueden causar. Por lo tanto será necesario usar una forma de códigos de escape en lugar de estos caracteres, ‘&lt;’ representa al tag de inicio ‘<’ y ‘&gt;’ representa a el tag de fin ‘>’

Es posible para un elemento el contener información acerca de su contenido además de su nombre. Por ejemplo, se desea saber el uso para el cual está destinado determinado equipo de computo, si es un servidor ó un PC de escritorio, esta información es llamada meta-dato, y está almacenada en los atributos, los atributos son un mecanismo para agregar información descriptiva a un elemento, un solo elemento puede contener uno o más atributos.

Para cada atributo es necesario tener una dupla, nombre y valor.

Cuando no se usa un DTD, el valor es simplemente considerado como una unidad de texto, no se hace ninguna distinción entre valores numéricos y caracteres, pero cuando es utilizado un DTD se puede ejercer mayor control sobre el rango de valores permitidos para cada atributo. Un atributo es asociado con un elemento en particular por el DTD, y le es asignado un atributo de tipo ‘character data’ que puede contener valores que consisten de caracteres generales, un atributo de tipo ‘name token’, puede contener solo una palabra simple, no son permitidos los espacios en blanco, los valores de los atributos pueden restringirse desde una palabra a un grupo de palabras en una enumeración, el DTD también puede especificarnos un valor por defecto.

A continuación se muestra un esquema del funcionamiento de SOAP

La especificación SOAP menciona que las aplicaciones deben ser independientes del lenguaje de desarrollo, por lo que las aplicaciones cliente y servidor pueden estar escritas con HTML, DHTML, Java, Visual Basic u otras herramientas y lenguajes disponibles. Lo importante es tener alguna implementación de SOAP (dependiendo de la herramienta de desarrollo elegida) y enlazar sus librerías con la aplicación. Aunque esto no es estrictamente necesario, es preferible trabajar usando dichas librerías, con el fin de no reescribir un código ya probado.

Las peticiones con el uso del protocolo HTTP emplean el comando POST para transmitir información entre el cliente y el servidor.

Estos mensajes constan de 3 secciones: envelope, header y body.

Donde:

• Los mensajes SOAP son transmisiones unidireccionales desde un emisor a un receptor.
• Se suelen combinar mensajes para implementar patrones, como petición/respuesta.
• Las implementaciones SOAP se pueden optimizar para explotar las características específicas de sistemas de red concretos.

Una aplicación SOAP debe procesar un mensaje siguiendo un orden de acciones:

1. Identificar las partes del mensaje SOAP dirigido a dicha aplicación.
2. Aceptar las partes obligatorias identificadas en el paso 1 y procesarlas de la forma adecuada. De lo contrario, descartar el mensaje.
3. Si la aplicación SOAP no es el destino final del mensaje, quitar todas las partes identificadas en el paso 1 antes de reenviar el mensaje.

También hay que tener en cuenta que este protocolo es extensible.

SOAP puede ser extendido realizando adiciones de módulos de funcionalidad. Este enfoque permite a los desarrolladores usar los módulos y funcionalidad que ellos necesitan, sin tener la necesidad de implementar la totalidad de estos.

Algunas de las extensiones que pueden ser deseables en los proveedores son las siguientes:

Attachments – La posibilidad de incluir un documento no XML, archivo binario ó de enviar documentos de fax, imágenes de medicina, dibujos de ingeniería, o cualquier otro tipo de imágenes, codificadas en Base64.

Routing/Intermediaries – Relacionadas al proceso de rutear mensajes SOAP a través de intermediarios. Esto ofrece la posibilidad de agregar varios Web Services (WS) y ofrecerlos como parte del paquete, es una manera de hacer a los WS escalables, a través del direccionamiento, incluso hacia múltiples servidores

Security – Dar un marco de seguridad a la comunicación. Algunos de los aspectos podrían ser aplicar SSL, firma digital, etc. XML referent nos ayuda a responder: quien envía el mensaje y si el mensaje fue alterado en la ruta.

Quality of Services – QoS es una medida que puede ser comparada con el número o calificación dada a los ASP o ISP, que mide la calidad del servicio, un concepto similar puede manejarse para los Web Services.

Context/Privacy – Hace referencia a guardar el contexto y privacidad, del entorno de los usuarios. (Platform for Privacy and �referentes (P3P)).

Transaction Support – Permitir que un grupo de operaciones o acciones se comporten como si fueran una simple unidad (o todo falla o todo es un éxito).

Message Syntax – el formato tiene un área separada para extensiones que sean adicionadas.

Data – SOAP puede contener cualquier tipo de datos. Provee un método para serialización de datos, pero las aplicaciones pueden definir sus propias reglas.

Transport – No define como son transportados los mensajes durante el intercambio. SOAP muestra como podrían ser intercambiados sobre http, pero cualquier protocolo o método puede sustituir a http.

Purpose – SOAP no define que es lo que hay dentro del mensaje. Hay una diferencia entre los datos y su propósito o finalidad.

Entre las ventajas de SOAP se tiene que:

• Es sencillo de implementar, probar y usar
• Atraviesa "firewalls" y routers, pues estos "piensan" que es una comunicación HTTP.
• Tanto los datos como las funciones se describen en XML, lo que permite que el protocolo no sólo sea más fácil de utilizar sino que también sea muy sólido.
• Es independiente del sistema operativo y procesador.
• Se puede utilizar tanto de forma anónima como con autenticación (nombre/clave).
• Facilidad para utilizar cualquier lenguaje: Los desarrolladores involucrados en nuevos proyectos pueden elegir desarrollar con el último y mejor lenguaje de programación que exista. 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 alguno de ellos admiten SOAP.
• Aprovecha los estándares existentes en la industria: Los principales contribuyentes a la especificación SOAP evitaron, intencionalmente, 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 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.

Entre las desventajas de SOAP se tiene que:

• Las desventajas de la utilización de SOAP recaen en la dificultad para entender las especificaciones del protocolo, puesto que es un complejo esquema de codificación en el cual es necesario precisar que todos los mensajes se incluyan en un sobre, con el contenido del mensaje dentro de un elemento de cuerpo para que puedan ser entendidos por cada una de las aplicaciones Web que procesan el mensaje.
• SOAP convierte en opcionales elementos como encabezados y ofrece un amplio margen con respecto a lo que se puede incluir en el elemento de cuerpo y además cambia los nombres de métodos en etiquetas secundarias del cuerpo y los argumentos en etiquetas secundarias del nombre del método, lo que puede generar ciertos problemas de interoperabilidad.
• Las especificaciones SOAP indican que si recibe un encabezado SOAP con un atributo mustUnderstand establecido como "1", deberá entenderlo o generar un error. Numerosas implementaciones no lo hicieron al principio lo que implicó problemas de interoperabilidad.

Actualmente, los WS están siendo ampliamente aceptados por las empresas para el desarrollo de software de uso interno. Debido a la tecnología que es usada por los WS, y en concreto al uso de SOAP, que permite la cooperación y la interoperabilidad entre empresas que estén desarrollando proyectos en común y en las cuales no estén trabajando sobre la misma plataforma, lenguaje de programación o hardware compatibles.

Para realización de dichos proyectos hay que tener en cuenta los siguientes aspectos:

Los servicios pueden implementar toda su funcionalidad y permanecer seguros tras el Cortafuegos de la compañía. Las técnicas de seguridad convencionales que se han venido usando en Internet, ya no son suficientes. Con 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 WS necesitan tecnologías que protejan los mensajes desde el principio hasta el final y así permitir que SOAP realice su trabajo de interoperabilidad entre aplicaciones de manera eficiente.

Para ello 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 WS 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 WS intercambien información de autentificación y autorización entre ellos, de modo que un WS confíe en un usuario autentificado por otro WS.
• Validación de datos: Permite que los WS reciban datos dentro de los rangos esperados.

Los WS proporcionan conectividad con cualquier software de un modo transparente por el paso de mensaje SOAP, 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.

Por último, también sería interesante analizar las características que ofrece el proveedor de WS. Actualmente no hay estándares definidos 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 interoperabilidad entre las diferentes tecnologías, la calidad y la fiabilidad de los servicios por los que se paga.

Los WS están basados en el estándar XML, que ha sido universalmente aceptado. SOAP es el único protocolo que ha sido aceptado en este momento por el World Wide Web Consortium y se encuentra estandarizado. SOAP y WSDL están siendo ampliamente usados.

Algunas de las empresas más importantes en el desarrollo de Negocio Electrónico como IBM, Intel, Microsoft u Oracle, han creado el WS-I: organización para la Interoperabilidad de los Web Services. El objetivo de dicha organización es la promoción de la estandarización de los WS de modo que se fomente la cooperación e interoperabilidad entre las compañías y mercados utilizando este protocolo.

Las principales compañías del mundo han empezado a desarrollar soluciones mediante la tecnología de los WS bajo el paso de mensajes SOAP. Algunos ejemplos son:

• Microsoft: Recientemente ha anunciado la disponibilidad de su primer WS, llamado MapPoint.Net. mediante este servicio, el usuario podrá conocer su localización exacta y otros datos adicionales relacionados con su posición actual, como información de tráfico, rutas posibles o puntos comerciales cercanos.
• IBM: Ha implementado una solución basada en los WS llamada e-Business on Demand. Esta solución permite la construcción de Extranets que ayuden a las empresas a ver los catálogos de productos, realizar y localizar pedidos o chequear el estado del inventario en tiempo real.
• Líneas Aéreas Escandinavas: Estas líneas aéreas han desarrollado un WS que permite a los usuarios comprar tiquetes y chequear el estado de los vuelos, mediante el uso del teléfono móvil.

• La primera versión de SOAP (Protocolo simple de acceso a objetos), se dio a conocer en 1999 y fue desarrollada por Microsoft Corp., DevelopMentor Inc. y Userland Software Inc. SOAP 1.1 fue liberada el 8 de Mayo del 2000 hasta llegar hoy en día a versiones adaptadas a paquetes tales como SOAP: Lite for Perl, Apache SOAP Ver. 2.2, Apache Axis, etc.
• Es un protocolo de mensajes entre computadoras. SOAP especifica el formato de mensaje que accede e invoca a los objetos, mas que un objeto en particular y permite solucionar los problemas de las tecnologías que desarrollan aplicaciones que trabajen sobre Internet (CORBA, COM, EJB entre otras), estos problemas son la falta de interoperabilidad, la dependencia a la arquitectura de trabajo, así como al lenguaje de programación.
• SOAP es un protocolo ligero para el intercambio de información en un entorno distribuido y descentralizado. Esta basado en el protocolo XML y consiste en tres partes: una envoltura que define una estructura para describir que contiene el mensaje y como procesarlo, un conjunto de reglas de codificación para expresar instancias de tipos de datos definidos para la aplicación y un convenio para representar las llamadas a procedimientos remotos y las respuestas.
• Web Services y SOAP hoy en día están siendo altamente utilizados en las grandes empresas del mundo pues le permiten a estas la cooperación e integridad entre ellas cuando trabajan en un proyecto en común, debido a que permite la interoperabilidad entre sus tecnologías.

http://www.revista.unam.mx/vol.3/num1/art3

http://www.microsoft.com/spanish/msdn/articulos/archivo/280901/voices/soapinteropbkgnd.asp

http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art51.asp

http://www.desarrolloweb.com/articulos/1557.php?manual=54

http://es.wikipedia.org/wiki/SOAP

INGENIERO DE SISTEMAS

CORPORACIÓN UNIVERSITARIA DEL CARIBE CECAR

FACULTAD DE INGENIERÍAS

PROGRAMA DE INGENIERÍA DE SISTEMAS

SISTEMAS DISTRIBUIDOS

SINCELEJO

2005