S.O.A.P.

Ing. Sandro Moscatelli

21/08/01 In.Co.

Interconexin de aplicaciones legadas usando el paradigma de mensajes

Indice
1 SOAP..........................................................................................................................................................3 1.1 INTRODUCCIN...................................................................................................................................3 1.2 QU ES SOAP....................................................................................................................................3 1.3 MENSAJES DE SOAP..........................................................................................................................4 1.4 ARQUITECTURA BSICA DE SOAP.....................................................................................................5 1.5 PORQUE SOAP...................................................................................................................................5 1.6 PROTOCOLO SOAP.............................................................................................................................6 1.6.1 Mensaje SOAP .............................................................................................................................6 1.6.2 Reglas codificacin (Encoding Rules)........................................................................................10 1.6.3 SOAP RPC..................................................................................................................................10 1.7 ARQUITECTURA................................................................................................................................12 1.7.1 Funcionamiento genrico de RPC en SOAP..............................................................................12 1.8 VENTAJAS.........................................................................................................................................14 1.9 DESVENTAJAS...................................................................................................................................16 1.10 SOAP Y LAS TECNOLOGAS DISTRIBUIDAS....................................................................................17 2 ANEXO - APACHE SOAP....................................................................................................................19 2.1 INSTALACIN....................................................................................................................................20 2.2 XERCES ............................................................................................................................................21

Interconexin de aplicaciones legadas usando el paradigma de mensajes

1 SOAP
1.1 Introduccin
Simple Object Access Protocol (SOAP) surge a partir de la especificacin realizada por Dave Winer, de la empresa UserLand Software a finales del ao 1998, de un mecanismo basado en XML para realizar invocaciones RPC. A partir de dicha especificacin y de la unin de las empresas DevelopMentor, UserLand Software y Microsoft surge pblicamente la versin 0.9 de SOAP en setiembre de 1999. La versin 1.0 fue lanzada casi a continuacin de la versin 0.9 (diciembre de 1999) y enviada a la IETF (Internet Engineering Task Force). Este organismo hizo de esta versin una recomendacin oficial. Posteriormente se realiz la versin 1.1 de SOAP, donde, adems de las empresas mencionadas, tambin participaron Lotus e IBM, entre muchas otras empresas de desarrollo de software. Esta nueva versin fue enviada al W3C (World Wide Web Consortium) en mayo del 2000, con el propsito de formar un grupo de trabajo en el rea de los protocolos basados en XML. En julio de 2000 el grupo de trabajo en el rea de XML del W3C edita el primer W3C Working Draft de la versin 1.2 de SOAP. La especificacin del protocolo SOAP, bsicamente, describe un formato de mensajes para comunicar aplicaciones. La filosofa de SOAP, para lograr dicha comunicacin, es no inventar una nueva tecnologa, sino combinar tecnologas existentes y de amplia aceptacin en la industria de software. En particular, combina XML para la codificacin de los mensajes y HTTP como protocolo de transporte (aunque no se excluye el uso de otros protocolos de tranporte).

1.2 Qu es SOAP
SOAP define un mecanismo simple y liviano (en contraposicin a sofisticado) para la comunicacin, en un entorno distribuido o descentralizado, entre componentes de software o aplicaciones. La comunicacin se realiza mediante mensajes codificados en XML y transportados por un protocolo de transporte (SOAP no mandata el uso de un protocolo de transporte en particular, aunque si define como es el transporte en caso de usar HTTP). En definitiva SOAP define un mecanismo para el intercambio de informacin, estructurada y tipeada, entre pares de aplicaciones en un entorno distribuido, teniendo como objetivos de diseo la simplicidad y la extensibilidad. SOAP no define por s mismo la semntica de las aplicaciones, como ser un modelo de programacin o algn tipo de semntica especfica de una implementacin, sino que provee un mecanismo simple para expresar la semntica de las aplicaciones, mediante un modelo modular de empaquetado de mensajes y la definicin de como codificar los datos de las aplicaciones en dichos mdulos, es posible ver a SOAP desde distintos puntos de vista: 1. Como un mecanismo para invocar mtodos en servidores, servicios, o componentes, para lo cual se define en la especificacin una metodologa para encapsular e intercambiar invocaciones RPC, en los mensajes, usando la extensibilidad y flexibilidad que proporciona XML. 2. Como un protocolo para intercambio de mensajes (sincrnicos o asincronicos). 3. Como un formato para intercambio de documentos XML.

Interconexin de aplicaciones legadas usando el paradigma de mensajes

1.3 Mensajes de SOAP

La especificacin de SOAP define el formato de los mensajes para comunicar aplicaciones, normalmente dichos mensajes son una forma de comunicacin de una nica va entre un emisor y un receptor (mensajes asincrnicos), sin embargo pueden ser combinados de manera de implementar patterns de requerimiento/respuesta (mensajes sincrnicos). En la versin 1.0 de la especificacin de SOAP se estableca como mandatorio el uso de HTTP como protocolo de transporte, sin embargo a partir de la versin 1.1 se desacopla SOAP del uso de HTTP, lo cual permite una mayor variedad de protocolos de tranporte como ser FTP, SMTP, etc. En definitiva la especificacin no establece un protocolo de transporte particular pero si especifica como se realiza el transporte en caso de usar HTTP. El implementar patterns requerimiento/respuesta es sumamente natural si se utiliza HTTP como protocolo de transporte dado que en este caso los mensajes SOAP siguen el modelo requerimiento/respuesta de los mensajes HTTP, enviando el requerimiento en un request HTTP y la respuesta SOAP en un HTTP response. Adems de lo anterior, el hecho de usar HTTP tiene las siguientes ventajas: Es el protocolo estndar para la comunicacin en Internet. Est disponible para todas las plataformas. Requiere muy poco soporte en tiempo de ejecucin para funcionar adecuadamente. La seguridad de HTTP es simple y efectiva. Es un protocolo que permite atravesar firewalls. No es un protocolo orientado a la conexin (para establecer o manener una sesin se deben intercambiar pocos o ningn paquete)

La especificacon de SOAP establece que los mensajes sean codificados en XML. El uso de XML tiene la siguientes ventajas: XML es un protocolo para representar datos independientemente de plataformas y lenguajes Se est transformando rpidamente en un estndar al ser ampliamente aceptado por la industria de sofware. Est disponible en todas las plataformas. Es adecuado para manipular datos estructurados y tipeados Es fcil de analizar (parsing) y entender (tanto para mquinas como por personas) por ser texto.

Interconexin de aplicaciones legadas usando el paradigma de mensajes

1.4 Arquitectura bsica de SOAP

Desde el punto de vista de la presente tesis interesa usar SOAP para comunicar aplicaciones, realizando invocaciones RPC e implementando el pattern requerimiento/respuesta, por lo cual el comportamiento es similar al de una arquitectura cliente servidor, donde el proceso es iniciado por el cliente y el servidor responde al requerimiento del mismo. Este tipo de comunicacin se basa en un sistema de mensajes SOAP sincrnicos, codificados en XML que son transportados por HTTP.

En la figura se observa la arquitectura bsica de un sistema, anlogo al descripto, construdo sobre SOAP y los mensajes que definen la interaccin entre la aplicacin cliente y la aplicacin servidor. Generalmente la aplicacin cliente enva un mensaje (REQUEST va HTTP), el cual al ser recibido por la aplicacin servidor genera una respuesta (RESPONSE) que es enviada a la aplicacin cliente va HTTP. Se observa adems que en el caso de usar SOAP para realizar RPC, la invocacin RPC se mapea naturalmente al REQUEST de HTTP y la respuesta RPC se mapea al RESPOSE de HTTP.

1.5 Porque SOAP

Puede pensarse en cul es la necesidad de un protocolo de las caractersticas de SOAP, si actualmente existen tecnologas de procesamiento distribuido que funcionan correctamente y ampliamente difundidas como ser DCOM o CORBA, por mencionar solamente a dos de las ms conocidas, cada una de las cuales provee su propio protocolo de comunicacin. Fundamentalmente si se piensa en la evolucin de los sistemas distribuidos hacia los WEB Services, en donde las aplicaciones distribuidas son accesibles a otros sistemas (escritos y funcionando en otra plataforma), puede verse que las distintas tecnologas de procesamiento distribuido existentes presentan una serie de limitaciones debido a: son dependientes de la plataforma y de fabricantes . DCOM est ligado a Windows NT y CORBA, a pesar de ser una arquitectura abierta, est controlado por determinados vendedores. Por lo tanto hacer que los sistemas distribuidos, construidos usando DCOM o CORBA, sean accesibles a otros sistemas heterogneos (escritos o funcionando en otra plataforma) es un problema bastante serio, a menos que ambas partes tengan la misma plataforma y sistemas similares, lo cual implica que las aplicaciones tengan un alto acoplamiento. presentan problemas con los firewalls . Tanto DCOM como CORBA asignan puertos en forma dinmica, lo cual dificulta su uso en internet, donde los firewalls corporativos bloquean normalmente el acceso, a no ser por puertos especficos (por ejemplo puerto HTTP). hacen uso de protocolos sofisticados. Esto implica la instalacin de grandes y complejas libreras del lado del cliente, adems de implicar que el proceso de desarrollo de los clientes DCOM y CORBA es complejo. Esto contradice la idea de los

Interconexin de aplicaciones legadas usando el paradigma de mensajes

WEB services cuya idea base es publicar servicios para que sea accesibles a otras aplicaciones. Adems requeieren un gran soporte en tiempo de ejecucin para funcionar adecuadamente. Ambas tecnologas utilizan formatos propietarios de representacin de los datos . DCOM utiliza un formato llamado Network Data Representation (NDR) y CORBA utiliza un esquema similar pero incompatible llamado Common Data Representation (CDR). Adems dichos formatos son binarios y muy ligados a la arquitectura de los modelos de componentes respectivos. En definitiva en el entorno de sistemas distribuidos funcionando sobre internet, las tecnologas existentes presentan serias limitaciones debido a la heterogeneidad del entorno, la presencia de firewalls y al uso de formatos propietarios para representar datos. Bajo estas condiciones SOAP es una alternativa sumamente til para comunicar aplicaciones heterogneas (interoperabilidad), fundamentalmente por el uso de XML que es un estndard basado en texto e independiente de plataformas y lenguajes y por el uso de HTTP como transporte, el cual normalmente atraviesa los firewalls dado que estos no bloquean el puerto HTTP. Adems al no ser un protocolo sofisticado y al no definir modelos de programacin permite que las aplicaciones tengan un bajo acoplamiento, lo cual es ideal en el entorno de internet. De todas maneras puede verse que SOAP no es una tecnologa que reemplace a las existentes sino una tecnologa que permite la interoperabilidad de aplicaciones heterogneas.

1.6 Protocolo SOAP

La especificacin del protocolo SOAP indica que el mismo consiste de 3 partes: El constructor SOAP ENVELOPE que define un framework para expresar qu hay en un mensaje, a quin est dirigido el mensaje y cuando es opcional o mandatorio. Las reglas de codificacin que definen un mecanismo de serializacin para ser usado para intercambiar instancias de tipos de datos. La representacin SOAP RPC que define una metodologa que puede ser usada para representar invocaciones a procedimientos remotos y sus respuestas.

Se describen a continuacin las 3 partes del protocolo SOAP

1.6.1 Mensaje SOAP

Tanto los mensajes REQUEST como RESPONSE consisten en mensajes HTTP, pero es de hacer notar que en caso de usar cualquier otro protocolo de transporte no cambia el contenido del mensaje, el cual est codificado en XML. La parte XML de los mensajes tiene la estructura que se muestra en la siguiente figura:

Interconexin de aplicaciones legadas usando el paradigma de mensajes

Los mensajes SOAP estn codificados en XML y consisten de una seccin denominada ENVELOPE (obligatoria), la cual est compuesta de una seccin denominada HEADER (opcional) y de una seccin denominada BODY (obligatoria). Cada una de estas secciones se explican a continuacin.

1.6.1.1 SOAP Envelope

Esta construccin sintctica de nombre ENVELOPE contiene el resto del documento XML y debe estar presente siempre y ser primer seccin del mensaje. Define los distintos NAMESPACES que son usados en el resto del mensaje <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> </SOAP-ENV:Envelope> Los NAMESPACES se utilizan para garantizar la unicidad de los elementos y evitar ambiguedades.

1.6.1.2 SOAP Header

Esta construccin sintctica de nombre HEADER es opcional y es un mecanismo genrico para extender las caractersticas de los mensajes SOAP de una manera descentralizada y sin un acuerdo previo entre las partes que se comunican. En caso de estar presente debe ser el primer hijo de la construccin ENVELOPE. A modo de ejemplo algunas extensiones que pueden ser implementadas mediante esta construccin son transportar informacin auxiliar para la autenticacin, manejo de transacciones, etc. <SOAP-ENV:Header> <User Information> </SOAP-ENV:Header> <SOAP-ENV:Header> <Transaction Information> </SOAP-ENV:Header>

1.6.1.3 SOAP Body

Es una construccin sintctica de nombre BODY que acta como contenedor para la informacin que se enva al receptor del mensaje. Esta construccin debe estar presente siempre en los mensajes SOAP y debe estar a continucin del HEADER, si est presente, o ser el primer hijo de ENVELPE si el HEADER no est presente. Los usos tpicos de esta construccin son proveer un mecanismo simple de intercambiar informacin con el receptor del mensaje SOAP. En esta parte del mensaje es donde se encuentran las invocaciones RPC o bien el resultado de la invocacin. <SOAP-ENV:Body> <m1:RemoteMethodName xmlns:m1="some URI"> <arg1>value1</arg1> <arg2>value2</arg2> </m1:RemoteMethodName> <m2:RemoteMethodName xmlns:m2="some URI"> <arg1>value1</arg1> </m2:RemoteMethodName> </SOAP-ENV:Body>

Interconexin de aplicaciones legadas usando el paradigma de mensajes

1.6.1.4 Mensajes
Cada una de las construcciones sintcticas HEADER y BODY pueden ser organizadas en bloques, es decir unidades sintcticas usadas para delimitar informacin que lgicamente constituye una unidad computacional para un emisor o receptor. La siguiente figura muestra lo explicado anteriormente:
<SOAP-ENV:Envelope

SOAP Envelope
SOAP Header
(optional) Header1

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

<SOAP-ENV:Header> <User Information> </SOAP-ENV:Header>

Header2

<SOAP-ENV:Header> <Transaction Information> </SOAP-ENV:Header>

SOAP Body
Remote Method 1 signature

<SOAP-ENV:Body>

<m1:RemoteMethodName1 <arg1>value1</arg1> <arg2>value2</arg2> </m1:RemoteMethodName>

xmlns:m1="some URI">

Remote Method 2 signature

<m2:RemoteMethodName2 xmlns:m2="some URI"> <arg1>value1</arg1> </m2:RemoteMethodName> </SOAP-ENV:Body> </SOAP:Envelope>

Interconexin de aplicaciones legadas usando el paradigma de mensajes

1.6.1.5 SOAP y HTTP

Como se mencion los mensajes SOAP son transportados generalmente por HTTP. En este caso pueden usarse distintos mtodos para el REQUEST pero el ms comn es el POST. Por lo tanto un mensaje SOAP consiste en un HEADER HTTP que se encuentra antes del mensaje SOAP, este HEADER HTTP difiere poco de un cabezal HTTP tpico como se detalla a continuacin: En la primer lnea se especifica el mtodo de envo, la URI requerida y la versin del protocolo usada: POST /ProductCatalog HTTP/1.1 En la siguiente lnea se especfica el destino: HOST: www.mywebsite.com Las siguientes 3 lneas son usadas para definir el formato MIME para desplegar el mensaje, la codificacin HTTP y el largo del mensaje: Content-Type: text/xml; charset="utf-8" Content-Length: nn A continuacin se agregan cabezales SOAPACTION, esta parte del HEADER HTTP es la que difiere de otros cabezales tpicos HTTP, que indican la intencin del mensaje y son usados en el REQUEST. En particular una posibilidad es indicar el mtodo a ser invocado y el valor es una URI identificando el mtodo (formada por el nombre del mtodo precedida por la URI del HOST y usando el carcter # como separador) SOAPAction:"http://www.mywebsite.com#NombreMetodo

Otros posibles valores para el cabezal SOAPACTION son el string vaco () que indica que se intenta acceder a la URI especificada en la primer lnea o bien sin valor que indica que no se tiene informacin sobre la intencin del mensaje SOAPAction: SOAPAction: Nota: 1- Los firewalls y otros filtros de seguridad pueden usar este campo (SOAPACTION) para conocer el requerimiento que llega sin necesidad de parsear el mensaje 2- El identificador que sigue al caracter # debe machear con los nombres de las tags en el BODY

Interconexin de aplicaciones legadas usando el paradigma de mensajes

A continuacin se presenta el mensaje SOAP completo: POST /ProductCatalog HTTP/1.1 HOST: www.mywebsite.com Content-Type: text/xml; charset="utf-8" Content-Length: nn SOAPAction:http://www.mywebsite.com#RemoteMethodName1 SOAPAction:http://www.mywebsite.com#RemoteMethodName2 <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Header> <User Information> </SOAP-ENV:Header> <SOAP-ENV:Header> <Transaction Information> </SOAP-ENV:Header> <SOAP-ENV:Body> <m1:RemoteMethodName xmlns:m1="http://www.mywebsite.com#"> <arg1>value1</arg1> <arg2>value2</arg2> </m1:RemoteMethodName> <m2:RemoteMethodName xmlns:m2="http://www.mywebsite.com#"> <arg1>value1</arg1> </m2:RemoteMethodName> </SOAP-ENV:Body> </SOAP:Envelope>

1.6.2 Reglas codificacin (Encoding Rules)

1.6.3 SOAP RPC

Uno de los aspectos fundamentales de SOAP definir una metodologa para encapsular e intercambiar invocaciones RPC usando la extensibilidad y flexibilidad que proporciona XML. El uso de SOAP para realizar RPC es ortogonal al protocolo usado para el transporte del mensaje SOAP. En el caso de usar HTTP, la invocacin RPC se mapea directamente al request de HTTP y la respuesta RPC se mapea al response de HTTP. Para realizar una invocacin RPC es necesaria la siguiente informacin: La ubicacin del objeto remoto El nombre del objeto remoto El nombre del mtodo Los parmetros del mtodo

Tanto las invocaciones RPC como las respuestas son transportadas en el elemento BODY del mensaje SOAP y son modeladas como structs. Es posible usar el cabezal SOAPACTION para especificar el nombre del objeto remoto y su ubicacin.

10

Interconexin de aplicaciones legadas usando el paradigma de mensajes

En el caso de un request, la tag inicial de cada entrada en el elemento BODY es usada para especificar el nombre del mtodo (<NombreMetodo>) y los elementos hijos de esta tag son usados para especificar los parmetros de entrada y/o entrada/salida del mtodo, en el mismo orden que en la signatura del mtodo remoto. A continuacin se muestra un ejemplo de un request SOAP

<SOAP-ENV:Body> <m:addProduct xmlns:m="MY_XML_SCHEMA/IProductCatalog"> <name>Sony TV</name> <desc>17 inch color TV</desc> <price>255.99</price> <cateogryId>101</categoryId> </m:addProduct> </SOAP-ENV:Body> En el caso de un response, la tag inicial de cada entrada del elemento BODY es el nombre el mtodo seguido por la palabra response (<NombreMetodoResponse>) y los elementos hijos de esta tag representan los parmetros de salida y/o entrada/salida del mtodo, en el mismo orden que en la signatura del mtodo remoto. En el caso que el mtodo retorne un valor este es el primer hijo de la tag y a continuacin se encuentran los parmetros de slida y/o entrada/salida Ejemplo: <SOAP-ENV:Body> <m:addProductResponse xmlns:m="MY_XML-SCHEMA/IProductCatalog"> <productId>P00145TV</productId> </m:addproductResponse> <SOAP-ENV:Body>

11

Interconexin de aplicaciones legadas usando el paradigma de mensajes

1.7 Arquitectura
1.7.1 Funcionamiento genrico de RPC en SOAP
La siguiente figura muestra la arquitectura general de un sistema distribuido basado en SOAP:

Aplicacin Cliente respuesta SOAP Cliente SOAP response SOAP Servidor respuesta Servidor Aplicaciones invocacin SOAP request invocacin

El siguiente diagrama de secuencia explica en detalle la figura anterior: Aplicacin Cliente invocacin Generar XML (serializacin) SOAP request (HTTP POST) Parsing XML Deserializacin invocacin respuesta Genera XML (Serializacin) SOAP Cliente SOAP Server Servidor Aplicaciones

SOAP response (HTTP) Parsing XML respuesta Deserializacin 12

Interconexin de aplicaciones legadas usando el paradigma de mensajes

La aplicacin cliente formula un requerimiento de servicio (invocacin) , utilizando las funcionalidades de un Cliente SOAP se crea un mensaje en formato XML en el cual se serializa el requerimiento. El mensaje XML conteniendo el requerimiento del cliente es enviado mediante un protocolo de transporte (en el caso de HTTP mediante un POST) a un servidor SOAP El servidor SOAP parsea el mensaje XML recibido. El servidor SOAP deserializa el mensaje XML. El servidor SOAP realiza la invocacin al servidor de aplicaciones apropiado. El servidor SOAP recibe el resultado de la invocacin y genera un mensaje en formato XML (serializacin de la respuesta) El servidor SOAP enva el mensaje XML al cliente SOAP utilizando un protocolo de transporte (por ejemplo HTTP). El cliente SOAP al recibir la respuesta parsea el mensaje XML. El cliente SOAP deserializa el mensaje XML y pasa el resultado a la aplicacin cliente.

Aplicacin Cliente respuesta invocacin Cliente SOAP Serializacin Parsing XML

Deserializacin

SOAP response (HTTP)

SOAP request (HTTP POST) Parsing XML

Servidor SOAP Serializacin Deserializacin respuesta Servidor Aplicaciones invocacin

13

Interconexin de aplicaciones legadas usando el paradigma de mensajes

1.8 Ventajas
1- Protocolo abierto SOAP es una especificacin abierta, construdo sobre tecnologas tambin abiertas como XML y HTTP. Por estas razones ha sido aceptado uniformemente por la industria, lo cual incrementa sus posibilidades de transformarse en estndard. 2- Simplicidad La especificacin de SOAP est bien definida y es sumamente simple. 3- Independiente de plataformas y lenguajes SOAP propone el uso de XML y HTTP para acceder objetos, servicios y servidores. Hoy da HTTP es un protoclo de transporte aceptado por la industria y es usado en forma general sobre todas las plataformas. XML est siguiendo un camino parecido, dado que actualmente existen versiones de XML para casi cualquier plataforma o lenguaje de uso comn. El uso de XML y HTTP hace a SOAP completamente independiente de plataformas, sistemas operativos o lenguajes de programacin. 4- Interoperabilidad El mundo de la computacin distribuida se encuentra dividido en grandes grupos dependiendo de la tecnologa usada, cada uno de los cuales adhiere a su propio protocolo: Microsoft con DCOM, CORBA o Java RMI/IIOP. Es un hecho que la interaccin entre sistemas basados en diferentes tecnologas no es algo simple por ms que existan bridges entre DCOM y CORBA por ejemplo. Cabe la pregunta de porque si los distintos browser existentes pueden acceder a los servidores WEB sin tener en cuenta la plataforma del mismo, porque los programadores no pueden hacer lo mismo, o sea invocar servicios remotos de una forma independiente de la plataforma? Uno de los objetivos de SOAP es eliminar las dificultades que separan las plataformas de la programacin distribuida. Para esto SOAP se basa en atributos de otros protocolos exitosos para la WEB: simplicidad, flexibilidad, independencia de plataforma y basado en texto. Puede afirmarse que SOAP no es una nueva tecnologa sino la utilizacin de tecnologas existentes para internet para estandarizar la comunicacin entre aplicaciones distribuidas a travs de la WEB. En el nivel ms bajo (core) SOAP es una manera estndard de serializar la informacin necesaria para invocar servicios remotos en un formato que puede ser transportado a travs de la red e interpretado por el servicio remoto independientemente de su plataforma. En el caso de DCOM se usa un esquema de serializacin propietario llamado Network Data Representation (NDR), Corba utiliza un esquema similar pero incompatible llamado Common Data Representation (CDR). Por este motivo no es posible hacer invocaciones entre uno y otro en forma nativa y solamente es posible si se dispone de un bridge, el cual agrega complejidad y disminuye la performance. SOAP enfoca la interoperabilidad entre los sistemas distribuidos en el nivel de serializacin de datos, introduciendo XML en reemplazo de los formatos propietarios de serializacin, lo cual permite adopatar una posicin neutral entre las distintas plataformas. En el rea de interoperabilidad SOAP tiene ventajas con respecto a otros protocolos como ser IIOP DCOM, RMI, etc. Fundamentalmente si se piensa en la evolucin de los sistemas distribuidos hacia los WEB Services, en donde las aplicaciones distribuidas son accesibles a otros sistemas (escritos y funcionando en otra plataforma) a travs de internet, SOAP representa un mecanismo sumamente til a tales efectos, mientras que otras tecnologas no

14

Interconexin de aplicaciones legadas usando el paradigma de mensajes

logran un buen desempeo debido a los formatos propietarios de codificacin de la interaccin y la dependencia de las plataformas. 5- Firewalls Al usar HTTP como transporte puede pasar fcilmente a travs de los firewalls, lo cuales dejan pasar habitualmente el trfico que les llega por el puerto HTTP. Generalmente los desarrolladores se deben esforzar mucho para hacer que sus aplicaciones distribuidas trabajen en internet debido a la presencia firewalls dado que los mismos bloquean comunmente casi todos los puertos excepto algunos, entre los cuales se encuentra el puerto HTTP. Otras tecnologas distribuidas, como DCOM y CORBA se basan en la asignacin dinmica de puertos para realizar invocaciones remotas. Esto obviamente implica convencer a los administradores del lugar donde reside el servidor que abran los puertos necesarios en el firewall. Sin embargo los clientes de las aplicaciones distribuidas que estn del otro lado de otro firewall corporativo tiene el mismo problema, si no configuran su firewall para abrir el mismo puerto no pueden hacer uso de la aplicacin. Obviamente esta reconfiguracin del firewall donde reside el cliente no es algo prctico. Pero como SOAP utiliza HTTP como mecanismo de transporte y muchos firewalls permiten que HTTP los atraviese, no existen problemas de invocaciones de ambos lados de un firewall. Es de destacar que SOAP permite que los administradores configuren los firewalls para bloquear selectivamente los mensajes SOAP usando SOAP headers especficos (el header SOAPACTION, puede ser usado por los firewalls y otros filtros para conocer el requerimiento que llega sin necesidad de parsear el mensaje) 6- Transporte La versin 1.0 la especificacin de SOAP mandataba el uso de HTTP como transporte, en la versin 1.1 de la especificacin se flexibiliz esta posicin permitiendo el uso de protocolos de transporte como FTP, SMTP, adems de HTTP y sus variantes (HTTPS). Puede pensarse que en algn momento se usen otros protocolos como ser IIOP, RMI, etc. y de esta manera aumentar su usabilidad e interoperabilidad. 7- Bajo acoplamiento Los sistemas distribuidos basados en SOAP tienen un bajo acoplamiento, por lo cual pueden ser fcilmente mantenidos dado que pueden ser modificados independientemente de otros sistemas. En particular SOAP presenta un bajo acoplamiento con los sistemas y las aplicaciones internas de una organizacin, situacin que no se da con otras tecnologas distribuidas (CORBA, DCOM, etc.) donde existe un alto acoplamiento con la arquitectura subyacente de las aplicaciones lo que implica que tanto el emisor como el receptor deben usar el mismo sistema o por lo menos sistemas compatibles. 8- Escalabilidad Al usar el protocolo HTTP como transporte, los sistemas distribuidos construidos sobre SOAP son sumamente escalables.

15

Interconexin de aplicaciones legadas usando el paradigma de mensajes

1.9 Desventajas
1- Performance No es una forma de comunicacin entre aplicaciones compacta, dado que los mensajes estn codificados en XML, o sea en un formato ASCII. Esto hace que el transporte sea ineficiente a travs de la red, en particular en los casos de grandes conjuntos de datos. Lo contrario sucede con los formatos binarios de datos como mecanismo de comunicacin entre aplicaciones, que son usado por ejemplo por CORBA (CDR), DCOM (NDR), etc. Frente a esto puede argumentarse que a pesar que los mensajes SOAP sean mucho ms grandes que sus equivalentes en formato NDR o CDR, por estar en formato XML o sea ASCII, que esta desmejora de la performance es insignificante en el caso de aplicaciones sobre internet donde la latencia inherente a la propia red es mucho ms significativa. Lo que si puede decirse es que para una LAN, o lo que es lo mismo dentro de una empresa, DCOM, CORBA o Java RMI tienen una performance mejor y por lo tanto estos protocolos son preferidos para desarrollar en el mbito de una LAN (recordar que adems no existen los problemas inherentes a los firewalls). Existen estudios publicados en http://www.tkim.net/paper/soap.html que comparan la performance de SOAP e IIOP. Por ejemplo en el caso local, usando CORBA/IIOP se logra una mejora de 15 veces que usando SOAP. Esto se da an en el caso de usar IIOP sobre HTTP 2- Parsing Como est basado en XML (formato ASCII) el parsing requiere ms recursos de CPU, que otros protocolos basados en formato binario. 3- Marhalling/Unmarshalling Como est basado en XML (formato ASCII) el marshalling/unmarshalling recursos de CPU, que otros protocolos basados en formatos binarios. 4- Serializacin Todos los datos son serializados y pasados por valor y no por referencia, esto puede provocar problemas de sincronizacin si mltiples copias de un objeto fuesen pasadas en el mismo momento. 5- Semntica SOAP no define la semntica de los mensajes, lo cual significa que la aplicacin cliente y la aplicacin servidor deben acordar al semntica de los mensajes. requiere ms

16

Interconexin de aplicaciones legadas usando el paradigma de mensajes

1.10 SOAP y las tecnologas distribuidas

SOAP no es comparable a las tecnologas de procesamiento distribuido existentes, dado que SOAP es un protocolo de comunicacin entre aplicaciones y no es una arquitectura distribuida completa, por lo cual varias caractersticas de estas arquitecturas quedan fuera del alcance de SOAP, como forma de cumplir con los objetivos de simplicidad y extensibilidad de su diseo. La siguiente tabla muestra como se compara SOAP con las caractersticas relevantes de las arquitecturas distribuidas y como estas se comparan entre s. DCOM JAVA-RMI SOAP Requiere Una vez mucho obtenida la intercambio referencia a inicial para Buena un objeto, activar y usar el performance. CORBA objeto remoto. Funciona La performance es baja, debido a que se permite una Una vez nicamente para debe extraer el mensaje SOAP, hacer el comunicacin obtenida la el lenguaje Java parsing de XML, crear los objetos directa, por lo referencia al y por lo tanto la apropiados y convertir los parmetros. cual la objeto remoto, performance est comunicacin es posible optimizada. es muy acceder en rpida. forma directa al objeto. La especificacin de SOAP no establece Muy flexible, nada al respecto, sin embargo si se utiliza Orientado a la provee subHTTP como protocolo de transporte, este conexin y Steteful. protocolos requiere una arquitectura stateless, la cual steteful. stateless y puede no ser apropiada en todas las stateful. circustancias. CORBA no establece el manejo distribuido de memoria, Provee un Provee de un La especificacin de SOAP no establece aunque mecanismo excelente nada al respecto. existen automtico. mecanismo. implementaci ones dependiendo del fabricante. La especificacin de SOAP no define Como Java RMI ninguna caracterstica de seguridad trabaja con el propia del protocolo SOAP. lenguaje de La seguridad, por lo menos en alguno de Provee soporte programacin sus aspectos, queda determinada por el No provee un para Java, hereda los protocolo de transporte que se utilice. soporte autentificacin, mecanismos de Teniendo en cuenta que los mensajes intrnseco autorizacin e seguridad est codificados en XML y por lo tanto en para identidad. Los existntes en texto, cualquiera podra alterar dichos autentificaci usuarios Java. El uso del mensajes. Como SOAP utiliza HTTP n, pueden definir RMI Security como transporte puede utilizar cualquier autorizacin o el nivel Manager habilita caracterstica de seguridad estndard de identidad. apropiado de la carg dinmica HTTP. Pueden usarse los mecanismos de seguridad. de clases y por lo autenticacin o bien canales seguros de tanto provee comunicaciones (SSL y HTTPS). seguridad adicional. CORBA

Seguridad

Garbage collection

Manejo del Estado

Performance

17

Interconexin de aplicaciones legadas usando el paradigma de mensajes

Otros aspectos de seguridad pueden implementarse haciendo uso de usa de headers especficos de los mensajes SOAP como ser el header SOAPACTION puede ser usado por los firewalls para filtrar los mensajes. TransaccionalContexto

La especificacin de SOAP no establece nada al respecto.

Activacin ReferenciaObjetos por

La especificacin del protocolo SOAP deja expresamente de lado este tema, dado que se requiere Garbage collection

La especificacin del protocolo SOAP deja expresamente de lado este tema, dado que requiere objetos por referencia

En conclusin SOAP no define o deja expresamente de lado ciertas caractersticas de las arquitecturas distribuidas con la finalidad de mantener los objetivos de su diseo de ser un protocolo simple y extensible. Sin embargo puede observarse que SOAP no tiene por finalidad sustituir las tecnologas de procesamiento distribuido existentes sino brindar interoperabilidad en un entorno heterogeneo, donde presenta caractersticas que lo hacen sumamente til frente a las limitaciones de otras tecnologas. Por lo tanto es posible que los sistemas distribuidos existentes de una organizacin o los desarrollos de nuevos sistemas sean expuestos a todos aquellos clientes que soporten SOAP.

18

Interconexin de aplicaciones legadas usando el paradigma de mensajes

2 ANEXO - APACHE SOAP

Apache SOAP es una implementacin open-source de la especificacin SOAP v1.1 en Java de Apache Software Foundation. Se basa en la implementacin SOAP4J, la cual fue donada por IBM a Apache. Apache SOAP puede ser usado como un librera cliente para invocar servicios SOAP disponibles en algn lugar o como herramienta para implementar servicios SOAP en servidores. Como librera cliente provee una API para invocar servicios usando RPC, as como una API para enviar y recibir mensajes. Como herramienta para escribir nuevos servicios accesibles a travs de RPC o a travs de mensajes, requiere de un WEB Application Server, que soporte servlets y Java Server Pages (JSP), que la contenga. La siguiente figura muestra la arquitectura de un sistema distribuido usando APACHE SOAP:

Aplicacin Cliente respuesta SOAP library invocacin Parsing XML SOAP request (HTTP POST) Remote Service registry SOAP Library Parsing XML Administracin Clientes

SOAP response (HTTP)

SOAP Listener (servlet) WEB server respuesta Servidor Aplicaciones invocacin

19

Interconexin de aplicaciones legadas usando el paradigma de mensajes

2.1 Instalacin
Notas Se asume que la instalacin se realiza en ambiente Windows. Sino se debe cambiar \ por /. Se debe tener instalado Java, en caso contrario: o Download la distribucin o Instalar en el directorio xxx\jdk1.3.1 Download de la distribucin binaria de Apache SOAP versin 2.2 (ltima versin disponible). Extraer el contenido del archivo anterior en el directorio xxx. Los archivos de la distribucin quedan bajo el directorio xxx\soap-2_2. Para el cliente se necesita: Soap.jar, se encuentra en xxx\soap-2_2\lib\soap.jar Download de mail.jar desde JavaMail Download de activation.jar desde JavaBeans Activation Framework Un parser de XML que sea compatible con JAXP y namespace-aware. Por ejemplo Apache Xerces (versin 1.1.2 en adelante).

Extraer los contenidos de los archivos anteriores en el directorio xxx. Los archivos de las distintas distribuciones quedan en los directorios xxx\javamail-1.2 xxx\jaf-1.0.1 xxx\xerces-1_4_1 respectivamente. Agregar a la variable CLASSPATH los jar anteriores: o o o o xxx\javamail-1.2\mail.jar xxx\soap-2_2\lib\soap.jar xxx\xerces-1_4_1\xerces.jar xxx\jaf-1.0.1\activation.jar

Nota: Si se encuentra instalado en el equipo otro parser de XML que no cumpla las especificaciones mencionadas anteriormente y el mismo se encuentra en la variable CLASSPATH, entonces el parser Apache Xerces debe aparecer al principio de la varible CLASSPATH, sino Apache SOAP no funcionr correctamente. El servidor SOAP de APACHE requiere un servidor WEB que soporte servlets y JSP(Java Server Pages), en particular se puede utilizar Apache Tomcat. Para el parsing de los mensajes en formato XML es posible utilizar cualquier parser que soporte DOM level 2 namespace support, en particular es posible usar Xerces de APACHE.

20

Interconexin de aplicaciones legadas usando el paradigma de mensajes

2.2 Xerces
The Xerces project provides XML parsers for a variety of languages, including Java, C++ and Perl. The Perl bindings are based on the C++ sources. There are Tcl bindings for Xerces in the 2.0 version of TclXML, by Steve Ball. This 2.0 version is only available at the moment thru Ajuba CVS repository. A XML parser is a tool used for programatic access to XML documents. This is a description of the standards supported by Xerces: DOM: DOM stands for Document Object Model. XML documents are hierarchical by nature (nested tags). XML documents can be accessed thru a tree like interface. The process is as follow: Parse document Build tree add/delete/modify nodes Serialize tree SAX:Simple API for XML. This is a stream based API. This means that we will receive callbacks as elements are encountered. These callbacks can be used to construct a DOM tree for example. XML Namespaces XML Schema: The XML standard provides the syntax for writing documents. XML Schema provides the tools for defining the contents of the XML document (semantics). It allows to define that a certain element in the document must be an integer between 10 and 20, etc. The Xerces XML project initial code base was donated by IBM. You can find more information in the Xerces Java, Xerces C and Xerces Perl homepages.

21