CENTRO NACIONAL DE INVESTIGACIÓN Y DESARROLLO … · 2014-02-13 · s.e.p. s.e.i.t. d.g.1.t centro...

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

. . . . . . .. . .


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


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


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


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


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


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


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


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


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


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


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


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

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


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


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


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


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


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


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


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


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


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


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


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

CENTRO NACIONAL DE INVESTIGACIÓN Y DESARROLLO … · 2014-02-13 · s.e.p. s.e.i.t. d.g.1.t centro...

Documents

Transcript of CENTRO NACIONAL DE INVESTIGACIÓN Y DESARROLLO … · 2014-02-13 · s.e.p. s.e.i.t. d.g.1.t centro...