Interconexin de aplicaciones legadas usando el paradigma de mensajes

S.O.A.P.

Ing. Sandro Moscatelli

21/08/01
In.Co.

Interconexin de aplicaciones legadas usando el paradigma de mensajes

Indice
1

SOAP.....................................................................................................................................................2
1.1
INTRODUCCIN...............................................................................................................................2
1.2
QU ES SOAP................................................................................................................................2
1.3
MENSAJES DE SOAP......................................................................................................................3
1.4
ARQUITECTURA BSICA DE SOAP.................................................................................................4
1.5
PORQUE SOAP...............................................................................................................................4
1.6
PROTOCOLO SOAP.........................................................................................................................5
1.6.1 Mensaje SOAP...........................................................................................................................5
1.6.1.1
1.6.1.2
1.6.1.3
1.6.1.4
1.6.1.5

SOAP Envelope..............................................................................................................................6
SOAP Header..................................................................................................................................6
SOAP Body....................................................................................................................................6
Mensajes.........................................................................................................................................7
SOAP y HTTP................................................................................................................................8

1.6.2 Reglas codificacin (Encoding Rules)......................................................................................9

1.6.3 SOAP RPC.................................................................................................................................9
1.7
ARQUITECTURA............................................................................................................................11
1.7.1 Funcionamiento genrico de RPC en SOAP...........................................................................11
1.8
VENTAJAS.....................................................................................................................................13
1.9
DESVENTAJAS...............................................................................................................................15
1.10 SOAP Y LAS TECNOLOGAS DISTRIBUIDAS..................................................................................16
2

ANEXO - APACHE SOAP................................................................................................................18

2.1
2.2

INSTALACIN................................................................................................................................19
XERCES.........................................................................................................................................20

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:
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.
1.

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 Envelope

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

SOAP Header
(optional)
Header1

Header2

SOAP Body
Remote Method 1
signature

Remote Method 2
signature

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

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

<SOAP-ENV:Body>

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

xmlns:m1="some URI">

<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.

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>

10

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
invocacin

respuesta
SOAP Cliente

SOAP request

SOAP response
SOAP Servidor

invocacin

respuesta
Servidor Aplicaciones

El siguiente diagrama de secuencia explica en detalle la figura anterior:

SOAP
Cliente

Aplicacin
Cliente

SOAP
Server

Servidor
Aplicaciones

invocacin
Generar XML
(serializacin)
SOAP request
(HTTP POST)
Parsing XML
Deserializacin
invocacin
respuesta

SOAP response
(HTTP)
Parsing XML
respuesta

Deserializacin
11

Genera XML
(Serializacin)

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
Deserializacin
Serializacin
SOAP response (HTTP)

Parsing XML

SOAP request (HTTP POST)

Servidor SOAP
Serializacin
Deserializacin
respuesta

invocacin
Servidor Aplicaciones

12

Parsing XML

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

13

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.

14

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.

requiere ms

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.

15

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.

Seguridad

Garbage collection

Manejo del
Estado

Performance

CORBA

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.

16

Interconexin de aplicaciones legadas usando el paradigma de mensajes

TransaccionalContexto

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.

Activacin ReferenciaObjetos por

La especificacin de SOAP no establece

nada al respecto.

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.

17

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

invocacin
SOAP library

Parsing XML
SOAP request (HTTP POST)

SOAP response (HTTP)

SOAP Listener (servlet)

WEB server
respuesta

invocacin
Servidor Aplicaciones

18

Remote Service
registry
SOAP Library
Parsing XML

Administracin
Clientes

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.

19

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.

20