Mejores prcticas SOA

Impartir capacitacin en visin y tecnologa SOA

Como se mencion en la introduccin, es importante tener un conocimiento de
los aspectos y las expectativas comunes de SOA para poder concentrar la
atencin en el esfuerzo de QA. Para ello ser necesario capacitar a los equipos
de TI respecto del alcance general del entorno SOA, incluyendo las reas de la
empresa que estn involucradas, los sistemas que participan en la prestacin
de servicios y los sistemas que sern nuevos consumidores de servicios.
Tambin deben conocer las normas, las instrucciones y la gobernanza
implementadas con la iniciativa.
Adems de la capacitacin en la iniciativa SOA, los equipos deber sentirse
seguros con las tecnologas de servicios web que se requieren para las
pruebas. Entre ellas estn XML (estructura, espacios de nombres y esquemas)
y WSDL.
As, la planificacin de la capacitacin en estas reas es una parte permanente
de la iniciativa SOA.

Mantener suites de pruebas de integracin de servicios automatizadas
Los servicios estratgicos principales tienen una expectativa de fcil consumo,
as como una mayor reutilizacin a lo largo del tiempo. Sus sencillas interfaces
deben esconder las complejidades de la integracin en los diferentes sistemas
de back-end subyacentes. Por este motivo existe un riesgo ms alto para la
calidad de los servicios que debe ser contenido. Un cambio producido dentro
de cualquier nivel de la pila de implementacin de un servicio podra originar
una regresin en las capacidades del servicio. En esta situacin, es necesario
detectar la regresin tempranamente y aislarla de inmediato para determinar e
implementar los ajustes necesarios antes de la siguiente actualizacin de los
sistemas.

A fin de gestionar la calidad de cada uno de los servicios estratgicos, se
recomienda mantener una suite automatizada de pruebas junto con el servicio
(en [2] encontrar instrucciones especficas para crear esta suite con servicios
compuestos). La suite debe ser ejecutable segn las necesidades, con escaso
o nulo tiempo de configuracin, y debe impactar en los principales
componentes dentro de cada nivel de la pila de servicio.
Una prctica de gobernanza relacionada consiste en certificar un servicio para
su uso solo cuando se verifique que su suite de pruebas de integracin
automatizada existe y se mantiene.

Adoptar un marco de pruebas de servicios
A fin de automatizar y mantener suites de pruebas de integracin de servicios,
existen ciertas capacidades comunes que se deben desarrollar y reutilizar.
Entre ellas se encuentran:

1. La capacidad de producir agentes de prueba en ausencia de la interfaz de
usuario de una aplicacin
2. Generacin de mensajes de prueba, basados en la descripcin del servicio
(WSDL)
3. Variacin de datos de entrada, usando una tabla de datos
4. Scripts de desmontaje y configuracin de datos
5. Datos de salida de informes de pruebas
6. Definicin de resultados esperados
7. Ejecucin de pruebas en cada nivel integrado de la pila (por lo general, a
travs de un entorno de prueba unitaria)
8. Emulacin de servicios externos (falsos)
9. Inspeccin y validacin de mensajes de servicio de aplicaciones
consumidoras
10. Envo de mltiples mensajes de prueba a travs de subprocesos
separados

Estas capacidades vienen empaquetadas en un marco integrado de pruebas
(ITF, por su sigla en ingls). Por lo general, el marco est compuesto de
herramientas comerciales o de cdigo abierto combinadas con
personalizaciones para satisfacer las necesidades especficas del entorno.
En lugar de implementar estas capacidades para cada uno de los servicios, es
aconsejable mantener el ITF como un activo individual reutilizable que
contenga las utilidades, herramientas y scripts ms comunes. Se recomienda
que el marco est basado en una herramienta de pruebas funcionales (ver [3] y
[4]).


Figura 5. Marco integrado de pruebas (ITF)



Usar falsos servicios para probar consumidores antes de la integracin
con proveedores
Los falsos servicios permiten ejecutar pruebas cuando el proveedor real no
est disponible. Esto contribuye al desarrollo de pruebas de servicio, pero
tambin puede ayudar a aislar las pruebas de consumidores antes de la
integracin con el servicio completo.
En el caso de una sincronizacin de proyectos imperfecta, como cuando un
servicio est en proceso de desarrollo y el consumidor necesita proceder con
otras pruebas, es posible alojar falsos servicios en lugar de servicios reales. La
produccin de falsos servicios debera ser una capacidad del ITF para su uso
en esas situaciones.


Figura 6. Falso servicio


Usar suites de pruebas para probar servicios adecuadamente antes de
integrar consumidores
Durante el desarrollo del servicio, tambin se debera desarrollar una versin
emergente de la suite de pruebas de integracin automatizada. De esta manera
se simplificar el proceso necesario para la determinacin y depuracin de
problemas. En caso contrario, resultar ms difcil determinar si el problema se
debe a los consumidores o a los proveedores.

Planificar pruebas de rendimiento
Las pruebas de rendimiento para medir la escalabilidad y la capacidad de
respuesta de los nuevos servicios deben formar parte del plan. Tambin es
necesario tomar en consideracin las pruebas de rendimiento con los nuevos
consumidores, ya que los diversos consumidores pueden tener diferentes
caractersticas de carga. El ITF debera incluir la capacidad de escalar el
nmero de solicitudes paralelas.

Es necesario tomar medidas de rendimiento para la implementacin del
servicio de manera temprana y permanente. No se puede esperar hasta el final,
ya que los cambios de diseo pueden ser costosos.

Asignar tiempo suficiente para la configuracin y la validacin de
seguridad
En el caso de las implementaciones de seguridad del servicio, se deben tener
en cuenta una serie de lecciones:

1. Puede ser difcil depurar los protocolos de enlace del servicio cuando la
solucin est asegurada de extremo a extremo, p. ej., en el caso de los perfiles
de smbolo (token)
2. Los escenarios de casos de prueba negativos son mucho ms frecuentes
que los casos positivos (p. ej., reconocimiento y procesamiento de un mensaje)
3. En cuanto a las interfaces de usuario de uso final, se deben desarrollar
casos de prueba que validen todo lo que los usuarios pueden hacer en la
solucin en contraste con lo que tienen permitido hacer en las aplicaciones de
soporte
4. Es necesario que el ITF pueda invocar servicios seguros
5. Solamente un subconjunto de las especificaciones WS-Security es
interoperable en las diferentes implementaciones de marcos de proveedor y de
cdigo abierto; asigne tiempo para soluciones alternativas
6. Las pruebas con socios o consumidores externos se deben planificar de
manera de incluir un registro de mensajes y parmetros del lado del
consumidor para reducir los esfuerzos de depuracin

Disear capacidades de instrumentacin y registro
A fin de identificar y reducir los problemas de manera rpida dentro de las
implementaciones SOA, especialmente en el caso de flujos de procesos
complejos, se recomienda usar un registro. El registro debera ser
intercambiable en mltiples niveles de detalle y debera permitir la correlacin
de informacin de seguimiento en los diferentes sistemas, p. ej., a travs del
registro preciso de marcas de tiempo o de identificadores de encabezado.

Emplear pruebas de humo en el entorno
Las soluciones SOA suelen depender de muchos componentes de integracin,
como Enterprise Service Bus (ESB) y puertas de enlace. Dadas las
numerosas partes mviles, las pruebas de estos componentes, antes de la
implementacin completa dentro de cada entorno, deberan ser las habituales.
La reduccin de problemas puede volverse ms difcil y larga si no se han
validado los componentes de entorno y de integracin con anterioridad.

Adoptar prcticas generales de desarrollo controlado por pruebas
Varias de las prcticas descriptas en este artculo pueden clasificarse como
prcticas generales de desarrollo generado por pruebas (TDD). TDD
recomienda efectuar las pruebas de una manera temprana y constante, como
en el caso de cada compilacin de sistema. A medida que los sistemas
evolucionan, surge la necesidad de contar con diferentes formas de agentes de
prueba, incluida la capacidad de falsear o arrancar las partes que no estn
listas para el horario central.
Teniendo en cuenta la complejidad y los requisitos de coordinacin de muchos
proyectos SOA, no es rara la aplicacin de prcticas de desarrollo
incrementales o iterativas. Se recomienda usar principios TDD para
complementar esos proyectos, permitindoles obtener comentarios
instantneos basados en las pruebas respecto de los ltimos cambios.

Planificar cuidadosamente la estrategia de prueba
La estrategia de prueba da detalles del proyecto o de la versin, como las
responsabilidades de las pruebas y los tipos de pruebas que se deben realizar.
Debera incluir planes relativos a la capacitacin, la generacin de suites de
pruebas de integracin de servicios, las pruebas de consumidores
independientes, las pruebas de rendimiento, la seguridad y la gestin de
dependencias (para aquellos escenarios comunes en los que los componentes
dependientes no sean lanzados en pasos manejables).
A efectos de una mayor consistencia, se recomienda usar instrucciones para
las prcticas predeterminadas en cada escenario posible. Esto incluira:

Pruebas y mediciones de pruebas para cada nuevo servicio
Generacin y ejecucin de suites integradas de pruebas para cada nuevo
servicio
Ejecucin de la suite integrada de pruebas para cada nuevo conjunto de
actualizaciones del sistema
Alojamiento temprano de falsos servicios o versiones de prueba de los
servicios reales para los nuevos consumidores