centro nacional de investigación y desarrollo tecnológico ... - … maria… · faby, aldo, rafa,...

S.E.P. S.E.S. D.G.E.S.T.

Centro Nacional de Investigación y Desarrollo Tecnológico

cenidet

Composición de Servicios Web

TESIS

Que para obtener el grado de: MAESTRO EN CIENCIAS EN

CIENCIAS DE LA COMPUTACIÓN

Presenta:

I.S.C. Mariana Guzmán Ruiz

Director de tesis:

M.C. Olivia Graciela Fragoso Diaz

Codirector de tesis: Dr. René Santaolaya Salgado

Cuernavaca, Morelos Marzo del 2006

DEDICATORIAS A mis padres, Inés y José Luis. Por todo su amor, cariño y comprensión, que me han brindado siempre, y el gran ejemplo que me han dado de enfrentar los problemas de la vida para seguir adelante día a día, y levantarme de todas las caídas y no dejarme vencer aunque las cosas sean adversas, porque nunca han dudado de mí y siempre me han apoyado. A mis hermanos, José Luis, Juan Jesús y Alberto Alejandro, por siempre estar conmigo, apoyarme y creer en mí, por esta vida juntos llena de juegos y aventuras, que seguimos compartiendo, y ser mis incondicionales hermanos. A mi novio Abel por ser el compañero que me escucha, comprende y aconseja, por apoyarme en este proyecto de la maestría y todos los proyectos de la vida, por comprender mi sentir siempre. Y ese amor que alimenta cada día.

AGRADECIMIENTOS A Dios. Al Centro Nacional de Investigación y Desarrollo Tecnológico, Cenidet, y al personal tan amable que labora. Al Cosnet, por su ayuda económica para lograr mis estudios de maestría. ¡Y por esos depósitos de la beca tan puntuales siempre! A la SEP por su ayuda económica para lograr mis estudios de maestría. A mi directora de tesis la M.C. Olivia Graciela Fragoso Díaz, por esa motivación incondicional y esos consejos tan enriquecedores, y al Dr. Rene Santaolaya Salgado, por las discusiones positivas, sus sabios consejos y pláticas. Gracias a los dos hicieron de mi estancia en el Cenidet una experiencia agradable y positiva. A mis revisores, el M.C. Mario Guillén, M.C. Felipe Alanis y M.C. Moisés González, que guiaron el trabajo de tesis por un buen camino. A mis amigos hechos en el Cenidet: Manuel, Xochitl, Santos, May, Isidro, Isaac, Ceyca, y Vanoye. Por todo su apoyo. Y a mis cuates Homero, Ismael y, Guillermo, Gabriel, Armando, Adrián y Marco. A las chicas, (lo rescatable de la estancia) Erika, Mireya, Silvana y Sandy. A la familia, sobrinos: Micky y Cristi, y su mami Iliana, primos: Bety, Mariano, Diana, Faby, Aldo, Rafa, Ivan, Esme (Maria), Rodolfito y Chelo. Tios: Bety, Victor, Yola, Helena, Lupe, Rodolfo, Irma. Por todo su apoyo su fe en mi y todo ese amor que me brindan. Sus consejos y todos esos buenos momentos. Muchas gracias a todos.

ÍNDICE GENERAL Índice de Figuras…………………………………………………………………… ii Índice de Tablas……………………………………………………………………. iv Glosario de Términos. …………………………………………………………….. v Capítulo 1: Introducción. 1.1. Introducción……………………………………………………………………... 2 1.2. Organización del documento de tesis. ………………………………………... 3 Capítulo 2: Antecedentes. 2.1. Introducción....………………………………………………………………..... 5 2.2. Estado del arte. ………………………………………………………………..... 5 2.2.1. Trabajos relacionados.……………………………………………………….... 5 2.2.2. Herramientas para Composición de Servicios Web ………………………..... 6 2.2.3. Comparación entre la tesis y los trabajos analizados en el estado del arte……. 7 2.3. Objetivo. ……………………………………………………………………….. 7 2.3.1. Objetivo General………………………………………………………………. 7 2.3.2. Objetivos Específicos…………………………………………………………. 7 2.4. Descripción del problema…………………………………………………..…… 8 2.5. Justificación del estudio…………………………………………………………. 8 2.6. Límites y alcances de estudio………….………………………………………... 8 2.6.1. Limites de estudio…………………………………………………………….. 8 2.6.2. Alcances de estudio………………………………………………………….... 8 Capítulo 3: Marco Teórico. 3.1. Introducción………………..…………………………………………………..... 10 3.2. Definición de Servicios Web…………………………………………………..... 10 3.2.1. Componentes de un Servicios Web…………………………………………… 10 3.2.2. Proceso de un Servicio Web…………………………………………………... 10 3.3. Aplicaciones Web……………………………………………………………….. 11 3.4. Composición…………………………………………………………….............. 11 3.5. Tecnología XML………………………………………………………………... 12 3.5.1. XML frente HTML……………………………………………………………. 12 3.5.2. Usos de XML…………………………………………………………………. 13 3.6. SOAP (Protocolo de Acceso para Objetos Simples)……………………………. 13 3.6.1. Ventajas de SOAP respecto a otros protocolos.………………………………. 14 3.7. UDDI (Definición para Descubrimiento e Integración de Servicios Web)........... 15 3.7.1. Como funciona UDDI………………………………………………………… 16 3.8. WSDL (Lenguaje para Definición de Servicios Web)…………………….......... 17 3.8.1. Elementos de un documento WSDL………………………………………….. 18 3.9. API JDOM………………………………………………………………………. 21 3.9.1. Ventajas de JDOM……………………………………………………………. 21

CENIDET 2006 i

3.9.1. Estructura de JDOM…………………………………………………………... 21 3.10. Axis de Apache Tomcat……………..………………………………………… 22 3.11. Microsoft Visual Studio .Net …………………………………………………. 22 Capítulo 4: Definición del Proceso y Desarrollo de la Herramienta. 4.1. Introducción……………………………………………………………………... 26 4.2. Proceso Metodológico para componer Servicios Web………………………….. 26 4.3. Modelo conceptual de la herramienta…………………………………………… 27 4.4. Descripción de la Herramienta Web Services Compositor……………………... 28 4.4.1. Selección de los Servicios Web………………………………………………. 28 4.4.2. Acceso y análisis de los documentos WSDL de los servicios web………….... 29 4.4.3. Presentación de los nombres de los métodos de entrada y salida……………... 30 4.4.4. Selección de los métodos de los servicios web……………………………….. 32 4.4.5. Generación del código para habilitar la composición de los servicios web…... 33 4.4.6. Generación del código cliente que integra los servicios web…………………. 35 4.5. Diseño de la herramienta utilizando casos de uso………………………………. 37 4.5.1. Diagramas de clases…………..………………………………………………. 39 4.5.1.1. Descripción de la responsabilidad de cada clase……………………………. 39 4.5.1.2. Diagramas de secuencias……………………………………………………. 40 4.6. Conclusión del proceso y desarrollo de la herramienta…………………………. 44 Capítulo 5: Pruebas. 5.1. Composición de los servicios web WS_Suma y WS_Media…………………… 45 5.1.1. Objetivo……………………………………………………………………….. 45 5.1.2. Descripción……………………………………………………………………. 45 5.1.3. Resultado de la prueba………………………………………………………… 45 5.1.4. Evaluación de resultados……………………………………………………… 51 5.2. Composición de los servicios web WS_AreaRectangulo y WS_PerimetroRectangulo……………………………………………………………

52

5.2.1. Objetivo……………………………………………………………………….. 52 5.2.2. Descripción……………………………………………………………………. 52 5.2.3. Resultado de la prueba………………………………………………………… 52 5.2.4. Evaluación de resultados……………………………………………………… 58 5.3. Composición de los servicios web WS_AreaTriangulo y WS_PerimetroTriangulo………………………………………...……………………

59

5.3.1. Objetivo……………………………………………………………………….. 59 5.3.2. Descripción……………………………………………………………………. 59 5.3.3. Resultado de la prueba………………………………………………………… 59 5.3.4. Evaluación de resultados……………………………………………………… 65 5.4. Composición de los servicios web WS_AreaCuadrado y WS_AreaCirculo……………………………………………………………………..

66

5.4.1. Objetivo……………………………………………………………………….. 66 5.4.2. Descripción……………………………………………………………………. 66 5.4.3. Resultado de la prueba………………………………………………………… 66 5.4.4. Evaluación de resultados……………………………………………………… 72 5.5. Conclusión de las pruebas realizadas…………………………………………… 72

CENIDET 2006 ii

Capítulo 6: Conclusiones. 6.1. Conclusiones……………………………………………………………………. 74 6.2. Recomendaciones y trabajos futuros……………………………………………. 75 Referencias Referencias…………………………………………………………………………... 77 Anexo A: Instalación de Herramientas. A.1. Procedimiento de instalación de las herramientas……………………………… 81 A.1.1. Requerimientos y herramientas……….……………………………………… 81 A.1.2. Procedimiento de instalación…………………………………………………. 81 A.2. Ejemplo de la publicación de un servicio web con Apache Axis………………. 82 A.2.1. Requerimientos y herramientas………………………………………………. 82 A.2.2. Pasos para instalar el servidor Axis e integrarlo con el servidor Tomcat…….. 83 A.2.3. Pasos para crear un servicio web………………………………………..……. 85

ÍNDICE DE FIGURAS

Figura 3.1. Flujo de procesos operacionales entre los componentes de un servicio

web.……………………………………………………………………. 12

Figura 3.2. Ejemplo que muestra los elementos que conforman un documento WSDL. …………………………………………………………………

19

Figura 3.3. La Plataforma .NET.…………………………………………………… 24 Figura 4.1. Diagrama de actividades de la solución general del problema………… 26 Figura 4.2. Modelo conceptual de la herramienta Web Services Compositor.……. 27 Figura 4.2. Ventana donde se muestran algunos servicios web que se encuentran

en el servidor Axis……………………………………………………... 28 Figura 4.3. Documento WSDL del servicio web MyServicioUno, visto desde un

navegador……………………………………………………………… 30 Figura 4.4. Documento WSDL del servicio web MyServicioDos, visto desde un

navegador………………………………………………………………

31 Figura 4.5. Ventana donde se introduce la URL del documento WSDL del

servicio web a ser compuesto para su análisis…………………………

32 Figura 4.6. Ventana donde se muestran los métodos extraídos del documento

WSDL de cada servicio web a ser compuesto………………………… 33 Figura 4.7. Ventana que muestra en la parte media, la selección de los métodos de

los dos servicios web…………………………………………………..

34 Figura 4.8. Documento xml con la composición de los métodos de cada servicio 35

CENIDET 2006 iii

web…………………………………………………………………….. Figura 4.9. Código Stubs de los servicios web WS_Suma y WS_Media………….. 36 Figura 4.10. Ventana que muestra en la parte inferior la secuencia de los métodos

de los servicios web WS_Suma y WS_Media………………………....

37 Figura 4.11. Archivo cliente de la composición de los servicios web

MyServicioUno y MyServicioDos…...………………………………...

38 Figura 4.13. Diagrama general de casos de uso de la herramienta………………… 39 Figura 4.14. Diagrama de clases que muestra la arquitectura general de la

herramienta…………………………………………………………….. 40 Figura 4.15. Diagrama de secuencias general de la herramienta………………….. 42 Figura 4.16. Diagrama de secuencias del método AbrirDocumento( ) de la clase

AnalizaWDSL…………………………………………………………. 43 Figura 4.17. Diagrama de secuencias del método LeeBasicos() de la clase

AnalizaWSDL donde los datos básicos de los documentos WSDL de los servicios web son nombre del servicio y dirección………………...

43 Figura 4.18. Diagrama de secuencias del método LeeOperaciones() de la clase

AnalizaWSDL, donde las operaciones son los nombres de los métodos que están descritos en los documentos WSDL de los servicios web…..

44 Figura 4.19. Diagrama de secuencias del método Valida_Vector()………………. 44 Figura 4.20. Diagrama de secuencias de los objetos de la clase MenuPrincipal….. 45 Figura 5.1. Selección de los servicios WS_Suma y WS_Media…………………… 48 Figura 5.2. Código Stubs para la composición de los servicios WS_Suma y

WS_Media……………………………………………………………...

50 Figura 5.3. Código Cliente en la parte superior, y en la parte inferior ventana de

ejecución de los archivos resultantes de la composición de los servicios WS_Suma y WS_Media, con el conjunto de datos No. 1……





53 Figura 5.6. Selección de los servicios WS_AreaRectangulo y

WS_PerimetroRectangulo……………………………………………...

55 Figuara 5.7. Código Stubs para la composición de los servicios

WS_AreaRectangulo y WS_PerimetroRectangulo……………………………………………...

57

Figura 5.8. Código Cliente en la parte superior, y en la parte inferior ventana de ejecución de los archivos resultantes de la composición de los servicios WS_AreaRectangulo y WS_PerimetroRectangulo, con el conjunto de datos No. 1………………………………………………...


ejecución de los archivos resultantes de la composición de los servicios WS_AreaRectangulo y WS_PerimetroRectangulo, con el conjunto de datos No. 2………………………………………………...


CENIDET 2006 iv

ejecución de los archivos resultantes de la composición de los servicios WS_AreaRectangulo y WS_PerimetroRectangulo, con el conjunto de datos No. 3………………………………………………...

60 Figura 5.11. Selección de los servicios WS_AreaTriangulo y

WS_PerimetroTriangulo……………………………………………….

62 Figura 5.12. Código Stubs para la composición de los servicios

WS_AreaTriangulo y WS_PerimetroTriangulo………………………..


ejecución de los archivos resultantes de la composición de los servicios WS_AreaTriangulo y WS_PerimetroTriangulo, con el conjunto de datos No. 1………………………………………………...


ejecución de los archivos resultantes de la composición de los servicios WS_AreaTriangulo y WS_PerimetroTriangulo, con el conjunto de datos No. 2………………………………………………...


ejecución de los archivos resultantes de la composición de los servicios WS_AreaTriangulo y WS_PerimetroTriangulo, con el conjunto de datos No. 3………………………………………………..

67 Figura 5.19. Selección de los servicios WS_AreaCuadrado y WS_AreaCirculo….. 69 Figura 5.20. Código Cliente para la composición de los servicios

WS_AreaCuadrado y WS_AreaCirculo………………………………..


ejecución de los archivos resultantes de la composición de los servicios WS_AreaCuadrado y WS_AreaCirculo, con el conjunto de datos No. 1……………………………………………………………...


ejecución de los archivos resultantes de la composición de los servicios WS_AreaCuadrado y WS_AreaCirculo, con el conjunto de datos No. 2……………………………………………………………..


ejecución de los archivos resultantes de la composición de los servicios WS_AreaCuadrado y WS_AreaCirculo, con el conjunto de datos No. 3……………………………………………………………..

75 Figura A1. Árbol de directorio del servidor Axis integrado al servidor Tomcat y

las bibliotecas jar necesarias…………………………………………...

83 Figura A2. Iniciando el servidor Tomcat, en forma manual desde una ventan de

ms-dos………………………………………………………………….

84 Figura A3. Iniciando el servidor Tomcat, en forma automática desde Windows….. 84 Figura A4. Muestra la página index.htm, lo cual indica que se ha instalado

correctamente el servidor Axis…………………………………………

85 Figura A5. Comando desde la consola para realizar el despliegue del servicio de

Web mediante el archivo deployMyprueba.wsdd……………………...

86 Figura A6. El servidor Axis despliega un listado de los servicios de Web

disponibles……………………………………………………………...

87

CENIDET 2006 v

ÍNDICE DE TABLAS Tabla 4.1. Descripción de Casos de uso del diagrama general de la herramienta…. 39 Tabla. 5.1. Tabla de resultados esperados del caso de prueba 1…………………… 53 Tabla. 5.2. Tabla de resultados esperados del caso de prueba 2…………………… 60 Tabla. 5.3. Tabla de resultados esperados del caso de prueba 3…………………… 67 Tabla. 5.4. Tabla de resultados esperados del caso de prueba 4…………………… 74 Tabla A1. Variables de entorno de Java a configurar……………………………… 81 Tabla A2. Variables de entorno API JDOM a configurar………………………….. 82

GLOSARIO DE TÉRMINOS

• RPC: Remote procedure call, (procedimiento de llamadas remoto). • Servicio Web: colección de funciones que se empaquetan como una sola entidad y

son publicadas en la red para ser usadas por aplicaciones cliente. • SOAP: Simple Object Access Protocol (Protocolo de Acceso para Objetos Simples). • UDDI: Universal Discovery and Description. (Definición para descubrimiento e

integración de Servicios Web) • UML: Unified Modeling Language. (Lenguaje de modelado unificado). • W3C: World Wide Web Consortium. Agrupación encargada de llevar estándares

que se ejecutan a través de la Internet. • WSDL: Web Service Definition Lenguaje (Lenguaje para Definición de Servicios

Web).

CENIDET 2006 vi

Anexo A

INSTALACIÓN DE HERRAMIENTAS

A.1. Procedimiento de instalación de las herramientas. A.1.1. Requerimientos y herramientas. A.1.2. Procedimiento de instalación.

A.2. Ejemplo de la publicación de un servicio de Web con Apache Axis. A.2.1. Requerimientos y herramientas. A.2.2. Instalación del servidor Axís e integración con el servidor Tomcat. A.2.3. Pasos para crear un servicio web.

Referencias.

Anexo A: Instalación de Herramientas. A.1. Procedimiento de instalación de las herramientas.

A.1.1. Requerimientos y herramientas. Los requerimientos mínimos para hacer pruebas del sistema son:

• PC con procesador Pentium III a 750 Mhz o superior. • Espacio en disco de 1 Gb por lo menos libre. • 256 Mb de Memoria RAM. • Windows 2000 o XP versión profesional.

Las herramientas a instalar son:

• Java Development Kit (J2SDK SE), version 1.4.0_02, Sun Microsystems [1]. • Eclipse, como entorno de programación. IBM Corporation [2]. • API JDOM, version 2.0 [3].

A.1.2. Procedimiento de instalación. Pasos para la instalación de las herramientas.

1. Para instalar Java Development Kit, en su versión estándar, solamente hay que bajar la versión señalada del sitio de Sun Microsystems, tal proyecto puede trabajar con una versión posterior del JDK, pero no de una inferior. La instalación es muy sencilla debido a que la herramienta contiene un asistente de instalación, en la carpeta java (C:\java\) por default.

2. Editar variables de entorno, estas se encuentran dentro de propiedades del sistema (clic derecho sobre Mi PC y selecciona propiedades) y después seleccionamos opciones avanzadas y la pestaña de variables de entorno.

Variable Valor

JAVA_HOME C:\ruta de java\ CLASSPATH C:\ruta de java\lib\classes.zip PATH C:\ruta de java\bin

Tabla A1. Variables de entorno de Java a configurar.

3. Como entorno integrado de desarrollo (IDE) de Java, se usa Eclipse, que es un IDE gratuito para Java, otra ventaja es que no incorpora API´s propias como otros lenguajes basados en Java. No requiere de instalación, únicamente se descomprime el archivo en la ruta (C:\Eclipse\) ahí mismo se desempaquetan las carpetas propias del eclipse, y al momento de ejecutar el archivo .exe, busca la versión de Java y el lugar donde esté instalado.

4. La API JDOM la podemos descargar de la pagina oficial [3]. agregarla a las variables de entorno del sistema (clic derecho sobre Mi PC y seleccionar propiedades) y después seleccionamos opciones avanzadas y la pestaña de variables de entorno. Y ahí agregamos la ruta donde se encuentra la API JDOM.

Cenidet 2006 81

Anexo A: Instalación de Herramientas.

Variable Valor CLASSPATH C:\ruta de java\lib\classes.zip; C:\ruta API JDOM\jdom.jar

Tabla A2. Variables de entorno API JDOM a configurar. 5. Copiar el paquete que contiene la herramienta Web Services Compositor, dentro del

directorio Workspace de la ruta del Eclipse (C:\Eclipse\workspace\), y ejecutar la clase Menuprincipal para carga el sistema.

A.2. Ejemplo de la publicación de un servicio de Web con Apache Axis.

A.2.1. Requerimientos y herramientas. Los requerimientos mínimos para hacer pruebas del sistema son:

• PC con procesador Pentium IV a 2.8 Mhz o superior. • Espacio en disco de 1 Gb por lo menos libre. • 512 Mb de Memoria RAM. • Windows XP versión Profesional.

Las herramientas a instalar son:

• Java Development Kit (J2SDK SE), version 1.4.0_02, Sun Microsystems [1]. • Eclipse, como entorno de programación. IBM Corporation [2]. • Servidor Apache Tomcat versión 5.0 [4]. • Servidor Apache Axís 1.2_alpha [5].

Antes de empezar el ejemplo, será necesario instalar el servidor Apache Axis y realizar las configuraciones necesarias para el funcionamiento del servicio de Web. El siguiente listado muestra las herramientas que deben estar instaladas en la PC. El servidor Tomcat escucha por default en el puerto 8080:. Descargar y configurar el servidor Apache Axís:

1. Bibliotecas .jar que vienen con el servidor Axís: • Axis.jar • Axis_ant • Commons-discovery.jar • Commons-logging-api.jar • Log4j-1.2.8.jar • Saaj.jar • Wsdl4j.jar

2. Bibliotecas .jar que hay que descargar: • Activation.jar [11]. • Mailapi.jar [12].

Cenidet 2006 82


• Xerces.jar [13].

A.2.2. Instalación del servidor Axís e integración con el servidor Tomcat.

1. El servidor Apache Tomcat es muy fácil de instalar gracias a que la herramienta cuenta con un asistente de instalación, solo hay que seguirlo y elegir el directorio dónde se quiere instalarlo (C:\Tomcat 5.0\) seria el directosio por default.

2. Descomprimir el archivo zip del servidor Apache Axís y copiar la carpeta \axis dentro del directorio webapps del servidor Tomcat (C:\Tomcat 5.0\webapps) como se muestra en la figura A.1.

3. Copiar los archivos *.jar dentro del directorio home_tomcat/webapps/axis/WEB-INF/lib (C:\Tomcat\webapps\axis\WEB-INF\lib).

Figura A1. Árbol de directorio del servidor Axis integrado al servidor Tomcat y las bibliotecas jar necesarias.

4. Colocar la ruta absoluta de cada archivo jar en la variable de sistema CLASSPATH. 5. Crear el archivo axis.xml en el directorio home_tomcat/webapps/axis. El archivo debe

contener la siguiente información:

<Context path="/axis" docBase="../webapps/axis" debug="0" privileged="true"> </Context>

6. Iniciar el servidor Tomcat. Hay dos formas de iniciar el servidor la primera es manualmente y segunda es automáticamente.

a) Manualmente. Se abre una ventana de ms-dos, después se accesa al directorio

bin dentro de Tomcat (C:\Tomcat\bin\), y se ejecuta el archivo Startup.bat. Como se muestra en la figura A2.

Cenidet 2006 83


Figura A2. Iniciando el servidor Tomcat, en forma manual desde una ventan de ms-dos.

b) Automáticamente. Seleccionar del menú Inicio Programas. Como se muestra en la figura A3.

Figura A3. Iniciando el servidor Tomcat, en forma automática desde Windows.

Cenidet 2006 84


7. Colocar la URL http://localhost:8080/axis/ en el browser, con lo cual aparece la pantalla mostrada en la figura A.4. Lo anterior indica que el servidor Axis ya se encuentra en ejecución.

Figura A4. Muestra la página index.htm, lo cual indica que se ha instalado correctamente el

servidor Axis.

A.2.3. Pasos para crear un servicio web.

1. Implementar en el lenguaje Java las funciones que se desea desplegar como servicios de Web. Aquí se presenta el código del archivo Myprueba.java como ejemplo, donde la función implementada tiene la finalidad de crear un directorio en la ruta indicada por la variable path (el directorio es creado en la máquina donde se monte la función como un servicio de Web).

/* La función crea un directorio y retorna el valor de 1. Si el directorio existe devuelve 0. Si el path es un archivo devuelve 0 */

import java.io.*; public class Myprueba{ public int CreateDirectory(String path) { int valor_retorno=1; File objeto; objeto=new File(path);

Cenidet 2006 85


if (objeto.isFile()) {return 0;} if (objeto.isDirectory()) {return 0;} if (objeto.mkdirs()==false) {return 0;} return valor_retorno; } }

2. Compilar el archivo Myprueba.java. El archivo resultante Myprueba.class hay que moverlo al directorio home_tomcat/webapps/axis/WEB-INF/clases.

3. Crear un archivo con la extensión .wsdd para desplegar (deploy) la función como un

servicio de Web. Este archivo debe contener una estructura en etiquetas de XML, las cuales configuran al servidor Axís para dar de alta el servicio. A continuación presentamos la estructura del archivo DeployMyprueba.wsdd.

<deployment xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"> <service name="MyServiceDirectory" provider="java:RPC"> <parameter name="className" value="Myprueba"/> <parameter name="allowedMethods" value="*"/> </service> </deployment>

4. Ejecutar en la consola el comando mostrado en figura A5. Este proceso lee las

etiquetas de XML contenidas en el archivo deployMyprueba.wsdd y monta el servicio en el servidor Axis.

Figura A5. Comando desde la consola para realizar el despliegue del servicio de Web

mediante el archivo deployMyprueba.wsdd.

5. Una vez que el comando realizó su proceso, es necesario reiniciar el servidor Tomcat (para la versión 4.x) o reiniciar el servidor Axis (para la versión Tomcat 5.x).

6. Abrir el navegador y buscar la dirección http://localhost:8080/axis/servlet/AxisServlet.

La figura A.6 muestra ahora que nuestra función está disponible como un servicio de Web.

Cenidet 2006 86


Figura A6. El servidor Axis despliega un listado de los servicios de Web disponibles.

Los servicios web para los casos de prueba utilizados en el capitulo 5, fueron desarrollados y publicados de esta misma forma en un servidor Apache Axis similar.

Cenidet 2006 87


Referencias. 1. Java Developer Kit, versión 1.4, Sun Microsystems. http://java.sun.com/j2se/ 2. Proyecto Eclipse, Internacional Business Machines.http://www.eclipse.org/platform 3. API JDOM . http://www.jdom.org 4. Apache Tomcat, http://jakarta.apache.org/ 5. Axis para Apache Tomcat http://ws.apache.org/axis/java/install.html

Cenidet 2006 88

Capítulo 2

ANTECEDENTES

2.1. Introducción. 2.2. Estado del arte.

2.2.1. Trabajos relacionados. 2.2.2. Herramientas para Composición de Servicios Web. 2.2.3. Comparación entre la tesis y los trabajos analizados en el estado del arte.

2.3. Objetivos. 2.3.1. Objetivo General. 2.3.2. Objetivo Específico.

2.4. Descripción del problema. 2.5. Justificación del estudio. 2.6. Límites y alcances del estudio.

2.6.1. Limites del estudio. 2.6.2. Alcances del estudio.

Capítulo 2: Antecedentes 2.1. Introducción. En este capítulo se describe un estudio del estado del arte, comprendiendo trabajos relacionados y las herramientas comerciales más representativas, así como una comparación con este trabajo de tesis. También se describen los objetivos de la tesis, la descripción del problema, la justificación de este trabajo así como sus límites y alcances. 2.2. Estado del arte.

2.2.1. Trabajos relacionados. Alor y Olmedo [5] en su artículo presentan una revisión de las especificaciones o lenguajes que permiten la integración y la composición de servicios web como son: BPML, WSCI, XLANG, WSFL y BPEL4WS. Con la ayuda de los lenguajes de composición de servicios web, es posible diseñar y construir servicios web mas complejos a partir de la re-utilización de servicios web públicamente disponibles. Estos autores concluyen que es de suma importancia que el desarrollo de nuevas aplicaciones empiecen a diseñarse en torno a ésta nueva forma de realizar integración con el fin de ínter operar con otras ya existentes, ya que en un corto tiempo la mayoría de las aplicaciones disponibles en Internet utilizaran esta base tecnológica.

Ko y Neches [4] presentan en su artículo una herramienta para explorar, entender y registrar pasos de análisis en aplicaciones de administración de integración de información llamada Eurasia. Eurasia es un sistema de alto nivel que ayuda a los usuarios a explorar y probar en forma rápida varios servicios web de manera que ellos puedan componer aplicaciones a gran escala. Los desarrolladores pueden usar BPEL4WS o DAML-S como lenguaje subyacente para describir las aplicaciones de administración de información que utilizan servicios web.

Diversos proveedores de tecnologías de información como IBM, Microsoft y Sun MicroSystems han diseñado nuevos lenguajes y técnicas para llevar a cabo el proceso de composición de aplicaciones web. Chris Peltz [2] en su artículo menciona que Microsoft XLANG e IBM WSFL (Lenguaje de Flujo de Servicios Web) trabajan para diseñar un proceso estándar de negocios para integrar servicios web. Estas compañías están combinando estos estándares para formar el BPEL4WS (Lenguaje de Ejecución de Procesos de Negocios), mientras que HP esta desarrollando el WSCL (Lenguaje de Conversación de Servicios Web) con un entorno simple para modelar la secuencia de composición entre servicios web. El cual sometió al grupo de trabajo de coreografía de servicios web W3C.

Microsoft con XLANG [2] para su servidor Biz Talk, se enfoca en modelar el flujo de procesos secuencial, paralelo y condicional entre servicios web. Visual Studio.NET y el .NET Framework, son en conjunto los productos más importantes lanzados por Microsoft [3], en esta referencia se menciona como el primer ambiente de desarrollo totalmente integrado para construir servicios web XML y aplicaciones de Internet de siguiente generación. Visual Studio

Cenidet 2006 5

Capítulo 2: Antecedentes .NET y .NET Framework permitirán a los desarrolladores crear y utilizar servicios web XML sobre la plataforma .Net. Los servicios web XML proporcionan a los negocios una nueva forma de emplear el Internet como una plataforma de desarrollo y permite a los negocios interoperar a través de diversos sistemas y plataformas. Estos productos permiten a los desarrolladores extender sus habilidades existentes para abarcar el nuevo mundo de servicios web XML. IBM WSFL (Lenguaje de Flujo de Servicios Web), se enfoca en la creación de procesos de negocios e intercambio de mensajes entre servicios web [2]. WSFL es un lenguaje creado por IBM y diseñado exclusivamente para representar flujos de servicios web y de este modo facilitar la creación de orquestaciones de estos servicios. Se trata de un lenguaje muy sencillo y basado en XML [13].

2.2.2. Herramientas para Composición de Servicios Web. A continuación se describen las dos herramientas más representativas en el mercado para crear servicios web. Microsoft Visual Studio .Net [7] proporciona a los desarrolladores las más productivas herramientas para la construcción de la siguiente generación de aplicaciones para Microsoft Windows y el web. Visual Studio .Net, en su versión de arquitectura empresarial apoya a los desarrolladores del framework .Net al incluir capacidades adicionales para diseño, especificación, y comunicación de aplicaciones. Cuando los desarrolladores usan la arquitectura de Visual Studio .Net esperan obtener los siguientes beneficios:

• Diseñar visualmente servicios web. Definir claramente la aplicación y su funcionalidad, además de su arquitectura.

• Crear y entregar guías de arquitectura. Tomar ventaja de la aplicación de UML, que asegura que la arquitectura y funcionalidad son claramente documentadas y comunicadas antes de codificar.

• Utilizar una herramienta de plataforma abierta para construir servicios web. Usar plantillas empresariales para desarrollar guías y políticas, compartir el conocimiento de desarrolladores expertos y arquitecturas para miembros del equipo con menos experiencia.

• Crear frameworks de aplicaciones reutilizables para proyectos. Visual Studio .Net incluye diseñadores visuales para Windows, el web, manejo de datos, componentes de servidor que logran tareas de manera más eficiente que sus productos anteriores. El desarrollo con el framework .Net de Microsoft habilita la creación y uso de servicios web para construir la siguiente generación de aplicaciones basadas en Internet. Java de la empresa Sun Microsystems [8], trata acerca de la conversión de componentes empresariales propios (JavaBean empresariales) hacia servicios web, de alguna manera similar a Microsoft con COM, proponen una metodología para la conversión de tales herramientas. La metodología de conversión y un ejemplo sencillo son expuestas en su sitio web.

Cenidet 2006 6

Capítulo 2: Antecedentes Existe una página de Sun [9] que muestra la arquitectura de un servicio web, la manera en como trabajan sus interfaces, y como su metodología es usada para implementar componentes reutilizables. Es posible crear un componente empresarial Java (Javabean) que es fácilmente reutilizable como componente de un servicio web [10]. Para convertir estos componentes empresariales a servicios web, se puede crear un esquema XML genérico o usar un esquema público a través de objetos serializables en un dominio. Tal serialización de los objetos en ciertos dominios con XML es una representación de un estado del componente, y provee la facilidad de obtener un estado del componente en un formulario de XML. Una vez creado con XML un esquema genérico se puede representar cualquier información, también se pueden derivar de este mismo esquema otros esquemas más específicos.

2.2.3. Comparación entre la tesis y los trabajos analizados en el estado del arte. Todos los trabajos mencionados anteriormente están de acuerdo en la necesidad que hay de lograr la composición o integración de los servicios web. Las empresas están trabajando enfocándose a las necesidades individuales que tienen. La composición se realiza utilizando definiciones de procesos con BPEL4WS (Lenguaje de Ejecución de Procesos de Negocios de servicios web) proponiéndolo como un estándar. A diferencia de otros trabajos, el trabajo presentado en este documento de tesis no se basa en un lenguaje de definición de procesos de negocios, este trabajo consiste en la definición de un proceso para la composición de servicios web, y el desarrollo de una herramienta que habilite este proceso.

2.3. Objetivos.

2.3.1. Objetivo General. El objetivo de esta tesis es desarrollar un proceso para habilitar al desarrollador de software a crear aplicaciones informáticas reduciendo los costos de producción, aumentando la calidad de los productos y reduciendo también su complejidad, mediante la composición de servicios web, que proporcionen la funcionalidad que se requiere.

2.3.2. Objetivo Específico.

• Proponer un proceso para componer servicios web. • Desarrollar una herramienta para habilitar la composición de servicios web.

Cenidet 2006 7

Capítulo 2: Antecedentes 2.4. Descripción del problema. El problema que esta tesis resuelve, se presenta cuando un usuario requiere que varios servicios web colaboren para resolver su aplicación. Por lo tanto es necesario construir un software mediador que los comunique. 2.5. Justificación del estudio. Actualmente muchas de las aplicaciones que se desarrollan se basan en la tecnología web, por lo tanto requieren de servicios web para realizarlas. Dado que un servicio web esta construido normalmente como una unidad independiente, y muchas de las veces no resuelven las necesidades de aplicaciones por si mismos, sino que se requieren de varios servicios web para completarlas, es necesario contar con una proceso o serie de pasos a seguir y una herramienta que nos ayude, a integrar diferentes funcionalidades, por medio de la composición de servicios que se encuentran disponibles en la web.

2.6. Límites y alcances del estudio.

2.6.1. Limites del estudio.

• El planteamiento de un proceso para la composición de servicios web. • No se definirá un lenguaje de negocios para componer servicios web. • Se limitara la composición a dos servicios web. • Los servicios web que se utilizaran para pruebas fueron desarrollados en el CENIDET.

2.6.2. Alcances del estudio.

• Análisis de los métodos de composición de servicios web existentes. • Definir un proceso de composición de servicios web. • Realizar pruebas con dos servicios web. • Instrumentación del proceso para la composición de servicios web.

Cenidet 2006 8

Capítulo 3

MARCO TEÓRICO

3.1. Introducción. 3.2. Definición de Servicios Web.

3.2.1. Componentes de un Servicio Web. 3.2.2. Proceso de un Servicio Web.

3.3. Aplicaciones Web. 3.4. Composición. 3.5. Tecnología XML.

3.5.1. XML frente a HTML. 3.5.2. Usos de XML.

3.6. SOAP (Protocolo de Acceso para Objetos Simples). 3.6.1. Ventajas de SOAP respecto a otros protocolos.

3.7. UDDI (Descubrimiento, Descripción e Integración Universal). 3.7.1. Cómo funciona UDDI.

3.8. WSDL (Lenguaje para Definición de Servicios Web). 3.8.1. Elementos de un documento WSDL.

3.9. API JDOM. 3.9.1. Ventajas de JDOM. 3.9.1. Estructura de JDOM.

3.10. Axis de Apache Tomcat. 3.11. Microsoft Visual Studio .Net.

Capítulo 3: Marco Teórico 3.1. Introducción. En este capítulo se muestran las definiciones y conceptos que dan sustento a este trabajo. También se describen las herramientas y las tecnologías utilizadas, así como algunos componentes que habilitan la arquitectura orientada a servicios web. 3.2. Definición de Servicios Web. Un servicio web es una colección de funciones que son presentadas como una sola entidad y es anunciado en la red para ser usado por otros programas [1]. Un servicio web es un componente de software independiente de plataforma, implementación y lenguaje, que puede ser:

• Descrito usando un lenguaje de descripción de servicios web (WSDL). • Publicado en un registro de servicios. • Descubierto a través de un mecanismo estándar (tiempo de ejecución o tiempo de

diseño). • Invocado a través de una API declarada generalmente en la red. • Compuesto de otros servicios [2].

3.2.1. Componentes de un Servicio Web.

• Servicio. Un servicio es una aplicación ofrecida para ser utilizada por solicitantes que llenan los requisitos especificados por el proveedor de servicios. La implementación se realiza sobre una plataforma accesible en la red. El servicio se describe a través de un leguaje de descripción de servicio. Tanto la descripción como las políticas de uso se publican de antemano en un registro.

• Proveedor de Servicio. Desde el punto de vista comercial, es quien presta el servicio. Desde el punto de vista de arquitectura, es la plataforma que provee el servicio.

• Directorio de Servicios. Es un depósito de descripciones de servicios que puede ser consultado, donde los proveedores publican sus servicios y los solicitantes encuentran los servicios y los detalles para utilizarlos.

• Solicitante de Servicios (Cliente). Desde el punto de vista comercial, la empresa que requiere cierto servicio. Desde el punto de vista de la arquitectura, es la aplicación o cliente que busca e invoca un servicio [2].

3.2.2. Proceso de un Servicio Web.

La figura 3.1 muestra las relaciones operacionales entre los componentes de un servicio web. Primero el proveedor de servicios describe y publica su servicio a través de un documento de descripción WSDL en un directorio de servicios web, luego el cliente busca el servicio en un

Cenidet 2006 10

Capítulo 3: Marco Teórico directorio de servicios UDDI, después el cliente descarga la descripción del servicio que necesita, y al final se establece la comunicación entre el proveedor de servicios y el cliente por medio de SOAP.

Figura 3.1. Flujo de procesos operacionales entre los componentes de un servicio web. 3.3. Aplicaciones Web. En ingeniería del software una aplicación web es aquella que los usuarios usan desde un servidor web a través de Internet o de una intranet. Las aplicaciones web son populares debido a la ubicuidad del navegador como un cliente, a veces llamado cliente ligero. La habilidad para actualizar y mantener aplicaciones web sin distribuir e instalar software en miles de potenciales clientes es otra razón de su popularidad. Aplicaciones como los webmail, amazon.com y eBay son ejemplos bien conocidos de aplicaciones web, pero éstas tienen usos en otras áreas como los negocios y la ciencia, debido a las limitaciones inherentes de los actuales navegadores web [3]. En resumen, una aplicación web usa un sitio web como entrada (front-end) a una aplicación típica. Si no existe lógica del negocio en el servidor, el sistema no puede ser llamado aplicación web [2]. Bajo este concepto las aplicaciones web no sólo se encargan de desplegar información, sino que también, deben contener una lógica asociada que permita apoyar algún proceso propio de la lógica del negocio para el cual fue diseñada [4].

Cenidet 2006 11

Capítulo 3: Marco Teórico 3.4. Composición.

cción y efecto de componer. Arte de agrupar las figuras y accesorios para conseguir el mejor

esde dos puntos de vista la composición servicios web se describe de la siguiente forma, una

.5. Tecnología XML.

ML (Lenguaje de Marcado Extensible): fue creado al amparo del Word Wide Web

l Lenguaje de marcado extensible (XML) proporciona una forma de describir datos

a ventaja de XML sobre HTML es que separa la interfaz de usuario de los datos

continuación se presentan algunos puntos importantes que se deben tener en cuenta acerca

• XML no es un sustituto de HTML; de hecho, XML se puede considerar como un

• de un

• l lenguaje HTML, el autor de un esquema o documento define las

actual.

Aefecto, según lo que se haya de representar [14]. Des cuando se componen servicios web para resolver una aplicación, o sea que a partir de la composición de servios web se forma una aplicación por medio de diagramas de flujo, y el otro tipo de composición es cuando se componen servicios web para formar un nuevo servicio web, a este tipo se le llama de alto nivel, coordinando las interacciones entre los componentes de los servicios web. 3 XConsortium (W3C). Su desarrollo se comenzó en 1996 y la primera versión salió a la luz el 10 de febrero de 1998. La primera definición que apareció fue: Sistema para definir validar y compartir formatos de documentos en la web [5]. Eestructurados. A diferencia de las etiquetas HTML, que se utilizan básicamente para controlar la presentación y apariencia de los datos, las etiquetas XML se utilizan para definir la estructura y los tipos de datos de los propios datos. Lestructurados. Esta separación de datos de la presentación habilita la integración de datos desde diversos orígenes

3.5.1. XML frente a HTML. Ade la relación entre XML y HTML:

complemento de HTML. XML y HTML tienen objetivos distintos: HTML está diseñado para mostrar datos y se centra en la apariencia de los datos, mientras que XML está diseñado para describir datos y está centrado en lo que son los datos. Mientras que es posible utilizar las etiquetas XML para describir la estructuraelemento como un pedido, este lenguaje no contiene ningún código que se pueda utilizar para enviar ese pedido, procesarlo o asegurarse de que está completo. Otras personas deben escribir código para hacer realmente estas cosas con sus datos en formato XML. A diferencia deetiquetas XML y éstas son ilimitadas. Las etiquetas HTML están predefinidas; los autores de HTML sólo pueden utilizar etiquetas compatibles con el estándar HTML

Cenidet 2006 12

Capítulo 3: Marco Teórico 3.5.2. U

ilita el intercambio de información entre aplicaciones y para entornos Internet, Intranet y Extranet. Algunos ejemplos donde se

uede utilizar XML de acuerdo a [6] son:

egistro de citas o un pedido. • Aplicaciones web de Internet o Intranet que mueven datos .

persistente de un objeto o control ActiveX . ulta.

annel Definition Format,

n.

• tar con XML. web XML

Div saacuerdo

• Los formatos XML se basan en texto, que lo hacen más legible, fácil de documentar y,

ntos XML pueden utilizar mucha de la infraestructura ya creada para

idores de seguridad.

• s de XML para realizar alguna

3.6 O

para facilitar la llamada mota de funciones a través de Internet, permitiendo que dos programas se comuniquen de

na manera muy similar técnicamente a la invocación de páginas web.

OAP ha recibido gran tención debido a que facilita una comunicación del estilo RPC entre un cliente y un servidor

sos de XML.

El uso de Tecnología XML facsistemas heterogéneos p

• Un documento normal con etiquetas. • Un registro estructurado, como un r

• Un objeto con datos, como el formato • Un registro de datos, como el conjunto de resultados de una cons• Metacontenido acerca de un sitio web, como CDF (Ch

Formato de definición de canal). • Una presentación gráfica, como una interfaz de usuario de la aplicació• Vínculos entre información y personas del web.

Código C# que se puede documen• Documentos de descubrimiento utilizados para encontrar servicios

disponibles.

er s ventajas que XML tiene sobre otros formatos a la hora de almacenar informaciónde a [6] son:

a veces, más fácil de depurar. • Los docume

HTML, incluido el protocolo HTTP y algunos exploradores. HTTP permite que se transfiera XML a través de serv

• El análisis XML está perfectamente definido y ampliamente implementado, lo que posibilita la recuperación de información de documentos XML en diversos entornos. Las aplicaciones pueden confiar en los analizadorevalidación estructural, así como en la comprobación de tipo de datos (cuando se utilizan esquemas).

• XML se crea en una base Unicode, lo que facilita la creación de documentos estándar.

. S AP (Protocolo de Acceso para Objetos Simples). SOAP (Simple Object Access Protocol) es un protocolo elaborado reu En el núcleo de los servicios web se encuentra el protocolo simple de acceso a datos SOAP, que proporciona un mecanismo estándar de empaquetar mensajes. Saremoto. Pero existen multitud de protocolos creados para facilitar la comunicación entre aplicaciones, incluyendo RPC de Sun, DCE de Microsoft, RMI de Java y ORPC de CORBA.

Cenidet 2006 13

Capítulo 3: Marco Teórico Una de las razones principales del por qué SOAP ha llegado a ser importante, es por que ha recibido un increíble apoyo por parte de la industria. SOAP es el primer protocolo de su tipo que ha sido aceptado prácticamente por todas las grandes compañías de software del mundo.

tros protocolos.

Algunas de las Ventajas de SOAP son: arrolladores involucrados en nuevos

proyectos pueden elegir desarrollar con el último y mejor lenguaje de programación es son responsables de mantener esta preocupaciones,

•

• ente, reinventar las cosas. Optaron por

n sus necesidades. Por

•

municarse mediante mensaje SOAP con

Adicion lamar

nciones de manera remota como DCOM, CORBA o directamente en TCP/IP:

t forma parte, adoptado por W3C (http://www.w3.org/TR/SOAP/) y por varias otras empresas.

para casi todo: la comunicación se hace

Compañías que en raras ocasiones cooperan entre sí están ofreciendo su apoyo a este protocolo. Algunas de las más grandes compañías que soportan SOAP son Microsoft, IBM, SUN, Microsystems, SAP y Ariba [7].

3.6.1. Ventajas de SOAP respecto a o

• No esta asociado con ningún lenguaje: los des

que exista, pero los desarrolladorpodrían o no hacer esta elección sobre el lenguaje de programación que utilizan. SOAP no especifica una API, por lo que la implementación de la API se deja al lenguaje de programación, como en Java, y la plataforma como Microsoft .Net. No se encuentra fuertemente asociado a ningún protocolo de transporte. Un mensaje de SOAP no es más que un documento XML, por lo que puede transportarse utilizando cualquier protocolo capaz de transmitir texto.

• No está atado a ninguna infraestructura de objeto distribuido. Aprovecha los estándares existentes en la industria: Los principales contribuyentes a la especificación SOAP evitaron, intencionadamextender los estándares existentes para que coincidieran coejemplo, SOAP aprovecha XML para la codificación de los mensajes, en lugar de utilizar su propio sistema de tipos, que ya están definidos en la especificación del esquema de XML. Y como ya se ha mencionado SOAP no define un medio de trasporte de los mensajes; los mensajes de SOAP se pueden asociar a los protocolos de transporte existentes como HTTP y SMTP. Permite la interoperabilidad entre múltiples entornos: SOAP se desarrollo sobre los estándares existentes de la industria, por lo que las aplicaciones que se ejecuten en plataformas con dicho estándares pueden coaplicaciones que se ejecuten en otras plataformas. Por ejemplo, una aplicación de escritorio que se ejecute en una PC puede comunicarse con una aplicación del back-end ejecutándose en un mainframe capaz de enviar y recibir XML sobre HTTP.

almente, el protocolo SOAP tiene diversas ventajas sobre otras formas de lfu

• Es sencillo de implementar, probar y usar. • Es un estándar de la industria, creado por un consorcio del cual Microsof

• Utiliza los mismos estándares de la web mediante HTTP con paquetes virtualmente idénticos; los protocolos de autenticación y

Cenidet 2006 14

Capítulo 3: Marco Teórico

encriptación son los mismos; el mantenimiento de estado se hace de la misma forma; se implementa normalmente por el propio servidor web. Atraviesa "firewalls" y routers, que "piensan" que es una comunicación HTTP. Tanto los datos como las funciones se describen en X

• • ML, lo que permite que el

• ve). Ind en ML

escribe perfectamente los datos en tiempo de ejecución y evita los problemas ocasionados

os métodos disponibles a través de páginas XML accesibles por la web. La idea es la siguiente:

si cualquier ambiente de programación. ctualmente, existen diversos paquetes de desarrollo SOAP para diversos sistemas operativos

.7. UDDI (Descubrimiento, Descripción e Integración Universal).

permite la ublicación y localización de los servicios. Los directorios UDDI actúan como una guía de

bre empresas y los servicios que éstas ofrecen. A través de un UDDI, se puede publicar y

protocolo no sólo sea más fácil de utilizar sino que también sea muy sólido. • Es independiente del sistema operativo y procesador.

Se puede utilizar tanto de forma anónima como con autenticación (nombre/cla

ep dientemente de cómo se haga la solicitud, las respuestas siempre son en XML. Xdpor cambios inadvertidos en las funciones, ya que los objetos llamados tienen la posibilidad de validar siempre los argumentos de las funciones, haciendo que el protocolo sea muy sólido. Así mismo, SOAP define un estándar llamado WSDL, que describe perfectamente los objetyquien publica un servicio, crea también estas páginas. Quien quiera llamar el servicio, puede utilizar estas páginas como "documentación" de la llamada y también utilizarlas antes de llamar las funciones para verificar si cambió algo. SOAP se puede implementar fácilmente en caAy lenguajes de alto nivel [8]. 3 UDDI (Universal Description Discovery and Integration): Este protocolo pservicios web. Una vez definido el servicio web, es necesario darlo a conocer a la comunidad para que sepan de su existencia. Lógicamente, el siguiente paso consiste en definir cómo se dará a conocer el servicio web para que los clientes interesados puedan descubrirlo fácilmente y utilizarlo en sus aplicaciones. En la actualidad, ya existe un mecanismo de descubrimiento que cumple estos requisitos: UDDI una iniciativa del sector para hacer compatible el descubrimiento de servicios web con todo tipo de tecnologías y plataformas. UDDI es un registro público diseñado para almacenar de forma estructurada información sodescubrir información de una empresa y de sus servicios. Se pueden utilizar sistemas taxonómicos estándar para clasificar estos datos y poder encontrarlos posteriormente en función de la categorización. Lo más importante es que UDDI contiene información sobre las interfaces técnicas de los servicios de una empresa. A través de un conjunto de llamadas a API XML basadas en SOAP, se puede interactuar con UDDI tanto en tiempo de diseño como de ejecución para descubrir datos técnicos de los servicios que permitan invocarlos y utilizarlos. De este modo, UDDI sirve como infraestructura para una colección de software basado en servicios web [9].

Cenidet 2006 15

Capítulo 3: Marco Teórico La iniciativa UDDI surgió por varias empresas como, Microsoft, IBM, Sun, Oracle, Compaq, Hewlett Packard, Intel, SAP y unas trescientas más (un listado mas completo se puede ver en

comunidad del UDDI). Estas compañías unieron sus esfuerzos para desarrollar una

se pueden encontrar de forma sistemática y confiable en una capacidad universal talmente independiente de proveedores. Se pueden llevar a cabo búsquedas categóricas

La información de UDDI se aloja en nodos operadores. Los nodos operadores son empresas cutar un nodo público conforme a la especificación que rige el

onsorcio www.UDDI.org. En la actualidad existen dos nodos públicos que se ajustan a la

enta su nodo. El nodo sólo se debe ajustar a la especificación DDI. El nodo de Microsoft http://uddi.microsoft.com/default.aspx, por ejemplo, se ha escrito

ligero; se ha diseñado como registro, o como depósito. La diferencia, aunque sutil, resulta esencial. Un registro redirige al usuario

a recursos, mientras que un depósito sólo almacena información. El registro Microsoft®

laespecificación basada en estándares abiertos y tecnologías no propietarias que permitieran resolver varias necesidades. El resultado, cuya versión beta se lanzó en diciembre de 2000 y estaba en producción en mayo de 2001, fue un registro empresarial global alojado por varios nodos de operadores en el que los usuarios podían realizar búsquedas y publicaciones sin costo alguno. A partir de la creación de esta infraestructura para servicios web, los datos sobre estos servicios toprecisas utilizando sistemas de identificación y taxonómicos extensibles. La integración de UDDI en tiempo de ejecución se puede incorporar a las aplicaciones. Como resultado, se fomenta el desarrollo de un entorno de software de servicios web.

3.7.1. Cómo funciona UDDI.

que se han comprometido a ejecversión 1 de la especificación UDDI: Microsoft aloja uno e IBM el otro. Hewlett Packard se ha comprometido a alojar un nodo bajo la versión 2 de la especificación. Los operadores del host deben replicar datos entre ellos a través de un canal seguro, para conseguir la redundancia de la información en el registro UDDI. Se pueden publicar los datos en un nodo y descubrirlos en otro tras la réplica. Actualmente, la réplica se produce cada 24 horas. En el futuro, este intervalo entre réplicas se reducirá, ya que habrá más aplicaciones que dependan de los datos de UDDI. Resulta importante observar que no existen requisitos de propietario respecto al modo en que el operador del host implemUpor completo en C# y se ejecuta en tiempo real en lenguaje común .NET Beta 2. El código de base se beneficia claramente de la compatibilidad nativa con SOAP y de la serialización que ofrecen las clases de sistema .NET. En el lado del servidor, el nodo del operador Microsoft utiliza Microsoft® SQL Server 2000 como almacén de datos. No obstante, los dos nodos se comportan exactamente igual, ya que se ajustan al mismo conjunto de llamadas a API XML basadas en SOAP. Las herramientas de los clientes pueden interoperar con ambos nodos sin problemas. Por eso, el nodo público UDDI constituye un claro ejemplo de que el modelo de servicios web XML funciona en entornos heterogéneos. El siguiente paso para comprender la iniciativa UDDI consiste en ver qué datos se almacenan en UDDI y cómo se estructuran. UDDI es relativamente n

Cenidet 2006 16

Capítulo 3: Marco Teórico Windows® puede servir de ejemplo: contiene las configuraciones y parámetros básicos pero, en última instancia, su función es la de dirigir la aplicación a un recurso. Buscar un componente COM basándose en su Id. de programa conduce a un Id. de clase, que a su vez dirige a la ubicación del binario. UDDI se comporta de forma similar: como el registro de Windows, se basa en identificadores únicos globales (GUID) para garantizar la capacidad de búsquedas y determinar la ubicación de recursos. En última instancia, las consultas a UDDI conducen a una interfaz (un archivo

SDL, .XSD, .DTD, etc.) o a una implementación (como un archivo .ASMX o .ASP)

SDL (Web Services Description Language) define los servicios como colecciones de puntos de mensajes se separa

de la i stalación concreta de red o de los enlaces del formato de datos. Esto permite la utilización de definiciones abstractas de los datos que se están intercambiando y tipos de

os datos que se están comunicando. • <operation>: descripción abstracta de una acción admitida por el servicio.

erto

de red.

.Wubicadas en otro servidor [9]. 3.8. WSDL (Lenguaje para Definición de Servicios Web).

Wde red o puertos. En WSDL, la definición abstracta de puntos finales y

nrepuertos, que son colecciones abstractas de operaciones como se muestra en el ejemplo de un documento WSDL en la figura 3.2. Las especificaciones concretas del protocolo y del formato de datos para un tipo de puerto determinado constituyen un enlace reutilizable. Un puerto se define por la asociación de una dirección de red y un enlace reutilizable; una colección de puertos define un servicio. Por esta razón, un documento WSDL utiliza los siguientes elementos en la definición de servicios de red [10]:

• <types>: contenedor de definiciones del tipo de datos que utiliza algún sistema de tipos (por ejemplo XSD).

• <message>: definición abstracta y escrita de l

• <port Type>: conjunto abstracto de operaciones admitidas por uno o más puntos finales.

• <binding>: especificación del protocolo y del formato de datos para un tipo de pudeterminado.

• <port>: punto final único que se define como la combinación de un enlace y una dirección

• <service>: colección de puntos finales relacionados.

Cenidet 2006 17

Capítulo 3: Marco Teórico <?xml version="1.0" encoding="UTF-8" ?>

- <wsdl:definitions targetNamespace="http://xml.apache.org/axis/wsdd/" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="http://xml.apache.org/axis/wsdd/" xmlns:intf="http://xml.apache.org/axis/wsdd/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

-  - <wsdl:types>- <schema targetNamespace="http://xml.apache.org/axis/wsdd/"

xmlns="http://www.w3.org/2001/XMLSchema"> <element name="AdminService" type="xsd:anyType" /> <element name="AdminServiceReturn" type="xsd:anyType" />

</schema> </wsdl:types>

- <wsdl:message name="AdminServiceRequest"> <wsdl:part element="impl:AdminService" name="part" />

</wsdl:message>- <wsdl:message name="AdminServiceResponse"> <wsdl:part element="impl:AdminServiceReturn" name="AdminServiceReturn" />

</wsdl:message>- <wsdl:portType name="Admin">- <wsdl:operation name="AdminService"> <wsdl:input message="impl:AdminServiceRequest" name="AdminServiceRequest" /> <wsdl:output message="impl:AdminServiceResponse" name="AdminServiceResponse" />

</wsdl:operation> </wsdl:portType>

- <wsdl:binding name="AdminServiceSoapBinding" type="impl:Admin"> <wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" /> - <wsdl:operation name="AdminService"> <wsdlsoap:operation soapAction="" /> - <wsdl:input name="AdminServiceRequest"> <wsdlsoap:body use="literal" />

</wsdl:input>- <wsdl:output name="AdminServiceResponse"> <wsdlsoap:body use="literal" />

</wsdl:output> </wsdl:operation> </wsdl:binding>

- <wsdl:service name="AdminService">- <wsdl:port binding="impl:AdminServiceSoapBinding" name="AdminService"> <wsdlsoap:address location="http://192.168.190.82:8080/axis/services/AdminService" />

</wsdl:port> </wsdl:service> </wsdl:definitions>

Figura 3.2. Ejemplo que muestra los elementos que conforman un documento WSDL.

3.8.1. Elementos de un documento WSDL. Elemento <types> El elemento <types> contiene información de esquema referenciado en el documento WSDL. El sistema de tipos predeterminado que admite WSDL es de esquema de XML. Si se usa el

Cenidet 2006 18

Capítulo 3: Marco Teórico esquema de XML para definir los tipos que contiene el elemento <types> el elemento schema aparecerá inmediatamente como elemento hijo. Se pueden utilizar otros sistemas de tipo por extensión. Si se desea utilizar otro sistema de tipo puede aparecer un elemento de extensibilidad bajo el elemento <Types>. El nombre de este elemento debería identificar el sistema de tipos utilizados. En esta tesis el esquema utilizado es XML porque es el sistema de tipos dominante en los documento WSDL. Elemento <message> El elemento <message> proporciona una abstracción común para el paso de mensajes entre el cliente y el servidor. Debido a que puede utilizar múltiples formatos de definición de esquema en un documento WSDL, es necesario de disponer de un mecanismo común de identificar los mensajes. El elemento <message> proporciona este nivel común de abstracción al que se hará referencia en otras partes del documento WSDL. Múltiples elementos <message> pueden aparecer en un documento WSDL, uno para cada mensaje que se comunica entre el cliente y el servidor. Cada mensaje contiene uno o más elementos <part> que describen las piezas del contenido del mensaje. Un ejemplo de una parte es el cuerpo de un mensaje de SOAP o un parámetro que forma parte de una cadena de petición, un parámetro codificado en el cuerpo del mensaje de SOAP o todo el cuerpo de un mensaje de SOAP. Elemento <portType> El elemento <porType> contiene un conjunto de operaciones abstractas que representan los tipos de correspondencia que pueden producirse entre el cliente y el servidor. Para los servicios web de estilo RPC se puede pensar en un <porType> como una definición donde cada método se puede definir como una operación. Un tipo <porType> se compone de un conjunto de elementos <operation> que define una determinada acción. Los elementos <operation> se componen de mensajes definidos en el documento WSDL. WSDL define los siguientes cuatro tipos de operaciones:

• Request-response (petición-respuesta). Comunicación del tipo RPC en la que el cliente realiza una petición y el servidor envía la correspondiente respuesta.

• One-way (un-sentido). Comunicación del estilo del documento en la que el cliente envía un mensaje pero no recibe una respuesta del servidor indicando el resultado del mensaje procesado.

• Solicit-response (solicitud-respuesta). Comunicación del tipo RPC en la que el servidor envía una petición y el cliente le envía de vuelta una respuesta.

• Notification (Notificación). Comunicación del estilo documento en la que el servidor envía una comunicación del estilo documento al cliente pero no recibe una respuesta del servidor indicando el resultado del mensaje procesado.

Cenidet 2006 19

Capítulo 3: Marco Teórico Elemento <binding> El elemento <binding> contiene las definiciones de la asociación de un protocolo como SOAP a un determinado <bindingType>. Las definiciones <binding> especifican detalles de formatos del mensaje y el protocolo. Por ejemplo, la información de asociación especifica si se puede acceder a una instancia de un <portType> de forma RPC. Las definiciones <binding> también indican el número de comunicaciones de red que se requieren para realizar una determinada acción. Por ejemplo, una llamada RPC de SOAP sobre HTTP podría involucrar un intercambio de comunicación HTTP, pero esa misma llamada sobre SMTP podría involucrar dos intercambios de comunicaciones de SMTP discretas. La asociación se logra utilizando elementos de extensión. Cada protocolo tiene su propio conjunto de elementos de extensión para especificar los detalles del protocolo y el formato de los mensajes. Para un determinado protocolo los elementos de extensión se suelen utilizar para decorar las acciones individuales de una operación y la propia operación con la información de asociación del protocolo. A veces los elementos de extensión se utilizan en el propio nivel <portType>. Elemento <service> Un servicio es un grupo de puertos relacionados y se definen en el elemento <service>. Un puerto es un extremo concreto de un servicio web al que se hace referencia por una dirección única. Los puertos que se definen en determinado servicio son independientes. Por ejemplo, la salida de un puerto que no puede utilizarse como una entrada de otro. Elementos de Extensibilidad Los elementos de extensibilidad se utilizan para representar determinadas tecnologías. Por ejemplo, se pueden utilizar los elementos de extensibilidad para especificar el idioma que se utiliza en el esquema de los elementos <types>. Lo más habitual es que los elementos de extensibilidad se utilicen para especificación de asociación. La especificación WSDL define conjunto de elementos de extensibilidad para la asociación SOAP, HTTP GET, HTTP POS, MIME. Sin embargo, la especificación sólo define las asociaciones para dos de los cuatro tipos de operaciones. Request-response y One-way [10].

Cenidet 2006 20

Capítulo 3: Marco Teórico 3.9. API JDOM. La API JDOM comprende una especificación con retroalimentación y soporte que define la funcionalidad para una visión muy somera de un documento XML y también incluye un comportamiento estándar adecuado de entrada y salida para crear un objeto Document JDOM a partir de los datos existentes en XML y escribe los datos del Document en cualquier destino especificado. La implementación de referencia contenida en el paquete org.jdom es un producto totalmente trabajado en la versión 1.0 y en la actualidad está disponible en la dirección: http://www.jdom.org/ JDOM, intenta solucionar las diferencias ya conocidas en SAX, DOM Y JAXP [13]. JDOM es un API para leer, crear y manipular documentos XML de una manera sencilla y muy intuitiva para cualquier programador en Java. Al contrario de otras APIs tales como DOM y SAX, las cuales se idearon sin pensar en ningún lenguaje en concreto, de ahí que resulte un poco incomodo su utilización. DOM y SAX son dos especificaciones que como tal no podemos trabajar con ellas, pero si con las implementaciones de dichas especificaciones, es decir, los parsers: Xerces, XML4j, Crimson, Oracle's parsers, etc. JDOM utiliza por default el analizador Xerces.

3.9.1. Ventajas de JDOM. La API JDOM no es un parser, en realidad, usa un parser para su trabajo. JDOM solamente aporta una capa de abstracción en el tratado de documentos XML facilitándo bastante la tarea. Para poder trabajar con XML desde Java.

• En JDOM no hace falta usar el método Factory ni otros modelos avanzados de programación para crear un Document, cosa que si hay que hacer en DOM.

• DOM no tiene una manera estándar de crear un Document, cada parser tiene implementado sus métodos específicos, siendo programas dependientes del parser utilizado. Es muy cierto que para solventar este problema Sun ideo la API JAXP, pero tiene el inconveniente de que no todos los parses tienen soporte JAXP.

• Debido a que el Node de DOM es siempre construido a través del método factoría de su padre <Document>, se presenta el viejo problema del huevo y la gallina, ya que un Element tiene que ser construido con un Document, pero un Document no debería existir sin un Element que sea su raíz.

• Con SAX no la comparamos en este aspecto ya que dicha API es solo de lectura.

3.9.1. Estructura de JDOM. La API JDOM está formada por 5 paquetes. De entre ellos comentamos lo siguiente que será más que suficiente para utilizar la API.

Cenidet 2006 21


• El paquete org.jdom destacamos las clases: Document que representará el documento XML, Element que representará el elemento o etiqueta que forma el documento, y la clase Attribute que representa los atributos que puedan tener los elementos.

• El paquete org.jdom.adapters contiene todas las clases adaptadoras (ver patrón de diseño Adapter, Thinking in patterns) ya que no todos los parsers DOM tienen la misma API.

• El paquete org.jdom.input contiene las clases builder para construir los documentos XML.

• El paquete org.jdom.output contiene las clases que utilizaremos para dar salida a la clase Document.

3.10. Axis de Apache Tomcat. El software Open Source, ha probado su fiabilidad a millones de usuarios en todo el mundo, además, ha demostrado ser fiable y tener infinitud de grandes funcionalidades, según una encuesta realizada entre grandes compañías Europeas. Por eso, grandes empresas de sectores como el de las Telecomunicaciones, Financiero, Distribución, Energía y sobre todo Administraciones Públicas, están poniendo en marcha políticas de implantación de software de código abierto. A nivel mundial, nombres como Yahoo!, Google, AOL, Amazon, NASA, IBM, Compaq, HP… han apostado por el software Open Source como parte de su estrategia corporativa. Axis es una implementación Open-Source de un "SOAP Engine"; a través de este componente es posible llevar acabo una comunicación mediante "Web-Services" una de las variaciones más prometedoras del lenguaje XML . En el caso de "Axis", éste se encuentra diseñado para ser ejecutado dentro de un "Java Application Server" o bien un "Servlet Engine" como Tomcat ; aunque hoy en día ya existen otros "SOAP Engines" que pueden ser ejecutados de manera independiente de un "Java Application Server" o "Servlet Engine", al residir un "SOAP Engine" dentro estos, se permite que métodos residentes puedan ser publicados como "Web-Services" y de esta manera ser accesibles de otras plataformas/lenguajes que también soporten "SOAP" [11]. 3.11. Microsoft Visual Studio .Net. El objetivo de la plataforma .NET es simplificar el desarrollo de aplicaciones web. Provee las herramientas y tecnologías para transformar a Internet en una plataforma de computación distribuida en gran escala. Esta plataforma además soporta los estándares sobre los cuales se basan los servicios web.

Cenidet 2006 22


Figura 3.3. La Plataforma .NET. La plataforma .NET utiliza tecnologías existentes, productos modificados para su uso dentro de la plataforma y elementos nuevos. Productos existentes: COM. Microsoft tiene una tecnología para la creación, invocación y uso de componentes llamada COM (Modelo de Objetos Componentes). Al igual que el protocolo SOAP utilizado para la invocación de los servicios web, COM establece las reglas acerca de cómo los objetos deben ser invocados y cómo deben interactuar. También los componentes COM pueden implementar funcionalidad similar a la de los servicios web. Sin embargo tienen dos puntos en contra. Primero: No son una tecnología estándar. Segundo: No pueden ser utilizados fuera de la barrera de seguridad que las empresas tienen para su comunicación hacia y desde Internet (firewall). Por lo tanto no sirven al modelo de computación distribuida en Internet. Sin embargo, hay muchas soluciones que usan COM en el mercado. La plataforma .NET puede por medio de clases especiales hacer uso de COM y los objetos COM también pueden hacer uso de servicios web. Lo que permite aprovechar la plataforma instalada para el desarrollo de nuevos proyectos. Productos Modificados: La familia de sistemas operativos de Windows 2000 fue modificada para soportar a la plataforma .NET. También todos los productos de servidores de aplicaciones fueron modificados para permitir la interoperatividad basada en XML. Elementos Nuevos: BizTalk Server es un producto pensado para entender y manipular datos en formato XML y para poder transformar datos en XML a otros formatos y viceversa. Permite coordinar el flujo de información entre aplicaciones dentro de la empresa y también "orquesta" el flujo de datos con otras empresas. De ahí que se califique a su función como "orquestación". Algo muy importante actualmente ya que las distintas aplicaciones deben comunicarse entre sí y muchas veces los formatos de los datos son incompatibles. El .NET Framework es una tecnología nueva de Microsoft y por su importancia merece que la estudiemos con detenimiento [12].

Cenidet 2006 23

Capítulo 4

DEFINICIÓN DEL PROCESO Y

DESARROLLO DE LA HERRAMIENTA

4.1. Introducción. 4.2. Proceso Metodológico para Componer Servicios Web. 4.3. Modelo conceptual de la herramienta. 4.4. Descripción de la herramienta Web Services Compositor.

4.4.1. Selección de los servicios web. 4.4.2. Acceso y análisis de los documentos WSDL de los servicios web. 4.4.3. Presentación de los nombres de los métodos y los parámetros de entrada y salida. 4.4.4. Selección de los métodos de los servicios web. 4.4.5. Generación del código para habilitar la composición de los servicios web. 4.4.6. Generación del código cliente que integra los servicios web.

4.5. Diseño de la herramienta utilizando casos de uso 4.5.1. Diagrama de Clases 4.5.1.1 Descripción de la Responsabilidad de Cada Clase. 4.5.1.2. Diagramas de Secuencias.

4.6. Conclusión del proceso y desarrollo de la herramienta.

Capítulo 4: Definición del Proceso y Desarrollo de la Herramienta

4.1. Introducción. En este capítulo se describe el proceso propuesto para realizar la composición de dos servicios web. Se describe también la herramienta desarrollada llamada Web Services Compositor. Las herramientas de trabajo utilizadas fueron el kit de desarrollo para Java de Sun Microsystems, el plugin Eclipse para Java, además del contenedor Web Axis de Apache Tomcat. En la sección 4.2 se describe los pasos a seguir para el desarrollo de la composición de los servicios web. En la sección 4.3 se describe el modelo conceptual de la herramienta. La sección 4.4 describe la herramienta Web Services Compositor y el caso de prueba de los servicios web: WebServiceSuma y WebServiceMedia. 4.2. Proceso Metodológico para Componer Servicios Web.

El proceso consiste de 6 actividades principales que se muestran el la figura 4.1

1. Selección de los servicios web.

2. Acceso y análisis de los documentos WSDL.

3. Presentación de los nombres de los

4. Selección de los métodos de los servicios web.

5. Generación del código para habilitar la composición de los servicios web

6. Generación del código cliente que integra los servicios web.

métodos, y parámetros de entrada y salida.

Figura 4.1. Diagrama de actividades de la solución general del problema.

Cenidet 2006 25


4.3. Modelo conceptual de la herramienta. En la figura 4.2 se muestra el diseño conceptual de la herramienta Web Services Compositor, el diseño consta de tres módulos principales.

• Módulo analizador WSDL.- utilizando la API JDOM, el analizador accede a los documentos WSDL, el análisis se realiza con un recorrido del documento WSDL en forma de árbol, para extraer la información necesaria tal como el nombre del servicio web, la dirección donde se encuentra y el puerto, los métodos con sus parámetros de entrada y salida si existen.

• Módulo de la interfaz.- es con la que el usuario interactúa para especificar primero las direcciones URL donde se encuentran los documentos WSDL y así de esta manera el módulo analizador pueda extraer la información que se requiere para llevar acabo la función de composición. También en la interfaz es donde el usuario va a seleccionar los métodos de cada servicio web a componer así como la secuencia de composición.

• Módulo composición.- en este módulo se genera el documento .xml de composición, el código stubs, y el código del cascarón del cliente composición.

• Documento xml.- en este documento de nombre composición.xml podemos encontrar la información necesaria de cada método seleccionado de los servicios web a ser compuestos, para que posteriormente el usuario pueda completar el cascarón del código cliente con los datos o tipo de parámetros que enviamos a los servicios web y los que recibimos respectivamente.

• Código stubs.- el archivo de Stubs contiene el código que establece la conexión entre los servicios web a componer con el código cliente.

• Cliente composición.- el archivo cliente es un cascarón que se genera tomando la secuencia que el usuario selecciona en la interfaz gráfica de la herramienta.

MODULO ANALIZADOR

DE WSDL

MODULO DE COMPOSICION

Datos de los servicios web

Selección de la secuencia de servicios web

Generación de Stubs

Generación de Cliente

Figura 4.2. Modelo conceptual de la herramienta Web Services Compositor.

Cenidet 2006 26


4.4. Descripción de la herramienta Web Services Compositor. Las actividades del diagrama de la figura 4.1 se describen a continuación:

4.4.1. Selección de los servicios web. La selección de los servicios web a ser compuestos la hace directamente el desarrollador de aplicaciones. La selección es basada en la funcionalidad de los servicios. En este caso se utilizaron los servicios web desarrollados en el CENIDET y ubicados en un servidor Axis como se muestra en la Figura 4.2.

Figura 4.2. Ventana donde se muestran algunos servicios web que se encuentran en el servidor Axis.

Cenidet 2006 27


4.4.2. Acceso y análisis de los documentos WSDL de los servicios web. Este acceso se realiza por medio de la dirección URL que se encuentra especificada en un repositorio UDDI. En las figuras 4.3 y 4.4 se muestra como se visualiza un documento WSDL desde el navegador, especificando su ruta de acceso URL. El análisis del documento WSDL de los servicios web seleccionados se hace con el propósito de obtener información acerca de los servicios web a ser compuestos, tal como los nombres de los métodos los parámetros de entrada y salida, y la dirección y el puerto de los servicios. Esta actividad es soportada por la API JDOM. En la figura 4.5 se muestra la interfaz en donde el usuario introduce la URL del documento WSDL donde se encuentran los servicios web.

Cenidet 2006 28


Figura 4.3. Documento WSDL del servicio web MyServicioUno, visto desde un navegador.

Cenidet 2006 29


Figura 4.4. Documento WSDL del servicio web MyServicioDos, visto desde un navegador.

Cenidet 2006 30


Figura 4.5. Ventana donde se introduce la URL del documento WSDL del servicio web a ser compuesto para su análisis.

4.4.3. Presentación de los nombres de los métodos y los parámetros de entrada y salida.

Esta información es presentada al desarrollador para la selección de la composición de los servicios web. Los nombres de los métodos y sus parámetros se muestran en las 2 cajas de la parte superior de la figura 4.6. Los nombres int addnumber(double in), double getsuma() e int inicializarSuma(), son los nombres de los métodos que corresponden a uno de los servicios web a ser compuestos MySumaService (WS_Suma). Los métodos int add(), double getMedia(double in), int inicializarMedia() e int getCantidad() corresponden al otro servicio web a ser compuesto MyMediaService (WS_Media), cada nombre de método se almacena en un arreglo como un objeto que contiene su propio nombre de servicio, su dirección y puerto, así como sus parámetros correspondientes.

Cenidet 2006 31


Figura 4.6. Ventana donde se muestran los métodos extraídos del documento WSDL de cada servicio web a ser compuesto.

4.4.4. Selección de los métodos de los servicios web. Una vez que la información de los servicios web a componer es mostrada como en la figura 4.6, el desarrollador puede seleccionar los métodos de la lista de cada servicio web. Los métodos seleccionados aparecerán mostrando de que documento WSDL son seleccionados, por ejemplo WSDL1 pertenece a WS_Suma y WSDL2 pertenece a WS_Media, como se muestra en la figura 4.7 en la parte media de la interfaz. Los métodos seleccionados de los dos servicios web se agregan a un vector para generar el documento xml y el archivo de stubs.

Cenidet 2006 32


Figura 4.7. Ventana que muestra en la parte media, la selección de los métodos de los dos servicios web.

4.4.5. Generación del código para habilitar la composición de los servicios web. En la figura 4.8 se muestra el documento xml con la composición de los métodos de cada servicio web, este es generado automáticamente por la herramienta después de seleccionar los métodos a componer. Las etiquetas que se definieron se describen a continuación.

- <Composition> esta etiqueta es la raíz del documento. - <Services> esta etiqueta esta contenida dentro de la raíz y cada una contiene un

método y sus datos. - <Operation name> esta etiqueta contiene el nombre de la operación o método del

servicio web elegido. - <ParametrosIn name> esta etiqueta contiene los nombres de los parámetros de

entrada y sus tipos que recibe esta método como es nombres y tipo de datos. En caso de que el método seleccionado lo tuviera.

- <ParametroOut name> > esta etiqueta contiene el nombre del parámetro y su tipo de salida del método, como es nombre y tipo de dato.

- <Service name> esta etiqueta contiene el nombre del servicio al cual pertenece el método.

Cenidet 2006 33


- <Port Location> esta etiqueta contiene la dirección y el puerto en le cual se encuentra el servicio web.

Figura 4.8. Documento xml con la composición de los métodos de cada servicio web.

Una vez que los métodos que se usarán en la composición son seleccionados, es necesario generar el código del mediador conocido como stubs. Los stubs ayudarán al código cliente a conectarnos a los servicios de Web a ser compuestos. En la figura 4.9 se muestra parte de un código de stubs de los servicios web WS_Suma y WS_Media, este es generado automáticamente por la herramienta después de generar el documento xml.

Cenidet 2006 34


package pruebaStub; import org.apache.axis.client.Call; import org.apache.axis.client.Service; import org.apache.axis.encoding.XMLType; import javax.xml.rpc.ParameterMode; public class Stubs_MIservicioMediaService_MiservicioSumaService{ Service myservicio=null; Call mycall=null; public Stubs_MIservicioMediaService_MiservicioSumaService() { try{ myservicio= new Service(); mycall = (Call) myservicio.createCall(); mycall.setMaintainSession(true); }catch (Exception e){mycall=null;} } public int inicializarSuma() { int respuesta = 0; try{ mycall.removeAllParameters(); String endpoint = "http://192.168.200.13:8080/axis/services/MySumaService"; mycall.setTargetEndpointAddress( new java.net.URL(endpoint) ); mycall.setOperationName("inicializarSuma"); mycall.setReturnType( XMLType.XSD_INT); Integer r =(Integer) mycall.invoke( new Object[]{}); respuesta = r.intValue(); }catch(Exception e){System.out.println(e.toString());} return respuesta; } public double getSuma() { ... } public int add() { ... } public double getMedia(double in0) { ... } public int inicializarMedia() { ... } public int getCantidad() { ... } public int addnumber(double in0) { ... } }

Figura 4.9. Código Stubs de los servicios web WS_Suma y WS_Media.

4.4.6. Generación del código cliente que integra los servicios web. Después de que los stubs son generados, el desarrollador deberá seleccionar la secuencia de composición de los servicios. En la parte inferior de la figura 4.10, se muestra la secuencia de composición de los servicios web. En esta parte la secuencia se define de acuerdo a como aparecen los métodos de los servicios web. Esta secuencia se va a utilizar para generar la plantilla de código cliente.

Cenidet 2006 35


Figura 4.10. Ventana que muestra en la parte inferior la secuencia de los métodos de los servicios web WS_Suma y WS_Media.

Cenidet 2006 36


Figura 4.11. Archivo cliente de la composición de lo

MyServicioD

La figura 4.11 muestra el archivo cliente de la composcomo la secuencia de invocación de los servicios web. Earchivos:

• El documento composition.xml. Se muestra en la• El archivo de código Stubs_MIservicioMediaSer

muestra en la figura 4.9. • El archivo cascarón del código Cliente_WS_Med

muestra en la figura 4.11. 4.5. Diseño de la herramienta utilizando casos En la figura 4.13 se muestra el diagrama general dinteracción del cliente con la herramienta desarrollada. de suso de la figura 4.13.

Cenidet 2006

Aquí podemos ver la secuencia deinvocación de cada una de los métodos. InicializarSuma() ServicioWebUno InicializarMedia() ServicioWebDos Add() ServicioWebDos addNumbre() ServicioWebUno Add() ServicioWebDos addNumbre() ServicioWebUno Add() ServicioWebDos addNumbre() ServicioWebUno getSuma() ServicioWebUno getMedia()ServicioWebDos

s servicios web MyServicioUno y os.

ición, viéndolo desde punto de vista l resultado obtenido son los siguientes

figura 4.8. vice_MiservicioSumaService.java. Se

iaService_WS_SumaService.java. Se

de uso

e casos de uso, el cual muestra la En la tabla 4.1 se describen los casos

37


Mostrar_Metodos

Analizar_WSDL

Actor

Generar_Stubs

Generar_Cliente_Composición

Analizar_SW

<<include>>

<<include>>

Generar_XML

Componer_SW

<<include>>

<<include>>

<<include>>

<<include>>

Figura 4.13. Diagrama general de casos de uso de la herramienta.

Casos de Uso Descripción: Precondiciones Condición Final de Éxito

Componer_SW

Crea documento XML, el código Stubs y el

código cliente composición.

Haber ejecutado el caso de uso

Analizar_SW

Generar doc.XML, Generar Stub

Generar Cliente Composición.

Analizar_SW Analiza documentos WSDL, y extrae sus

datos.

Debe existir el URL del WSDL

Obtener los datos del documento WSDL.

Generar_XML Genera el documento XML

Seleccionar los métodos de los servicios web

Genera docuemto XML.

Generador_Stub Genera código Stubs Seleccionar los métodos de los servicios web

Crear el archivo de código Stub

Genarador_Cliente Genera el cascarón del código cliente

Seleccionar la secuencia de

invocación de los métodos

Crear el archivo de código del cascarón del

cliente

Tabla 4.1. Descripción de Casos de uso del diagrama general de la herramienta.

Cenidet 2006 38


4.5.1. Diagrama de Clases En la figura 4.14 se muestra el diagrama de clases que representa la estructura de la herramienta Web Services Compositor. Las clases más importantes se describen en el siguiente apartado.

MenuPrincipal

main()

ButtonFrame

ButtonFrame()$f rame

CrearXML

XML_iniciar_documento()XML_open_method()XML_add_parameterIn()XML_add_parameterOut()XML_close_method()XML_crear_documento()XML_add_serv ice_port()

SAXBuilderM

obtenTipoConf iguracion : jav a.util.Propertiesarchiv o : String = "tipos.properties"

obtenTipo()ObtenerTipo()

ObtenTipoVConf iguracion : jav a.util.Propertiesarchiv o : String = "tipo_v ariable.properties"

ObtenTipoV()ObtenerTipo()

AnalizadorWSDLlocation : String = ""Nombre_Serv icio : String = ""numero_operaciones : int = 0

AbrirDocumento()LeeBasicos()LeeOperaciones()getObjects()

builder

ButtonPanelv ector_composicion : jav a.util.Vector = nullv ector_composicion_secuencia : jav a.util.Vector = null

ButtonPanel()actionPerf ormed()PedirWSDL()Valida_Vector()

buttonPanel

my documento

wsdl

GenerardorStubv ector_composicion : jav a.util.Vector = null

GenerardorStub()crear()

ObtenerTipoObtenerTipoV

GeneradorClientev ector_composicion_secuencia : jav a.util.Vector = null

GeneradorCliente()crear()

PFuncionnombre_serv icio : StringDireccion : Stringnombre_f uncion : StringParametroOut : Stringparametros : jav a.util.Vector

PFuncion()setNombre_f uncion()getNombre_f uncion()setDireccion()getDireccion()setNombre_serv icio()getNombre_serv icio()setParametroOut()getParametroOut()setParamerterIn()setParamerterIn()getParameterIn()getCantParametros()

array f unciones[]

-af 1[]-af 2

-ObjFuncionSelect

FuncionStubs FuncionStubs

Figura 4.14. Diagrama de clases que muestra la arquitectura general de la herramienta.

4.5.1.1 Descripción de la Responsabilidad de Cada Clase. MenuPrincipal es la clase principal que tiene método el main() el cual crea un objeto de tipo ButtonFrame el cual es un objeto de tipo ButtonPanel para la interfaz gráfica.

Cenidet 2006 39


ButtonFrame es la clase en la cual se crea un objeto de tipo ButtonPanel para presentar la interfaz gráfica. ButtonPanel en esta clase se crean los objetos que contiene el panel, también se instancia la clase AnalizaWSDL para leer los documentos WSDL de los servicios web seleccionados los cuales se almacenan en forma de objetos en la clase PFuncion y así validar el vector composición el cual contiene los métodos que son seleccionados de cada servicio. Pfuncion esta clase es la clase de arreglos donde se almacenan los objetos que contienen nombre de función, nombre de servicios web y su dirección. AnalizaWSDL en esta clase esta implementado el análisis de los documentos WDSL en forma de recorrido de un árbol, esta clase contiene un método AbrirDocumento() el cual abre el documento WSDL de la URL que el usuario proporciona desde la interfaz de la herramienta. El método LeeBasicos() lee los datos básicos como son: nombre del servicio, dirección y puerto. También contiene un método llamado LeeOperaciones() el cual lee los métodos que tiene descritos el servicio web así como sus parámetros y tipo de dato respectivamente, almacenándolos en un objeto de tipo Pfuncion, el cual tiene asociados su respectivo nombre de servicio web, dirección y puerto. CrearXML esta clase genera el documento xml, el cual contiene la información de los servicios web a componer, así como también toda la información extraída de ellos. GeneradorStub esta clase tiene un método Crear(). Este método crea un archivo donde se envía la información necesaria para generar el código stubs con cada uno método de los servicios web que selecciona el usuario desde la interfaz de la herramienta. GeneradorCliente en esta clase el método Crear(), crea un archivo donde se envía la información necesaria para generar el código cascarón del cliente el cual toma la secuencia de invocación de los métodos de los servicios web seleccionados por el usuario en la interfaz la de la herramienta.

4.5.1.2. Diagramas de Secuencias.

En esta sección se presentan los diagramas de secuencias que muestran las interacciones entre los objetos para llevar acabo las funciones de la herramienta.

Cenidet 2006 40


Figura 4.15. Diagrama de secuencias general de la herramienta.

Cenidet 2006 41


Figura 4.16. Diagrama de secuencias del método AbrirDocumento( ) de la clase

AnalizaWDSL.

Figura 4.17. Diagrama de secuencias del método LeeBasicos() de la clase AnalizaWSDL

donde los datos básicos de los documentos WSDL de los servicios web son nombre del servicio y dirección.

Cenidet 2006 42


Figura 4.18. Diagrama de secuencias del método LeeOperaciones() de la clase

AnalizaWSDL, donde las operaciones son los nombres de los métodos que están descritos en los documentos WSDL de los servicios web.

Figura 4.19. Diagrama de secuencias del método Valida_Vector().

Cenidet 2006 43


Figura 4.20. Diagrama de secuencias de los objetos de la clase MenuPrincipal.

4.6. Conclusión del proceso y desarrollo de la herramienta. El proceso desarrollado en esta tesis y que se describe la sección 4.2 de éste capítulo, fue esencial e importante ya que sobre este se diseño y desarrollo la herramienta Web Services Compositor. Fue importante porque permitió definir el conjunto de actividades que se deben realizar para identificar, seleccionar y componer servicios web. También mencionar que las operaciones de composición que se pueden realizar con la herramienta Web Services Compositor son en secuencia y sincronizadas.

Cenidet 2006 44

Capítulo 5

PRUEBAS

5.1. Introducción. 5.2. Composición de los servicios web WS_Suma y WS_Media.

5.2.1. Objetivo. 5.2.2. Descripción. 5.2.3. Resultado de la prueba. 5.2.4. Evaluación de resultados.

5.3. Composición de los servicios web WS_AreaRectangulo y WS_PerimetroRectangulo.

5.3.1. Objetivo. 5.3.2. Descripción. 5.3.3. Resultado de la prueba. 5.3.4. Evaluación de resultados.

5.4. Composición de los servicios web WS_AreaTriangulo y WS_PerimetroTriangulo. 5.4.1. Objetivo. 5.4.2. Descripción. 5.4.3. Resultado de la prueba. 5.4.4. Evaluación de resultados.

5.5. Composición de los servicios web WS_AreaCuadrado y WS_AreaCirculo. 5.5.1. Objetivo. 5.5.2. Descripción. 5.5.3. Resultado de las pruebas. 5.5.4. Evaluación de resultados.

Capítulo 5: Pruebas del Sistema 5.1. Introducción. En este capítulo se describen las pruebas realizadas con la herramienta Web Services Compositor. Tambien se Incluye una descripción de la funcionalidad de cada servicio web, objetivo de la prueba, resultados esperados, resultados obtenidos y la evaluación en cada prueba realizada con los servicios web. 5.2. Composición de los servicios web WS_Suma y WS_Media.

5.2.1. Objetivo. Sumar y obtener la media de 3 conjuntos de números, utilizando 2 servicios web que son independientes.

5.2.2. Descripción. Los servicios WS_Suma y WS_Media, se encuentran en un servidor web Axis. El servicio web WS_Suma se usa para sumar datos, y el servicio web WS_Media se usa para calcular la media de datos. Ambos servicios son independientes. Un servicio web calcula solo la suma, mientras que el otro necesita saber el total de la suma más el número de elementos que se sumaron para obtener el cálculo de la media. Para las pruebas fueron utilizados con 3 conjuntos de datos diferentes. Los métodos compuestos de cada servicio son:

• WS_Suma servicio web que contiene los métodos: inicializarSuma() el cual inicializa las parámetros del servicio, addnumber() el cual recibe los datos a sumar y getSuma() devuelve la suma de los datos. De este servicio se utilizaron los 3 métodos.

• WS_Media servicio web que contiene los métodos: inicializarMedia() el cual inicializa las parámetros del servicio, add() es un contador del numero de datos, getCantidad() regresa la cantidad de datos que tiene el contador y getMedia() devuelve la media de los datos. De este servicio solo se utilizaron 3 métodos inicializaMedia(), add() y getMedia().

Conjuntos de datos:

1. 1, 2, 3 y 4. 2. 20, 35, 45.8 y 18. 3. 88.88, 350.00, 405.80 y 222.22.

5.2.3. Resultado de la prueba. Fue posible lograr la composición de la funcionalidad de estos dos servicios web y obtener los resultados correctos de esta composición, invocando los métodos seleccionados de estos dos servicios en la secuencia elegida.

1ª Prueba calcular la suma de los datos que es = 10, y luego calcular la media de números que es = 3.75. Los resultados se muestran en la figura 5.3.

2ª Prueba la media = 29.7. Los resultados se muestran en la figura 5.4.

Cenidet 2006 47

Capítulo 5: Pruebas del Sistema

3ª Prueba la media = 266.72. Los resultados se muestran en la figura 5.5.

Figura. 5.1. Selección de los servicios WS_Suma y WS_Media.

Cenidet 2006 48


import org.apache.axis.client.Call; import org.apache.axis.client.Service; import org.apache.axis.encoding.XMLType; import javax.xml.rpc.ParameterMode; public class Stubs_MIservicioMediaService_MiservicioSumaService { Service myservicio=null; Call mycall=null; public Stubs_MIservicioMediaService_MiservicioSumaService() { try{ myservicio= new Service(); mycall = (Call) myservicio.createCall(); mycall.setMaintainSession(true); }catch (Exception e){mycall=null;} } public int addnumber(double in0) { int respuesta = 0; try{ mycall.removeAllParameters(); String endpoint = "http://127.0.0.1:8080/axis/services/MySumaService"; mycall.setTargetEndpointAddress( new java.net.URL(endpoint) ); mycall.setOperationName("addnumber"); mycall.addParameter("in0", XMLType.XSD_DOUBLE, ParameterMode.IN); mycall.setReturnType( XMLType.XSD_INT); Integer r =(Integer) mycall.invoke( new Object[]{new Double(in0)}); respuesta = r.intValue(); }catch(Exception e){System.out.println(e.toString());} return respuesta; } public double getSuma() { double respuesta = 0; try{ mycall.removeAllParameters(); String endpoint = "http://127.0.0.1:8080/axis/services/MySumaService"; mycall.setTargetEndpointAddress( new java.net.URL(endpoint) ); mycall.setOperationName("getSuma"); mycall.setReturnType( XMLType.XSD_DOUBLE); Double r =(Double) mycall.invoke( new Object[]{}); respuesta = r.doubleValue(); }catch(Exception e){System.out.println(e.toString());} return respuesta; } public int inicializarSuma() { int respuesta = 0; try{ mycall.removeAllParameters(); String endpoint = "http://127.0.0.1:8080/axis/services/MySumaService"; mycall.setTargetEndpointAddress( new java.net.URL(endpoint) ); mycall.setOperationName("inicializarSuma"); mycall.setReturnType( XMLType.XSD_INT); Integer r =(Integer) mycall.invoke( new Object[]{}); respuesta = r.intValue(); }catch(Exception e){System.out.println(e.toString());} return respuesta; }

public int add() { int respuesta = 0; try{ mycall.removeAllParameters(); String endpoint = "http://127.0.0.1:8080/axis/services/MyMediaService"; mycall.setTargetEndpointAddress( new java.net.URL(endpoint) ); mycall.setOperationName("add"); mycall.setReturnType( XMLType.XSD_INT); Integer r =(Integer) mycall.invoke( new Object[]{}); respuesta = r.intValue(); }catch(Exception e){System.out.println(e.toString());} return respuesta; }

. . .

Cenidet 2006 49


public double getMedia(double in0) { double respuesta = 0; try{ mycall.removeAllParameters(); String endpoint = "http://127.0.0.1:8080/axis/services/MyMediaService"; mycall.setTargetEndpointAddress( new java.net.URL(endpoint) ); mycall.setOperationName("getMedia"); mycall.addParameter("in0", XMLType.XSD_DOUBLE, ParameterMode.IN); mycall.setReturnType( XMLType.XSD_DOUBLE); Double r =(Double) mycall.invoke( new Object[]{new Double(in0)}); respuesta = r.doubleValue(); }catch(Exception e){System.out.println(e.toString());} return respuesta; } public int inicializarMedia() { int respuesta = 0; try{ mycall.removeAllParameters(); String endpoint = "http://127.0.0.1:8080/axis/services/MyMediaService"; mycall.setTargetEndpointAddress( new java.net.URL(endpoint) ); mycall.setOperationName("inicializarMedia"); mycall.setReturnType( XMLType.XSD_INT); Integer r =(Integer) mycall.invoke( new Object[]{}); respuesta = r.intValue(); }catch(Exception e){System.out.println(e.toString());} return respuesta; } public int getCantidad() { int respuesta = 0; try{ mycall.removeAllParameters(); String endpoint = "http://127.0.0.1:8080/axis/services/MyMediaService"; mycall.setTargetEndpointAddress( new java.net.URL(endpoint) ); mycall.setOperationName("getCantidad"); mycall.setReturnType( XMLType.XSD_INT); Integer r =(Integer) mycall.invoke( new Object[]{}); respuesta = r.intValue(); }catch(Exception e){System.out.println(e.toString());} return respuesta; } }

Figura. 5.2. Código Stubs para la composición de los servicios WS_Suma y WS_Media.

Cenidet 2006 50


Figura 5.3. Código Cliente en la parte superior, y en la parte inferior ventana de ejecución de los archivos resultantes de la composición de los servicios WS_Suma y WS_Media, con el

conjunto de datos No. 1.

Cenidet 2006 51




Cenidet 2006 52




5.2.4. Evaluación de resultados. Se calculo la suma y la media de 3 conjuntos de datos utilizando dos servicios web independientes. Los resultados fueron los esperados, y se muestran a continuación.

Resultado esperado Conjunto de Datos Media Media 1 3.75 3.75 2 29.70 29.70 3 266.725 266.725

Tabla. 5.1. Tabla de resultados esperados del caso de prueba 1.

Cenidet 2006 53

Capítulo 5: Pruebas del Sistema 5.3. Composición de los servicios web WS_AreaRectangulo y WS_PerimetroRectangulo.

5.3.1. Objetivo. Calcular el área y el perímetro de un rectángulo, utilizando 2 servicios web que son independientes.

5.3.2. Descripción. Los servicios WS_AreaRectangulo y WS_PerimetroRectangulo, se encuentran en un servidor web Axis. El servicio web WS_AreaRectangulo se utiliza para calcular el área de una figura de forma rectangular, y el servicio web WS_PerimetroRectangulo se usa para calcular el perímetro de una figura de forma rectangular. Un servicio web calcula solo el área de una superficie en forma rectangular, mientras que el otro calcula solo el perímetro de una superficie en forma rectangular. Para las prueba fueron utilizados 3 conjuntos de datos diferentes. Los métodos compuestos de cada servicio son:

• WS_AreaRectangulo servicio web que contiene los métodos: inicializarAreaR() el cual inicializa los parámetros del servicio, setMedidasAR() el cual recibe los datos de la figura, y getAreaR() devuelve el resultado calculado del área de la figura.

• WS_PerimetroRectangulo servicio web que contiene los métodos: inicializarPerR() el cual inicializa las parámetros del servicio, setMedidasPR() el cual recibe los datos de la de la figura, getPerimetroR() devuelve el resultado calculado del perímetro de la figura.

Conjuntos de datos:

1. base = 4.0 y altura = 2.0. 2. base = 60 y altura = 20. 3. base = 15 y altura = 30.


1ª Prueba calcular el área de un rectángulo y luego su perímetro, dando como

resultados área = 8, perímetro = 6. Los resultados se muestran en la figura 5.8. 2ª Prueba dio como resultados área = 1200.0, perímetro = 80.0. Los resultados se

muestran en la figura 5.9. 3ª Prueba dio como resultados área = 450.0, perímetro = 45.0. Los resultados se

muestran en la figura 5.10.

Cenidet 2006 54


Figura 5.6. Selección de los servicios WS_AreaRectangulo y WS_PerimetroRectangulo.

Cenidet 2006 55


import org.apache.axis.client.Call; import org.apache.axis.client.Service; import org.apache.axis.encoding.XMLType; import javax.xml.rpc.ParameterMode; public class Stubs_perimetroRectanguloService_areaRectanguloService { Service myservicio=null; Call mycall=null; public Stubs_perimetroRectanguloService_areaRectanguloService() { try{ myservicio= new Service(); mycall = (Call) myservicio.createCall(); mycall.setMaintainSession(true); }catch (Exception e){mycall=null;} } public int setMedidasAR(double in0, double in1) { int respuesta = 0; try{ mycall.removeAllParameters(); String endpoint = "http://192.168.190.82:8080/axis/services/AreaRectanguloService"; mycall.setTargetEndpointAddress( new java.net.URL(endpoint) ); mycall.setOperationName("setMedidasAR"); mycall.addParameter("in0", XMLType.XSD_DOUBLE, ParameterMode.IN); mycall.addParameter("in1", XMLType.XSD_DOUBLE, ParameterMode.IN); mycall.setReturnType( XMLType.XSD_INT); Integer r =(Integer) mycall.invoke( new Object[]{new Double(in0),new Double(in1)}); respuesta = r.intValue(); }catch(Exception e){System.out.println(e.toString());} return respuesta; } public double getAreaR() { double respuesta = 0; try{ mycall.removeAllParameters(); String endpoint = "http://192.168.190.82:8080/axis/services/AreaRectanguloService"; mycall.setTargetEndpointAddress( new java.net.URL(endpoint) ); mycall.setOperationName("getAreaR"); mycall.setReturnType( XMLType.XSD_DOUBLE); Double r =(Double) mycall.invoke( new Object[]{}); respuesta = r.doubleValue(); }catch(Exception e){System.out.println(e.toString());} return respuesta; } public int inicializarAreaR() { int respuesta = 0; try{ mycall.removeAllParameters(); String endpoint = "http://192.168.190.82:8080/axis/services/AreaRectanguloService"; mycall.setTargetEndpointAddress( new java.net.URL(endpoint) ); mycall.setOperationName("inicializarAreaR"); mycall.setReturnType( XMLType.XSD_INT); Integer r =(Integer) mycall.invoke( new Object[]{}); respuesta = r.intValue(); }catch(Exception e){System.out.println(e.toString());} return respuesta; } public int setMedidasPR(double in0, double in1) { int respuesta = 0; try{ mycall.removeAllParameters(); String endpoint = "http://192.168.190.82:8080/axis/services/PerimetroRectanguloService"; mycall.setTargetEndpointAddress( new java.net.URL(endpoint) ); mycall.setOperationName("setMedidasPR"); mycall.addParameter("in0", XMLType.XSD_DOUBLE, ParameterMode.IN); mycall.addParameter("in1", XMLType.XSD_DOUBLE, ParameterMode.IN); mycall.setReturnType( XMLType.XSD_INT); Integer r =(Integer) mycall.invoke( new Object[]{new Double(in0),new Double(in1)}); respuesta = r.intValue(); }catch(Exception e){System.out.println(e.toString());} }

return respuesta;

. . .

Cenidet 2006 56


public double getPerimetroR() { double respuesta = 0; try{ mycall.removeAllParameters(); String endpoint = "http://192.168.190.82:8080/axis/services/PerimetroRectanguloService"; mycall.setTargetEndpointAddress( new java.net.URL(endpoint) ); mycall.setOperationName("getPerimetroR"); mycall.setReturnType( XMLType.XSD_DOUBLE); Double r =(Double) mycall.invoke( new Object[]{}); respuesta = r.doubleValue(); }catch(Exception e){System.out.println(e.toString());} return respuesta; } public int inicializarPerR() { int respuesta = 0; try{ mycall.removeAllParameters(); String endpoint = "http://192.168.190.82:8080/axis/services/PerimetroRectanguloService"; mycall.setTargetEndpointAddress( new java.net.URL(endpoint) ); mycall.setOperationName("inicializarPerR"); mycall.setReturnType( XMLType.XSD_INT); Integer r =(Integer) mycall.invoke( new Object[]{}); respuesta = r.intValue(); }catch(Exception e){System.out.println(e.toString());} return respuesta; } }

Figura 5.7. Código Stubs para la composición de los servicios WS_AreaRectangulo y WS_PerimetroRectangulo.

Cenidet 2006 57


Figura 5.8. Código Cliente en la parte superior, y en la parte inferior ventana de ejecución de los archivos resultantes de la composición de los servicios WS_AreaRectangulo y

WS_PerimetroRectangulo, con el conjunto de datos No. 1.

Cenidet 2006 58




Cenidet 2006 59




5.3.4. Evaluación de resultados. Se calculo el área y el perímetro de 3 conjuntos de datos utilizando dos servicios web independientes. Los resultados fueron los esperados, y se muestran a continuación.

Resultado esperado Conjunto de Datos Área Perímetro Área Perímetro

1 8 6 8.0 6.0 2 1200.0 80.0 1200.0 80.0 3 450.0 45.0 450 45.0


Cenidet 2006 60

Capítulo 5: Pruebas del Sistema 5.4. Composición de los servicios web WS_AreaTriangulo y WS_PerimetroTriangulo.

5.4.1. Objetivo. Calcular el área y el perímetro de un triángulo, utilizando 2 servicios web que son independientes.

5.4.2. Descripción. Los servicios WS_AreaTriangulo y WS_PerimetroTriangulo, se encuentran en un servidor web Axis. El servicios web WS_AreaTriangulo se utiliza para calcular el área de una figura de forma triangular, y el servicio web WS_PerimetroTriangulo se utiliza para calcular el perímetro de una figura de forma triangular. Un servicio web calcula solo el área de una superficie en forma triangular, mientras que el otro calcula solo el perímetro de una superficie en forma triangular. Para las pruebas fueron utilizados 3 conjuntos de datos diferentes. Los métodos compuestos de cada servicio son:

• WS_AreaTriangulo servicio web que contiene los métodos: inicializarAreaT() el cual inicializa los parámetros del servicio, setMedidasAT() el cual recibe los datos de la figura, y getAreaT() devuelve el resultado calculado del área de la figura.

• WS_PerimetroTriangulo servicio web que contiene los métodos: inicializarPerT() el cual inicializa las parámetros del servicio, setMedidasPT() el cual recibe los datos de la de la figura, getPerimetroT() devuelve el resultado calculado del perímetro de la figura.

Conjuntos de datos:

1. base = 20 y altura = 35. 2. base = 200 y altura = 500. 3. base = 8 y altura = 15.


1ª Prueba calcular el área de un triangulo y luego su perímetro, dando como resultados área = 350.0, perímetro = 90.0. Los resultados se muestran en la figura 5.13.

2ª Prueba da como resultados área = 50000.0, perímetro = 1200.0. Los resultados se muestran en la figura 5.14.

3ª Prueba dio como resultados área = 60.0, perímetro = 38.0. Los resultados se muestran en la figura 5.15.

Cenidet 2006 61


Fig. 5.11. Selección de los servicios WS_AreaTriangulo y WS_PerimetroTriangulo.

Cenidet 2006 62


import org.apache.axis.client.Call; import org.apache.axis.client.Service; import org.apache.axis.encoding.XMLType; import javax.xml.rpc.ParameterMode; public class Stubs_perimetroTrianguloService_areaTrianguloService { Service myservicio=null; Call mycall=null; public Stubs_perimetroTrianguloService_areaTrianguloService() { try{ myservicio= new Service(); mycall = (Call) myservicio.createCall(); mycall.setMaintainSession(true); }catch (Exception e){mycall=null;} } public int setMedidasAT(double in0, double in1) { int respuesta = 0; try{ mycall.removeAllParameters(); String endpoint = "http://192.168.190.82:8080/axis/services/AreaTrianguloService"; mycall.setTargetEndpointAddress( new java.net.URL(endpoint) ); mycall.setOperationName("setMedidasAT"); mycall.addParameter("in0", XMLType.XSD_DOUBLE, ParameterMode.IN); mycall.addParameter("in1", XMLType.XSD_DOUBLE, ParameterMode.IN); mycall.setReturnType( XMLType.XSD_INT); Integer r =(Integer) mycall.invoke( new Object[]{new Double(in0),new Double(in1)}); respuesta = r.intValue(); }catch(Exception e){System.out.println(e.toString());} return respuesta; } public double getAreaT() { double respuesta = 0; try{ mycall.removeAllParameters(); String endpoint = "http://192.168.190.82:8080/axis/services/AreaTrianguloService"; mycall.setTargetEndpointAddress( new java.net.URL(endpoint) ); mycall.setOperationName("getAreaT"); mycall.setReturnType( XMLType.XSD_DOUBLE); Double r =(Double) mycall.invoke( new Object[]{}); respuesta = r.doubleValue(); }catch(Exception e){System.out.println(e.toString());} return respuesta; } public int inicializarAreaT() { int respuesta = 0; try{ mycall.removeAllParameters(); String endpoint = "http://192.168.190.82:8080/axis/services/AreaTrianguloService"; mycall.setTargetEndpointAddress( new java.net.URL(endpoint) ); mycall.setOperationName("inicializarAreaT"); mycall.setReturnType( XMLType.XSD_INT); Integer r =(Integer) mycall.invoke( new Object[]{}); respuesta = r.intValue(); }catch(Exception e){System.out.println(e.toString());} return respuesta; } public int setMedidasPT(double in0, double in1) { int respuesta = 0; try{ mycall.removeAllParameters(); String endpoint = "http://192.168.190.82:8080/axis/services/PerimetroTrianguloService"; mycall.setTargetEndpointAddress( new java.net.URL(endpoint) ); mycall.setOperationName("setMedidasPT"); mycall.addParameter("in0", XMLType.XSD_DOUBLE, ParameterMode.IN); mycall.addParameter("in1", XMLType.XSD_DOUBLE, ParameterMode.IN); mycall.setReturnType( XMLType.XSD_INT); Integer r =(Integer) mycall.invoke( new Object[]{new Double(in0),new Double(in1)}); respuesta = r.intValue(); }catch(Exception e){System.out.println(e.toString());} return respuesta; }

.

.

.

Cenidet 2006 63


public double getPerimetroT() { double respuesta = 0; try{ mycall.removeAllParameters(); String endpoint = "http://192.168.190.82:8080/axis/services/PerimetroTrianguloService"; mycall.setTargetEndpointAddress( new java.net.URL(endpoint) ); mycall.setOperationName("getPerimetroT"); mycall.setReturnType( XMLType.XSD_DOUBLE); Double r =(Double) mycall.invoke( new Object[]{}); respuesta = r.doubleValue(); }catch(Exception e){System.out.println(e.toString());} return respuesta; } public int inicializarPerT() { int respuesta = 0; try{ mycall.removeAllParameters(); String endpoint = "http://192.168.190.82:8080/axis/services/PerimetroTrianguloService"; mycall.setTargetEndpointAddress( new java.net.URL(endpoint) ); mycall.setOperationName("inicializarPerT"); mycall.setReturnType( XMLType.XSD_INT); Integer r =(Integer) mycall.invoke( new Object[]{}); respuesta = r.intValue(); }catch(Exception e){System.out.println(e.toString());} return respuesta; } }

Figura 5.12. Código Stubs para la composición de los servicios WS_AreaTriangulo y WS_PerimetroTriangulo.

Cenidet 2006 64


Figura 5.13. Código Cliente en la parte superior, y en la parte inferior ventana de ejecución de los archivos resultantes de la composición de los servicios WS_AreaTriangulo y

WS_PerimetroTriangulo, con el conjunto de datos No. 1.

Cenidet 2006 65




Cenidet 2006 66






1 350.0 90.0 350.0 90.0 2 50000.0 1200.0 50000.0 1200.0 3 60.0 38.0 60.0 38.0


Cenidet 2006 67

Capítulo 5: Pruebas del Sistema 5.5. Composición de los servicios web WS_AreaCuadrado y WS_AreaCirculo.

5.5.1. Objetivo. Calcular el área de una superficie de forma cuadrada y calcular el área de una superficie de forma triangular, utilizando 2 servicios web que son independientes.

5.5.2. Descripción. Los servicios WS_AreaCuadrado y WS_AreaCirculo, se encuentran en un servidor web Axis. El servicio web WS_AreaCuadrado se utiliza para calcular el área de una figura de forma cuadrada, y el servicio web WS_AreaCirculo este servicio se utiliza para calcular el área de una figura de forma circular. Un servicio web calcula solo el área de una superficie en forma triangular, mientras que el otro calcula s el área de una superficie en forma circular. Para las prueba fueron utilizados 3 conjuntos de datos diferentes. Los métodos compuestos de cada servicio son:

• WS_AreaCuadrado servicio web que contiene los métodos: inicializarAreaC() el cual inicializa los parámetros del servicio, setMedidasAC() el cual recibe los datos de la figura, y getAreaC() devuelve el resultado calculado del área de la figura.

• WS_AreaCirculo servicio web que contiene los métodos: inicializarAreaCir() el cual inicializa las parámetros del servicio, setMedidasACir() el cual recibe los datos de la de la figura, getAreaCir() devuelve el resultado calculado del perímetro de la figura.

Conjuntos de datos:

1. cuadrado lado = 10 y circulo radio = 8. 2. cuadrado lado = 35 y circulo radio = 20. 3. cuadrado lado = 15 y circulo radio = 42.

5.5.3. Resultado de las pruebas. Fue posible lograr la composición de la funcionalidad de estos dos servicios web y obtener los resultados correctos de esta composición, invocando los métodos seleccionados de estos dos servicios en la secuencia elegida.

1ª Prueba calcular el área de un cuadrado y luego el área de un circulo, dando como resultados área circulo = 201.0624, área cuadrado = 100.0. Los resultados se muestran en la figura 5.21.

2ª Prueba dando como resultados área circulo = 1256.63, área cuadrado = 1225.0. Los resultados se muestran en la figura 5.22.

Cenidet 2006 68


3ª Prueba dio como resultados área circulo = 5541.78, área cuadrado = 225.0. Los resultados se muestran en la figura 5.24.

Figura 5.19. Selección de los servicios WS_AreaCuadrado y WS_AreaCirculo.

Cenidet 2006 69


import org.apache.axis.client.Call; import org.apache.axis.client.Service; import org.apache.axis.encoding.XMLType; import javax.xml.rpc.ParameterMode; public class Stubs_areaCuadradoService_areaCirculoService { Service myservicio=null; Call mycall=null; public Stubs_areaCuadradoService_areaCirculoService() { try{ myservicio= new Service(); mycall = (Call) myservicio.createCall(); mycall.setMaintainSession(true); }catch (Exception e){mycall=null;} } public int setMedidasACir(double in0) { int respuesta = 0; try{ mycall.removeAllParameters(); String endpoint = "http://192.168.190.82:8080/axis/services/AreaCirculoService"; mycall.setTargetEndpointAddress( new java.net.URL(endpoint) ); mycall.setOperationName("setMedidasACir"); mycall.addParameter("in0", XMLType.XSD_DOUBLE, ParameterMode.IN); mycall.setReturnType( XMLType.XSD_INT); Integer r =(Integer) mycall.invoke( new Object[]{new Double(in0)}); respuesta = r.intValue(); }catch(Exception e){System.out.println(e.toString());} return respuesta; } public double getAreaCir() { double respuesta = 0; try{ mycall.removeAllParameters(); String endpoint = "http://192.168.190.82:8080/axis/services/AreaCirculoService"; mycall.setTargetEndpointAddress( new java.net.URL(endpoint) ); mycall.setOperationName("getAreaCir"); mycall.setReturnType( XMLType.XSD_DOUBLE); Double r =(Double) mycall.invoke( new Object[]{}); respuesta = r.doubleValue(); }catch(Exception e){System.out.println(e.toString());} return respuesta; } public int inicializarAreaCir() { int respuesta = 0; try{ mycall.removeAllParameters(); String endpoint = "http://192.168.190.82:8080/axis/services/AreaCirculoService"; mycall.setTargetEndpointAddress( new java.net.URL(endpoint) ); mycall.setOperationName("inicializarAreaCir"); mycall.setReturnType( XMLType.XSD_INT); Integer r =(Integer) mycall.invoke( new Object[]{}); respuesta = r.intValue(); }catch(Exception e){System.out.println(e.toString());} return respuesta; } public int setMedidasAC(double in0) { int respuesta = 0; try{ mycall.removeAllParameters(); String endpoint = "http://192.168.190.82:8080/axis/services/AreaCuadradoService"; mycall.setTargetEndpointAddress( new java.net.URL(endpoint) ); mycall.setOperationName("setMedidasAC"); mycall.addParameter("in0", XMLType.XSD_DOUBLE, ParameterMode.IN); mycall.setReturnType( XMLType.XSD_INT); Integer r =(Integer) mycall.invoke( new Object[]{new Double(in0)}); respuesta = r.intValue(); }catch(Exception e){System.out.println(e.toString());} return respuesta; }

.

.

.

Cenidet 2006 70


public double getAreaC() { double respuesta = 0; try{ mycall.removeAllParameters(); String endpoint = "http://192.168.190.82:8080/axis/services/AreaCuadradoService"; mycall.setTargetEndpointAddress( new java.net.URL(endpoint) ); mycall.setOperationName("getAreaC"); mycall.setReturnType( XMLType.XSD_DOUBLE); Double r =(Double) mycall.invoke( new Object[]{}); respuesta = r.doubleValue(); }catch(Exception e){System.out.println(e.toString());} return respuesta; } public int inicializarAreaC() { int respuesta = 0; try{ mycall.removeAllParameters(); String endpoint = "http://192.168.190.82:8080/axis/services/AreaCuadradoService"; mycall.setTargetEndpointAddress( new java.net.URL(endpoint) ); mycall.setOperationName("inicializarAreaC"); mycall.setReturnType( XMLType.XSD_INT); Integer r =(Integer) mycall.invoke( new Object[]{}); respuesta = r.intValue(); }catch(Exception e){System.out.println(e.toString());} return respuesta; } }

Figura 5.20. Código Cliente para la composición de los servicios WS_AreaCuadrado y

WS_AreaCirculo.

Cenidet 2006 71


Figura 5.21. Código Cliente en la parte superior, y en la parte inferior ventana de ejecución de los archivos resultantes de la composición de los servicios WS_AreaCuadrado y

WS_AreaCirculo, con el conjunto de datos No. 1.

Cenidet 2006 72




Cenidet 2006 73






1 8 6 8.0 6.0 2 1200.0 80.0 1200.0 80.0 3 450.0 45.0 450 45.0


5.5. Conclusión de las pruebas realizadas. En este capítulo podemos ver que los resultados esperados en cada una de las cuatro pruebas, fueron igual a los resultados obtenidos, con esto podemos concluir el correcto funcionamiento de la herramienta.

Cenidet 2006 74

Capítulo 6

CONCLUSIONES Y TRABAJO FUTURO

6.1. Conclusiones. 6.2. Trabajos futuros.

Capítulo 6: Conclusiones y Trabajo Futuro

6.1. Conclusiones. En el presente trabajo de tesis, se definió un proceso para la composición de servicios web y una herramienta que lo implementa. La herramienta se nombró Web Services Compositor. Las pruebas realizadas mostraron que siguiendo el proceso y utilizando la herramienta, la composición de los servicios web es factible y que la herramienta tuvo un funcionamiento correcto. Los objetivos de la tesis se cumplieron satisfactoriamente de acuerdo a lo planteado en la propuesta al inicio del proyecto. Gracias a la tesis se pudieron determinar horizontes para nuevos proyectos, al conocer ventajas y desventajas con el uso del proceso y de la herramienta. La más sobresaliente de las desventajas que se conocieron fué que la tecnología de Servicios Web no esta todavía bien alineada en la publicación y descripción de los servicios web y que hay diferencias en cada plataforma o ambiente de desarrollo. El código cliente generado por la herramienta y que corresponde a la última actividad del proceso de composición, corresponde al enfoque de composición de servicios web para ser integrados en una aplicación, no al de generación de un servicio web de alto nivel. El más importante de los beneficios de la tesis es contar con una herramienta que facilite la composición de los servicios web. Esto significa que es factible realizar una labor de reutilización de software. Lo anterior involucra un ahorro en tiempo de desarrollo y costo empleado en la creación de aplicaciones nuevas. Otras ventajas que se obtienen con el uso de la herramienta desarrollada en esta tesis, fueron las siguientes:

• La composición de servicios web es una manera de aprovechar las funcionalidades de los servicios web para soportar el desarrollo de aplicaciones en cualquier sistema operativo y lenguaje de programación.

• Para un desarrollador, componer servicios web es muy fácil y rápido, una vez que el análisis y la selección de métodos de los servicios web a utilizar se hayan realizado Este análisis y selección son las primeras actividades que el proceso definido permite llevar cabo con el uso de la herramienta. Después, sólo se tiene que dar la secuencia de los métodos de los servicios web a ser invocados. El documento XML generado por la herramienta puede ser usado como auxiliar para llenar el cascarón del código cliente. Además de estar en un formato estándar de XML

Dentro de las desventajas del trabajo desarrollado también se puede mencionar lo siguiente:

• La herramienta solamente analiza documentos WSDL generados por servidores Axis, ya que la descripción de los documentos WSDL de los servicios web es diferente en cada plataforma o ambiente de desarrollo, los elementos del documento WSDL pueden contener definiciones y ubicaciones diferentes. Sin embargo, se identificó la forma de analizar otro tipo de WSDL, aunque no se implementó en la herramienta.

• La interfaz de la herramienta esta limitada a componer solo dos servicios web. Aunque puede ser extendida para soportar la composición de más servicios.

• Las pruebas realizadas, solo fueron a servicios web con tipos de datos primitivos.

Cenidet 2006 76

Capítulo 6: Conclusiones y Trabajo Futuro Como resultado adicional de la investigación, se elaboró un artículo sometido para su evaluación al evento ISSAD’S 2005. Otro artículo se encuentra en proceso de escritura al momento de terminar este documento de tesis.

6.2. Trabajos futuros. Como trabajo futuro, se propone la definición de un proceso que implemente en una herramienta la composición automáticamente de múltiples servicios web, mediante el modelado de flujo de datos, que habilite la invocación de los servicios web. La propuesta se debe al hecho de que herramienta actual no soporta la invocación en forma concurrente o paralela de los servicios web. También como trabajo futuro se propone habilitar la selección automática de los servicios web de cualquier plataforma o ambiente de desarrollo de servicios web. Ya que actualmente se esta realizando investigación sobre las técnicas que nos permitan automatizar la selección de servicios web a ser compuestos, y otras actividades relativas al proceso de composición de servicios web definido en este trabajo de tesis y que son realizadas por el desarrollador de aplicaciones. A continuación se detallan los puntos:

• Extender la interfaz para soportar la selección de múltiples servicios web, a ser compuestos.

• Estudiar los múltiples esquemas o modelos que soporten la composición de los servicios web, ya sea para integración a una aplicación o para generar un servicio web de alto nivel.

• Extender la herramienta para generar la capa de software, para el código cliente que actualmente se genera, y así llevarlo a servicio web.

• Integrar la herramienta a una aplicación de selección automática de servicios web. • Habilitar la herramienta para manejo de estructuras de datos en los servicios web.

Un trabajo futuro de gran importancia se refiere a la construcción de la capa de servicio web que el código cliente generado debe llevar antes de convertirse en un servicio web de alto nivel, y de esta manera lograr concretar los dos enfoques de la composición de servicios web.

Cenidet 2006 77

REFERENCIAS

Referencias Referencias

1. MC Carlos Lizárraga Celaya, “Servicios Web”, Laboratorio de Física Interdisciplinaria, Departamento de Física; Universidad de Sonora, http://www.fisica.uson.mx/carlos/WebServices/WSRevolution.htm. 05/05/2004.

2. Chris Peltz, “Web Services Orchestration and Choreography”, IEEE Internet Computing, Octubre; pp 46-77, 2003.

3. WikiMedia Project, http://es.wikipedia.org/wiki/Aplicaci%C3%B3n_web, 30/08/2005.

4. Cinxgler Mariaca Minda, Grupo Linux Universidad Distrital, Bogotá, Colombia, http://glud.udistrital.edu.co/glud/areas/doc/articulos/1_articulo_ws/aplicaciones-web.html, 30/08/2005

5. María Isabel García Arenas, Departamento de Arquitectura y Tencología de Computadores, Universidad de Granada, Granada, España, http://geneura.ugr.es/~maribel/xml/introduccion/index.shtml, 08/09/05.

6. Microsoft, http://msdn.microsoft.com/library/spa/default.asp?url=/library/SPA/vbcon/html/vbconXMLTechnologyBackgrounder.asp, 30/09/2005.

7. Benjamín González C., http://www.desarrolloweb.com/articulos/1557.php?manual=54, 08/09/05.

8. Microsoft, http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art51.asp, 08/09/2005.



11. Velásquez, http://www.osmosislatina.com/axis/basico.htm, 19/09/2005 12. Benjamín González C.,

http://www.desarrolloweb.com/articulos/1704.php?manual=54, 09/09/2005. 13. JAVA Y XML, BRETT MCLAUGGHLIN, ANAYA MULTIMEDIA 2001. 14. Enciclopedia Encarta Microsoft 2004.

Cenidet 2006 79

RESUMEN

Los servicios web tienen como propósito permitir que diferentes sistemas cliente puedan interactuar con ellos para obtener cierta funcionalidad. Los servicios web pueden ser accedidos por los clientes a través de estándares de Internet, como HTTP, XML y SOAP. En la actualidad es necesario hacer uso de varios servicios web para poder resolver un problema y las herramientas existentes nos generan un cliente por cada servicio web requerido. Por lo tanto se necesitan herramientas que soporten la generación de clientes que habiliten la composición de varios servicios web. Este trabajo presenta el desarrollo de Web Services Compositor, una herramienta capaz de generar un cliente para composición de varios servicios web incluyendo los stubs de conexión. Este documento muestra también un proceso para la utilización de la herramienta que facilita el desarrollo de aplicaciones cliente con composición de servicios web. La herramienta Web Services Compositor contiene tres módulos principales: el módulo analizador de documentos WSDL, el módulo de composición y el módulo de interfaz. El módulo analizador de documentos WSDL accede a los documentos WSDL de los servicios web y realiza un análisis de estos con un recorrido en forma de árbol, para extraer el nombre del servicio web, su ubicación, sus métodos y parámetros necesarios para la composición. El módulo de composición genera el documento composicion.xml. Este documento es un archivo que contiene los métodos y la información acerca de los parámetros, de los servicios web seleccionados para la composición. El código de los stubs es otro archivo que se genera desde este módulo y que contiene la parte del código de conexión entre los servicios web y la aplicación cliente. También este módulo es el encargado de generar un código semicompleto de la aplicación cliente, el cual contiene la secuencia de invocación de los servicios web. El módulo de la interfaz, facilita al usuario la especificación de las direcciones URL donde se encuentran los documentos WSDL de los servicios web que se desea componer. También facilita al usuario la selección de los métodos de cada servicio web a componer y su secuencia de ejecución. La diferencia principal entre la herramienta Web Services Compositor descrita en este documento y otros trabajos relacionados, consiste en que el trabajo presentado en este documento de tesis no se basa en un lenguaje de definición de procesos de negocios, este trabajo consiste en la definición de un proceso para la composición de servicios web, y el desarrollo de una herramienta que habilite este proceso.

ABSTRACT

Web services have as purpose to permit different software systems to interact with them in order to use their functionality. Web services can be accessed by the clients through standard protocols of Internet, such as HTTP, XML and SOAP. Currently it is necessary to use of several web services to be able to solve a given problem, and the existing tools generate one client for each web service required. Therefore tools to generate clients that habilitate the composition of several web services are needed. This work presents the development of Web Services Composer, a tool capable to generate a client for composition of several web services including the connection stubs. This document also shows a process for the utilization of the tool that facilitates the development of client applications with composition of web services. The tool Web Services Composer contains three main modules: the parser module for WSDL documents, the composition module and the interface module. The parser module accesses the WSDL documents of the web services and parses them with a walkthrough in the form of a tree, to extract the information of the services needed for the composition. The composition module generates a document identified as composicion.xml. This document is a file that contains the names of the methods and information about their parameters, of the selected web services. The stubs code is another file that is generated by the module and contains the part of the code for connecting the web services and the client application. In addition, this module is responsible for generating part of the client application containing the invocation sequence of the web services. The interface module facilitates to the user the specification of the URL addresses where the WSDL documents of the web services to be composed can be found. It also facilitates the selection of the methods of each web service to be composed and their sequence of execution. The main difference among the tool Web Services Composer described in this document and other related works, refers to the fact that this tool is not based on a business process definition language. Instead, this work consists of the definition of a process for the composition of web services, and the development of a tool that supports the process.

centro nacional de investigación y desarrollo tecnológico ... - … maria… · faby, aldo, rafa,...

Documents