-
S.E.P. S.E.I.T. D.G.1.T
CENTRO NACIONAL DE INVESTIGACIÓN Y DESARROLLO TECNOL~GICO
cenidet PLATAFORMA DE SOPORTE PARA LA INTEGRACIÓN DE SERVICIOS
WEB
T E S I S PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS
EN CIENCIAS DE LA COMPUTACIÓN
P R E S E N T A MARIA GUADALUPE VILLANUEVA CARRASCO
Director de Tesis Dr. VíCTOR JESÚS SOSA SOSA
Co-Director de Tesis M.C. JUAN GABRIEL G6NZALEZ SERNA
CUERNAVACA, MORELOS DICIEMBRE 2003
CENTRO DE INFORMAClON DG'Tl SEP CENIDET 0 3 - 0 7 4 s
-
Jt Díus Pur camiizar sieMpre a M i fadu
Jt wis padres h i s y ~uaáafupe Pur su amur iimwiiciuflaf
Jt M í s herMams Sifvia, 8ereizice y Erasmu
Pur ser mi famiíia
Jt wisubríflu Xuis Eduatdu
Pur regafarm esa suiztisa que me iizspiraba cada día
JI tudus queffus que han cregu y cunfidu en mi
-
FORMULARIO C3 REVISIdN DE TESIS I
cenidet
Cuemavaca, Mor., a 2 de diciembre de 2003.
Dr. Gerard0 Reyes Salgado Presidente de la Academia de Ciencias
Computacionales Presente
Nos es grato comunicarle. que confotme a los lineamientos para
la obtención del grado de Maestro en Ciencias de este Centro, y
después de haber sometido a revisión académica la tesis denominada:
Plataforma de Soporte para la Integración de Servicios Web,
realizada por ei(ia) C. Mana Guadalupe Villanueva Carrasco, y
habiendo realizado las correcciones que le fueron indicadas,
acordarnos no tener objeción para que se le conceda la autorización
de impresión de la tesis.
Sin otro particular, quedamos de usted.
Atentamente
La comisión de revisión de tesis
CC. d - , . ~ k * n . M.C. Mano Guillén Rodriguez M.C. Josd
Antoblio Zarate Marceleño
. . ~ --+J,J¿¿J. ~.~ ~~ .
.Dr. Vi r Jesús Sosa Sosa #Director de tesis
M.C. Juan G a b 2 GoEález Sema Codirector de tesis
C.C.P. Dr. Rodolfo A. Pazos Rangel, Jefe del Depto. de Ciencias
Cornputacionales. Lic. Ohia Maquinay Díaz, Jefe del Depto. de
Servicios Escolares. C. María Guadalupe Villanueva Carrasco, alumno
del programa de maestría.
INTERIOR INTERNADO PALMIRA S/N. C O L . PALMIRA , A.P. 5-164. C
P . 62490. C U E R N A V A C A , M O R . - M E X I C O TELS. (777)
312 23 14.318 77 41. FAX (777) 312 24 34 EMAIL
pazos~sd-cenidet.com.mx
-
Agradecimientos Quiero expresar mi más sincero agradecimiento a
todos aquellos que han creído
en mi y que de alguna manera hicieron posible que este trabajo
se realizara.
AI Centro Nacional de Investigación y Desarrollo,Tecnológico por
ser mi casa de estudio y por todo lo que en sus aulas y fuera de
ellas aprendí.
A Cosnet y CEP por aportar los recursos económicos,
contribuyendo enormemente a que este trabajo fuera posible.
A mi director, el Dr. Victor Jesús Sosa Sosa y mi codirector, el
M.C. Gabriel González Serna por sus contribuciones siempre
acertadas, y el apoyo que siempre me brindaron.
A mis profesores que supieron transmitirme su experiencia y
conocimientos en las aulas, proporcionándome las bases necesarias
para realizar este trabajo.
A mis revisores por el tiempo dedicado a analizar este trabajo y
por sus acertadas observaciones, que hicieron posible
mejorarlo.
A mi familia y a la Sra. Virginia por su apoyo
incondicional.
A Anita, la Sra. Adelina, la Lic. Obvia, a Irma, a Gerard0 y a
todo el personal que siempre fue tan amable.
A todos mis compañeros del área de distribuidos que compartieron
conmigo no sólo un laboratorio sino también la alegría y el reto de
trabajar en equipo.
A Raúl por creer en mi y enseñarme a disfrutar cada momento como
si fuera el Último de mi vida.
A todos mis compañeros de generación, Alo, Leo, Juan José,
Armando, Nubia, Roberto, Jesus, Emilio, Vianey, Edgardo, César,
Maricela, Yanet, Rosario, Mario y Sele que al igual que yo vivieron
esta gran aventura.
A mis amigos, ya que cada uno de ellos no sólo compartió conmigo
una maestría. sino que me brindó su valiosa amistad.
A Sele. por todos los cafés que compartimos y por ser mi
cómplice en las aventuras que emprendimos. A César, por que con él,
amplié mi criterio y me hizo volver a reír. A Emilio, que aunque
casi no hablaba, cuando lo hacía era contundente. A Alonso, por su
siempre disposición. A Leo, por demostrarnos que podemos disfrutar
los sabores al máximo. A Mari, por sus acertados consejos y sus
asesorías. A Rosario, porque a pesar de todo, hicimos un buen
equipo. A Erika, por apoyarme incondicionalmente.
A todos, muchas gracias.
-
TA'BLA DE CONTENIDO
Dedicatorias
............................................................................
Agradecimientos
.......................................................................
Tabla de Contenido
....................................................................
Lista de Figuras
........................................................................
Lista de Tablas
.........................................................................
Resumen
..................................................................................
. .
1 . INTRODUCCION
...................................................................
1 . 1. Antecedentes
..................................................................
1.2. Planteamiento del Problema
............................................ 1.3. Objetivo de la
Tesis .........................................................
1.4. Organización de la Tesis
................................................
2 . MARCO TEóRiCO
.................................................................
2.1. Sistemas distribuidos ... ....... .................. 2.2.
Arquitectura de los sistemas distribuidos .....................
2.2.1. Modelo Cliente-Servidor
............................................. 2.2.2. Servidores
proxy y cachés ..........................................
2.4. Servicios Web
.................................................................
2.4.1, Arquitectura orientada a servicios
...............................
2.5. Tecnologías asociada a los servicios web . . 2.5.1.
Lenguaje de marcado XML ............. 2.5.2. Lenguaje de
Descripción de Servicios Web .... . . . . . . . . . . . . . .
2.3. Aplicaciones Middleware .......................
................ . .
............... ..............
2.5.3. Protocolo SOAP
........................................................ 2.5.4.
Repositorios de Documentos WSDL ............................
2.5.4.1. UDDI ................................
................... . . . . . 2.5.4.2. ebXML
................................................................
... 111
iv V
viii X
xi
10
11
12 12
13 14 16 17 20
20
21 24 21
2 1
21
V
-
I
1 3 . ESTADO DEL ARTE
.............................................................. 3 .
1 . Tecnologia Microsoft .NET
..............................................
3.1.1. .NET Framework
...................................................... 3.1.2.
Lenguaje Común en Tiempo de Ejecución (CLR) . . . . . . . . . 3.1 .
3. Biblioteca de Clases
..................................................
3.2. Web Service Invocation Framework (WSIF)
....................... 3.3. Proyecto Axis
..................................................................
3.4. JWSDP (Java Web Service Developer Package)
................
3.4.1. Java API for XML Processing (JAXP)
.......................... 3.4.2. Java API for XML-based RPC
(JAX-RPC) .................... 3.4.3. Java API for XML Messaging
(JAXM) .......................... 3.4.4. Java API for XML
Registries (JAXR) .......................... 3.4.5. XML Stylesheet
Language for Transformations (XSLT) .
4 . DISENO DE LA PLATAFORMA
.............................................. . . 4.1 . Diseño
Arquitectonico
.............................................................................
4.2. Diseño Conceptual
..................................................................................
4.2.1 . Diagrama de Casos de Uso
........................................................... 4.2.2.
Escenarios de Uso .................
...................................... 4.2.3. Diagramas de
Actividad .....................................
..........................
4.2.3.1. Proceso de Registro de Servicios
............................. 4.2.3.2. Proceso de Invocación de un
Servicio ......................................
4.2.4. Modelo General de la Plataforma
..................................................... 4.3. Módulos
de la Plataforma
........................................................................
4.3.1 . Módulo Servidor de Peticiones
........................................... 4.3.2. Módulo
Analizador de Documentos WSDL ......... .........................
4.3.3. Módulo de Registro de Servicios Web
.............................................. 4.3.4. Módulo de
Página Amarilla de Servicios Web ..................................
4.3.5. Módulo de Búsqueda de Servicios Web ...................
4.3.6. Módulo de Invocación de Servicios Web
.......................................... 4.3.7. Módulo de
Integración de Servicios Web
.........................................
29
30
30 31 32 33 35
36 37 38
39 39 40
41
42 43 43
45 49 50 50 52 52 52 53 53
53 53
54 54
vi
-
5 . I M P L E M E N T A C I ~ N
.......................................................... 5.1.
Metodología de desarrollo ........................... 5.2.
Implementación de módulos .................
.................. ........................
5.2.1. Paquetes desarrollados
............................................. 5.2.2. Descripción de
los Módulos ......................
5.2.2.1. Módulo Servidor de Peticiones
............................. 5.2.2.2. Módulo Analizador de
Documentos WSDL ............. 5.2.2.3. Módulo de Registro de
Servicios Web ...................
I
5.2.2.4. Módulo de Página Amarilla de Servicios Web ........
5.2.2.5. Módulo de Búsqueda de Servicios Web ...... 5.2.2.6. Módulo
de Invocación de Servicios Web ................ 5.2.2.7. Módulo de
Integración de Servicios Web ...............
5.3.1. Java Server Page (JSP)
............................................. 5.3.2. Java JAXP
.................................. ..........................
5.3. Tecnologías uti l izadas
...................................
6 . PRUEBAS
............................................................................
6.1. Herramientas uti l izadas
...................................................
6.1 . 1. Servidor de Aplicaciones Apache Tomcat
.................... 6.1.2. Servidor Web Internet Information
Server (11s) ............. 6.1.3. .NET Framework
.......................................................
6.2. Escenarios de Pruebas
.................................................... 6.3. Plan de
Pruebas
.............................................................. 6.4.
Evaluación Experimental
..................................................
7 . CONCLUSIONES
..................................................................
7.1. Conclusiones
..................................................................
7.2. Beneficios
.......................................................................
7.3. Resultados Obtenidos
...................................................... 7.4.
Trabajos Futuros
.............................................................
Referencias
.............................................................................
. .
55
56
57 57 60 60 61
61 61
62 62 63 64 64
64
66
67 67 68 69 69 70 71
88
89
90 91 92 93
vii
-
LISTA DE FIGURAS
Fig. 1.1.
Fig. 1.2. Una in t ranet t ip ica
F ig . 1 . 3 .
Fig. 2 . 1 . Modelo Cl iente - Servidor
Fig. 2.2. Servidor proxy
Fig. 2 .3 .
Fig. 2 .4 .
Fig. 2.5
Fig. 2.6.
Fig. 3 . l .
Fig. 3.2.
F ig . 3.3.
Fig. 3 .4 .
~ i ~ , 4.1,
~ i ~ , 4.2.
Fig. 4 .3 .
~ i ~ , 4 .4 ,
Fig. 4.5.
F ig . 5 . ’ .
Fig. 5.2.
F ig . 5 .3 ,
Fig. 5 . 4 .
Fig. 5 . 5 .
Fig. 5 .6 .
~ i ~ , 5.7,
~ i ~ . 5.8.
Una porc ión t ip ica de Internet
Pet ic ión HTTP en u n mqdelo Cl iente I Servidor
Capas de sof tware y hardware en sistemas d is t r ibu idos
Arquitectura Orientada a Servicios
Estructura de u n documentos WSDL
Estructura de u n mensaje SOAP
Componentes de Microsof t .NET
Axis e jecutándose en un servidor de ap l i cac iones Tomcat
Serv ic io basado en JAX-RPC en t iempo de ejecución
Arqui tectura de la API JAXR
Arqui tectura de la p lataforma de soporte de in tegración de
servicios web Diagrama de casos de uso de la p lataforma de soporte
d e in tegración de servicios web Diagrama de act iv idad del
proceso de regis t ro de un servicio
Diagrama de act iv idad del proceso de invocación de un serv ic
io
Modelo pr incipal de la p lataforma
Clases del paquete servidor
Diagrama de c lases del paquete servidor
Clases del paquete intserweb
Diagrama de c lases del paquete intserweb
Clases del paquete wsd i
Diagrama de c lases del paquete wsdl
In teracción entre las di ferentes capas e n el módu lo de regis
t ro de serv ic ios web Interacción entre las di ferentes capas en
e l módulo de página amar i l la
... V l l l
3
4
5
12
13
14
17
23
25
31
36
38
40
43
44
50
51
52
57
58
58
59
59
60
61
62
-
Fig. 5 .9 .
Fig. 5.10.
Fig. 5 .11
Fig. 6.1.
F ig. 6.2.
Fig. 6.3.
Fig. 6.4.
F ig. 6.5.
Fig. 6.6.
Fig. 6 .7 .
Fig. 6.8.
F ig. 6 .9 .
F ig. 6.10.
Fig. 6.11.
Fig. 6.12.
Fig. 6 .13 .
Fig. 6.14.
Fig. 6 . 1 5 .
F ig. 6.16.
Fig. 6 .17.
F ig. 6.18.
Fig. 6 .19.
Fig. 6.20.
Fig. 6.21.
F ig. 6 .22.
I Interacción entre las di ferentes capas en e l módulo de
búsqueda de servic ios we6 Interacción entre ¡as di ferentes capas
en e l móduio de invocación de servic ios web Interacción entre las
di ferentes capas en e l módulo de integración de servic ios
web.
Estructura de director io de l servidor Apache Tomcat
Escenario de prueba 1
Escenar io de prueba 2
Inic ial ización del Servidor de pet ic iones
Conf iguración del Navegador
Sol ic i tud de servic ios disponibles dentro de la ln t
ranet
Pagina de reg is t ro de servic ios
Página de conf i rmación de registro de un servic io en una
nueva categor ía Página de conf i rmación de registro de un servic
io en una categoría existente Página de aviso de que un servic io
que se intenta registrar ya existe
Página para la el iminación del registro de un servic io
Página para ¡a actual ización de una categor ia
Página para la el iminación de una categoría
Página de búsqueda de servic ios
Página de resul tados de una búsqueda de Servicios página de
resul tados de una búsqueda de Servicios sin coincidencias Página
amari l la de servic ios registrados
Selección de un servic io o categoría a invocar
se lecc ión de un método U operación disponible de l servic
io
62
63
63
68
69
70
71
71
72
73
74
74
75
76
77
79
80
81
82
83
84
84
Introducción de los parámetros requeridos para la ejecución de
84 una operación Resul tados de un servic io de una categoría con
un solo 85 servic io Resul tados de la integración de los servic
ios de una categor ia 87
ix
-
LISTA DE TABLAS
Tabla 2.1.
Tabla 2.2.
Tabla 2.3.
Tabla 6 .1 . Plan de pruebas
Tecnologías ut i l izadas en los middleware Protocolos y
tecnologías ut i l izadas en serv ic ios web
Mensajes SOAP de sol ic i tud y respuesta de un serv ic io
web
15
19
26 70
X
-
RESUMEN
El crecimiento acelerado de la información y aplicaciones
disponibles en la Web; así como el uso de la Internet ha permitido
a un gran número de usuarios tener acceso a una vasta cantidad de
información y aplicaciones. Sin embargo, el volumen de información
y servicios es tan amplio que resulta dificil explotarlos de manera
eficiente; además de que muchas de las aplicaciones que se han
desarrollado no fueron diseñadas originalmente para el Web.
Este trabajo describe una plataforma que permite integrar
aplicaciones implementadas en plataformas heterogéneas pero que
pueden ser accedidas via Internet. Esta plataforma proporciona a
los usuarios que acceden a Internet via un proxy la posibilidad de
acceder a éstas aplicaciones de manera transparente e integrar
resultados procedentes de aplicaciones comunes.
La plataforma ofrece la posibilidad a los proveedores de
servicios o desarrolladores de publicar sus aplicaciones; así como
a los consumidores o clientes de localizar y utilizar estas
aplicaciones, sin considerar la plataforma bajo la cual éstas
fueron desarrolladas.
También se describen brevemente las tecnologias que han surgido
como propuestas para crear estándares en el desarrollo de
aplicaciones distribuidas y para facilitar la integración de las
mismas. Una de éstas propuestas, resultante de la necesidad de
crear aplicaciones distribuidas que crucen las fronteras entre las
plataformas en que las aplicaciones se desarrollan son los
servicios web, es por ello que se han considerado dentro de esta
plataforma como una parte importante en la integración de
aplicaciones, sin dejar de tomar en cuenta a aquellas aplicaciones
que no se basan en la tecnología reciente de servicios web, pero
que conforman la gran parte de aplicaciones disponibles que
requieren ser publicadas
dentro de un directorio de servicios.
xi
-
..-L . . .. . .
I N T R O D U C C I ~ N CAPiTULO 1
CAPÍTULO 1 !
En este capitulo nos situaremos en el contexto de este
trabajo
de tesis, revisando los antecedentes, la problemática, el
objetivo y los alcances de la tesis, así como la organización del
documento.
1
-
I N T R O D U C C I ~ N CAPiTULO 1
1.1. ANTECEDENTES
Debido a la evolución que han tenido el uso de las redes, se
ha
dado la posibilidad de desarrollar sistemas cada vez más
complejos
como lo son los sistemas distribuidos.
Un sistema distribuido es aquel en el que los componentes (tanto
de
hardware como de software) están localizados en computadores
conectados en red que se comunican y coordinan únicamente
mediante el paso de mensajes[ l ] .
Un ejemplo muy claro de un sistema distribuido es la Internet,
la cual
es una red computacional que conecta a millones de
computadoras
de diferentes países. Sin embargo, no existe una autoridad
central
que controle la Internet y por otro lado existen varias
organizaciones
que administran diferentes partes de la Internet. La Internet
fue
creada por la Agencia de Proyectos de Investigación Avanzada
(ARPA, Advanced Research Projects Agency) del gobierno de los
Estados Unidos en los 60's. La Internet permite a los usuarios,
donde
quiera que ellos se localicen, hacer uso de servicios tales como
la
WWW (World Wide Web, mejor conocida como la Web), e l correo
electrónico y la transferencia de archivos. La figura 1.1. nos
muestra un ejemplo de una porción de Internet.
La figura nos muestra una colección de intranets (subredes
operadas por compañías y otras organizaciones). Los proveedores de
servicios
de Internet (ISPs, Internet Service Providers) son compañías
que
proporcionan enlaces de modem u otros tipos de conexiones a
usuarios individuales y pequeñas organizaciones, permitiéndoles
acceder a los servicios disponibles en cualquier parte de la
Internet
-
INTRODUCCIÓN I C A P ~ T U L O 1
así como también de proporcionar servicios locales tales como
correo
electrónico y hospedaje web (web hosting). I
1 RJ6 Computadora I Servidor I
Enlace de red
Fig 1 .l. Una porción típica de net
Como se puede observar en la figura anterior una Intranet
puede
formar parte de la Internet y ser administrada de forma
separada, ya
que tiene límites que pueden ser configurados para reforzar las
políticas de seguridad local. La configuración de una intranet
en
particular es responsabil idad de la organización que la
administra.
La figura 1.2. nos muestra una intranet típica, la cual puede
estar compuesta de varias redes locales enlazadas mediante
conexiones
backbone. Un backbone es un enlace de red con una capacidad
de
3
-
C A P ~ T U L O I INTRODUCCIÓN
transmisión alta, que puede emplear conexiones satelitales,
cables de
fibra óptica y otros circuitos de ancho de banda altos.
Otros Servidores
Fig. 1.2. Una intranet tipica
Por otro lado tenemos la World Wide Web, (WWW o "Web") se
refiere
a esas computadoras conectadas a la Internet que pueden
comunicarse entre s i util izando un protocolo llamado HTTP'[2].
Todos
los navegadores utilizan el HTTP para solicitar y recibir
páginas web de otras cornputadoras'
La Web es un sistema desarrollado para publicar y acceder
recursos y servicios a traves de la Internet. Comúnmente el
software disponible en los navegadores web tales como Netscape e
Internet Explorer permiten a los usuarios recuperar y visualizar
documentos
de muchos tipos, escuchar audio, visualizar video e interactuar
con
un ilimitado conjunto de servicios.
Hypertext Transfer Protocol, Protocolo de Transferencia de
hiperiexto. En muchas ocasiones, la Web es incorrectamente
confundido con la Internet.
I
2
4
-
.APíTULO 1 I N T R O D U C C I ~ N
.a Web comenzó a desarrollarse en el Centro Europeo de
nvestigación Nuclear (CERN, European Centre for Nuclear
lesearch), en Suiza en 1989 como un medio para intercambiar
locumentos entre una comunidad de físicos, conectados mediante
la
nternet. Una característica clave de la Web es que proporciona
una
istructura hipertexto entre los documentos que están
almacenados.
isto signif ica que los documentos contienen enlaces o
referencias a itros documentos y recursos que también se
encuentran
ilmacenados en la Web, por lo que permite pasar de uno a otro en
el
irden que se desee.
.a figura 1.3. nos muestra los elementos principales que
componen
ina petición con el protocolo HTTP a un servidor web en una
modelo
Zliente / Servidor
Solicitud HTTP Solicitud HTTP
Página HTML Página HTML
avegadores (Clientes) Estilo hipeneno
SeNldOr Web
Fig. 1.3. Petición HTTP en un modelo Cliente / Servidor
:om0 podemos observar en la figura existen tres elementos ir
incipales dentro una petición a un servidor web, los cuales son: a)
:I servidor web, e l cual es un programa ejecutándose en una
:omputadora conectada a una red que acepta solicitudes HTTP
desde
)tras computadoras l lamadas clientes; procesa la solicitud y
devuelve a respuesta de dicha solicitud en forma de una página HTML
a quien a realizó; b) El Cliente es aquel que envía una solicitud
mediante el Irotocolo HTTP, normalmente a través de un navegador,
para que el
-
5
-
C A P ~ T U L O I INTRODUCCIÓN
servidor realice una operación y espera una respuesta del mismo;
y
c) La red que es el medio físico por donde viajan los mensajes
de solicitud y respuesta enviados del cliente al servidor y
viceversa.
Dentro de la Web han aparecido tecnologías para el desarrollo
de
aplicaciones tanto del lado del cliente como del lado del
servidor. Las
tecnologías han permitido crear aplicaciones que pueden ser
accedidas por un navegador desde cualquier parte donde se
tenga
acceso a la Internet. Las tecnologías han evolucionado de
manera
significante logrando así no sólo proporcionar páginas
estáticas
almacenadas en los servidores web sino también la generación
de
páginas dinámicas y una interacción mayor entre el cl iente y
el
servidor.
Por otro lado, e l uso de la programación orientada a objetos
también
ha contribuido enormemente a la evolución de las
aplicaciones
disponibles en la Web; puesto que sus conceptos han sido uti l
izados para crear componentes de software reutilizables cada vez
más
confiables. Algunas de éstas son tecnologías como RM1[3],
CORBA[4], DCOM y servicios web.
1.2. PLANTEAMIENTO DEL PROBLEMA
El crecimiento acelerado de la información y aplicaciones
disponibles en la Web; as¡ como el uso de la Internet, ha permitido
a un gran número de usuarios tener acceso a una vasta cantidad de
información y aplicaciones. Sin embargo, el volumen de información
y
aplicaciones es tan amplio que resulta difícil localizarlos y
explotarlos de manera eficiente.
6
-
CAPiTULO 1 INTRODUCCIÓN
Por otra parte el desarrollo de aplicaciones ha pasado por una
serie
de etapas evolutivas que han generado una cantidad de software
bajo
diferentes plataformas y diferentes lenguajes de programación,
que
ahora resulta difícil que éstas interactúen de forma fácil y
transparente.
Debido a la heterogeneidad de los elementos que forman parte del
desarrollo de las aplicaciones distribuidas, heterogeneidad en
redes,
hardware, sistemas operativos, lenguajes de programación e
implementaciones; surgen una serie de consideraciones para que
éstas puedan interactuar sin sufrir cambios significativos;
puesto que
la comunicación entre aplicaciones heterogéneas puede resultar
un
proceso complejo sin los estándares que regularicen y facil i
ten este
intercambio de información.
La necesidad tanto de los proveedores de servicios de hacer
disponibles sus aplicaciones y que éstas puedan ser uti l izadas
de
una forma fácil; y la de los consumidores de localizar y util
izar las aplicaciones sin tener que preocuparse por la plataforma
en que
fueron desarrollados ha dado una razón suficiente para la
realización
de este trabajo de tesis.
1.3. OBJETIVO DE LA TESIS
Para resolver el problema planteado se propone implementar
una plataforma que permita hacer más disponibles a los
usuarios
finales muchos servicios que se ofrecen en la Internet. mediante
una infraestructura que permita localizar e invocar los servicios
existentes.
-
C A P ~ T U L O I I N T R O D U C C I ~ N
Para ello se propone desarrollar un directorio de servicios que
nos
permita registrar los servicios y un módulo que integre los
resultados obtenidos de servicios con características
similares.
Además que se propone implementar un intermediario que facilite
la
localización tanto del directorio de servicios como de un
servicio en
particular a los usuarios que tengan acceso a la Internet a
través de
este intermediario.
1.4. ORGANIZACIdN DE LA TESIS
La tesis se organiza en los siguiente capítulos:
Capítulo 1. Se presenta una introducción para entrar en contexto
en
el cual se desarrolló esta tesis, definiendo además el
planteamiento
del problema, el objetivo y los alcances de la misma.
Capítulo 2. Se hace un recorrido por los diferentes conceptos y
tecnologías involucradas en el proceso de desarrollo de
aplicaciones
distribuidas que fueron analizadas para el desarrollo de la
plataforma.
Capitulo 3. Se describen brevemente los trabajos realizados
sobre
servicios web en cuanto a la integración de aplicaciones
heterogéneas.
Capítulo 4 . Se describe el proceso de diseño de la
plataforma,
definición de los elementos que la conforman; así como los
diferentes escenarios en los cuales la plataforma es utilizada.
8
-
CAPíTULO 1 I N T R O D U C C I ~ N
Capítulo 5. Se presenta la descripción del proceso de codif
icación de
la plataforma, incluyendo las aplicaciones y APls uti l izadas
para el desarrollo de la misma.
Capítulo 6. Se muestran los resultados obtenidos en las
pruebas
realizadas con la plataforma, en los cuales podemos observar que
se cumplió el objetivo de este trabajo de tesis.
Capítulo 7 . Se presentan las conclusiones, así como los
beneficios obtenidos con la plataforma desarrollada y los trabajos
futuros que podrían aportar continuidad a este trabajo de
investigación
9
-
MARCO TEÓRICO CAPITULO z
CAPÍTULO 2 MARCO TEÓRICO
En este capítulo se describen los diferentes conceptos y
tecnologías involucradas en el proceso de desarrollo de
aplicaciones
distribuidas que fueron analizadas para el desarrollo de la
plataforma.
10
-
CAPITULO 2 MARCO TEÓRICO
2.1. SISTEMAS DISTRIBUIDOS
Un sistema distribuido es aquel en el que los componentes (tanto
de hardware como de software) están localizados en
computadores conectados en red que se comunican y coordinan
únicamente mediante el paso de mensajes[5].
Compartir recursos es la principal motivación para
desarrollar
sistemas distribuidos. Los recursos son administrados por
servidores
y accedidos por cl ientes. La Web es un ejemplo claro de un
sistema que comparte una gran cantidad de recursos y la Internet de
un sistema distribuido.
Los retos a los que se enfrentan los sistemas distribuidos son
la
heterogeneidad de sus componentes, la extensibil idad que
permite agregar o eliminar componentes sin afectar el sistema, la
seguridad,
la escalabilidad que permite trabajar bien aún cuando el número
de
usuarios se incremente, e l tratamiento de fallas, la
concurrencia y la transparencia [6].
Dentro de un sistema distribuido podemos compartir todos los
recursos que se encuentren disponibles, tanto de hardware como
de software, tales como impresoras, archivos, páginas web,
aplicaciones. El recurso principal a compartir en este trabajo
son
todos aquellas aplicaciones que sean de uti l idad dentro de una
organización que cuenta con una intranet o red donde los usuarios
tienen acceso a la Internet a través de un intermediario.
0 5 - 0 7 4 3 11
-
C A P ~ T U L O 2 MARCO TEÓRICO
2.2. ARQUITECTURAS DE LOS SISTEMAS DISTRIBUIDOS
La división de responsabilidades entre los componentes de un
sistema distribuido(aplicaciones, servidores y otros procesos) y
la localización de los componentes en las diferentes computadoras
en la
red son quizás los aspectos más evidentes del diseño de sistemas
distribuidos.
En un sistema distribuido, los procesos con responsabil idades
bien definidas interactúan unos con otros para efectuar una
actividad. A continuación describiremos dos de las arquitecturas
más conocidas de los sistemas distribuidos dependiendo de la
localización de los
procesos y las responsabilidades de cada uno de ellos.
2.2.1. Modelo Cliente-Servidor
Esta es quizás la arquitectura más conocida. La figura 2.1. nos
muestra una estructura simple en la cual los procesos de los
clientes interactúan con los procesos de un servidor para acceder a
los recursos compartidos que éstos administran. Para el lo e l cl
iente
envía una solicitud a l servidor para que realice una actividad
y espera
la respuesta emitida por e l servidor una vez que la solicitud
es
procesada.
Fig. 2.1. Modelo Cliente -Servidor
12
-
. . . . . . .. . .
CAPITULO 2 MARCO TEÓRICO
2.2.2. Servidores Proxy y Cachéc
Una caché es un almacén de los objetos de datos usados
recientemente. Cuando un .nuevo objeto es recibido por una
computadora, éste es agregado al. almacén caché,
reemplazando
algunos objetos existentes si es necesario. Cuando un objeto
es
requerido por un proceso cliente el servicio de caching primero
verifica e l caché y si t iene una copia disponible la devuelve al
cliente
que hizo la solicitud. En caso de que el objeto no se encuentre
en la
caché, hace una solicitud al servidor para después devolver
la
respuesta al cl iente y además almacena una copia en la caché.
Las
cachés pueden ser localizadas en cada cliente o en un servidor
proxy
que puede ser compartido por varios clientes. ir
Los servidores proxy proporcionan una ca:ché compartida de
recursos
para las máquinas cliente que tienen acceso a la Internet a
través de
este proxy. El propósito de los servidores proxy es incrementar
la
disponibilidad y rendimiento de los serv i i ios reduciendo la
carga en la red de área amplia y en los serviüores web. Los
servidores proxy
pueden tener otros roles, como por ejemplo pueden ser usados
para
acceder servidores web a través de un firkwall (muralla de
fuego),
I
I
3
Fig. 2.2. Servidor proxy. 3 Un firewall es un mecanismo
utilizado para proteger los datos y las computadoras de usuarios y
programas externos o no autorizados.
13
I
I!
-
C A P ~ T U L O 2 MARCO TEÓRICO - * * 1 ,,. ~ I , . > ":.. .
::i
2.3. A P L I C AC I ON . . ES . M . I D . . . D L E WA R EXi .
.. " , . * ' .t. e' .. , . . .I , .,
El término middleware se apliica. a, la capa .de .software
que
oculta la heterogeneidad I . de las redes,, ,,. hardware,
sistemas.operativos ~. .
y,lenguajes de programación que se encuentran , . debajo de esta
capa,
como .se muestra en la figura 2.3. proporciona un nivel de
abstracción
que resulta en un modelo de programación conveniente a los
p rog ram ad o res de a p I i cac i o n es [ 71.
,. . .
-- .
.. - : ,;B
Fig. 2.3. Capas de software y hardware en sistemas distribuidos
{ ..?
Un middleware proporciona bloques a e .. software establecidos.
para la
construcción de componentes de software que puedan trabajar
con
otros en un sistema distribuido sin tener que preocuparse por
los
detalles' de la comunkación entre aplicaciones, es decir,
proporciona
un nivel de abstracción en actividades tales como ,la invocación
de
métodos remotos, la comunicación entre grupos de procesos,
notif icación de eventos, replicación de datos compartidos y
la
transmisión de datos multimedia en tiempo real.
t !/ ,
. . ,, . J p 7 f . '4
i
I L I. .: . ' >* "L Common Object Request Broker
,Architecture (CORBA), Java Remote
! I .
Object Invocation (RMI),.. Distributed Common Object . . Model
(DCOM)
de Microsoft son algunos ejemplos.de productos middleware. . I \
*
.. , . . .. ' ' , . J
Por ejemplo, CORBA ofrece una variedad de servicios, tales
como:
servicio de nombres, seguridad, transacciones,
almacenamiento
14
http://ejemplos.de
-
CAPiTULO 2 MARCO TEÓRICO
Las arquitecturas RPC, implementadals en tecnologías como DCOM
y
CORBA, permitieron que los programas fueran divididos en
diferentes
piezas ejecutándose en computadoras diferentes. Las técnicas
orientadas a objetos fueron particularmente adecuadas a este
ambiente distribuido, debido a que los objetos mantienen su
propia
identidad y a que el código 'que maneja las comunicaciones
entre
objetos podría ser encapsulado sobre su propio conjunto de
clases,
tal que los programadores trabajarán en un ambiente distribuido
sin
la necesidad de preocuparse de cómo'.trabaja esa
comunicación.
Desafortunadamente, tanto CORBA l o m o DCOM comparten
muchos
de los mismos problemas. DCOM e.si expresamente una
arquitectura
exclusiva de Microsoft, y aunque CO'RBA pretende proporcionar
una
plataforma interoperable, es compleja y semánticamente ambigua
para proporcionar algún nivel de interoperabilidad, implicando
una
gran carga de trabajo de integración manual.
/I
11 .
2.4. SERVICIOS WEB
Debido a los problemas existentes con las tecnologías CORBA y
DCOM, los servicios web señalan un cambio de paradigma en el
cómputo distribuido. Los servicios web tienen el potencial
para
cambiar la forma en que interactúan los sistemas distribuidos,
lo cual afectará fundamentalmente la operación de la Internet.
Un servicio web es cualquier servicio que esté disponible en la
Internet, usando un sistema de intercambio de mensajes
estandarizado XML y que no esté atado a ningún sistema operativo
o lenguaje de programación[8].
16
-
CAPiTULO 2 MARCO TEÓRICO
Definiendo más formalmente un servicio web, es considerado
como
una aplicación que pueden ser descrita, publicada, localizada e
invocada sobre la Internet .O cualquierlotra red.
2.4.1. Arquitectura Orientada a Serviicios I: I
El nuevo concepto de serv:icios web ha originado una
arquitectura, llamada arquitectura orientada a servicios[9]
(SOA,
Service Oriented Architecture). Esta arquitectura define los
elementos
principalmente que intervienen en los servicios web.
~0 f Proveedor 't de Servicios Descripcibn
Registro de Solicitante Servicios del Servicio
Fig. 2.4. Arquitectura Orientada a Servicios (SOA)
Como podemos observar la arquitectura organiza los servicios
web
dentro de tres elementos básicos, los cuales describiremos a
continuación:
II
El proveedor del servicio. Es quien proporciona el servicio, es
decir, implementa el servicio y lo publica haciendolo disponible en
la
Internet, para ello deberá proporcionar un documento de
descripción
del servicio. I El solicitante del servicio. Es el consumidor
que buscará el servicio y una vez localizado lo invocará ai t ravés
de una conexión de red y
I
-
C A P ~ T U L O 2 MARCO TEÓRICO
enviando una solicitud XML, la cual será descrita en el
siguiente capitulo.
I
El r eg i s t ro de serv ic ios . Este es un'idirectorio lógico
centralizado de servicios. Los registros proporcionan un lugar
central dónde los desarrolladores publican sus nuevos' servicios o
encuentran algunos existentes.
Dentro de esta arquitectura también podemos observar que el
documento de descripción del servicio es una pieza clave, ya que
a
través de él, el proveedor publica su servicio para que después
sea
enviado al cliente, dándole de estaj forma la información
necesaria
para invocar el servicio.
8 1
Dentro de la arquitectura de servicios, hay ciertas actividades
que se
llevan a cabo tales como implementación, publicación,
localización e
invocación del.servicio; por lo que se han desarrollado una
serie de
tecnologías que se enfocan en éstas acciones. En los
siguientes
apartados de este capítulo explicaremos algunas de estas
tecnologías.
Implementac ión. Hay dos enfoques para construir un servicio
web: construir uno partiendo desde el principio o proporcionar
una envoltura o API para una aplicación,. o servicio existente para
que se
exponga como un servicio web.
Pub l i cac ión . Consiste en hacer disponible e l servicio,
para ello e l
proveedor deberá proporcionar e l ' documento de descripción del
servicio que desea publicar.
18
-
CAPITULO 2 MARCO TEÓRICO
Local izac ión. Una vez que el servicio se ha publicado,
cualquier
consumidor puede buscar y localizar en los diferentes
repositorios el servicio que requiera y así obtener e l documento
de descripción del
servicio, con la información necesaria para invocarlo.
Actividad Localización Publicación Invocación
Invocac ión . Puede llevarse a cabo directamente con la
información proporcionada en el documento de descripción del
servicio o a través de una aplicación cliente, la cual toma
la
información contenida en este documento y crea un intermediario
que
permita la invocación del servicio.
Protocolo /Tecnología UDDl
WSDL, UDDl XML-RPC, SOAP
Para llevar a cabo estas actividades los servicios web han hecho
uso
de protocolos ya existentes, así como de otros nuevos, la tabla
2.2. nos muestra la pila de algunos protocolos y tecnologías uti l
izadas por los servicios web.
Como se mencionó anteriormente los sistemas distribuidos
cuentan
con arquitecturas donde una solicitud puede ser atendida por uno
o
más servidores, de igual forma, una solicitud puede requerir de
la invocación de más de un servicio, por lo que es indispensable
definir
el mecanismo de comunicación entre aplicaciones.
Los servicios web en su afán de hacer uso de los estándares
ya
definidos o tecnologías en camino a convertirse en estándares,
han optado por util izar e l lenguaje XML para la definición de los
mensajes intercambiados entre aplicaciones.
19
-
MARCO T E ~ R I C O CAPITULO 2
2.5. TECNOLOGíAS ASOCIADA A LOS SERVICIOS WEB
2.5.1. Lenguaje de Marcado XML
La revolución de la información en los Últimos años ha
ocasionado grandes cambios' en la forma en que los datos son
representados, almacenados e intercambiados.
Hasta ahora, hemos mencionado el lenguaje XML[10] como el
adoptado por los servicios web para definir los mensajes que
serán intercambiados entre procesos dentro de un sistema
distribuido, pero
no hemos definido explícitamente que es XML.
XML son las siglas con las que se reconoce al lenguaje de
marcado
extensible (Extensible Markup Language). XML es un
metalenguaje
que define la sintaxis util izada para definir otros lenguajes
de
etiquetas estructurados. La idea básica es que con XML, es
posible
codificar información en un documento de texto, que no sólo
contiene
datos, sino también, contiene información que describe el
significado
de los mismos en una forma estructurada y legible para los
humanos.
XML está basado en un estándar anterior l lamado SGML
(Standard
Generalized Markup Language, IS0 8879). SGML proporciona un modo
consistente y preciso de aplicar etiquetas (marcas) para describir
las partes que componen un documento, permitiendo además el
intercambio de documentos entre diferentes plataformas.
Sin embargo, el problema que se atribuye a SGML es su
excesiva
dificultad por lo que se derivó XML como un subconjunto
simplificado,
eliminando las partes más engorrosas y menos útiles. AI igual
que SGML, el XML es un metalenguaje: es un lenguaje para
definir
20
-
C A P ~ T U L O 2 MARCO TEÓRICO
lenguajes. Los elementos que lo componen pueden dar información
sobre lo que contienen, no necesariamente sobre su estructura
física
o presentación, como ocurre en HTML.
Los servicios web están basados en el lenguaje XML, por lo
que
toman las ventajas que XML ofrece.
2.5.2. Lenguaje de Desc r i pc ión d e Serv ic ios Web
(WSDL)
En el afán de establecer estándares que permitan describir
un
servicio web ha surgido el Lenguaje de Descripción de Servicio
Web
(WSDL) [ I I ] propuesto por IBM y Microsoft a la W3C, que
permite definir las características principales de un servicio web,
las
funciones o métodos disponibles, los parámetros de entrada y
de
salida, así como detalles de implementación que permitan que
estos
métodos sean invocados desde cualquier otra aplicación a través
de
un protocolo de comunicación.
El WSDL está basado en XML, util izando su gramática para
especificar las propiedades de un servicio web, tales como: qué
hace,
dónde está localizado y cómo invocar lo[ l2] . Dentro del
documento
existen tres secciones conceptuales:
1. La parte que nos describe abstractamente al servicio,
definiendo las operaciones que proporciona el servicio, sin incluir
detalles de implementación. Esta parte consta principalmente de
tres elementos
o etiquetas:
. En
o compuestos
intercambiados
esta sección se definen los tipos de datos complejos
que serán uti l izados dentro de los mensajes
entre e l servidor y el cliente. Esta sección podría no
L1
"""I ISEP CENIDET --. - 7 n n n c I h i E n D h A A T i n N
-
MARCO TEÓRICO CAPiTULO 2
aparecer si sólo se requieren tipos de datos básicos ya
definidos en
los esquemas del lenguaje XML.
+ . Un mensaje es un elemento de comunicación básico entre e l
servicio y e l invocador del mismo, e l cual contiene una o mas
partes, donde cada parte representa un parámetro. Los
mensajes
pueden ser de entrada o de salida, lo que indica que pueden
contener
los datos necesarios para invocar un método u operación ofrecida
por
el servicio así como la respuesta de éste. Cada parte es
definida a
través de la etiqueta .
. Un portType representa un conjunto concreto de operaciones
soportadas por el servicio web, donde cada operación
definida con la etiqueta , consta de un mensaje de entrada y
salida específico, representando de esta forma una
operación solicitudIrespuesta; dándose el caso que pudiera
solamente contener ya sea un mensaje de entrada o uno de
salida.
2. La parte que nos dice cómo invocar las operaciones definidas
en la
sección anterior, describiendo los detalles de la
implementación
técnica del servicio web. Esta sección consta únicamente de
elementos de enlace .
. Dentro de la sección anterior, Únicamente definimos de
manera abstracta las operaciones soportadas por el servicio web,
el binding relaciona las operaciones definidas con un protocolo
de
comunicación concreto, ( los más utilizados HTTPIGET.
HTTPIPOST,
SOAP), relacionando cada portType con un protocolo específico. E
s importante aclarar que si el servicio soporta más de un protocolo
deberá definirse un binding por cada uno de ellos.
22
-
C A P ~ T U L O 2 MARCO TEÓRICO
3. La Última parte del documento nos indica dónde se localiza
el
servicio y consta de los siguientes elementos:
. Cada elemento port relaciona cada uno de los portType
definido con el binding correspondiente, agregando además la
localización real (URI) de un servicio web. Cabe aclarar que
pueden
existir más de un elemento port dentro de un servicio, donde
cada
uno corresponde a un protocolo específico soportado por e l
servicio.
así como los elementos que se requieran.
. Es el elemento donde se define el nombre del servicio,
Debido a que el documento WSDL cumple con la gramática definida
en el lenguaje XML, existe un elemento raiz llamado definitions,
el
cual contiene los elementos descritos anteriormente, además de
una serie de atributos tales como el nombre, y los espacios de
nombres
utilizados dentro del documento. La figura 2 .5 . nos muestra
la
estructura de un documento WSDL
< definitions > < import I >
< , I types > < messages > < 1 messages > .I
portType > < 1 portType 3- < binding > < I binding
> < service > < 1 service
< I definitions > ~ ~
Fig. 2.5 Estructura de un documentos WSDL
23
-
CAPiTULO 2 MARCO TEÓRICO
El documento de descripción de servicios no sólo nos permite
definir un servicio, sino que también, nos permite hacerlo
disponible al
publicarlo en algún repositorio de servicios web, donde un
cliente
pueda realizar búsquedas posteriormente. De esta forma, cuando
un
cliente haga una búsqueda de servicios web basándose en
algún
criterio, lo que obtendrá como respuesta será su documento de
descripción, e l cual le permitirá hacer uso de él.
2.5.3. Protocolo SOAP
Uno de los protocolos nuevos que se han propuesto es el
SOAP[13]. SOAP nos permite intercambiar documentos XML entre
aplicaciones, a través de una red, uti l izando los
protocolos
estándares como HTTP, SMTP y otros. A continuación se explica
de
forma breve el protocolo SOAP para comprender más su papel
dentro del desarrollo de aplicaciones uti l izando servicios
web.
Los documentos XML intercambiados mediante SOAP contienen
mensajes con la información necesaria para invocar y transportar
los
resultados de una aplicación. SOAP proporciona un mecanismo
simple y consistente que permite a una aplicación enviar
mensajes
XML a otra aplicación. E s un protocolo de alto nivel que sólo
define la estructura del mensaje y unas pocas reglas para su
procesamiento, es completamente independiente del protocolo que lo
transporta, por lo que pueden ser transportados sobre HTTP, SMTP u
otros. Actualmente el más utilizado es el HTTP[ l4 ] .
SOAP inicialmente propuesto por Microsoft y ahora promovido por
la W3C ha alcanzado su nivel de aceptación general por diversas
razones:
24
-
CAPiTULO 2 MARCO TEÓRICO
a) Es una especificación abierta, disponible para cualquier uso
b) Es simple de escribir y legible para el ser humano
c) Es extensible, pues toma las ventajas que ofrece XML
SOAP es una forma estándar de serialización de la
información
necesaria para invocar servicios localizados en sistemas
remotos, para que la información pueda ser enviada sobre una red (o
cable) a
un sistema remoto en un formato que el sistema remoto pueda
comprender sin tomar en cuenta en qué plataforma el servicio
se
está ejecutando o en qué lenguaje está escr i to[ l5] .
SOAP proporciona tres capacidades claves:
Es un marco de trabajo de intercambio de mensajes, el cual
consiste de un elemento Envelope (envoltura) que contiene un
elemento opcional Header (encabezado) y un elemento
obligatorio
Body (cuerpo).
codificados, serializados y decodificados cuando son
recibidos.
Es un mecanismo RPC (Remote Procedure Call, Llamada a
Procedimientos Remotos) que permite a los objetos l lamar
métodos
de objetos remotos.
Es un formato de codificación que describe cómo los objetos
son
Fig. 2.6. Estructura de un mensaje SOAP
25
-
CAPíTULO 2 MARCO TEÓRICO
Solicitud
POST1 miruta httpil.1 Host: 123.45.67.89 Content-Type: texüxml
Content-length:300 SOAPMethodNarne:
urn:misitio.wm:NurneroTelefono#ObtenerNurneroTelefono
Un mensaje SOAP contiene la información necesaria para invocar
un
método remoto o transportar la respuesta del método a quien lo
solicitó. En la f igura 2.6. se puede observar la estructura de
un
mensaje SOAP. La envoltura del transporte es la parte que
contiene
la información necesaria para que el mensaje pueda viajar
sobre
algún protocolo específico, como HTTP; la envoltura del SOAP es
un
elemento obligatorio del documento XML que representa el mensaje
y
que contiene las declaraciones de los espacios de nombres así
como
otros atributos; e l elemento del encabezado SOAP es opcional
y
podría ser usado para autentificación, transacciones,
información de
carga u otras capacidades que la especif icación SOAP no
proporciona; el cuerpo del mensaje SOAP es usado para contener
la
carga del mensaje SOAP, es decir la información para l lamar
un
método o la respuesta del mismo.
Respuesta
Hrrmi.0 ZOO ok Content-Type: texüxml Content-Length:374
-
CAPiTULO 2 MARCO TEÓRICO
2.5.4. Repositorios de Documentos WSDL
Otro punto muy importante dentro de los servicios web, son
los
repositorios o directorios de servicios que nos permiten
registrar
servicios a través de un documento XML, por lo que se
conocen
también como repositorios o registros XML. a continuación se
describen brevemente dos de los más uti l izados.
2.5.4.1. UDDl
(Universal, Description, Discovery, and Integration) [I 61
proporciona un mecanismo para describir, publicar, y localizar
servicios web que provee alguna empresa o compañia. el cual nos
permite registrar servicios como entidades de negocios que
pueden
ser categorizadas para después ser localizadas. En pocas
palabras, e l UDDl es una especificación para un registro
distribuido de
información sobre servicios web. UDDl permite a los negocios
localizar socios de negocios y conectarse dinámicamente a
sus
servicios web, as i como publicar sus servicios.
2.5.4.2. ebXML (Electronic Business using extensible Markup
Language, ebXML[17])
es un conjunto de especificaciones que permite a los negocios
de
cualquier tamaño y localizados en cualquier lugar realizar
transacciones sobre la Internet. Proporciona un método estándar
para intercambiar mensajes, definir y registrar procesos de
negocios, basándose en documentos XML.
Junto con los repositorios web se ha desarrollado JAXR[18]
(Java API for XML Registries), la cual es una API en Java que
nos permite acceder a los diferentes registros XML, como UDDl y
ebXML
27
-
C A P ~ T U L O 2 MARCO TEÓRICO
de forma fácil, es decir, el cliente tendrá la capacidad de
buscar los servicios en diferentes repositorios utilizando
JAXR.
28
-
CAPiTULO 3
. . . . . . . -
ESTADO DEL ARTE
CAPÍTULO 3 ESTADO DEL ARTE
En este capítulo describiremos algunas tecnologías que dan
soporte a la invocación de aplicaciones heterogéneas uti l
izando los servicios web y en algunos casos han considerado la
integración de las mismas.
29
-
CAPiTULO 3 ESTADO DEL ARTE
3.1. TECNOLOGíA MICROSOFT .NET
Microsoft .NET[19] es una generación avanzada de software,
que integra tecnologías de la información y comunicaciones
para
transformar el uso de la Web, permitiendo la publicación y
acceso a
la información en cualquier momento, en cualquier lugar y
desde
cualquier dispositivo. Microsoft .NET ofrece multitud de
ventajas a
programadores, empresarios, departamentos de tecnologías de
la
información y usuarios.
La tecnología .NET es la plataforma de Microsoft para
servicios
web basados en documentos XML. La plataforma .NET permite la
creación y uso de servicios de aplicaciones, procesos y sitios
web basados en XML, que comparten y combinan información y
funcionatidad por su diseño, en cualquier plataforma o
dispositivo preparado para ello. La plataforma .NET administra gran
parte de los
detalles de infraestructura, permitiendo a los
desarrolladores
centrarse en escribir el código de la lógica empresarial para
sus
aplicaciones.
La plataforma .NET provee un conjunto de herramientas de
desarrollo, aplicaciones cliente, servicios web y servidores en
las que
destaca el modelo de programación .NET Framework. En la figura
3.1. se muestran los componentes de Microsoft .NET. El .NET
Framework incluye el lenguaje común en tiempo de ejecución
(CLR,
Common Language Runtime) y bibliotecas de clases[20].
3.1.1. .NET Framework
El .NET Framework es un componente del sistema operativo
Microsoft Windows@ que proporciona el modelo de programación
para
crear, implementar y util izar aplicaciones basadas en la
Web,
aplicaciones para dispositivos inteligentes y servicios web
XML.
30
-
ESTADO DEL ARTE CAPiTULO 3
Fig. 3.1. Componentes de Microsoft .NET
3 .1 .2 . L e n g u a j e Común e n Tiempo d e E j e c u c i ó n
(CLR).
El componente principal de .NET es la capa más baja de su modelo
en capas, e l lenguaje común en tiempo de ejecución
(Common Language Runtime, CLR) o también conocido como
máquina virtual común. Se trata de un programa, que se puede
ejecutar en principio, en cualquier sistema operativo, y que
provee
una serie de servicios que se pueden usar desde diferentes
lenguajes
de programación. El CLR es el responsable de los servicios en
tiempo
de ejecución y de la integración de lenguajes, la aplicación de
seguridad y la administración de la memoria, los procesos y
subprocesos. Además, juega un papel importante en tiempo de
desarrollo, puesto que características como la administración de
la duración, la aplicación de verificación de tipos que asegura
la
compatibilidad de tipos, e l control de excepciones entre
lenguajes, la creación de enlaces dinámicos, etc. reducen la
cantidad de código
que debe escribir un desarrollador para convertir la lógica
empresarial en un componente reutilizable.
31
-
CAPiTULO 3 ESTADO DEL ARTE
3.1.3. Biblioteca d e Clases
Las clases base proporcionan funcionalidad estándar tales
como funciones de entrada y salida, manipulación de cadenas,
administración de la seguridad, comunicaciones de red,
administración de subprocesos y de texto, características de
diseño
de la interfaz de usuario y otras funciones. Las clases de datos
de Microsoft ADO.NET admiten ,la administración de datos
permanentes
e incluyen clases SQL para manipular almacenes de datos
permanentes a través de una interfaz SQL estándar. Las clases
XML
permiten la manipulación de datos XML, así como la búsqueda
y
traducción de XML. Las clases de Microsoft A5iP.NET admiten
el
desarrollo de aplicaciones web y servicios web XML.
El .NET Framework tiene características para hacer más fácil
la
implementación, ejecución y administración de aplicaciones.
El
aislamiento de aplicaciones y el control de vers,iones
automático de
componentes pueden ayudar a prevenir conflictos de versiones.
Las
aplicaciones creadas usando el .NET Framework pueden ser
implementadas en un cliente o en un servidor si,mplemente
copiando
el directorio de la aplicación al equipo, sin realizar cambios
en el
registro.
El .NET Framework fue diseñado desde un principio con soporte
para
servicios web XML. un modelo para computación distribuida en
múltiples ambientes, basado en protocolos como XML, SOAP y HTTP.
Los servicios web XML pueden ser usados para integrar
aplicaciones
que se ejecutan en diferentes plataformas, o para proporcionar
software como un servicio. Con el .NET Framework, una
aplicación
puede ser transformada en un servicio web XML con solamente una
simple línea de código.
32
http://A5iP.NET
-
ESTADO DEL ARTE CAPiTULO 3
3.2. WEB SERVICE INVOCATION FRAMEWORK (WSIF)
El marco de trabajo de invocación de servicios web (Web
Service Invocation Framework, WSIF) es simplemente una API4
en
lenguaje java para la invocación de s e r h o s web, sin
preocuparse
cómo o de dónde provienen los servicios[21].
WSlF permite a los desarrolladores interactuar con las
representaciones abstractas de los servicios web a través de
sus
descripciones WSDL en lugar de trabajar directamente con los
protocolos como SOAP, utilizados normalmente para esta
interacción[22].
WSlF tiene la capacidad de invocar dinámicamente un servicio
web,
examinando los meta-datos del servicio en tiempo de ejecución.
WSlF esta basado en el WSDL, por lo tanto puede invocar cualquier
servicio que pueda ser descrito mediante un documento WSDL[23].
WSlF utiliza la información contenida en el WSDL, de manera que
es
capaz de acceder a l servicio de forma independiente del
protocolo o la localización. Es una API4 que utiliza el WSDL para
acceder a la
funcionalidad del servicio ,,descrito. Esto también permite
escribir
código que se adapte fácilmente a los cambios. La separación de
la API del protocolo actual también nos da flexibilidad, es decir,
podemos cambiar de prot,ocolos o de localización sin tener que
recompilar e l código de la aplicación cliente, solamente
cambiando la
Una API (Application Program Interface) nos proporciona una
interfaz entre un programa de aplicación y utilidades o servicios.
dando un nivel de abstracción a los usuarios que evita tener que
preocuparse de cómo se lleva a cabo esta comunicación:
4
,I
33
-
ESTADO DEL ARTE C A P ~ T U L O 3
descripción del servicio o WSDL sin necesidad de realizar alguna
modificación en la aplicación que usa el servicio.
La API WSIF permite a los clientes invocar servicios enfocándose
en
la descripción abstracta del servicio, es decir, en la porción
del
documento WSDL que cubre los puertos, las operaciones y los
mensajes de intercambio sin tener que lreferirse a un protocolo
en
particular. El desacoplamien,to de la invocación abstracta de la
real
nos proporciona un modelo de programación flexible que permite
la
invocación dinámica. '¡I
Usando WSIF, e l WSDL puede l legar a convertirse en la pieza
central
de u n marco de trabajo de integración para acceder software
ejecutándose en diversas plataformas y usando una amplia variedad
de protocolos. La única condición necesaria es describir el
software
utilizando WSDL.
'I j !
La secuencia natural de la invocación de un servicio web dentro
de
una aplicación cliente es:
Identificar el servicio
Identificar la operación
Identif icar los parámetro: Ejecutar la operación
Extraer el resultado o la falla.
La arquitectura WSIF[24] proporciona lo necesario para l levar a
cabo la invocación de un servicio web de forma dinámica. Para ello
el
documento WSDL es interpretado, los mensajes de entrada son
creados usando los argumentos especificados por los usuarios y
la operación es invocada.
34
-
CAPíTULO 3 ESTADO DEL ARTE
3.3. PROYECTO AXIS
Axis es un proyecto de los creadores de Apache SOAP[25], cuyas
características facil i tan el trabajo de los programadores.
Las
acciones más comunes que se pueden realizar con esta
herramienta
son: exponer la funcionalidad como un servicio web y acceder a
un
servicio web.
Podemos decir que Axis es: 1
Una implementación de la API JAX-RPC para contenedores web.
Contiene una serie de herramientas que se pueden instalar en
el
servidor de aplicaciones web: I/
a) APls
b) Herramientas que nos permiten generar un documento WSDL a
partir de una clase en java (Java2WSDL) o que nos permiten
generar una clase en java a partir de un documento WSDL
(WSDL2Java).
!! It
c) Un servlet (AxisServlet) que recibe las peticiones SOAP
sobre
HTTP que envían ,los clientes; invocando la operación
correspondiente sobre e l servicio web; y devuelve una
respuesta SOAP como resultado de la operación.
I!
Axis es un servidor y cliente SOAY de código abierto. SOAP
implementa la API JAX-RPC, una de las formas estándar para
servicios implementados en java.
Axis puede ser instalado licomo una aplicación más dentro de un
servidor de aplicaciones como el Torncat[26]. La figura 3.2. nos
muestra el Axis desplegándose en cua'lquier navegador después
de
haber sido instalado en un servidor de aiplicaciones Tomcat.
35
-
9E
-
ESTADO DEL ARTE C A P ~ T U L O 3
JavaServer Pages (JSP) JSP Standard Tag Library (JSTL)
Este conjunto de APls facilita el trabajo del desarrollador;
ayudan en
la generación de documentos WSDL, llamadas de métodos en
servicios disponibles usando RPC, petición y respuesta de
mensajes
utilizando SOAP y en la publicación de servicios web.
I/
Cada una de las APls proporcionadas por e l JWSDP juega un
papel
específico dentro de los servicios web, el programador deberá
elegir
las APls que requiera para el desarrol lo~jde una aplicación.
Las APls contenidas en el JWSDP pueden ser utlilizadas solas o
varias a la
vez, dependiendo de las necesidades de la aplicación.
A continuación se explica brevemente la funcionalidad que
nos
brindan algunas de las APls contenidas en JWSDP que son
utilizadas
para el procesamiento y uso'de documenios XML.
3.4.1. Java API for XML Processing (JAXP) I1
/I
Esta API esta orientada hacia los documentos y t iene
como funcionalidad la de procesar documentos XML, uti l izando
varios I II
parsers o analizadores.
La API JAXP hace más fácil el procesamiento de datos XML al
realizar aplicaciones escritas en el lenguaje java. JAXP hace uso
de
analizadores tales como SAX (Simple API for XML Parsing) y
DOM
(Document Object Model) de manera qhe se puede seleccionar
qué
parser util izar para analizar los datos, ya sea como un flujo
de eventos o construyendo una representación de éstos en un árbol
estructurado.
37
-
ESTADO DEL ARTE CAPiTULO 3
JAXP también soporta el estándar XSLT (XML Stylesheet
Language
Transformations) la cual nos proporciona el control sobre la
presentación de los datos y nos permite convertir los datos a
otros
documentos XML u otros formatos, tales Icorno HMTL. JAXP también
proporciona soporte para los espacios de nombres, permitiendo
trabajar con esquemas que pudieran l legar a tener confl ictos en
el nombrado
I
3.4.2. Java API for XML-based RPC (JAX-RPC)
JAX-RPC es la API de java para1)el desarrollo y uso de los
servicios web. Envia l lamadas a métodos SOAP localizados en
sitios
remotos sobre la Internet y recibe los resultados. li
Un servicio web basado en ,RPC es una colección de
procedimientos
que pueden ser l lamados por un cliente remoto sobre la
Internet. Un
servicio web es una aplicación en el servidor que implementa
los
procedimientos que están disponibles para que los clientes hagan
uso de ellos, éstos están almacenados en un contenedor en el lado
del
servidor. El contenedor puede ser un contenedor de servlets
tales // ' t
como el Tomcat o el contenedor disponible en la edición
empresarial
de la plataforma Java 2 (J2EE) que está basado en la
tecnologia
javabeans. La figura 3.3 nos muestra un esquema general de
un
servicio web basado en JAX-RPC en tiempo de ejecución. !I 14
sewicio Cliente
Stubs
Fig. 3.3. Servicio basado en JAX-RPC en tiempo de ejecución
38
-
CAPiTULO 3 ESTADO DEL ARTE
3.4.3. Java API for XML Messaging (JAXM')
La API JAXM proporciona una forma estándar de enviar
documentos XML sobre la Internet desde una plataforma java.
Está
basada en el protocolo SOAP, por lo tanto cumple con las
especificaciones de éste.
JAXM define un marco de trabajo básico para el intercambio
de
mensajes SOAP entre aplicaciones. JAXM puede ser extendido
para
trabajar con protocolos de manejo de mensajes de un nivel más
alto
como el util izado por ebXML, proporcionando una forma más
segura
de enviar mensajes entre negocios sobre !'la Internet. I/ !I
JAXM nos proporciona todas las herramientas necesarias para
crear mensajes y enviar mensajes SOAF sobre la Internet para que
puedan ser intercambiados entre aplicaciones.
3.4.4. Java API for XML Registries (JAXR)
La API JAXR proporciona una forma conveniente para acceder a
varios registros de negocios o servicios sobre la Internet. Los
registros son frecuentemente descritos como páginas amarillas
electrónicas porque contienen l istados de negocios y los
productos o servicios que éstos ofrecen. JAXR le proporciona a
los
desarrolladores de aplicaciones bajo la plataforma java una
forma uniforme de usar los registros de negocios que están basados
en estándares abiertos (talesi como ebXML) o especif icaciones
(tales
como UDDI).
I! 1,
Util izando JAXR los negócios pueden registrar sus productos
o
servicios que deseen compartir, o pueden localizar servicios o
productos de otros negocios que deseen utilizar o adquirir.
39
// I
'I .I
-
ESTADO DEL ARTE CAPiTULO 3
Un registro basado en XML es una infraestructura que permite
la
construcción, la publicación y e l descubrimiento de servicios
web. Es por ello que los registros dstán convir tkndose en un
componente
importante de los servicios web ya que permiten a los negocios
colaborar de forma dinámi,ca con otros negocios y de manera
desacoplada. La figura 3.4. nos muestra la arquitectura de la
API
JAXR.
i it Cliente JAXR i
i 'I I' I
Aki JAXR
Diversos registros
Fig. 3.4. Arquitectura de la API JAXR
3.4.5. XML Stylesheet Language for Transformations (XSLT)
La API XSLT definida por e l grupo de trabajo de la W3C
XSLWorking, describe un lenguaje para transformar documentos
XML
en otros documentos XML o en otros formatos. Para llevar a cabo
la transformación, se requiere proporcionar una hoja de esti lo
(style sheet), la cual está escrita en el lenguaje de hojas de esti
lo XML
(XML Stylesheet Language, XSL). La hoja de estilo XSL
especifica
cómo los datos XML deben ser presentados y e l XSLT usa las
instrucciones en la hoja de'lestilo para realizar la
transformación.
I!
II
40
-
. . . - . .- -
CAPiTULO 4
_.. ~
DISENO DE LA PLATAFORMA
CAPÍTULO 4 DISEÑO DE LA PLbTAFORMA
En este capitulo se' describe e\ proceso de diseño de la
plataforma, definición de los elementos que la conforman; así
como
los diferentes escenarios en los cuales la plataforma es uti l
izada.
41
-
CAPiTULO 4 DISENO DE LA PLATAFORMA ~~
El diseño del sistema es la estrategia deia l to nivel para
resolver un problema y construir una solución. Éste incluye
decisiones acerca de
la organización del sistemas en subsistemas, la asignación
de
subsistemas a componentes de hardware y software, y
decisiones
fundamentales conceptuales y de política que son las que
constituyen
el marco de trabajo para el di.seño detalla$o[28].
1, li
Cada sistema de software debe tener una función y una forma.
Estas
dos cosas deben equilibrarse para obtener un software de
calidad.
Los casos de uso constituyen la función del sistema y la
arquitectura la forma y debiendo existir una interacción entre
ellos.
I /
I'
La arquitectura en un sistema de software se describe
mediante
diferentes vistas del sistema y todos los casos de uso
constituyen el modelo conceptual, el cual describe la funcionalidad
total del sistema
e denomina
desde el punto de vista del usuario.
4.1. DISENO A R Q U I T E C T ~ N I C O ',
La organización global del sistema es lo que 3 arquitectura del
sistema. La arquitectura básica de la plataforma
desarrollada corresponde a la de un sistema distribuido. Debido
a que
existen varios t ipos de arquitecturas para sistemas
distribuidos
podemos considerar que la plataforma corresponde a una variante
de un modelo cliente servidor, util izando un proxy (Figura 2.2),
por lo cual tenemos a los clientes enviando peticiones o
solicitudes a un
servidor pasando a través de un proxy y recibiendo las
respuestas
emitidas por e l servidor a través del mismo.
La figura 4.1 nos muestra ulna arquitectura en capas de la
plataforma.
42
!I
-
CAPiTULO 4 DISEÑO DE LA PLATAFORMA
Fig. 4.1. Arquitectura de la plataforma de soporte de
integración de servicios web
Dentro de la arquitectura podemos identificar la parte del cl
iente que
constituye la presentación o interfaz del usuario, la cual es
definida
por medio de páginas web escritas en HTML o páginas JSP. La
lógica de la plataforma está localizada en un intermediario entre
el cliente
que realiza las peticiones a,itravés de Iailinterfaz y los
servidores que proporcionan los servicios. La tercera parte de la
plataforma
corresponde a los servidores que proporcionan los servicios,
que
serán registrados, invocados e integrados desde la
plataforma.
i /
4.2. DISEÑO CONCEPTUAL
4.2.1. Diagrama de Casos de Uso
Dentro del modelo conceptual podemos identif icar a los actores
que interactúan con el sistema, los cuales están representados,
al
43
-
CAPiTULO 4 DISEÑO DE LA PLATAFORMA
igual que la funcionalidad del sistema, en el diagrama de casos
de
uso que se muestra en la f igura 4 . 2 . 'I
Proveedor
de Servicios
! Plataforma de Soporfe para la inte&ación de Servicios Web
I
/I
Consumidor
de Servicios
>; I1 I Fig. 4.2. Diagrama de casos de uso de la plataforma
de soporte de integración de servicios web
Como podemos observar en el diagrama de casos de uso existen dos
actores que interactúan con el sistema: el proveedor de servicios y
e l consumidor de servicios. E l proveedor d,e servicios realiza el
registro
de los servicios que desea hacer dispo'nibles y agrupa los
servicios que tengan una funcionalidad compatible en categorías.
El
consumidor de servicios consulta la página amarilla con los
servicios registrados en la plataforma, busca servicios en base a
algún criterio
y realiza la invocación de los servicios disponibl'es e n la
plataforma.
I! I/
44
-
CAPiTULO 4 DISENO DE LA PLATAFORMA
4.2.2. Escenarios de Uso
Los escenarios de uso, resultado de los casos de uso
identificados, son descritos *a continuación:
Escenario de uso 1: El proveedor .de servicios registra un
servicio Este caso de uso se lleva a cabo cuando el proveedor de
servicios desea registrar un servicio para que sea disponible en la
plataforma.
Escenario de éxito 1,
1. El proveedor de servicios proporciona la dirección dónde se
localiza el documento de descripción del servicio que desea
registrar.
2 . El proveedor selecciona una categoría a la que desea que
pertenezca el servicio a registrar. a. La categoría pue.de ser
seleccionada de las categorías ya
existentes.
b. Se puede registrar una nueva categoría.
3. El proveedor proporciona el nombre del servicio a registra?
4. El proveedor proporciona una descripción del servicio si lo
I!
considera.
5. El proveedor registra el servicio.
a. Si la categoría seleccionada fue nueva se l levará a cabo I
/
el registro de una nueva categoría.
b. Si la categoría seleccionada ya existía, el servicio se
agregará al grupo de servicios de esa categoría.
E s recomendable que el nombre del servicio sea el que se
encuentre especificado en el 5 documento de descripción del
servicio que fue proporcionado.
45
-
CAPiTULO 4 DISEÑO DE LA PLATAFORMA
Escenario de falla
Una falla al momento de registrar un servicio puede darse en
las
siguientes situaciones:
a. Cuando la dirección proporcionada por el proveedor de
servicios en el punto 1 del escenario de éxito no sea
válida.
b. Cuando el documento al que se hace referencia en la dirección
proporcionada por el proveedor de servicios en el punto 1 del
escenario de éxito no esté disponible. c. Cuando el documento al
que se hace referencia en la dirección
proporcionada por e l proveedor de servicios en el punto 1 del
escenario de éxito no sea un documento de descripción de
servicio válido.
I1
I
Escenar io de uso 2: E l p roveedor e l im ina el registro de u
n se rv i c i o
Este caso de uso se realiza cuando el proveedor de servicios
desea eliminar un servicio previamente registrado en la
plataforma.
Escenario de éxito
1. El proveedor de servicios selecciona la categoría donde
se
encuentra e l servicio que desea dar de baja.
2. El proveedor de servicios selecciona el servicio que desea
eliminar de la l ista de servicios q'ue pertenecen a la
categoría
seleccionada en el punto anterior.
3 . El proveedor elimina el servicio.
!I
a. Si la categoría donde se encontraba el servicio eliminado
tenía un solo servicio, la categoría se elimina también.
b. S i la categoría donde se encontraba e l servicio
eliminado
tenía más de un servicio, la categoría sólo es actualizada.
:I 1;
46
-
C A P ~ T U L O 4 DISENO DE LA PLATAFORMA
Escenario de uso 3: El proveedor de servicios actualiza una
categoría El proveedor de servicios a,ctualiza una categoría a l
momento de registrar o eliminar un servicio de la categoría. Además
de eso podría actualizar la descripción de la categoría.
,I
Escenario de éxito
1. El proveedor selecciona la categoria que desea actualizar. 2.
El proveedor proporciona una nueva descripción de la
categoría.
3. El proveedor actualiza la categoría.
Escenario de uso 4: Regist,rar categoría AI momento de registrar
.un nuevo servicio, es posible que el
proveedor de servicio no seleccione una de las categorías
previamente registradas, por lo que una nueva categoria se
registra.
Escenario de uso 5: Eliminar categoría AI momento de eliminar e
l registro de un servicio que se encuentre en
una categoría donde sólo exista ese servicio, la categoría es
dada de
baja automáticamente.
Escenario de uso 6: El consumidor delservicios busca un servicio
El consumidor de servicios busca un servicio basándose en algún
criterio como el nombre o la descripción del servicio.
Escenario de éxito
1. El consumidor proporciona un criterio de búsqueda de
servicios,
2. El consumidor obtiene la l ista de servicios que coincidieron
o
ya sea parte del nombre o de la descripción del servicio.
cumplieron con el criterio de búsqiueda proporcionado.
47
-
C A P ~ T U L O 4 DISENO DE LA PLATAFORMA
Escenario de falla.
El consumidor podría obtener una lista de servicios vacía s i no
encuentra algún servicio que cumpla con el criterio proporcionado
en
el punto 1 del escenario de éxito.
I
Escenario de uso 7: El consumidor de servicios consulta la
página amarilla de servicios El consumidor de servicios consulta la
página de servicios registrados en la plataforma, la cual contendrá
una l ista de todas las
categorías registradas, donde el usuario seleccionará la
categoría
que contenga los servicios que desee invocar.
Escenario de uso 8: El consumidor de servicios invoca un
servicio El consumidor de servicios selecciona, ya sea después de
realizar
una búsqueda de servicios o de consultar la página amarilla,
una
categoría e invoca los servicios que estén contenidos en
ella.
Escenario de éxito
I. El consumidor selecciona una categoría de servicios
registrada.
2. Se selecciona alguna de las operaciones que los servicios
3. Se proporcionan 10s parámetros que requiere la operación
que
contenidos en la categoría ofrezca.
se quiere invocar, cuando existan tales parámetros. 4 . Se
invocan el o los servicios registrados en la categoría.
a. Si la categoría Sólo contiene un servicio éste es
invocado
directamente y el resultado devuelto al consumidor. b. Si la
categoría contiene m á s de un servicio, son
invocados cada'! uno de los' servicios que contengan la
48
-
C A P ~ T U L O 4 DISENO DE LA PLATAFORMA
operación solicitada y se devuelven los resultados que se
obtienen.
Escenario de falla
Los posibles escenarios de falla que pueden darse son los
siguientes:
a. Que al momento de seleccionar una categoria en el punto 1 del
escenario de éxito, todos los servicios contenidos en esa
categoría no estén disponibles.
b. Que los parámetros que se proporcionen en el punto 3 del
escenario de éxito sean incorrectos y ocasionen una falla en
la
ejecución del servicio o los servicios.
Escenar io de uso 9: In tegrar se rv i c i os La integración de
servicios se da cuando al invocar los servicios en
una categoria, la categoría seleccionada contenga más de un
servicio, por lo que los resultados serán integrados en uno solo
antes
de ser devueltos al consumidor.
4.2.3. Diagramas de Ac t i v i dad /I
Un diagrama de actividad es una'ivariante de un diagrama de
flujo de datos, donde se muestran las actividades involucradas
en un
proceso. Dentro de la plataforma podemos identif icar dos de los
procesos principales, en los cuales se presentan la mayor parte
de
los casos de uso definidos. Por tal razón estos procesos son
descritos a continuación mediante sus respectivos diagramas de
actividad.
! .
49
-
CAPiTULO 4 DISENO DE LA PLATAFORMA
Proveedor
T Registrar Docu Servicio
Confirinaci6i
4.2.3.1. Proceso de Reg is t ro de Serv ic ios
nento
El proceso de registro de servicios inicia en el momento en
que
un proveedor desea registrar un servicio 'para hacerlo
disponible a los usuarios de la plataforma y concluye cuando el
servicio es registrado. La figura 4.3. nos muestra su diagrama de
actividad correspondiente.
I1
Plataforma de Soporte para la Integración de Servicios Web
7 .
WSDL r .
Registrar 1, +*l. Cate Oría Categoría J
Categoria Existente
Actualizar Categorial'
;Error IRegistrar Servicio en el Directorio de Servicios
Fig. 4.3. Diagrama de actividad::del proceso de$egistro de un
servicio
4.2.3.2. Proceso de Invocac ión de un Serv ic io
El proceso para invocar un serviciolinicia en el momento en
que
un consumidor de servicios selecciona uno de los servicios
disponibles, ya sea de una l ista de servicios proporcionada
después
de una búsqueda o al consultar la página amarilla de los
servicios registrados; este proceso concluye al momento de obtener
los
I!
50
-
CAPiTULO 4 DISENO DE LA PLATAFORMA
resultados de la invocación del servicio o la categoría
seleccionada.
La figura 4.4. nos muestra e l 'diagrama delactividad
correspondiente a
este proceso.
Consumidor
Buscar Servicio +--
Proporcionar Parámetros
Plataforma de Soporte para la Integración de /'Servicios Web
{...(.I Generar Pagina
Obtener Parámetros
Fig. 4.4. Diagrama de actividad del procesolde invocación de un
servicio
51
-
II 11 - ~ -
CAPiTULO 4 DISENO DE LA PLATAFORMA
4.2.4. Modelo General de la Plataforma
El modelo general de la plataforma que se muestra en la figura
4.5. nos proporciona una vista conceptual de la misma, la cual
engloba los casos de uso definidos, así como el f lujo de
las
actividades realizadas pori. los actores que interactúan con
la
plataforma
m g RE
Proxy
Plataforma de Soporte para la, Integración de Servicios Wed
WSDL
13 SI I n I
Internet
Fig 4.5. Modelo principal de la plataforma
4.3. MÓDULOS DE LA PLATAFORMA
Dentro de la plataforma hemos definido los módulos que
integran la misma, los cuales"son descritos a continuación:
4.3.1. Módulo Servidor de Peticiones
El módulo servidor de peticiones es, e l encargado de
analizar
cada una de las peticiones que realizan los clientes o usuarios
dentro de la plataforma y que determinara si la petición es una
solicitud de una página web o de un servicio web. Este módulo actúa
de manera
transparente al usuario bajo previa configuración del
navegador.
52
-
CAPiTULO 4 DISENO DE LA PLATAFORMA
4.3.2. Módulo Analizador de Documentos WSDL
El módulo analizador de documentos WSDL examinará
detalladamente cada uno de los documentos de descripción de
servicio que sean registrados dentro de la plataforma para
verificar s i
son válidos y extraer la información necesaria para la
invocación de los servicios descritos en cada uno de ellos.
4.3.3. Módulo de Registro de Servicios Web
El módulo de registro de servicios web tiene la funcionalidad
de
registrar los documentos de descripción de servicios y agrupar
los
servicios en categorías, lo cual permitirá que varios servicios
de la misma funcionalidad puedan integrarse posteriormente. Este
módulo
también permitirá la eliminación o actualizac'ión de los
servicios ylo categorías registradas.
I 4.3.4. Módulo de Página Amarilla de Servicios Web
Este módulo t iene la finalidad de consultar los servicios
registrados y agrupados en categorías para generar una lista
de
éstos y mostrarla en forma de un directorio de servicios.
4.3.5. Módulo de Búsqueda de Servicios Web
Este módulo realizará las búsquedas de los servicios que un
consumidor requiera basándose en algún criterio de selección y
retornar una lista de los servicios que coincidan con tal
criterio.
53
-
CAPITULO 4 DISENO DE LA PLATAFORMA
4.3.6. Módulo de Invocación de Servicios Web
El módulo de invocación obtendrá la información necesaria
del
documento de descripción de servicio, para que el servicio
descrito
pueda invocarse de forma dinámica, es decir, solicitará los
parámetros necesarios para llevar a cabo la ejecución del
servicio y
con la información obtenida , del documento WSDL, como la
localización del servicio, invocará al servicio solicitado.
4.3.7. Módulo de Integración de Servicios Web
Este módulo tendrá la función de analizar si una categoría
contiene más de un servicio con l