Download Evaluación de plataformas para el desarrollo de WS

Evaluación de plataformas para
el desarrollo de WS
Manuel Palomo Duarte
Antonio García Domínguez
Índice
●
Evaluación de herramientas
–
●
Herramientas complementarias
–
●
Active BPEL Engine, Glassfish (OpenESB),
Apache ODE
soapUI, Eclipse Web Tools Platform/BPEL, ...
Creación de mockups
–
BPELUnit, WSDL2Java, respuestas SOAP, ...
●
Trabajo futuro
●
Comentarios finales
Evaluación de sistemas
●
Active BPEL Engine (+ Tomcat + JDK 5)
–
–
Sistema completamente libre:
●
Active BPEL: GPL + LGPL + posiblemente otras
●
Tomcat: Apache License
Se analiza la estructura de los .bpr:
●
●
–
Incluyen los ficheros .bpel, .wsdl, .ppd, referencias
a WSDL externos
El .ppd indica, con WS-Addressing dónde está y
cómo acceder a cada partner
Plataforma elegida
Evaluación de sistemas
●
Glassfish (OpenESB)
–
También libre
–
Glassfish Incorpora un servidor de aplic. J2EE
pero necesita un motor BPEL
–
Glassfish + OpenESB (+ NetBeans)
–
Es muy pesado (incorpora CORBA, BBDD, ...)
–
El editor que trae para BPEL, WSDL, etc está
muy bien
Evaluación de sistemas
●
Apache ODE (+ Tomcat)
–
También libre
–
No tiene interfaz web para controlar los
servicios (hay que hacerlo desde Axis)
–
El despligue de un proceso BPEL es similar a
ActiveBPEL
–
Se ve menos maduro que ActiveBPEL (acaba
de publicarse su primera versión estable)
Herramientas complementarias
●
soapUI
●
Eclipse Web Tools Platform:
–
●
Permite trabajar con Ajax, Xml, EJB, ... (pero
no BPEL)
Eclipse BPEL:
–
Quiere proporcionar soporte para crear,
editar, probar y depurar procesos BPEL
–
No está desarrollado completamente todavía
–
Será independiente del motor BPEL
●
soapMonitor (pertenece a Axis2)
●
ActiveBPEL Designer
Ejecución de casos de prueba
●
●
BPEL es un lenguaje concurrente:
–
Al llegar determinados mensajes se crean
instancias paralelas
–
Cada servicio puede tener una respuesta
para cada caso de prueba (sin relación 1 a 1
con las entradas que reciba)
Solución:
–
Tener en cada momento una sola instancia
en ejecución y preparar el entorno (mockups)
específico para ella
Control de Estado
●
Uno de los retos es el control de estado:
–
Puede ser que quiera invocar dos veces un
mismo servicio con iguales parámetros pero
que cada vez me de un valor distinto.
Ejemplos:
●
Predicción meteorológica
●
Seleccionar datos aleatorios de un conjunto
–
Se puede solucionar añadiendo marcas de
tiempo y correlación (hay que cambiar el
WSDL)
–
¿Los ejemplos de BPEL lo necesitan?
Creación de mockups
●
Varias alternativas
–
Crear procesos BPEL
–
Crear WS mockups
–
●
WSDL2Java (del proyecto Apache AXIS2)
●
Apache CXF, ZoleraSOAP (no evaluados)
Crear respuestas SOAP
●
●
Hacerlas nosotros (necesita servidor HTTP +
Proxy)
Sistemas ya realizados (para usar)
–
Usar BPELUnit
–
Usar custom calls de ActiveBPEL
Mockups BPEL
●
●
Ventaja:
–
Es muy fácil realizar un procesos BPEL que al
recibir un mensaje devuelvan otro
–
Pueden implementar estado con un bucle de
espera de mensajes. Probado en ActiveBPEL,
pero aviso de falta de correlación (lo
soluciona incrustando un ID en la cabecera
SOAP)
Problema:
–
Hay que instalarlos, desplegarlos y lanzar
una instancia para cada caso de prueba
Mockups WS: WSDL2Java
●
WSDL2Java
–
Funciona:
●
Se invoca wsdl2java.sh
●
Se pone la respuesta que dará en un método
●
Se compila y se instala
–
Para que nos sirviera habría que convertir la
especificación del caso de prueba a código
Java para incluirlo en el método
–
Implementar el control de estado parece fácil
–
Algunas opciones cambian de AXIS a AXIS2
Respuestas SOAP propias
●
Como SOAP va sobre HTTP hay que tener
un servidor HTTP:
–
Tomcat es pesado y no es fácil de manejar
–
Sería mejor un servidor ligero que pueda dar
respuestas HTTP predefinidas:
●
●
●
Fallo, WS no encontrado, conexión con el WS,
timeout...
Se implementa dicho servidor
Se crea las respuestas SOAP
automáticamente indicando su cuerpo
Ejemplo de respuesta SOAP
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envel
ope/">
<soapenv:Body>
<ns2:servicioAsesorRiesgoOperationResponse xmlns:ns2="http://j2ee.netbeans.org/wsdl/servicioAse
sorRiesgo">
<riesgo>bajo</riesgo>
</ns2:servicioAsesorRiesgoOperationResponse>
</soapenv:Body>
</soapenv:Envelope>
Uso de BPELUnit
●
●
●
Permite hacer pruebas unitarias de
procesos desplegados en BPEL
Se puede incorporar el motor ActiveBPEL
a BPELUnit (es GNU/GPL)
Podría facilitar el desarrollo:
–
●
●
Integración con Eclipse, tareas para Ant
Se han ejecutado varios casos de prueba
sobre él correctamente
Línea de trabajo hasta ahora, parece
interesante
Demostración uso de BPELUnit
●
●
Requisitos software:
–
BPELUnit 1.0 (la más reciente)
–
ActiveBPEL 4.1 (motor BPEL)
–
Tomcat 5.5.25 (contenedor servlets)
–
Ant 1.7.0
–
Sun JDK 5.0 o superior (incluye JVM)
Configuración:
–
BPELUNIT_HOME tiene la ruta a BPELUnit
–
CATALINA_HOME tiene la ruta a Tomcat
–
JAVA_HOME tiene la ruta a la JVM
Uso custom ActiveBPEL
●
●
ActiveBPEL incorpora custom invoke
handler:
–
Se enlaza/asocia (bind) las definiciones
WSDL al manejador que indiquemos (escrito
en Java)
–
El motor no invoca al servicio, sino el código
Java de su máquina que tiene asociado
Descubierta esta semana, no evaluada
por ahora
Trabajo futuro I
●
●
Analizador del árbol XML de BPEL:
–
Permite conocer valores límite
–
Permite instrumentar el código
–
Según parece está ya realizado por Antonia
Reina, miembro del proyecto (US)
Incluir asertos en el código BPEL:
–
El estándar permite extender BPEL
–
Hay que buscar una sintaxis adecuada
●
BPELUnit usa expresiones XPath booleanas
Ejemplo XPath
<sendReceive
port="BookingProcessPort"
operation="process"
service="client:BookingProcess">
<send>
<data>
<client:bookme>
<client:employeeID>848</client:employeeID>
</client:bookme>
</data>
</send>
<receive>
<condition>
<expression>
client:bookinganswer/client:booked/text()
</expression>
<value>'true'</value>
</condition>
</receive>
</sendReceive>
Trabajo futuro II
●
●
Instrumentador de código BPEL
–
Analizar las variables de la composición
–
Enviar sus valores a WS de log antes y
después de cada operación de interés
Añadir características de BPEL a Daikon
–
●
Timeout, compensaciones, etc
¿Los ejemplos de BPEL necesitan control
de estado?
–
Si usamos ejemplos sencillos no
Comentarios finales
●
Cuidado con el código que usamos:
–
–
El estándar final BPEL 2.0 ha cambiado
algunos detalles de la sintaxis:
●
Asignaciones con Xpath (no getVariableData)
●
Atributo query ahora es un elemento anidado
Hay ejemplos BPEL que usan extensiones de
algunos motores concretos (Oracle BPEL)