cenidet...para contribuir a solucionar este problema, en esta tesis se propone el uso de diagramas...

cenidet

Centro Nacional de Investigación y Desarrollo Tecnológico

Departamento de Ciencias Computacionales

TESIS DE MAESTRÍA EN CIENCIAS

Composición de Servicios Web Utilizando Diagramas de Actividad

Presentada por:

Silvana De Gyvés Avila Ing. en Sistemas Computacionales por el Instituto Tecnológico de Veracruz

Como requisito para la obtención del grado de:

Maestría en Ciencias en Ciencias de la Computación

Directores de tesis: Dr. René Santaolaya Salgado

MC. Olivia Graciela Fragoso Diaz

Jurado:

Dr. Guillermo Rodríguez Ortiz – Presidente Dr. René Santaolaya Salgado – Secretario

MC. Mario Guillén Rodríguez – Vocal Dr. Moisés González García – Vocal Suplente

Cuernavaca, Morelos, México. 7 de Diciembre de 2007

Resumen Los servicios Web permiten un alto grado de integración de aplicaciones. Desde un nivel sencillo de integración denominado servicios básicos, en el que las aplicaciones interactúan con los servicios Web, invocando sus operaciones. Hasta un nivel complejo denominado servicios compuestos, donde se generan servicios a partir de otros servicios simples o compuestos.

En la actualidad, las empresas y organizaciones necesitan colaborar con otras entidades para satisfacer los requerimientos de sus procesos de negocio. Aquí es donde se da origen a las arquitecturas orientadas a servicios, ya que ofrecen una solución atractiva para el desarrollo de aplicaciones inter-empresariales. La compleja funcionalidad requerida en este tipo de aplicaciones, generalmente no se puede cubrir con un solo servicio Web, por lo que su desarrollo involucra del uso de servicios compuestos para complementar sus requerimientos.

El proceso que permite crear un servicio compuesto a partir de varios servicios existentes, se denomina composición de servicios. La composición requiere de la especificación del modelo de interacción entre las operaciones de los servicios involucrados, esto se puede realizar mediante la codificación manual de dicha especificación utilizando lenguajes como el BPEL4WS, WSFL y XLANG, lo que genera un incremento en el tiempo de desarrollo y demanda el aprendizaje de lenguajes de composición.

Para contribuir a solucionar este problema, en esta tesis se propone el uso de diagramas de actividad de UML para modelar estructuras que especifiquen la interacción entre las operaciones de los servicios Web y generar de forma automática el código de esta interacción en BPEL4WS.

En este documento, se presenta un estudio del estado del arte y la evolución del desarrollo de sistemas de software, así como un conjunto de trabajos de investigación relacionados y un análisis comparativo entre ellos y el prototipo propuesto en esta tesis.

También, se presentan el análisis realizado para integrar algunos sistemas que forman parte del modelo de solución; y el análisis del lenguaje BPEL4WS y los diagramas de actividad modelados en el cliente del sistema llamado WS-SIDDOO. Este último, dio como resultado las correspondencias entre los elementos gráficos de los diagramas de actividad y las actividades del BPEL; los atributos de los elementos a habilitar en este trabajo; y los escenarios para la generación de código. Asimismo, en este documento se describen a detalle el diseño e implementación de la integración de sistemas y el módulo de composición, así como el funcionamiento de cada uno de los elementos que los conforman.

Además, se presentan el plan experimental realizado para probar la generación de código BPEL a partir de los modelos, los casos de prueba y los resultados obtenidos, donde se demostró que el código generado a partir de un diagrama de actividad, permite especificar la interacción entre métodos de diferentes servicios Web utilizando estructuras secuenciales, iterativas y condicionales.

Y por último, se describen las conclusiones y aportaciones generadas con el desarrollo y evaluación de este trabajo de investigación, y la propuesta de una serie de trabajos que con su desarrollo complementarían el que se presenta en este documento.

Abstract Web services allow high level applications integration, from simple to complex integration level. A simple integration level uses web services known as basic services, where applications interact with them by invoking their methods. Complex integration uses composite web services built from other basic or composite services.

Now a days, companies and organizations need to collaborate with other entities to satisfy their business process requirements. It is here where service oriented architectures gain importance, as they offer an attractive solution for inter-enterprise applications development. Complex functionality required in such applications, usually can’t be filled with a single Web service, so, its development involves composite services to complement its requirements.

Web services composition is a process that builds composite Web services from a set of existing services. Composition requires an interaction model specification between the operations of the involved services; it can be made by manual coding the specification using languages such as BPEL4WS, WSFL and XLANG, which increases development time and demand learning composition languages.

In order to contribute to the solution of this problem, this thesis proposes the use of UML activity diagrams to model the structures that specify the interaction between the operations of the Web services, and the generation of the interaction code in BPEL4WS.

This document presents a review on Web services composition and software development evolution state-of-the-art. It also describes a set of related works and a comparative analysis between them and the prototype that generates web services interaction code, proposed in this thesis.

This document also presents the analysis realized to integrate some systems which are part of the solution model and the analysis of the BPEL4WS language and activity diagrams modeled with a system known as WS-SIDDOO. This analysis produced an equivalence relationship among the graphic elements of the activity diagrams and the activities of BPEL4WS, the attributes of the elements to enable this work, and the code generation scenarios. In addition, this document also describes in detail the design and implementation of the systems integration and of the composition module, as well as the functionality of each element that build it.

This document also describes the experimental plan carried out to test the module for BPEL4WS code generation from activity diagrams models, the test cases and their results which revealed that code generated from an activity diagram allows the specification of the interaction between different Web services methods by using sequential, conditional and iterative structures.

Finally, it describes conclusions and main contributions obtained with the development and evaluation of this research work, and the proposal for a set of works that may complement the work presented in this document.

i

Tabla de contenido Tabla de contenido i

Índice de figuras iii

Índice de tablas v

Glosario de términos y siglas vi

Introducción 1

Capítulo 1. Antecedentes 4 1.1. Antecedentes 4 1.2. Planteamiento de problema 6 1.3. Objetivo 6 1.4. Justificación y beneficios 6 1.5. Estado del arte 7 1.6. Trabajos relacionados 9

1.6.1. Composición de servicios basada en flujos de trabajo 9 1.6.2. Composición de servicios basada en planeación por Inteligencia Artificial 11 1.6.3. Análisis comparativo 12

1.7. Alcances y limitaciones 14

Capítulo 2. Marco teórico 16 2.1. Servicios Web 16 2.2. Estándares relacionados con los servicios Web 18 2.3. Composición de servicios Web 20 2.4. El lenguaje BPEL4WS 21

2.4.1. Estructura básica de un documento BPEL4WS 22 2.5. Diagramas de actividad 23

2.5.1. Formalización de los diagramas de actividad 25

Capítulo 3. Análisis del problema y solución propuesta 26 3.1. WS-SIDDOO 27 3.2. WS-Compositor 30 3.3. Sistema de búsqueda y selección de servicios Web 31 3.4. Correspondencias entre diagramas de actividad y el BPEL4WS 31 3.5. Elementos del BPEL4WS 32

3.5.1. Partner links y variables 32 3.5.2. Actividades básicas 33 3.5.3. Actividades estructuradas 35 3.5.4. Atributos seleccionados para la generación de código 36

3.6. Escenarios para la generación de código 37 3.6.1. Escenarios para la generación de código de estructuras secuenciales 37 3.6.2. Escenarios para la generación de código de estructuras condicionales 38 3.6.3. Escenarios para la generación de código de estructuras iterativas 41 3.6.4. Escenario general de fracaso para la generación de código 42

ii

3.7. Modelo de solución 43

Capítulo 4. Diseño e implementación del sistema 46 4.1. Diseño e implementación de la integración de sistemas 47

4.1.1. Casos de uso 47 4.1.2. Implementación de la integración de sistemas 48

4.2. Diseño e implementación del módulo de composición de servicios 50 4.2.1. Casos de uso del módulo de composición 52 4.2.2. Implementación del módulo de composición 53

4.3. Ventanas de configuración 57

Capítulo 5. Plan experimental 61 5.1. Hipótesis a probar 61 5.2. Convención de nombres 62 5.3. Documentación de prueba 62 5.4. Plan de pruebas 62 5.5. Especificación del diseño de pruebas 66

5.5.1. MCS-DP-01. Diseño de prueba para la generación de código de estructuras secuenciales 66 5.5.2. MCS-DP-02. Diseño de prueba para la generación de código de estructuras condicionales 67 5.5.3. MCS-DP-03. Diseño de prueba para la generación de código de estructuras iterativas 67 5.5.4. MCS-DP-04. Diseño de prueba para la ejecución de código en BPEL4WS 68

5.6. Especificación de casos de prueba 69 5.7. Resultados de la ejecución del plan experimental 72 5.8. Análisis de resultados 73

Capítulo 6. Conclusiones 75 6.1. Conclusiones 75 6.2. Aportaciones 77 6.3. Trabajo futuro 77

Anexo A. Ejemplo de código BPEL4WS 79

Anexo B. Escenarios para los casos de uso del sistema 81

Anexo C. Escenarios para los casos de uso del módulo de composición 86

Anexo D. Descripción de las clases del módulo de composición 91

Anexo E. Descripción de los casos de prueba 96

Referencias 132

iii

Índice de figuras Figura 1. Arquitectura orientada a servicios 17 Figura 2. Estructura básica del BPEL4WS 1.1 23 Figura 3. Ejemplo de un diagrama de actividad 24 Figura 4. Diagrama de clases del WS-SIDDOO 28 Figura 5. Diagrama de clases del cliente del WS-SIDDOO 29 Figura 6. Clases del módulo analizador 30 Figura 7. Sintaxis para la definición de un partner link 32 Figura 8. Sintaxis para la definición de una variable 33 Figura 9. Sintaxis para la actividad assign 33 Figura 10. Sintaxis para la actividad invoke 34 Figura 11. Sintaxis para la actividad receive 34 Figura 12. Sintaxis para la actividad reply 35 Figura 13. Sintaxis para la actividad sequence 36 Figura 14. Sintaxis para la actividad switch 36 Figura 15. Sintaxis para la actividad while 36 Figura 16. Escenario de éxito para la generación de código de estructuras secuenciales 37 Figura 17.Escenario de éxito para la generación de código de estructuras de selección

simple 38 Figura 18. Escenario de fracaso para la generación de código de estructuras de selección

simple 39 Figura 19. Escenario de éxito para la generación de código de estructuras de selección

doble 39 Figura 20. Escenario de éxito para la generación de código de estructuras de selección

en cascada 40 Figura 21. Escenario de éxito para la generación de código de estructuras de selección

múltiple 41 Figura 22. Escenario de éxito para la generación de código de estructuras iterativas

while 41 Figura 23. Escenario de éxito para la generación de código de estructuras iterativas

do_while 42 Figura 24. Escenario de fracaso para la generación de código 43 Figura 25. Modelo de solución propuesto 44 Figura 26. Casos de uso del sistema 47 Figura 27. Diagrama de componentes del sistema 48 Figura 28. Diagrama de secuencia general del sistema 50 Figura 29. Estructuras condicionales 51 Figura 30. Estructura condicional en cascada 51 Figura 31. Estructuras iterativas (while). a) simple. b) anidadas 52 Figura 32. Estructura iterativa (do_while) 52 Figura 33. Diagrama de casos de uso del módulo de composición 53 Figura 34. Arquitectura de clases del módulo de composición 54

iv

Figura 35. Escenario para generar código del encabezado, partnerLinks y las variables del proceso 55

Figura 36. Escenario de generación de código de estructuras secuenciales 56 Figura 37. Escenario de generación de código de estructuras condicionales 57 Figura 38. Ventana de configuración. a) Operación assign. b) Operación invoke 58 Figura 39. Ventana de creación de variables. a) Tipos WSDL. b) Tipos primitivos 59 Figura 40. Ventana para agregar un partner link 59 Figura 41. Ventana de asignación 59 Figura 42. Ventana de búsqueda de variables 60 Figura 43. Ventana BPEL 60 Figura 44. Convención de nombres 62 Figura 45. Elementos del BPEL y actividades básicas 80 Figura 46. Diagrama de actividad para el caso de prueba MCS-CP-01 97 Figura 47. Estructura del código esperado para el caso MCS-CP-01 98 Figura 48. Diagrama de actividad para el caso de prueba MCS-CP-02 99 Figura 49. Estructura del código esperado para el caso MCS-CP-02 100 Figura 50. Diagrama de actividad para el caso de prueba MCS-CP-03 101 Figura 51. Estructura del código esperado para el caso MCS-CP-03 101 Figura 52. Diagrama de actividad para el caso de prueba MCS-CP-04 102 Figura 53. Estructura del código esperado para el caso MCS-CP-04 103 Figura 54. Diagrama de actividad para el caso de prueba MCS-CP-05 104 Figura 55. Estructura del código esperado para el caso MCS-CP-05 105 Figura 56. Diagrama de actividad para el caso de prueba MCS-CP-06 106 Figura 57. Estructura del código esperado para el caso MCS-CP-06 107 Figura 58. Diagrama de actividad para el caso de prueba MCS-CP-07 108 Figura 59. Estructura del código esperado para el caso MCS-CP-07 109 Figura 60. Diagrama de actividad para el caso de prueba MCS-CP-08 110 Figura 61. Estructura del código esperado para el caso MCS-CP-08 111 Figura 62. Diagrama de actividad para el caso de prueba MCS-CP-09 112 Figura 63 Estructura del código esperado para el caso MCS-CP-09 114 Figura 64. Diagrama de actividad para el caso de prueba MCS-CP-10 115 Figura 65. Estructura del código esperado para el caso MCS-CP-10 116 Figura 66. Diagrama de actividad para el caso de prueba MCS-CP-11 117 Figura 67. Estructura del código esperado para el caso MCS-CP-11 119 Figura 68. Diagrama de actividad para el caso de prueba MCS-CP-12 120 Figura 69. Estructura del código esperado para el caso MCS-CP-12 122 Figura 70. Diagrama de actividad para el caso de prueba MCS-CP-13 123 Figura 71. Estructura del código esperado para el caso MCS-CP-13 124 Figura 72. Diagrama de actividad para el caso de prueba MCS-CP-14 125 Figura 73. Estructura del código esperado para el caso MCS-CP-14 127 Figura 74. Diagrama de actividad para el caso de prueba MCS-CP-15 128 Figura 75. Estructura del código esperado para el caso MCS-CP-15 131

v

Índice de tablas Tabla 1. Comparación entre herramientas y modelos que dan soporte a la composición

de servicios 13 Tabla 2. Servicios Web básicos a usar en la composición 63 Tabla 3. Resultados de la ejecución del plan experimental 72

vi

Glosario de términos y siglas API (Application Programming Interface) La Interfaz de Programación de

Aplicaciones es un conjunto de especificaciones de comunicación entre componentes de software.

Axis Es un servidor de aplicaciones formado por un conjunto de librerías Java

que permite construir procesadores SOAP para ser utilizados en la implementación de clientes de Servicios Web y el desarrollo de servicios.

BPEL4WS (Business Process Execution Language for Web Services) El Lenguaje

de Ejecución de Procesos de Negocio para Servicios Web define una notación para especificar el comportamiento de los procesos de negocio basados en servicios Web. También se conoce como BPEL.

DAML (DARPA Agent Markup Language) es un lenguaje para modelar ontologías creado con una extensión de RDF. En las nuevas versiones se conoce como OWL-S.

JDOM Es un API para leer, crear y manipular documentos XML de una manera

sencilla y muy intuitiva para cualquier programador en Java. OMG (Object Management Group) El Grupo de Gestión de Objetos es un

consorcio dedicado al cuidado y el establecimiento de diversos estándares de tecnologías orientadas a objetos, tales como UML, XMI, CORBA.

OWL-S (Ontology Web Language for Services) El Lenguaje de Web para

Ontologías de Servicios es un lenguaje formado por un conjunto de etiquetas o marcas que se utiliza para describir las propiedades y capacidades de los servicios Web en una forma no ambigua, interpretable por una computadora.

P2P (Peer to Peer) se refiere a una red que no tiene clientes y servidores fijos,

sino una serie de nodos que se comportan simultáneamente como clientes y como servidores de los demás nodos de la red.

RDF (Resource Description Framework) Marco de descripción de recursos. SOAP (Simple Object Access Protocol) El Protocolo Simple de Acceso a Datos

es un protocolo basado en XML que se utiliza para la mensajería de los servicios Web.

vii

Stubs Objeto que forma parte del cliente (entidad que usa el servicio) y se

encarga de establecer la conexión con los servicios Web. Systinet WASP El servidor WASP (Web Applications and Services Platform) de

Systinet para Java es una plataforma robusta para servicios Web. Puede ejecutarse como un servicio stand-alone, pero generalmente trabaja sobre un servidor de aplicaciones J2EE.

UDDI (Universal Description, Discovery and Integration) Es una

especificación que se utiliza para definir qué información que proporcionan las empresas referentes a sus servicios debe almacenarse, cómo almacenarla y cómo acceder posteriormente a dicha información.

UML (Unified Model Language) El Lenguaje Unificado de Modelado es un

lenguaje gráfico para visualizar, especificar, construir y documentar un sistema de software. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocios y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes de software reutilizables.

UMT (UML Model Transformation Tool) Es una herramienta para la

transformación de modelos y la generación de código basada en especificaciones UML y XMI.

URL (Uniform Resource Locutor ) El Localizador Uniforme de Recurso es

una secuencia de caracteres, de acuerdo a un formato estándar, que se usa para nombrar recursos, como documentos e imágenes en Internet, por su localización.

WS-Addressing Proporciona un mecanismo de transporte neutral para direccionar

servicios Web y mensajes. WorkSCo Es un marco orientado a objetos escrito en Java que proporciona a los

desarrolladores de software conceptos sobre flujos de trabajo que pueden ser utilizados dentro de su código.

WSDL (Web Service Description Language) El Lenguaje de Descripción de

Servicios Web es una tecnología utilizada para definir documentos basados en XML, donde se incluye toda la información de los servicios, ya sean las operaciones específicas que ofrece, los parámetros de dichas operaciones, etc.

WSFL (Web Services Flow Language) El Lenguaje de Flujo para Servicios

viii

Web es un lenguaje basado en XML propuesto por IBM para describir la composición de servicios Web como parte de la definición de un proceso de negocio.

WS-SIDDOO Servicio Web que contiene el analizador de diagramas de actividad del

Sistema Visual para el Diseño Detallado de Métodos de Clases (SIDDOO).

XLANG Es una extensión del WSDL desarrollada por Microsoft que describe

el comportamiento de los servicios Web como parte de un proceso de negocio.

XML (eXtensible Markup Language) El Lenguaje de Marcado eXtensible es un metalenguaje de etiquetas desarrollado por el World Wide Web Consortium (W3C). Su objetivo principal es conseguir una página Web más semántica, separando la estructura del contenido y permitiendo el desarrollo de vocabularios modulares.

XML Schema Es una alternativa a los DTDs basada en XML que se utiliza para

describir la estructura de un documento XML. También se conoce como XSD.

XPath Es un lenguaje que se utiliza para localizar información dentro de un

documento XML. Se utiliza para navegar a través de los elementos y atributos del documento.

XSLT (XSL Transformations) Estándar de la W3C que presenta una forma de

transformar documentos XML en otros e incluso a formatos que no son XML.

1

Introducción Los servicios Web son componentes de software auto-contenidos y modulares que permiten el intercambio de datos entre aplicaciones vía Internet, independientemente de cómo fueron creadas, cuál es el sistema operativo o la plataforma en que se ejecutan y cuáles son los dispositivos utilizados para obtener acceso a ellas.

Utilizando servicios Web, una organización puede intercambiar información con diferentes entidades, complementar sus transacciones y conseguir una completa integración de sus procesos de negocio, razón por la cual se han convertido en una tecnología clave para el diseño, construcción y ejecución de aplicaciones de negocios inter-empresariales.

Generalmente, un solo servicio Web no satisface la funcionalidad requerida por este tipo de aplicaciones y es necesario combinar servicios existentes para que ésta sea cubierta. A esta acción se le denomina composición de servicios.

Introducción

2

La composición permite modelar el proceso y establecer mecanismos y restricciones para que dos o más servicios colaboren entre sí y se cubran requerimientos específicos que van más allá del alcance de sus capacidades individuales.

Sin embargo, la composición necesita de la especificación de interacción entre las operaciones de los diferentes servicios Web involucrados en el proceso. Esta situación ha generado un gran número de trabajos de investigación, tanto en la industria como en instituciones académicas, los cuales proponen distintos métodos para llevar a cabo la composición de forma automática y semi-automática. La mayoría de estos se encuentran dentro de dos categorías: basados en un flujo de trabajo y basados en planeación por Inteligencia Artificial.

En esta tesis se analiza el problema de la composición de servicios y se propone el uso de diagramas de actividad de UML para el modelado de procesos que contengan estructuras secuenciales, condicionales e iterativas, y la generación automática de código en el lenguaje BPEL4WS, a partir del modelo, para especificar la interacción entre los métodos de los servicios componente.

Organización del documento La organización del presente documento de tesis es la siguiente:

En el capítulo 1, la sección 1.1 muestra una breve descripción de los trabajos que

forman los antecedentes de esta tesis; la sección 1.2 presenta el planteamiento del problema; la sección 1.3 describe el objetivo perseguido en esta investigación; la sección 1.4 explica los puntos que justifican este trabajo y los beneficios que con él se obtienen; la sección 1.5 describe el estado del arte y la evolución del desarrollo de sistemas de software; la sección 1.6 presenta un conjunto de trabajos, que con distintos enfoques abordan el problema tratado en esta tesis y un análisis comparativo entre ellos; y la sección 1.7 presenta los alcances y limitaciones considerados en el desarrollo de esta investigación.

En el capítulo 2, la sección 2.1 presenta la definición de servicios Web y describe brevemente la arquitectura orientada a servicios; la sección 2.2 describe los estándares que dan soporte a la infraestructura de los servicios Web; la sección 2.3 presenta la definición de composición de servicios; la sección 2.4 define y describe el lenguaje BPEL4WS; y la sección 2.5 define y describe los diagramas de actividad de UML.

En el capítulo 3, la sección 3.1 describe el funcionamiento y la estructura del WS-SIDDOO y su cliente; la sección 3.2 describe el funcionamiento del WS-Compositor y la estructura del módulo de composición de este prototipo; la sección 3.3 describe el sistema de búsqueda y selección de servicios Web; la sección 3.4 explica las correspondencias entre diagramas de actividad y el BPEL4WS; la sección 3.5 presenta las características de los elementos del BPEL implementados en este trabajo; la sección 3.6 describe los diferentes escenarios para la generación de código, identificados a partir de diagramas de actividad modelados en el cliente del WS-SIDDOO; y la sección 3.7, presenta el modelo de solución propuesto.

Introducción

3

En el capítulo 4, la sección 4.1 presenta los detalles de diseño e implementación de la integración entre los sistemas presentados en el capítulo 1 y el módulo de composición; la sección 4.2 describe las características que deberán tener los diagramas modelados en el cliente del WS-SIDDOO y el diseño e implementación del módulo de composición de servicios; y la sección 4.3 muestra las diferentes ventanas de configuración que dan soporte al módulo de composición y describe su funcionamiento.

En el capítulo 5, la sección 5.1 presenta la hipótesis a probar con la ejecución del plan experimental; la sección 5.2 muestra la convención de nombres utilizada en la evaluación del módulo de composición; la sección 5.3 presenta la documentación de prueba; la sección 5.4 detalla los diferentes puntos que integran el plan de pruebas del módulo de composición; la sección 5.5 describe la especificación del diseño de pruebas para la generación y ejecución de código en BPEL4WS; la sección 5.6 presenta el propósito de cada uno de los casos de prueba; la sección 5.7 muestra los resultados de la ejecución del plan experimental; y la sección 5.8 presenta el análisis que se realizó en base a los resultados obtenidos.

En el capítulo 6, la sección 6.1 presenta las conclusiones generadas con el desarrollo y evaluación de este trabajo; la sección 6.2 muestra las aportaciones logradas durante esta investigación; y la sección 6.3 describe los trabajos futuros.

4

Capítulo 1. Antecedentes 1.1. Antecedentes

La complejidad de los actuales sistemas de cómputo y la necesidad de ampliar su cobertura para dar servicio a usuarios ubicados en distintas localizaciones geográficas, lleva a los desarrolladores a reutilizar el software y compartirlo en ambientes distribuidos, pasando en pocos años de una mentalidad centralizada, donde prevalecía la confidencialidad y sistemas de información basados en Intranet, a una mentalidad totalmente opuesta, descentralizada y basada en Internet [IRIB01], dando origen a tecnologías como CORBA (Common Object Request Broker Architecture), RMI (Remote Method Invocation) y los servicios Web.

Los servicios Web son componentes de software modulares, auto-contenidos y auto-descriptivos que pueden ser publicados, localizados e invocados a través de la Web [SAMP05]. Permiten a los desarrolladores utilizar en la implementación de soluciones de software,

Capítulo 1. Antecedentes

5

componentes creados por otros desarrolladores, sin importar la plataforma, lenguaje o lugar en el que fueron desarrollados.

La tesis que se presenta en este documento forma parte de una serie de trabajos de investigación desarrollados en la línea de servicios Web por estudiantes del grupo de ingeniería de software del CENIDET. A continuación se describen tres tesis de maestría que en conjunto forman el antecedente de este trabajo de tesis. Generación de servicios Web a partir de software legado [VAZQ04]

En este trabajo se presentó una metodología para reestructurar herramientas de desarrollo hacia marcos orientados a objetos y posteriormente convertir esos marcos en servicios, solventando de esta manera los problemas que evitan que una herramienta de desarrollo de software pueda ser utilizada como un servicio Web y facilitar el proceso del desarrollo de software.

En otras palabras, esta metodología estuvo enfocada en convertir software legado a servicios Web, teniendo como principal objetivo promover la reutilización de soluciones de software que ya hubieran sido probadas.

Para probar la metodología de conversión a servicios, desarrollada, se tomó como caso de prueba una herramienta para modelado de diagramas de actividad de UML (Unified Modeling Language). El resultado de aplicar la metodología de reestructura a la herramienta SIDDOO [ROMA03] fue el servicio Web “WS-SIDDOO” y un cliente. El cliente corresponde al ambiente gráfico de la herramienta, en el cual el usuario puede llevar a cabo el modelado de los diagramas, mientras que el servicio Web es el analizador y se encarga de validar la construcción de los mismos. Composición de servicios Web [GUZM06]

El objetivo general de esta tesis fue el desarrollo de una secuencia de pasos soportados por una herramienta, que permitieran al desarrollador de software crear aplicaciones informáticas específicas, mediante la composición de servicios Web, reduciendo los tiempo, costos y complejidad de producción.

El problema que esta tesis resuelve se presenta cuando un usuario necesita que varios servicios Web colaboren entre sí para resolver un requerimiento de su aplicación. Por lo que fue necesario construir una herramienta (WS-Compositor) que permitiera el intercambio de información entre ellos, generara un cliente para la composición de varios servicios (integración de aplicaciones) y los stubs de conexión. Sistema de búsqueda y selección de servicios Web [SOLI06]

El objetivo de este trabajo fue diseñar, implementar y evaluar un modelo de búsqueda y selección de servicios Web que extiende la funcionalidad de los registros actuales a través de una biblioteca basada en casos y un módulo razonador que manipula dicha biblioteca, proporcionando un mecanismo para la clasificación y selección de servicios en base a su funcionalidad, permitiendo realizar la búsqueda de las descripciones de los servicios seleccionados de forma no secuencial dentro de los mismos registros.

El modelo permite al usuario expresar la funcionalidad requerida de un servicio y proporciona como resultado, de la búsqueda, la descripción o descripciones de servicios que proveen la funcionalidad que más se aproxima a la requerida.


6

Este trabajo utiliza métricas como la precisión, índice de recuperación y nivel de coincidencia en las búsquedas realizadas usando el modelo propuesto, con la finalidad de comparar su desempeño con el modelo de búsqueda que actualmente utilizan los registros públicos de servicios Web. 1.2. Planteamiento de problema El desarrollo de aplicaciones complejas o de gran escala, tales como el comercio electrónico (Business to Business, Business to Consumer), Peer to Peer (P2P) y todas aquellas que se utilizan para construir otras aplicaciones independientes del lenguaje y plataforma de implementación, pueden complementar sus requerimientos mediante el uso de servicios Web.

Las operaciones proporcionadas por un servicio Web se describen utilizando WSDL. Sin embargo, un documento WSDL no está habilitado para especificar el orden de ejecución de estas operaciones, o su interacción con operaciones de otros servicios para implementar un proceso de negocios, por lo que se utilizan lenguajes como el BPEL4WS para realizar esta especificación.

La composición de servicios Web necesita de la especificación de interacción entre las operaciones de los diferentes servicios involucrados en el proceso. Esta especificación se puede hacer de forma manual, escribiendo el código que implementa dicha interacción. El problema que se tiene, es que cuando una aplicación involucra un proceso de composición, la codificación manual de dicha especificación genera un incremento en el tiempo de desarrollo y demanda el aprendizaje de lenguajes de composición tales como el BPEL4WS.

1.3. Objetivo Evitar que el desarrollador de aplicaciones escriba el código de interacción entre las operaciones de los servicios Web involucrados en un proceso de composición, mediante la generación automática de código de composición, a partir de diagramas de actividad de UML modelados en el cliente del WS-SIDDOO. 1.4. Justificación y beneficios Justificación

La composición de servicios Web es de utilidad para todas aquellas aplicaciones en las que un servicio no es suficiente para complementar sus requerimientos. Un error en la especificación de la interacción entre las operaciones de los servicios resultaría crítico debido a las pérdidas que pudieran generarse (información, económicas). Al automatizar la generación del código de dicha interacción, se trata de minimizar la inserción de errores de codificación por parte del desarrollador de aplicaciones y se reduce el tiempo de desarrollo.


7

Por lo tanto, es necesario evitar que se codifique de forma manual la interacción entre servicios Web en la implementación de soluciones de software que involucren procesos de composición.

Para componer servicios, se requieren las URLs de sus descripciones, almacenadas en repositorios UDDI; las características de las operaciones que realizan, descritas en los documentos WSDLs de los servicios; y la definición de mecanismos, para que dichas operaciones colaboren entre sí.

El sistema de búsqueda y selección de servicios Web [SOLI06] localiza el ó los servicios que más se ajustan a un problema, dentro de un repositorio UDDI, pero no realiza la integración o composición de estos.

La herramienta WS-Compositor [GUZM06] hace solamente la integración secuencial de servicios Web, dejando fuera situaciones donde aparecen estructuras condicionales e iterativas. Además, tanto los servicios como sus métodos son seleccionados a partir de una caja de diálogo.

Las dos tesis mencionadas anteriormente se han desarrollado de manera independiente, razón por la cuál se quiere utilizar el cliente del WS-SIDDOO (que resulta de aplicar la metodología de [VAZQ04] al sistema SIDDOO) para relacionarlas, modelar la lógica de la composición y completar el proceso, permitiendo que el servicio compuesto soporte interacciones secuenciales, iterativas y condicionales entre las operaciones de los servicios que lo componen.

Beneficios

Este trabajo proporciona un ambiente de modelado para la composición de servicios Web que integra el cliente del WS-SIDDOO, el sistema de búsqueda y selección de servicios Web [SOLI06] y el WS-Compositor [GUZM06]. Con esto, se tiene completo el proceso que permite llevar a cabo de forma semi-automática la búsqueda, selección y composición de servicios Web.

Los desarrolladores se verán beneficiados ya que podrán efectuar la composición de varios servicios Web sin tener que escribir el código que especifique la interacción entre sus operaciones, reduciendo el tiempo y esfuerzo requeridos para el desarrollo de nuevas aplicaciones, así como el número de errores que se pueden generar durante la codificación de la especificación del nuevo servicio. 1.5. Estado del arte “A mediados de los años 90´s apareció el primer modelo de cómputo distribuido conocido como DCE (Distributed Computation Environment). Este modelo establecía las pautas y normas que se debían seguir para el desarrollo de sistemas distribuidos. Esto dio paso a la aparición de conceptos como sistemas legados, wrappers y glue. Pero el concepto más importante que cambió y sigue cambiando los procesos de ingeniería, es el concepto de componente.

A partir de la aparición de los componentes empiezan a diferenciarse dos estilos de desarrollo de software: basado en el reuso y para el reuso.


8

El uso de componentes realmente comienza a tomar presencia con la aparición de los nuevos modelos de cómputo distribuido como CORBA (Common Object Request Broker Architecture), DCOM (Distributed Component Object Model) y EJB (Enterprise Java Beans), desarrollados por la OMG (Object Management Organization), Microsoft y Sun Microsystems, respectivamente” [IRIB01].

Estos modelos definen la forma de sus interfaces y mecanismos para interconectarlos entre sí. Basadas en los modelos de componentes DCOM, EJB y CORBA, se desarrollaron las plataformas ActiveX/OLE, Enterprise Beans y Orbix [FUEN01].

“Desafortunadamente, estas plataformas no son compatibles entre sí, por lo que sus fabricantes se vieron en la necesidad de definir e implementar nuevos servicios y funcionalidades que extienden los modelos básicos, como los servicios de CORBA 3.0, las extensiones Glasgow, Enterprise o Edinburgh de JavaBeans, o los servicios de la arquitectura de componentes MDCA (Microsoft Data Access Components) definida por Microsoft” [TROY99].

Dentro de las tecnologías que en la actualidad soportan el intercambio de información inter-organizacional de una manera versátil y flexible, a la vez robusta y segura, hay que destacar algunas como son RMI (Remote Method Invocation), CORBA y los servicios Web.

RMI es un mecanismo ofrecido por Java para invocar métodos remotamente. “Depende totalmente del núcleo de la serialización de objetos de Java, así como de la implementación tanto de la portabilidad como de los mecanismos de carga y descarga de objetos en otros sistemas.

Por su parte, CORBA es una tecnología de integración, no de programación. Se diseñó específicamente para llenar los huecos entre los distintos lenguajes de programación [HERR98]”.

CORBA y RMI presentan el inconveniente de que para establecer la comunicación utilizan puertos distintos al 80. Casi todos los mecanismos de seguridad aplicados en las empresas para protegerse de ataques (firewall) sólo dejan pasar conexiones sobre dicho puerto. Si una empresa desea implantar soluciones con las tecnologías CORBA o RMI, tiene que adaptar sus sistemas de seguridad al nuevo puerto de comunicación. Esto encarece la solución, aparte de hacerla más compleja [GARC05].

Esto nos lleva a la solución proporcionada por los servicios Web. Esta tecnología utiliza un mecanismo de comunicación que trabaja con el puerto 80, ya que va montado sobre el protocolo HTTP.

Los servicios Web son independientes de la plataforma donde se despliegan, de esta forma permiten la comunicación entre plataformas heterogéneas (como pueden ser J2EE y .NET). Esto es posible gracias a que todos los componentes y estándares que forman la Arquitectura Orientada a Servicios (SOA) se basan en XML.

“Actualmente el campo en el que más se aplican los servicios Web es el comercio electrónico, en el cual muchas empresas necesitan determinados productos o materia prima que consiguen a través de su relación con otras empresas que les proveen de dichos productos. Estas relaciones de compra-venta de productos a proveedores se realizan a través de servicios Web y de estrategias que controlan todo el proceso de compra-venta, de forma que se optimiza mucho el tiempo de todo el proceso de negocio.

Los servicios Web permiten un alto grado de integración de aplicaciones. Esta integración puede tener varios niveles, desde un nivel sencillo de integración denominado


9

servicios básicos o e-servicios, en el que las aplicaciones se integran con servicios Web. Hasta un nivel complejo de integración, denominado servicios compuestos en el que la integración se produce en servicios compuestos de varios servicios simples” [GARC05].

1.6. Trabajos relacionados Construir un servicio compuesto de manera automática o semi-automática es una situación que ha generado un gran número de trabajos de investigación, tanto en la industria como en instituciones académicas. Estos trabajos han dado como resultado distintos métodos propuestos para la composición de servicios. La mayoría de ellos se encuentran entre las siguientes categorías: basados en un flujo de trabajo (composición vía procesos de negocio) y basados en planeación por Inteligencia Artificial. 1.6.1. Composición de servicios basada en flujos de trabajo Un servicio Web compuesto es similar a un flujo de trabajo, ya que su definición incluye un conjunto de servicios atómicos, el control y el flujo de datos entre ellos. En la definición de un flujo de trabajo se especifican el flujo y los elementos de trabajo [CASA01].

La flexibilidad de los flujos de trabajo, adaptación automática de procesos e integración inter-empresarial, proporcionan los medios para la composición automática de servicios Web [RAOJ04a].

La forma más común de especificar flujos de trabajo o proceso es utilizando un modelo gráfico, como puede ser un diagrama de flujo, diagrama de estado o diagrama de actividad.

A continuación se describen algunas herramientas y modelos para la composición de servicios que utilizan métodos basados en flujos de trabajo.

Web Service Composition in UML [SLOG04]

Este trabajo propone un método que utiliza diagramas de actividad de UML para diseñar la composición de servicios Web y MDA (Model Driven Architecture) para generar especificaciones ejecutables en diferentes lenguajes de composición de servicios.

Por lo general un servicio Web se encuentra formado por varias operaciones. En este trabajo, un servicio corresponde a una clase de UML y una actividad a la invocación de una operación del servicio. Un servicio compuesto tiene una o más operaciones que invocan a otros servicios Web (simples).

Este método utiliza el estándar UML construido con un conjunto mínimo de extensiones para servicios Web y reglas de transformación que pueden ser usadas para producir modelos de composición de servicios. Estas reglas se implementaron como XSLT sobre la herramienta UMT [UMLM04] para transformar documentos WSDL en diagramas de clases y soportar la generación de documentos BPEL4WS y WorkSCo a partir de diagramas de actividad.


10

Adaptive and Dynamic Service Composition in e-Flow [CASA00] EFlow es un sistema desarrollado en Java por Hewlett Packard que permite la

definición de servicios compuestos a partir de servicios simples. Soporta la especificación, publicación y manejo de servicios compuestos y la especificación de procesos adaptativos y dinámicos que pueden configurarse a sí mismos en tiempo de ejecución de acuerdo a las necesidades de cada cliente y al tipo de servicios disponibles en Internet.

En eFlow un servicio compuesto se describe como un proceso que está compuesto de otros servicios, simples o compuestos. Visualmente, un servicio compuesto se modela como un proceso de negocios, utilizando un diagrama de flujo que define el orden de ejecución e intercambio de datos entre los nodos del proceso. El diagrama se crea de forma manual, pero se puede actualizar dinámicamente.

EFlow proporciona características que soportan el manejo y especificación de procesos de servicios, incluyendo un lenguaje simple para la composición de servicios, manejo de excepciones y eventos, transacciones a nivel de servicio, manejo de seguridad y herramientas de monitoreo. Zenflow: A Visual Web Service Composition Tool for BPEL4WS [MART05]

Zenflow es una herramienta visual para la composición y ejecución de servicios Web escritos en BPEL4WS. Contiene muchas características visuales que facilitan la definición de procesos de negocios y liberan al diseñador de trabajar directamente con código XML.

En Zenflow un servicio compuesto se modela con un diagrama de flujo que muestra un proceso de BPEL como un conjunto de elementos visuales que representan los datos y el control del flujo. Al cortar o pegar elementos al diagrama, se verifica la sintaxis para evitar errores sintácticos.

Este trabajo está diseñado para habilitar la composición de servicios de abajo hacia arriba (bottom-up) y de arriba hacia abajo (top-down). Cuenta con un buscador visual para UDDI, por medio del cual se puede conectar con cualquier repositorio UDDI a través de su interfaz de servicios Web. Así como con un compilador de WSDL, uno de BPEL y sus respectivos generadores de código para dar un soporte completo al proceso. Triana: A Graphical Web Service Composition and Execution Toolkit [MAJI04]

El marco Triana PSE (Problem Solving Enviroment) es un ambiente gráfico interactivo desarrollado en Java que permite la creación de programas completos sin llevar a cabo ningún tipo de programación. Al extender sus componentes, Triana puede facilitar el descubrimiento, composición e invocación de servicios Web.

Los servicios en Triana se descubren por medio de consultas a un servidor UDDI, la búsqueda se realiza en base a parámetros especificados por el usuario. Los servicios compuestos se modelan como un flujo de trabajo, arrastrando los elementos deseados de la caja de herramientas hacia el canvas de trabajo y posteriormente relacionándolos con un cable de conexión. El diagrama del servicio puede ser ejecutado o guardado en formato BPEL4WS.

Para publicar los servicios Web compuestos se utiliza un auxiliar paso a paso. Éste carga el diagrama del servicio, genera el documento WSDL en base a los WSDLs de los servicios componente y publica los detalles del servicio en el servidor UDDI.


11

1.6.2. Composición de servicios basada en planeación por Inteligencia Artificial En la mayoría de los métodos relacionados con planeación por Inteligencia Artificial (IA) se asume que un servicio Web es una acción que altera el estado del mundo como resultado de su ejecución [MATS05], la cual puede especificarse por medio de sus precondiciones y poscondiciones en el contexto de planeación.

Un servicio Web es un componente de software que toma una entrada de datos y produce una salida de datos, donde las precondiciones y poscondiciones se encuentran en la entrada y salida de parámetros del servicio respectivamente.

En los métodos basados en planeación por IA, el usuario puede especificar las entradas y salidas requeridas del servicio compuesto, entonces el servicio (como una composición de servicios disponibles) se genera automáticamente por planeadores de IA sin conocer un flujo de trabajo predefinido [MATS05]. A continuación se describen algunas herramientas y modelos para la composición de servicios que utilizan métodos basados en planeación por IA. SWORD: A Developer Toolkit for Web Service Composition [PONN02]

SWORD es un conjunto de herramientas que permiten la composición de un subconjunto de servicios Web, entre los que se encuentran los servicios que proporcionan información, correo electrónico y servicios de conversión de imagen. No trabaja con estándares como WSDL y OWL-S, en su lugar utiliza modelos Entidad-Relación (ER) para especificar las entradas y salidas de los servicios.

En SWORD un servicio se representa por una regla que expresa ciertas entradas (precondiciones) a partir de las cuales el servicio es capaz de producir salidas específicas (poscondiciones).

Para crear un servicio compuesto, el solicitante del servicio sólo necesita especificar los estados inicial y final del servicio compuesto, y un sistema experto basado en reglas determinará automáticamente la manera en que se puede generar el servicio compuesto.

La implementación de un prototipo demuestra que SWORD puede trabajar con servicios Web sin que su desarrollo se encuentre basado en estándares como SOAP, WSDL, UDDI, RDF o DAML. Definition and Execution of Composite Web Services: The SELF-SERV Project [BENA02]

El proyecto SELF-SERV tiene como objetivo proporcionar una herramienta e infraestructura de software intermedio para la definición y ejecución de servicios Web compuestos. Se ha implementado un sistema prototipo en el cuál los servicios son compuestos declarativamente y el servicio resultante puede ser orquestado de manera centralizada o P2P (Peer to Peer) dentro de un ambiente dinámico.

En SELF-SERV, el modelado del proceso del servicio compuesto se especifica a través de un diagrama de estados, en el cual los estados son etiquetados como invocaciones a servicios Web y las transiciones como eventos, condiciones y operaciones de asignación de variables.

La ejecución de un servicio compuesto es orquestada por una colección de componentes de software llamados coordinadores de estado. Cada coordinador está relacionado con un estado del servicio compuesto. Este coordinador se encarga de inicializar,


12

controlar y monitorear al estado, así como su colaboración con otros durante la ejecución del proceso de orquestación. A Petri Net-based Model for Web Service Composition [HAMA03]

Este trabajo propone un modelo algebraico basado en redes de petri para modelar el flujo de control en los procesos de composición de servicios Web. Este modelo permite capturar la semántica de combinaciones complejas de servicios y sus respectivas especificaciones, así como habilitar la composición declarativa de servicios.

El comportamiento de un servicio Web es básicamente un conjunto de operaciones parcialmente ordenado. Por lo tanto, es posible y claro mapearlo hacia una red de petri. Las operaciones se modelan por transiciones y el estado del servicio por lugares. Las flechas entre lugares y transiciones se utilizan para especificar relaciones causales.

El modelo algebraico presentado permite la creación de nuevos servicios Web utilizando servicios existentes. Cualquier servicio expresado utilizando el álgebra propuesta puede traducirse a una red de petri. Además, el uso de un modelo formal permite la detección de inconsistencias tanto dentro de los servicios como entre ellos. Value-Added Web Service Composition Using Automatic Program Synthesis [MATS02]

Este trabajo propone un método que aplica los métodos de síntesis y composición de software para la composición de servicios Web con valor agregado. Los servicios con valor agregado no son parte de los servicios convencionales y tienen propiedades y características únicas.

El método de composición propuesto utiliza un método de Síntesis Estructural de Programas (SSP). El sintetizador basado en SSP toma como entrada la especificación de un servicio compuesto y genera un plan para satisfacer dicha especificación. El resultado de la planeación es una secuencia de acciones (servicios) a ser ejecutados. Esta secuencia es un servicio compuesto sintetizado.

A partir del modelo planteado se implementó un prototipo que utiliza un lenguaje basado en SSP como presentación interna y DAML-S como lenguaje externo para la descripción de las propiedades de los servicios Web. 1.6.3. Análisis comparativo Existen diferentes métodos y herramientas para dar soporte a la composición de servicios Web. En los apartados 1.6.1 y 1.6.2 de esta sección, se presentó una revisión de trabajos que se encuentran relacionados con el trabajo de tesis que se presenta en este documento. Durante esta revisión se detectaron algunas características que tienen en común, a partir de las cuales se clasificaron en dos categorías principales: basados en un flujo de trabajo y basados en planeación por Inteligencia Artificial (IA).

Debido a las facilidades de modelado que proporcionan las herramientas y modelos basados en un flujo de trabajo, se aplican en situaciones donde el usuario conoce el modelo del proceso y lo define en la petición del servicio compuesto. Para encontrar los servicios Web que completan los requerimientos de dicha petición, estos trabajos requieren de un programa automático o semi-automático de búsqueda de servicios.


13

Además, los métodos basados en flujos de trabajo proporcionan los medios para relacionar los nodos abstractos de los modelos con las fuentes concretas (servicios) automáticamente [RAOJ04a].

Los métodos basados en planeación por IA se utilizan cuando el usuario tiene un conjunto de precondiciones y poscondiciones requeridas para la definición del servicio compuesto.

En los trabajos donde se aplican métodos basados en planeación por IA, el usuario define las características del servicio deseado y éste se genera de forma automática. En algunos de estos trabajos el modelo del proceso puede generarse automáticamente a partir de las llamadas a los métodos que forman el nuevo servicio, a diferencia de los que aplican métodos basados en flujos de trabajo, donde el servicio compuesto se especifica a partir de un diagrama o modelo gráfico, lo que le da un mayor nivel de abstracción y libera al desarrollador de especificaciones textuales.

Una desventaja que presentan la mayoría de los trabajos basados en planeación por IA, es que el usuario debe tener conocimiento detallado del lenguaje que se utiliza para especificar las características del servicio compuesto, ya que estas se representan por medio de reglas, enunciados y/o precondiciones y poscondiciones, según la estrategia de composición utilizada. Además, estas precondiciones y poscondiciones deberán estar definidas dentro de los servicios Web.

Tabla 1. Comparación entre herramientas y modelos que dan soporte a la composición de servicios.

Trabajo Método de

composición Estrategia de composición1

Tipo de modelado Producto resultado

[SLOG04] Guiada por modelo Diagramas de

actividad Método

[CASA00] Diagramas de flujo Herramienta

[MART05] Diagramas de flujo Herramienta

[MAJI04]

Basado en flujos de trabajos

Dinámica

Flujos de trabajo Herramienta

[PONN02] Basada en reglas Modelo Entidad-

Relación Herramienta

[BENA02] Diagramas de estado Prototipo

[HAMA03] Composición declarativa Redes de Petri

Modelo algebraico

[MATS02]

Basado en planeación por IA

Composición por Síntesis de Programas

-- Método

“Esta tesis” Basado en flujos de

trabajos Guiada por modelo

Diagramas de actividad

Prototipo

En la tabla 1 se presentan los trabajos relacionados agrupados de acuerdo a las

características que presentan en común, tomando como base para esta clasificación el método de composición aplicado.

El desarrollo de este trabajo de tesis está basado en flujos de trabajo. En él se lleva a cabo la composición de servicios Web guiada por un modelo utilizando diagramas de actividad. Con esto, el desarrollador de aplicaciones puede especificar la interacción entre servicios de forma gráfica, a través de una notación estándar en el modelado de procesos.

1 Descritas a detalle en [DUST05] y [RAOJ04b].


14

Dentro de los trabajos que aplican métodos basados en flujos de trabajo, se presentan herramientas que modelan el proceso con diagramas de flujo. Un diagrama de flujo es parecido a un diagrama de actividad, la diferencia clave es que los diagramas de actividad pueden mostrar procesamiento en paralelo y los diagramas de flujo, no. Esto es importante cuando se va a modelar un proceso de negocios [POPK02].

El único trabajo que utiliza diagramas de actividad para modelar el proceso, es el que se presentó en [SLOG04]. La desventaja que presenta, es que implementa un método en UMT [UMLM04] . Esta herramienta (UMT) no permite el modelado del proceso, en su lugar utiliza archivos XMI (XML Metadata Interchange) que representan diagramas de actividad, generados por otras herramientas, lo que trae como consecuencia una dependencia hacia sistemas externos y pasos innecesarios en el proceso de composición, como lo son la exportación e importación de archivos. 1.7. Alcances y limitaciones Alcances

A continuación se mencionan los alcances considerados dentro de este trabajo de tesis:

• El producto resultado integra el sistema de búsqueda y selección de servicios, el cliente del WS-SIDDOO y el módulo analizador de documentos WSDL del WS-Compositor (capítulo 4).

• El módulo de composición de servicios permite la generación de código en BPEL4WS de los partner links (enlaces a servicios), variables y la actividad principal del proceso (especificación de interacción entre las operaciones de los servicios componente modelada con diagramas de actividad). Así como la generación de un archivo XML con las URL de los servicios involucrados en el proceso.

• El código de las actividades estructuradas en BPEL se genera a partir de estructuras secuenciales, iterativas y condicionales modeladas con diagramas de actividad (capítulo 3).

• El cliente del WS-SIDDOO (interfaz principal) presenta al usuario una serie de ventanas que permiten configurar cada una de las actividades del modelo en relación a actividades en BPEL4WS (capítulo 4).

• El cliente del WS-SIDDOO permite al usuario definir el documento WSDL que describirá los tipos de datos de entrada y salida del servicio compuesto, utilizando tipos de datos primitivos.

Limitaciones

A continuación se mencionan las limitaciones consideradas dentro de este trabajo de tesis:

• La búsqueda y selección de servicios no están contempladas en este trabajo, ya que corresponden al sistema de búsqueda y selección de servicios Web.


15

• El cliente del WS-SIDDOO se encuentra limitado, y mejorar esta interfaz no se consideró dentro del desarrollo de este trabajo.

• El cliente del WS-SIDDOO permite el modelado de concurrencia entre los métodos que componen al nuevo servicio, pero no se genera el código en BPEL4WS para esos casos.

• El cliente del WS-SIDDOO no permite relacionar las condiciones con los rombos de selección, por lo que el código correspondiente debe incorporarse de forma manual al código BPEL generado a partir del modelo.

• El módulo analizador de documentos WSDL solamente permite analizar los tipos de datos contenidos en la definición <types> dentro del documento WSDL o dentro de un documento XSD importado desde el WSDL, dejando fuera definiciones de tipos de datos que se encuentren en documentos XSD importados desde otro XSD.

• Los documentos WSDL de los servicios a componer deben contener la definición de los partner links de acuerdo a las operaciones expuestas.

16

Capítulo 2. Marco teórico En este capítulo se describen los servicios Web y sus estándares, la composición de servicios, el lenguaje BPEL4WS y los diagramas de actividad. Elementos que se encuentran fuertemente ligados con el desarrollo de este trabajo, y que en conjunto forman el marco teórico que respalda esta tesis. 2.1. Servicios Web Los servicios Web son aplicaciones auto-contenidas y modulares, independientes de la plataforma sobre la que están implementados, y pueden ser: “descritos mediante un lenguaje de descripción de servicios, como el lenguaje WSDL (Web Service Description Language); publicados utilizando el método de registro UDDI (Universal Description, Discovery and Integration); localizables al enviar peticiones al registro y recibir detalles de enlace (binding)

Capítulo 2. Marco teórico

17

del servicio que se ajusta a los parámetros de la búsqueda; asociados al utilizar la información contenida en la descripción del servicio para crear una instancia de servicio disponible o proxy; invocados sobre la red al utilizar la información contenida en los detalles de enlace de la descripción del servicio; y compuestos con otros servicios para integrar servicios y aplicaciones” [SAMP05].

El W3C (World Wide Web Consortium) define a un servicio Web como:

“… un sistema de software diseñado para soportar la interacción entre dos máquinas a través de una red. Posee una interfaz descrita en un formato que puede ser procesado por una máquina (específicamente WSDL). Otros sistemas pueden interactuar con el servicio Web en la manera prescrita por su descripción utilizando mensajes SOAP, típicamente transportados utilizando HTTP y serializados con XML, en conjunción con otros estándares relacionados con la Web ” [W3CW04].

Figura 1. Arquitectura orientada a servicios. Como se muestra en la figura 1, la arquitectura orientada a servicios está compuesta

por tres entidades: el proveedor del servicio, el registro y el consumidor o cliente. Donde el proveedor del servicio simplemente ofrece el servicio Web, el registro contiene información adicional acerca del proveedor y detalles técnicos acerca del servicio, y el consumidor recupera la información del registro y utiliza la descripción del servicio obtenida para enlazar e invocar el servicio Web [DUST05].

Esta arquitectura plantea algo más que una técnica para el desarrollo de aplicaciones Web, representa un modelo de computación distribuida para Internet basado en XML. Bajo este concepto ya no sólo se trata la comunicación usuario-aplicación, sino que de manera adicional se maneja la interacción aplicación-aplicación.

Un servicio Web se puede considerar como una rutina a la cual se le envían los parámetros utilizando XML encapsulados en el protocolo HTTP [RAMA04] .

Descripciones de los servicios

Descripción del servicio

Servicio Enlazar (SOAP)

Registro

Proveedor del servicio

Cliente

Publicar (WSDL, UDDI)

Encontrar (WSDL, UDDI)


18

2.2. Estándares relacionados con los servicios Web

Para conseguir la comunicación entre servicios Web se necesita contar con estándares definidos que permitan llevar a cabo las operaciones de publicación, localización y enlace. Entre estos estándares tenemos: el Lenguaje de Marcado eXtensible (XML), el Lenguaje de Descripción de Servicios Web (WSDL), el Protocolo de Acceso a Objetos Simples (SOAP) y el estándar Universal de Descripción, Localización e Integración (UDDI).

A continuación se describe cada uno de ellos:

Lenguaje de Marcado eXtensible (XML) El lenguaje de marcado extensible (XML) fue desarrollado por un grupo de trabajo

formado bajo el auspicio del W3C en 1996 y desde entonces ha tenido un desarrollo exponencial. Surge como un lenguaje de marcado para complementar a HTML. Tomando como punto de partida al lenguaje SGML (Standard Generalized Markup Language), pero simplificándolo para poder trabajar en la Web, se creó XML y sólo 2 años después, en febrero de 1998, fue adoptado como recomendación por el W3C.

“XML es un lenguaje extensible de etiquetas que juega un papel fundamental en el intercambio de datos. Es muy similar a HTML, pero su función principal es describir datos y no mostrarlos como es el caso de HTML. XML sirve para estructurar, almacenar e intercambiar información. Es un formato que permite la lectura de datos a través de diferentes aplicaciones.

Las tecnologías XML son un conjunto de módulos que ofrecen servicios útiles a las demandas más frecuentes por parte de los usuarios. Entre las tecnologías XML disponibles se pueden destacar: XSL (Extensible Stylesheet Language), XPath (XML Path Language), XLink (XML Linking Language), XPointer (XML Pointer Language) y XQL (XML Query Language)” [W3CO06].

Lenguaje de Descripción de Servicios Web (WSDL)

WSDL es un lenguaje basado en XML que se utiliza para describir servicios Web, define la interfaz del servicio y sus características de implementación. Se puede utilizar para describir, prácticamente, cualquier servicio de red, independientemente de los formatos de los mensajes o protocolos de red utilizados para comunicarse.

“WSDL describe los servicios de red como un conjunto de puntos finales (end points) que procesan mensajes contenedores de información orientada tanto a documentos como a procedimientos. Las operaciones y los mensajes se describen de forma abstracta y después se enlazan a un protocolo de red y a un formato de mensaje concreto para definir un punto final de red. Los puntos finales concretos relacionados se combinan en puntos finales abstractos (servicios).

Un documento WSDL describe servicios como colecciones de puntos finales de red o puertos. En WSDL, la definición abstracta de puntos finales y de mensajes se separa de la instalación concreta de red o de los enlaces del formato de datos. Esto permite la reutilización de definiciones abstractas: mensajes, que son descripciones abstractas de los datos que se están intercambiando y tipos de puertos, que son colecciones abstractas de operaciones.


19

Las especificaciones concretas del protocolo y del formato de datos para un tipo de puerto determinado constituyen un enlace reutilizable. Un puerto se define por la asociación de una dirección de red y un enlace; una colección de puertos define un servicio.

Los elementos que utiliza un documento WSDL en la definición de servicios de red son:

• Types: contenedor de definiciones del tipo de datos que utiliza algún sistema de tipos

(por ejemplo XSD). • Message: definición abstracta y escrita de los datos que se están comunicando. • Operation: descripción abstracta de una acción permitida por el servicio. • Port Type: conjunto abstracto de operaciones admitidas por uno o más puntos finales. • Binding: especificación del protocolo y del formato de datos para un tipo de puerto

determinado. • Port: punto final único que se define como la combinación del enlace y una dirección

de red. • Service: colección de puntos finales relacionados” [W3CN01].

Protocolo de Acceso a Objetos Simples (SOAP)

SOAP es un protocolo estándar basado en XML y creado por Microsoft, IBM y otros, (actualmente está bajo el auspicio de la W3C). Proporciona un mecanismo ligero para el intercambio de información estructurada entre puntos en ambientes descentralizados y distribuidos.

Consta de tres partes: un sobre que define el marco para describir lo que está en el mensaje y cómo procesarlo; un conjunto de reglas codificadas que definen el mecanismo de serialización a utilizar en el intercambio de instancias de los datatypes definidos en la aplicación; y una convención para representar las llamadas y respuestas a procedimientos remotos [W3CN00].

“SOAP Simplifica el acceso a los objetos, permitiendo a las aplicaciones invocar métodos, objetos o funciones, que residen en sistemas remotos.

Una aplicación SOAP crea una petición bloque en XML, proporcionando los datos necesarios para el método remoto así como la ubicación misma del objeto remoto” [PERI02].

Un mensaje SOAP se compone de un sobre (envelope) que contiene el cuerpo (body) y la cabecera (header) del mensaje. El cuerpo contiene la carga de datos del mensaje y la cabecera contiene los datos adicionales que no pertenecen necesariamente al cuerpo del mensaje. Descripción Universal, Localización e Integración (UDDI)

“UDDI son las siglas del catálogo de negocios de Internet denominado Universal Description, Discovery and Integration. El registro en el catálogo se hace en XML. UDDI es una iniciativa industrial abierta (sufragada por la OASIS) que se encuentra en el contexto de los servicios Web. El registro de un negocio en UDDI tiene tres partes:

• Páginas blancas: dirección, contacto y otros identificadores conocidos. • Páginas amarillas: categorización industrial basada en taxonomías.


20

• Páginas verdes: información técnica sobre los servicios que aportan las propias empresas. Es uno de los estándares básicos de los servicios Web cuyo objetivo es ser accedido

por los mensajes SOAP y dar paso a documentos WSDL, en los que se describen los requisitos del protocolo y los formatos del mensaje solicitado para interactuar con los servicios Web del catálogo de registros” [WIKI07] . 2.3. Composición de servicios Web El modelado de procesos de negocio y el uso de servicios Web dan origen al concepto de composición de servicios. Esta permite modelar el proceso y establecer mecanismos para que dos o más servicios colaboren entre sí y cubran requerimientos específicos que van más allá del alcance de sus capacidades individuales.

“Actualmente es posible crear procesos compuestos por interacciones con múltiples servicios Web, o usar algunas soluciones propietarias. Sin embargo, es necesario abordar la composición de servicios basándose en especificaciones estándares, cuyos requisitos básicos son:

• Interacciones asincrónicas con servicios: de tal forma que se habilite la posibilidad

de crear procesos que transcurran durante largos periodos de tiempo. • Interacciones simultáneas con servicios: lo cual significará un aumento considerable

en cuanto a eficiencia. • Manejo de excepciones: un proceso basado en múltiples servicios puede fallar en su

ejecución si al menos uno de sus componentes no está disponible. Se debe tener en cuenta la posibilidad de ocurrencia de errores y además debe incluir mecanismos de manejo para tales escenarios.

• Integridad transaccional: un proceso de larga duración basada en servicios puede fallar eventualmente, requiriendo que parte de las acciones ya efectuadas sean deshechas.

Los dos términos comúnmente usados para referirse a la colaboración entre varios

servicios Web son coreografía y orquestación. Ambos están relacionados directamente con la composición de servicios, pero se enfocan en aspectos complementarios de la interacción entre ellos” [CUBI04]. A continuación se define cada uno de ellos:

Coreografía

Es el conjunto de reglas que rige las características de conducta en relación a la interacción de un grupo de servicios Web. Estas reglas incluyen la secuencia en la cual los servicios pueden ser invocados. El enfoque de coreografía se encuentra generalmente relacionado a una actividad o tarea [EARL04].

“La coreografía sigue la secuencia de los mensajes que pueden implicar múltiples partes y fuentes, incluyendo clientes, proveedores y socios. Típicamente se asocia con el


21

intercambio público de mensajes que ocurre entre servicios Web, más que con un proceso específico del negocio que sea ejecutado por una sola parte” [PELT03].

La coreografía de servicios es colaborativa, ya que cada parte implicada en el proceso describe el papel que juega en la interacción y no es controlada por uno sólo de los participantes.

“Un proceso Web es de coreografía cuando define las colaboraciones entre cualquier tipo de aplicaciones componente, independientemente del lenguaje de programación o de la plataforma de soporte de cada una de ellas. Puede entenderse como un proceso público y no ejecutable: es público porque define el comportamiento común y globalmente visible entre los diferentes participantes en una interacción; por otro lado es no ejecutable porque no está pensado para ser llevado a cabo, sino para actuar como un protocolo de negocio que dicta reglas de interacción que deben ser cumplidas por las entidades participantes. En la coreografía no es relevante la forma en la cual cada entidad implementa su participación, simplemente exige que se rija por ella” [CUBI04]. Orquestación

“Es la implementación de una coreografía dentro del contexto de un flujo de trabajo o proceso de negocio” [EARL04]. Describe cómo pueden interactuar los servicios Web entre sí a nivel de mensajes, incluyendo la lógica del negocio y el orden de ejecución de las interacciones. Estas interacciones pueden atravesar aplicaciones y/o organizaciones, y resultar en un modelo de proceso duradero, transaccional y multi-etapa [PELT03].

Un proceso Web es de orquestación de servicios cuando es controlado totalmente por una única entidad (componente informático). Esta define completamente las interacciones con los servicios componente y la lógica requerida para conducir correctamente esas interacciones. Este proceso puede entenderse como privado y ejecutable: privado porque la definición de la lógica del proceso es hecha enteramente por un participante en la interacción; y ejecutable porque tiene un comportamiento de conversión de entradas en salidas y tiene efectos en el mundo real [CUBI04].

2.4. El lenguaje BPEL4WS “El lenguaje BPEL4WS (Business Process Execution Language for Web Services), BPELWS o comúnmente BPEL, define una notación estándar para especificar el comportamiento de procesos de negocio basados en servicios Web. Representa la convergencia de las ideas presentes en las especificaciones WSFL de IBM y XLANG de Microsoft.

Un proceso BPEL4WS define cómo se coordinan múltiples interacciones de servicios para lograr una meta comercial, así como el estado y la lógica necesaria para esta coordinación.

BPEL4WS introduce mecanismos sistemáticos para tratar excepciones y procesamiento de fallas, y un mecanismo para definir cómo actividades individuales o compuestas en un proceso pueden ser compensadas en caso que ocurra una excepción o se revoque una petición a un servicio” [BEAS03].

22

“BPEL permite especificar tanto procesos abstractos (protocolos de negocio) como procesos de negocio ejecutables. Un proceso abstracto especifica la secuencia de mensajes que deben ser intercambiados por varias entidades que participan en un protocolo de negocio, pero sin revelar aspectos internos de implementación en cada entidad. Mientras que un proceso ejecutable, especifica el comportamiento interno de una entidad, de tal forma que pueda ser ejecutado automáticamente por un motor de ejecución.

Los procesos abstractos especifican coordinaciones de servicios Web, mientras que los procesos ejecutables especifican sus composiciones. Ambos tipos de procesos se especifican utilizando la misma notación básica, común para ambos, y extensiones especificas para cada uno de ellos. Las extensiones son pocas comparadas con la notación básica, de tal forma que la mayor parte de la notación es común para ambos tipos” [ARIA05] .

El lenguaje BPEL4WS depende de las siguientes especificaciones basadas en XML: WSDL 1.1, XMLSchema 1.0, XPath 1.0 y WS-Addressing, siendo WSDL la que más influencia tiene.

Los mensajes WSDL y las definiciones de tipos de XMLSchema, proporcionan el modelo de datos utilizado por los procesos BPEL; XPath, el soporte para la manipulación de datos; y WS-Addressing, un mecanismo para la definición de referencias de los puntos finales (end point) de los servicios Web. Todos los recursos externos se representan en los WSDL de los servicios componentes [BEAS03].

2.4.1. Estructura básica de un documento BPEL4WS BPEL4WS es un lenguaje basado en XML, donde el nodo raíz (process) representa un proceso, y contiene al resto de los elementos que dan lugar a la composición (ver figura 2) [BEAS03].

<process>

 <partnerLinks> . . . . </partnerLinks>

 <partners> . . . . </partners>

  <correlationSets> . . . . </correlationSets>

  <faultHandlers> . . . . </faultHandlers>

  <compensationHandler> . . . . </compensationHandler >

  <eventHandlers> . . . . </eventHandlers>

<!-- Definición del proceso de negocio en el que in teractúan los socios -- > activity


23

</process>

Figura 2. Estructura básica del BPEL4WS 1.1. Un proceso en BPEL4WS es una especie de diagrama de flujo, donde cada elemento

del proceso se llama actividad (activity). Las actividades se clasifican en dos grupos: básicas y estructuradas. Las básicas

(assign, compensate, empty, invoke, receive, reply, throw y wait) representan unidades atómicas de trabajo, mientras que las estructuradas (flow, pick, scope, sequence, switch y while) contienen internamente a otras actividades y especifican las restricciones que aplican a dichas actividades [ARIA05] .

Las actividades estructuradas sequence, switch, while y flow controlan el orden de ejecución de sus actividades internas. Representan ejecución secuencial, condicional, iterativa y concurrente respectivamente. 2.5. Diagramas de actividad “Los diagramas de actividad de UML (Unified Modeling Language), son un caso especial de diagramas de estado que se usan para modelar una secuencia de acciones y condiciones que toman lugar dentro de un proceso” [BELL00]. Sin embargo, un diagrama de estados muestra el flujo entre estados de un objeto en particular, mientras que un diagrama de actividad habla más sobre las transiciones y actividades que causan los cambios de estado del objeto.

Los elementos que componen un diagrama de actividad son [OSMO05]:

• Inicio se representa por un círculo negro sólido. • Actividad representa la acción que será realizada por el sistema, la cual es

representada por un ovalo. • Transición ocurre cuando se lleva a cabo el cambio de una actividad a otra. La

transición se representa por una línea con una flecha en su terminación para indicar dirección.

• Ramificación (branch) ocurre cuando existe la posibilidad de que ocurra más de una transición (resultado) al terminar determinada actividad. Este elemento se representa a través de un rombo.

• Unión (merge) ocurre al fusionar dos o más transiciones en una sola transición o actividad. Este elemento se representa a través de un rombo.

• Expresiones de resguardo (guard expressions) se utiliza para indicar una descripción explícita acerca de una transición. Esta expresión se representa mediante corchetes ([...]) y se coloca sobre la línea de transición.

• Fork representa la necesidad de ramificar una transición en más de una posibilidad. Aunque similar a una ramificación (branch), la diferencia radica en que un fork representa más de una ramificación obligada, esto es, la actividad debe proceder por dos o más caminos, mientras que una ramificación (branch) representa una transición u


24

otra, alternativamente, para la actividad (como una condicional). Se representa por una línea negra sólida, perpendicular a las líneas de transición.

• Join ocurre al fusionar dos o más transiciones provenientes de un fork. Se emplea para unir dichas transiciones en una sola, tal y como ocurría antes de un fork. Se representa por una línea negra sólida, perpendicular a las líneas de transición.

• Fin se representa por un círculo, con otro círculo concéntrico de color negro sólido. • Canales (swimlanes) en determinadas ocasiones ocurre que un diagrama de actividad

se expande a lo largo de más de una entidad o actor. Cuando esto ocurre el diagrama de actividad es particionado en canales (swimlines), donde cada canal representa la entidad o actor que esta llevando a cabo la actividad.

La figura 3 muestra un diagrama de actividad que representa el proceso para llevar a

cabo la reservación de un vehículo, en éste se pueden observar los siguientes elementos: inicio (1), actividad (2), transición (3), evaluación (4) y fin (5).

Figura 3. Ejemplo de un diagrama de actividad. “Aunque un diagrama de actividad es muy similar en definición a un diagrama de flujo

(típicamente asociado al diseño de software), no son lo mismo. Un diagrama de actividad se utiliza en conjunción con un diagrama de casos de uso para auxiliar a los miembros del equipo de desarrollo a entender cómo se utiliza el sistema y cómo reacciona en determinados eventos. En contraste, un diagrama de flujo ayuda a un programador a desarrollar código a través de una descripción lógica de un proceso” [OSMO05]. Para casos de uso, se puede considerar que un diagrama de actividad describe un escenario del problema, mientras que un diagrama de flujo describe la solución, lo mismo sucede para diagramas de actividad que detallan un método.

Un diagrama de actividad tiene como objetivos: identificar y describir la mayor cantidad de tareas necesarias para realizar una operación; documentar la secuencia de las

(1)

(2)

(3)

(4)

(5)


25

actividades, incluyendo las que ocurren en paralelo; asignar responsabilidades; y buscar las oportunidades de reuso.

En [DUMA01] se examinó la expresividad y adecuación de los diagramas de actividad en la especificación de flujos de trabajo, evaluando la forma en que capturan los patrones de dichos flujos. Esta evaluación demostró que soportan la mayoría de los patrones considerados por los WFMS (WorkFlow Management System). 2.5.1. Formalización de los diagramas de actividad

Los diagramas de actividad son semiformales [LOPE04], por esta razón se han realizado diversas investigaciones que proponen semánticas formales y métodos para transformarlos en lenguajes formales como las redes de petri.

En [ESHU01a] se define una semántica formal apropiada para el modelado de flujos de trabajo utilizando diagramas de actividad. Esta semántica permite la manipulación de datos y se basa en la semántica de los diagramas de estado y las redes de petri, ambas extendidas con propiedades transaccionales para trabajar con la manipulación de datos.

El trabajo realizado en [ESHU01b] también define una semántica formal para el modelado de flujos de trabajo utilizando diagramas de actividad de UML. El objetivo de esa semántica es soportar la ejecución de modelos de flujos de trabajo y el análisis de los requerimientos funcionales que satisfacen a dichos modelos. Se basa en la semántica de los diagramas de estado extendida con propiedades transaccionales.

Para proporcionar una semántica formal a los diagramas de actividad en términos de redes de petri, en [LOPE04] se propone un método donde cada uno de los elementos del diagrama se traduce en su equivalente en LGSPN (Labeled Generalized Stochastic Petri net). Esta semántica representa una interpretación de los conceptos definidos informalmente en los diagramas de actividad de UML.

Otro trabajo que examina el estándar de los diagramas de actividad y define una semántica formal en términos de redes de petri se presenta en [STOR04]. Esta semántica se basa en las redes de petri coloreadas y contempla la concurrencia y el control de flujo de datos. Además, conserva la estructura original de los diagramas de actividad en las redes de petri resultantes. En el presente capítulo se describieron los elementos que dan sustento al desarrollo de esta tesis y sus conceptos. En particular, el lenguaje de composición de servicios BPEL4WS y los diagramas de actividad, son parte fundamental en el desarrollo de este trabajo de investigación, cuyo análisis se describe en el capítulo 3, el diseño e implementación en el capítulo 4 y el plan experimental en el capítulo 5.

26

Capítulo 3. Análisis del problema y solución propuesta Para generar código a partir de modelos gráficos, es necesario conocer a detalle el lenguaje a generar y el modelo de base (diagrama); encontrar correspondencias entre código y modelo; y determinar qué elementos se pueden generar de forma automática y cuales no.

En este capítulo se presentan el análisis realizado a los sistemas a integrar (WS-SIDDOO, WS-Compositor y SBSSW), a partir del cual se determinaron los faltantes para realizar la integración y el modelo de solución; y el análisis del lenguaje BPEL4WS [BEAS03] y los diagramas de actividad modelados en el cliente del WS-SIDDOO, que dio como resultado las correspondencias entre los elementos gráficos de los diagramas de actividad y las actividades del BPEL; los atributos de las actividades (básicas y estructuradas) habilitadas en el desarrollo de este trabajo de tesis, los partner links (enlaces a socios) y las variables; y los escenarios para la generación de código de estructuras secuenciales, condicionales e iterativas.

Capítulo 3. Análisis del problema y solución propuesta

27

3.1. WS-SIDDOO

El WS-SIDDOO y su cliente forman un sistema de modelado visual, desarrollado en Java, que permite la creación de diagramas de actividad. El cliente (interfaz gráfica) está formado por menús de opciones, barras de herramientas y otros elementos necesarios para el modelado.

El análisis de este prototipo se dividió en tres partes: la primera corresponde a la revisión de la gramática visual que se implementó en el analizador; la segunda al análisis del funcionamiento del servicio Web (analizador) y la tercera al análisis del funcionamiento del cliente del servicio. Gramática

La gramática visual del WS-SIDDOO se define de la siguiente manera:

GP = (NT,T,S,P,POS,PE), donde: NT: conjunto de símbolos no terminales. T: conjunto de símbolos terminales. S: símbolo inicial. Elemento de NT. P: reglas de producción. POS: elemento que proporciona la posición espacial de los símbolos gráficos. PE: regla de evaluación. El elemento POS se define de la siguiente manera:

POS = {FLUJO, FLUJO_OBJ, DER, ABA, IZQ, ARR}, donde: FLUJO indica la interconexión o flujo de las actividades que se sigue de acuerdo al diseño del diagrama. FLUJO_OBJ representa el flujo opcional de cambio de estado con alguna actividad. DER, ABA , IZQ y ARR indican la posición espacial que tienen los símbolos con respecto a otros. Los símbolos terminales considerados son elementos gráficos que forman parte del

lenguaje visual del tipo diagramático. A cada símbolo terminal se le definen puntos de enlace para unir su conexión externa con otros símbolos gráficos. Los puntos de conexión (enlace) sirven para que los símbolos puedan tener una relación de enlace con otros símbolos y dicha relación se debe dar a través de sus conexiones definidas.

La descripción detallada de la gramática (en notación BNF), la tabla de símbolos no terminales, los símbolos terminales y las reglas de producción se presentan en [ROMA03]. Funcionamiento del servicio Web WS-SIDDOO

El WS-SIDDOO es el encargado de validar formalmente la creación de los modelos evaluando las relaciones entre los diferentes elementos de los diagramas contemplados en la gramática visual desarrollada para el SIDDOO.


28

El servicio está formado por siete clases (ver figura 4). La clase WSSIDDOO se encarga de exponer los métodos del servicio para acceder a ellos vía Internet. La clase WSAnalizaDiseño es una interfaz de programación en la que se definen los métodos que serán implementados en las clases que derivan de ella.

Figura 4. Diagrama de clases del WS-SIDDOO.

Las demás clases del servicio: WSEva_Sinicio, WSEva_Sactividad, WSEva_Sdecisión, WSEva_SBune y WSEva_SBdiv son clases concretas de la interfaz WSAnalizaDiseño.

En el método evaluaConexion de cada clase concreta se implementan las reglas de producción de la gramática correspondientes a los símbolos de inicio, actividad, decisión, unión y división respectivamente.

El método actualizaVarConexion actualiza las variables de los objetos después de crear una nueva conexión.

El WS-SIDDOO está montado en un servidor WASP de Systinet versión 6.0 que se integró al eclipse SDK 3.1 como un plug-in. En su configuración, el servicio no tiene un número máximo de instancias definido y el protocolo XML que utiliza para generar el WSDL es el SOAP 1.1.

Funcionamiento del cliente del WS-SIDDOO

El cliente del WS-SIDDOO corresponde al ambiente de modelado visual de la herramienta. Utiliza las APIs Swing y 2D Graphics de Java para la creación de los elementos gráficos.

En la figura 5 se muestra el diagrama de clases del cliente del WS-SIDDOO, donde la clase principal es Amb_Visual. Esta clase representa la interfaz gráfica del usuario del sistema, contiene la barra de herramientas de modelado, menús y el área de modelado.

Para definir el área que permite dibujar y manipular los símbolos gráficos se definió la clase AreaModelado. Esta clase recibe los eventos del ratón y del teclado que el usuario haga y los pasa a la clase mediador.

WSEva_Sinicio WSEva_Sactividad

WSEva_SBune WSEva_SBdiv

WSSIDDOO WSAnalizaDiseno

WSEva_Sdecision


29

Figura 5. Diagrama de clases del cliente del WS-SIDDOO.

La clase mediador funciona como coordinador de las clases que participan en el ambiente visual (AreaModelado, DibujarS, Barras_Menus y ControlaHerr). Lleva el control temporal de los símbolos y conexiones y se encarga de recibir la orden del área de modelado para repintar los símbolos y conexiones almacenados.

DibujarS es una clase abstracta que define los métodos para dibujar los diferentes símbolos de los diagramas de actividad (inicio del modelo, actividad, ramificación, fork, join, estado de un objeto y fin del modelo).

PintaActi, PintaCondi, PintaDeci, PintaDiv, PintaFin, PintaIni, PintaObj y PintaUne son clases concretas que implementan los métodos que se definen en la clase DibujarS (selecciono, obtenSelecc, dibuja, move, contains, guardacuadro, creaConectores, obtenColor).

La clase MComandos es una interfaz de programación que controla la ejecución de las opciones del menú y las barras de herramientas. Las clases concretas que implementan a MComandos son las diferentes opciones que van a ejecutar acciones de acuerdo a los eventos del ratón o teclado seleccionados.

La clase Adaptador obtiene los valores de los objetos de tipo DibujarS y los convierte en objetos de tipo Vector, para enviarlos al servicio Web.

La clase WSAutomata se comunica con el servicio Web y, a través de ésta, CtrlConexiones accede a las funciones del servicio para validar las conexiones entre los símbolos del modelo.

Durante el modelado de los diagramas, los símbolos gráficos y las conexiones entre ellos se van almacenando en dos vectores de objetos de tipo DibujarS, los cuales contienen la información del objeto (como el tipo, posición dentro del área de modelado y el texto [en caso de tenerlo]). En el caso de las conexiones, se almacena también el objeto de inicio y el objeto final. Estos vectores se almacenan en un archivo, lo que permite reutilizar los modelos.

El cliente del WS-SIDDOO y el servicio, permiten al usuario modelar diagramas de actividad de UML, pero carecen de elementos que habiliten la composición de servicios Web. Para integrar esta herramienta de modelado con los demás módulos y el sistema de búsqueda y

Cortar Copiar Pegar

Mcomandos

Mediador

ControlaHerr

DibujarS

PintaIni PintaObj

Conexion

PintaCondi

AreaModelado

Barras_Menus

Amb_visual

WSAutomata

Adaptador

CtrlConexiones

PintaActi ….

…


30

selección de servicios, se requiere un menú que presente las diferentes actividades a realizar y ventanas que permitan configurar los elementos de la composición.

3.2. WS-Compositor El WS-Compositor [GUZM06] es una herramienta, desarrollada en Java, que habilita la composición secuencial de dos o más servicios Web y permite la generación de un cliente para dicha composición, incluyendo los stubs de conexión. Cuenta con una interfaz que permite al usuario especificar las direcciones URL de los servicios que se desean componer. Esta interfaz facilita la selección de los métodos de cada servicio y la especificación de su secuencia de ejecución en el cliente.

El análisis del WS-Compositor se enfocó al módulo analizador de documentos WSDL, ya que éste se integró con la interfaz del WS-SIDDOO. Analizador de documentos WSDL

Este módulo obtiene la información correspondiente a cada servicio Web necesaria para la composición. Recorre los documentos WSDL de cada servicio y extrae datos como el nombre, ubicación, métodos y parámetros (entrada y salida). Está formado por las clases PFuncion y AnalizadorWSDL (ver figura 6).

Figura 6. Clases del módulo analizador. En PFuncion se define un vector para almacenar los datos de cada de uno de los

métodos del servicio Web, como son el nombre del método, nombre del servicio, parámetros de entrada, parámetros de salida y la URL.

La clase AnalizadorWSDL implementa funciones para el análisis de los documentos WSDL. Este se lleva a cabo en forma de recorrido de un árbol. Para hacer estos recorridos, AnalizadorWSDL utiliza las diferentes funciones que proporciona la API JDOM para la manipulación de documentos XML.

Los métodos que forman la clase AnalizadorWSDL son: getObjects, AbrirDocumento, LeeBásicos y LeeOperaciones. El método getObjects regresa un arreglo de objetos de tipo

PFuncion

String nombre_servicioString DireccionString nombre_funcionString ParametroOutVector parametros

PFuncion()setNombre_funcion()getNombre_funcion()setDireccion()getDireccion()setNombre_servicio()getNombre_servicio()setParametroOut()getParametroOut()setParameterIn()getParameterIn()getCantParametros()

SaxBuilder

AnalizadorWSDL

String LocationString Nombre_Servicioint numero_operaciones

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

builder arrayFunciones


31

PFuncion; AbrirDocumento, abre el documento WSDL de la URL que el usuario proporciona desde la interfaz de la herramienta; LeeBasicos, lee los datos generales del servicio Web como son: nombre, dirección y puerto; y LeeOperaciones, lee los métodos que están implementados en el servicio Web, sus parámetros y tipos de dato, y los almacena en un objeto de tipo Pfuncion.

Estos métodos reconocen la información de los servicios en documentos WSDL generados por las utilerías del servidor Axis, por lo que se requiere modificar su estructura, para adaptarlos a documentos generados por el servidor SOA de Oracle (seleccionado para este trabajo), y agregar una nueva clase que permita obtener los tipos de datos contenidos en esquemas XSD. 3.3. Sistema de búsqueda y selección de servicios Web El sistema de búsqueda y selección de servicios Web (SBSSW) [SOLI06] implementa un modelo de búsqueda y selección de servicios que aplica técnicas de razonamiento basado en casos y proporciona como resultado la descripción o conjunto de descripciones de servicios que se ajustan a los requerimientos del usuario.

Este sistema cuenta con una interfaz Web al usuario implementada en AJAX (Asynchronous JavaScript and XML) que consta de tres páginas Web: la página principal, la página de registro de servicios y la página de localización de servicios; y una interfaz al usuario, desarrollada en Java, que permite realizar la búsqueda de servicios, pero a diferencia de la interfaz Web, no cuenta con una canasta de selección en donde almacenar los servicios a componer.

Debido a que el cliente del WS-SIDDOO no es una interfaz Web, para realizar la integración de los sistemas se seleccionó la interfaz de escritorio del SBSSW, implementada en la clase FrmInterfazSBSSW, la cual debe modificarse, para que permita almacenar las direcciones de las descripciones de los servicios seleccionados para la composición.

Los demás módulos y elementos del sistema (módulo de conexión, módulo razonador, nodo UDDI y biblioteca de casos) no se contemplaron en este trabajo de tesis ya que sólo se utiliza el resultado de las búsquedas efectuadas en la interfaz. 3.4. Correspondencias entre diagramas de actividad y el BPEL4WS Un proceso en BPEL4WS es una especie de diagrama de flujo, expresado en forma textual, representa el orden de ejecución e intercambio de información entre los socios del negocio (partners).

Se usa un diagrama de actividad para modelar la secuencia de acciones (actividades) y condiciones que toman lugar dentro de un proceso.

De acuerdo a la estructura básica de un documento BPEL (capítulo 2), existen elementos definidos fuera de la actividad principal del proceso, estos son: los partner links, variables, conjuntos de correlación y los manejadores de eventos, fallos y compensación. Al analizarlos, no se encontró una correspondencia entre estos y los elementos de un diagrama de


32

actividad, ya que por su estructura, un diagrama de actividad sólo permite modelar la actividad principal de un proceso BPEL, dentro de la que se encuentran las actividades básicas y estructuradas.

Para que un proceso en BPEL se pueda ejecutar, es necesario que existan dentro de éste las definiciones de los partner links y las variables. Por lo que fue necesario considerarlos en el desarrollo de este trabajo de tesis. Quedando la generación de código limitada a las secciones de enlaces a socios (partner links), variables y la actividad principal. 3.5. Elementos del BPEL4WS [BEAS03] A continuación se presentan las características de los diferentes elementos del BPEL implementados en este trabajo de tesis y la selección de atributos de cada uno de ellos para la generación de código. 3.5.1. Partner links y variables PartnerLink

Define las relaciones entre los socios por medio de mensajes SOAP y tipos de puerto utilizados en las interacciones en ambas direcciones.

Cada partner link tiene un nombre y se caracteriza por un partnerLinkType (definido en el documento WSDL).

El rol del proceso se indica a través del atributo myRole y el rol del socio, por el atributo partnerRole. En caso de que el partnerLinkType sólo tenga un rol, se omite uno de los atributos o se asigna el mismo valor para los dos.

En la figura 7 se muestra la sintaxis para la definición de un partner link, como se presenta en la especificación del BPEL.

<partnerLink name="nombre" partnerLinkType="nombreP LT" myRole="nombreMR"? partnerRole="nombrePR"?> </partnerLink>

Figura 7. Sintaxis para la definición de un partner link. Los elementos marcados con un signo de interrogación (?) pueden o no estar presentes

en la definición del elemento. En el Anexo A de esta tesis, se presenta un ejemplo de código BPEL que contiene definiciones de partner links.

Variable

Define una variable de datos usada durante el proceso. Proporciona su definición en términos de tipos de mensajes WSDL, tipos simples en XML Schema o elementos XML Schema.

El nombre de la variable debe ser único, los atributos messageType, type y element se utilizan para especificar el tipo de la variable (ver Anexo A).


33

En la figura 8 se presenta la sintaxis para la definición de una variable, de acuerdo a la especificación del BPEL.

<variable name="nombreVar" messageType="tipoMensaje "? type="tipoDato"? element="elemento"?/>

Figura 8. Sintaxis para la definición de una variable. 3.5.2. Actividades básicas El lenguaje BPEL cuenta con ocho actividades básicas: assign, compensate, empty, invoke, receive, reply, throw y wait. De las cuales, compensate y throw corresponden a la definición de manejadores de fallas y compensación; empty, representa una actividad nula; y wait, define un tiempo de espera durante la ejecución del proceso. Todas estas no se contemplaron para este trabajo de tesis.

Las actividades restantes, assign, invoke, receive y reply, permiten establecer la comunicación entre el proceso y los servicios componente, así como el intercambio de información entre ellos. Razones por las cuales se seleccionaron para ser implementadas en este trabajo. En el Anexo A de esta tesis, se presenta un ejemplo de código BPEL que contiene definiciones de estas actividades. A continuación se describe cada una de ellas y se presenta su sintaxis:

Assign

Asigna o actualiza un valor para una o más variables. Permite copiar datos de una variable XML a otra o calcular el valor de una expresión y almacenarlo en una variable. Para esto, los tipos de dato origen y destino deben ser compatibles.

En la figura 9 se presenta la sintaxis de la actividad assign, como se muestra en la especificación del BPEL.

<assign standard-attributes> standard-elements <copy>+ from-spec to-spec </copy> </assign>

Figura 9. Sintaxis para la actividad assign. Dentro de las etiquetas <assign> y </assign> se debe definir al menos una operación de

copiado, donde el origen se coloca dentro de una etiqueta <from> y el destino dentro de la etiqueta <to>.

El lenguaje XPath juega un papel muy importante dentro de la operación assign, ya que en ésta se utilizan: XPath querys, XPath expressions, Core XPath functions y BPEL XPath functions [ORAC06], por medio de los que se obtiene y manipula información contenida dentro de las variables.


34

Invoke Invoca una operación de un servicio Web. Puede ser una operación síncrona o

asíncrona. Esto depende de los puertos definidos en el WSDL del servicio. En la etiqueta <invoke> se deben definir los atributos partnerLink (enlace con un

servicio), portType (puerto definido en el WSDL del servicio a invocar) y operation (operación del servicio).

Dependiendo de la operación se define el puerto y se determina si se definen una o dos variables. En la figura 10 se muestra la sintaxis de la actividad invoke, de acuerdo a la especificación del BPEL.

<invoke partnerLink="ncname" portType="qname" operation="ncname" inputVariable="ncname"? outputVariable="ncname"? standard-attributes> standard-elements <correlations>? <correlation set="ncname" initiate="yes|no"? pattern="in|out|out-in"/>+ </correlations> <catch faultName="qname" faultVariable="ncname"? >* activity </catch> <catchAll>? activity </catchAll> <compensationHandler>? activity </compensationHandler> </invoke>

Figura 10. Sintaxis para la actividad invoke. Los elementos marcados con un signo de interrogación (?) pueden o no estar presentes

en la definición de la actividad. Las etiquetas correlations, catch y compensation corresponden a los conjuntos de correlación, manejadores de errores y de compensación respectivamente. Receive

Especifica que el partner link espera recibir un mensaje por parte de la operación y el puerto que invocó. Juega un rol importante en el ciclo de vida del proceso, ya que la única forma de instanciarlo, es colocando el atributo createInstance=’yes’ en la primer actividad del proceso.

En la etiqueta <receive> se deben definir los atributos partnerLink (enlace con un servicio), portType (puerto definido en el WSDL del servicio a invocar) y operation (operación del servicio). Dependiendo de la operación, se definen el puerto y la variable.

<receive partnerLink="ncname" portType="qname" operation="ncname" variable="ncname"? createInstanc e="yes|no"? standard-attributes> standard-elements <correlations>? <correlation set="ncname" initiate="yes|no"?> + </correlations> </receive>

Figura 11. Sintaxis para la actividad receive.


35

En la figura 11 se presenta la sintaxis de la actividad receive, como se muestra en la especificación del BPEL.

Los elementos marcados con un signo de interrogación (?) pueden o no estar presentes en la definición de la actividad. La etiqueta correlations corresponde a los conjuntos de correlación. Reply

Envía un mensaje de respuesta a una petición aceptada previamente a través de una actividad receive.

En la etiqueta <reply> se deben definir los atributos partnerLink (enlace con un servicio), portType (puerto definido en el WSDL del servicio a invocar) y operation (operación del servicio). Dependiendo de la operación se definen el puerto y la variable.

En la figura 12 se muestra la sintaxis de la actividad reply, como se presenta en la especificación del BPEL.

<reply partnerLink="ncname" portType="qname" operation="ncname" variable="ncname"? faultName="qn ame"? standard-attributes> standard-elements <correlations>? <correlation set="ncname" initiate="yes|no"?> + </correlations> </reply>

Figura 12. Sintaxis para la actividad reply.

Los elementos marcados con un signo de interrogación (?) pueden o no estar presentes en la definición de la actividad. La etiqueta correlations corresponde a los conjuntos de correlación.

3.5.3. Actividades estructuradas Las actividades estructuradas contienen internamente a otras actividades (básicas y/o estructuradas), y especifican las restricciones que aplican a dichas actividades. En este trabajo de tesis, se implementó la generación del código correspondiente a las actividades de control sequence, switch y while, ya que estas representan la interacción entre métodos de servicios Web dentro de un proceso de composición de forma secuencial, condicional e iterativa, respectivamente. A continuación se describe cada una de ellas y se presenta su sintaxis. Sequence

Contiene una o más actividades (básicas o estructuradas) que se ejecutan de forma secuencial, en el orden en que están definidas dentro del elemento <sequence>. Una actividad no puede comenzar a ejecutarse hasta que su predecesora haya terminado.

En la figura 13 se muestra la sintaxis de la actividad sequence, donde el símbolo más (+) indica que pueden existir una o más actividades (estructuradas o básicas) dentro de una secuencia.


36

<sequence standard-attributes> standard-elements activity+ </sequence>

Figura 13. Sintaxis para la actividad sequence. Switch

Consiste en un conjunto ordenado de ramas condicionales, asociadas a una actividad y definidas en elementos case, seguidas de forma opcional por un elemento otherwise. Las ramas se evalúan en el orden en que fueron definidas. La rama cuya condición se evalúe verdadera, se selecciona para ser ejecutada. Si ninguna condición se evalúa como verdadera y se definió una opción otherwise, entonces se selecciona esta última.

En la figura 14 se muestra la sintaxis de la actividad switch, donde puede existir una o más opciones <case> (esto se especifica por medio de un signo de más) acompañadas de una condición booleana y puede o no existir una opción <otherwise> (esto se especifica por medio de un signo de interrogación).

<switch standard-attributes> standard-elements <case condition="bool-expr">+ activity </case> <otherwise>? activity </otherwise> </switch>

Figura 14. Sintaxis para la actividad switch. While

Soporta la ejecución iterativa de una actividad específica. Tiene asociada una condición booleana y ejecuta la actividad interna mientras que la condición sea verdadera.

En la figura 15 se muestra la sintaxis de la actividad while, donde se asigna una expresión booleana a la condición y se define una actividad interna que puede ser básica o estructurada.

<while condition="bool-expr" standard-attributes> standard-elements activity </while>

Figura 15. Sintaxis para la actividad while. 3.5.4. Atributos seleccionados para la generación de código En base al análisis realizado a cada uno de los elementos del BPEL a utilizar en este trabajo de tesis, se definieron los atributos para su configuración y elementos internos de la siguiente manera:


37

• PartnerLink: nombre2, partnerLinkType, myRole y partnerRole. • Variable: nombre2 y messageType o type (dependiendo el tipo de variable). • Assign: nombre2, origen (variable XML o expresión a copiar) y destino (variable a

actualizar). • Invoke: nombre2, partnerLink, operación, tipo de puerto, variable de entrada y variable

de salida. • Receive: nombre2, partnerLink, operación, tipo de puerto, variable y crear instancia2. • Reply: nombre2, partnerLink, operación, tipo de puerto y variable. • Sequence: actividad interna. • Switch: secciones case (con su respectiva condición1) y/o otherwise. • While: condición2 y actividad interna.

3.6. Escenarios para la generación de código Para generar el código correspondiente a las estructuras secuenciales, condicionales e iterativas a partir de diagramas de actividad, modelados en el cliente del WS-SIDDOO, se verificó qué tipo de estructuras se pueden modelar y bajo qué restricciones (definidas en la gramática de la herramienta). A partir de este análisis se lograron identificar los escenarios que se describen en los siguientes puntos. 3.6.1. Escenarios para la generación de código de estructuras secuenciales

En el cliente del WS-SIDDOO la secuencia de actividades sólo puede modelarse de una forma, con una actividad seguida de otra y así sucesivamente.

La figura 16 muestra el escenario de éxito para la generación de código de estructuras secuenciales. Esta figura contiene un diagrama modelado en el cliente del WS-SIDDOO que cuenta con dos actividades relacionadas por flechas que indican el flujo del proceso y los símbolos de inicio y fin, así como su correspondencia en código BPEL4WS.

Figura 16. Escenario de éxito para la generación de código de estructuras secuenciales.

<sequence> <receive partnerLink="s1" operation="metodo1".../> <assign>

<copy> <from … /><to … /> </copy>

</assign> </sequence>

2 Atributos que pueden ser definidos por el usuario.


38

Al llevar este modelo a código se genera un bloque delimitado por las etiquetas <sequence></sequence>. 3.6.2. Escenarios para la generación de código de estructuras condicionales El cliente del WS-SIDDOO permite el modelado de cuatro tipos de estructuras condicionales: simples, dobles, en cascada y múltiples.

Un problema que se presenta al modelar una estructura condicional en el cliente del WS-SIDDOO, es que puede o no existir la definición de condiciones y éstas, no están relacionadas con las opciones de la condicional. Esto se debe a que la gramática del servicio no tiene reglas de validación definidas para este tipo de situaciones. Al no estar las condiciones relacionadas con los elementos del diagrama, no es posible incluirlas al momento de generar el código y determinar si existe o no una opción por defecto.

Otro problema que se presenta, es que la gramática no valida estructuras, sólo valida la conexión entre elementos, por lo que es necesario definir restricciones para identificar el tipo de estructura a la que pertenecen los rombos de selección y si abren o cierran dicha estructura.

La especificación del lenguaje BPEL4WS 1.1, no contiene una definición para estructuras de tipo if-then o if-then-else, en esta versión, todas las estructuras condicionales se representan mediante actividades estructuradas switch3, por otra parte, los diagramas de actividad carecen de una forma de representación para estructuras switch. Razones por las que en este trabajo, las estructuras if-then e if-then-else de los modelos, serán mapeadas a actividades switch del BPEL.

Tomando en cuenta estas limitantes, se identificaron los diferentes escenarios para la generación de código de estructuras condicionales, que a continuación se describen: a) Selección simple

Una estructura de selección simple permite ejecutar una actividad o un grupo de actividades sólo si se cumple una determinada condición booleana [ESPI04]. Si la condición no se cumple, continúa con la siguiente actividad.

En la figura 17 se presenta el escenario de éxito para la generación de código de estructuras condicionales de selección simple. Esta figura contiene un fragmento de diagrama que cuenta con dos rombos (uno de ramificación y uno de combinación), dos opciones y una actividad, así como su correspondencia en código en BPEL4WS.

Figura 17.Escenario de éxito para la generación de código de estructuras de selección simple.

<switch> <case condition= "" >

<sequence> <assign>

<copy> <from … /><to … />

</copy> </assign> </sequence>

</case> </switch>

3 En BPEL, si no se cumple alguna de las condiciones dentro de una actividad switch, se continúa con la ejecución de la siguiente actividad dentro del proceso de composición.


39

Al llevar este modelo a código, se genera un bloque delimitado por las etiquetas <case></case> y se coloca dentro de las etiquetas <switch> y </switch>.

En la figura 18 se presenta el escenario de fracaso para la generación de código de estructuras de selección simple. Esta figura, modelada en el cliente del WS-SIDDOO, contiene dos rombos (uno de ramificación y uno de combinación), una opción y una actividad.

Figura 18. Escenario de fracaso para la generación de código de estructuras de selección simple.

En este modelo, la estructura condicional se encuentra mal formada, no es posible identificar cuál de los rombos inicia y cuál termina la estructura, ya que el número de sus entradas y salidas es igual, por lo tanto, el código no se puede generar.

b) Selección doble

La estructura de selección doble permite seleccionar una de dos opciones posibles en base a una condición booleana [ESPI04]. La diferencia entre la selección simple y la doble es que en la selección doble se tienen dos caminos diferentes y se pueden especificar una o dos condiciones, mientras que en la simple sólo se especifica una condición que afecta a una actividad o grupo de actividades.

En la figura 19 se presenta el escenario de éxito para la generación de código de estructuras condicionales de selección doble. Esta figura contiene un fragmento de diagrama que cuenta con dos rombos (uno de ramificación y uno de combinación), dos opciones y dos actividades, así como su correspondencia en código en BPEL4WS.

Figura 19. Escenario de éxito para la generación de código de estructuras de selección doble.

<switch> <case condition= "" >

<sequence> <assign>



</case> <case condition= "" >

<sequence> <assign>



</case> </switch>


40

Al llevar este modelo a código, se generan dos bloques delimitados por las etiquetas <case></case>, esto se debe a que no es posible asignar condiciones para identificar si existe o no una opción por defecto (otherwise). Ambos fragmentos de código se colocan dentro de las etiquetas <switch> y </switch> (de acuerdo a la especificación del BPEL). c) Selección en cascada

La estructura de selección en cascada esta formada por varias estructuras de selección doble, una a continuación de otra, de forma que a un rombo de ramificación le sigue otro. Se pasa de una condición a otra si la anterior resulta falsa. En el momento que se encuentra una condición verdadera, se efectúa la acción correspondiente a dicha condición y se omite el resto de la estructura [ESPI04].

Figura 20. Escenario de éxito para la generación de código de estructuras de selección en cascada. En la figura 20 se presenta el escenario de éxito para la generación de código de

estructuras condicionales de selección en cascada. Esta figura contiene un fragmento de diagrama que cuenta con cuatro rombos (dos de ramificación y dos de combinación), cuatro opciones y tres actividades, así como su correspondencia en código en BPEL4WS.

Al llevar este modelo a código, se genera un bloque delimitado por las etiquetas <case></case> para cada rama de las diferentes condicionales. Por cada estructura condicional se genera un bloque delimitado por etiquetas <switch> y </switch>. d) Selección múltiple

La estructura de selección múltiple permite elegir una opción entre varias opciones posibles. El número de conexiones de los rombos de ramificación o iteración de actividades limitan la selección múltiple en los diagramas de actividad a sólo tres opciones.

En la figura 21 se presenta el escenario de éxito para la generación de código de estructuras condicionales de selección múltiple. Esta figura contiene un fragmento de diagrama que cuenta con dos rombos (uno de ramificación y uno de combinación), tres opciones y tres actividades, así como su correspondencia en código en BPEL4WS.

<switch> <case condition= "" /> <invoke partnerLink="s1" .../> </case> <case condition= "" /> <switch>

<case condition= "" /> <assign>…</assign> </case> <case condition= "" />

<assign>…</assign> </case> </switch>

</case> </switch>


41

Figura 21. Escenario de éxito para la generación de código de estructuras de selección múltiple. Al llevar este modelo a código se genera un bloque delimitado por las etiquetas

<case></case> para cada rama de la condicional y se colocan dentro de las etiquetas <switch> y </switch>. 3.6.3. Escenarios para la generación de código de estructuras iterativas El cliente del WS-SIDDOO permite modelar las estructuras iterativas de actividades de dos formas: la primera evaluando la condición antes de ejecutar la actividad (while) y la segunda, evaluando la condición al final (do_while).

Un problema que se presenta al modelar una estructura iterativa en el cliente del WS-SIDDOO es que puede o no existir la definición de una condición y no está relacionada con el rombo que delimita la estructura. Esto se debe a que la gramática del servicio no tiene reglas de validación definidas para este tipo de situaciones. Al no estar las condiciones relacionadas con los elementos del diagrama, no es posible incluirlas al momento de generar el código.

A continuación se presentan los diferentes escenarios que se identificaron para la generación de código de estructuras iterativas: a) Evaluación de la condición antes de ejecutar las actividades

La estructura iterativa while evalúa la condición booleana al inicio, si es falsa continúa con la ejecución de la siguiente actividad. Si la condición es verdadera, ejecuta la actividad (o actividades) que se encuentra dentro del cuerpo y vuelve a evaluar la condición.

Figura 22. Escenario de éxito para la generación de código de estructuras iterativas while.

<switch> <case condition= ""> <receive partnerLink="s1" operation="metodo1"../> </case> <case condition= "" > <invoke partnerLink="s2" operation="metodo2".../> </case> <case condition= "" > <assign>... </assign> </case> </switch>

<while condition= "" > <invoke partnerLink= "s1" operation="metodo1" .../> <receive partnerLink="s1" operation="metodo1" .../> </while>


42

En la figura 22 se presenta el escenario de éxito para la generación de código de estructuras iterativas de tipo while. Esta figura contiene un fragmento de diagrama que cuenta con un rombo de ramificación, dos opciones y dos actividades, así como su correspondencia en código en BPEL4WS.

Al llevar este modelo a código, la condición se coloca como atributo de la etiqueta <while> y las actividades se colocan dentro de las etiquetas <while> y </while>.

b) Evaluación de la condición después de ejecutar las actividades

La estructura iterativa do_while asegura la ejecución de la actividad (o actividades) internas al menos una vez y después evalúa la condición.

El cliente del WS-SIDDOO permite modelar este tipo de estructuras, pero en la especificación del lenguaje BPEL4WS v.1.1, no existe una correspondencia. Por lo que es necesario realizar una conversión y expresarla utilizando una actividad BPEL de tipo while.

La figura 23 muestra el escenario de éxito para la generación de código de estructuras iterativas de tipo do_while. Esta figura contiene un fragmento de diagrama que cuenta con un rombo de ramificación, dos opciones y dos actividades, así como su correspondencia en código en BPEL4WS.

Figura 23. Escenario de éxito para la generación de código de estructuras iterativas do_while. Al llevar este modelo a código, contiene dos veces las mismas actividades internas de

la estructura. El primer juego de actividades, de forma secuencial y el segundo, dentro de las etiquetas <while> y </while>, la condición se coloca como atributo de la etiqueta <while>. 3.6.4. Escenario general de fracaso para la generación de código El cliente del WS-SIDDOO permite realizar modelos incompletos. Un escenario de fracaso para la generación del código de cualquiera de las estructuras presentadas, ocurre cuando en el diagrama de actividad no se definen todas las relaciones necesarias entre los elementos de las estructuras que lo forman, tal como se muestra en la figura 24.

Al llevar este modelo a código, el resultado sólo incluye aquellos elementos que se evalúan antes de llegar a la segunda actividad de tipo assign, de la rama de la condicional incompleta (1). El resto del diagrama se omite, ya que el recorrido se trunca cuando hacen falta relaciones entre los elementos que lo componen.

<assign> . . . </assign> <invoke partnerLink="s1" .../> <while condition= ""> <assign>

<copy> <from … /><to … /> </copy> </assign> <invoke partnerLink="s1" .../> </while>


43

Figura 24. Escenario de fracaso para la generación de código.

3.7. Modelo de solución Para contribuir a solucionar el problema de la composición de servicios Web, en esta tesis se propone la integración del sistema de búsqueda y selección de servicios Web [SOLI06], el módulo analizador de documentos WSDL del WS-Compositor [GUZM06] y el WS-SIDDOO (cliente y servicio Web) [VAZQ04]. Logrando así, que a partir de una búsqueda de servicios Web en base a su funcionalidad se habilite la composición de éstos, especificando su interacción con un diagrama de actividad que puede contener estructuras secuenciales, condicionales y/o iterativas.

Esto proporciona al desarrollador de aplicaciones la ventaja de especificar la interacción entre los métodos de los servicios componente de forma gráfica, a través de una notación estándar en el modelado de procesos.

En base al análisis que se realizó a los módulos que componen los trabajos a integrar, se plantea un modelo de solución compuesto por cinco módulos: el cliente del WS-SIDDOO, el servicio Web WS-SIDDOO, la interfaz del sistema de búsqueda y selección de servicios Web, el módulo analizador de WSDL y el módulo de composición (ver figura 25).

(1)

<sequence> <receive … /> <switch> <case …> <sequence> <assign>…</assign> <assign>…</assign>


44

Figura 25. Modelo de solución propuesto. Por medio de la interfaz al usuario del sistema de búsqueda y selección de servicios

Web, el desarrollador de aplicaciones introduce las características funcionales de los servicios deseados, el sistema se encarga de realizar la búsqueda dentro de la UDDI (Universal Description Discovery and Integration), presenta al usuario el resultado y el desarrollador selecciona las descripciones de los servicios a componer.

Los nombres y las URL (Uniform Resource Locator) de los documentos WSDL de los servicios seleccionados se envían al cliente del WS-SIDDOO. En éste, el desarrollador modela la interacción entre los diferentes servicios. Para asignar a las actividades del modelo una acción relacionada con un servicio, se presenta una ventana de configuración, donde el desarrollador selecciona de una lista, el tipo de operación a realizar y un servicio.

De acuerdo al servicio seleccionado, el módulo analizador de WSDL obtiene la información necesaria para la composición (métodos, enlaces entre los elementos a componer y mensajes) y la presenta al desarrollador, para que éste configure la operación.

El servicio Web WS-SIDDOO se encarga de validar las conexiones entre los diferentes elementos del modelo.

Por último, el desarrollador manda llamar desde el cliente del WS-SIDDOO al módulo de composición, el cual se encarga de generar un documento en BPEL4WS que corresponde a la interacción entre los servicios Web de acuerdo al modelo generado. Este módulo está formado por una serie de algoritmos que identifican las estructuras que forman al diagrama de actividad, así como las operaciones, elementos y variables del proceso. En este capítulo, se presentaron diversos puntos relacionados con el análisis del problema y la propuesta de solución. Siendo la identificación de correspondencias entre el BPEL4WS y los diagramas de actividad, y el análisis de los elementos del lenguaje, puntos clave para determinar los alcances del módulo de composición de servicios Web. El análisis de los

(WS-Compositor) Analizador WSDL

Sistema de búsqueda y selección de servicios

Web

Cliente WS-SIDDOO

Módulo de composición

WS-SIDDOO

Especificación de la interacción de los servicios

UDDI Métodos, enlaces, mensajes

Nombre, URL WSDL

URL WSDL

INTERNET INTERNET


45

diferentes sistemas a integrar, dio como resultado el modelo de solución. El diseño e implementación de la solución, a nivel de integración de sistemas y módulo de composición, se encuentran descritos en el siguiente capítulo.

46

Capítulo 4. Diseño e implementación del sistema El desarrollo de este trabajo de tesis involucró la integración de distintos sistemas y módulos, previamente implementados en otras investigaciones del área, que fueron adaptados para permitir la interacción entre ellos; así como el desarrollo de un módulo y ventanas encargados de la configuración y generación del código en BPEL4WS para la composición de servicios Web.

En este capítulo se presenta el diseño e implementación del sistema (integración), representado por diagramas de casos de uso, secuencia y componentes; el diseño e implementación del módulo de composición, formado por diagramas de casos de uso, clases y secuencia; y el diseño e implementación de las ventanas de configuración que dan soporte a dicho módulo.

Capítulo 4. Diseño e implementación del sistema

47

4.1. Diseño e implementación de la integración de sistemas Al integrar el sistema de búsqueda y selección de servicios Web (SBSSW), el WS-SIDDOO (cliente y servicio), el módulo analizador de documentos WSDL (WS-Compositor) y el módulo de composición de servicios, el sistema resultado permite realizar tres operaciones principales: buscar y seleccionar servicios Web; modelar la interacción entre los servicios seleccionados; y generar el código en BPEL4WS correspondiente al modelo realizado.

En esta sección se presenta una vista general del sistema (integración), que incluye las operaciones implementadas en los sistemas y módulos anteriormente mencionados, las desarrolladas en este trabajo y las relaciones que existen entre ellas. 4.1.1. Casos de uso En la figura 26 se presentan los casos de uso del sistema, donde los casos CU_1, CU_2 y CU_4 son operaciones que fueron implementadas de forma independiente, en [SOLI06], [VAZQ04] y [GUZM06] respectivamente, y se integraron con el caso CU_3 (operación desarrollada en este trabajo de tesis).

Figura 26. Casos de uso del sistema.

Los casos de uso CU_1, CU_2 y CU_3, están relacionados directamente con el desarrollador de aplicaciones, ya que él es quien se encarga de llevar a cabo las acciones correspondientes a cada uno de ellos.

El caso CU_2 incluye al CU_4, que se encarga de analizar los documentos WSDL de los servicios en busca de los datos necesarios para la composición, y permite al desarrollador especificar las operaciones de los servicios a utilizar.

<<uses>>

CU_1. Buscar y seleccionar servicios Web

Desarrollador CU_4. Analizar WSDLCU_2. Modelar interacción entre servicios Web

<<include>>

CU_3. Generar código en BPEL


48

La descripción completa de los escenarios de éxito y fracaso de estos casos de uso, se encuentra en el Anexo B de esta tesis.

4.1.2. Implementación de la integración de sistemas Los sistemas y módulos integrados en este trabajo, formados por componentes y paquetes, se encuentran relacionados entre sí y se pueden considerar componentes del sistema resultado (ver figura 27).

Figura 27. Diagrama de componentes del sistema. A continuación se describe la estructura de cada uno de estos componentes y las

relaciones que existen entre ellos:

• Sistema de búsqueda y selección de servicios Web. Está constituido por un nodo UDDI, un módulo de conexión, un módulo razonador, una biblioteca de casos y una interfaz al usuario. Permite al usuario realizar búsquedas de servicios de acuerdo a su funcionalidad y seleccionarlos para la composición, para posteriormente presentarlos en el cliente del WS-SIDOO.

• Cliente del WS-SIDDOO. Se encuentra formado por un conjunto de clases

desarrolladas en Java y el paquete WASP de Systinet. Presenta una interfaz gráfica al usuario en la que el desarrollador modela los diagramas de actividad y relaciona las actividades del modelo con operaciones de los servicios seleccionados (de acuerdo a los datos obtenidos en el módulo analizador de WSDL) y por medio de las librerías del WASP se conecta con el servicio Web WS-SIDDOO para validar los modelos.

UDDI

Biblioteca de casos

Módulo de conexión

<<Java>>

Módulo razonador

<<Java>>

Interfaz<<Java>>

Sistema de búsqueda y selección de servicios Web

JDOM<<package>>

Módulo analizador de WSDL

Módulo de composición

Servicio Web WS-SIDDOO

Clases<<Java>>

WASP<<package>>

Cliente del WS-SIDDOO

Clases<<Java>>

Clases<<Java>>

Clases<<Java>>


49

• Módulo analizador de documentos WSDL. Está formado por un conjunto de clases desarrolladas en Java y el paquete JDOM. Este módulo depende de las direcciones (URLs) de los servicios Web seleccionados en la ventana de configuración del cliente del WS-SIDDOO.

• Servicio Web WS-SIDDOO. Se encuentra formado por un conjunto de clases

desarrolladas en Java que se encargan de validar las conexiones entre los distintos elementos de los diagramas de actividad modelados en el cliente.

• Módulo de composición. Está constituido por un conjunto de clases desarrolladas en

Java, que a partir de un diagrama modelado en el cliente del WS-SIDDOO genera el código correspondiente en BPEL4WS. Para ilustrar la interacción entre estos componentes, en la figura 28 se presenta un

diagrama de secuencia representando un escenario de generación de código en BPEL, que parte de la búsqueda y selección de servicios Web.

En este escenario, el desarrollador de aplicaciones accede a la interfaz del sistema de búsqueda y selección de servicios, donde realiza búsquedas en base a la funcionalidad requerida de los servicios a componer. Selecciona los servicios a utilizar y la opción componer dentro de la interfaz. Esta envía al cliente del WS-SIDDOO un vector que contiene los nombres y las URLs de los documentos WSDL de los servicios Web.

El desarrollador selecciona cada uno de los servicios a utilizar y configura los diferentes partner links que estarán involucrados en el proceso, para esto, el cliente envía las URLs de los WSDLs de los servicios Web al módulo analizador, éste obtiene los datos necesarios para la configuración.

Posteriormente, el desarrollador dibuja cada una de las actividades que corresponderán a actividades en BPEL. Para configurarlas, el cliente del WS-SIDDOO envía al analizador de documentos WSDL la URL del partner link seleccionado para dicha actividad. Este obtiene los datos correspondientes a las operaciones y puertos del servicio. El cliente recupera esta información y la presenta al desarrollador, dentro de una ventana de configuración, para asignar las operaciones a las actividades del modelo.

Se dibujan las conexiones entre los elementos del diagrama de actividad y se envían al servicio Web WS-SIDDOO, para validar que sea posible relacionar los elementos de inicio y fin de la conexión, y que no han sobrepasado el número de conexiones permitido.

Al haber terminado de modelar y configurar el diagrama, el desarrollador selecciona la opción componer en el cliente del WS-SIDDOO. Este último envía el vector de conexiones al módulo de composición de servicios.

El módulo de composición recorre el vector de conexiones y los vectores que almacenan variables, partner links y espacios de nombre, genera el código en BPEL4WS correspondiente al modelo y lo envía al cliente del WS-SIDDOO.


50

Figura 28. Diagrama de secuencia general del sistema. 4.2. Diseño e implementación del módulo de composición de servicios Después de analizar la gramática que valida la construcción de los diagramas de actividad, implementada en el servicio Web WS-SIDDOO, se llegó a la conclusión de que ésta sólo verifica la conexión entre los diferentes símbolos que forman el diagrama. Por lo tanto, no fue posible agregarle acciones semánticas para la generación de código.

Módulo analizador de WSDL

: DesarrolladorSistema de búsqueda y

selección de SWCliente del

WS_SIDDOOWS_SIDDOO Módulo de

composición

Busca_SW

Proporciona_Resultados

Selecciona_Componer

Selecciona_SW

Dibuja_conexión

Asigna_operación

Selecciona_componer

Presenta_BPEL

Conf igura_activ idad

Conf igura_PartnerLink

Selecciona_serv icioEnv ia_URL_de_WSDL

Obtiene_datos

Env ia_v ector

Dibuja_elementos

Recupera_datos

Presenta_datos

Recupera_datosPresenta_datos

Env ia_conexiónValida_conexión

Env ia_v ector_de_conexionesRecorre_v ectores

Genera_BPEL

Regresa_BPEL

*[Mientras hay a f iguras]

*[Mientras hay a partner Links]


51

La información correspondiente al diagrama modelado en el cliente del WS-SIDDOO se almacena de forma temporal en dos vectores: el primero, contiene los elementos gráficos que componen al diagrama; y el segundo, las relaciones que existen entre ellos. Cada relación está formada por un elemento flecha, en el que se definen como atributos dos objetos de la clase DibujarS (elementos inicio y fin de la relación).

A partir de la información que se encuentra en el vector de relaciones, fue posible determinar qué estructuras componen al diagrama y qué elementos se encuentran contenidos en ellas (actividades u otras estructuras).

Para reconocer estas estructuras y generar el código correspondiente en BPEL4WS, se diseñaron e implementaron una serie de algoritmos basados en características definidas para cada una de ellas, de acuerdo a lo que permite modelar el cliente del WS-SIDDOO. Quedando estas características de la siguiente manera:

a) Estructuras condicionales (simple, doble o múltiple)

El inicio de estas estructuras se indica con un rombo de ramificación (branch) con una entrada y varias salidas (2 ó 3), y el fin con un símbolo de fin o un rombo de combinación (merge) que tiene varias entradas (2 ó 3) y una salida, (ver figura 29).

Figura 29. Estructuras condicionales. b) Estructuras condicionales en cascada

Inician con rombos de ramificación (branch) continuos que tienen una entrada y dos salidas, y cada condicional termina con un rombo de combinación (merge) que tiene dos entradas y una salida. Entre los rombos de selección pueden existir otras estructuras o actividades (ver figura 30).

Figura 30. Estructura condicional en cascada.


52

c) Estructuras iterativas de tipo while El inicio y fin de estas estructuras se indica con un rombo de ramificación que tiene

dos entradas y dos salidas. En los casos donde se presentan estructuras anidadas, estas se separan por las actividades que inicializan e incrementan los valores de las variables de control (ver figura 31).

a) b) Figura 31.Estructuras iterativas (while). a) simple. b) anidadas.

d) Estructuras iterativas de tipo do_while

El inicio de estas estructuras se indica con un símbolo de actividad y el fin con un rombo (ver figura 32).

Figura 32. Estructura iterativa (do_while). 4.2.1. Casos de uso del módulo de composición En la figura 33 se presentan los casos de uso del módulo de composición, así como las relaciones que existen entre ellos. El caso CU_3 (diagrama general de casos de uso) incluye a los casos CU_5, CU_6, CU_7 y CU_8, y se encarga de coordinar la generación de código de los diferentes elementos del BPEL4WS.


53

Figura 33. Diagrama de casos de uso del módulo de composición.

El caso de uso CU_5, involucra la generación del código correspondiente al encabezado del documento BPEL, variables y partner links. Los casos CU_6, CU_7 y CU_8, el código correspondiente a las estructuras que forman la actividad principal del proceso. La descripción completa de los escenarios de éxito y fracaso de estos casos de uso, se encuentra en el Anexo C de esta tesis.

4.2.2. Implementación del módulo de composición El módulo de composición de servicios Web se desarrolló utilizando el lenguaje Java. En su arquitectura de clases se implementaron los patrones de diseño Composite y Strategy (ver figura 34).

Las clases principales de este módulo son CBPELElementos, que contiene en su definición vectores estáticos que almacenan parte de la información de la configuración del modelo (diagrama de actividad) y los métodos para recuperarla, y CGeneraBPEL, que coordina la ejecución de los métodos de las clases generadoras de código.

Las funciones para generar el código del encabezado, variables y partner links, se separaron en las clases CGenEncabezado, CGenPL y CGenVariable. Aplicando el patrón de diseño Strategy para dar extensibilidad al módulo. Si se desea implementar la generación de código de alguno de los elementos que no fueron considerados en este trabajo, es posible

CU_6. Generar código de estructuras secuenciales

CU_7. Generar código de estructuras condicionales

CU_8. Generar código de estructuras iterativas

CU_3. Generar código en BPEL

CU_5. Generar código de encabezado

<<include>>

<<include>>

<<include>>

<<include>>


54

agregar la clase que contenga el algoritmo generador sin hacer cambios a la estructura actual del módulo.

Figura 34. Arquitectura de clases del módulo de composición.

Las clases CActividad, CDecisión, CFin, CFork y CJoin, también implementan el patrón Strategy, separando los algoritmos de recorrido del diagrama, de acuerdo al elemento (de la notación UML) encontrado. La clase AStrategy contiene una función que hereda a todas sus sub-clases, con la que se aplica el patrón Composite. Esto permite crear nuevos objetos de los tipos de las clases derivadas para el recorrido del vector de conexiones. La descripción completa de cada clase del módulo de composición se encuentra en el Anexo D de esta tesis y la descripción de las ventanas, en el siguiente apartado.

A continuación se ilustra la interacción entre las clases del módulo de composición por medio de diagramas de secuencia que modelan escenarios de éxito para generar código en BPEL4WS. En todos los escenarios se asume que el cliente del WS-SIDDOO creó una

objobj

obj obj

CGenEncabezado

CGenEncabezado()StringBuffer fnGenera()

CGenVariable

CGenVariable()StringBuffer fnGenera()

obj

editor

obj

Ventanas

CActividad

int entradas

CActividad()void fnRecorre()void fnCuentaES()

CDecision

CDecision()void fnRecorre()void fnRecorreCond()void fnRecorreWhile()

CFin

CFin()void fnRecorre()

CFork

CFork()void fnRecorre()

CJoin

CJoin()void fnRecorre()

DibujarS pintaFlecha

obj

AStrategy

DibujarS conexionpintaFlecha conectorstatic boolean copiarstatic stringBuffer BPELAuxstatic pintaActi controlstatic int empty

void fnRecorre()void fnLlamaMetodos()

AGenElemento

StringBuffer xml

StringBuffer fnGenera()

amb_visual

CRecorreVect

Vector conexionesVector anteriorVector siguienteint iStringBuffer BPELAStrategy obj

CRecorreVect()void fnIdentificaObj()void fnCuentaES()StringBuffer fnGetBPEL()

CVentanaNombre

CGeneraBPEL

StringBuffer BPELCRecorreVect genBPELAGenElemento genEnc

CGeneraBPEL()void fnObtenerBPEL()

genEnc

identifica

genBPEL

ventanaN

CVentanaBPELventana

CBPELElementos

Vector serviciosVector variablesVector PLVector TNS

void fn Inicializa()Void fnGuardaServicios()void fnGuardaTNS()void fnGuardaPL()void fnGuardaVariables()Vector fnGetServicios()Vector fnGetTNS()Vector fnGetPL()Vector fnGetVariables()

CGenXML

Document doc

CGenXML()fnGuardaXML()

obj

Modulo analizador WSDL

CGenPL

CGenPL()StringBuffer fnGenera()

AnalizadorWSDL analizador


55

instancia de la clase CGeneraBPEL y le envió como parámetro el vector de conexiones del diagrama de actividad.

La figura 35 presenta el escenario para generar el código del encabezado. En éste, la instancia de la clase CGeneraBPEL invoca al constructor de la clase CVentanaNombre, genera una ventana para pedir al usuario el nombre del proceso y lo recupera con el método fnGetNombre( ).

Figura 35. Escenario para generar código del encabezado, partnerLinks y las variables del proceso. La instancia de la clase CGeneraBPEL también contiene un objeto de tipo

AGenElemento, al que le indica comportarse como objeto de los tipos CGenEncabezado, CGenPL y CGenVariable, y por medio de fnGenera( ), generar y recuperar el código en BPEL del encabezado (etiqueta process), la definición de los partner links y la declaración de variables, respectivamente.

El escenario para generar código correspondiente a estructuras secuenciales se muestra en la figura 36. En éste, una instancia de CGeneraBPEL invoca al constructor de la clase CRecorreVect. Al llamar al método fnIdentificaObj( ), comienza el recorrido del vector de conexiones y se agrega a un objeto de tipo StringBuffer la etiqueta <sequence> que inicia la actividad principal del proceso.

En CRecorreVect se define un objeto de tipo AStrategy (obj), el cual va a tomar forma de acuerdo al elemento que se encuentre en el vector de conexiones relacionado con el símbolo de inicio. Obj toma la forma de un objeto de tipo CActividad y se encarga de generar el código correspondiente al elemento del diagrama e identificar el tipo del siguiente elemento en el vector. En CActividad se define a su vez un objeto de tipo AStrategy, también

identif ica : CGeneraBPEL

v entanaN : CVentanaNombre

genEnc : CGenEncabezado

genEnc : CGenPL

genEnc : CGenVariable

new CGenEncabezado( )

StringBuf f er f nGenera( )

StringBuf f er f nGenera( )

new CGenPL( )

new CGenVariable( )

StringBuf f er f nGenera()

new CVentanaNombre( )

Vector f nGetNombre( )

Return nombre

Return BPEL

Return BPEL

Return BPEL


56

denominado obj, el cual toma la forma de un objeto de tipo CFin (ya que en este caso el siguiente elemento es un fin).

Figura 36. Escenario de generación de código de estructuras secuenciales.

Entre los parámetros que se envían a través de fnRecorre( ) y fnLlamaMetodos( ) se encuentra el StringBuffer del código generado. Este se va modificando durante las ejecuciones de fnRecorre( ). Al terminar el recorrido del vector de conexiones, el código BPEL del diagrama se encuentra en la instancia de la clase CRecorreVect, donde se agregan las etiquetas </sequence> y </process>. El objeto de la clase CGeneraBPEL llama al método fnGetBPEL( ) y lo recupera.

La figura 37 presenta el escenario para generar código de estructuras condicionales. Se asume que una instancia de CGeneraBPEL invocó al constructor de CRecorreVect. El método fnCuentaES( ) determina el número de entradas y salidas para cada rombo del diagrama. La ejecución de fnIdentificaObj( ) inicia el recorrido del vector de conexiones.

Obj toma la forma de un objeto de tipo CActividad, genera el código de este elemento y busca el símbolo que se encuentre relacionado con esta actividad dentro del vector de conexiones. La función fnLlamaMetodos( ) lo identifica como un rombo. El objeto obj contenido en CActividad toma la forma de un objeto de tipo CDesicion.

FnRecorre( ) identifica si el rombo corresponde a una condicional o a una estructura iterativa. Al identificarse como elemento que abre una estructura condicional, se agregan al código las etiquetas <switch>, <case> y <sequence>.

Se continúa con el recorrido del vector y la generación del código de las actividades internas de la estructura. Al llegar a un rombo que se identifica como elemento de cierre de una condicional, se agregan las etiquetas </sequence> y </case>, y en el caso de que no existan más opciones dentro de la estructura, la etiqueta </switch>.

identifica : CGeneraBPEL

genBPEL : CRecorreVect

obj : CActividad

obj : CFin

new CRecorreVect( )

void fnIdentificaObj()

new CActividad( )

void fnLlamaMetodos()

new CFin( )

void fnRecorre( )

void fnRecorre( )

Return BPEL

StringBuffer fnGetBPEL( )


57

Figura 37. Escenario de generación de código de estructuras condicionales.

4.3. Ventanas de configuración Las ventanas de configuración necesarias para complementar la interfaz del cliente del WS-SIDDOO se desarrollaron utilizando Java. A través de ellas, el usuario puede configurar elementos involucrados en la composición y que no corresponden a símbolos de la notación UML, tales como las variables y los partner links, así como relacionar a cada una de las actividades del modelo con actividades en BPEL4WS, servicios, operaciones y variables. Ventana de configuración (principal)

Permite al usuario configurar una actividad del modelo (diagrama de actividad) con relación a uno de los servicios seleccionados y una operación en BPEL4WS. Los principales elementos de esta ventana se muestran en la figura 38 y son:

genBPEL : CRecorreVect

obj : CDecision

obj : CActividad

new CActividad( )

void fnRecorre( )

void fnLlamaMetodos( )

void fnCuentaES( )

new CDecision( )

void fnRecorre( )void fnRecorreCond( )


new CActividad( )

void fnRecorre( )


new CDecision( )

void fnRecorre( )void fnRecorreCond( )


58

• Un combo (1) para seleccionar el tipo de actividad en BPEL a realizar. A partir de la actividad seleccionada se presentan distintos campos para su configuración de acuerdo a los atributos seleccionados de la especificación del lenguaje (capítulo 3).

• Un botón (2) que llama a la ventana agregar partner links. • Un botón (3) que llama a la ventana de configuración de roles. • Un combo (4) que permite al usuario seleccionar el partner link a relacionar con la

actividad. • Un combo (5) para seleccionar la operación del partner link que se presenta en el

combo (4). • Dos botones (6) que llaman a la ventana de creación de variables. • Dos botones (7) que llaman a la ventana de búsqueda de variables. • Dos botones (8) que llaman a la ventana de asignación.

a) b) Figura 38. Ventana de configuración. a) Operación assign. b) Operación invoke.

En la figura 38a se presenta la ventana de configuración para una operación de tipo

assign, donde los datos necesarios son el nombre y las partes o variables de donde se va a copiar la información y las partes o variables destino. Mientras que en la figura 38b se muestra la ventana para una operación de tipo invoke, la cual involucra campos como el partner link (definición de enlace a un servicio), la operación a realizar y las variables con las que se va a manejar la información. Ventanas de creación de variables

Las ventanas que se muestran en la figura 39, permiten crear variables para las actividades BPEL invoke, receive y reply. En la ventana de la figura 39a, el nombre de la variable se crea de forma automática a partir del nombre de la actividad BPEL seleccionada en la ventana de configuración, la operación del servicio y el tipo de variable. Para crear variables de tipos primitivos se utiliza la ventana de la figura 39b.

(1)

(8)

(1)

(2) (3)

(6) (7)

(4)

(5)


59

a) b) Figura 39. Ventana de creación de variables. a) Tipos WSDL. b) Tipos primitivos.

Ventana para agregar un partner link

Permite agregar un partner link al proceso a partir de un servicio que haya sido previamente registrado, y configurar sus atributos en base a los roles y tipos definidos en el documento WSDL del servicio (ver figura 40).

Figura 40. Ventana para agregar un partner link. Ventana de asignación

Permite seleccionar una variable o parte de ella desde un árbol, para asignarla a otra variable dentro del proceso, así como definir expresiones en el lenguaje XPath para obtener y manipular información (ver figura 41).

Figura 41. Ventana de asignación.


60

Ventana de búsqueda de variables Permite buscar una variable que fue previamente registrada, para relacionarla con la

actividad en BPEL que se está configurando (ver figura 42).

Figura 42. Ventana de búsqueda de variables. Ventana BPEL

La figura 43 muestra la ventana que presenta al usuario código BPEL4WS editable generado a partir del diagrama de actividad. Al guardar este código en un archivo, se genera de forma automática en la misma dirección, el archivo BPEL.xml, en el cual se almacenan las direcciones de los partner links involucrados en el proceso de composición.

Figura 43. Ventana BPEL. En este capítulo, la descripción del diseño e implementación de la integración de módulos y sistemas, fue necesaria, ya que su resultado es el prototipo para la composición de servicios Web. Sin embargo, los dos aspectos más importantes en cuanto al diseño e implementación se refiere, corresponden al módulo de composición y las ventanas de configuración. Con estos, se logra la generación de código en BPEL4WS a partir de diagramas de actividad, y la configuración de los partner links y las variables del proceso de composición. La generación de código se relaciona con el plan experimental que se presenta en el siguiente capítulo.

61

Capítulo 5. Plan experimental Para probar que el código BPEL se genera correctamente a partir de diagramas de actividad y que el resultado de su ejecución corresponde a lo modelado, se desarrolló el plan experimental que se presenta en este capítulo, integrado por la hipótesis a probar, el plan de pruebas, el diseño de pruebas y la descripción de los casos de pruebas. En este capítulo, también se presentan los resultados obtenidos de la ejecución de los casos de prueba y el análisis que se realizó en base a ellos. 5.1. Hipótesis a probar

“Es posible modelar estructuras secuenciales, iterativas y condicionales para especificar la interacción entre servicios Web utilizando diagramas de actividad y generar de forma automática el código en BPEL4WS”.

Capítulo 5. Plan experimental

62

5.2. Convención de nombres La convención de nombres que se presenta a continuación será utilizada a través de toda la evaluación del módulo de composición de servicios Web (ver figura 44).

Figura 44. Convención de nombres. 5.3. Documentación de prueba

MCS-PP-XX Plan de pruebas. MCS-DP-XX Especificación de diseño de pruebas. MCS-CP-XX Especificación de los casos de prueba.

5.4. Plan de pruebas MCS-PP-01. Plan de pruebas para el módulo de composición de servicios Web a) Introducción

Este plan de pruebas está basado en el estándar 829-1998 de la IEEE (Institute of Electrical and Electronics Engineers) y cubre el caso de uso generar código en BPEL, a implementar, en el módulo de composición de servicios Web.

El módulo de composición de servicios se encarga de generar el código en BPEL4WS a partir de los diagramas de actividad modelados en el cliente del WS-SIDDOO. Es de interés probar en este módulo que el código se genere correctamente, de acuerdo a los modelos.

Para evaluar el módulo de composición se realizarán 15 pruebas de modelado y composición de servicios Web. Estas tendrán como objetivo demostrar que se lleva a cabo correctamente la composición de servicios a partir de diagramas de actividad de UML (Unified Modeling Language).

En cada una de las pruebas a realizar, se modelará un diagrama que involucre llamadas a métodos de servicios Web utilizando estructuras secuenciales, condicionales y/o iterativas.

Módulo de Composición de Servicios Web

MCS – YY – XX

Tipo de artículo

Número de versión


63

A partir del modelo realizado se generará el código correspondiente en BPEL4WS. Al desplegar este código en un motor para BPEL, se podrá realizar la ejecución del servicio compuesto y evaluar su resultado.

El plan de pruebas contiene los siguientes puntos: elementos de prueba, características a ser probadas, características que no se van a probar, enfoque, criterio aceptado/no aceptado, criterio de suspensión y requisitos de reanudación, liberación de pruebas, requerimientos del sistema, responsabilidades, riesgos y aprobación. b) Elementos de prueba

El presente capítulo contiene un conjunto de casos de prueba que tienen como fin validar y verificar que a partir de un diagrama de actividad se genera correctamente el código en BPEL4WS para la composición de servicios Web.

Para realizar las pruebas es necesario definir los siguientes elementos:

• Servicios Web. Debido a que no existen conjuntos de servicios estándar para pruebas, se implementarán servicios que utilicen valores numéricos para realizar cálculos (ver tabla 2) y serán usados como servicios base en los procesos de composición.

Tabla 2. Servicios Web básicos a usar en la composición.

Nombre del Servicio Características sumaBPEL Cálculo de la suma de dos enteros.

ServicioRestas Cálculo de la resta de dos enteros.

ServicioDivision Cálculo de la división de dos enteros.

ServicioPotencia Cálculo de la potencia de un flotante con exponente entero.

CalculaRaiz Cálculo de la raíz n de un número entero.

VerificaPrimo Verifica si un número entero es primo.

MediaAritmetica Cálculo de la media aritmética de 5 flotantes.

• Diagramas de actividad. Al igual que con los servicios Web, no existe un conjunto

estándar de diagramas que se haya utilizado en trabajos similares. Por lo tanto, estos diagramas serán creados considerando que deben contener estructuras secuenciales, iterativas y/o condicionales para modelar la interacción entre servicios Web, y que estas actividades del modelo deberán estar relacionadas con actividades en BPEL (assign, invoke, receive o reply).

c) Características a ser probadas

La siguiente lista describe las características a ser probadas:

• Generación de código de estructuras secuenciales en BPEL4WS correspondiente al diagrama de actividad modelado en el cliente del WS-SIDDOO.

• Generación de código de estructuras condicionales (de selección simple, doble, múltiple y/o en cascada) en BPEL4WS correspondiente al diagrama de actividad modelado en el cliente del WS-SIDDOO.


64

• Generación de código de estructuras iterativas (while, do_while) en BPEL4WS correspondiente al diagrama de actividad modelado en el cliente del WS-SIDDOO.

• Generación de código a partir de la combinación de estructuras secuenciales, condicionales e iterativas.

• Resultado de la ejecución de documentos BPEL4WS en un motor de ejecución para BPEL.

d) Características que no se van a probar

En el presente plan de pruebas las características que no se van a probar son las siguientes:

• El modelado de diagramas de actividad en el cliente del WS-SIDDOO. • El funcionamiento del cliente del WS-SIDDOO. • El funcionamiento del servicio Web WS-SIDDOO. • El funcionamiento del sistema de búsqueda y selección de servicios Web. • El tiempo de duración de la prueba. • El funcionamiento del motor de ejecución de BPEL.

e) Enfoque

Este plan de pruebas se basará en su totalidad en pruebas del tipo caja negra, donde sólo se considerarán los códigos en BPEL generados a partir de los diagramas de actividad de los casos de prueba y los resultados de su ejecución.

Entre las razones que se cuentan para tomar esta decisión, es que el estudio a realizar es de factibilidad y la restricción del tiempo, ya que las pruebas de caja blanca son más completas pero necesitan mucho tiempo para poder llevarlas a cabo.

f) Criterio aceptado/ no aceptado

Para los casos de prueba del módulo de composición de servicios Web, el criterio aceptado/no aceptado se realizará mediante la evaluación del código generado a partir del diagrama y el cálculo manual del proceso modelado, comparando el resultado con el obtenido utilizando el servicio compuesto.

Se considerará que una prueba ha pasado con éxito cuando los resultados esperados coincidan con los descritos en el caso de prueba. En caso de no coincidencia, se determinará si la discordancia supone un fallo en la validación del módulo de composición y si debe continuarse con los restantes casos de prueba o bien dar por finalizada la validación. g) Criterio de suspensión y requisitos de reanudación

Las pruebas sólo se suspenderán temporalmente cuando un caso de prueba no sea aceptado, inmediatamente se evaluará y corregirá el error. Se volverá a aplicar la prueba al caso hasta que pase el criterio de aceptación.

h) Liberación de pruebas

Para aceptar las pruebas son suficientes los códigos de salida y los resultados de la ejecución de los archivos BPEL4WS especificados en cada caso de prueba del módulo de composición de servicios.


65

i) Requisitos ambientales Las características y propiedades físicas y lógicas requeridas para el ambiente de

pruebas son las siguientes: Equipo:

• Procesador Intel P4 o superior. • 1 GB de memoria RAM o superior. • Mouse. • Teclado.

Sistema Operativo: • Windows XP.

Herramientas y servidores: • Eclipse v. 3.1. • Servidor Systinet v. 6.0 o superior. • Servidor de aplicaciones Apache Tomcat v. 5.5.17. • MySQL Server 5.0. • Servidor para BPEL (Oracle BPEL PM 10.1.2 o superior). • jDeveloper 10.1.2 o superior, que incluya un modelador para BPEL.

Programas de prueba: • Servicios Web desarrollados en java.

j) Responsabilidades

La persona responsable de realizar las pruebas será la ISC. Silvana De Gyvés Avila, quien se encargará de llevar a cabo los diagramas, generar el código en BPEL4WS, ejecutar los archivos resultantes en un motor para BPEL y comparar los resultados obtenidos con los esperados. k) Riesgos

Cabe destacar que esta planificación prevé posibles atrasos. Entre las posibles fuentes de problemas están:

• Atrasos en la generación de casos de prueba. • Caso de prueba incorrecto: es posible que algún caso de prueba esté incorrecto, por lo

tanto las pruebas que serán aplicadas estarán defectuosas o incorrectas. • Atrasos en corrección de errores: se puede presentar el caso en el cual se descubran

errores y/o defectos y no haya tiempo de corregirlos, y menos tiempo habrá para seguir probando.

l) Aprobación

El plan de pruebas debe ser aprobado por la MC. Olivia Fragoso Díaz y el Dr. René Santaolaya Salgado.


66

5.5. Especificación del diseño de pruebas En esta sección se presenta el diseño de pruebas para la generación de código BPEL de estructuras secuenciales, iterativas y condicionales, a partir de diagramas de actividad de UML, y su ejecución. 5.5.1. MCS-DP-01. Diseño de prueba para la generación de código de estructuras secuenciales a) Características a ser probadas

La característica a probar con esta prueba es la generación de código de estructuras secuenciales en BPEL4WS correspondiente al diagrama de actividad modelado y configurado en el cliente del WS-SIDDOO. b) Refinamiento del enfoque

El diseño de esta prueba está basado en diagramas de actividad que modelan la interacción entre diferentes servicios Web. Su objetivo es probar que el código de las estructuras secuenciales que forman el diagrama se genera correctamente.

Para cada prueba, se modelará un diagrama que contenga estructuras secuenciales y actividades en BPEL (assign, invoke, receive y/o reply). Posteriormente, se generará el código correspondiente al modelo y se evaluará por inspección visual utilizando el jDeveloper, ya que este puede visualizar el código BPEL de forma gráfica. c) Identificación de pruebas

Característica de prueba Caso de prueba Generación de código de estructuras secuenciales MCS-CP-01

Generación de código de estructuras secuenciales MCS-CP-08 a 15

d) Criterio aceptado/ no aceptado

El criterio aceptado/no aceptado para probar la generación de código de estructuras secuenciales, se hará mediante la evaluación del código generado a partir del diagrama. En caso de que el diagrama contenga errores de modelado (atribuibles al cliente del WS-SIDDOO), el sistema no será capaz de identificarlos, por lo que el usuario debe realizar una revisión visual del modelo.

Se considerará que una prueba ha pasado con éxito cuando el código en BPEL generado, corresponda al modelo.


67

5.5.2. MCS-DP-02. Diseño de prueba para la generación de código de estructuras condicionales a) Características a ser probadas

La característica a probar con esta prueba es la generación de código de estructuras condicionales en BPEL4WS correspondiente al diagrama de actividad modelado y configurado en el cliente del WS-SIDDOO.

b) Refinamiento del enfoque

El diseño de esta prueba está basado en diagramas de actividad que modelan la interacción entre diferentes servicios Web. Su objetivo es probar que el código de las estructuras condicionales (simples, dobles, múltiples y en cascada) que forman el diagrama se genera correctamente.

Para cada prueba, se modelará un diagrama que contenga estructuras condicionales y actividades en BPEL (assign, invoke, receive y/o reply). Posteriormente, se generará el código correspondiente al modelo y se evaluará por inspección visual utilizando el jDeveloper, ya que este puede visualizar el código BPEL de forma gráfica. c) Identificación de pruebas

Característica de prueba Caso de prueba Generación de código de estructuras condicionales simples MCS-CP-02

Generación de código de estructuras condicionales dobles MCS-CP-03

Generación de código de estructuras condicionales múltiples MCS-CP-04

Generación de código de estructuras condicionales en cascada MCS-CP-05

Generación de código de estructuras condicionales MCS-CP-08 a 15


El criterio aceptado/no aceptado para probar la generación de código de estructuras condicionales, se hará mediante la evaluación del código generado a partir del diagrama. En caso de que el diagrama contenga errores de modelado (atribuibles al cliente del WS-SIDDOO), el sistema no será capaz de identificarlos, por lo que el usuario debe realizar una revisión visual del modelo.

Se considerará que una prueba ha pasado con éxito cuando el código en BPEL generado, corresponda al modelo. 5.5.3. MCS-DP-03. Diseño de prueba para la generación de código de estructuras iterativas a) Características a ser probadas

La característica a probar con esta prueba es la generación de código de estructuras iterativas en BPEL4WS, correspondiente al diagrama de actividad modelado y configurado en el cliente del WS-SIDDOO.


68

b) Refinamiento del enfoque El diseño de esta prueba está basado en diagramas de actividad que modelan la

interacción entre diferentes servicios Web. Su objetivo es probar que el código de las estructuras iterativas (while y do_while) que forman el diagrama se genera correctamente.

Para cada prueba, se modelará un diagrama que contenga estructuras iterativas y actividades en BPEL (assign, invoke, receive y/o reply). Posteriormente, se generará el código correspondiente al modelo y se evaluará por inspección visual utilizando el jDeveloper, ya que este puede visualizar el código BPEL de forma gráfica. c) Identificación de pruebas

Características de prueba Caso de prueba Generación de código de estructuras iterativas while MCS-CP-06

Generación de código de estructuras iterativas do_while MCS-CP-07

Generación de código de estructuras iterativas MCS-CP-08 a 15


El criterio aceptado/no aceptado para probar la generación de código de estructuras iterativas (while y do_while), se hará mediante la evaluación del código generado a partir del diagrama. En caso de que el diagrama contenga errores de modelado (atribuibles al cliente del WS-SIDDOO), el sistema no será capaz de identificarlos, por lo que el usuario debe realizar una revisión visual del modelo.

Se considerará que una prueba ha pasado con éxito cuando el código en BPEL generado, corresponda al modelo. 5.5.4. MCS-DP-04. Diseño de prueba para la ejecución de código en BPEL4WS a) Características a ser probadas

Las características a probar con esta prueba son el despliegue y resultado de la ejecución del código en BPEL generado a partir de un diagrama de actividad modelado y configurado en el cliente del WS-SIDDOO. b) Refinamiento del enfoque

El diseño de esta prueba está basado en diagramas de actividad que modelan la interacción entre diferentes servicios Web. Su objetivo es probar que el código generado a partir del diagrama se despliega y ejecuta correctamente en un motor para BPEL.

Para cada prueba, se modelará un diagrama que contenga estructuras secuenciales, condicionales y/o iterativas, y actividades en BPEL (assign, invoke, receive y/o reply). Posteriormente, se generará el código correspondiente al modelo, se guardará en la carpeta de proyectos del jDeveloper, será desplegado en el servidor BPEL PM de Oracle y se probará su ejecución desde la consola del servidor. El resultado de la ejecución del proceso en el servidor será comparado con el resultado de la operación efectuada de forma manual.


69

c) Identificación de pruebas

Característica de prueba Caso de prueba Ejecución del código BPEL generado a partir de los modelos MCS-CP-01 a 15


El criterio aceptado/no aceptado se realizará mediante el despliegue y la ejecución del código del servicio compuesto generado a partir del diagrama y el cálculo manual del proceso modelado, comparando los resultados obtenidos. En caso de que el diagrama contenga errores de modelado (atribuibles al cliente del WS-SIDDOO), el sistema no será capaz de identificarlos, por lo que el usuario debe realizar una revisión visual del modelo.

Se considerará que una prueba ha pasado con éxito cuando los resultados obtenidos en la ejecución, coincidan con los descritos en el caso de prueba. En caso de no coincidencia, se determinará si la discordancia supone un fallo en la validación del módulo de composición y si debe continuarse con los restantes casos de prueba o bien dar por finalizada la validación. 5.6. Especificación de casos de prueba Especificación de casos para probar la generación de código de estructuras secuenciales, iterativas y condicionales a partir de diagramas de actividad de UML. En esta sección se describe el propósito de cada uno de los casos diseñados para probar el módulo de composición de servicios Web, quedando la definición completa de sus características y resultado esperado en el Anexo E de este documento. Caso de prueba MCS-CP-01

Verificar la generación de código en BPEL4WS correspondiente a estructuras secuenciales y la ejecución del código total generado, de acuerdo a las especificaciones de diseño de pruebas MCS-DP-01 y MCS-DP-04.

La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, calcule la suma de tres números enteros. Caso de prueba MCS-CP-02

Verificar la generación de código en BPEL4WS correspondiente a estructuras condicionales simples y la ejecución del código total generado, de acuerdo a las especificaciones de diseño de pruebas MCS-DP-02 y MCS-DP-04.

La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, calcule la media de cinco flotantes, evalúe el resultado utilizando una estructura condicional simple y envíe al usuario un mensaje de acuerdo a la evaluación. Caso de prueba MCS-CP-03

Verificar la generación de código en BPEL4WS correspondiente a estructuras condicionales dobles y la ejecución del código total generado, de acuerdo a las especificaciones de diseño de pruebas MCS-DP-02 y MCS-DP-04.


70

La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, calcule la media de cinco flotantes, evalúe el resultado utilizando una estructura condicional doble y envíe al usuario un mensaje de acuerdo a la evaluación. Caso de prueba MCS-CP-04

Verificar la generación de código en BPEL4WS correspondiente a estructuras condicionales múltiples y la ejecución del código total generado, de acuerdo a las especificaciones de diseño de pruebas MCS-DP-02 y MCS-DP-04.

La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, calcule la media de tres enteros utilizando servicios de suma y división, evalúe el resultado con una estructura condicional múltiple y envíe al usuario un mensaje de acuerdo a la evaluación. Caso de prueba MCS-CP-05

Verificar la generación de código en BPEL4WS correspondiente a estructuras condicionales en cascada y la ejecución del código total generado, de acuerdo a las especificaciones de diseño de pruebas MCS-DP-02 y MCS-DP-04.

La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, eleve un número flotante a la n-esima potencia (siendo el exponente un entero positivo) y envíe al usuario el resultado. El proceso será modelado utilizando estructuras condicionales en cascada. Caso de prueba MCS-CP-06

Verificar la generación de código en BPEL4WS correspondiente a estructuras iterativas de tipo while y la ejecución del código total generado, de acuerdo a las especificaciones de diseño de pruebas MCS-DP-03 y MCS-DP-04.

La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, efectúe la multiplicación de dos números enteros positivos y envíe al usuario el resultado. Caso de prueba MCS-CP-07

Verificar la generación de código en BPEL4WS correspondiente a estructuras iterativas de tipo do_while y la ejecución del código total generado, de acuerdo a las especificaciones de diseño de pruebas MCS-DP-03 y MCS-DP-04.

La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, identifique los números primos que se encuentran dentro de un rango de enteros proporcionados por el usuario. El proceso se modelará con una estructura iterativa do_while y una condicional simple. Caso de prueba MCS-CP-08

Verificar la generación de código en BPEL4WS correspondiente a estructuras secuenciales, condicionales e iterativas, y la ejecución del código total generado, de acuerdo a las especificaciones de diseño de pruebas MCS-DP-01, MCS-DP-02, MCS-DP-03 y MCS-DP-04.

La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, eleve un número entero a la n-esima potencia (siendo el exponente un entero positivo) y evalúe el resultado. Si éste es mayor que 100, obtenga su n-sima raíz, si no, le sume unidades hasta


71

alcanzar el 100. El proceso se modelará utilizando estructuras secuenciales, condicionales dobles e iterativas de tipo while. Caso de prueba MCS-CP-09

Verificar la generación de código en BPEL4WS correspondiente a estructuras secuenciales y condicionales, y la ejecución del código total generado, de acuerdo a las especificaciones de diseño de pruebas MCS-DP-01, MCS-DP-02 y MCS-DP-04.

La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, realice una operación aritmética de acuerdo a la entrada proporcionada por el usuario. El proceso será modelado utilizando estructuras condicionales dobles y múltiples en cascada. Caso de prueba MCS-CP-10

Verificar la generación de código en BPEL4WS correspondiente a estructuras secuenciales e iterativas, y la ejecución del código total generado, de acuerdo a las especificaciones de diseño de pruebas MCS-DP-01, MCS-DP-03 y MCS-DP-04.

La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, calcule la media cuadrática de un conjunto de números proporcionados por el usuario. El proceso será modelado utilizando estructuras secuenciales e iterativas de tipo while. Caso de prueba MCS-CP-11


La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, calcule la media geométrica de un conjunto de números positivos proporcionados por el usuario. El proceso será modelado utilizando estructuras secuenciales, condicionales dobles e iterativas de tipo do_while. Caso de prueba MCS-CP-12


La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, calcule la varianza de un conjunto de números proporcionados por el usuario. El proceso será modelado utilizando estructuras secuenciales, condicionales dobles e iterativas de tipo while. Caso de prueba MCS-CP-13

Verificar la generación de código en BPEL4WS correspondiente a estructuras secuenciales e iterativas, y la ejecución del código total generado, de acuerdo a las especificaciones de diseño de pruebas MCS-DP-01, MCS-DP-03 y MCS-DP-04.

La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, realice la suma entre elementos de dos arreglos de enteros proporcionados por el usuario. El proceso será modelado utilizando estructuras secuenciales e iterativas de tipo while.


72

Caso de prueba MCS-CP-14 Verificar la generación de código en BPEL4WS correspondiente a estructuras

secuenciales, condicionales e iterativas, y la ejecución del código total generado, de acuerdo a las especificaciones de diseño de pruebas MCS-DP-01, MCS-DP-02, MCS-DP-03 y MCS-DP-04.

La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, multiplique elementos de un arreglo de enteros proporcionado por el usuario. El proceso será modelado utilizando estructuras secuenciales, condicionales múltiples e iterativas de tipo do_while. Caso de prueba MCS-CP-15


La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, realice la suma de los elementos de un arreglo de enteros proporcionado por el usuario. El proceso será modelado utilizando estructuras secuenciales, condicionales dobles, condicionales en cascada, iterativas de tipo do_while e iterativas de tipo while. 5.7. Resultados de la ejecución del plan experimental Los resultados de la ejecución de los casos de prueba, de acuerdo a los diseños de pruebas MCS-DP-01, MCS-DP-02 y MCS-DP-03, corresponden a código en BPEL4WS; y del MCS-DP-04, al despliegue y resultado de la ejecución del código en el servidor BPEL PM de Oracle.

Tabla 3. Resultados de la ejecución del plan experimental 4.

Generación de código de estructuras Identificador

Secuenciales Condicionales Iterativas Despliegue Ejecución

MCS-CP-01 --- --- MCS-CP-02 --- MCS-CP-03 ---

MCS-CP-04 --- MCS-CP-05 --- MCS-CP-06 --- MCS-CP-07 --- MCS-CP-08 MCS-CP-09 ---

MCS-CP-10 --- MCS-CP-11

4 Iconos utilizados en la tabla: = correcto = incorrecto --- = no aplica


73

MCS-CP-12 MCS-CP-13 ---

MCS-CP-14 MCS-CP-15

En la tabla 3 se presenta el resumen de los resultados de la evaluación visual del

código generado por el módulo de composición de servicios Web; el despliegue del código después de haber sido editado por el usuario; y su ejecución en el servidor, tomando en cuenta los resultados esperados descritos en cada caso de prueba. 5.8. Análisis de resultados En todos los casos de prueba, a excepción del caso MCS-CP-13, la generación del código BPEL4WS correspondiente a las estructuras que forman los modelos se llevó a cabo correctamente. En el caso MCS-CP-13, los ciclos anidados no se dibujaron de acuerdo a las características de modelado descritas en el capítulo 4 y el código generado para las estructuras iterativas, no correspondió al diagrama.

En los casos MCS-CP-03 y MCS-CP-10, se presentaron errores al momento de validar los archivos BPEL, por lo que no fue posible desplegarlos en el servidor. Y en el caso MCS-CP-09, el resultado de la ejecución no fue el esperado. Esto se debió a defectos insertados por el usuario al momento de configurar los elementos del proceso. Entre estos defectos se pueden mencionar:

• Configuración incorrecta de roles de los partner links. • Asignación de tipos incompatibles entre elementos de las variables. • Definición incorrecta de expresiones lógicas para evaluación de estructuras

condicionales e iterativas. • Definición incorrecta de expresiones XPath para actividades BPEL de asignación.

Después de identificar y eliminar los defectos mencionados, se generó, modificó y

validó nuevamente el código para cada uno de los procesos que presentaron errores. Con esto, el modelador del jDeveloper permitió desplegar y probar la ejecución de cada uno de los procesos desde la consola del servidor de BPEL.

Al terminar la ejecución de los casos de prueba, podemos afirmar que un diagrama de actividad permite especificar la interacción entre métodos de diferentes servicios Web utilizando estructuras secuenciales, iterativas y condicionales. Sin embargo, para generar código BPEL ejecutable, es necesario definir elementos del proceso que no se pueden integrar en el diagrama, tales como los partner links y las variables.

Es importante mencionar, que si el modelado de las estructuras no se efectúa de acuerdo a las características descritas en el capítulo 4 de este documento (caso MCS-CP-13), el código puede no representar la estructura esperada, no ser ejecutable o generar un resultado


74

inesperado al momento de ejecutar el proceso. Quedando toda la responsabilidad del modelado y la configuración del modelo en el usuario.

75

Capítulo 6. Conclusiones 6.1. Conclusiones El uso de servicios Web y la construcción de servicios compuestos, son temas actuales y de gran importancia para el desarrollo de aplicaciones de cómputo distribuidas que trabajen sobre Internet. El objetivo de este trabajo fue “evitar que el desarrollador de aplicaciones escriba el código de interacción entre las operaciones de los servicios Web involucrados en un proceso de composición, mediante la generación automática de código de composición, a partir de diagramas de actividad de UML modelados en el cliente del WS-SIDDOO”.

Para diseñar una estrategia que nos permitiera alcanzar este objetivo, fue necesario llevar a cabo una etapa de análisis, en la que se realizaron distintos estudios detallados sobre los sistemas y módulos a integrar, el lenguaje BPEL4WS, los diagramas de actividad y las tecnologías a utilizar. A partir de ésta, se generó un modelo de solución, que se implementó integrando el sistema de búsqueda y selección de servicios Web, el módulo analizador de

Capítulo 6. Conclusiones

76

documentos WSDL del WS-Compositor y el módulo de composición (desarrollado en este trabajo) con la interfaz del WS-SIDDOO.

En el prototipo, los modelos de interacción entre las operaciones de los servicios se realizan a nivel de detalle, utilizando diagramas de actividad, donde cada símbolo de actividad trabaja como un estado de acción, es decir, es atómico y no permite transiciones mientras esta activo y representa una actividad en el lenguaje BPEL4WS.

Para probar el desempeño del módulo de composición generado y verificar que el objetivo de este trabajo se cumpliera, se ejecutaron 15 casos de prueba en los que se modelaron diferentes servicios compuestos. La generación de código fue exitosa en 14 de ellos. En un caso (MCS-CP-13), el código generado no correspondió al modelo, ya que el diagrama no se realizó de acuerdo a las especificaciones de construcción de los modelos de ciclos anidados descritas en el capítulo 4.

En dos casos, se presentaron errores al momento de validar los archivos BPEL; y en otro, el resultado de la ejecución no fue el esperado. Esto se debió a que el usuario configuró de forma incorrecta algunos elementos del proceso (actividades o partner links).

Al analizar los resultados que arrojaron las pruebas realizadas, se confirmó la hipótesis planteada y se demostró que, los diagramas de actividad permiten modelar estructuras secuenciales, condicionales e iterativas que especifican la interacción entre operaciones de servicios Web, dentro de un proceso de composición (a nivel de orquestación), y que a partir de un diagrama de actividad es posible generar de forma automática el código en BPEL4WS correspondiente al modelo.

Sin embargo, un diagrama de actividad no puede representar todos los elementos del lenguaje BPEL, ya que por su estructura, sólo permite modelar la secuencia de acciones (actividades) y condiciones que toman lugar dentro de un proceso, dejando fuera del modelo a los partner links, las variables, los conjuntos de correlación y los manejadores de eventos, fallos y compensación.

Para que el código BPEL generado sea ejecutable, requiere de la definición de partner links y variables, además de la actividad principal del proceso, por lo que fue necesario definir e implementar una estrategia para generar estos elementos, que no corresponden a símbolos de la notación de UML, e integrarlos con el diagrama.

Además, para ejecutar este código y verificar que proporcionara los resultados esperados, fue necesario buscar y descargar un motor de ejecución de BPEL de la red. Lo que ocasionó una dependencia entre el prototipo y el motor para BPEL de Oracle.

El prototipo resultado muestra algunas ventajas en comparación con los trabajos relacionados presentados en el capítulo 1. La primera, es que utiliza diagramas de actividad de UML, estos permiten el modelado de flujos de trabajo y soportan la mayoría de los patrones considerados por los WFMS (WorkFlow Management System), mientras que otras notaciones como los diagramas de flujo no pueden dar ese soporte; la segunda, es que el modelado se realiza de forma gráfica por medio de una notación estándar, lo que facilita el entendimiento de la especificación de interacción entre los servicios; y la tercera, es que la gramática que valida la creación de los diagramas de actividad está implementada como servicio Web.

Sin embargo, el prototipo desarrollado también presenta ciertas desventajas, la más importante va relacionada con la forma en que el desarrollador realiza el diagrama y configura las actividades, ya que sólo se validan las conexiones entre elementos, quedando la lógica de la estructura del modelo bajo la responsabilidad del usuario.


77

La falta de un mecanismo de validación y retroalimentación de la estructura del modelo, que permita al usuario saber si el diagrama es incorrecto, puede permitir que se generen resultados inesperados o errores al momento de ejecutar el proceso en el servidor.

6.2. Aportaciones La aportación principal de este trabajo de tesis es el módulo de composición de servicios Web, que como se demostró con la ejecución del plan experimental, permite generar código en BPEL4WS a partir de diagramas de actividad modelados y configurados en el cliente del WS-SIDOO.

Entre otras aportaciones se encuentran:

• El prototipo resultado de la integración de sistemas que permite la búsqueda, selección y composición de servicios Web, y utiliza diagramas de actividad para modelar el proceso.

• Las correspondencias para el mapeo entre los elementos de los diagramas de actividad y los elementos del lenguaje BPEL4WS.

6.3. Trabajo futuro Para facilitar el modelado de la interacción entre las operaciones de los servicios Web, se propone como trabajo futuro mejorar la interfaz al usuario (cliente del WS-SIDDOO), de manera que permita relacionar condiciones con los rombos de selección, que sea flexible al momento de mover los elementos del diagrama; y agregar un mecanismo de validación de la estructura del modelo y retroalimentación, para prevenir la inserción de errores durante la creación de los mismos.

También se pueden agregar extensiones a la notación de los diagramas de actividad, de tal forma que permitan representar manejadores de fallas y compensación, para tener modelos de proceso más completos, con respecto a la especificación del lenguaje.

Para resolver el problema de la dependencia que tiene el prototipo desarrollado con respecto al motor de ejecución de BPEL de Oracle, sería conveniente el desarrollo de un motor de ejecución propietario.

En el módulo de composición, se propone implementar algoritmos que habiliten la generación de código de estructuras que representen concurrencia. En las ventanas de configuración, se propone agregar las actividades básicas que no fueron implementadas (compensate, empty, throw y wait). Con esto se tendrían todas las actividades (básicas y estructuradas) que puede tener un proceso en BPEL de acuerdo a la especificación 1.1.

Al final de la implementación de este trabajo, se desarrolló un módulo, formado por dos clases, que permite crear de forma automática un documento WSDL en base a características proporcionadas por el usuario. El cual está limitado a cinco tipos de datos primitivos, por lo que se recomienda ampliarlos para la definición de nuevo servicios compuestos.


78

También se propone como trabajo futuro, utilizar para el modelado de la composición de servicios una notación propia del modelado de procesos de negocio, como la BPMN (Business Process Modeling Notation) y realizar un estudio comparativo entre ambos prototipos.

Finalmente, se propone realizar un estudio semiótico sobre los íconos de la notación de los diagramas de actividad, para determinar el impacto que tienen y la forma en que son asimilados por parte de los usuarios.

79

Anexo A Ejemplo de código BPEL4WS En este anexo se presenta un ejemplo de código en BPEL4WS para las secciones de partnerlinks y variables, y las actividades básicas (assign, invoke, receive y reply) implementadas en este trabajo de tesis, descritas en el capítulo 3.

Anexo A. Ejemplo de código BPEL4WS

80

En la figura 45 se presenta el código de un proceso en BPEL4WS formado por las cuatro actividades básicas implementadas en este trabajo. Dentro éste, se encuentran las definiciones de los partner links, las variables y la actividad principal (que representa el orden de ejecución de los métodos de los servicios componente).

<?xml version = '1.0' encoding = 'UTF-8' ?> <process name = 'AnexoA' targetNamespace = 'http://xmlns.oracle.com/AnexoA' xmlns = 'http://schemas.xmlsoap.org/ws/2003/03/busi ness-process/' xmlns:xp20 = 'http://www.oracle.com/XSL/Transform/java/oracle.ti p.pc.services.functions.Xpath20' xmlns:bpws = 'http://schemas.xmlsoap.org/ws/2003/03 /business-process/' xmlns:ldap = 'http://schemas.oracle.com/xpath/exten sion/ldap' xmlns:xsd = 'http://www.w3.org/2001/XMLSchema' xmlns:ora = 'http://schemas.oracle.com/xpath/extens ion' xmlns:ns1 = 'http://xmlns.oracle.com/CalculaPotenci a' xmlns:ns2 = 'http://xmlns.oracle.com/servicioMediaG eometrica' xmlns:ns3 = 'http://xmlns.oracle.com/ServicioVarian za'>  <partnerLinks> <partnerLink name='PL_CalculaPotencia' partnerLin kType ='ns1:CalculaPotencia' partnerRole='CalculaPotenciaProveedor' myRole='C alculaPotenciaSolicitante'/> <partnerLink name ='PL_servicioMediaGeometrica' p artnerLinkType='ns2: servicioMediaGeometrica' partnerRole ='servicioM ediaGeometricaProveedor' myRole='servicioMediaGeometricaProveedor' /> <partnerLink name='PL_ServicioVarianza' PartnerLi nkType='ns3:ServicioVarianza' partnerRole='ServicioVarianzaProveedor' myRole = 'ServicioVarianzaProveedor'/> </partnerLinks>  <variables> <variable name ='Invoke_inicio_VariableEntrada' messageType='ns1:CalculaPotenciaRequestMessage'/ > <variable name ='Receive_inicio_Variable' messageType ='ns1:CalculaPotenciaRequestMessage' /> <variable name ='Reply_process_Variable' messageType ='ns3:ServicioVarianzaResponseMessag e'/> </variables>  <sequence> <receive name ='Receive' partnerLink ='PL_Calcul aPotencia' portType ='ns1:CalculaPotencia' operation ='inicio' va riable ='Receive_inicio_Variable' createInstance ='y es'/> <assign name ='Assign'> <copy> <from expression = "number(3)"/> <to variable ='Reply_process_Variable' par t='payload' query ='/ns3:ServicioVarianzaVarSalida/ns3:resul tado'/> </copy> </assign> <invoke name ='Invoke' partnerLink ='PL_CalculaP otencia' portType ='ns1:CalculaPotencia' operation ='inicio' in putVariable ='Invoke_inicio_VariableEntrada'/> <reply name ='Reply' partnerLink ='PL_ServicioVa rianza' portType ='ns3:ServicioVarianza' operation ='process' variable ='Reply_process_Variable'/> </sequence> </process>

Figura 45. Elementos y actividades básicas del BPEL4WS. En este ejemplo, podemos ver la relación que existe entre los partner links, las

variables y las actividades, dentro de un proceso de composición. Es importante mencionar, que no existe una secuencia lógica entre las actividades de este proceso, por lo que al compilar el código se generarían errores debido a las inconsistencias que presenta.

81

Anexo B Escenarios para los casos de uso del sistema En este anexo se muestran las plantillas de escenarios de los casos de uso del sistema presentados en el capítulo 4 de esta tesis: CU_1.Buscar y seleccionar servicios Web, CU_2.Modelar interacción entre servicios Web, CU_3.Generar código en BPEL y CU_4.Analizar WSDL.

Anexo B. Escenarios para los casos de uso del sistema

82

ID : CU_1 Nombre de caso

de uso: Buscar y seleccionar servicios Web

Creador: Silvana De Gyvés Avila Ultima modificación:

Silvana De Gyvés Avila

Fecha de creación:

29/01/07 Fecha de última modificación:

15/02/07

Actores: Desarrollador de aplicaciones. Descripción: El desarrollador realiza una consulta para recuperar descripciones

de servicios con funcionalidades específicas. Precondiciones: 1. El desarrollador debe tener clara la funcionalidad deseada del

servicio o los servicios a buscar. Poscondiciones: 1. Conjunto de nombres y direcciones de los documentos WSDL

de los servicios seleccionados por el desarrollador. Escenario principal de

éxito: 1. El desarrollador proporciona la funcionalidad deseada en la

interfaz del sistema de búsqueda y selección de servicios Web. 2. Se establece comunicación con la UDDI y se obtienen las

descripciones de los servicios indicados. 3. La interfaz presenta los resultados obtenidos. 4. El desarrollador selecciona el o los servicios que satisfacen sus

requerimientos. Escenario de fracaso (1): 1. El desarrollador proporciona una descripción de las

características funcionales que no es consistente en el dominio que se está trabajando.

Escenario de fracaso (2): 1. El desarrollador proporciona la funcionalidad deseada en la interfaz del sistema de búsqueda y selección de servicios Web.

2. Se establece comunicación con la UDDI, pero no existen servicios con al menos una de las características deseadas.

3. Se presenta el mensaje: “No se encontraron servicios con esa descripción”.

Includes: Suposiciones: 1. Se supone la existencia de las descripciones de la funcionalidad

de los servicios estructuradas y validadas en la interfaz al usuario.


de uso: Modelar interacción entre servicios Web



Fecha de creación:


15/02/07

Actores: Desarrollador de aplicaciones. Descripción: El desarrollador modela un diagrama de actividad en el cliente del

WS-SIDDOO y asigna a las actividades, operaciones relacionadas


83

con los servicios Web previamente seleccionados. Precondiciones: 1. El desarrollador ha seleccionado los servicios Web a componer

en la interfaz del sistema de búsqueda y selección de servicios. 2. El desarrollador tiene clara la funcionalidad deseada del servicio

compuesto. Poscondiciones: 1. Un diagrama de actividad que contiene llamadas a distintos

métodos de servicios Web y la lógica que controla la interacción entre ellos.

2. Vectores que almacenan la información correspondiente al diagrama.

Escenario principal de éxito:

1. El desarrollador dibuja los elementos del diagrama. 2. Asigna a las actividades del modelo actividades de BPEL,

partner links, métodos y variables, de acuerdo a los resultados obtenidos por el módulo analizador.

3. El desarrollador dibuja las conexiones entre los elementos. 4. El cliente del WS-SIDDOO envía la conexión entre elementos al

servicio Web. 5. El servicio valida la conexión.

Escenario de fracaso: 1. El desarrollador dibuja los elementos del diagrama. 2. Asigna a las actividades del modelo actividades de BPEL,

partner links, métodos y variables, de acuerdo a los resultados obtenidos por el módulo analizador.

3. El desarrollador dibuja una conexión inadecuada entre los elementos del diagrama.

4. El cliente del WS-SIDDOO envía la conexión entre elementos al servicio Web.

5. El servicio invalida esa conexión. 6. No se dibuja la conexión y se envía un mensaje de error al

desarrollador. Includes: CU_4. Analizar WSDL

Suposiciones: 1. Existe una conexión a Internet. 2. Los servicios están disponibles.


de uso: Generar código en BPEL



Fecha de creación:


15/02/07

Actores: Desarrollador de aplicaciones. Descripción: El módulo de composición recibe el vector de conexiones del

diagrama, a partir del cual genera código en BPEL4WS correspondiente a la composición de los métodos de los servicios que intervienen en el modelo.


84

Precondiciones: 1. Se ha terminado el modelado y configuración del diagrama de actividad que especifica la interacción entre los servicios Web.

Poscondiciones: 1. Se genera código en BPEL4WS correspondiente al modelo. Escenario principal de

éxito: 1. El desarrollador selecciona componer servicios en el cliente del

WS-SIDDOO. 2. El cliente del WS-SIDDOO envía el vector de conexiones del

diagrama al módulo de composición. 3. Se recorren el vector de conexiones y los vectores que

almacenan variables, partner links y espacios de nombre. 4. El módulo de composición genera el código en BPEL y lo envía

al cliente del WS-SIDDOO. 5. El cliente del WS-SIDDOO presenta el BPEL al desarrollador.

Escenario de fracaso (1): 1. El desarrollador selecciona componer servicios en el cliente del WS-SIDDOO.

2. El cliente del WS-SIDDOO envía el vector de conexiones del diagrama al módulo de composición.

3. Se recorren el vector de conexiones y los vectores que almacenan variables, partner links y espacios de nombre.

4. El diagrama de actividad contiene estructuras que habilitan la concurrencia.

5. No se genera el código correspondiente a la concurrencia. 6. El módulo de composición genera código incorrecto en BPEL y

lo envía al cliente del WS-SIDDOO. 7. El cliente del WS-SIDDOO presenta el BPEL al desarrollador.

Escenario de fracaso (2):

1. El desarrollador selecciona componer servicios en el cliente del WS-SIDDOO.

2. El cliente del WS-SIDDOO envía el vector de conexiones del diagrama al módulo de composición.

3. El diagrama de actividad está incompleto. 4. No se puede recorrer el vector de conexiones. 5. No se puede generar código.

Includes: CU_5. Generar código encabezado. CU_6. Generar código de estructuras secuenciales. CU_7. Generar código de estructuras condicionales. CU_8. Generar código de estructuras iterativas.

Suposiciones:


de uso: Analizar WSDL



Fecha de creación:


15/02/07

Actores: CU_2. Modelar interacción entre servicios Web.


85

Descripción: El módulo analizador recibe la dirección del documento WSDL del partner link (servicio Web) seleccionado en la ventana de configuración del cliente del WS-SIDDOO y obtiene los datos necesarios para la composición.

Precondiciones: 1. El desarrollador ha seleccionado la actividad a configurar y el servicio Web a relacionar.

Poscondiciones: 1. Una lista de características correspondientes al servicio Web seleccionado (operaciones, mensajes y partner links).


1. La ventana de configuración (cliente del WS-SIDDOO) envía al módulo analizador de WSDL la dirección de la descripción del partner link seleccionado.

2. El módulo analiza el documento WSDL del servicio (ligado a un partner link) y obtiene los datos necesarios para la composición.

3. El cliente del WS-SIDDOO recupera los datos del servicio. Escenario de fracaso: 1. La ventana de configuración (cliente del WS-SIDDOO) envía al

módulo analizador de WSDL la dirección de la descripción del partner link seleccionado.

2. Se genera un error debido a que la dirección es incorrecta. 3. El módulo envía un mensaje de error al cliente del WS-

SIDDOO. Includes:

Suposiciones: 1. Existe una conexión a Internet. 2. Los servicios están disponibles. 3. Los documentos WSDL de los servicios Web contienen la

definición de partner links.

86

Anexo C Escenarios para los casos de uso del módulo de composición En este anexo se muestran las plantillas de escenarios de los casos de uso del módulo de composición de servicios Web presentados en el capítulo 4 de esta tesis: CU_5.Generar código de encabezado, CU_6.Generar código de estructuras secuenciales, CU_7.Generar código de estructuras condicionales y CU_8.Generar código de estructuras iterativas.

Anexo C. Escenarios para los casos de uso del módulo de composición

87


de uso: Generar código de encabezado



Fecha de creación:


25/07/07

Actores: Cliente del WS-SIDDOO. Descripción: El módulo de composición genera el código en BPEL para la

etiqueta process, la definición de los partner links y variables utilizados en la composición.

Precondiciones: 1. Se han definido y configurado todas las variables y los partner links del proceso.

2. La clase amb_visual del cliente del WS-SIDDOO creó un objeto de la clase CGeneraBPEL y le ha enviado el vector de conexiones.

Poscondiciones: 1. Código en BPEL correspondiente a la definición de las variables, los partner links y la etiqueta process.


1. Se solicita al usuario el nombre del proceso. 2. Se obtienen las definiciones de los espacios de nombres de los

servicios almacenados en el vector TNS y genera el código de la etiqueta process.

3. Se obtienen las definiciones de los partner links almacenados en el vector PL y se genera el código correspondiente.

4. Se obtienen las definiciones de las variables almacenadas en el vector variables y se genera el código correspondiente.

Escenario de fracaso: 1. Se solicita al usuario el nombre del proceso. 2. Se obtienen las definiciones de los espacios de nombres de los

servicios almacenados en el vector TNS y genera el código de la etiqueta process.

3. Se obtienen las definiciones de los partner links almacenados en el vector PL.

4. Un servicio Web de los utilizados en el proceso no está disponible.

5. Se genera código incorrecto en BPEL y se envía un mensaje de error.

Includes: Suposiciones: 1. Existe una conexión a Internet.


de uso: Generar código de estructuras secuenciales



Fecha de 23/02/07 Fecha de última 25/07/07


88

creación: modificación: Actores: Cliente del WS-SIDDOO.

Descripción: Se insertan etiquetas de secuencia en el código BPEL. Precondiciones: 1. Se definieron todas las actividades y estructuras del proceso.

2. Se terminó el modelado y configuración del diagrama de actividad que especifica la interacción entre los servicios Web.


Poscondiciones: 1. Código en BPEL con etiquetas que indican secuencia. Escenario principal de

éxito: 1. El módulo recorre el vector de conexiones. 2. Si encuentra el inicio del proceso, de un ciclo o de una condición

(rama de una condicional), agrega una etiqueta <sequence> al código BPEL después de la etiqueta de la estructura encontrada.

3. Si encuentra una actividad o estructura, evalúa su contenido para generar el código correspondiente en BPEL.

4. Si encuentra el fin del proceso, de ciclo o de condición, agrega una etiqueta </sequence> al código BPEL antes de la etiqueta de la estructura encontrada.

Escenario de fracaso (1): 1. El módulo recorre el vector de conexiones. 2. Si encuentra el inicio del proceso, de un ciclo o de una

condición, agrega una etiqueta <sequence> al código BPEL. 3. Encuentra una actividad configurada de forma incorrecta, evalúa

su contenido y genera código incorrecto en BPEL. 4. Si encuentra el fin del proceso, de ciclo o de condición, agrega

una etiqueta </sequence> al código BPEL. Escenario de fracaso (2): 1. El módulo recorre el vector de conexiones.

2. Falta alguna relación en el diagrama. 3. No se puede recorrer todo el vector. 4. El código BPEL queda incompleto.

Includes: Suposiciones: 1. Todas las actividades fueron configuradas.


de uso: Generar código de estructuras condicionales



Fecha de creación:


26/07/07

Actores: Cliente del WS-SIDDOO. Descripción: Se insertan etiquetas de condición en el código BPEL.

Precondiciones: 1. Se definieron todas las actividades y estructuras del proceso. 2. Se terminó el modelado y configuración del diagrama de

actividad que especifica la interacción entre los servicios Web.


89


Poscondiciones: 1. Código en BPEL con etiquetas que definen estructuras condicionales.


1. El módulo recorre el vector de conexiones. 2. Si encuentra un rombo que define el inicio de una estructura

condicional, agrega una etiqueta <switch> al código BPEL. 3. Por cada opción de la condicional agrega una etiqueta <case>. 4. Evalúa la secuencia de actividades o estructuras dentro de cada

opción, al terminar, agrega la etiqueta </case>. 5. Si encuentra un rombo que define el fin de la estructura

condicional, o un símbolo de fin, agrega la etiqueta </switch> al código BPEL.

Escenario de fracaso: 1. El módulo recorre el vector de conexiones. 2. Falta alguna relación en el diagrama. 3. No se puede recorrer todo el vector. 4. El código BPEL queda incompleto.

Includes: Suposiciones: 1. Todas las actividades fueron configuradas.

2. Todas las condicionales terminan en un rombo de unión (merge) o en un símbolo de fin.

3. Las condicionales en cascada terminan en rombos de unión.


de uso: Generar código de estructuras iterativas



Fecha de creación:


26/07/07

Actores: Cliente del WS-SIDDOO. Descripción: Se insertan etiquetas de iteración en el código BPEL.

Precondiciones: 1. Se definieron todas las actividades y estructuras del proceso. 2. Se terminó el modelado y configuración del diagrama de

actividad que especifica la interacción entre los servicios Web. 3. La clase amb_visual del cliente del WS-SIDDOO creó un objeto

de la clase CGeneraBPEL y le ha enviado el vector de conexiones.

Poscondiciones: 1. Código en BPEL con etiquetas que definen estructuras iterativas. Escenario principal de

éxito: 1. El módulo recorre el vector de conexiones. 2. Si encuentra un rombo que define el inicio de una estructura

iterativa de tipo while, agrega una etiqueta <while> al código BPEL.

3. Evalúa la secuencia de actividades o estructuras dentro del ciclo.


90

4. Encuentra el rombo que define el final de la estructura y agrega la etiqueta </while> al código BPEL.

Escenario alterno de éxito:

1. El módulo recorre el vector de conexiones. 2. Si encuentra una actividad que define el inicio de una estructura

iterativa de tipo do_while, continúa el recorrido del vector y la generación de código de las actividades y estructuras, hasta encontrar un rombo que determine el fin de ciclo.

3. Agrega una etiqueta <while> al código BPEL. 4. Agrega una copia del código generado entre la actividad inicial

y el rombo de fin, y agrega una etiqueta </while>. Escenario de fracaso: 1. El módulo recorre el vector de conexiones.

2. Falta alguna relación en el diagrama. 3. No se puede recorrer todo el vector. 4. El código BPEL queda incompleto.

Includes: Suposiciones: 1. Todas las actividades fueron configuradas de acuerdo a

operaciones en BPEL. 2. El rombo que define el final del ciclo (en el caso del do_while)

sólo tiene una entrada.

91

Anexo D Descripción de las clases del módulo de composición En este anexo se describen las clases del módulo de composición de servicios Web y los métodos que las forman. La arquitectura de este módulo se presenta en el capítulo 4 de esta tesis.

Anexo D. Descripción de las clases del módulo de composición

92

CGeneraBPEL Clase principal del módulo. Define el orden de creación de objetos y la ejecución de

métodos para la generación del código en BPEL a partir de un diagrama de actividad.

Método Descripción CGeneraBPEL(Vector conexiones) Constructor de la clase. Inicializa las variables

genBPEL y BPEL.

fnObtenerBPEL( ) Método que controla el orden de creación de objetos y la ejecución de métodos para la generación de código.

CBPELElementos

Clase formada por elementos estáticos que permiten almacenar información correspondiente a los servicios, variables y partner links involucrados en el proceso de composición.

Método Descripción void fnInicializa ( ) Método que inicializa los vectores que almacenan la

información de los servicios, espacios de nombre, partner links y variables.

void fnGuardaServicios (Vector serv)

Método que recibe un vector con los nombres y URLs de los documentos WSDL de los servicios y los almacena en el vector servicios.

void fnGuardaTNS (String tns) Método que recibe una cadena correspondiente al espacio de nombres de un servicio y la almacena en el vector TNS (TargetNameSpace).

void fnGuardaPL (Vector pl) Método que recibe un vector con las características de un partner link y lo almacena en el vector PL.

void fnGuardaVariables (Vector var)

Método que recibe un vector con las características de una variable y lo almacena en el vector variables.

Vector fnGetServicios ( ) Método que permite recuperar al vector servicios.

Vector fnGetTNS ( ) Método que permite recuperar al vector TNS.

Vector fnGetPL ( ) Método que permite recuperar al vector PL.

Vector fnGetVariables ( ) Método que permite recuperar al vector variables.

AGenElemento

Clase abstracta que define el método fnGenera( ).

Método Descripción StringBuffer fnGenera(Vector vec, Vector serv)

Método abstracto a implementar en clases derivadas.

CGenEncabezado

Clase derivada de la clase AGenElemento. Implementa el método fnGenera( ) para la generación del código de la etiqueta process.


93

Método Descripción CGenEncabezado( ) Constructor de la clase. Inicializa la variable xml.

StringBuffer fnGenera(Vector vec, Vector nombre)

Método que genera el código de la etiqueta process. Incluye los espacios de nombres de los servicios involucrados en el proceso.

CGenVariable

Clase derivada de la clase AGenElemento. Implementa el método fnGenera( ) para la generación del código de definición de las variables globales del proceso.

Método Descripción CGenVariable( ) Constructor de la clase. Inicializa la variable xml.

StringBuffer fnGenera(Vector vec, Vector serv)

Método que genera el código de definición de las variables globales del proceso. Incluye los atributos nombre y tipo de mensaje o de dato.

CGenPL

Clase derivada de la clase AGenElemento. Implementa el método fnGenera( ) para la generación del código de definición de los partner links.

Método Descripción StringBuffer fnGenera(Vector vec, Vector serv)

Método que genera el código de definición de los partner links. Incluye los atributos partnerLinkType, partnerRole y myRole.

CGenPL( ) Constructor de la clase. Inicializa la variable xml.

CRecorreVect

Clase que inicializa la generación de código de la actividad principal del proceso BPEL.

Método Descripción CRecorreVect(Vector con) Constructor de la clase. Inicializa las variables a utilizar

en la generación de código.

void fnIndentificaObj( ) Método que inicia el recorrido del vector de conexiones y la generación de código correspondiente al diagrama de actividad.

void fnCuentaES(DibujarS fin) Método que cuenta las entradas y salidas de los elementos de tipo “decisión”.

StringBuffer fnGetBPEL() Método que permite recuperar la variable BPEL.

AStrategy

Clase abstracta que define el método fnRecorre( ) e implementa el método fnLlamaMetodos( ).


94

Método Descripción void fnRecorre(DibujarS fin, int posF, StringBuffer BPEL, int i, Vector conexiones, Vector anterior, Vector siguiente)

Método abstracto a implementar en clases derivadas.

void fnLlamaMetodos(DibujarS fin, int j, StringBuffer BPEL, int i, Vector conexiones, Vector anterior, Vector siguiente)

Método que controla el recorrido del vector de conexiones. Permite crear objetos de acuerdo al tipo de elemento encontrado al final de la conexión.

CActividad

Clase derivada de la clase AStrategy. Implementa el método fnRecorre( ) para la generación de código correspondiente a las operaciones en BPEL definidas en el diagrama de actividad.

Método Descripción CActividad( ) Constructor de la clase.

void fnRecorre(DibujarS fin, int posF, StringBuffer BPEL, int i, Vector conexiones, Vector anterior, Vector siguiente)

Método que genera el código correspondiente a las operaciones definidas en el diagrama. Identifica el inicio de ciclos do-while.

void fnCuentaES(DibujarS fin, int i, Vector conexiones)

Método que cuenta el número de entradas del objeto actividad.

CDecision

Clase derivada de la clase AStrategy. Implementa el método fnRecorre( ) para generar las etiquetas que indican estructuras condicionales e iterativas.

Método Descripción CDecision( ) Constructor de la clase.

void fnRecorre (DibujarS fin, int posF, StringBuffer BPEL, int i, Vector conexiones, Vector anterior, Vector siguiente)

Método que identifica si la estructura es una condicional o un ciclo while.

void fnRecorreCond(pintaDeci deci, int posF, StringBuffer BPEL, int i , Vector conexiones, Vector anterior, Vector siguiente)

Método que implementa un algoritmo para recorrer el vector de conexiones y generar etiquetas correspondientes a estructuras condicionales o iterativas de tipo do-while.

void fnRecorreWhile(pintaDeci deci,int posF, StringBuffer BPEL, int i, Vector conexiones, Vector anterior, Vector siguiente)

Método que implementa un algoritmo para recorrer el vector de conexiones y generar etiquetas correspondientes a estructuras iterativas de tipo while.


95

CFin Clase derivada de la clase AStrategy. Implementa el método fnRecorre( ) para generar

las etiquetas de fin de secuencia al final de rama de una condicional.

Método Descripción CFin( ) Constructor de la clase.

void fnRecorre(DibujarS fin, int posF, StringBuffer BPEL, int i, Vector conexiones, Vector anterior, Vector siguiente)

Método que genera las etiquetas para terminar una secuencia de operaciones dentro de una rama de una condicional.

CGeneraXML

Clase encargada de generar el archivo bpel.xml, en el cual se almacenan las URLs de los documentos WSDL de servicios involucrados en el proceso y se relacionan con su respectivo partner link.

Método Descripción CGenXML( ) Constructor de la clase. Inicializa la variable doc de tipo

document.

Void fnGuardaXML(string nombre)

Genera el archivo bpel.xml y lo almacena en la misma dirección donde se guarda el archivo de código BPEL.

Las clases CFork y CJoin son clases derivadas de la clase AStrategy. Implementan el método fnRecorre( ) para recorrer el vector en busca del siguiente elemento del diagrama de actividad. No generan código.

96

Anexo E Descripción de los casos de prueba En este anexo se describen completamente las características y los resultados esperados de los casos de prueba del módulo de composición de servicios presentados en el capítulo 5 de esta tesis.

Anexo E. Descripción de los casos de prueba

97

1. Caso de prueba MCS-CP-01 La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, calcule la suma de tres números enteros. a) Elementos de prueba

Los elementos utilizados son el servicio sumaBPEL, que permite realizar la suma de dos números enteros; los documentos WSDL sumaBPEL y BPELSumaTresEnteros, empleados en la configuración de las actividades del modelo; y un diagrama de actividad modelado en el cliente del WS-SIDDOO, que especifica la secuencia de las actividades involucradas en el proceso. b) Especificación de entrada

Las entradas para probar el módulo de composición de servicios Web son el diagrama de actividad modelado y configurado (figura 46) en el cliente del WS-SIDDOO y los vectores (servicios, variables, PL y TNS) que contienen información correspondiente a los demás elementos de BPEL a generar (de acuerdo a lo configurado por el usuario).

Figura 46. Diagrama de actividad para el caso de prueba MCS-CP-01. Para probar la ejecución del código BPEL generado, se utilizarán como valores de

entrada en la consola del servidor BPEL PM de Oracle los siguientes conjuntos de datos:

Conjunto Valores de entrada

1 3, 2, 8

2 10, 5, 7


98

c) Especificación de salida El código correspondiente a la secuencia de actividades que representa el modelo de la

figura 46 deberá tener la estructura que se muestra en la figura 47. Esta estructura es una representación abstracta del código de salida esperado.

<sequence> <receive . . . /> <assign . . . > <copy> <from . . . /> <to . . . / > </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . / > </copy> </assign> <invoke . . . /> <receive . . . /> <assign . . . > <copy> <from . . . /> <to . . . / > </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . / > </copy> </assign> <invoke . . . /> <receive . . . /> <assign . . . > <copy> <from . . . /> <to . . . / > </copy> </assign> <invoke . . . /> </sequence>

Figura 47. Estructura del código esperado para el caso MCS-CP-01.

El resultado de la ejecución del BPEL en el servidor de acuerdo a los valores de entrada deberá ser:

Conjunto Resultado

1 13

2 22

2. Caso de prueba MCS-CP-02 La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, calcule la media de cinco flotantes, evalúe el resultado utilizando una estructura condicional simple y envíe al usuario un mensaje de acuerdo a la evaluación.


99

a) Elementos de prueba Los elementos utilizados son el servicio MediaAritmetica; los documentos WSDL

MediaAritmetica y EvaluaMedia, empleados en la configuración de las actividades del modelo; y un diagrama de actividad modelado en el cliente del WS-SIDDOO, que especifica el orden de ejecución de las actividades involucradas en el proceso. b) Especificación de entrada


Figura 48. Diagrama de actividad para el caso de prueba MCS-CP-02.

Para probar la ejecución del código BPEL generado, se utilizarán como valores de entrada en la consola del servidor BPEL PM de Oracle los siguientes conjuntos de datos:

Conjunto Valores de entrada

1 12.1, 3.0, 5.2, 4.25, 10.8

2 28.2, 33.5, 17.9, 51.3, 9.8

c) Especificación de salida

El código correspondiente al modelo de la figura 48 deberá tener la estructura que se presenta en la figura 49. Esta estructura es una representación abstracta del código de salida esperado para la condicional simple.


100

<switch> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </case> </switch>

Figura 49. Estructura del código esperado para el caso MCS-CP-02. El usuario deberá modificar el código generado, agregando la condición a evaluar. El

resultado de la ejecución del BPEL en el servidor de acuerdo a los valores de entrada deberá ser:

Conjunto Resultado

1 El resultado es 7.07 y es menor que 20

2 El resultado es 28.14

3. Caso de prueba MCS-CP-03 La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, calcule la media de cinco flotantes, evalúe el resultado utilizando una estructura condicional doble y envíe al usuario un mensaje de acuerdo a la evaluación. a) Elementos de prueba

Los elementos utilizados son el servicio MediaAritmetica; los documentos WSDL MediaAritmetica y EvaluaMediaDoble, empleados en la configuración de las actividades del modelo; y un diagrama de actividad modelado en el cliente del WS-SIDDOO, que especifica el orden de ejecución de las actividades involucradas en el proceso. b) Especificación de entrada Las entradas para probar el módulo de composición de servicios Web son el diagrama de actividad modelado y configurado (figura 50) en el cliente del WS-SIDDOO y los vectores (servicios, variables, PL y TNS) que contienen información correspondiente a los demás elementos de BPEL a generar (de acuerdo a lo configurado por el usuario).

Para probar la ejecución del BPEL generado se utilizarán como valores de entrada en la consola del servidor BPEL PM de Oracle los siguientes conjuntos de datos:

Conjunto Valores

1 33.1, 20.3, 18.2, 24.25, 7.34

2 8.3, 12.5, 23.2, 11.03, 30


101

Figura 50. Diagrama de actividad para el caso de prueba MCS-CP-03. c) Especificación de salida

El código correspondiente al modelo de la figura 50 deberá tener la estructura que se presenta en la figura 51. Esta estructura es una representación abstracta del código de salida esperado para la condicional doble.

<switch> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> < to . . ./> </copy> </assign> </sequence> </case> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> < to . . . /> </copy> </assign> </sequence> </case> </switch>


El usuario deberá modificar el código generado, agregando la condición a evaluar en cada caso. El resultado de la ejecución del BPEL en el servidor de acuerdo a los valores de entrada deberá ser:


102

Conjunto Resultado

1 El resultado es: 20.638 y es mayor que 20

2 El resultado es 17.006 y es menor que 20

4. Caso de prueba MCS-CP-04 La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, calcule la media de tres enteros utilizando servicios de suma y división, evalúe el resultado con una estructura condicional múltiple y envíe al usuario un mensaje de acuerdo a la evaluación. a) Elementos de prueba

Los elementos utilizados son los servicios BPELSumaTresEnteros y ServicioDivision; los documentos WSDL BPELSumaTresEnteros, ServicioDivision y EvaluaCalificaciones, empleados en la configuración de las actividades del modelo; y un diagrama de actividad modelado en el cliente del WS-SIDDOO, que especifica el orden de ejecución de las actividades involucradas en el proceso. b) Especificación de entrada





103

Conjunto Valores

1 100, 98, 99

2 80, 90, 88

3 75, 72, 85


El código correspondiente al modelo de la figura 52 deberá tener la estructura que se presenta en la figura 53. Esta estructura es una representación abstracta del código de salida esperado para la condicional múltiple.

<switch> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> < to . . . /> </copy> </assign> </sequence> </case> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> < to . . . /> </copy> </assign> </sequence> </case> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> < to . . . /> </copy> </assign> </sequence> </case> </switch>


El usuario deberá modificar el código generado, agregando la condición a evaluar en cada caso. El resultado de la ejecución del BPEL en el servidor de acuerdo a los valores de entrada deberá ser:

Conjunto Resultado

1 Promedio: 99 (excelente)

2 Promedio: 86 (bueno)

3 Promedio: 77.33 (bajo)

d) Dependencias entre casos

Este caso de prueba depende de la ejecución del proceso BPELSumaTresEnteros generado en el caso MCS-CP-01.


104

5. Caso de prueba MCS-CP-05 La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, eleve un número flotante a la n-ésima potencia (siendo el exponente un entero positivo) y envíe al usuario el resultado. El proceso será modelado utilizando estructuras condicionales en cascada. a) Elementos de prueba

Los elementos utilizados son el servicio ServicioPotencia; los documentos WSDL ServicioPotencia y CalculaPotencia, empleados en la configuración de las actividades del modelo; y un diagrama de actividad modelado en el cliente del WS-SIDDOO, que especifica el orden de ejecución de las actividades involucradas en el proceso.

b) Especificación de entrada




Conjunto Valores

1 103.5, 4

2 6, 1

3 201, 0


105

c) Especificación de salida El código correspondiente al modelo de la figura 54 deberá tener la estructura que se

presenta en la figura 55. Esta estructura es una representación abstracta del código de salida esperado para las condicionales en cascada.

<switch> <case condition='' > <sequence> <switch> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </case> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </case> </switch> </sequence> </case> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <invoke . . . /> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </case> </switch>

Figura 55. Estructura del código esperado para el caso MCS-CP-05. El usuario deberá modificar el código generado, agregando la condición a evaluar en

cada caso. El resultado de la ejecución del BPEL en el servidor de acuerdo a los valores de entrada deberá ser:


106

Conjunto Resultado

1 114752300.0625

2 6

3 1

6. Caso de prueba MCS-CP-06 La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, efectúe la multiplicación de dos números enteros positivos y envíe al usuario el resultado. a) Elementos de prueba

Los elementos utilizados son el servicio sumaBPEL; los documentos WSDL sumaBPEL y calculaMultiplicacion, empleados en la configuración de las actividades del modelo; y un diagrama de actividad modelado en el cliente del WS-SIDDOO, que especifica el orden de ejecución de las actividades involucradas en el proceso. b) Especificación de entrada





107

Conjunto Valores

1 5, 3

2 12, 8

3 42, 1

4 23, 0


El código correspondiente al modelo de la figura 56 deberá tener la estructura que se presenta en la figura 57. Esta estructura es una representación abstracta del código de salida esperado para la estructura iterativa while.

<while condition='' > <sequence> <invoke . . . /> <receive . . . /> <assign . . . > <copy> <from . . . /> <to . . ./> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </while>


El usuario deberá modificar el código generado, agregando la condición a evaluar en la actividad BPEL while. El resultado de la ejecución del BPEL en el servidor de acuerdo a los valores de entrada deberá ser:

Conjunto Resultado

1 15

2 96

3 42

4 0

7. Caso de prueba MCS-CP-07 La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, identifique los números primos que se encuentran dentro de un rango de enteros proporcionados por el usuario. El proceso se modelará con una estructura iterativa do_while y una condicional simple.


108

a) Elementos de prueba Los elementos utilizados son el servicio VerificaPrimo; los documentos WSDL

VerificaPrimo y NumerosPrimos, empleados en la configuración de las actividades del modelo; y un diagrama de actividad modelado en el cliente del WS-SIDDOO, que especifica el orden de ejecución de las actividades involucradas en el proceso. b) Especificación de entrada


Figura 58. Diagrama de actividad para el caso de prueba MCS-CP-07. Para probar la ejecución del BPEL generado se utilizarán como valores de entrada en la

consola del servidor BPEL PM de Oracle los siguientes conjuntos de datos:

Conjunto Valores

1 1, 10

2 13, 17

3 21, 30


El código correspondiente al modelo de la figura 58 deberá tener la estructura que se presenta en la figura 59. Esta estructura es una representación abstracta del código de salida esperado para la estructura iterativa do_while (expresada utilizando una actividad BPEL while).

<assign . . . > <copy> <from . . . /> <to . . . /> </copy>


109

</assign> <invoke . . . /> <switch> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </case> </switch> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <while condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <invoke . . . /> <switch> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </case> </switch> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </while>


El usuario deberá modificar el código generado, agregando las condiciones a evaluar en cada caso (actividad switch o while). El resultado de la ejecución del BPEL en el servidor de acuerdo a los valores de entrada deberá ser:

Conjunto Resultado

1 2, 3, 5, 7

2 13, 17

3 23, 29

8. Caso de prueba MCS-CP-08 La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, eleve un número entero a la n-ésima potencia (siendo el exponente un entero positivo) y evalúe el resultado. Si éste es mayor que 100, obtenga su n-sima raíz, si no, le sume unidades hasta


110

alcanzar el 100. El proceso se modelará utilizando estructuras secuenciales, condicionales dobles e iterativas de tipo while. a) Elementos de prueba

Los elementos utilizados son los servicios CalculaRaiz, ServicioPotencia y sumaBPEL; los documentos WSDL CalculaRaiz, ServicioPotencia, sumaBPEL y servicioCompuesto1, empleados en la configuración de las actividades del modelo; y un diagrama de actividad modelado en el cliente del WS-SIDDOO, que especifica el orden de ejecución de las actividades involucradas en el proceso. b) Especificación de entrada




Conjunto Valores

1 15, 3

2 9, 2


El código correspondiente al modelo de la figura 60 deberá tener la estructura que se presenta en la figura 61. Esta estructura es una representación abstracta del código de salida esperado.


111

<sequence> <receive . . . /> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . ./> <to . . . /> </copy> </assign> <invoke . . . /> <switch> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <while condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <invoke . . . /> <receive . . . /> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </while> </sequence> </case> <case condition=''> <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <invoke . . . /> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </case> </switch> <invoke . . . /> </sequence>


El usuario deberá modificar el código generado, agregando las condiciones a evaluar en cada caso (actividad switch o while) y sustituyendo las etiquetas <case> y </case> de la


112

segunda opción de la condicional, por las etiquetas <otherwise> y </otherwise>, respectivamente. El resultado de la ejecución del BPEL en el servidor de acuerdo a los valores de entrada deberá ser:

Conjunto Resultado

1 15

2 100

9. Caso de prueba MCS-CP-09 La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, realice una operación aritmética de acuerdo a la entrada proporcionada por el usuario. El proceso será modelado utilizando estructuras condicionales dobles y múltiples en cascada. a) Elementos de prueba

Los elementos utilizados son los servicios sumaBPEL, ServicioRestas, calculaMultiplicacion y servicioDivision; los documentos WSDL sumaBPEL, ServicioRestas, calculaMultiplicacion, servicioDivision y servicioOperaciones, empleados en la configuración de las actividades del modelo; y un diagrama de actividad modelado en el cliente del WS-SIDDOO, que especifica el orden de ejecución de las actividades involucradas en el proceso. b) Especificación de entrada




113


Conjunto Valores

1 5, 3, S

2 12, 8, R

3 3, 2, M

4 22, 11, D



<sequence> <receive . . ./> <switch> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <invoke . . . /> <receive . . . /> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </case> <case condition='' > <sequence> <switch> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <invoke . . . /> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </case> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy>


114

</assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <invoke . . . /> <receive . . . /> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </case> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <invoke . . . /> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </case> </switch> </sequence> </case> </switch> <invoke . . . /> </sequence>

Figura 63 Estructura del código esperado para el caso MCS-CP-09.

El usuario deberá modificar el código generado, agregando las condiciones a evaluar en cada caso. El resultado de la ejecución del BPEL en el servidor de acuerdo a los valores de entrada deberá ser:

Conjunto Resultado

1 8

2 4

3 6

4 2


Este caso de prueba depende de la ejecución del proceso calculaMultiplicacion generado en el caso MCS-CP-06.


115

10. Caso de prueba MCS-CP-10 La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, calcule la media cuadrática de un conjunto de números proporcionados por el usuario. El proceso será modelado utilizando estructuras secuenciales e iterativas de tipo while. a) Elementos de prueba

Los elementos utilizados son los servicios CalculaRaiz, ServicioPotencia y servicioDivision; los documentos WSDL CalculaRaiz, ServicioPotencia, servicioDivision y servicioCompuesto2, empleados en la configuración de las actividades del modelo; y un diagrama de actividad modelado en el cliente del WS-SIDDOO, que especifica el orden de ejecución de las actividades involucradas en el proceso. b) Especificación de entrada




Conjunto Valores

1 10, 5, 4, 6, 8

2 22, 15, 45, 3


116


presenta en la figura 65. Esta estructura es una representación abstracta del código de salida esperado.

<sequence> <receive . . . /> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <while condition= '' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <invoke . . . /> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </while> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <invoke . . . /> <receive . . . /> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <invoke . . . /> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <reply . . . /> </sequence>



117

El usuario deberá modificar el código generado, agregando la condición a evaluar en la actividad BPEL while. El resultado de la ejecución del BPEL en el servidor de acuerdo a los valores de entrada deberá ser:

Conjunto Resultado

1 6.928

2 26.1916

Nota: el resultado de la operación no es exacto, ya que se redondean algunos valores durante el proceso debido a los tipos de datos manejados por los servicios. 11. Caso de prueba MCS-CP-11 La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, calcule la media geométrica de un conjunto de números positivos proporcionados por el usuario. El proceso será modelado utilizando estructuras secuenciales, condicionales dobles e iterativas de tipo do_while. a) Elementos de prueba

Los elementos utilizados son los servicios CalculaRaiz y calculaMultiplicacion; los documentos WSDL CalculaRaiz, calculaMultiplicacion y servicioMediaGeometrica, empleados en la configuración de las actividades del modelo; y un diagrama de actividad modelado en el cliente del WS-SIDDOO, que especifica el orden de ejecución de las actividades involucradas en el proceso. b) Especificación de entrada



118



Conjunto Valores

1 6, 11, 4, 7

2 1, 3 ,9

3 0



<sequence> <receive . . . /> <switch> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </case> <case condition=''> <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <invoke . . . /> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <while condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <invoke . . . />


119

<assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </while> <switch> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <invoke . . . / > <assign . . . > <copy> <from . . . /> <to . . . /> <copy> </assign> </sequence> </case> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </case> </switch> </sequence> </case> </switch> <reply . . . /> </sequence>

Figura 67. Estructura del código esperado para el caso MCS-CP-11. El usuario deberá modificar el código generado, agregando las condiciones a evaluar

en cada caso (actividad switch o while) y sustituyendo las etiquetas <case> y </case> de la segunda opción de la condicional principal, por las etiquetas <otherwise> y </otherwise>, respectivamente.


Conjunto Resultado

1 6.555

2 3.0

3 Error


120

d) Dependencias entre casos Este caso de prueba depende de la ejecución del proceso calculaMultiplicacion

generado en el caso MCS-CP-06. 12. Caso de prueba MCS-CP-12 La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, calcule la varianza de un conjunto de números proporcionados por el usuario. El proceso será modelado utilizando estructuras secuenciales, condicionales dobles e iterativas de tipo while. a) Elementos de prueba

Los elementos utilizados son los servicios ServicioPotencia y ServicioDivision; los documentos WSDL ServicioPotencia, ServicioDivision y ServicioVarianza, empleados en la configuración de las actividades del modelo; y un diagrama de actividad modelado en el cliente del WS-SIDDOO, que especifica el orden de ejecución de las actividades involucradas en el proceso. b) Especificación de entrada





121

Conjunto Valores

1 10, 2

2 11, 15, 21, 17

3 2, 8, 13



<sequence> <receive . . . /> <switch> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <while condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </while> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <while condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <invoke . . . /> <assign . . . > <copy>


122

<from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </while> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <invoke . . . /> <receive . . . /> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </case> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </case> </switch> <reply . . . /> </sequence>


El usuario deberá modificar el código generado, agregando las condiciones a evaluar en cada caso (actividad switch o while).


Conjunto Resultado

1 16

2 13

3 20.3333

Nota: el resultado de la operación no es exacto, ya que se redondean algunos valores durante el proceso debido a los tipos de datos manejados por los servicios.


123

13. Caso de prueba MCS-CP-13 La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, realice la suma entre elementos de dos arreglos de enteros proporcionados por el usuario. El proceso será modelado utilizando estructuras secuenciales e iterativas de tipo while. a) Elementos de prueba

Los elementos utilizados son el servicio sumaBPEL; los documentos WSDL sumaBPEL y sumaArreglos, empleados en la configuración de las actividades del modelo; y un diagrama de actividad modelado en el cliente del WS-SIDDOO, que especifica el orden de ejecución de las actividades involucradas en el proceso. b) Especificación de entrada




Conjunto Valores

1 A1= 2, 3, 8 A2= 2, 1

2 A1= 3, 11, 4, 9, 15 A2= 5, 3, 10


124



<sequence> <receive . . ./> <assign . . .> <copy> <from . . ./> <to . . ./> </copy> </assign> <assign . . .> <copy> <from . . ./> <to . . ./> </copy> </assign> <assign . . .> <copy> <from . . ./> <to . . ./> </copy> </assign> <while condition='' > <sequence> <while condition='' > <sequence> <assign . . .> <copy> <from . . ./> <to . . ./> </copy> </assign> <assign . . .> <copy> <from . . ./> <to . . ./> </copy> </assign> <invoke . . ./> <receive . . ./> <assign . . .> <copy> <from . . ./> <to . . ./> </copy> </assign> <assign . . .> <copy> <from . . ./> <to . . ./> </copy> </assign> </sequence> </while> <assign . . .> <copy> <from . . ./> <to . . ./> </copy> </assign> <assign . . .> <copy> <from . . ./> <to . . ./> </copy> </assign> </sequence> </while> <invoke . . ./> </sequence>

Figura 71. Estructura del código esperado para el caso MCS-CP-13. El usuario deberá modificar el código generado, agregando las condiciones a evaluar

en cada actividad BPEL while. El resultado de la ejecución del BPEL en el servidor de acuerdo a los valores de entrada deberá ser:


125

Conjunto Resultado

1 22

2 132

14. Caso de prueba MCS-CP-14 La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, multiplique elementos de un arreglo de enteros proporcionado por el usuario. El proceso será modelado utilizando estructuras secuenciales, condicionales múltiples e iterativas de tipo do_while. a) Elementos de prueba

Los elementos utilizados son el servicio calculaMultiplicacion; los documentos WSDL calculaMultiplicacion y servicioCompuesto3, empleados en la configuración de las actividades del modelo; y un diagrama de actividad modelado en el cliente del WS-SIDDOO, que especifica el orden de ejecución de las actividades involucradas en el proceso. b) Especificación de entrada





126

Conjunto Valores

1 --

2 8

3 2, 7, 3, 15



<sequence> <receive . . . /> <switch> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </case> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </case> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <invoke . . . /> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . />


127

</copy> </assign> <while condition='' > <sequence> <assign . . .> <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <invoke . . . /> <assign . . . > <copy> <from. . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </while> </sequence> </case> </switch> <invoke . . . /> </sequence>


El usuario deberá modificar el código generado, agregando las condiciones a evaluar en cada caso (actividad switch o while).


Conjunto Resultado

1 0

2 8

3 630


Este caso de prueba depende de la ejecución del proceso calculaMultiplicacion generado en el caso MCS-CP-06. 15. Caso de prueba MCS-CP-15 La prueba consiste en generar código BPEL que al ser ejecutado en el servidor, realice la suma de los elementos de un arreglo de enteros proporcionado por el usuario. El proceso será modelado utilizando estructuras secuenciales, condicionales dobles, condicionales en cascada, iterativas de tipo do_while e iterativas de tipo while.


128

a) Elementos de prueba Los elementos utilizados son el servicio sumaBPEL; los documentos WSDL

sumaBPEL y servicioCompuesto4, empleados en la configuración de las actividades del modelo; y un diagrama de actividad modelado en el cliente del WS-SIDDOO, que especifica el orden de ejecución de las actividades involucradas en el proceso. b) Especificación de entrada Las entradas para probar el módulo de composición de servicios Web son el diagrama de actividad modelado y configurado (figura 74) en el cliente del WS-SIDDOO y los vectores (servicios, variables, PL y TNS) que contienen información correspondiente a los demás elementos de BPEL a generar (de acuerdo a lo configurado por el usuario).



Conjunto Valores

1 8

2 11, 23

3 15, 3, 7

4 9, 1, 14, 21


129



<sequence> <receive . . . /> <switch> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </case> <case condition=''> <sequence> <switch> <case condition='' > <sequence> <switch> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . .> <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . .> <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . .> <copy> <from . . . /> <to . . . /> </copy> </assign> <invoke . . . /> <receive . . . /> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <while condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <invoke . . . / > <receive . . . /> <assign . . . >


130

<copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </while> </sequence> </case> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <while condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <invoke . . . / > <receive . . . /> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </while> </sequence> </case> </switch> </sequence> </case> <case condition='' > <sequence> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <invoke . . . /> <receive . . . /> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> </sequence> </case>


131

</switch> </sequence> </case> </switch> <assign . . . > <copy> <from . . . /> <to . . . /> </copy> </assign> <reply . . . /> </sequence>


El usuario deberá modificar el código generado, agregando las condiciones a evaluar en cada caso (actividad switch o while) y sustituyendo las etiquetas <case> y </case> de la segunda opción de la condicional principal, por las etiquetas <otherwise> y </otherwise>, respectivamente.


Conjunto Resultado

1 8

2 34

3 25

4 45

Referencias

132

Referencias [ARIA05] Arias J.: Definición de un modelo para la verificación formal de procesos de negocio.

Departamento de Ingeniería Telemática. Universidad Carlos III de Madrid. Tesis doctoral. 2005. [Citado 2007-05-15]. Disponible en línea: <http://www.it.uc3m.es/jaf/tesis/tesis.pdf >

[BEAS03] BEA Systems, IBM, Microsoft, SAP AG, Siebel Systems: BPEL4WS V1.1 Specification.

[Citado 2007-05-15]. Disponible en línea: <http://download.boulder.ibm.com/ibmdl/pub/ software/dw/specs/ws-bpel/ws-bpel.pdf>

[BELL00] Bellows, J.: Activity Diagrams and Operation Architecture. [Citado 2007-05-15]. Disponible en

línea: <http://www.cbd-hq.com/articles/2000/000101jb_activitydiagrams .asp> [BENA02] Benatallah B., Dumas M., Maamar Z.: Definition and Execution of Composite Web Services:

The SELF-SERV Project. Data Engineering Bulletin 25(4). IEEE Computer Society. Diciembre, 2002. [Citado 2007-05-21]. Disponible en línea: <http://sky.fit.qut.edu.au/~dumas/tcde02.pdf>

[CASA00] Casati F., Ilnicki S., Jin L., Krishnamoorthy V., Shan M.: Adaptive and Dynamic Service

Composition in eFlow. HP Labs 2000 Technical Reports. [Citado 2007-05-21]. Disponible en línea: <http://www.hpl.hp.com/techreports/2000/HPL-2000-39.pdf>

[CASA01] Casati F., Sayal M., Shan M.: Developing e-services for composing e-services. In Proceedings

of 13th International Conference on Advanced Information Systems Engineering(CAiSE), Interlaken, Suiza. Junio, 2001. Springer Verlag. [Citado 2007-05-21]. Disponible en línea: <http://www.hpl.hp.com/personal/Fabio_Casati/docs/caise01.pdf>

[CUBI04] Cubillos J.A., Burbano J.E., Corrales J.C., Ordóñez J.A.: Composición Semántica de Servicios

Web. Grupo de Ingeniería Telemática, Universidad del Cauca, Popayán, Colombia. [Citado 2007-05-14]. Disponible en línea: <http://www.cintel.org.co/media/temacentral_3_14.pdf>

[DUMA01] Dumas M., Hofstede A.: UML Activity Diagrams as a Workflow Specification Language.

Proceedings of the 4th.International Conference UML’2001. Volumen 2185 LNCS, 76-90. Springer Verlag. 2001. [Citado 2007-05-15]. Disponible en línea: <http://sky.fit.qut.edu.au/%7Edumas/uml01_dumas.pdf>

[DUST05] Dustdar S., Schreiner W.: A Survey on Web Services Composition. International Journal of

Web and Grid Services, 1(1), 1 - 30, 2005. [Citado 2007-05-14]. Disponible en línea: <http://www.infosys.tuwien.ac.at/Staff/sd/papers/A%20survey%20on%20web%20services%20composition_Dustdar_Schreiner_inPress.pdf>

[EARL04] Earl T.: Service Oriented Architecture. A field Guide to Integrating XML and Web Services.

Saddle River, New Jersey: Prentice Hall, 2004, p. 61-62. [Citado 2007-05-15]. [ESHU01a] Eshuis R., Wieringa R.: A Formal Semantics for UML Activity Diagrams – Formalising

Workflow Models. CTIT Technical Report 01-04. Universidad de Twente, Italia. Febrero, 2001. [Citado 2007-05-15]. Disponible en línea: <http://doc.utwente.nl/fid/1256>

[ESHU01b] Eshuis R., Wieringa R.: A Real-Time Execution Semantics for UML Activity Diagrams.

Proceedings of Fundamental Approaches to Software Engineering (FASE 2001). Volumen 2029 LNCS, 76–90. Springer Verlag. 2001. [Citado 2007-05-15]. Disponible en línea: <http://wwwhome.cs.utwente.nl/~tcm/fase.pdf>

Referencias

133

[ESPI04] Espinoza D.: Estructuras de Selección. [Citado 2007-07-03]. Lima, Perú. Mayo, 2004. Disponible en línea: <http://www.geocities.com/david_ees/Algoritmia/cap03.htm>

[FUEN01] Fuentes L., Troya M., Vallecillo A.: Desarrollo de Software Basado en Componentes.

Departamento de Lenguajes y Ciencias de la Computación, Universidad de Málaga, España. 2001. [Citado 2007-05-18]. Disponible en línea: <http://www.lcc.uma.es/~av/Docencia /Doctorado/tema1.pdf>

[GARC05] García I. : Coordinación de Procesos de Negocio en entornos de servicios Web: Implementación

de business activity. Facultad de Informática. Universidad Politécnica de Madrid, España. 2005. [Citado 2007-05-18]. Disponible en línea: <http://internetng. dit.upm.es/business%20activity.pdf>

[GUZM06] Guzmán M.: Composición de servicios Web. Laboratorio de Ingeniería de Software. Centro

Nacional de Investigación y Desarrollo Tecnológico. México. Tesis de maestría, 2006. [HAMA03] Hamadi R., Benatallah B.: A Petri Net-based Model for Web Service Composition. In

Proceedings of the Fourteenth Australasian database conference on Database technologies 2003, 191-200, Darlinghurst, Australia, Australia. 2003. Australian Computer Society, Inc. [Citado 2007-05-21]. Disponible en línea: <http://crpit.com/confpapers/CRPITV17 Hamadi.pdf>

[HERR98] Herrera L.: Objetos distribuidos. [Citado 2007-05-18]. Disponible en línea:

<http://www.mcc.unam.mx /~cursos/Algoritmos/javaDC99-1/resumen3.html> [IRIB01] Iribane L.: Pasado, Presente y Futuro de los Sistemas de Información Distribuidos.

Departamento de Lenguajes y Computación, Universidad de Almería, España. 2001. [Citado 2007-05-18]. Disponible en línea: <http://acacia.ual.es/profesor/LIRIBARNE/research/tr/ Historia-SID.pdf>

[LOPE04] López J., Mersegues J., Campos J.: From UML Activity Diagrams To Stochastic Petri Nets:

Application To Software Performance Engineering. Departamento de Informática e Ingeniería de Sistemas. Universidad de Zaragoza, España. [Citado 2007-05-15]. Disponible en línea: <http://webdiis.unizar.es/CRPetri/papers/jcampos/04_LGMC_WOSP.pdf>

[MAJI04] Majithia S., Shields M., Taylor I., Wang I.: Triana: A Graphical Web Service Composition and

Execution Toolkit. In Proceedings of the IEEE International Conference on Web Services (ICWS'04), 514-524. IEEE Computer Society, 2004. [Citado 2007-05-21]. Disponible en línea: <http://www.trianacode.org/papers/pdf/Majithia2004Triana.pdf>

[MART05] Martínez A., Patiño M., Jimenez R., Pérez F.: ZenFlow: A Visual Web Service Composition

Tool for BPEL4WS. In Proceedings of the 2005 IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC'05), 00, 181-188, 2005. [Citado 2007-05-21]. Disponible en línea: <http://lsd.ls.fi.upm.es/lsd/papers/2005/vlhcc05.pdf>

[MATS02] Matskin M., Rao J.: Value-Added Web Services Composition Using Automatic Program

Synthesis. In Web Services, E-Business, and the Semantic Web, CAiSE 2002 International Workshop, WES2002, n. 2512 en LNCS, Toronto, Canada. 2002. Springer Verlag. [Citado 2007-05-21]. Disponible en línea: <http://www.cs.cmu.edu/~jinghai/papers/wes02_lncs. pdf>

[MATS05] Matskin M., Küngas P., Rao J., Sampson J., Petersen S. A.: Enabling Web Services

Composition with Software Agents. In Proceedings of the Ninth IASTED International Conference on Internet and Multimedia Systems and Applications, IMSA 2005, 93-98,

Referencias

134

Honolulu, Hawaii, USA. Agosto, 2005. [Citado 2007-05-21]. Disponible en línea: <http://www.idi.ntnu.no/~peep/papers/IMSA2005MKRS.pdf>

[ORAC06] Oracle: Tutorial 3: Manipulating XML Documents in BPEL. [Citado 2007-06-28]. Disponible

en línea: <http://www.oracle.com/technology/products/ias/bpel/pdf/orabpel-Tutorial3-DataManipulationTutorial.pdf>

[OSMO05] Osmosis Latina: Diagramas de actividad, definición y usos. [Citado 2007-05-15]. Disponible en

línea: <http://www.osmosislatina.com/lenguajes/uml/actividad.htm> [PELT03] Peltz C. HP: Web services orchestration. [Citado 2007-05-15]. Disponible en línea:

<http://devresource.hp.com/drc/technical_white_papers/WSOrch/WSOrchestration.pdf> [PERI02] Peris P., Belenguer N. Servicios Web. Facultad de Informática - Universidad Politécnica de

Valencia. [Citado 2007-05-14]. Disponible en línea: <http://www.dsic.upv.es/asignaturas/ facultad/lsi/trabajos/272002.doc>

[PONN02] Ponnekanti S., Fo A.: SWORD: A Developer Toolkit for Web Service Composition. In

Proceedings of the 11th International World Wide Web conference, Honolulu, Hawaii, USA. Mayo, 2002. [Citado 2007-05-21]. Disponible en línea: <http://www2002.org /CDROM/alternate/786/>

[POPK02] Popkin Software and Systems: Modelado de sistemas con UML. [Citado 2007-05-22].

Disponible en línea: <http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/multiple-html/x291.html>

[RAMA04] Rama Estudiantil IEEE – UD. Capítulo de Computadores: Servicios Web. Universidad

Distrital Francisco José de Caldas. [Citado 2007-05-14]. Disponible en línea: <http://ieee. udistrital.edu.co/computer/paginas.php?topic=ws>

[RAOJ04a] Rao J., Su X.: A Survey of Automated Web Service Composition Methods. In Proceedings of

the First International Workshop on Semantic Web Services and Web Process Composition, SWSWPC 2004, San Diego, California, USA. Julio, 2004. [Citado 2007-05-21]. Disponible en línea: <http://www.cs.cmu.edu/~jinghai/papers/survey_rao.pdf>

[RAOJ04b] Rao J.: Semantic Web Service Composition via Logic-Based Program Synthesis. Department of

Computer and Information Science, Norwegian University of Science and Technology. Norway, Tesis de doctorado.

[ROMA03] Román J.: Sistema Visual para el Diseño Detallado de Métodos de Clases con UML.

Laboratorio de Ingeniería de Software. Centro Nacional de Investigación y Desarrollo Tecnológico. Cuernavaca, México. Tesis de maestría, 2003.

[SAMP05] Samper J.J.: Ontologías para servicios Web semánticos de información de tráfico: descripción y

herramientas de explotación. Departamento de Informática, Universidad de Valencia. [Citado 2007-05-14]. Disponible en línea: <http://www.tesisenxarxa.net/ TESIS_UV/AVAILABLE/TDX-0628106-085805//SAMPER.pdf>

[SLOG04] Slogan D., Gronmo R., Solheim I.: Web service composition in UML. The 8th International

IEEE Enterprise Distributed Object Computing Conference (EDOC) Monterey, California, USA. Septiembre, 2004. [Citado 2007-05-21]. Disponible en línea: <http://folk.uio.no/roygr/EDOC-2004.pdf>

[SOLI06] Solís I.: Sistema de búsqueda y selección de servicios Web. Laboratorio de Ingeniería de

Referencias

135

Software. Centro Nacional de Investigación y Desarrollo Tecnológico. México. Tesis de maestría, 2006.

[STOR04] Störrle H.: Semantics and Verification of Data Flow in UML 2.0 Activities. Proceedings of

IEEE Symposium on Visual Languages and Formal Methods (VLFM) 2004. [Citado 2007-05-15]. Disponible en línea: <www.pst.informatik.uni-muenchen.de/personen/stoerrle/V/ AD2b-DataFlow.pdf>

[TROY99] Troya J., Vallecillo A.: Integración de Componentes en Sistemas Abiertos. Computación y

Sistemas. 2(4), 174-182, Abril/Junio, 1999. [Citado 2007-05-18]. Disponible en línea: <www.lcc.uma.es/~av/Publicaciones/99/avseid99.doc>

[UMLM04] UML Model Transformation Tool (UMT). [Citado 2007-05-21]. Disponible en línea:

<http://umt-qvt.sourceforge.net/downloads.html> [VAZQ04] Vázquez I.: Generación de servicios Web a partir de software legado. Laboratorio de Ingeniería

de Software. Centro Nacional de Investigación y Desarrollo Tecnológico. México. Tesis de maestría, 2004.

[WIKI07] WikiPedia: UDDI. [Citado 2007-05-14]. Disponible en línea: <http://es.wikipedia.org/

wiki/UDDI> [W3CN00] W3C Note: Simple Object Access Protocol (SOAP) 1.1. [Citado 2007-05-14]. Disponible en

línea: <http://www.w3.org/TR/2000/NOTE-SOAP-20000508> [W3CN01] W3C Note: Web Services Description Language (WSDL) Version 1.1. [Citado 2007-05-14].

Disponible en línea: <http://www.w3.org/TR/wsdl > [W3CW04] W3C Working Group Note: Web Services Architecture. [Citado 2007-05-14]. Disponible en

línea: <http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#whatis> [W3CO06] W3C Oficina Española: Guía Breve de Tecnologías XML. [Citado 2007-05-14]. Disponible

en línea: <http://www.w3c.es/Divulgacion/Guiasbreves/TecnologiasXML>