transparencias de tesis phd

Generación dinámica de invariantes para composicionesde servicios web en WS-BPEL

Manuel Palomo Duarte

Tesis doctoral

Julio 2011

M. Palomo (UCA) Invariantes dinámicos para composiciones WS-BPEL 1 / 67

Índice

1 Introducción

2 Invariantes dinámicos en WS-BPEL

3 Optimizaciones

4 Experimentos

5 Conclusiones


Introducción

Índice

1 Introducción


3 Optimizaciones

4 Experimentos

5 Conclusiones


Introducción

Objetivo general de la tesis

ObjetivoDemostrar la viabilidad de la generación dinámica de invariantes (GDI) parala composición de servicios web (SW) en WS-BPEL

DefinicionesGDI técnica de prueba de software que detecta propiedades que

cumple un programa en diversas ejecucionesWS-BPEL lenguaje de programación a gran escala (programming in the

large) para componer SW usando otros SW


Introducción Arquitecturas Orientadas a Servicio

Definiciones

Visión de W3C y OASISArquitecturas Orientadas a Servicio tecnologías para la integración de

software de modo independiente de lenguajes deprogramación, sistemas operativos y arquitecturas hardware

SW son su base, un software con el que interoperar enviandomensajes a través de la web según protocolos estandarizados

Tecnologías estandarizadasXML Schema tipos de datos

XPath consulta de datos XML SchemaWS-BPEL composición de WS por orquestación

WS-BPEL 2.0 es estándar OASIS



WS-BPEL

Ejemplo de composición

Cliente

SW1

SWdirector

SW3SW2

Orquestación de servicios

CaracterísticasCódigo XML (desarrollo conGUI)Despliegue y creación deinstancias en servidorDependencia del entorno(SW socios)Instrucciones específicas:invocación de SW, gestión deeventos externos, etc.Código poco modularÁmbitos para variables



Generación de invariantes

Invariante versus invariante potencialInvariante propiedad que cumple un programa (pre/post-condición,

aserto, invariante de bucle, etc.), obtenida con métodosformalesSiempre cierto, pero costoso de conseguir y con resultadoslimitados

Invariante potencial propiedad que se mantiene en una serie de casos deprueba (también llamado invariante generado dinámicamenteo invariante dinámico)Más sencillos de obtener automáticamente, ciertos bajodeterminadas condiciones y amplios resultados

Abuso del términoLa tesis versa sobre invariantes potenciales, pero para agilizar la exposiciónse usará el término invariante a secas


Introducción Prueba de software para WS-BPEL

Uso de invariantes

Punto de Programa (PP)Por cada instrucción i del programa se definen dos PP:Antes de i invariantes ciertos justo antes de ejecutar i

Después de i ciertos inmediatamente tras su ejecuciónSi i es una instrucción de bloque pueden anidarse

Usos de invariantesVerificaciónDepuración de errores (prueba de regresión)DocumentaciónMejora de un conjunto de casos de prueba



Ciclo de uso de la GDI propuesto

Fin

Ejecución

Generación deinvariantes

Mejora de los casos de prueba

Mejora del programa

Generadordinámico deinvariantes

Usuario

Casos de pruebaPrograma



GDI para WS-BPEL

InnovaciónLa GDI se ha aplicado a lenguajes imperativos, pero no a WS-BPEL ni otrolenguaje de composición de SW

AdecuaciónNo traducción del códigoEjecución de código en motor WS-BPEL 2.0Capacidad de uso de SW realesSuplantación opcional de SW

SW no disponibles para prueba: coste, bloqueo recursos, etc.Simulación de escenarios: ¿cómo se comportará la composición si esteSW responde tal cosa y este otro tal otra?


Invariantes dinámicos en WS-BPEL

Índice

1 Introducción


3 Optimizaciones

4 Experimentos

5 Conclusiones


Invariantes dinámicos en WS-BPEL Arquitectura

Arquitectura general de GDI [Ernst]

Implementada usando sistemas libres y código propio:

Sistema resultante:



Composición del préstamoSe muestra cada fase de la arquitectura con un ejemplo

ClienteCant

Cant<10.000

Asesor

Riesgo<>alto

Aprob=1

ClienteAprob

Sí

Sí

No

No

AprobAprobador

Riesgo



Fase de Instrumentalización

ObjetivoPreparar ficheros para que al ejecutarse generan información de flujo decontrol y de valores de variables

Proceso WS-BPEL original

Etapa de Instrumentalización

Instrumentalizador

Ficherosespecíficos del motor

Proceso WS-BPELinstrumentalizado



Instrumentalizado

DecisiónConsiderar PP las entradas y salidas de bloques de actividadesEl usuario indica si instrumentalizar o no un PP y qué variables registrar

ProblemaActiveBPEL genera información de flujo de control de la ejecución de unacomposición, pero no registra los valores de variables

SoluciónIntegrar en ActiveBPEL funciones XPath (código propio) que registran elcontenido de variables (sin modificarlas)



Código WS-BPEL no instrumentalizado simplificado

<copy><from>true </from><to>proce s sOutput . accept </to>

</copy>



Código WS-BPEL instrumentalizado simplificado

reg(’processOutput’)

<copy><from>true </from><to>proce s sOutput . accept </to>

</copy>

reg(’processOutput’)



Fase de ejecución

ObjetivoEjecutar los casos de prueba sobre la composición instrumentalizada

Etapa de Ejecución

BPELUnitServicios simulados

Mensajes

Registros de ejecución de

casos de prueba

ExtensionesXPath deregistro

ActiveBPEL

Especificación decasos de prueba

Serviciosreales

Mensajes

Ficherosespecíficos del motor


Cambio de llamadasa servicios simulados



Ejecución

Pasos que realiza BPELUnit1 Desplegar la composición en el motor ActiveBPEL2 Lanzar el servidor de SW simulados3 Para cada caso de prueba

1 Si procede, configurar SW simulados2 Invocar a la composición con los parámetros correctos3 Almacenar resultados

4 Replegar la composición



Fragmento simplificado del registro de ejecución extendido

INSPECTION(processOutput.accept) = false

Execu t i ng [ ( . . . ) copy ]Completed no rma l l y [ ( . . . ) copy ]

INSPECTION(processOutput.accept) = true



Fase de análisis

ObjetivoEjecutar el generador de invariantes Daikon con la información recopilada

Registros de ejecución de

casos de prueba

Daikon

Ficheros específicosde Daikon

Invariantes inferidos

Etapa de análisis

Preprocesador




Análisis

Daikon necesitaLos registros de ejecución en su formato de entradaUn fichero de declaracionesDe cada variable inspeccionada en un PP indica:

NombreTipo original (XML Schema)Tipo para Daikon (Java)



Fichero de declaraciones simplificado

SmallAmountLowRisk : : : ENTERproce s sOutput . accep txsd : boo l eanboo l ean

SmallAmountLowRisk : : : EXITproce s sOutput . accep txsd : boo l eanboo l ean



Ejemplo de invariantes

Cuando la cantidad es pequeña y riesgo es bajo

SmallAmountLowRisk : : : ENTERas s e s s o rOu tpu t . r i s k = " low "p r o c e s s I n p u t . amount < 10000proce s sOutput . accep t = 0

SmallAmountLowRisk : : : EXITa s s e s s o rOu tpu t . r i s k = " low "p r o c e s s I n p u t . amount < 10000proce s sOutput . accep t = 1


Invariantes dinámicos en WS-BPEL Análisis de resultados

Ejemplo de invariantes que muestran errores

Código WS-BPEL simplificado con errorEn la condición de un if, donde había un = se pone un ! =

<i f >( a s s e s s o rOu tpu t . r i s k != ’ h igh ’ )

Los invariantes muestran el error

SmallAmountLowRisk : : : ENTERas s e s s o rOu tpu t . r i s k = " h igh "

Smal lAmountHighRisk : : : ENTERas s e s s o rOu tpu t . r i s k = " low "


Invariantes dinámicos en WS-BPEL Correspondencia XML Schema

Tipos de datos en WS-BPEL y Daikon

ProblemaXML Schema permite definir variables tipo árbolPero Daikon sólo puede procesar estructuras de una dimensión

SoluciónDividir cada variable tipo árbol de más de un nivel en varias variables tipovector unidimensional (respetando parte de la estructura del árbol)

ImplementaciónTakuan incorpora dos técnicas para solucionar este problema:

Aplanado (matrix slicing)División (matrix flattening)

Ejemplo con variable ficticia de ventasM. Palomo (UCA) Invariantes dinámicos para composiciones WS-BPEL 26 / 67


Venta [1]

Artículo [1]

Precio [1]

Pedido [1]

Artículo [2]

Precio [2]

Artículo [3]

Precio [3]

Pedido [2]

Artículo [4]

Precio [4]

Venta [2]

Artículo [5]

Precio [5]

Pedido [3]



Correspondencia mediante aplanado

FuncionamientoCrea una variable por cada tipo de elemento hoja (da igual sus ancestros)siguiendo el orden del documento



Venta [1]

Artículo [1]

Precio [1]

Pedido [1]

Artículo [2]

Precio [2]

Artículo [3]

Precio [3]

Pedido [2]

Artículo [4]

Precio [4]

Venta [2]

Artículo [5]

Precio [5]

Pedido [3]

Venta.Pedido.Artículo

Artículo [2]

Artículo [3]

Artículo [4]

Artículo [5]

Artículo [1]

Venta.Pedido.Precio

Precio [2]

Precio [3]

Precio [4]

Precio [5]

Precio [1]



Discusión de correspondencia mediante aplanado

VentajasGenera invariantes sobre todos los elementos de un determinado tipoen la estructura originalEl número de variables se mantiene constante sobre el número deelementos y el nivel de anidamiento

InconvenientesRompe bastante la estructura del árbol original



Correspondencia mediante división

FuncionamientoDivide iterativamente el árbol desde la raíz hasta que queden un vectorunidimensional por cada tipo de variable hoja



Venta [1]

Artículo [1]

Precio [1]

Pedido [1]

Artículo [2]

Precio [2]

Artículo [3]

Precio [3]

Pedido [2]

Artículo [4]

Precio [4]

Venta [2]

Artículo [5]

Precio [5]

Pedido [3]

Venta[1].Pedido[1].Artículo

Artículo [2]

Venta[1].Pedido[1].Precio

Precio [2]


Artículo [4]


Precio [4]



Artículo [1]

Artículo [3]

Artículo [5]

Precio [1]

Precio [3]

Precio [5]



Discusión de correspondencia mediante división

VentajasPermite obtener invariantes de elementos concretosCada variable es un conjunto de elementos contiguos en el árbol XMLoriginal

InconvenientesLa cantidad de variables se incrementa considerablemente al aumentarlas dimensiones y los elementosLas variables resultantes son independientes a todos los efectos



Composición de la metabúsqueda

DescripciónBusca en Google y MSN webs relacionadas con un términoDevuelve sus resultados intercalados empezando por Google



Invariantes en metabúsqueda con aplanado

maxGoogle one o f { 0 , 1 , 3 }

r e s u l t [ ] . from e l ement s one o f { " Google " , "MSN" }



Invariantes en metabúsqueda con división

maxGoogle one o f { 0 , 1 , 3 }

r e s u l t [ 1 ] . from one o f { [ Google ] , [MSN] }r e s u l t [ 2 ] . from one o f { [ Google ] , [MSN] }r e s u l t [ 3 ] . from one o f { [ Google ] , [MSN] }r e s u l t [ 4 ] . from e l ement s = "MSN"r e s u l t [ 5 ] . from e l ement s = " Google "r e s u l t [ 6 ] . from e l ement s = "MSN"

s i z e ( r e s u l t [ 3 ] . from ) one o f { 0 , 1 }s i z e ( r e s u l t [ 4 ] . from ) one o f { 0 , 1 }s i z e ( r e s u l t [ 5 ] . from ) one o f { 0 , 1 }s i z e ( r e s u l t [ 6 ] . from ) one o f { 0 , 1 }



Resumen

Dos tipos de correspondencia complementarias:

AplanadoGenera menos variables e invariantes, pero más generalesMenor tiempo de cómputoAdecuado para visión general de la composición

DivisiónGenera muchas variables e invariantes muy concretosMayor tiempo de cómputoAdecuado para observar comportamientos en detalle


Invariantes dinámicos en WS-BPEL Resultados

Rendimiento medido

Tiempo de ejecuciónEn metabúsqueda es bastante alto:

200 casos ≈ +horaDiferencia entre división (≈ +20%) y aplanadoReducible seleccionando PP (64) o campos de variables (> 10,000)

SalidaSe obtienen invariantes no deseables

Invariantes que informan de restricciones XML SchemaInvariantes no informativos (variables no relacionables)

Es necesario implementar optimizaciones


Optimizaciones

Índice

1 Introducción


3 Optimizaciones

4 Experimentos

5 Conclusiones


Optimizaciones

Análisis de rendimiento

Desglose del tiempo de ejecuciónHay tres pasos en el proceso:Instrumentalización tiempo constante

Ejecución BPELUnit y ActiveBPEL tienen tiempo linealAnálisis Daikon no es lineal

Time = O((vars3 ∗ Tfalsif + trueInvars ∗ casos) ∗ pp)

ComponentesSería deseable mitigarlos:Tfalsif y casos difíciles de reducirVars, trueInvars y pp con margen de mejora


Optimizaciones

Optimizaciones implementadasComparabilidad evita invariantes que relacionen variables sin conexiónFiltrado de variables y PP solo registra variables usadas en un PPRestricciones XML Schema no comprueba invariantes que informen de

restricciones de los tipos XML Schema


Optimizaciones Comparabilidad

Justificación

ObjetivoUsar información de comparabilidad implícita en la composición para evitarinvariantes sin sentido

EjemploUna composición puede tener tres variables tipo entero:

La edad de una persona que pide un préstamoEl código postal de su domicilioLos años de devolución del préstamo

Solo edad y devolución son del mismo tipo semántico (años naturales)



Implementación

ProblemaDaikon admite un índice de comparabilidad en cada variable

Pero no puede calcularse estáticamente por XPathAnalizar comparabilidad de campos accedidos en tiempo de ejecución

SoluciónAmpliar los registros de ActiveBPEL con los tipos abstractos



Algoritmo

Se analiza el uso de los miembros de cada expresiónLas variables de una expresión pertenecen a un mismo tipo abstracto, salvo:

Argumentos de una llamada a función (excepto min, MAX y similares)Operadores relacionales and, or y notPredicados de filtrados de conjuntos de nodos

Ejemplo:

( max(cliente[i].edad,edadAvalista) < umbral ) and solvente(dni,visa)

Se agrega la información de todos los casos de prueba



Fichero de declaraciones de la metabúsqueda simplificado

DECLAREGoog leSearch . queryxsd : s t r i n gS t r i n g6

i n p u tV a r i a b l e . l anguagexsd : s t r i n gS t r i n g3

i n p u tV a r i a b l e . que ryxsd : s t r i n gS t r i n g6



Resultados en la metabúsqueda

ComparabilidadReducción de número de invariantes (≈ −10%)Se eliminan invariantes no informativosEj, si un buscador dejaba vacíos día y hora, se obtenía:

result.day = result.hour



Filtrado de variables no usadas

Problemática con ámbitos de variables en WS-BPELLa colaboración entre actividades es mediante variables compartidas

Las variables son accesibles en muchos PPPero solo se suelen usar ciertos campos en algunos de ellos

SoluciónRegistrar campos de variables sólo en los PP donde se usanSi un PP no tiene variables registradas se puede eliminar




Filtrado de variablesMuy agresivo: ≈ −90% registros de variables y de invariantesReduce significativamente el tiempo de ejecución (≈ −70% a −80%)


Optimizaciones Restricciones XML Schema

Problemática

Restricciones XML SchemaXML Schema permite definir restricciones sobre las variables arbóreas:longitudes máximas o mínimas, listas de valores válidos, etc

ProblemaSe infieren como invariantes: no aportan información y consumen tiempoCon correspondencia por división se multiplica el problema

SoluciónAmpliar Daikon para que acepte una lista de propiedades que no comprobaráTambién válida para otros lenguajes que usen tipos con restriccionessimilares (vectores de tamaño fijo, etc.)



Fichero de declaraciones ampliado

DECLARESmallAmountLowRisk : : : ENTERas s e s s o rOu tpu t . r i s kRiskTypeS t r i n g2



Fichero de declaraciones ampliado

DECLARESmallAmountLowRisk : : : ENTERas s e s s o rOu tpu t . r i s kRiskType # minlength=1, maxlength=1, values=["high", "low"]S t r i n g2




Restricciones XML SchemaCon aplanado resultados muy similaresCon división desaparecen de 600 a 9.000 invariantes (≈ −30%)


Experimentos

Índice

1 Introducción


3 Optimizaciones

4 Experimentos

5 Conclusiones


Experimentos

Composiciones

Se han realizado experimentos conMercado de compraventa: 53 instrucciones, 3 variablesPréstamo (2 versiones): ≈ 110 instrucciones, 6 variablesMetabúsqueda (2 versiones): ≈ 600 instrucciones, 20 variables

EstructuraBasados en los realizados por Ernst


Experimentos

Casos de prueba aleatorios

ObjetivoDemostrar la convergencia de Takuan usando casos de prueba aleatorios

EstructuraSe generan 5 casos de prueba aleatorios, y se ejecuta en TakuanSe añaden al conjunto 5 más y se ejecutan los 10Se añaden al conjunto 10 más y se ejecutan los 20. . . hasta que la salida se estabiliza

Se comparan los resultados del conjunto más completo con los demás


Experimentos

Casos de prueba con distintas coberturas

ObjetivoDemostrar la convergencia de la GDI con Takuan usando casos de pruebacon distinta cobertura del flujo de ejecución

EstructuraCinco conjuntos casos de prueba de igual tamaño pero con distintascoberturas

AleatorioInstrucciones (dos conjuntos)RamasCaminos

Se ejecutan en Takuan y se almacenan resultadosSe comparan los resultados con cobertura de caminos con las demás


Experimentos

Análisis de resultados

AleatoriosEstabilización con distinta cantidad de casos de prueba:

En metabúsqueda se necesitaron de 100 a 500 casos de pruebaEn composiciones pequeñas menos de 50

Por coberturasMejora progresiva de resultados al mejorar la cobertura:Diferencias en invariantes (sobre 66): 7, 5, 3 y 2Poca diferencia entre cobertura por ramas y de caminos

Tanto la cantidad de casos aleatorios como su cobertura son indicadores dela fiabilidad de los invariantes generados


Conclusiones

Índice

1 Introducción


3 Optimizaciones

4 Experimentos

5 Conclusiones


Conclusiones Resumen

Objetivos cumplidosAdecuación de la GDI para WS-BPELDiseño de una arquitectura para la GDI en WS-BPELSe ha implementado Takuan, el único generador dinámico deinvariantes para WS-BPEL hasta la fechaTakuan recibe una composición y un conjunto de casos de prueba, ygenera invariantes automáticamenteSe ha probado su utilidad para detectar errores en una composiciónIncorpora optimizaciones para eliminar invariantes no deseablesSe ha estudiado su estabilidad con entrada aleatoria y según cobertura


Conclusiones Resumen

AportacionesIntegración en ActiveBPEL de funciones XPath de registroDesarrollo de dos modelos de correspondencia XML Schema a JavaImplementación optimizaciones específicas:

Comparabilidad basada en expresiones de las ejecucionesRegistro de campos de variables (y PP) según usoAmpliación de Daikon para que acepte invariantes conocidos: aplicado aXML Schema, válido para otros lenguajes


Conclusiones Trabajos futuros

Trabajos futurosImplementar otras correspondencias XML Schema para composicionesdonde proceda usarlasEstudio cualitativo del comportamiento del sistema: tamaño deentrada, invariantes, filtrado de variables, etc.Comparación con otras propuestas de prueba para WS-BPELAmpliar el estudio a tecnologías relacionadas: BPMN, BPELScript,BPEL4People, etc.


Conclusiones Producción

Principales publicacionesRevista JCR (enviado):

Congresos internacionales:



Otros méritos

Comité científico WS-BPEL

Estancia en Moscú, Rusia

Capítulo de libro

Software libre y aportaciones alproyecto BPELUnit



Captura del plugin de Takuan para Netbeans



Captura de IdigInBPEL


Conclusiones Preguntas

Trabajo financiado por el Programa Nacional de I+D+I del Ministerio de Educacióny Ciencia y fondos FEDER, proyecto SOAQSim (TIN2007-67843-C06-04)

Gracias por su atención

¿Preguntas?

Esta tesis, los programas y datos necesarios para repetir sus experimentos y losresultantes de realizarlos están disponibles en la URL persistente

http://purl.org/mpalomo/tesis


http://purl.org/mpalomo/tesis

Conclusiones Licencia

Esta presentación es libre

© Manuel Palomo Duarte 2011, excepto los logotipos

Este trabajo se publica bajo la licencia:Creative Commons Attribution-Share Alike Licensehttp://creativecommons.org/licenses/by-sa/3.0/

Usted es libre de:copiar, distribuir y comunicar públicamente la obrahacer obras derivadas

Bajo las condiciones siguientes:Atribución Debes reconocer la autoría de la obra en los términos

especificados por el propio autor o licenciante.Licenciamiento Recíproco Si alteras, transformas o creas una obra a partir

de esta obra, solo podrás distribuir la obra resultante bajo unalicencia igual a ésta.


http://creativecommons.org/licenses/by-sa/3.0/

transparencias de tesis phd

Technology