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. .1 !unciona"ien#o gen$%ico de RPC en SOAP..............................................................................12 1.8 VENTAJAS.........................................................................................................................................14 1. DESVENTAJAS...................................................................................................................................16 1.1! SOAP " LAS TECNOLO#$AS DISTRIBUIDAS....................................................................................17 2 ANEXO - APACHE SOAP....................................................................................................................19 2.1 INSTALACIN....................................................................................................................................2! 2.2 %ERCES ............................................................................................................................................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 Da e !iner" de la empresa #ser$and Soft%are a finales del a&o '(()" de un mecanismo basado en *+$ para realizar in ocaciones ,P-. A partir de dic.a especificacin / de la unin de las empresas De elop+entor" #ser$and Soft%are / +icrosoft surge p0blicamente la ersin 1.( de SOAP en setiembre de '(((. $a ersin '.1 fue lanzada casi a continuacin de la ersin 1.( (diciembre de '((() / en iada a la I234 (Internet 2ngineering 3as5 4orce). 2ste organismo .izo de esta ersin una recomendacin oficial. Posteriormente se realiz la ersin '.' de SOAP" donde" adem6s de las empresas mencionadas" tambi7n participaron $otus e I8+" entre muc.as otras empresas de desarrollo de soft%are. 2sta nue a ersin fue en iada al !9- (!orld !ide !eb -onsortium) en ma/o del :111" con el propsito de formar un grupo de trabajo en el 6rea de los protocolos basados en *+$. 2n julio de :111 el grupo de trabajo en el 6rea de *+$ del !9- edita el primer !9- !or5ing Draft de la ersin '.: de SOAP. $a especificacin del protocolo SOAP" b6sicamente" describe un formato de mensajes para comunicar aplicaciones. $a filosof;a de SOAP" para lograr dic.a comunicacin" es no in entar una nue a tecnolog;a" sino combinar tecnolog;as existentes / de amplia aceptacin en la industria de soft%are. 2n particular" combina *+$ para la codificacin de los mensajes / <33P como protocolo de transporte (aun=ue no se exclu/e el uso de otros protocolos de tranporte).

1.2 Qu es SOAP
SOAP define un mecanismo simple / li iano (en contraposicin a sofisticado) para la comunicacin" en un entorno distribuido o descentralizado" entre componentes de soft%are o aplicaciones. $a comunicacin se realiza mediante mensajes codificados en *+$ / transportados por un protocolo de transporte (SOAP no mandata el uso de un protocolo de transporte en particular" aun=ue si define como es el transporte en caso de usar <33P). 2n definiti a SOAP define un mecanismo para el intercambio de informacin" estructurada / tipeada" entre pares de aplicaciones en un entorno distribuido" teniendo como objeti os de dise&o la simplicidad / la extensibilidad. SOAP no define por s; mismo la sem6ntica de las aplicaciones" como ser un modelo de programacin o alg0n tipo de sem6ntica espec;fica de una implementacin" sino =ue pro ee un mecanismo simple para expresar la sem6ntica de las aplicaciones" mediante un modelo modular de empa=uetado de mensajes / la definicin de como codificar los datos de las aplicaciones en dic.os mdulos" es posible er a SOAP desde distintos puntos de ista> '. -omo un mecanismo para in ocar m7todos en ser idores" ser icios" o componentes" para lo cual se define en la especificacin una metodolog;a para encapsular e intercambiar in ocaciones ,P-" en los mensajes" usando la extensibilidad / flexibilidad =ue proporciona *+$. :. -omo un protocolo para intercambio de mensajes (sincrnicos o asincronicos). 9. -omo un formato para intercambio de documentos *+$.

Interconexin de aplicaciones legadas usando el paradigma de mensajes

1.3 Mensa es de SOAP

$a especificacin de SOAP define el formato de los mensajes para comunicar aplicaciones" normalmente dic.os mensajes son una forma de comunicacin de una 0nica ;a entre un emisor / un receptor (mensajes asincrnicos)" sin embargo pueden ser combinados de manera de implementar patterns de re=uerimiento?respuesta (mensajes sincrnicos). 2n la ersin '.1 de la especificacin de SOAP se establec;a como mandatorio el uso de <33P como protocolo de transporte" sin embargo a partir de la ersin '.' se desacopla SOAP del uso de <33P" lo cual permite una ma/or ariedad de protocolos de tranporte como ser 43P" S+3P" etc. 2n definiti a la especificacin no establece un protocolo de transporte particular pero si especifica como se realiza el transporte en caso de usar <33P. 2l implementar patterns re=uerimiento?respuesta es sumamente natural si se utiliza <33P como protocolo de transporte dado =ue en este caso los mensajes SOAP siguen el modelo re=uerimiento?respuesta de los mensajes <33P" en iando el re=uerimiento en un request <33P / la respuesta SOAP en un <33P response. Adem6s de lo anterior" el .ec.o de usar <33P tiene las siguientes entajas> 2s el protocolo est6ndar para la comunicacin en Internet. 2st6 disponible para todas las plataformas. ,e=uiere mu/ poco soporte en tiempo de ejecucin para funcionar adecuadamente. $a seguridad de <33P es simple / efecti a. 2s un protocolo =ue permite atra esar fire%alls. @o es un protocolo orientado a la conexin (para establecer o manener una sesin se deben intercambiar pocos o ning0n pa=uete)

$a especificac;on de SOAP establece =ue los mensajes sean codificados en *+$. 2l uso de *+$ tiene la siguientes entajas> *+$ es un protocolo para representar datos independientemente de plataformas / lenguajes Se est6 transformando r6pidamente en un est6ndar al ser ampliamente aceptado por la industria de sof%are. 2st6 disponible en todas las plataformas. 2s adecuado para manipular datos estructurados / tipeados 2s f6cil de analizar (parsing) / entender (tanto para m6=uinas como por personas) por ser texto.

Interconexin de aplicaciones legadas usando el paradigma de mensajes

1.! Ar"uitectura #$sica de SOAP

Desde el punto de ista de la presente tesis interesa usar SOAP para comunicar aplicaciones" realizando in ocaciones ,P- e implementando el pattern re=uerimiento?respuesta" por lo cual el comportamiento es similar al de una ar=uitectura cliente ser idor" donde el proceso es iniciado por el cliente / el ser idor responde al re=uerimiento del mismo. 2ste tipo de comunicacin se basa en un sistema de mensajes SOAP sincrnicos" codificados en *+$ =ue son transportados por <33P.

2n la figura se obser a la ar=uitectura b6sica de un sistema" an6logo al descripto" constru;do sobre SOAP / los mensajes =ue definen la interaccin entre la aplicacin cliente / la aplicacin ser idor. Aeneralmente la aplicacin cliente en ;a un mensaje (,2B#2S3 ;a <33P)" el cual al ser recibido por la aplicacin ser idor genera una respuesta (,2SPO@S2) =ue es en iada a la aplicacin cliente ;a <33P. Se obser a adem6s =ue en el caso de usar SOAP para realizar ,P-" la in ocacin ,P- se mapea naturalmente al ,2B#2S3 de <33P / la respuesta ,P- se mapea al ,2SPOS2 de <33P.

1.% Por"ue SOAP

Puede pensarse en cu6l es la necesidad de un protocolo de las caracter;sticas de SOAP" si actualmente existen tecnolog;as de procesamiento distribuido =ue funcionan correctamente / ampliamente difundidas como ser D-O+ o -O,8A" por mencionar solamente a dos de las m6s conocidas" cada una de las cuales pro ee su propio protocolo de comunicacin. 4undamentalmente si se piensa en la e olucin de los sistemas distribuidos .acia los !28 Ser ices" en donde las aplicaciones distribuidas son accesibles a otros sistemas (escritos / funcionando en otra plataforma)" puede erse =ue las distintas tecnolog;as de procesamiento distribuido existentes presentan una serie de limitaciones debido a> son dependientes de la plataforma y de fabricantes . D-O+ est6 ligado a !indo%s @3 / -O,8A" a pesar de ser una ar=uitectura abierta" est6 controlado por determinados endedores. Por lo tanto .acer =ue los sistemas distribuidos" construidos usando D-O+ o -O,8A" sean accesibles a otros sistemas .eterog7neos (escritos o funcionando en otra plataforma) es un problema bastante serio" a menos =ue ambas partes tengan la misma plataforma / sistemas similares" lo cual implica =ue las aplicaciones tengan un alto acoplamiento. presentan problemas con los firewalls . 3anto D-O+ como -O,8A asignan puertos en forma din6mica" lo cual dificulta su uso en internet" donde los fire%alls corporati os blo=uean normalmente el acceso" a no ser por puertos espec;ficos (por ejemplo puerto <33P). hacen uso de protocolos sofisticados. 2sto implica la instalacin de grandes / complejas librer;as del lado del cliente" adem6s de implicar =ue el proceso de desarrollo de los clientes D-O+ / -O,8A es complejo. 2sto contradice la idea de los

Interconexin de aplicaciones legadas usando el paradigma de mensajes

!28 ser ices cu/a idea base es publicar ser icios para =ue sea accesibles a otras aplicaciones. Adem6s re=ueieren un gran soporte en tiempo de ejecucin para funcionar adecuadamente. Ambas tecnologas utilizan formatos propietarios de representacin de los datos . D-O+ utiliza un formato llamado @et%or5 Data ,epresentation (@D,) / -O,8A utiliza un es=uema similar pero incompatible llamado -ommon Data ,epresentation (-D,). Adem6s dic.os formatos son binarios / mu/ ligados a la ar=uitectura de los modelos de componentes respecti os. 2n definiti a en el entorno de sistemas distribuidos funcionando sobre internet" las tecnolog;as existentes presentan serias limitaciones debido a la .eterogeneidad del entorno" la presencia de fire%alls / al uso de formatos propietarios para representar datos. 8ajo estas condiciones SOAP es una alternati a sumamente 0til para comunicar aplicaciones .eterog7neas (interoperabilidad)" fundamentalmente por el uso de *+$ =ue es un est6ndard basado en texto e independiente de plataformas / lenguajes / por el uso de <33P como transporte" el cual normalmente atra iesa los fire%alls dado =ue estos no blo=uean el puerto <33P. Adem6s al no ser un protocolo sofisticado / al no definir modelos de programacin permite =ue las aplicaciones tengan un bajo acoplamiento" lo cual es ideal en el entorno de internet. De todas maneras puede erse =ue SOAP no es una tecnolog;a =ue reemplace a las existentes sino una tecnolog;a =ue permite la interoperabilidad de aplicaciones .eterog7neas.

1.& Protocolo SOAP

$a especificacin del protocolo SOAP indica =ue el mismo consiste de 9 partes> 2l constructor SOAP 2@C2$OP2 =ue define un frame%or5 para expresar =u7 .a/ en un mensaje" a =ui7n est6 dirigido el mensaje / cuando es opcional o mandatorio. $as reglas de codificacin =ue definen un mecanismo de serializacin para ser usado para intercambiar instancias de tipos de datos. $a representacin SOAP ,P- =ue define una metodolog;a =ue puede ser usada para representar in ocaciones a procedimientos remotos / sus respuestas.

Se describen a continuacin las 9 partes del protocolo SOAP

1.&.1 Mensa e SOAP

3anto los mensajes ,2B#2S3 como ,2SPO@S2 consisten en mensajes <33P" pero es de .acer notar =ue en caso de usar cual=uier otro protocolo de transporte no cambia el contenido del mensaje" el cual est6 codificado en *+$. $a parte *+$ de los mensajes tiene la estructura =ue se muestra en la siguiente figura>

Interconexin de aplicaciones legadas usando el paradigma de mensajes

$os mensajes SOAP est6n codificados en *+$ / consisten de una seccin denominada 2@C2$OP2 (obligatoria)" la cual est6 compuesta de una seccin denominada <2AD2, (opcional) / de una seccin denominada 8ODD (obligatoria). -ada una de estas secciones se explican a continuacin.

1.&.1.1 SOAP 'n(elo)e

2sta construccin sint6ctica de nombre 2@C2$OP2 contiene el resto del documento *+$ / debe estar presente siempre / ser primer seccin del mensaje. Define los distintos @A+2SPA-2S =ue son usados en el resto del mensaje <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope" SOAP-ENV:encodingSt le="http://schemas.xmlsoap.org/soap/encoding/"! </SOAP-ENV:Envelope! $os @A+2SPA-2S se utilizan para garantizar la unicidad de los elementos / e itar ambiguedades.

1.&.1.2 SOAP *eader

2sta construccin sint6ctica de nombre <2AD2, es opcional / es un mecanismo gen7rico para extender las caracter;sticas de los mensajes SOAP de una manera descentralizada / sin un acuerdo pre io entre las partes =ue se comunican. 2n caso de estar presente debe ser el primer .ijo de la construccin 2@C2$OP2. A modo de ejemplo algunas extensiones =ue pueden ser implementadas mediante esta construccin son transportar informacin auxiliar para la autenticacin" manejo de transacciones" etc. <SOAP-ENV:"eader! <#ser$%n&ormation! </SOAP-ENV:"eader! <SOAP-ENV:"eader! <'ransaction$%n&ormation! </SOAP-ENV:"eader!

1.&.1.3 SOAP +od,

2s una construccin sint6ctica de nombre 8ODD =ue act0a como contenedor para la informacin =ue se en ;a al receptor del mensaje. 2sta construccin debe estar presente siempre en los mensajes SOAP / debe estar a continucin del <2AD2," si est6 presente" o ser el primer .ijo de 2@C2$P2 si el <2AD2, no est6 presente. $os usos t;picos de esta construccin son pro eer un mecanismo simple de intercambiar informacin con el receptor del mensaje SOAP. 2n esta parte del mensaje es donde se encuentran las in ocaciones ,P- o bien el resultado de la in ocacin. <SOAP-ENV:(od ! <m):*emote+ethodName$$$xmlns:m)="some$#*%"! <arg)!val,e)</arg)! <arg-!val,e-</arg-! </m):*emote+ethodName! <m-:*emote+ethodName$$xmlns:m-="some$#*%"! $$$$$$$$$$$<arg)!val,e)</arg)! $$$$$$</m-:*emote+ethodName! </SOAP-ENV:(od !$

Interconexin de aplicaciones legadas usando el paradigma de mensajes

1.&.1.! Mensa es
-ada una de las construcciones sint6cticas <2AD2, / 8ODD pueden ser organizadas en blo=ues" es decir unidades sint6cticas usadas para delimitar informacin =ue lgicamente constitu/e una unidad computacional para un emisor o receptor. $a siguiente figura muestra lo explicado anteriormente>
<SOAP-ENV:Envelope

SOAP Envelope
SOAP *eader
(optional) *eader1

$$xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope" $$SOAP-ENV:encodingSt le="http://schemas.xmlsoap.org/soap/encoding/"! $$

$$<SOAP-ENV:"eader! $$$$<#ser$%n&ormation! $$</SOAP-ENV:"eader! $$ $$<SOAP-ENV:"eader! $$$$<'ransaction$%n&ormation! $$</SOAP-ENV:"eader!

*eader2

SOAP +od,
-e.ote Met/od 1 signature

$$<SOAP-ENV:(od !

$$$$<m):*emote+ethodName)$$$xmlns:m)="some$#*%"! $$$$$$<arg)!val,e)</arg)! $$$$$$<arg-!val,e-</arg-! $$$$</m):*emote+ethodName! $$$<m-:*emote+ethodName-$$xmlns:m-="some$#*%"! $$$$$$<arg)!val,e)</arg)! $$$$$$</m-:*emote+ethodName! $$</SOAP-ENV:(od ! </SOAP:Envelope!

-e.ote Met/od 2 signature

Interconexin de aplicaciones legadas usando el paradigma de mensajes

1.&.1.% SOAP , *00P

-omo se mencion los mensajes SOAP son transportados generalmente por <33P. 2n este caso pueden usarse distintos m7todos para el ,2B#2S3 pero el m6s com0n es el POS3. Por lo tanto un mensaje SOAP consiste en un <2AD2, <33P =ue se encuentra antes del mensaje SOAP" este <2AD2, <33P difiere poco de un cabezal <33P t;pico como se detalla a continuacin> 2n la primer l;nea se especifica el m7todo de en ;o" la #,I re=uerida / la ersin del protocolo usada> POS'$/Prod,ct.atalog$"''P/).) 2n la siguiente l;nea se espec;fica el destino> "OS':$&&&.'(&)*+,-)../' $as siguientes 9 l;neas son usadas para definir el formato +I+2 para desplegar el mensaje" la codificacin <33P / el largo del mensaje> .ontent-' pe:$text/xml/ charset=",t&-0"$ .ontent-1ength:$nn$ A continuacin se agregan cabezales SOAPA-3IO@" esta parte del <2AD2, <33P es la =ue difiere de otros cabezales t;picos <33P" =ue indican la intencin del mensaje / son usados en el ,2B#2S3. 2n particular una posibilidad es indicar el m7todo a ser in ocado / el alor es una #,I identificando el m7todo (formada por el nombre del m7todo precedida por la #,I del <OS3 / usando el car6cter E como separador) SOAPAction:"http://222.m 2e3site.com4Nom3re+etodo5

Otros posibles alores para el cabezal SOAPA-3IO@ son el string ac;o (FG) =ue indica =ue se intenta acceder a la #,I especificada en la primer l;nea o bien sin alor =ue indica =ue no se tiene informacin sobre la intencin del mensaje SOAPAction:55 SOAPAction: @ota> 'H $os fire%alls / otros filtros de seguridad pueden usar este campo (SOAPA-3IO@) para conocer el re=uerimiento =ue llega sin necesidad de parsear el mensaje :H 2l identificador =ue sigue al caracter E debe mac.ear con los nombres de las tags en el 8ODD

Interconexin de aplicaciones legadas usando el paradigma de mensajes

A continuacin se presenta el mensaje SOAP completo> POS'$/Prod,ct.atalog$"''P/).) "OS':$&&&.'(&)*+,-)../' .ontent-' pe:$text/xml/ charset=",t&-0"$ .ontent-1ength:$nn SOAPAction:0--1233&&&.'(&)*+,-)../'4*emote+ethodName) SOAPAction:0--1233&&&.'(&)*+,-)../'4*emote+ethodName<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope" SOAP-ENV:encodingSt le="http://schemas.xmlsoap.org/soap/encoding/"! $$$$$$<SOAP-ENV:"eader! $$$$$<#ser$%n&ormation! $$$$$$</SOAP-ENV:"eader! $$$$$$<SOAP-ENV:"eader! $$$$$<'ransaction$%n&ormation! $$$$$$</SOAP-ENV:"eader! $$$$$$<SOAP-ENV:(od ! $$$$$$<m):*emote+ethodName$$$xmlns:m)="0--1233&&&.'(&)*+,-)../'4"! $$$$<arg)!val,e)</arg)! $$$$<arg-!val,e-</arg-! $$$$$$</m):*emote+ethodName! $$$$$$ <m-:*emote+ethodName$$xmlns:m-="0--1233&&&.'(&)*+,-)../'4"! $$$$$$$$$$$$$$$<arg)!val,e)</arg)! $$$$$$$$$$$$</m-:*emote+ethodName! $$$$$$$</SOAP-ENV:(od ! </SOAP:Envelope!$

1.&.2 -eglas codi1icacin 2'ncoding -ules3

1.&.3 SOAP -PC

#no de los aspectos fundamentales de SOAP definir una metodolog;a para encapsular e intercambiar in ocaciones ,P- usando la extensibilidad / flexibilidad =ue proporciona *+$. 2l uso de SOAP para realizar ,P- es ortogonal al protocolo usado para el transporte del mensaje SOAP. 2n el caso de usar <33P" la in ocacin ,P- se mapea directamente al request de <33P / la respuesta ,P- se mapea al response de <33P. Para realizar una in ocacin ,P- es necesaria la siguiente informacin> $a ubicacin del objeto remoto 2l nombre del objeto remoto 2l nombre del m7todo $os par6metros del m7todo

3anto las in ocaciones ,P- como las respuestas son transportadas en el elemento 8ODD del mensaje SOAP / son modeladas como structs. 2s posible usar el cabezal SOAPA-3IO@ para especificar el nombre del objeto remoto / su ubicacin.

1!

Interconexin de aplicaciones legadas usando el paradigma de mensajes

2n el caso de un re=uest" la tag inicial de cada entrada en el elemento 8ODD es usada para especificar el nombre del m7todo (I@ombre+etodoJ) / los elementos .ijos de esta tag son usados para especificar los par6metros de entrada /?o entrada?salida del m7todo" en el mismo orden =ue en la signatura del m7todo remoto. A continuacin se muestra un ejemplo de un re=uest SOAP

5SOAP6ENV2B/7(8 5'2977P:/7;.- <'=>+2'?@M"A%MLASCBEMA3IP:/7;.-C9-9=/C@8 5>9')8S/>( TV53>9')8 57)+.817 ,>.0 ./=/: TV537)+.8 51:,.)8255. 531:,.)8 5.9-)/C:(I781!153.9-)C/:(I78 53'2977P:/7;.-8 53SOAP6ENV2B/7(8 E> )= .9+/ 7) ;> :)+1/>+)D =9 -9C ,>,.,9= 7) .979 )>-:979 7)= )=)')>-/ BOD" )+ )= >/'*:) )= 'E-/7/ +)C;,7/ 1/: =9 19=9*:9 F:)+1/>+)G H5N/'*:)M)-/7/R)+1/>+)8I ( =/+ )=)')>-/+ 0,J/+ 7) )+-9 -9C :)1:)+)>-9> =/+ 19:K')-:/+ 7) +9=,79 (3/ )>-:9793+9=,79 7)= 'E-/7/D )> )= ',+'/ /:7)> L;) )> =9 +,C>9-;:9 7)= 'E-/7/ :)'/-/. E> )= .9+/ L;) )= 'E-/7/ :)-/:>) ;> M9=/: )+-) )+ )= 1:,'): 0,J/ 7) =9 -9C ( 9 ./>-,>;9.,N> +) )>.;)>-:9> =/+ 19:K')-:/+ 7) +=,79 (3/ )>-:9793+9=,79 EJ)'1=/2 5SOAP6ENV2B/7(8 5'2977P:/7;.-R)+1/>+) <'=>+2'?@M"A%ML6SCBEMA3IP:/7;.-C9-9=/C@8 51:/7;.-I78P!!145TV531:/7;.-I78 53'29771:/7;.-R)+1/>+)8 5SOAP6ENV2B/7(8

11

Interconexin de aplicaciones legadas usando el paradigma de mensajes

1.4 Ar"uitectura
1.4.1 5unciona.iento genrico de -PC en SOAP
$a siguiente figura muestra la ar=uitectura general de un sistema distribuido basado en SOAP>

A1=,.9.,N> C=,)>-) :)+1;)+-9 SOAP C=,)>-) SOAP :)+1/>+) SOAP S):M,7/: :)+1;)+-9 S):M,7/: A1=,.9.,/>)+ ,>M/.9.,N> SOAP :)L;)+,>M/.9.,N>

2l siguiente diagrama de secuencia explica en detalle la figura anterior> A1=,.9.,N> C=,)>-) ,>M/.9.,N> #)>):9: %ML H+):,9=,O9.,N>I SOAP :)L;)+HBTTP POSTI P9:+,>C %ML D)+):,9=,O9.,N> ,>M/.9.,N> :)+1;)+-9 #)>):9 %ML HS):,9=,O9.,N>I SOAP C=,)>-) SOAP S):M): S):M,7/: A1=,.9.,/>)+

SOAP :)+1/>+) HBTTPI P9:+,>C %ML :)+1;)+-9 D)+):,9=,O9.,N> 12

Interconexin de aplicaciones legadas usando el paradigma de mensajes

$a aplicacin cliente formula un re=uerimiento de ser icio (in ocacin) " utilizando las funcionalidades de un -liente SOAP se crea un mensaje en formato *+$ en el cual se serializa el re=uerimiento. 2l mensaje *+$ conteniendo el re=uerimiento del cliente es en iado mediante un protocolo de transporte (en el caso de <33P mediante un POS3) a un ser idor SOAP 2l ser idor SOAP parsea el mensaje *+$ recibido. 2l ser idor SOAP deserializa el mensaje *+$. 2l ser idor SOAP realiza la in ocacin al ser idor de aplicaciones apropiado. 2l ser idor SOAP recibe el resultado de la in ocacin / genera un mensaje en formato *+$ (serializacin de la respuesta) 2l ser idor SOAP en ;a el mensaje *+$ al cliente SOAP utilizando un protocolo de transporte (por ejemplo <33P). 2l cliente SOAP al recibir la respuesta parsea el mensaje *+$. 2l cliente SOAP deserializa el mensaje *+$ / pasa el resultado a la aplicacin cliente.

A1=,.9.,N> C=,)>-) :)+1;)+-9 ,>M/.9.,N> C=,)>-) SOAP S):,9=,O9.,N> P9:+,>C %ML

D)+):,9=,O9.,N>

SOAP :)+1/>+) HBTTPI

SOAP :)L;)+- HBTTP POSTI P9:+,>C %ML

S):M,7/: SOAP S):,9=,O9.,N> D)+):,9=,O9.,N> :)+1;)+-9 S):M,7/: A1=,.9.,/>)+ ,>M/.9.,N>

13

Interconexin de aplicaciones legadas usando el paradigma de mensajes

1.8 6enta as
17 Protocolo a#ierto SOAP es una especificacin abierta" constru;do sobre tecnolog;as tambi7n abiertas como *+$ / <33P. Por estas razones .a sido aceptado uniformemente por la industria" lo cual incrementa sus posibilidades de transformarse en est6ndard. 27 Si.)licidad $a especificacin de SOAP est6 bien definida / es sumamente simple. 37 Inde)endiente de )lata1or.as , lengua es SOAP propone el uso de *+$ / <33P para acceder objetos" ser icios / ser idores. <o/ d;a <33P es un protoclo de transporte aceptado por la industria / es usado en forma general sobre todas las plataformas. *+$ est6 siguiendo un camino parecido" dado =ue actualmente existen ersiones de *+$ para casi cual=uier plataforma o lenguaje de uso com0n. 2l uso de *+$ / <33P .ace a SOAP completamente independiente de plataformas" sistemas operati os o lenguajes de programacin. !7 Intero)era#ilidad 2l mundo de la computacin distribuida se encuentra di idido en grandes grupos dependiendo de la tecnolog;a usada" cada uno de los cuales ad.iere a su propio protocolo> +icrosoft con D-O+" -O,8A o Ka a ,+I?IIOP. 2s un .ec.o =ue la interaccin entre sistemas basados en diferentes tecnolog;as no es algo simple por m6s =ue existan bridges entre D-O+ / -O,8A por ejemplo. -abe la pregunta de por=ue si los distintos bro%ser existentes pueden acceder a los ser idores !28 sin tener en cuenta la plataforma del mismo" por=ue los programadores no pueden .acer lo mismo" o sea in ocar ser icios remotos de una forma independiente de la plataformaL #no de los objeti os de SOAP es eliminar las dificultades =ue separan las plataformas de la programacin distribuida. Para esto SOAP se basa en atributos de otros protocolos exitosos para la !28> simplicidad" flexibilidad" independencia de plataforma / basado en texto. Puede afirmarse =ue SOAP no es una nue a tecnolog;a sino la utilizacin de tecnolog;as existentes para internet para estandarizar la comunicacin entre aplicaciones distribuidas a tra 7s de la !28. 2n el ni el m6s bajo (core) SOAP es una manera est6ndard de serializar la informacin necesaria para in ocar ser icios remotos en un formato =ue puede ser transportado a tra 7s de la red e interpretado por el ser icio remoto independientemente de su plataforma. 2n el caso de D-O+ se usa un es=uema de serializacin propietario llamado @et%or5 Data ,epresentation (@D,)" -orba utiliza un es=uema similar pero incompatible llamado -ommon Data ,epresentation (-D,). Por este moti o no es posible .acer in ocaciones entre uno / otro en forma nati a / solamente es posible si se dispone de un bridge" el cual agrega complejidad / disminu/e la performance. SOAP enfoca la interoperabilidad entre los sistemas distribuidos en el ni el de serializacin de datos" introduciendo *+$ en reemplazo de los formatos propietarios de serializacin" lo cual permite adopatar una posicin neutral entre las distintas plataformas. 2n el 6rea de interoperabilidad SOAP tiene entajas con respecto a otros protocolos como ser IIOP D-O+" ,+I" etc. 4undamentalmente si se piensa en la e olucin de los sistemas distribuidos .acia los !28 Ser ices" en donde las aplicaciones distribuidas son accesibles a otros sistemas (escritos / funcionando en otra plataforma) a tra 7s de internet" SOAP representa un mecanismo sumamente 0til a tales efectos" mientras =ue otras tecnolog;as no

14

Interconexin de aplicaciones legadas usando el paradigma de mensajes

logran un buen desempe&o debido a los formatos propietarios de codificacin de la interaccin / la dependencia de las plataformas. %7 5ire8alls Al usar <33P como transporte puede pasar f6cilmente a tra 7s de los fire%alls" lo cuales dejan pasar .abitualmente el tr6fico =ue les llega por el puerto <33P. Aeneralmente los desarrolladores se deben esforzar muc.o para .acer =ue sus aplicaciones distribuidas trabajen en internet debido a la presencia fire%alls dado =ue los mismos blo=uean comunmente casi todos los puertos excepto algunos" entre los cuales se encuentra el puerto <33P. Otras tecnolog;as distribuidas" como D-O+ / -O,8A se basan en la asignacin din6mica de puertos para realizar in ocaciones remotas. 2sto ob iamente implica con encer a los administradores del lugar donde reside el ser idor =ue abran los puertos necesarios en el fire%all. Sin embargo los clientes de las aplicaciones distribuidas =ue est6n del otro lado de otro fire%all corporati o tiene el mismo problema" si no configuran su fire%all para abrir el mismo puerto no pueden .acer uso de la aplicacin. Ob iamente esta reconfiguracin del fire%all donde reside el cliente no es algo pr6ctico. Pero como SOAP utiliza <33P como mecanismo de transporte / muc.os fire%alls permiten =ue <33P los atra iese" no existen problemas de in ocaciones de ambos lados de un fire%all. 2s de destacar =ue SOAP permite =ue los administradores configuren los fire%alls para blo=uear selecti amente los mensajes SOAP usando SOAP .eaders espec;ficos (el .eader SOAPA-3IO@" puede ser usado por los fire%alls / otros filtros para conocer el re=uerimiento =ue llega sin necesidad de parsear el mensaje) &7 0rans)orte $a ersin '.1 la especificacin de SOAP mandataba el uso de <33P como transporte" en la ersin '.' de la especificacin se flexibiliz esta posicin permitiendo el uso de protocolos de transporte como 43P" S+3P" adem6s de <33P / sus ariantes (<33PS). Puede pensarse =ue en alg0n momento se usen otros protocolos como ser IIOP" ,+I" etc. / de esta manera aumentar su usabilidad e interoperabilidad. 47 +a o aco)la.iento $os sistemas distribuidos basados en SOAP tienen un bajo acoplamiento" por lo cual pueden ser f6cilmente mantenidos dado =ue pueden ser modificados independientemente de otros sistemas. 2n particular SOAP presenta un bajo acoplamiento con los sistemas / las aplicaciones internas de una organizacin" situacin =ue no se da con otras tecnolog;as distribuidas (-O,8A" D-O+" etc.) donde existe un alto acoplamiento con la ar=uitectura sub/acente de las aplicaciones lo =ue implica =ue tanto el emisor como el receptor deben usar el mismo sistema o por lo menos sistemas compatibles. 87 'scala#ilidad Al usar el protocolo <33P como transporte" los sistemas distribuidos construidos sobre SOAP son sumamente escalables.

15

Interconexin de aplicaciones legadas usando el paradigma de mensajes

1.9 :es(enta as
17 Per1or.ance @o es una forma de comunicacin entre aplicaciones compacta" dado =ue los mensajes est6n codificados en *+$" o sea en un formato AS-II. 2sto .ace =ue el transporte sea ineficiente a tra 7s de la red" en particular en los casos de grandes conjuntos de datos. $o contrario sucede con los formatos binarios de datos como mecanismo de comunicacin entre aplicaciones" =ue son usado por ejemplo por -O,8A (-D,)" D-O+ (@D,)" etc. 4rente a esto puede argumentarse =ue a pesar =ue los mensajes SOAP sean muc.o m6s grandes =ue sus e=ui alentes en formato @D, o -D," por estar en formato *+$ o sea AS-II" =ue esta desmejora de la performance es insignificante en el caso de aplicaciones sobre internet donde la latencia in.erente a la propia red es muc.o m6s significati a. $o =ue si puede decirse es =ue para una $A@" o lo =ue es lo mismo dentro de una empresa" D-O+" -O,8A o Ka a ,+I tienen una performance mejor / por lo tanto estos protocolos son preferidos para desarrollar en el 6mbito de una $A@ (recordar =ue adem6s no existen los problemas in.erentes a los fire%alls). 2xisten estudios publicados en .ttp>??%%%.t5im.net?paper?soap..tml =ue comparan la performance de SOAP e IIOP. Por ejemplo en el caso local" usando -O,8A?IIOP se logra una mejora de 'M eces =ue usando SOAP. 2sto se da a0n en el caso de usar IIOP sobre <33P 27 Parsing -omo est6 basado en *+$ (formato AS-II) el parsing re=uiere m6s recursos de -P#" =ue otros protocolos basados en formato binario. 37 Mar/alling/;n.ars/alling -omo est6 basado en *+$ (formato AS-II) el mars.alling?unmars.alling recursos de -P#" =ue otros protocolos basados en formatos binarios. !7 Seriali<acin 3odos los datos son serializados / pasados por alor / no por referencia" esto puede pro ocar problemas de sincronizacin si m0ltiples copias de un objeto fuesen pasadas en el mismo momento. %7 Se.$ntica SOAP no define la sem6ntica de los mensajes" lo cual significa =ue la aplicacin cliente / la aplicacin ser idor deben acordar al sem6ntica de los mensajes. re=uiere m6s

16

Interconexin de aplicaciones legadas usando el paradigma de mensajes

1.10 SOAP , las tecnolog=as distri#uidas

SOAP no es comparable a las tecnolog;as de procesamiento distribuido existentes" dado =ue SOAP es un protocolo de comunicacin entre aplicaciones / no es una ar=uitectura distribuida completa" por lo cual arias caracter;sticas de estas ar=uitecturas =uedan fuera del alcance de SOAP" como forma de cumplir con los objeti os de simplicidad / extensibilidad de su dise&o. $a siguiente tabla muestra como se compara SOAP con las caracter;sticas rele antes de las ar=uitecturas distribuidas / como estas se comparan entre s;. :COM >A6A7-MI SOAP ,e=uiere #na ez muc.o obtenida la intercambio referencia a inicial para 8uena un objeto" acti ar / usar el performance. -O,8A objeto remoto. 4unciona $a performance es baja" debido a =ue se permite una #na ez 0nicamente para debe extraer el mensaje SOAP" .acer el comunicacin obtenida la el lenguaje Ka a parsing de *+$" crear los objetos directa" por lo referencia al / por lo tanto la apropiados / con ertir los par6metros. cual la objeto remoto" performance est6 comunicacin es posible optimizada. es mu/ acceder en r6pida. forma directa al objeto. $a especificacin de SOAP no establece +u/ flexible" nada al respecto" sin embargo si se utiliza Orientado a la pro ee subH <33P como protocolo de transporte" este conexin / Steteful. protocolos re=uiere una ar=uitectura stateless" la cual steteful. stateless / puede no ser apropiada en todas las stateful. circustancias. -O,8A no establece el manejo distribuido de memoria" Pro ee un Pro ee de un $a especificacin de SOAP no establece aun=ue mecanismo excelente nada al respecto. existen autom6tico. mecanismo. implementaci ones dependiendo del fabricante. $a especificacin de SOAP no define -omo Ka a ,+I ninguna caracter;stica de seguridad trabaja con el propia del protocolo SOAP. lenguaje de $a seguridad" por lo menos en alguno de Pro ee soporte programacin sus aspectos" =ueda determinada por el @o pro ee un para Ka a" .ereda los protocolo de transporte =ue se utilice. soporte autentificacin" mecanismos de 3eniendo en cuenta =ue los mensajes intr;nseco autorizacin e seguridad est6 codificados en *+$ / por lo tanto en para identidad. $os existntes en texto" cual=uiera podr;a alterar dic.os autentificaci usuarios Ka a. 2l uso del mensajes. -omo SOAP utiliza <33P n" pueden definir ,+I Securit/ como transporte puede utilizar cual=uier autorizacin o el ni el +anager .abilita caracter;stica de seguridad est6ndard de identidad. apropiado de la carg din6mica <33P. Pueden usarse los mecanismos de seguridad. de clases / por lo autenticacin o bien canales seguros de tanto pro ee comunicaciones (SS$ / <33PS). seguridad adicional. CO-+A

Seguridad

?ar#age collection

Mane o del 'stado

Per1or.ance

17

Interconexin de aplicaciones legadas usando el paradigma de mensajes

Otros aspectos de seguridad pueden implementarse .aciendo uso de usa de .eaders espec;ficos de los mensajes SOAP como ser el .eader SOAPA-3IO@ puede ser usado por los fire%alls para filtrar los mensajes. 0ransaccionalConte@to

$a especificacin de SOAP no establece nada al respecto.

Acti(acin -e1erenciaO# etos )or

$a especificacin del protocolo SOAP deja expresamente de lado este tema" dado =ue se re=uiere Aarbage collection

$a especificacin del protocolo SOAP deja expresamente de lado este tema" dado =ue re=uiere objetos por referencia

2n conclusin SOAP no define o deja expresamente de lado ciertas caracter;sticas de las ar=uitecturas distribuidas con la finalidad de mantener los objeti os de su dise&o de ser un protocolo simple / extensible. Sin embargo puede obser arse =ue SOAP no tiene por finalidad sustituir las tecnolog;as de procesamiento distribuido existentes sino brindar interoperabilidad en un entorno .eterogeneo" donde presenta caracter;sticas =ue lo .acen sumamente 0til frente a las limitaciones de otras tecnolog;as. Por lo tanto es posible =ue los sistemas distribuidos existentes de una organizacin o los desarrollos de nue os sistemas sean expuestos a todos a=uellos clientes =ue soporten SOAP.

18

Interconexin de aplicaciones legadas usando el paradigma de mensajes

2 AA'BO 7 APAC*' SOAP

Apac.e SOAP es una implementacin openHsource de la especificacin SOAP '.' en Ka a de Apac.e Soft%are 4oundation. Se basa en la implementacin SOAPNK" la cual fue donada por I8+ a Apac.e. Apac.e SOAP puede ser usado como un librer;a cliente para in ocar ser icios SOAP disponibles en alg0n lugar o como .erramienta para implementar ser icios SOAP en ser idores. -omo librer;a cliente pro ee una API para in ocar ser icios usando ,P-" as; como una API para en iar / recibir mensajes. -omo .erramienta para escribir nue os ser icios accesibles a tra 7s de ,P- o a tra 7s de mensajes" re=uiere de un !28 Application Ser er" =ue soporte ser lets / Ka a Ser er Pages (KSP)" =ue la contenga. $a siguiente figura muestra la ar=uitectura de un sistema distribuido usando APA-<2 SOAP>

A1=,.9.,N> C=,)>-) :)+1;)+-9 SOAP =,*:9:( ,>M/.9.,N> P9:+,>C %ML SOAP :)L;)+- HBTTP POSTI R)'/-) S):M,.) :)C,+-:( SOAP L,*:9:( P9:+,>C %ML A7',>,+-:9.,N> C=,)>-)+

SOAP :)+1/>+) HBTTPI

SOAP L,+-)>): H+):M=)-I PEB +):M): :)+1;)+-9 S):M,7/: A1=,.9.,/>)+ ,>M/.9.,N>

Interconexin de aplicaciones legadas usando el paradigma de mensajes

2.1 Instalacin
@otas Se asume =ue la instalacin se realiza en ambiente !indo%s. Sino se debe cambiar FOG por F?G. Se debe tener instalado Ka a" en caso contrario> o Do%nload la distribucin o Instalar en el directorio xxxOjd5'.9.' Do%nload de la distribucin binaria de Apac.e SOAP ersin :.: (0ltima ersin disponible). 2xtraer el contenido del arc.i o anterior en el directorio xxx. $os arc.i os de la distribucin =uedan bajo el directorio xxxOsoapH:P:. Para el cliente se necesita> Soa). ar" se encuentra en xxxOsoapH:P:OlibOsoap.jar Do%nload de .ail. ar desde Ka a+ail Do%nload de acti(ation. ar desde Ka a8eans Acti ation 4rame%or5 #n parser de *+$ =ue sea compatible con KA*P / namespaceHa%are. Por ejemplo Apac.e *erces ( ersin '.'.: en adelante).

2xtraer los contenidos de los arc.i os anteriores en el directorio xxx. $os arc.i os de las distintas distribuciones =uedan en los directorios xxxOja amailH'.: xxxOjafH'.1.' xxxOxercesH'PNP' respecti amente. Agregar a la ariable -$ASSPA3< los jar anteriores> o o o o xxxOja amailH'.:Omail.jar xxxOsoapH:P:OlibOsoap.jar xxxOxercesH'PNP'Oxerces.jar xxxOjafH'.1.'Oacti ation.jar

@ota> Si se encuentra instalado en el e=uipo otro parser de *+$ =ue no cumpla las especificaciones mencionadas anteriormente / el mismo se encuentra en la ariable -$ASSPA3<" entonces el parser Apac.e *erces debe aparecer al principio de la arible -$ASSPA3<" sino Apac.e SOAP no funcionr6 correctamente. 2l ser idor SOAP de APA-<2 re=uiere un ser idor !28 =ue soporte ser lets / KSP(Ka a Ser er Pages)" en particular se puede utilizar Apac.e 3omcat. Para el parsing de los mensajes en formato *+$ es posible utilizar cual=uier parser =ue soporte DO+ le el : namespace support" en particular es posible usar *erces de APA-<2.

2!

Interconexin de aplicaciones legadas usando el paradigma de mensajes

2.2 Berces
T0) %):.)+ 1:/J).- 1:/M,7)+ %ML 19:+):+ Q/: 9 M9:,)-( /Q =9>C;9C)+D ,>.=;7,>C J9M9D CRR 9>7 P):=. T0) P):= *,>7,>C+ 9:) *9+)7 /> -0) CRR +/;:.)+. T0):) 9:) T.= *,>7,>C+ Q/: %):.)+ ,> -0) 2.! M):+,/> /Q T.=%MLD *( S-)M) B9==. T0,+ 2.! M):+,/> ,+ />=( 9M9,=9*=) 9- -0) '/')>- -0:; AJ;*9 CVS :)1/+,-/:(. A %ML 19:+): ,+ 9 -//= ;+)7 Q/: 1:/C:9'9-,. 9..)++ -/ %ML 7/.;')>-+. T0,+ ,+ 9 7)+.:,1-,/> /Q -0) +-9>79:7+ +;11/:-)7 *( %):.)+2 DOM2 DOM +-9>7+ Q/: D/.;')>- O*J).- M/7)=. %ML 7/.;')>-+ 9:) 0,):9:.0,.9= *( >9-;:) H>)+-)7 -9C+I. %ML 7/.;')>-+ .9> *) 9..)++)7 -0:; 9 -:)) =,S) ,>-):Q9.). T0) 1:/.)++ ,+ 9+ Q/==/&2 P9:+) 7/.;')> B;,=7 -:)) 97737)=)-)3'/7,Q( >/7)+ S):,9=,O) -:)) SA%2S,'1=) API Q/: %ML. T0,+ ,+ 9 +-:)9' *9+)7 API. T0,+ ')9>+ -09- &) &,== :).),M) .9==*9.S+ 9+ )=)')>-+ 9:) )>./;>-):)7. T0)+) .9==*9.S+ .9> *) ;+)7 -/ ./>+-:;.- 9 DOM -:)) Q/: )<9'1=). %ML N9')+19.)+ %ML S.0)'92 T0) %ML +-9>79:7 1:/M,7)+ -0) +(>-9< Q/: &:,-,>C 7/.;')>-+. %ML S.0)'9 1:/M,7)+ -0) -//=+ Q/: 7)Q,>,>C -0) con#en#s /Q -0) %ML 7/.;')>- H+)'9>-,.+I. I- 9==/&+ -/ 7)Q,>) -09- 9 .):-9,> )=)')>- ,> -0) 7/.;')>- ';+- *) 9> ,>-)C): *)-&))> 1! 9>7 2!D )-.. T0) %):.)+ %ML 1:/J).- ,>,-,9= ./7) *9+) &9+ 7/>9-)7 *( IBM. "/; .9> Q,>7 '/:) ,>Q/:'9-,/> ,> -0) %):.)+ J9M9D %):.)+ C 9>7 %):.)+ P):= 0/')19C)+.

21