Selección, Prueba y Adaptación de Servicios para Integración en Aplicaciones Orientadas a Servicios

(1)

Tesis

Doctorado en Ciencias de la Computaci ´on

Selecci ón, Prueba y Adaptaci ón de Servicios para Integraci ón en

Aplicaciones Orientadas a Servicios

Lic. Martin Garriga

Director: Dr. Alejandro Zunino

Co-Director: Dr. Andres Flores

Informe presentado en cumplimiento de los requisitos para el Grado de Doctor en Ciencias de la Computaci ´on

Universidad Nacional del Centro de la provincia de Buenos Aires

Facultad de Ciencias Exactas

ISISTAN

(2)

Resumen

Actualmente, una práctica com ún para el desarrollo de software es reusar funcionalidad provista por terceras partes. Esta práctica no s ólo ayuda a reducir los costos, sino también a enfocar el proceso de desarrollo en la funcionalidad principal del sistema. En este contexto, el crecimiento de la Web habilita a los desarrolladores a ofrecer software no s ólo en forma de bibliotecas a descargar e instalar, sino como componentes que se pueden invocar de forma dinámica, que se conocen como servicios. Para utlizar servicios para construir software, es necesario descubrir previamente aquellos servicios que ofrezcan la funcionalidad deseada. Una vez que los servicios potencialmente adecuados son identificados, el desarrolador debe seleccionar el más adecuado. Este paradigma es llamado Computaci ón Orientada a Servicios (SOC).

Sin embargo, un uso eficaz del paradigma SOC requiere un abordaje eficiente para permitir que las aplicaciones consuman servicios. Actualmente, los desarrolladores deben realizar b úsquedas manuales de servicios principalmente a través de catálogos Web, los cuales usualmente brindan informaci ón pobre y/o poco relevante, y luego deben proveer el c ódigo intermedio adecuado pa-ra ensamblar efectivamente el servicio seleccionado en la aplicaci ón cliente. Esto implica invertir un gran esfuerzo en descubrir servicios, analizar su idoneidad en el contexto de la aplicaci ón cliente, y finalmente determinar las adaptaciones necesarias para su correcta integraci ón y con-sumo.

(3)

Abstract

Nowadays, it is a common practice to create software reusing functionality provided by third-parties. This practice helps not only to reduce costs, but also to focus the development process on the system core functionality. The Web has enabled software developers to offer functionality not as libraries that should be downloaded and installed, but as software components that can be invoked dynamically, called services. In order to use services to build software, it is necessary to discover the services that offer the desired functionality. Once the potential services are identified, the developer should select the most suitable one. This paradigm to develop software is called Service Oriented Computing (SOC).

However, a broadly use of the SOC paradigm requires efficient approaches to allow service con-sumption from within applications. Currently, developers are required to search for suitable ser-vices mainly by manually exploring Web catalogs, which usually show poorly relevant into a client application. This implies a large effort into discovering services, analyzing the suitability of retrieved candidate services and envisioning the required adaptations for their correct integra-tion and safe consumpintegra-tion.

(4)

(5)

Agradecimientos

Si bien una tesis es un trabajo ”individual”, no ser´ıa posible sin las redes que sustentan y acom-pa ˜nan al doctorando. Redes afectivas, de conocimiento e institucionales.

En primer lugar, agradezco a mi familia. Mis viejos Jos´e y Silvina, y mi hermano Fernando, nada de esto ser´ıa posible sin ellos.

Agradezco a mis directores, Alejandro y Andrés. Alejandro confi ó en m´ı sin conocerme y me gui ó oportunamente siempre que lo necesité, sobre todo en los momentos dif´ıciles. Andrés fue mi gu´ıa en el d´ıa a d´ıa. Un referente como docente e investigador, sin él no hubiera llegado a culminar este trabajo.

Agradezco a Alejandra, quien me invit ó a formar parte del grupo GIISCo, y a las personas que conoc´ı en él. En especial a mis compa ñeros de todos los d´ıas: Alan, Maxi, Matias, Diego; sin ellos este camino no ser´ıa tan divertido.

Agradezco al equipo del ISISTAN, becarios e investigadores, que me hicieron sentir como en mi casa. En especial a Cristian, quien me gui ´o desinteresadamente.

Agradezco a mis amigos y hermanos del alma con los cuales compart´ı estos a ˜nos.

Agradezco al CONICET por el apoyo recibido a trav´es de diferentes becas, sin las cuales no hubiera podido culminar mis estudios.

A todos, gracias.

(6)

´Indice general

1. Introducci ´on 11

1.1. Motivaci ´on . . . 11

1.2. Soluci ´on propuesta . . . 13

1.3. Aplicaciones Orientadas a Servicios . . . 14

1.3.1. Tecnolog´ıa de Servicios Web . . . 15

1.3.2. Componentes Software y Servicios Web . . . 16

1.4. Testing de Software . . . 18

1.4.1. T´ecnicas de Testing para Componentes y Servicios Web . . . 19

1.5. Organizaci ´on de la Tesis . . . 23

2. Estado del Arte en Selecci ón e Integraci ón de Servicios 25 2.1. Introducci ón . . . 25

2.1.1. Caracter´ısticas para analizar propuestas en Servicios Web . . . 26

2.1.2. Caracter´ısticas Espec´ıficas de Servicios REST . . . 30

2.2. Enfoques Actuales . . . 31

2.2.1. Enfoques en Selecci ´on de Servicios . . . 31

2.2.2. Enfoques en Adaptaci ´on de Servicios . . . 32

2.2.3. Enfoques en Testing de Servicios . . . 34

2.2.4. Enfoques en Servicios RESTful . . . 35

2.3. An´alisis de Enfoques Actuales . . . 38

2.3.1. An´alisis Bajo Caracter´ısticas Generales . . . 38

2.3.2. An´alisis Bajo las Caracter´ısticas RESTful . . . 42

2.4. Conclusi ´on . . . 43

3. Método de Selecci ón de Servicios: Evaluaci ón de Interfaces 44 3.1. Introducci ón . . . 44

3.1.1. Caso de Estudio . . . 45

3.2. M´etodo de Selecci ´on de Servicios . . . 45

3.3. An´alisis Estructural de Interfaces . . . 47

3.3.1. Condiciones de Equivalencia Estructural . . . 48

3.3.1.1. Equivalencia de tipos de datos . . . 48

3.3.1.2. Tipos de Datos Complejos . . . 48

3.3.1.3. Nombres de Operaci ´on . . . 49

(7)

3.3.2. Resultados . . . 50

3.4. An´alisis Estructural y Sem´antico de Interfaces . . . 51

3.4.1. Alternativas para la Base Sem´antica . . . 52

3.4.1.1. Evaluaci ´on de identificadores utilizando WordNet con JWI . . . . 53

3.4.1.2. Evaluaci ´on de identificadores utilizando WordNet con JWNL . . . 55

3.4.1.3. Evaluaci ´on de identificadores utilizando DISCO . . . 57

3.4.2. An´alisis Estructural-Sem´antico por Elemento de Signatura . . . 58

3.4.2.1. Evaluaci ´on de Tipos Complejos . . . 58

3.4.2.2. Evaluaci ´on del Retorno . . . 60

3.4.2.3. Evaluaci ´on de Nombres de Operaci ´on . . . 61

3.4.2.4. Evaluaci ´on de Par´ametros . . . 61

3.4.2.5. Evaluaci ´on de Excepciones . . . 63

3.4.3. Resultados . . . 64

3.4.3.1. Sugerencia de Correspondencias de Par´ametros . . . 65

3.5. Conclusiones del An´alisis de Compatibilidad de Interfaces . . . 67

4. Método de Selecci ón de Servicios: Evaluaci ón de Comportamiento basado en Testing 68 4.1. Introducci ón . . . 68

4.1.1. Evaluaci ´on de Comportamiento . . . 69

4.1.2. Caso de Estudio . . . 70

4.2. Construcci ´on del Test Suite de Comportamiento . . . 70

4.2.1. Test Suite Exhaustivo . . . 71

4.2.2. Test Suite Reducido . . . 74

4.2.2.1. Construcci ´on del TS Reducido . . . 74

4.2.2.2. Operaciones Conflictivas . . . 75

4.2.2.3. Generaci ´on de la Clase Shadow . . . 75

4.2.2.4. Generaci ´on del Test Suite Reducido . . . 79

4.2.2.5. Criterios de Cubrimiento Espec´ıficos del TS Reducido . . . 80

4.2.2.6. Generaci ´on de Casos de Test . . . 81

4.3. An´alisis de Compatibilidad de Comportamiento . . . 81

4.3.1. Generaci ´on de Wrappers . . . 82

4.3.1.1. Basado en el Mapeo Estructural de Interfaces . . . 82

4.3.1.2. Basado en el Mapeo Estructural-Sem´antico de Interfaces . . . 85

4.3.2. Evaluaci ´on de Wrappers . . . 89

4.4. Conclusiones del Procedimiento de Evaluaci ´on de Comportamiento . . . 92

5. Validaci ´on Experimental 94 5.1. Introducci ´on . . . 94

5.2. Experimento 1 – Evaluaci ón de Métodos de Selecci ón con base Estructural, Semánti-ca e H´ıbrida . . . 94

5.2.1. Selecci ´on Sem´antica de Servicios . . . 95

5.2.2. Generaci ´on y Mutaci ´on de Consultas . . . 96

5.2.3. Escenario Experimental . . . 98

(8)

5.2.5. Discusi ´on . . . 101

5.3. Experimento 2 – Comparaci ´on de las Alternativas para la Base Sem´antica . . . 102

5.3.1. Algoritmo de Descubrimiento y Selecci ´on de Stroulia . . . 103

5.3.2. Configuraci ´on y ejecuci ´on del Experimento . . . 103

5.3.3. Resultados . . . 104

5.3.4. Discusi ´on . . . 105

5.4. Experimento 3 – Comparaci ´on de la evaluaci ´on de interfaces respecto de algorit-mos basados en ontolog´ıas . . . 107

5.4.1. Algoritmo de categorizaci ´on y mapeo de servicios basado en ontolog´ıas . . 107

5.4.2. Configuraci ´on del Experimento . . . 108

5.4.3. Resultados . . . 108

5.4.4. Discusi ´on . . . 110

5.5. Experimento 4 – Compatibilidad de Comportamiento . . . 110

5.5.1. Configuraci ´on Experimental . . . 111

5.5.2. Resultados . . . 113

5.5.3. Discusi ´on . . . 115

5.6. Conclusiones . . . 116

6. Conclusi ´on y Trabajos Futuros 118 6.1. Conclusi ´on . . . 118

6.1.1. Contribuciones y objetivos alcanzados . . . 118

6.2. Trabajos Futuros . . . 121

(9)

´Indice de figuras

1.1. Soluci ón propuesta: Método de Selecci ón de Servicios . . . 13

1.2. Arquitectura b´asica de un sistema orientado a servicios . . . 15

1.3. Arquitectura de Protocolos de Servicios Web . . . 16

1.4. Infraestructura est´andar de un Sistema orientado a Servicios . . . 16

2.1. Comparaci ´on de las pilas de lenguajes para SOAP y REST . . . 26

3.1. Interfaz Requerida y Servicio Candidato para el ejemplo de Car Rental . . . 45

3.2. M´etodo de Selecci ´on de Servicios . . . 46

3.3. An´alisis Estructural y Sem´antico de Compatibilidad de Interfaces . . . 52

3.4. Distancia entrecompact_ytruck_{en la jerarqu´ıa de WordNet . . . .} ₅₅

3.5. Estructura de la TablaHashpara la Sugerencia de Correspondencias de Parámetros 67 4.1. Método de Selecci ón de Servicios con la adici ón del Test Suite Reducido . . . 70

4.2. Interfaces para el ejemplo de Calculadora . . . 70

4.3. Procedimiento de Generaci ´on de TS Reducido . . . 74

4.4. Esquema de relaciones causa-efecto para operaciones de laClase Shadow . . . 76

4.5. Arbol de Generaci ´on de Wrappers para el ejemplo de Calculadora´ . . . 84

4.6. Proxy para la invocaci ´on de Servicios Web . . . 84

4.7. Enlace entre el wrapperCalculatory el proxy deCalculatorService . . . 85

4.8. Arbol de Generaci ´on de Wrappers: con y sin mapeo sem´antico . . . 86

4.9. Arbol de Generaci ´on de Wrappers Reducido para el ejemplo de Calculadora . . . .´ 89

4.10. Resultado de la ejecuci ´on del TS exhaustivo sobre los wrappers de Calculadora . . 91

4.11. Resultado de la ejecuci ´on del TS reducido sobre los wrappers de Calculadora . . . 93

5.1. Precision-en-n para el registro EasySOC . . . 100

5.2. Recall y NDCG para el Experimento 1 – EasySOC . . . 101

5.3. Resultados de Adaptabilidad para el Experimento 1 . . . 102

5.4. Escenario 1 – EasySOC . . . 102

5.5. Precision-en-nconn=[1,10] para los resultados orginales, procedimientos de com-patibilidad de interfaces y el algoritmo de Stroulia (m´as es mejor) . . . 105

5.6. Recall, F-Measure y NDCG para los resultados orginales, procedimientos de com-patibilidad de interfaces y el algoritmo de Stroulia (m´as es mejor) . . . 106

5.7. Precisi ón,recallyF-Measurepara los algoritmos de Compatibilidad de Interfaces, Categorizaci ón y Mapeo (más es mejor) . . . 109

5.8. Comparaci ´on de Artefactos de Software Generados por escenario . . . 114

(10)

´Indice de tablas

1.1. Modelos de Componentes Orientados a Objetos . . . 17

1.2. Factores de Facilidad de Testing para Componentes Software . . . 19

1.3. Factores de Facilidad de Testing para SOA . . . 20

2.1. Resumen de caracter´ısticas para analizar trabajos relacionados . . . 28

2.2. Resumen de las caracter´ısticas espec´ıficas de REST. . . 31

2.3. Caracterizaci ´on de Trabajos Relacionados – Parte I . . . 39

2.4. Caracterizaci ´on de Trabajos Relacionados – Parte II . . . 40

2.5. Caracterizaci ´on de Trabajos Relacionados de acuerdo a las caracter´ısticas RESTful . . . 43

3.1. Condiciones de Equivalencia Estructural por Elemento de Signatura . . . 47

3.2. Esquema de Evaluaci ´on Estructural . . . 47

3.3. Subtipificaci ´on Directa para Tipos Primitivos . . . 48

3.4. Equivalencia de Subtipos para Operaciones . . . 48

3.5. Reglas para descomponer nombres de operaciones . . . 49

3.6. Compatibilidad Estructural de Interfaces para el ejemplo de Car Rental . . . 51

3.7. Ejemplos de understemming y overstemming para pares de t´erminos . . . 54

3.8. Matriz de profundidad normalizada paraGetReservation_yGetCurrentBooking ₅₆ 3.9. Matriz de co-occurrencias para GetReservationyGetCurrentBooking . . . 57

3.10. Correspondencia entre el valor estructural y sem´antico y las condiciones de equi-valencia para retorno . . . 61

3.11.Correspondencia entre el valor sem´antico y las condiciones de equivalencia para nombres . 61 3.12.Correspondencia entre el valor estructural y sem´antico y las condiciones de equivalencia para retorno . . . 62

3.13.Correspondencia entre el valor estructural y sem´antico y las condiciones de equivalencia para par´ametros . . . 64

3.14. Mapeo de operaciones estructural y sem´antico para el ejemplo de Car Rental . . . 65

4.1. Criterios de cubrimiento para Expresiones Regulares . . . 72

4.2. Plantillas de Test para Calculadora . . . 73

4.3. Casos de test en formato MuJava paraCalculator. . . 73

4.4. Compatibilidad Estructural-sem´antica de Interfaces para el ejemplo de Calculadora 76 4.5. Casos de test en formato MuJava paraCalculator_{. . . .} ₈₁

4.6. Compatibilidad Estructural de Interfaces para el ejemplo de Calculadora . . . 83

(11)

4.9. Resultado de la ejecuci ´on del TS ExhaustivoMujavaCalculator 1_{. . . .} ₉₁

4.10. Resultado de la ejecuci ´on del TS Reducido para el ejemplo de Calculadora . . . 92

(12)

Cap´ıtulo 1

Introducci ´on

Actualmente, una práctica com ún para el desarrollo de software es reusar funcionalidad provista por terceras partes. Esta práctica no s ólo ayuda a reducir los costos, sino también a enfocar el pro-ceso de desarrollo en la funcionalidad principal del sistema. En este contexto, el crecimiento de la Web habilita a los desarrolladores a ofrecer software no s ólo en forma de bibliotecas, sino como componentes que se pueden invocar de forma dinámica, los cuales se conocen como servicios. En particular, la tecnolog´ıa de Servicios Web es la punta de lanza para la adopci ón del paradig-ma de Computaci ón Orientada a Servicios (SOC) [15]. Para utlizar servicios durante el desarrollo de software, es necesario descubrir previamente aquellos servicios que ofrezcan la funcionalidad deseada. Una vez que los servicios potencialmente adecuados son identificados, el ingeniero de software debe seleccionar el más adecuado.

Sin embargo, un uso eficaz del paradigma SOC requiere un abordaje eficiente para permitir que las aplicaciones consuman servicios. Actualmente, los desarrolladores deben realizar b úsquedas manuales de servicios principalmente a través de catálogos Web, los cuales usualmente brindan informaci ón pobre y/o poco relevante, y luego deben proveer el c ódigo intermedio adecuado pa-ra ensamblar efectivamente el servicio seleccionado en la aplicaci ón cliente. Esto implica invertir un gran esfuerzo en descubrir servicios, analizar su idoneidad en el contexto de la aplicaci ón cliente, y finalmente determinar las adaptaciones necesarias para su correcta integraci ón y con-sumo. En este contexto, la presente tesis presenta un enfoque para selecci ón, testing y adaptaci ón de servicios.

El presente cap´ıtulo se organiza de la siguiente manera. La Secci ón 1.1 presenta la motivaci ón de este trabajo de tesis. La Secci ón 1.2 presenta la soluci ón propuesta y los objetivos delineados para este trabajo de tesis. La Secci ón 1.3 provee algunas definiciones preliminares en el contexto de las aplicaciones orientadas a servicios y el paradigma SOC. Análogamente, la Secci ón 1.4 define algunos conceptos importantes en testing de software y particularmente testing de componentes y servicios. Finalmente, la Secci ón 1.5 describe la organizaci ón de la presente tesis.

1.1. Motivaci ´on

(13)

La Computaci ón Orientada a Servicios (SOC1) es el paradigma que tiene como objetivo abordar estos aspectos, promoviendo el desarrollo rápido y de bajo costo de aplicaciones de distribuci ón masiva, interoperables y capaces de evolucionar, que permiten interconectar m últiples organi-zaciones creando procesos de negocio dinámicos. SOC permite efectivizar la creaci ón de nue-vas facilidades de aplicaciones, en forma deservicios, posibilitando un crecimiento dinámico de portfolios de servicios organizacionales, y generando nuevas soluciones combinadas con com-ponentes externos que posiblemente residen en forma remota [126]. El bloque de construcci ón fundamental en SOC, elservicio, consiste de un componente de software de caja negra con una interfaz bien definida que se puede invocar a través de protocolos de red espec´ıficos [15]. La materializaci ón del paradigma SOC en las organizaciones se puede alcanzar mediante la Ar-quitectura Orientada a Servicios (SOA2), que se presenta como un modelo arquitect ónico centra-do en reducir la carga de implantaci ón de las TICs3en una empresa, facilitando una mejora en agilidad y rentabilidad [53]. SOA define una soluci ón tecnol ógica a la interacci ón de servicios, donde se pueden identificar los siguientes actores: un cliente de servicios, un proveedor de servi-cios, y un agente de servicios (broker) [173]. En general, las Aplicaciones Orientadas a Servicios se basan en la tecnolog´ıa de Servicios Web: programas con una interfaz bien definida que puede ser localizada, publicada e invocada utilizando la infraestructura estándar de la Web [15]. El paradigma SOC provee ventajas muy claras, dado que genera un bajo grado de acoplamien-to entre consumidor/proveedor de un determinado servicio y además promueve fuertemente la reusabilidad de componentes de software. Sin embargo, por otro lado se produce un incremento de esfuerzo en dos etapas de un proyecto de desarrollo de software: implementaci ón y manteni-miento [84]. En primer lugar, la b úsqueda de servicios publicados en un registro requiere invertir mucho tiempo – en particular considerando el registro UDDI4(Universal Description, Discovery, and Integration) para la tecnolog´ıa de Servicios Web [35]. Esto impacta directamente en los cos-tos de la fase de implementaci ón, ya que el paradigma SOC reemplaza el desarrollo de piezas espec´ıficas por el descubrimiento y contrataci ón de las mismas. En segundo lugar, al introducir servicios externos a una aplicaci ón, en general se produce un efecto colateral donde la l ógica del negocio queda “contaminada” con aspectos no funcionales, tales como localizaci ón, comunica-ci ón de datos sobre la red, etc. Esto no es un atributo de calidad deseable, dado que produce sistemas dif´ıciles de entender, mantener y extender [52]. Además, los frameworks actuales para invocar servicios, por ejemplo WSIF5, producen c ódigo fuente subordinado a un determinado proveedor de servicios [51]. En consecuencia, ante los cambios en las interfaces de los servicios externos o su reemplazo por nuevos proveedores, se requiere refactorizar el c ódigo para efectuar la invocaci ón de los mismos, lo cual propaga cambios por las partes “contaminadas” de la apli-caci ón [110]. Esta situaci ón, por lo tanto, genera un alto impacto sobre los costos en la etapa de mantenimiento de software.

Por lo tanto, para alcanzar un amplio uso del paradigma SOC se necesitan enfoques eficientes para permitir el consumo de servicios, excediendo la b úsqueda de servicios y la creaci ón de c ódi-go intermedio para ensamblaje en una aplicaci ón cliente [111]. Si bien existen esfuerzos actuales en la identificaci ón de servicios, que poseen mecanismos semi-automáticos para facilitar la tarea de un ingeniero de software, en general proveen resultados parciales compuestos de conjuntos de servicios candidatos, donde a ún deben efectuarse tareas manuales de análisis para realizar la selecci ón definitiva del servicio candidato más adecuado. Se requieren por tanto estrategias para facilitar la toma de decisiones sobre los servicios recuperados, dado que a ún con un conjunto reducido de candidatos, las heterogeneidades sobre las capacidades de los servicios (funciona-les y no-funciona(funciona-les) inyectadas por diferentes proveedores vuelven abrumador el esfuerzo de evaluaci ón requerido. La exploraci ón sobre los servicios candidatos debe también incluir una presunci ón sobre las adaptaciones necesarias para una correcta integraci ón y el consumo seguro

1_SOC:_{Service Oriented Computing} 2_SOA:_{Service Oriented Architecture}

3_{TIC: Tecnolog´ıa de la Informaci ´on y las Comunicaciones} 4_UDDI:_{http://uddi.xml.org/}

(14)

Figura 1.1: Soluci ón propuesta: Método de Selecci ón de Servicios

de los servicios. Las posibles combinaciones de proveedores de servicios pueden además exceder el rango de una selecci ón manual por parte de los consumidores. Se necesita manejar un entorno completamente heterogéneo en el que los artefactos y dispositivos de diferentes capacidades pue-dan ser incorporados en forma transparente. As´ı, los mecanismos requeridos para encontrar los “mejores” Servicios Web deben considerar que, sin una apropiada extracci ón de informaci ón re-levante de los contratos de servicios y su comportamiento operacional, la selecci ón del servicio candidato más adecuado se asemeja casi a un acto de predicci ón.

1.2. Soluci ´on propuesta

Con el fin de facilitar el desarrollo de Aplicaciones Orientadas a Servicios, en esta tesis se pre-senta un enfoque para asistir a los ingenieros de software en laselecciónde Servicios Web. Esta propuesta se basa en un enfoque reciente [58], que fue desarrollado inicialmente para seleccio-nar los componentes de softwareoff-the-shelf (OTS) más adecuados como una soluci ón para la sustituci ón de los sistemas basados en componentes. Dado que los Servicios Web implican un caso especial de un componente de software [95], decidimos aplicar los conceptos de selecci ón de componentes para definir un enfoque para selecci ón de servicios.

(15)

Luego, el procedimiento deCompatibilidad de Comportamientose basa en unframeworkde testing para explorar el comportamiento requerido para los servicios candidatos, mediante el análisis de las transformaciones de datos (entrada/salida), lo que facilita comprender elmapeo funcional de un servicio y por lo tanto su comportamiento operacional. Además, ambos procedimientos implican el análisis de factores espec´ıficos para construir artefactos de adaptaci ón, que resuelven la “impedancia” entre las interfaces requeridas y las interfaces de los Servicios Web candidatos. En funci ón de lo anteriormente expuesto, se puede entonces enunciar el objetivo general de esta tesis, de la siguiente manera:

“Definir un Método de Selección de Servicios Web para asistir a los ingenieros de software en la construcción de

Aplicaciones Orientadas a Servicios”

Para la consecuci ´on de este objetivo general, se propusieron los siguientes objetivos espec´ıficos:

1. Efectuar un estudio del Estado del Arte en selecci ón e integraci ón de Servicios Web, con énfasis en aspectos de composici ón, verificaci ón y adaptaci ón de servicios.

2. Definir un Procedimiento deAnálisis de Compatibilidad de Interfaces, considerando as-pectos puramente estructuralesy también bajo la inclusi ón de aspectossemánticos, y espe-cialmente a través de la informaci ón extra´ıda de las especificaciones WSDL de los Servicios Web.

3. Definir un Procedimiento deConstrucci ón de Test Suite de Comportamiento, en funci ón de criterios de testing de caja negra para componentes de software y Servicios Web, y conside-rando el factor de optimizaci ón en la sobrecarga de generaci ón y ejecuci ón que implica un Test Suite de gran volumen.

4. Definir un Procedimiento deEvaluaci ón de Compatibilidad de Comportamiento, basado en los resultados de los procedimientos anteriores y estableciendo la generaci ón de artefactos de adaptaci ón para integrar de manera segura los Servicios Web en una aplicaci ón cliente.

5. Desarrollar implementaciones protot´ıpicas de los procedimientos definidos, para la asisten-cia semi-autom´atica de un ingeniero de software en laselecci´onde Servicios Web.

6. Efectuar una evaluaci ón experimental del Método deSelecciónde Servicios Web, en térmi-nos de recuperabilidad, capacidad de adaptaci ón y eficacia de los tests.

1.3. Aplicaciones Orientadas a Servicios

En el paradigma SOC, unserviciose considera un contenedor de capacidades para un prop ósito com ún que define un contexto funcional distintivo. Tales capacidades se expresan de acuerdo con un contrato de servicio [53], y se encuentran encapsuladas como funciones aut ónomas que interact úan a través de una interfaz bien definida. Una definici ón de servicio debe incluir un identificador (ID), la interfaz (que describe medios para comunicarse con el entorno del servicio) y su comportamiento operacional (un conjunto de operaciones a ser ejecutadas de acuerdo con alguna estructura interna de control) [107].

(16)

ó dinámicamente vinculados a un servicio – ambos exponiendo una clara interfaz de sus capa-cidades funcionales [110]. Cuando se construye una nueva aplicaci ón, el ingeniero de software debe tomar la decisi ón de proveer una implementaci ón para alg ún componente de la aplicaci ón, ó bien, utilizar una implementaci ón ya existente. Esto se denominatercerización, es decir llenar el espacio que deja una funcionalidad faltante, con la implementaci ón de un servicio existente, desarrollado por terceras partes [126].

El paradigma SOC reemplaza el desarrollo de un componente de software por una combinaci ón de distintas actividades:descubrimientode servicios,selecciónde servicios eintegraciónde servicios en aplicaciones [84, 15]. La disponibilidad del modelo arquitect ónico de SOA establece un ade-cuado entorno tecnol ógico que satisface los principios de dise ño de orientaci ón a servicios [53], proveyendo componentes capaces de: 1) intercambiar mensajes, 2) describir los servicios, 3) pu-blicar y descubrir las descripciones de los servicios [153].

En SOA se define la interacci ón entre componentes software como un intercambio de mensajes entresolicitantesyproveedoresde servicios, mediante unagente de servicios, como se muestra en la Figura 1.2 [69, 52]. Un componentesolicitanterealiza la b úsqueda de un servicio en el registro que provee unagente de serviciosde acuerdo a sus necesidades y solicita la ejecuci ón del mismo. Un componenteproveedores responsable de publicar la descripci ón de un servicio en el registro de un agente de servicios, as´ı como aceptar y ejecutar las solicitudes de dichos servicios. Un componente puede asumir tanto el rol de proveedor como de solicitante de servicios. Unagente de servicios es un componente en el cual el servicio es publicado y puede ser descubierto; y puede ser visto como un registro o directorio de servicios.

Solicitante

de Servicios

Proveedor

de Servicios

Agente

de Servicios

Descubrir

Publicar

Interacción

Descripción de Servicio

Cliente Servicio

Figura 1.2: Arquitectura b´asica de un sistema orientado a servicios

1.3.1. Tecnolog´ıa de Servicios Web

En su mayor´ıa, la industria del software ha adoptado el paradigma SOC utilizando la tecnolog´ıa de Servicios Web, donde el concepto de servicio se implementa mediante una interfaz especifi-cada en WSDL (Web Service Description Language) y un identificador dado por un URI [107, 126]. En el mismo sentido, la W3C6define que “un servicio Web es un sistema software (identificado por un URI), dise ñado para soportar la interacción máquina-a-maquina sobre una red interoperable. Tiene una interfaz descripta en un formato procesable por máquina (espec´ıficamente WSDL), y otros sistemas interact úan con el Servicio Web de la manera que prescribe su descripción, utilizando (por lo general) mensajes SOAP transmitidos mediante HTTP con una serialización XML, junto con otros estándares de la Web” [17]. La arquitectura de Servicios Web [163] consta de una serie de protocolos de acceso,

(17)

que si bien se encuentran en constante evoluci ´on, se los puede agrupar actualmente en cuatro capas principales, como se observa en la Figura 1.3.

Figura 1.3: Arquitectura de Protocolos de Servicios Web

La capa inferior, denominada capa deTransporte, es la responsable de transportar los mensajes entre los componentes software, y actualmente incluye los protocolos HTTP (Hyper Text Transfer Protocol), SMTP (Simple Mail Transfer Protocol), y FTP (File Transfer Protocol), entre otros. La capa de

Mensajeses la responsable de codificar los mensajes en un único formato XML (eXtensible Markup Language), para lograr un entendimiento com ún. Esta capa incluye protocolos como XML-RPC (XML-Remote Procedure Call) y SOAP (Simple Object Access Protocol). La capa deDescripci ón de servicios es la responsable de describir la interfaz p ública de un Servicio Web espec´ıfico, que ac-tualmente se logra a través del protocolo WSDL (Web Service Description Language). Por último, la capa deDescubrimientode servicios es la responsable de centralizar servicios y proveer una interfaz para la b úsqueda y publicaci ón de servicios. Actualmente, el descubrimiento de servi-cios se encuentra materializado por UDDI. En la Figura 1.4 se muestra la implementaci ón de la arquitectura SOA, utilizando las tecnolog´ıas de Servicios Web, UDDI, WSDL y SOAP.

Cliente de

Servicio Web

UDDI

Descubrir

Publicar

SOAP

WSDL

Comunicación por medio de mensajes XML

Figura 1.4: Infraestructura est´andar de un Sistema orientado a Servicios

1.3.2. Componentes Software y Servicios Web

Un paradigma ampliamente relacionado a SOC y SOA es elDesarrollo de Software basado en Com-ponentes(CBSD7), donde la construcci ón de sistemas se basa principalmente en laseleccióne in-tegraciónde componentes software [81, 29]. Un componente software es una unidad reutilizable de composici ón, con interfaces y cualidades expl´ıcitamente especificadas, que denota una abs-tracci ón simple y puede ser sujeto de composici ón por terceras partes, sin necesidad de modifi-caci ón [158, 75].

(18)

Tabla 1.1:Modelos de Componentes Orientados a Objetos

Tipo Modelo Lenguaje

Definici´on Implementaci´on

Clase EJB Java Java

J2EE

Objeto

CCM OMG IDL CORBA

COM Microsoft IDL actualmenteC,C++ yAda .Net Microsoft IDL cualquier lenguaje.Net Servicios Web WSDL cualquier lenguaje

Dado que los componentes están completamente desarrollados y se encuentran disponibles pa-ra su reutilizaci ón, se los conoce com únmente comooff-the-shelf (OTS). Los componentes OTS poseen una variada procedencia: aquellos desarrollados en alg ún proyecto previo, denominados in-house, entre los cuales se pueden mencionar los sistemas heredados (legacy), y en conjunto con los componentes de c ódigo abierto denominados FOSS (free open source software), presentan como posibilidad el acceso al c ódigo fuente. Mientras que otros componentes OTS que se adquieren de terceras partes (usualmente de proveedores comerciales), denominados COTS ( commercial-off-the-shelf), no cuentan en general con tal disponibilidad de c ódigo fuente.

Modelo de Componentes

Existe una amplia diversidad de tecnolog´ıas involucradas en la construcci ón de sistemas basados en componentes, cada una con requisitos y restricciones particulares que establecen el aspecto concreto que adopta un componente y los mecanismos para su integraci ón en un sistema soft-ware. ElModelo de Componentesdefine la estructura y morfolog´ıa de los componentes, as´ı como también las reglas de creaci ón, composici ón y comunicaci ón de los mismos [95]. Los modelos establecen por ejemplo la forma de definici ón e invocaci ón de las interfaces de los componen-tes, estableciendo en algunos casos una clara separaci ón entre las interfaces y la implementaci ón (encapsulada) del comportamiento de un componente [156, 95]. La Tabla 1.1 presenta una clasi-ficaci ón de los modelos de componentes seg ún una base de orientaci ón a objetos (OO).

Considerando la separaci ón entre interfaces e implementaci ón, para los componentes que son en realidad clases Java, el lenguaje de definici ón coincide con el de implementaci ón, como en el caso de EJB y J2EE (Java 2 Enterprise Edition) [88]. Por otro lado, para el caso donde los com-ponentes son en realidad objetos, puede existir un lenguaje de descripci ón de interfaces (IDL8_{) y} otro de implementaci ón, como en el caso de COM (Component Object Model) [34], CCM (Corba Component Model) [122], la tecnolog´ıa .Net [118], y los Servicios Web.

Aqu´ı se observa claramente la vinculaci ón de la tecnolog´ıa de componentes software con el pa-radigma SOC, a través de la tecnolog´ıa de Servicios Web, que justamente se considera una forma espec´ıfica de componente software. La interfaz de un Servicio Web que se describe en WSDL es comparable a una interfaz de programaci ón de aplicaciones (API9), pero sin ataduras a frame-works de comunicaci ón propietarios. La l ógica encapsulada por un Servicio Web (su implemen-taci ón) podr´ıa además adoptar la forma de un componente software o bien de una aplicaci ón heredada (legacy).

La interfaz p ública de un Servicio Web se define como uncontratoque permite su integraci ón en una Aplicaci ón Orientada a Servicios a través del uso de componentes adaptadores. El contrato de un Servicio Web es esencialmente una colecci ón de metadatos que describe varios aspectos del programa software subyacente, que incluye el prop ósito y funci ón de sus operaciones; los men-sajes que necesitan ser intercambiados para activar las operaciones; los modelos de datos usados

(19)

para definir la estructura de los mensajes; un conjunto de condiciones bajo las cuales se proveen las operaciones; e informaci ón acerca de c ómo y d ónde puede ser accedido el servicio [53].

1.4. Testing de Software

A continuaci ´on se explican los conceptos relacionados con Testing de Software, particularmente en el contexto de CBSD y de Servicios Web.

El proceso de Testing de Software consiste de la verificaci ´on din´amica del comportamiento de un programa contra el comportamiento esperado, por medio de un conjunto finito de casos de test, que fueron adecuadamente seleccionados de un conjunto usualmente infinito de ejecuciones en un dominio [157].

Minimizaci ´on o Reducci ´on de Test Suite

Las estrategias de testing generalmente intentan cubrir, en el mayor grado posible, todas las po-sibles áreas de riesgo o conflictivas, es decir, aquellas que son más propensas a la presencia de defectos o que su existencia pudiera afectar considerablemente los datos/procesos/usuarios de los Sistemas bajo Test (SUT10). As´ı un TS puede asumir un volumen cada vez más grande para asegurar una confiabilidad sobre el comportamiento del SUT, y eso genera el problema del enor-me esfuerzo de ejecuci ón de un TS exhaustivo. Para ello, se han definido estrategias que intentan maximizar el valor del TS: minimizaci ón, selecci ón y priorizaci ón [168].

Minimización: intenta reducir el tama ño de un TS mediante la eliminaci ón de los casos de testredundantes, o bien conservar los casos de testesenciales. Minimizaci ón también se deno-mina “reducci ón”, lo que significa que la elideno-minaci ón es permanente. Estos dos conceptos son esencialmente intercambiables porque todas las técnicas de reducci ón se pueden utili-zar para producir un subconjunto temporal del TS, mientras que las técnicas de minimiza-ci ón se pueden utilizar para eliminar permanentemente los casos de test.

Selección: también intenta reducir el tama ño de un TS, pero la mayor´ıa de las técnicas de selecci ón consideran en particular la modificaci ón. Es decir, la selecci ón no s ólo es temporal con respecto a una versi ón actual del SUT, sino que también se centra en la identificaci ón de las partes modificadas del sistema. Los casos de test son seleccionados porque son relevan-tes para las parrelevan-tes modificadas del SUT, lo cual generalmente implica un análisis estático de caja blanca del c ódigo del programa (esto se explica en la Secci ón 1.4.1).

Priorización: intenta re-ordenar los casos de test para maximizar algunas propiedades desea-bles en forma temprana, tal como la tasa de detecci ón de fallas. Se trata de encontrar la permutaci ón óptima de la secuencia de casos de test, y además se asume que todos los ca-sos de test pueden ser ejecutados en el orden de la permutaci ón generada. No se trata de seleccionar casos de test y por lo mismo no se produce una reducci ón; pero al efectuar el re-ordenamiento de casos de test, es posible terminar la ejecuci ón del TS en un punto ar-bitrario – probablemente cuando se alcanza a cubrir la propiedad deseable con un grado adecuado.

Facilidad de Testing de Componentes y Servicios Web

De acuerdo al Glosario Est´andar IEEE 610 [85], la Facilidad de Testing de Software considera dos aspectos: 1) el grado en el cual un sistema o componente facilita que se establezcan criterios de testing y el rendimiento de los tests para determinar si esos criterios han sido cubiertos; 2) el grado en el cual un requerimiento es establecido en t´erminos de permitir que se establezcan criterios y rendimiento de tests para determinar si esos criterios han sido cubiertos.

(20)

En la definici ón previa se realizan dos consideraciones: la forma en que se desarrolla el software y los requerimientos sobre el sistema software que sirven de base para la definici ón de un con-junto de casos de test o Test Suite (TS). En la industria de software se requiere de componentes y servicios reutilizables que puedan ser efectivamente testeados, para as´ı satisfacer la gran deman-da de desarrollos eficaces en reducci ón de tiempo y costos. Para esto, los proveedores necesitan disponer de gu´ıas y métodos prácticos y válidos para desarrollar componentes y servicios con capacidad de ser testeados [89, 26].

En particular para la Facilidad de Testing en CBSD se ha establecido un conjunto de factores que son esenciales para que los proveedores puedan evaluar el nivel de facilidad de testing de los componentes, y los usuarios puedan realizar selecci ´on y evaluaci ´on de componentes y determi-nar el esfuerzo que ha invertido el desarrollador del componente para incrementar su capacidad de ser testeado. En la Tabla 1.2 [60, 89] se resumen los factores de Facilidad de Testing para Com-ponentes Software.

Tabla 1.2:Factores de Facilidad de Testing para Componentes Software

Factor Descripci ´on

Facilidad de Comprensi ´on

Informaci ´on anexa sobre el componente (ejemplo: documentaci ´on de las interfaces, de testing, etc.)

Facilidad de Observaci ´on

Percibir los datos desalidacomo funci ´on de lasentradas

Facilidad de Control Producir datos desalidaa partir de un conjunto espec´ıfico de datos deentrada

Facilidad de Trazado

Comparaci ón del comportamiento esperado con la ejecuci ón del componente (caja negra). Comprobaci ón del estado interno del componente en cada invocaci ón a sus interfaces (caja blanca)

Capacidad de Soporte de Testing

Mecanismos para agilizar el testing de componentes (ejemplo: para generar y ejecutar un TS, para administrar el proceso de testing, etc.)

En el contexto de Servicios Web se consideran válidos tales factores, donde los clientes o solicitan-tes de servicios deben agregar un nivel adicional de evaluaci ón que involucra la disponibilidad en tiempo de ejecuci ón de los servicios y la provici ón continua y confiable de las capacidades ofrecidas (funcionales y no funcionales). Esto implica una carga adicional de responsabilidad so-bre los proveedores de servicios que deben extender el esfuerzo del ciclo de vida del desarrollo de servicios hacia la provici ón de plataformas de ejecuci ón de servicios. En particular se trata de un aspecto propio del paradigma SOC que se ha denominado “relaci ón sin responsabilidad” [173], donde un cliente no requiere conocer c ómo se ha implementado el servicio con el que se comu-nica, ni preocuparse por la ejecuci ón concreta del servicio, en cada oportunidad que deba ser invocado. As´ı los desaf´ıos de confiabilidad en el paradigma SOC se ampl´ıan considerablemente y por ello se ha extendido el conjunto de factores para dar soporte a la Facilidad de Testing en SOA, como se resume en la Tabla 1.3.

1.4.1. T´ecnicas de Testing para Componentes y Servicios Web

A continuaci ´on se explica la posibilidad de uso (con mayor o menor ajuste) de estrategias tradi-cionales de testing, y el desarrollo de nuevas estrategias espec´ıficas en el contexto de CBSD y de Servicios Web.

Criterios de Cubrimiento para Componentes y Servicios Web

(21)

Tabla 1.3:Factores de Facilidad de Testing para SOA

Factor Descripci ´on

Servicios At ´omicos

Considerar los niveles de publicaci ón de servicios (e informaci ón accesible): c ódigo fuente, c ódigo binario, modelo, signatura (WSDL). Procedencia

de Datos

Considerar la historia del procesamiento de datos: identificar su origen en crudo, c ´omo fueron derivados, su enrutamiento en SOA, y los procesos aplicados a los datos.

Integraci ´on de Servicios

Considerar la dinamicidad de SOA: interoperabilidad, composici ón y re-composici ón, controlador de servicios (tal como orquestador), controlador de adaptaci ón (reconfiguraciones).

Colaboraci ´on de Servicios

Considerar el soporte de protocolos de colaboraci ón dinámica: preparaci ón, establecimiento, ejecuci ón, terminaci ón. As´ı cada servicio determina su colaboraci ón en ejecuci ón.

blanca. Sin embargo los clientes que no disponen del c ódigo fuente de un componente/servicio, requieren de criterios de testing espec´ıficos que les permitan evaluar la correctitud como una uni-dad que se integra a la aplicaci ón de destino. A continuaci ón se introducen algunas definiciones de los criterios de cubrimiento para componentes y Servicios Web [89, 20].

Criterio de M´etodos[70].

Los componentes pueden tener varias interfaces, cada una compuesta de un conjunto de operaciones o métodos. El criterio requiere que toda interfaz deba ser ejecutada al menos una vez. Esto significa que toda operaci ón de cada interfaz debe ser invocada al menos una vez. Este criterio también se denomina criterio de interfaces [167]. En el contexto de Servicios Web, se considera la definici ón de una única interfaz que se describe en WSDL y se compone de un conjunto de operaciones. Un criterio análogo se denominacriterio de operaciones[8].

Criterio de Eventos[167].

Un evento es un incidente en el cual el efecto resultante es la invocaci ón de una interfaz. Los eventos pueden ser s´ıncronos (por ejemplo, invocaciones directas a las operaciones) o as´ıncronos (por ejemplo, la ocurrencia de excepciones). El criterio requiere que todo evento (s´ıncrono o as´ıncrono) de un componente deba ser cubierto por alg ún caso de test. As´ı este criterio cubre a uno más espec´ıfico denominadocriterio de excepciones[70, 166].

Criterio de Dependencia de Contexto[167].

Los eventos pueden tener dependencias secuenciales con otros eventos, causando distintos comportamientos de acuerdo al orden en el que son invocados (operaciones o excepciones). El criterio requiere que cada una de las secuencias operacionales sea atravesada al menos una vez. En el contexto de Servicios Web se considera el flujo de control que definen las secuencias de invocaciones a las operaciones. Un criterio an´alogo se denomina criterio de flujo de operaciones[8].

Estos criterios han sido presentados de menor a mayor cubrimiento de acuerdo a la relaci ón de subsumci ón que existe entre ellos. En el caso del último criterio se pueden considerar dos casos particulares de dependencia sobre las invocaciones a las interfaces [166]:

(22)

Inter-componente. Cuando los eventos de la interfaz de un componente presentan depen-dencia coneventos externos. Los eventos externos se corresponden con eventos provocados por un componente y atendidos por otro, lo cual genera interacciones entre dos componen-tes. Esto requiere dise ˜nar tests en los cuales interviene un componente cliente y un compo-nente servidor.

Las dependencias anteriores son válidas en el contexto de Servicios Web, pero además se consi-deran otras dependencias en funci ón de los datos (mensajes) de entrada y salida de las operacio-nes [8]:

De la entrada. Cuando dos operaciones comparten los mismos mensajes de entrada.

De la salida. Cuando dos operaciones comparten los mismos mensajes de salida.

De entrada/salida. Cuando al menos uno de los mensajes de salida de una operaci ´on, es el mensaje de entrada de otra operaci ´on.

Sobre ambos tipos de dependencias – invocaciones a las interfaces y de datos (mensajes) – se pueden considerar inter-relaciones (combinaciones), para as´ı cubrir adecuadamente el flujo de control y datos para los Servicios Web.

Estrategias de Testing para Componentes y Servicios Web

La calidad y volumen de informaci ón que ofrece un componente/servicio sobre si mismo habi-lita la aplicaci ón de ciertas estrategias de testing. As´ı la posibilidad de contar con el acceso a un c ódigo fuente o a un c ódigo binario, o bien a la especificaci ón de un modelo, permite distinguir un tipo de componentes tal comoin-housey FOSS, los cuales podr´ıan ser también Servicios Web (desde la perspectiva de un proveedor), o bien otros componentes cuya única informaci ón dispo-nible consiste en las signaturas de las operaciones provistas, como la mayor´ıa de los componentes COTS, y nuevamente los Servicios Web (desde la perspectiva de un cliente).

Algunas técnicas de testing asumen la accesibilidad al c ódigo fuente, mientras que otras descar-tan tal disponibilidad pero dependen de que el proveedor incorpore informaci ón de testing o que el cliente pueda extraer cierta informaci ón de los componentes/servicios [89, 20].

A continuaci ón se identifican las estrategias de testing en el contexto de CBSD y Servicios Web, estableciendo una relaci ón con estrategias tradicionales que fueran directamente aplicables o con alguna adaptaci ón en este contexto. En general las estrategias en el software tradicional se clasi-fican en testing“basado en especificación” y testing“basado en código” [16, 13, 20].

Testing basado en Especificaci´on

También denominado testing de“caja negra”, encontramos técnicas funcionales y las ba-sadas en estado. El objetivo es revelar defectos (faults) relacionados con la funcionalidad externa, con la comunicaci ón de las interfaces entre m ódulos, con las restricciones reque-ridas (pre- y post-condiciones), y con el comportamiento de un programa. El problema es que generalmente la especificaci ón existente no es formal, lo cual dificulta la creaci ón de un TS para ejercitar los programas en forma sistemática. Sin embargo, los criterios basados en especificaci ón pueden usarse en cualquier contexto (procedural, OO, CBSD y Servicios Web) sin necesidad de una adaptaci ón importante.

Testing basado en C´odigo

(23)

de programaci ´on y la necesidad de tener acceso al c ´odigo fuente. Este factor no siempre es posible en el caso de componentes software (de acuerdo a su tipo y la perspectiva proveedo-r/cliente), y en el caso de Servicios Web no es directamente aplicable (desde la perspectiva de un cliente).

Testing Funcional: Se utiliza la especificaci ón para obtener los requerimientos de testing o los datos de test, sin ning ún conocimiento sobre la implementaci ón [138]. Se requiere una especifi-caci ón de alta calidad que se corresponda con los requerimientos del cliente, para as´ı soportar la aplicaci ón de los criterios funcionales. Ejemplos de tales criterios para testing tradicional son [16]: 1) Partici ón de Equivalencia; 2) Análisis de Valores L´ımite; 3) Grafo Causa-Efecto; y 4) Partici ón por Categor´ıa [6].

En el contexto de CBSD y Servicios Web, el cliente de un componente/servicio puede utilizar estas estrategias directamente. Sin embargo, como ocurre con todas las estrategias de caja ne-gra, resulta necesario disponer de una adecuada especificaci ón que provea informaci ón sobre las funciones (y argumentos) que son implementados en las operaciones provistas por un compo-nente/servicio. Por otro lado, la aplicaci ón de estrategias de caja negra no asegura que las partes esenciales de la implementaci ón puedan ser adecuadamente cubiertas [26, 89, 20].

Testing basado en Estado: Se utiliza una representaci ´on basada en una M´aquina de Estados Finita (FSM11) de la unidad bajo test. Basado en este modelo, los criterios para generar secuencias de test se utilizan para asegurar un comportamiento correcto [33, 147, 63].

Estos criterios son ampliamente usados en el contexto de OO para representar los aspectos de comportamiento de los objetos. Entre ellos se destacan elcriterio de estados,de eventosyde acciones entre los m´as d´ebiles, luego elcriterio de transicionesque cubre a los anteriores [9, 83, 72, 120], y luego criterios de mayor cubrimiento como elcriterio de caminos ida-vueltaparticularmente pro-puesto por [16].

También se utilizan los criterios de FSM en el contexto del software basado en componentes y orientado a servicios, dado que s ólo requieren una representaci ón basada en estado para ser apli-cados [14, 26]. En particular, si los componentes proveen especificaciones descritas en la forma de un FSM, se puede construir un FSM extendido integrando las especificaciones y luego aplicar los criterios basados en estado [29]. Pero además se pueden utilizar para construir una especie de grafo de flujo de control de la integraci ón del comportamiento de todos los componentes que forman el sistema. El usuario del componente puede entonces aplicar una adaptaci ón de las es-trategias de testing tradicional de flujo de control y flujo de datos para as´ı construir el TS [14, 20].

Testing Estructural: Se utilizan los aspectos de implementaci ón para determinar los requeri-mientos de testing. La mayor´ıa de los criterios de la técnica estructural se basan en un Grafo de Flujo de Control (también denominado Grafo de Programa) para representar el programa bajo test.

Los criterios estructurales se clasifican en: basados enflujo de control, y enflujo de datos. Entre los primeros se cuentan elcriterio de nodos(sentencias o comandos), elcriterio de arcos(o decisiones), y elcriterio de los caminos[138, 115]. Los criterios deflujo de datosexponen las interacciones entre las definiciones y los usos de las variables, y se componen de los criterios anteriores, agregando aquellos introducidos por [140], tales como, elcriterio de los p-usos,de las definiciones,de los usos, y de los du-caminos.

Se han generado diversas extensiones de los criterios de flujo de datos, tanto para testing de integraci ´on de programas procedurales, como de testing de unidad e integraci ´on para OO [78, 16].

El testing estructural, sin embargo, enfrenta serias restricciones y desventajas en relaci ´on con la necesidad de determinar requerimientos de testing inviables, tales como caminos no ejecutables y

(24)

asociaciones imposibles. Estas restricciones generan serios problemas para la automatizaci ón de testing. No obstante, esta técnica parece ser complementaria al testing funcional y la informaci ón que se obtiene con su aplicaci ón también resulta relevante para el mantenimiento, depuraci ón y estimaci ón de confiabilidad de software [138, 13].

Dado que estos criterios requieren el acceso al c ´odigo fuente, resulta en general imposible su aplicaci ´on en el contexto de CBSD para un cliente de componentes o Servicios Web [26].

Testing basado en Defectos: Se utiliza informaci ón de los defectos que se encuentran con ma-yor frecuencia en los distintos proyectos de desarrollo y además considera los tipos de defectos espec´ıficos que un ingeniero de testing desea descubrir. Existen dos criterios que t´ıpicamente se concentran en defectos: Inyecci ón de Errores (error seeding) y Testing Mutacional [49, 157, 90]. En la técnica deInyecci ón de Erroresse introducen en el programa bajo test (PUT12), un n úmero conocido de defectos artificiales previo a ejercitar el TS, para que luego del test se calcule el ratio entre defectos naturales/artificales a partir del n úmero total de defectos encontrados, y con ello se estima el n úmero de defectos naturales restantes [22, 43, 61].

ElTesting Mutacionalse basa en aplicar ligeros cambios al c ódigo fuente de un PUT generando nuevas versiones que deber´ıan comportarse de forma defectuosa. Las versiones defectuosas se denominan mutantes, y se crean en base a operadores de mutaci ón, que son reglas que definen cambios sintácticos que se aplican sobre el PUT para crear los mutantes. El prop ósito es evaluar la capacidad de un TS para distinguir la diferencia entre PUT y sus mutantes. Cuando un mu-tante tiene un comportamiento diferente al de PUT (es decir, las salidas de PUT y del mumu-tante son diferentes para alg ún caso de test de TS) se dice que el mutante “muere”; si no, el mutante permanece “vivo”. Un mutante vivo debe ser analizado para comprobar si es funcionalmente equivalente al PUT o si puede crearse alg ún nuevo caso de test que permita matar al mutante, promoviendo de esta manera la mejora del TS. Uno de los problemas con la técnica de mutaci ón es el alto costo de ejecutar un gran n úmero de mutantes [49, 29, 20].

Se han propuesto extensiones de este criterio para testing de integraci ón y para especificaciones de programas. Por ejemplo se ha definido el criterio de Mutaci ón de Interfaces que aplica el concepto de mutaci ón a la fase de testing de integraci ón. Con este criterio se propuso un nuevo conjunto de operadores mutantes especializados en errores de integraci ón [48, 70].

En el contexto de las especificaciones de testing, la mutaci ón puede ser usada para la comproba-ci ón mediante Redes de Petri y FSM [29], entre otros. Además se han propuesto enfoques para OO, que no difieren significativamente de los operadores mutantes tradicionales, pero introdu-cen operadores especializados correspondientes a aspectos propios de la OO tales como clases y relaciones entre clases [119].

En el caso de componentes que no proveen acceso al c ódigo fuente, a ún se pueden aplicar ciertas estrategias basadas en defectos, particularmente en funci ón de las interfaces provistas por los componentes. As´ı la técnica de Mutaci ón de Interfaces [48, 70] se puede utilizar con m´ınimos ajustes en el contexto de CBSD y de Servicios Web [29, 26].

1.5. Organizaci ´on de la Tesis

A continuaci ´on se describe en forma sint´etica el contenido del resto de los cap´ıtulos que com-prenden la estructura de esta Tesis:

Cap´ıtulo 2 Se presenta el Estado del Arte en Selecci ón e Integraci ón de Servicios, donde las pro-puestas son analizadas de acuerdo a un conjunto de caracter´ısticas definidas a partir de la literatura relacionada. Además, se discuten los problemas abiertos y desaf´ıos de investiga-ci ón actuales en el tema, lo que sustenta la propuesta de la presente tesis.

(25)

Cap´ıtulo 3 Se introduce una descripci ón general del Método deSelecciónde Servicios Web, y lue-go se presenta el procedimiento deAnálisis de Compatibilidad de Interfaces, que consiste de dos versiones: una puramenteestructuraly otrah´ıbrida(estructural-semántica) donde se aplican diferentes criterios de equivalencia y bases semánticas subyacentes.

Cap´ıtulo 4 Se presenta el procedimiento deEvaluaci ón de Compatibilidad de Comportamien-to, donde se desarrolla la generaci ón de artefactos adaptadores (wrappers) y que consta de dos versiones: la evaluaci ón exhaustiva,en funci ón del análisis puramenteestructuraly la versi ónreducida,en funci ón del análisish´ıbridode interfaces.

Cap´ıtulo 5 Se presenta la evaluaci ón experimental del Método de Selección de Servicios Web, que consta de un framework experimentale para evaluar los procedimientos a nivel de interfaces de servicios.

(26)

Cap´ıtulo 2

Estado del Arte en Selecci ´on e

Integraci ´on de Servicios

2.1. Introducci ´on

Recientemente, la adopci ón de Servicios Web se ha vuelto la alternativa con mayor potencial para soportar la integraci ón segura y transparente de aplicaciones B2B1_{. De esa manera, el}_framework elemental de servicios, constitu´ıdo sobre los estándares de base SOAP, WSDL y UDDI, es impul-sado hacia una frontera donde la norma com ún sea la composici ón y colaboraci ón. Esto implica poder combinar servicios tercerizados para ofrecer nuevos servicios con valor agregado.

Sin embargo, los mecanismos de selecci ón e integraci ón de servicios deben tener en cuenta m últi-ples y complejos factores, tal como el potencial de composici ón (composability), la adaptabilidad frente a fallos o incompatibilidades, ó la verificaci ón y validaci ón de ciertas propiedades espe-radas. Como resultado, las soluciones actuales para selecci ón de Servicios Web ya sea desde la industria (con base en las plataformas deworkflow) o la academia (con base en la Web Semántica) carecen de una adopci ón amplia y estandarizada [19, 141, 67]. En consecuencia, analizar y deci-dir sobre los mecanismos y plataformas de selecci ón más adecuados para cada contexto puede resultar impracticable.

Además, en los últimos a ños los servicios REST captaron la atenci ón como una soluci ón ligera, brindando escalabilidad, confiabilidad y visibilidad. REST es un estilo arquitect ónico que utiliza los métodos básicos de HTTP (get, put, post, delete) para acceder y manipular los recursos. La transici ón entre los estados de la aplicaci ón en REST se realiza siguiendo el principio HATEOAS2 mediante la navegaci ón a través de hiperv´ınculos [56, 96]. Los servicios REST son una alternativa para implementar Servicios Web paralela a los estándares relacionados con SOAP – estos últimos a veces abreviados como WS-*. Los servicios REST presentan cuatro propiedades caracter´ısticas:

1. El estado y la funcionalidad de la aplicaci ´on se abstraen bajo el concepto derecurso. 2. Cada recurso es direccionable un´ıvocamente utilizando un v´ınculo hipermedia (URI).

3. Todos los recursos comparten una interfaz uniforme para transferir el estado – esto es, los m´etodos HTTP.

4. Son f´acilmente consumibles y combinables por el usuario final en los denominados mas-hups.

1_{Business to Business}

(27)

Figure 2.1: Comparaci ´on de las pilas de lenguajes para SOAP y REST

Los proveedores y consumidores de servicios han comenzado a adoptar arquitecturas REST, y por ello es importante estudiar c ómo esta riqueza de nuevos servicios puede ser reutilizada por medio de selecci ón, adaptaci ón, testing y finalmente composici ón [131]. En tal sentido, se estu-dian en este cap´ıtulo algunos enfoques ligeros emergentes basados en servicios REST. Estos son evaluados de acuerdo a las caracter´ısticas definidas para servicios SOAP y luego de acuerdo a un conjunto de caracter´ısticas propias de servicios REST. La Figura 2.1 ilustra diferentes pilas de lenguajes y protocolos para servicios basados en SOAP y REST, donde se vislumbra que para servicios basados en SOAP se han propuesto más cantidad de lenguajes y estándares [96]. Existe en la comunidad de Servicios Web un debate social y técnico acerca de “REST vs. SOAP” [174, 131] desde el punto de vista del proceso de estandarizaci ón, y de las implicacio-nes de estas filosof´ıas de dise ño. Sin embargo, REST y SOAP no son necesariamente opuestos: REST es un estilo arquitectonico, y SOAP es un protocolo general que puede ser un elemento de muchas arquitecturas diferentes. Los autores sugieren pensar REST como un estilo navegacio-nal, y SOAP como un estilo procedural. A pesar de que estos términos son entendibles y usados frecuentemente, pueden generar cierta controversia.

En este Cap´ıtulo, proponemos en primer lugar un conjunto de caracter´ısticas (Secci ón 2.1.1) para identificar el valor agregado de cada mecanismo de selecci ón y composici ón de servicios – esta última como una extensi ón de la anterior. Además, se presenta un conjunto de caracter´ısticas propias de los servicios REST (Secci ón 2.1.2) que complementan a las anteriores en el análisis de este tipo particular de servicio.

Luego, basado en esas caracter´ısticas, analizamos trabajos representativos desde una perspectiva comparativa. Se agruparon los enfoques de acuerdo a tres ejes temáticos abordados a lo largo de esta de tesis: Selecci ón de Servicios (Secci ón 2.2.1), Adaptaci ón (Secci ón 2.2.2) yTesting (Sec-ci ón 2.2.3). Además, se realiza un análisis de propuestas basadas en servi(Sec-cios REST (Sec(Sec-ci ón 2.2.4). Finalmente, se discuten los puntos importantes del análisis de trabajos relacionados (Secci ón 2.3) que justifican el desarrollo de esta tesis.

2.1.1. Caracter´ısticas para analizar propuestas en Servicios Web

Se han llevado a cabo varias iniciativas para proporcionar plataformas y lenguajes que permitan la integraci ´on de sistemas heterog´eneos inter-organizacionales, tal como OWL-S3 [47] para el

(28)

marcado sem´antico de los servicios y composiciones, y BPEL4para la representaci ´on deworkflows de servicios, dondea prioriya se conocen los enlaces entre los servicios [163].

A pesar de todos estos esfuerzos, el ciclo de vida de los Servicios Web (Descubrimiento, Selecci ón, Integraci ón y Composici ón) sigue siendo una tarea muy compleja. Sin embargo, está más allá de la capacidad de un desarrollador hacer frente a todo este proceso de forma manual [139]. Como los Servicios Web pueden ser desarrollados por diferentes organizaciones, utilizando diferentes modelos conceptuales, actualmente es imposible definir y evaluar los Servicios Web de manera imparcial y con un lenguaje com ún. En este contexto, las propuestas actuales para la especifica-ci ón de Serviespecifica-cios Web y composiespecifica-ciones se pueden interpretar como una transiespecifica-ci ón haespecifica-cia un nuevo frameworkrobusto para el desarrollo de aplicaciones basadas en Servicios Web. Sin embargo, a ún persiste el desacuerdo sobre la estandarizaci ón: la industria y la academia no pueden hacer frente a los problemas de interoperabilidad real sin estándares robustos y comunmente acordados [42]. Por lo tanto, otro reto principal en los ecosistemas de servicios es verificar y satisfacer la inter-operaci ón de servicios potencialmente compatibles [54].

Para el análisis de trabajos relacionados, en este cap´ıtulo definimos un conjunto de ocho carac-ter´ısticas que describen c ómo los diferentes trabajos utilizan y/o proponen tecnolog´ıas, lengua-jes, prácticas y estándares orientados a servicios. Además, hemos validado convenientemente este conjunto de caracter´ısticas en relaci ón a otros relevamientos del estado del arte en SOA [67]. La Tabla 2.1 presenta un resumen de cada caracter´ıstica, junto con una lista de sus posibles va-lores. Luego, las secciones siguientes analizan los enfoques actuales en Selecci ón, Adaptaci ón y Testing de Servicios Web en base a este conjunto de caracter´ısticas.

Perspectiva La Perspectiva caracteriza a los enfoques actuales teniendo en cuenta la forma en que se combinan o componen los servicios, principalmente: orquestaci ón, coreograf´ıa,workflow, omashup. Orquestaci ón y coreograf´ıa [134] parecen abarcar todas las alternativas de composici ón basadas en SOAP e incluso se superponen ligeramente. También se aplican a muchos enfoques de composici ón de servicios REST. Además, la perspectiva deworkflowsurge del hecho de que, en muchos sentidos, una composici ón de servicios es similar a unworkflow. El interés actual en Servicios Web está dirigiendo la atenci ón a las cuestiones que tienen una historia más larga en la comunidad deworkflows[174, 139]. La persectiva demashupes estrictamente inherente a los enfoques REST.

Los posibles valores para esta caracter´ıstica son: “Orquestaci ´on”, “Coreograf´ıa”, “Workflow”, “ Mas-hup”, o “Ad-hoc”.

Automatizaci ón De acuerdo con esta caracter´ıstica, los enfoques sobre Servicios Web se pueden clasificar en tres categor´ıas: manual, semi-automático y automático [103]. Los enfoques manua-les esperan que el usuario generescriptsde aplicaciones basadas en servicios (para delinear la funcionalidad de una manera abstracta) ya sea gráficamente o mediante un editor de texto, y a continuaci ón especifican los scripts para un motor de ejecuci ón. Sin embargo, estos sistemas tienen varios inconvenientes, tales como el esfuerzo de programaci ón, ligadura manual – que implica reemplazar manualmente los servicios al detectar fallos – y la necesidad de usuarios con buenos conocimientos de programaci ón y servicios. Las técnicas semi-automatizadas hacen sugerencias para la selecci ón de servicios durante el proceso. No obstante, el usuario debe selec-cionar los servicios y vincularlos en el orden deseado. Estos sistemas no son escalables – ya que el proceso de filtrado puede ofrecer numerosos servicios para que el usuario seleccione – y care-cen de mecanismos de auto-adaptaci ón. Finalmente, las técnicas automatizadas utilizan técnicas de IA como planificadores o técnicas similares para automatizar todo el proceso. Sin embargo, una automatizaci ón total requiere la comprensi ón del contexto, la semántica y el dominio del problema.

(29)

Tabla 2.1:Resumen de caracter´ısticas para analizar trabajos relacionados

Categor´ıa Nombre Descripci ´on Valores

Tecnolog´ıas

Perspectiva

Perspectiva (un participante, m ´ultiples participantes) y punto de vista (desde un servicio en particular, vista general).

Orquestaci ´on / Coreografia / Workflow / Mashup / Ad-hoc

Automatizaci ´on

La soluci ón propuesta es automática hasta cierto punto, a través del uso de ontolog´ıas u otro soporte para

razonamiento sem´antico, t´ecnicas de planning, etc.

Manual / Semi-Auto / Auto

Definici ´on y ligadura

Las aplicaciones se construyen ensamblando servicios en tiempo de dise ño (estática), en tiempo de ejecuci ón y on-the-fly(dinámica), o combinando ambas (h´ıbrida).

Est´atica / Din´amica / H´ıbrida

Est´andares Conformidad

La soluci ón propuesta adhiere a estándares técnicos, o a lenguajes/especificaciones estandarizados para describir los servicios y/o su combinaci ón (composici ón).

Si(nombre del est´andar)/ No Especificaci ´on Especificaciones de Servicios Web (y/o composiciones)

aceptados por la propuesta

(nombre del lenguaje)/ Ad-hoc

Practicas

Adaptaci ´on

La l ógica de interconexi ón de servicios puede ser alterada desde una perspectiva abstracta o concreta. En caso de adaptaciones a nivel concreto, las incompatibilidades funcionales se manejan modificando las interfaces o el orden de los mensajes (protocolo), mientras que otras fallas pueden ser manejadas ligando nuevos servicios concretos al workflow. Abstracto / Concreto (Interfaz, Protocolp, re-ligadura de Workflow) / Ambos/ No Aplicable Verificaci ón &

Validaci ´on (V&V)

La soluci ón propuesta soporta verificaci ón y/o validaci ón a través de testing, monitoreo, simulaci ón, etc.

Si(mecanismo)/ No

QoS La propuesta considera criterios de calidad (QoS) o

propiedades no funcionales (NFPs) Si (criterios) / No

Definici ón y Ligadura Los servicios pueden ser ligados de forma manual y en base a una de-finici ón existentea priori– denominado enfoque estático; o de forma aut ónoma y bajo deman-da (on-the-fly) – denominado enfoque dinámico [31]. En comparaci ón, la definici ón y ligadura dinámica permiten a las aplicaciones ser más flexibles y adaptables al contexto y las preferencias del usuario (por ejemplo, la ubicaci ón, el tiempo, y el perfil). La alternativa dinámica también reduce los costos de desarrollo de aplicaciones por el ahorro de tiempo de descubrimiento de servicios. Sin embargo, la composici ón de servicios estática es más adecuada para el dise ño de patrones de interacci ón complejos, como bifurcaci ón o iteraci ón, a menudo presentes en las apli-caciones B2B, que son complejas, pero fáciles de prever en tiempo de dise ño [62].

Los posibles valores para esta caracter´ıstica son “Est´atica”, “Din´amica”, o “H´ıbrida”.

Conformidad con Estándares Sin un acuerdo s ólido y com ún sobre los estándares, los inves-tigadores y profesionales no pueden hacer frente a los problemas de interoperabilidad [42]. Los estándares están, por definici ón, bien fundamentados y documentados. Intuitivamente, los enfo-ques estandarizados pueden ser más fáciles de implementar y adoptar que las soluciones ad-hoc. Los posibles valores para esta categor´ıa son Si/No, junto con los nombres de los estándares adop-tados.