Universidad Nacional del Centro de la Provincia De Buenos Aires Facultad de Ciencias Exactas - Departamento de Computación y Sistemas
Ingeniería de Sistemas
Una evaluación empírica de técnicas para aumentar la
descubribilidad de Servicios Web Code-first
por
Silvina Daiana Wesner
Diego Martín Piu
Director: Dr. Juan Manuel Rodríguez
Co-Director: Dr. Cristian Mateos Diaz
Trabajo final de carrera presentado como requisito parcial para optar por el título de
Ingeniero de Sistemas
Resumen
Históricamente ha sido importante la reutilización de funcionalidad para la industria del software ya que permite reducir costos y focalizar el desarrollo en implementar la funcionalidad principal del sistema, reduciendo el tiempo que sería necesarios si todo el software debiera ser implementado de cero. El paradigma Service Oriented Comput-ing (SOC) brinda la posibilidad de reutilizar componentes escritos por terceros que se ejecutan de manera remota en los servidores de quienes proveen la funcionalidad. Es decir, SOC es la evolución del desarrollo de sistemas basados en componentes para am-bientes heterogéneos y distribuidos. Bajo este paradigma, la funcionalidad es expuesta mediante componentes llamados servicios que cuentan con una interfaz bien definida y respetando la técnica de caja negra. Actualmente, la manera más común de imple-mentar este paradigma es a través de protocolos Web estándar, tales como Hipertext Transfer Protocol (HTTP), Simple Object Access Protocol (SOAP) y Extensible Markup Language (XML). Cuando estos protocolos se emplean para implementar servicios, a estos servicios se los denomina Servicios Web.
La arquitectura Service Oriented Architecture (SOA) describe la estructura general de los sistemas SOC. En ella se define la interacción entre componentes que cumplen tres roles principales: Proveedor de Servicios, Consumidor de Servicios y Registro de Servicios. Los proveedores desarrollan los servicios definiendo tanto su lógica como su interfaz y publican información acerca de éstos en un registro. Por otro lado, los consumidores que quieren utilizar funcionalidad de terceros, buscan los servicios que necesitan en un reg-istro de servicios y luego los invocan remotamente. En todas las interacciones entre los distintos roles se utiliza un artefacto que contiene la información técnica y semántica de un servicio y se denomina Web Service Description Language (WSDL). Un documento WSDL se puede dividir en dos partes: abstracta y concreta. La parte abstracta contiene elementos que especifican un Servicio Web independientemente de los protocolos sopor-tados para invocarlo. Mientras que la parte concreta define cómo la parte abstracta está vinculada a los protocolos de invocación, es decir, se refiere a la implementación del ser-vicio. Pese a la importancia que tienen estos documentos, varios autores han señalado diversos problemas que aparecen de manera recurrente en los mismos y que se deben a malas prácticas adoptadas por los desarrolladores al momento de escribir servicios o que son incorporadas a los documentos por las herramientas que los generan. Cada mala práctica o anti-patrón está conformado por un nombre, sus síntomas y la manara de solu-cionarlo. Es importante que los documentos WSDL no contengan anti-patrones ya que dificultan que los consumidores puedan descubrir los servicios.
Agradecimientos
Queremos agradecerle a nuestras familias por el apoyo brindado a lo largo de la carrera, también a nuestros amigos y compañeros que de una u otra manera fueron parte de este camino.
Además, queremos hacer extensivo el agradecimiento a los directores de este trabajo final por el apoyo y la paciencia que nos tuvieron todo este tiempo.
Por último, queremos dedicar este trabajo final a nuestro hijo Luca.
Índice
1 Introducción 1
1.1 Nociones Preliminares . . . 1
1.2 Motivación . . . 5
1.3 Organización del Informe . . . 6
2 Contexto 9 2.1 SOC y Servicios Web . . . 9
2.2 WSDL . . . 11
2.3 Descubrimiento de Servicios Web . . . 13
2.3.1 Web Service Query By Example (WSQBE) . . . 15
2.3.2 Lucene . . . 17
2.4 Anti-patrones de descubrimiento . . . 18
2.4.1 Comentarios faltantes o inapropiados . . . 19
2.4.2 Nombres ambiguos . . . 19
2.4.3 Operaciones poco cohesivas . . . 20
2.4.4 Tipos de datos comodines . . . 21
2.4.5 Información de error encubierta en mensaje estándar . . . 22
2.4.6 Modelo de datos adjunto . . . 22
2.4.7 Modelo de datos redundante . . . 23
2.4.8 Port-types redundantes . . . 23
ÍNDICE
3 Trabajos relacionados 25
3.1 Una herramienta para generar descripciones de Servicios Web evitando
malas prácticas . . . 26
3.1.1 Detector de problemas de diseño sobre el código fuente de un Ser-vicio Web . . . 26
3.1.2 Generador automático de documentos WSDL . . . 30
3.2 Un enfoque para la mejora temprana de la calidad de los Servicios Web code-first . . . 33
3.3 Conclusiones . . . 38
4 Evaluación experimental del analizador de malas prácticas 39 4.1 Análisis Manual y Automático . . . 40
4.1.1 Adaptación del plug-in . . . 42
4.2 Comparación del análisis Manual vs. Automático . . . 43
4.2.1 Comentarios de métodos faltantes . . . 45
4.2.2 Comentarios de métodos inapropiados . . . 45
4.2.3 Nombres ambiguos en métodos . . . 46
4.2.4 Nombres ambiguos en parámetros . . . 46
4.2.5 Operaciones poco cohesivas . . . 47
4.2.6 Tipos de datos comodines . . . 47
4.2.7 Información de error encubierta en mensaje estándar . . . 47
4.3 Conclusiones de los resultados obtenidos . . . 48
4.3.1 Análisis Receiving Operating Characteristic (ROC) . . . 50
4.4 Conclusiones . . . 51
5 Evaluación experimental de la descubribilidad 53 5.1 Refactorización de código fuente y generación de los documentos WSDL . 54 5.2 Ejecución del experimento y comparación de resultados . . . 56
5.2.1 WSQBE . . . 57
5.2.2 Lucene4WSDL . . . 63
ÍNDICE
6 Conclusiones y trabajos futuros 71
Lista de Figuras
1.1 SOC Roles . . . 2
1.2 Estructura de los documentos WSDL . . . 3
2.1 Vista de alto nivel del enfoque WSQBE . . . 16
2.2 Arquitectura general de Lucene . . . 18
4.1 Partes del Plugin . . . 44
4.2 Gráfico ROC . . . 50
5.1 Generación masiva de WSDLs . . . 56
5.2 Original vs. Refactorizados (Nombres ambiguos) sin ruido . . . 58
5.3 Original vs. Refactorizados (Nombres ambiguos) con ruido . . . 58
5.4 Original vs. Refactorizados (Comentarios faltantes o inapropiados) sin ruido 59 5.5 Original vs. Refactorizados (Comentarios faltantes o inapropiados) con ruido . . . 59
5.6 Original vs. Refactorizados (Operaciones poco cohesivas) sin ruido . . . . 60
5.7 Original vs. Refactorizados (Operaciones poco cohesivas) con ruido . . . 60
5.8 Original vs. Refactorizados (Información de error encubierta en mensaje estándar) sin ruido . . . 61
5.9 Original vs. Refactorizados (Información de error encubierta en mensaje estándar) con ruido . . . 62
5.10 Original vs. Refactorizados (Tipos de datos comodines) sin ruido . . . 62
LISTA DE FIGURAS
5.12 Original vs. Refactorizados (Nombres ambiguos) sin ruido . . . 63 5.13 Original vs. Refactorizados (Nombres ambiguos) con ruido . . . 64 5.14 Original vs. Refactorizados (Comentarios faltantes o inapropiados) sin
ruido . . . 64 5.15 Original vs. Refactorizados (Comentarios faltantes o inapropiados) con
ruido . . . 65 5.16 Original vs. Refactorizados (Operaciones poco cohesivas) . . . 65 5.17 Original vs. Refactorizados (Operaciones poco cohesivas) con ruido . . . 66 5.18 Original vs. Refactorizados (Información de error encubierta en mensaje
estándar) sin ruido . . . 67 5.19 Original vs. Refactorizados (Información de error encubierta en mensaje
Lista de Tablas
1.1 Catálogo de Anti-patrones . . . 4
3.1 Clasificación de anti–patrones en base a la etapa donde se originan . . . . 27
3.2 Métricas Orientadas a Objetos . . . 35
4.1 Partes analizadas por cada detector . . . 41
4.2 Resultados obtenidos del análisis manual y automático . . . 41
4.3 Estructura matriz de confusión . . . 44
4.4 Matriz de confusión para el detector Comentarios faltantes . . . 45
4.5 Matriz de confusión para el detector Comentarios inapropiados . . . 46
4.6 Matriz de confusión para el detector Nombres ambiguos en métodos . . . 46
4.7 Matriz de confusión para el detector Nombres ambiguos en parámetros . 46 4.8 Matriz de confusión para el detector Operaciones poco cohesivas . . . 47
4.9 Matriz de confusión para el detector Tipos de datos comodines . . . 47
4.10 Matriz de confusión para el detector Información de error encubierta en mensaje estándar . . . 48
4.11 Resumen de resultados . . . 48
Glosario
API Application Programming Interface ATC Abstract Type Count
CAM Cohesion Among Methods CBO Coupling Between Objects DAM Data Access Metric
EPM Empty Parameter Methods HTML HyperText Markup Language HTTP Hipertext Transfer Protocol IR Information Retrieval
LCOM Lack of Cohesion in Methods
LCOM-3 Lack of Cohesion in Methods (Henderson-Sellers) LOC Lines Of Code
NAICS North American Industry Classification System
OASIS Organization for the Advancement of Structured Information Standards PDF Portable Document Format
QBE Query By Example RFC Response For a Class
LISTA DE TABLAS
SOA Service Oriented Architecture SOAP Simple Object Access Protocol SOC Service Oriented Computing TPC Total Parameter Count
UDDI Universal Description Discovery and Integration
UNSPSC United Nations Standard Products and Services Code URI Uniform Resource Identifier
URL Uniform Resource Locator VSM Vector Space Model
W3C World Wide Web Consortium WMC Weigthed Method per Class
Cap´ıtulo
1
Introducción
La creciente complejidad de los sistemas de software hace de la reutilización de compo-nentes una de las herramientas más valiosas para el desarrollo de nuevos sistemas de software [35]. Una de las opciones existentes para la reutilización de componentes es brindada por el paradigma SOC, el cual se basa en la utilización de componentes que se ejecutan de manera remota en los servidores de quienes proveen la funcionalidad. Bajo este paradigma, la funcionalidad es expuesta mediante componentes llamados servicios. Cada servicio cuenta con una interfaz bien definida que permite, a quienes deseen uti-lizarlo, invocarlo sin necesidad de conocer la implementación del mismo, ni la plataforma en la cual se ejecuta. Adicionalmente, debido a que el servicio es ejecutado en el provee-dor, éstos pueden brindar información que solo ellos conocen. Por ejemplo, pueden ser utilizados para validar compras con tarjeta de crédito de manera on-line o para obtener el último pronóstico del tiempo para una determinada zona geográfica. De esta manera, en este capítulo se introducen los conceptos básicos de SOC, los problemas que existen en la actualidad y cuál es la finalidad del presente trabajo.
1.1
Nociones Preliminares
Figura 1.1:SOC Roles
Una de las maneras de implementar el paradigma SOC es mediante el uso de protoco-los estándares de la Web, tales como SOAP, HTTP y XML. La principal ventaja es que la implementación de estos protocolos ha sido ampliamente adoptada por casi todas las plataformas de software modernas, lo que significa garantizar la interoperabilidad. El uso de estos protocolos en SOC resultó en lo que se conoce como Servicios Web. Además, para los Servicios Web se diseñaron especificaciones particulares, como Universal De-scription Discovery and Integration (UDDI) y WSDL.
UDDI1es un estándar cuyo desarrollo fue promovido por Organization for the Advance-ment of Structured Information Standards (OASIS), y que define mecanismos que per-miten a algunas organizaciones publicar los servicios que proveen y a otras buscarlos, mediante el intercambio de mensajes basados en XML. Además de ser un directorio de servicios, permite publicar información sobre las organizaciones que los proveen, como datos de contacto o información sobre la categoría a la que pertenecen. A pesar de proveer una gran cantidad de funcionalidad, su aceptación no fue tan amplia como la esperada por sus promotores. La excesiva complejidad de UDDI dificulta la tarea de publicar servicios. Por otro lado, su sistema de búsqueda de servicios basado en pal-abras claves ofrece resultados poco relevantes. Estos factores provocaron que los desar-rolladores optaran por otros enfoques más sencillos y menos ambiciosos, que ganaron popularidad y produjeron que el estándar UDDI cesara su desarrollo a partir del año 2007 [13].
WSDL2 se utiliza para representar la funcionalidad de un Servicio Web de forma ab-stracta, mediante un conjunto de operaciones que contienen mensajes de entrada y sal-ida, y permite a los proveedores asociar información para que los consumidores puedan invocar los servicios ofrecidos independientemente de la plataforma en la cual fueron implementados, es decir, abstrae al consumidor de servicios de la implementación de los mismos. Cada tipo de dato de los mensajes de entrada y salida está definido de acuerdo
Figura 1.2:Estructura de los documentos WSDL
al estándar XML Schema Definition (XSD). Éste es una extensión de XML estándar para definir tipos de datos que abarcan aquellos que están incluidos en una amplia gama de lenguajes de programación. Adicionalmente, este lenguaje permite definir toda la infor-mación técnica necesaria para invocar el servicio. Esta inforinfor-mación incluye dónde está el servicio (sitio de Internet), qué protocolos de transporte soporta y, como se sugiere más arriba, los datos de entrada/salida que se utilizan durante una invocación.
Un documento WSDL se puede dividir en dos partes: abstracta y concreta. La parte ab-stracta contiene elementos que especifican un Servicio Web independientemente de los protocolos soportados para invocar el servicio, es decir, se refiere a la definición de la interfaz del mismo. Un ejemplo de esta definición podrían ser los archivos con extensión “h” del lenguaje de programación C. Mientras que la parte concreta define cómo la parte abstracta está vinculada a los protocolos de invocación, es decir, se refiere a la imple-mentación del servicio. En la Figura 1.2 se presenta un esquema de la composición de un documento WSDL.
El descubrimiento de Servicios Web es una de las preocupaciones principales en el de-sarrollo de sistemas SOC ya que los proveedores quieren que los consumidores usen sus servicios y los consumidores están interesados en encontrar los servicios adecuados para construir sus sistemas. Por lo tanto, el descubrimiento es un objetivo central en el paradigma SOC ya que es la clave para el éxito del mismo [34].
Nombre Problema Tipo Solución Sugerida
Comentarios faltantes o inapropiados
Ocurre cuando: (1) un documento WSDL no tiene comentarios o (2) son
inapropiados.
(1) Evidente o (2) No
inmedi-atamente
aparente
Comentar las diferentes partes del documento.
Nombres
Ambiguos
Ocurre cuando se utilizan nombres sin
sentido para los elementos de un documento WSDL.
No
inmediata-mente aparente
Reemplazar los nombres sin
sentido por nombres representativos.
Operaciones poco cohesivas
Ocurre cuando un port-type agrupa operaciones poco relacionadas entre sí o
que no pertenecen al mismo dominio.
No inmediata-mente
aparente
Separar las operaciones poco cohesivas en distintos
port-types.
Tipos de datos comodines
Ocurre cuando un tipo de dato especial es usado para representar cualquier
objeto del dominio del problema.
Evidente Reemplazar los tipos de datos genéricos por otros más acordes
al dominio del problema.
Información de
error encubierta en mensaje estándar
Ocurre cuando mensajes de salida son
usados para notificar errores del servicio.
Presente en la
imple-mentación del
servicio
Usar mensajes de falla para
transmitir información de error.
Modelo de dato adjunto
Ocurre cuando el modelo de datos está definido dentro del documento WSDL
en lugar de en un documento XSD separado.
Evidente Mover la definición de tipos de datos a un documento XSD
separado.
Modelo de dato redundante
Ocurre cuando más de una definición de tipo de dato tienen la misma
información intercambiable en un documento WSDL.
Evidente Redefinir los tipos de datos redundantes en uno nuevo.
Port-type redundate
Ocurre cuando diferentes port-types ofrecen el mismo conjunto de
operaciones.
Evidente Redefinir los port-types redundantes en uno nuevo.
Tabla 1.1:Catálogo de Anti-patrones
1.2
Motivación
El desarrollo de software orientado a servicios requiere proveedores que describan sus servicios y los publiquen en registros, donde los consumidores puedan descubrirlos. En este sentido, el primer paso para incorporar un servicio externo a una aplicación es el
descubrimientoy se refiere a la búsqueda de los servicios que provean las funcionalidades
requeridas. Por esta razón, es fundamental en el desarrollo de software orientado a servi-cios que las descripciones asociadas a ellos sean concisas y que reflejen la funcionalidad ofrecida de la mejor manera posible.
En el desarrollo de Servicios Web existen dos enfoques principales, llamados contract--first y code-contract--first. En este último caso, el desarrollo del servicio comienza a partir de su código fuente. Los desarrolladores pueden escribir un servicio sin tener conocimiento de los WSDL ya que su descripción es generada automáticamente por una herramienta dependiente del lenguaje de programación. Así, el enfoque code-first es simple y fácil de usar para los usuarios que no están familiarizados con los estándares de Servicios Web, ya que los WSDL son difíciles de leer y usar para un principiante. Sin embargo este enfoque proporciona menos control sobre el WSDL dado que éste cambia cada vez que el código fuente es modificado. Además, debido a las falencias de las herramientas de generación automática, existe una gran posibilidad de que la calidad de la descripción de los servicios sea baja.
Por otro lado, en el enfoque contract-first, el desarrollo del servicio comienza definiendo un documento WSDL, que se convierte en un contrato entre el proveedor del servicio y el consumidor. Bajo este enfoque, los documentos WSDL son definidos manualmente por los desarrolladores usando estándares de Servicios Web y el servicio es implementado de acuerdo a ese contrato. Si bien es cierto que el enfoque contract-first es más complejo en comparación con el code-first, a largo plazo se obtienen descripciones de Servicios Web más concisas y más fáciles de leer. A pesar que académicamente existe el consenso de que el enfoque contract-first resulta en descripciones WSDL más descriptivas y auto--contenidas, la industria se basa principalmente en el enfoque code-first dado que es más rápido y consume menos recursos de desarrollo [28, 24].
independientemente de cuán bien documentado se encuentre el código fuente [24]. Adi-cionalmente, como el enfoque se basa en correlaciones existentes entre métricas clásicas de código orientado a objetos y la incidencia de anti-patrones, existe la posibilidad de que en algunos casos la modificación de los valores de una métrica no afecte el número de anti-patrones en los documentos WSDL.
En conclusión, la motivación de este trabajo final es medir la mejora en la calidad, en términos de descubribilidad, de los documentos WSDL generados con el enfoque code--first cuando se aplican las técnicas propuestas en [13] y [28].
Para realizar la comparación se tomará un conjunto de implementaciones de Servicios Web escritas en Java, y con estas se generarán nuevos conjuntos de implementaciones aplicando las refactorizaciones propuestas en [13] y [24] para eliminar anti-patrones. Uti-lizando cada uno de los conjuntos de implementaciones, es decir el original y el refactor-izado, se generarán diferentes conjuntos de documentos WSDL utilizando la herramienta de generación presentada en [13]. Posteriormente, se compararán los distintos conjuntos de documentos WSDL utilizando como parámetro cuántos y qué tipo de anti-patrones afectan a los mismos. Es decir, se aplicará un análisis similar al presentado en [24, 28]. A partir de estos resultados se determinará para qué tipo de anti-patrones funciona mejor cada enfoque [24, 28] y se identificarán puntos débiles de los mismos que puedan ser mejorados en trabajos futuros.
1.3
Organización del Informe
El informe está organizado en los siguientes capítulos. En el Capítulo 2 se introducen los conceptos necesarios que permiten comprender el contexto y el alcance del trabajo. En primer lugar se detallan los conceptos básicos del paradigma SOC y su implementación más común, los Servicios Web. En segundo lugar se describe el lenguaje WSDL, que se utiliza para describir éstos servicios. Posteriormente se profundiza en el concepto de descubribilidad de servicios y en el conjunto de malas prácticas que puede afectar tal característica.
En el Capítulo 4 se describe la primera parte de los experimentos realizados para medir la efectividad del analizador de diseño de la herramienta presentada en el Capítulo 3. Se comparan los resultados arrojados por la misma contra los obtenidos de un análisis manual del código fuente de un conjunto de Servicios Web públicos y reales realizado por los autores del presente trabajo.
En el Capítulo 5 se detalla la segunda parte de los experimentos que se realizaron para determinar para qué anti-patrones la versión refactorizada de los mismos resulta en un impacto positivo en cuanto a la descubribilidad del Servicios Web justificando el tiempo y esfuerzo invertido en quitarlo.
Cap´ıtulo
2
Contexto
Este capítulo profundiza los conceptos básicos del paradigma SOC y su implementación más común, los Servicios Web, en la Sección 2.1. En la Sección 2.2 se detalla cómo son descriptos estos servicios, explicando las partes de un documento WSDL. Además, en la Sección 2.3 se amplía el concepto de descubrimiento de Servicios Web detallando her-ramientas existentes para tal fin. Por último, en la Sección 2.4, se describen las malas prácticas encontradas en los documentos WSDL que pueden afectar la descubribilidad de los mismos.
2.1
SOC y Servicios Web
Históricamente, la reutilización de funcionalidad ha sido una de las cuestiones más im-portantes para la industria del software, debido a que reduce costos de desarrollo así como también tiempos de salida al mercado [32]. Como resultado, muchas técnicas de reuso han evolucionado, desde los lenguajes estructurados que permiten la reutilización de funciones y/o procedimientos hasta los frameworks que permiten a los desarrol-ladores reutilizar las estructuras completas de un sistema [26]. En este contexto, el de-sarrollo de software basado en componentes es un paradigma que tiene como objetivo la reutilización de funcionalidades complejas. Básicamente, un componente de software es una caja negra que se accede a través de una interfaz bien definida, y de esta man-era quien lo utiliza no tiene conocimiento de cómo está implementado, lo que facilita el intercambio de componentes que tienen la misma funcionalidad.
en el mismo lugar físico o en una sola plataforma, sino que se pueden ejecutar en distintos lugares y en distintas plataformas.
Los servicios son la clave del paradigma SOC y, al igual que los componentes, represen-tan funcionalidad con una interfaz bien definida y resperepresen-tando la técnica de caja negra. Esto permite que sean fácilmente intercambiables dado que quien invoca un servicio solo conoce su interfaz. Es decir, si un sistema está usando un servicio y encuentra otro que se adapta mejor, debería ser capaz de utilizar ese servicio en lugar del original sin demasi-adas modificaciones. Aunque los componentes y los servicios son similares en algunos aspectos también tienen diferencias sustanciales. La mayor de estas diferencias es que mientras los componentes son integrados a los sistemas, los servicios están ubicados en los servidores de los proveedores y son accedidos remotamente [34]. Esto permite ofre-cer funcionalidad públicamente que mediante componentes no sería factible, por ejemplo obtener el pronóstico meteorológico más actualizado.
Actualmente, la manera más común de implementar el paradigma SOC es a través de protocolos Web estándar, tales como HTTP, SOAP y XML. Cuando estos protocolos se emplean para implementar servicios, a estos servicios se los denomina Servicios Web. En primer lugar, los Servicios Web son independientes de la plataforma ya que estos proto-colos han sido desarrollados para casi todas las plataformas de software existentes y han sido ampliamente probados. En segundo lugar, dado que estos protocolos son amplia-mente usados, los firewalls no tienden a bloquear este tipo de tráfico, lo que significa que rara vez los Servicios Web son filtrados en las redes de comunicación [14].
documento WSDL. El lenguaje con el que se especifican estos documentos se describe en la siguiente sección.
2.2
WSDL
WSDL es un lenguaje basado en XML, estandarizado por la World Wide Web Consor-tium (W3C), específicamente diseñado para documentar Servicios Web. Este lenguaje permite dividir la descripción de un servicio en dos partes: su funcionalidad y como invocarlo. La primer parte, denominada abstracta, detalla la interfaz del servicio que se ofrece a los potenciales consumidores. La segunda parte, denominada concreta, es-pecifica los aspectos tecnológicos tales como los protocolos de transporte. La principal ventaja de esta división es que la interfaz del servicio es independiente de los protoco-los de comunicación y de donde se ejecutan protoco-los servicios. Como resultado, una parte abstracta puede estar relacionada con distintas partes concretas que ofrecen instancias particulares de un servicio. Los consumidores usan la descripción funcional para com-pararla con sus necesidades y determinar si tal servicio les sirve, en ese caso utilizan los detalles tecnológicos para invocarlo.
La parte abstracta consiste de tres tipos de elementos:
• <type>: definición de los tipos de datos que es escrita mediante un lenguaje basado en XML denominado XSD. Este lenguaje ofrece constructores para la definición de tipos de datos simples y mecanismos para la definición de tipos de datos complejos. Estos tipos de datos pueden ser definidos dentro del documento WSDL o impor-tados de un archivo XSD utilizando el elemento <import>. Este tipo de elemento permite establecer el namespace XML del documento a incluir y también especi-ficar su ubicación mediante una Uniform Resource Identifier (URI). Esto permite que varias definiciones de Servicios Web compartan la misma definición de tipos de datos.
• <message>: definición de la información que puede ser intercambiada entre provee-dores y consumiprovee-dores. Particularmente se describen la entrada, la salida y la in-formación de error de las operaciones atómicas que conforman la interfaz de un servicio. Cada <message> consiste de uno o más componentes lógicos (<part>). Cada componente se relaciona con uno de los tipos definidos en la sección anterior y tiene un nombre único entre todos los mensajes del mismo documento, que se especifica a través del atributoname.
mensajes se emplean para intercambiar información entre el proveedor y el con-sumidor. Básicamente, un mensaje puede cumplir uno de los tres roles especifica-dos: entrada, salida o error. Un mensaje de entrada es la información que un con-sumidor proporciona a un servicio. Un mensaje de salida es el resultado de invocar un servicio que se entrega al consumidor que lo invocó. Por último, el mensaje de error se utiliza para informar que el servicio no funciona según lo esperado por el consumidor.
La parte concreta consiste de dos elementos:
• <binding>: especifica un protocolo para cada port-type. Esto significa que si un proveedor de servicios quiere ofrecer un port-type utilizando más de un protocolo será necesario un elemento binding para cada uno. Este elemento contiene opera-ciones, entradas, salidas y mensajes de error y se lo identifica mediante un nombre definido en el atributoname, que debe ser único dentro del documento. Mediante el atributotypese referencia al port-type asociado a este elemento.
• <service>: agrupa un conjunto de elementos <binding> relacionados a una di-rección Uniform Resource Locator (URL) particular que utilizan los consumidores para invocar las operaciones que ofrece el Servicio Web.
Adicionalmente, todos los elementos que se incluyen en un documento WSDL pueden incluir el elemento <documentation> que permite detallar información útil para las per-sonas que vayan a utilizar el documento ya que podrán interpretar mejor el significado del elemento. Un ejemplo de un documento WSDL puede verse a continuación.
<? xml version ="1.0" ?>
< definitions name=" HelloService "
targetNamespace =" http: // www . examples . com / wsdl / HelloService . wsdl " xmlns ="
http: // schemas . xmlsoap . org / wsdl /"
xmlns:soap =" http: // schemas . xmlsoap . org / wsdl / soap /" xmlns:tns =" http: // www .
examples . com / wsdl / HelloService . wsdl "
xmlns:xsd =" http: // www . w3 . org /2001/ XMLSchema ">
< message name=" SayHelloRequest ">
< part name=" firstName " type=" xsd:string " / >
</ message >
< message name=" SayHelloResponse ">
< part name=" greeting " type=" xsd:string " / >
</ message >
< portType name=" Hello_PortType ">
< operation name=" sayHello ">
< output message =" tns:SayHelloResponse " / >
</ operation >
</ portType >
< binding name=" Hello_Binding " type=" tns:Hello_PortType ">
< soap:binding style =" rpc "
transport =" http: // schemas . xmlsoap . org / soap / http " / >
< operation name=" sayHello ">
< soap:operation soapAction =" sayHello " / >
< input >
< soap:body encodingStyle =" http: // schemas . xmlsoap . org / soap /
encoding /"
namespace =" urn:examples:helloservice " use =" encoded " / >
</ input >
< output >
< soap:body encodingStyle =" http: // schemas . xmlsoap . org / soap /
encoding /"
namespace =" urn:examples:helloservice " use =" encoded " / >
</ output >
</ operation >
</ binding >
< service name=" Hello_Service ">
< documentation >WSDL File for HelloService</ documentation >
< port binding =" tns:Hello_Binding " name=" Hello_Port ">
< soap:address location =" http: // www . examples . com / SayHello /" / >
</ port >
</ service >
</ definitions >
2.3
Descubrimiento de Servicios Web
A pesar de los beneficios que ofrece la utilización de Servicios Web, éstos no han sido ampliamente adoptados y reutilizados debido a la naturaleza compleja de su descubrim-iento [25, 37]. El descubrimdescubrim-iento es, en este contexto, el proceso que permite localizar la descripción de una operación específica. Los proveedores solían utilizar UDDI para hacer públicos sus servicios a potenciales consumidores. UDDI es un registro público diseñado para almacenar de forma estructurada información sobre empresas y los Servicios Web que éstas ofrecen. Un registro UDDI consta de los siguientes componentes:
• Páginas blancas: contienen información de ubicación y contacto de los proveedores de servicios (por ejemplo: dirección, código postal, email, sitio Web, etc.).
estándar y sistemas de clasificación tales como North American Industry Classifi-cation System (NAICS)1 y United Nations Standard Products and Services Code (UNSPSC)2.
• Páginas verdes: ofrecen información técnica de los servicios expuestos por los provee-dores, tales como protocolos de seguridad y transporte soportados por un Servicio Web dado, parámetros necesarios para invocarlo, etc.
UDDI define una Application Programming Interface (API) de consulta para descubrir Servicios Web que es utilizada por los consumidores. Concretamente, esta API recibe una consulta basada en palabras claves y devuelve una lista de documentos WSDL can-didatos. Para poder buscar y consultar un registro, la aplicación cliente debe obtener un token de autenticación que protege la información almacenada en los mismos previniendo el acceso malicioso o no autorizado.
A pesar de los beneficios de contar con un estándar para la especificación de los registros de servicios, en los últimos años UDDI ha ido perdiendo terreno frente a otros enfoques como consecuencia de varias limitaciones. Una de ellas es que solo permite la búsqueda y navegación de Servicios Web por categorías basada en palabras claves. La eficiencia de la navegación por categorías depende de cómo los proveedores clasifican sus servicios y esta clasificación es una tarea que consume tiempo porque las taxonomías usadas común-mente contienen muchas categorías. Esto se deduce en tener registros con páginas amar-illas poco pobladas, lo que influye negativamente en el proceso de descubrimiento [11]. El problema del descubrimiento de Servicios Web ha sido abordado desde varios en-foques. De acuerdo a [12], estos enfoques se pueden clasificar en tres técnicas de des-cubrimiento: motores de búsqueda Web estándar, basados en semántica y basados en Information Retrieval (IR). La primer técnica es transparente para el desarrollador de Servicios Web ya que propone la utilización de buscadores Web, como Yahoo o Google, para la búsqueda de servicios. Esta idea surge para aprovechar las capacidades de estos buscadores ya que las descripciones de los Servicios Web generalmente se encuentran en servidores Web. Sin embargo, este enfoque no es eficiente debido a que las búsquedas retornan los Servicios Web mezclados con páginas Web estándar.
La segunda técnica propone anotar las descripciones de Servicios Web usando conceptos no ambiguos de ontologías compartidas. Asumiendo que los servicios estarán mejor de-scriptos, se espera que la búsqueda de los mismos se simplifique a expensas de aumentar el esfuerzo de desarrollo. Este enfoque tiene la desventaja de que requiere la definición de ontologías para posteriormente describir los servicios. Adicionalmente, definir los ser-vicios y construir las consultas utilizando semántica es una tarea no trivial. Finalmente,
distintas ontologías para el mismo dominio paradójicamente no son compatibles, por lo que una consulta que funciona en un buscador no funcionaría en otro [19, 36].
El tercer enfoque propone indexar los documentos WSDL para posteriormente recuperar los servicios mediante técnicas tradicionales de IR adaptadas para considerar las par-ticularidades de los documentos WSDL. Los documentos WSDL son diferentes a otros tipos de documentos porque, en general, tienen menos cantidad de texto descriptivo y una gran cantidad de información técnica. Todos los registros de servicios basados en IR siguen cuatro pasos básicos para procesar un documento WSDL. El primero es extraer el texto contenido en el documento analizando cada etiqueta en búsqueda de informa-ción útil, tales como comentarios y nombres, removiendo términos poco descriptivos. El segundo paso consiste en separar los elementosnombre ya que éstos usualmente están escritos usando la notación CamelCase (nombreElemento) o la notación adoptada por el lenguaje C (nombre_elemento). El tercer paso consiste en quitar palabras y símbolos comunes conocidos como stop-words, tales como “a”, “the”, “of”, “for” y “&”, porque no brindan información relevante para el registro de servicios. Finalmente, los términos extraídos del documento pueden ser procesados para incrementar su utilidad. Proce-samientos clásicos de esta etapa son la extracción de la raíz semiológica de las palabras, conocido como stemming [31] o ampliación de términos utilizando bases de datos léxi-cas como WordNet [17]. En los registros no solo se guardan los términos asociados a un documento WSDL sino también información acerca de la importancia de estos términos para tal documento. Esta información puede obtenerse, por ejemplo, de la frecuencia de aparición del término en el documento. A continuación se describen con más detalle dos de estos enfoques sintácticos.
2.3.1 WSQBE
Figura 2.1:Vista de alto nivel del enfoque WSQBE
servicios relevantes requerirá buscar los documentos más cercanos en un espacio vecto-rial y su efectividad dependerá de cómo los desarrolladores nombren y documenten sus servicios.
UDDI por sus proveedores. Esta reducción del espacio de búsqueda puede ser interpre-tada como una versión automática de lo que sería un proceso de descubrimiento man-ual, el cual usualmente comprende dos pasos: navegación y selección. Posteriormente, WSQBE compara el ejemplo solo contra los servicios pertenecientes a su categoría (paso 5) y devuelve los similares (paso 6).
Este enfoque utiliza las especificaciones de UDDI para publicar y consultar servicios así que puede ser ubicado entre los usuarios (publicadores y descubridores) y UDDI de modo transparente. Su objetivo es ocultar detalles tecnológicos permitiendo a los usuar-ios que desean descubrir un servicio, proveer un ejemplo mediante (1) una descripción en lenguaje natural del servicio esperado y sus operaciones o (2) una descripción funcional de esas operaciones.
2.3.2 Lucene
Lucene3 es una biblioteca que permite desarrollar aplicaciones con funcionalidad de búsqueda. Estas aplicaciones podrán indexar y buscar datos almacenados en diferentes formatos y medios de almacenamiento como archivos locales, páginas Web, archivos de texto simples, documentos en Microsoft Word, XML, HyperText Markup Language (HTML), Portable Document Format (PDF), o cualquier otro formato a partir del cual la información textual pueda ser extraída.
Los documentos se encuentran representados por su contenido y campos específicos, que tienen que ser definidos de acuerdo al dominio del problema de búsqueda. Cada campo tiene un nombre que lo identifica, un texto o valor binario y una serie de opciones detal-ladas. Éstas describen qué debe hacer Lucene con los valores de cada campo cada vez que un documento es agregado. Luego, en tiempo de búsqueda, un usuario podrá bus-car por "título:servicios" para encontrar todos los documentos donde el valor del campo título contenga el término "servicios". En la Figura 2.2 se muestra la arquitectura gen-eral de Lucene donde pueden observarse las diferentes etapas necesarias para indexar diferentes tipos de datos.
Para indexar datos con Lucene, el texto plano debe ser extraído y luego crear un docu-mento Lucene. Una vez que el docudocu-mento fue creado con los campos completos, puede ser entregado al analizador. Durante este paso, Lucene divide el texto en tokens y eje-cuta una serie de operaciones sobre ellos. Por ejemplo, el texto deberá estar en minúscula antes de indexarlo, para hacer búsquedascase insensitive. También es conveniente quitar todas las palabras que no aportan información tales como artículos, preposiciones, etc. y reducir los tokens restantes a su raíz mediante el uso del algoritmo de Porter [31]. Una vez que la entrada ha sido analizada, se agrega al índice.
Figura 2.2:Arquitectura general de Lucene
Lucene almacena los documentos en una estructura de datos denominada índice inver-tido [2] que hace un uso eficiente del espacio en disco al mismo tiempo que permite una rápida búsqueda de palabras claves. Lo que hace es utilizar tokens extraídos de los doc-umentos como claves de búsqueda en lugar de tratar a los docdoc-umentos como entidades centrales. Por lo tanto, en lugar de tratar de responder la pregunta¿Qué palabras contiene
este documento? esta estructura se ha optimizado para proporcionar respuestas rápidas a
preguntas como¿Qué documentos contienen la palabra X?.
Desafortunadamente, Lucene no tiene en cuenta las características de los documentos WSDL, en consecuencia, palabras reservadas tales comoservice,bindingoportintroducen ruido en los motores de búsqueda. Para evitar esto Lucene fue potenciado con las téc-nicas de pre-procesamiento descriptas en 2.3.1, logrando aumentar su eficiencia en la recuperación de servicios. En el resto de este trabajo se referenciará a esta versión como Lucene4WSDL.
2.4
Anti-patrones de descubrimiento
servicios candidatos dentro de un registro de Servicios Web. Luego, el segundo paso requiere entender cada servicio candidato para seleccionar aquel que mejor se ajusta a sus necesidades. Sin embargo, varios autores [15, 30, 7, 6, 10] han señalado que existen malas prácticas comunes en los documentos WSDL que complican el descubrimiento de los mismos, las cuales fueron analizadas sistemáticamente en [35]. Estas malas prácticas podrían tener un impacto negativo sobre los algoritmos de recuperación automáticos uti-lizados por los registros de Servicios Web y también podrían dificultar el entendimiento de los documentos WSDL. En las siguientes sub-secciones se detallan cada una de éstas malas prácticas o anti-patrones discutiendo cuáles son sus causas, el impacto que pueden tener sobre los documentos WSDL y las soluciones propuestas para erradicarlos.
2.4.1 Comentarios faltantes o inapropiados
Descripción: comúnmente, los documentos WSDL no están bien documentados o lo que es peor no están documentados. El hecho de que un documento contenga comen-tarios hace que la funcionalidad ofrecida por el servicio asociado sea más fácil de entender. Por otra parte, los registros sintácticos de servicios utilizan esa docu-mentación para apoyar al descubrimiento. Se dice que un documento WSDL está bien documentado si cada una de sus operaciones tiene un comentario conciso y explicativo, que describe la semántica de la funcionalidad ofrecida. Además, como WSDL permite a los proveedores comentar cada parte del documento por sepa-rado, se considera una buena práctica colocar cada etiqueta <documentation> en el ámbito más restrictivo posible. Por ejemplo, si un comentario se refiere a un men-saje particular, la etiqueta debería colocarse en ese menmen-saje y no en la operación que lo usa.
Solución: la solución a este anti-patrón es comentar cada parte del documento WSDL. Como resultado de la refactorización, el documento WSDL es más legible y aporta más cantidad de términos relevantes que son esenciales para los registros sintácticos.
Tipo: cuando en un documento WSDL no hay comentarios se dice que esevidente
que sufre de este anti-patrón. Sin embargo, los comentarios inapropiados no son inmediatamente aparentes ya que requieren de mayor análisis para de-terminar si el comentario se condice con la funcionalidad ofrecida por la op-eración que se está detallando.
2.4.2 Nombres ambiguos
<operation>. De la misma manera que en otros lenguajes, el nombre de un ele-mento no solo es usado como un identificador único sino también como un de-scriptor. Semánticamente, el nombre debe describir lo que el elemento representa. De esta manera, nombres como in0, arg1 o foo deben evitarse. Además, si den-tro de un documento WSDL hay más de un elemento para representar lo mismo, éstos deben nombrarse de la misma manera. Sintácticamente, el nombre de una operación debe respetar la forma: <verbo> + <sustantivo>, ya que una operación representa una acción. Por otro lado, el nombre de un mensaje debe ser un <sustan-tivo>, de lo contrario puede significar que transmite información de control. Este caso está relacionado con el anti-patrónInformación de error encubierta en mensaje
es-tándar.Otro punto a tener en cuenta es que el buen funcionamiento de los registros
sintácticos depende de que se respeten las convenciones de nombres, como la no-tación CamelCase o la adoptada por el lenguaje C, para dividir nombres largos. Por último, la longitud del nombre no debe ser ni demasiado larga ni demasiado corta, se recomienda una longitud de entre tres y quince caracteres [7].
Solución: la solución a este anti-patrón es reemplazar los nombres sin sentido por nom-bres que respeten las convenciones antes mencionadas. Además, estos nomnom-bres en los documentos WSDL refactorizados deben ser consistentes. Esto quiere decir que los nombres y los conceptos que éstos representan deben tener una correspondencia unívoca.
Tipo: la detección de este anti-patrón no es inmediatamente aparente dado que requiere de un análisis más exhaustivo de los nombres utilizados para determinar si éstos tienen sentido o no para aquello que están representando.
2.4.3 Operaciones poco cohesivas
consultas sobre un registro sintáctico utilizando términos relacionados con el do-minio de los servicios, éstos tendrán mayor probabilidad de ser descubiertos. Solución: la solución a este anti-patrón es quitar las operaciones no cohesivas de un
port-type e incluirlas en uno nuevo o en otro Servicio Web. La idea es mantener solo las operaciones relacionadas del port-type para incrementar su cohesión. Como resultado, los documentos WSDL refactorizados contienen más port-types pero son más cohesivos.
Tipo: la detección de este anti-patrón no es inmediatamente aparente dado que requiere analizar las diferentes operaciones de cada port-type para descubrir si las mismas pertenecen al mismo dominio.
2.4.4 Tipos de datos comodines
Descripción: esta mala práctica consiste en utilizar tipos de datos de propósito general para representar cualquier objeto del dominio del problema y se basa en la uti-lización de constructoresxsd:anyyxsd:anyAttribute. Los desarrolladores suelen uti-lizar este tipo de dato especial para intercambiar una secuencia compleja de casi cualquier estructura XML entre proveedores y consumidores. Si bien esto puede ser visto como una alternativa para construir operaciones extensibles, oscurece el do-minio y rango de definición de las operaciones que transmiten este tipo de datos en sus mensajes. Como consecuencia, estas operaciones son más difíciles de entender por los descubridores. Además, este tipo de dato no brinda términos descriptivos, dificultando el descubrimiento mediante enfoques sintácticos.
Solución: si el anti-patrón se debe a un mal diseño del modelo de datos, la solución sug-erida es sustituir todas las definiciones de tipos de datos comodines por tipos de datos más adecuados, es decir aquel que transmite únicamente la información que una determinada operación necesita como entrada o la que produce como salida. Si, en cambio, la presencia del anti-patrón se debe al intento de hacer interfaces ex-tensibles, la solución consiste en utilizar la estrategia de versiones que recomienda construir nuevos tipos de datos compatibles con versiones anteriores mediante el uso de mecanismos de extensión de XSD que permite a los desarrolladores definir un nuevo tipo de dato a partir de uno creado previamente. Esta estrategia fue prop-uesta en [30].
2.4.5 Información de error encubierta en mensaje estándar
Descripción: este anti-patrón se manifiesta cuando se utilizan mensajes de salida para informar del error ocurrido durante la ejecución de una operación. En consecuen-cia, un mensaje de salida es diseñado para intercambiar información de error cuando la operación falla o un valor cuando la ejecución finaliza satisfactoriamente. Este tipo de mensaje debe constar de tres partes: una parte informa si se produjo un error, otra parte transmite información del error, en caso de que ocurra, y la última parte transmite el resultado de la operación. Entonces, el mensaje de salida no solo transporta datos de la aplicación sino que le dice a quien lo recibe qué hacer. Este es un caso especial de acoplamiento de control, una situación que se debe evitar en el diseño estructurado.
Solución: la solución a este anti-patrón consiste en utilizar el soporte provisto por el lenguaje WSDL para el manejo de información de error. De esta forma, dicha infor-mación debe ser transmitida dentro de mensajes<fault>. La operación refactorizada tiene tres mensajes: de entrada, de salida y de error. De este modo, los mensajes de entrada y salida solo intercambian información de la aplicación entre el cliente y el servidor.
Tipo: para poder detectar este anti-patrón es necesario analizar la implementación del servicio y ver qué se devuelve como resultado.
2.4.6 Modelo de datos adjunto
Descripción: un modelo de datos se denomina adjunto cuando su definición se incluye dentro de un documento WSDL y puede ser utilizado solo por las operaciones de-scriptas en el mismo documento. Esto lleva a que un modelo de datos no se pueda reutilizar entre distintos documentos y que haya que definirlo cada vez, lo cual se considera una mala práctica. Por otro lado, un modelo de datos importado es aquel que se define en un archivo XSD separado y se referencia desde los archivos WSDL que lo requieran. Esta se considera una buena práctica para denominar y modelar tipos de datos. Esto permite también que se combinen modelos de datos según sea necesario mediante las etiquetas <include> e <import>.
Solución: utilizar buenas prácticas para nombrar y modelar los tipos de datos, definiendo los mismos en distintos documentos XSD y, a su vez, combinar esquemas separa-dos según sea necesario. Esto permite compartir y reutilizar los modelos de datos en lugar de volverlos a definir para cada nuevo servicio.
2.4.7 Modelo de datos redundante
Descripción: más de un tipo de dato que representan el mismo objeto del dominio del problema y que coexisten en el mismo documento WSDL indican síntomas de este anti-patrón. En general, un modelo de datos redundante se produce cuando al menos dos definiciones de tipos de datos tienen la misma información intercambi-able en un documento WSDL y es causado frecuentemente por malos diseños. Este problema está estrechamente relacionado con el anti-patrónModelo de datos adjunto. Solución: la refactorización que permite eliminar ocurrencias del anti-patrón consiste en separar los tipos de datos redundantes en un nuevo tipo de dato y reemplazar las referencias antiguas por las nuevas. En consecuencia, la versión refactorizada de la descripción del servicio está libre de código XSD redundante, por lo que resulta más conciso y fácil de entender para los consumidores.
Tipo: la detección de este anti-patrón es evidente ya que observando el documento WSDL se puede detectar si existe más de un tipo de dato para representar el mismo objeto del dominio del problema.
2.4.8 Port-types redundantes
Descripción: un port-type redundante es aquel que ofrece el mismo conjunto de opera-ciones que otro port-type definido en el mismo documento WSDL. Esto puede considerarse como un intento de influir en el ranking de Servicios Web retornados por un registro sintáctico ya que para los registros cuántas más veces aparezca un término en un documento WSDL más importante es ese término para ese docu-mento. Como resultado, ese Servicio Web tiene más probabilidades de aparecer en los primeros lugares de las búsquedas que otro que no repite información. En la práctica se han detectado casos donde los desarrolladores definen más de una vez port-types que ofrecen las mismas operaciones con los mismos mensajes pero cada uno correspondiente a un protocolo de transporte en particular.
Solución: la solución a este anti-patrón es combinar los port-types redundantes en uno solo que no incluya aspectos tecnológicos. En consecuencia, si el documento WSDL refactorizado está libre de código redundante, el registro sintáctico no extraerá tér-minos redundantes del mismo y su ubicación en el ranking será más real. Por otro lado, el documento refactorizado será más conciso que el original.
2.5
Conclusiones
En el presente capítulo se ampliaron las nociones básicas presentadas sobre SOC en el capítulo anterior, explicando la necesidad del surgimiento de los servicios para cumplir con una de las cuestiones más importantes para la industria del software: el reuso de fun-cionalidad. Siendo éstos la evolución a los sistemas de software basados en componentes para ambientes heterogéneos y distribuidos. Para implementar este paradigma surgen distintos protocolos Web, tales como HTTP, SOAP y XML, y de ahí que los servicios pasen a llamarse Servicios Web. Dentro del paradigma SOC existen tres roles principales: proveedor, consumidor y registro de servicios que utilizan el lenguaje de descripción de Servicios Web, denominado WSDL, para comunicarse y cuyas partes fueron detalladas en éste capítulo. Entonces, un documento WSDL representa el contrato entre un provee-dor y un consumiprovee-dor y por eso es importante que la definición del mismo sea clara, concisa y no sea ambigua. Esto muchas veces no ocurre generando un impacto nega-tivo sobre el descubrimiento automático de servicios y también sobre la capacidad de los consumidores para entender y reutilizar los servicios descriptos. Además, en este capí-tulo se explicaron los anti-patrones que afectan a los WSDL, conjunto de malas prácticas frecuentes empleadas por los desarrolladores en los documentos, y las soluciones que se pueden aplicar para erradicarlos.
Cap´ıtulo
3
Trabajos relacionados
Como se mencionó en el capítulo previo, SOC es un enfoque innovador en el diseño e im-plementación de sistemas distribuidos en ambientes heterogéneos, como lo es Internet. Un aspecto crucial en este tipo de sistemas es contar con un mecanismo de descubrim-iento eficiente para que los consumidores puedan encontrar y usar servicios. Dado que los contratos, materializados a través de los documentos WSDL, son los únicos artefac-tos de software disponibles públicamente que describen la funcionalidad ofrecida por los Servicios Web, el diseño de estos documentos es un factor crucial para el éxito de los servicios [33] debido a que son la única forma por la cual los consumidores pueden descubrirlos, entenderlos y reutilizarlos [10]. Los documentos WSDL sin demasiados co-mentarios de sus operaciones, nombres poco representativos o una mala definición de la interfaz pueden dificultar que los Servicios Web asociados sean descubiertos, y en partic-ular la precisión en el descubrimiento de servicios en registros sintácticos se ve perjudi-cada cuando se trata de documentos WSDL con descripciones pobres. La calidad de estos documentos puede ser estimada mediante el número de ocurrencias de anti-patrones, ya que estos tienen un impacto directo en la comprensibilidad y descubribilidad de los Ser-vicios Web [35, 28].
descubribilidad al aplicar esas refactorizaciones [28].
3.1
Una herramienta para generar descripciones de Servicios Web
evitando malas prácticas
En [13] se propone una herramienta que tiene como objetivo disminuir la introducción de anti-patrones en documentos WSDL y que actúa en dos etapas del desarrollo de Ser-vicios Web: el diseño de la implementación del servicio y la generación automática del documento WSDL a partir del código fuente del mismo. Cabe aclarar que la secuencia de estos dos pasos se corresponde con el enfoque code-first, que consiste en escribir el código fuente de un Servicio Web previo a la generación del documento asociado. En cada uno de estos pasos existen factores que pueden provocar anti-patrones en el doc-umento WSDL generado. En el primer paso, el desarrollador puede introducir malas prácticas en la interfaz del Servicio Web. Estas malas prácticas son luego trasladadas al documento WSDL en forma de anti-patrones durante el proceso de mapeo que efectúan las herramientas de generación. Un ejemplo de esta situación es la asignación de nombres poco representativos a los métodos de la interfaz, lo cual produce el anti-patrónNombres
ambiguosen la operación que describe ese método dentro del documento WSDL. En el
segundo paso, las herramientas utilizadas pueden tomar decisiones incorrectas durante la generación del documento que producen la presencia de anti-patrones en los mismos. Por ejemplo, una herramienta que no incluye dentro del documento WSDL los comen-tarios agregados por el desarrollador a los métodos de una interfaz, provoca la apari-ción del anti-patrónComentarios faltantes o inapropiados. La clasificación presentada en el Cuadro 3.1 le permitió al autor determinar en qué momentos debe actuar la herramienta para prevenir la introducción de cada anti-patrón. El mismo dividió la herramienta en dos partes: un detector de problemas de diseño sobre el código fuente de los servicios y un generador automático de documentos WSDL.
3.1.1 Detector de problemas de diseño sobre el código fuente de un Servicio
Web
El detector es la parte encargada de identificar y advertir al desarrollador sobre posibles problemas en la interfaz del Servicio Web que pueden producir anti-patrones. A con-tinuación se describen los métodos de detección que utiliza la herramienta y las refac-torizaciones que propone a los desarrolladores para cada uno de los anti-patrones, cuya definición fue explicada en la Sección 2.4.
Anti-patrón Origen Etapa
Comentarios faltantes o
inapropiados
(1)El desarrollador no introduce comentarios o son
inapropiados en los métodos de una interfaz Java. (2)La herramienta de generación no tiene en cuenta los comentarios presentes en el código fuente de la interfaz
Java al crear el documento WSDL.
(1)Diseño de interfaz y
(2)Generación automática de WSDL
Nombres ambiguos (1)El desarrollador asigna nombres ambiguos a métodos o parámetros de una interfaz Java. (2)La herramienta de generación asigna nombres ambiguos a los parámetros
por no poder recuperar sus nombres originales a partir
delbytecodede la interfaz Java.
(1)Diseño de interfaz y (2)Generación automática de WSDL
Port–types redundantes La herramienta genera más de un port–type para una misma interfaz Java, típicamente uno por cada
protocolo de transporte soportado.
Generación automática de WSDL
Operaciones poco
cohesivas
El desarrollador crea métodos no relacionados entre si
en una interfaz Java.
Diseño de interfaz
Modelo de datos adjunto
La herramienta incluye las definiciones de los tipos de datos dentro del documento WSDL generado.
Generación automática de WSDL
Modelo de datos redundante
La herramienta genera definiciones duplicadas para un mismo tipo de dato.
Generación automática de WSDL
Tipos de datos
comodines
(1)El desarrollador utiliza tipos de datos genéricos en
los parámetros o valores retornados por los métodos de una interfaz Java. (2)La herramienta asigna tipos de datos genéricos o tipos comodines a los mensajes de
entrada o salida de una operación.
(1)Diseño de interfaz y
(2)Generación automática de WSDL
Información de error
encubierta en mensaje estándar
El desarrollador crea métodos que incluyen información
de error en los datos retornados.
Diseño de interfaz
método que no ha sido comentado o cuyo comentario no es coherente con el nom-bre que se le ha asignado. Comprobar la primera condición es trivial, pero no ocurre lo mismo con la segunda. Para evaluar la coherencia entre los comentarios de un método y su nombre se utiliza una heurística propuesta en [27] que permite medir el grado de similitud semántica entre dos frases. Esta heurística puede tomar val-ores entre 0 y 1 e indica en qué medida dos frases se refieren a los mismos conceptos. La comprobación realizada para determinar la coherencia de los comentarios de un método consiste en calcular el grado de similitud semántica entre los comentarios y el nombre asignado al método. Si el grado de similitud es menor a un determinado valor se considera que el comentario no es apropiado para el método analizado, dado que se refieren a conceptos diferentes.
– Refactorización: para impedir la ocurrencia de este anti-patrón en el docu-mento WSDL, la herramienta sugiere al desarrollador agregar un comentario descriptivo a todos aquellos métodos donde falten los mismos y reemplazar los comentarios existentes por otros más adecuados en todos aquellos métodos cuyos comentarios hayan sido detectados como inapropiados.
• Nombres ambiguos: para detectar la presencia de este problema se realizan distin-tas comprobaciones. La primera es en base a su longitud dado que si un nombre tiene sólo un carácter o es muy largo es considerado ambiguo. La segunda com-probación que se realiza es determinar si alguna de las palabras que componen el nombre forman parte de una lista de palabras consideradas como no explicativas o demasiado generales [7] y son:param, arg, var, obj, object, foo, input, output, in, out, str, entre otras. Si un nombre de método o parámetro contiene al menos una de las pal-abras listadas previamente es considerado ambiguo. Por último, se comprueba que los nombres tengan una estructura gramatical adecuada. En el caso de nombres de métodos se verifica que la estructura sea verbo + sustantivo porque represen-tan acciones sobre entidades. En cambio, para los nombres de los parámetros se verifica que sea algún tipo de sustantivo, puesto que representan entidades. Para analizar la estructura gramatical de los nombres de métodos y parámetros se uti-liza unparserde gramática libre de contexto probabilístico [22]. Este tipo deparsers
(debe) al comienzo del mismo para darle forma de oración imperativa y mejorar el análisis gramatical que realiza elparser. Dado que los nombres de métodos suelen comenzar con un verbo en infinitivo, elparserpuede tener dificultades para recono-cer la estructura de la frase y detectar como sustantivos los verbos al comienzo de la misma. Nuevamente, agregar "it must" al comienzo de la oración aumenta las probabilidades de que el parser detecte la primera palabra del nombre del método como un verbo en lugar de sustantivo. Posteriormente, la heurística examina los nodos del árbol de parsing y comprueba que existan al menos un verbo y un sus-tantivo. Si esta condición no se cumple se considera que el nombre del método es ambiguo.
– Refactorización: para evitar que este anti-patrón se presente en el documento WSDL, la herramienta sugiere al desarrollador reemplazar los nombres de métodos y parámetros detectados como ambiguos por nombres más adecua-dos. En el caso de los métodos, se recomienda que los nombres contengan al menos un verbo y un sustantivo, que denoten la acción llevada a cabo. Para los nombres de los parámetros se sugiere utilizar sustantivos o frases sustantivas, que representen sujetos, objetos o conceptos.
encuentran presentes en dicho sub-grafo.
– Refactorización: para prevenir la ocurrencia de este anti-patrón en el docu-mento WSDL, la herramienta sugiere al desarrollador incluir los métodos con-siderados poco cohesivos por la heurística en interfaces que provean una fun-cionalidad con conceptos más relacionados.
• Tipos de datos comodines: para detectar la presencia de este problema se examinan los métodos de la interfaz del servicio en busca de tipos de parámetros o tipos de retorno genéricos [1]. Los tipos de datos considerados genéricos son:Object, Vector, List, Map, Collection, Enumeration, Vector<Object>, List<Object>, Map<Object,Object>, Collection<Object> y Enumeration<Object>.
– Refactorización: para evitar los problemas que puede ocasionar este anti-patrón en los documentos WSDL, la herramienta sugiere al desarrollador reemplazar los tipos de parámetros o de retorno que hayan sido detectados como genéri-cos por tipos de datos más específigenéri-cos, que representen adecuadamente los objetos o tipos de datos intercambiados por el servicio.
• Información de error encubierta en mensaje estándar: para detectar la presencia de este problema se analizan los tipos de retorno de los métodos definidos en la inter-faz que materializa el servicio para determinar si permiten transportar información de error. Esta comprobación sólo se realiza sobre los tipos de retorno no primitivos y consiste en examinar los nombres de sus atributos para determinar si alguno de ellos indica que puede transportar información de error. Si el tipo de retorno de un método contiene un atributo cuyo nombre pertenece a la siguiente lista: ping, error, errors, fault, faults, fail, fails, exception, exceptions, overflow, mistake, misplay, se considera que dicho tipo permite transportar información de error.
– Refactorización: para evitar este anti-patrón, la herramienta sugiere al desar-rollador convertir todos aquellos tipos de retorno que hayan sido detectados como transportadores de información de error encubierta en excepciones ar-rojadas por dichos métodos.
3.1.2 Generador automático de documentos WSDL
• Comentarios faltantes o inapropiados: puede ser introducido por una herramienta de generación cuando ésta no traslada los comentarios presentes en el código fuente Java al documento WSDL para agregar los comentarios a los elementos correspon-dientes. Si el método de una interfaz tiene un comentario en el código fuente que describe su funcionalidad y no es trasladado al elemento <operation> correspondi-ente en forma de documentación, el anti-patrón se hace prescorrespondi-ente en la descripción resultante, pese a que la herramienta cuenta con la información necesaria para evi-tarlo. Si la herramienta aprovecha dichos comentarios para comentar los distintos elementos del documento WSDL, este anti-patrón no será introducido.
• Nombres ambiguos: puede ser introducido cuando se utilizan herramientas de gen-eración que operan sobre el bytecode de la interfaz que define el Servicio Web, como por ejemplo Axis, dado que pueden asignar nombres ambiguos a los parámetros por no poder recuperar los nombres originales de los mismos. Para evitar este in-conveniente, la herramienta debe poder acceder al nombre original de los parámet-ros de un método. La herramienta propuesta no tiene este problema dado que opera a partir del código fuente de la interfaz, obtiene el nombre original de los parámetros y los asigna a las partes de mensajes correspondientes dentro del doc-umento WSDL. Sin embargo, dado que en Java no se identifica el retorno con un nombre, este anti-patrón no puede evitarse completamente solo considerando el código Java.
• Port types redundantes: suele ser introducido por las herramientas de generación cuando el servicio descripto en el documento WSDL soporta diferentes tecnologías de transporte. Este es un error de interpretación de la especificación WSDL que se produce cuando se generan dos port-types de un servicio para dosbindings difer-entes del mismo. Dado que los port-types no definen aspectos técnicos específicos, la estructura de los mismos no varía de acuerdo a la tecnología de transporte uti-lizada. Por lo tanto, alcanza con que los dos bindingshagan referencia al mismo port-type. Para evitar este anti-patrón, la herramienta genera un único port-type por cada servicio descripto en el documento WSDL, independientemente de la can-tidad debindingsque éste soporte.
difer-entes documentos WSDL, hay casos en que esto no se justifica por tratarse de Ser-vicios Web pequeños, que soportan un número reducido de operaciones.
• Modelo de datos redundantes: puede ser introducido por una herramienta de gen-eración durante el proceso de mapeo de los tipos de datos utilizados en la interfaz que define el servicio a definiciones XSD. Esto sucede cuando se generan dos o más definiciones XSD para representar un mismo tipo de dato, es decir cuando se de-finen dos clases Java para describir la misma entidad. Para evitar este anti-patrón, la herramienta controla que sólo se genere una única definición diferente por cada tipo de dato Java. Sin embargo, un mal diseño de los tipos de datos puede resultar en la generación de documentos WSDL con este anti-patrón.
• Tipos de datos comodines: como en el caso anterior, puede ser introducido durante el proceso de mapeo de los tipos de datos utilizados en la interfaz que define el servicio a definiciones XSD. Esto se produce cuando la herramienta no realiza un mapeo preciso de los tipos de datos a definiciones. En general, los tipos de datos primitivos de los lenguajes tienen un equivalente en XSD, pero los tipos de datos más complejos (arreglos, tipos genéricos de Java, etc.) no tienen un equivalente directo, por lo que deben adoptarse algunas convenciones ad-hoc para definirlos. Esto suele generar problemas de compatibilidad entre distintos frameworks que utilizan documentos WSDL. Esta problemática es la que motiva a varias herramien-tas de generación a definir estos tipos de datos complejos con constructoresxsd:any
oxsd:anyType, para evitar incompatibilidades. Para disminuir la introducción de
este anti-patrón la herramienta procura realizar un mapeo completo de los tipos de datos, definiendo la estructura de los mismos de la forma más concreta posible y evitando la utilización de estas construcciones.