Espacio SOA

Vale, estamos en ello; tenemos entre manos el proyecto SOA del siglo y es terriblemente importante que salga adelante y lo haga bien (con lo que cuesta todo como para no hacerlo)

Y es en este punto cuando nos planteamos como realizar pruebas correctas de la arquitectura para comprobar que realmente estamos construyendo una arquitectura orientada a servicios y no una simple aplicación muy cara.

La verdad, cuando hablamos de testear una Arquitectura SOA, tenemos que plantearnos ciertas cuestiones y elegir las herramientas adecuadas; ya que difiere bastante de la forma tradicional de probar aplicaciones normales.

Es importante tener en mente la arquitectura, sus partes, sus dominios; e intentar dividir la misma en partes pequeñas que sean más faciles de probar; para posteriormente ir probando la integración de las mismas hasta llegar a un punto de arquitectura más o menos global.

Por ello, ante todo, tenemos que tener en mente unos objetivos a conseguir durante las pruebas de nuestra arquitectura:

1. Los servicios son y deben ser siempre reutilizables. Es una de las máximas de SOA y si no conseguimos eso, posiblemente la arquitectura estará abocada al fracaso.
2. Agilidad en los cambios: los procesos y la orquestación de servicios buscan la facilidad de composición de los mismos. Un cambio debería ser rápido y fácil de hacer si la capa base de servicios es la correcta y funciona correctamente.
3. Monitorización : ey! eso que llaman BAM. Es importante tener siempre visible nuestra arquitectura, en tiempo real; para detectar errores, cuellos de botella y otros factores que indiquen la necesidad de un cambio para la optimización de la misma.
4. Interoperabilidad : SOA habla de reutilización y como tal nuestra arquitectura al nivel más alto posible debería ser así. No solo se trata de que nuestros servicios sean reutilizables en referencia a nuestra arquitectura; sino que incluso lo sean de cara al exterior. Las posibilidades de reutilización entre empresas debe ser importante: por ello, cuanto más estándar, mejor que mejor.

Testear una arquitectura SOA pasa por tener en cuenta los dominios de la misma que debemos asegurar en fiabilidad y consistencia; esto es, que debemos probar:

1. Pruebas a nivel de servicio: Son la base de SOA y por tanto la base de toda la arquitectura. Probarlos a nivel de su funcionalidad es importante; pero más importante es probarlos asegurandonos su reutilización (incluso habrá ya servicios como composición de otros).
   Es importante, tener en cuenta que los servicios no son aplicaciones en sí mismas y por tanto deben ser probados atendiendo a ese factor (son independientes, aislados, sin estados, etc…). La mejor manera para probarlos es definir los casos de prueba de los servicios y ejecutarlos para comprobar su correcto funcionamiento.
   Además, hay que tener en cuenta que los servicios son autónomos (sin dependencias de otros servicios) y con una granularidad adecuada (no se trata de que sean ni muy atómicos ni muy complejos; las necesidades determinarán en cada caso como deben ser; pero es importante que tengan un sentido a nivel funcional para la empresa).
2. Pruebas a nivel de seguridad: intentar probar los servicios con una capa de seguridad añadida desde el principio puede ser más complejo de lo que parece. Es mejor probarlos de manera simple y aislados y luego probar la capa de seguridad que tenga nuestra arquitectura añadida a los servicios.
3. Pruebas de orquestación: como estamos hablando de composición; en algún momento tendremos orquestación de servicios y este dominio debería ser probado a partir de unos servicios fiables y seguros. En este momento estaremos hablando de pruebas que determinan la correcta comunicación entre servicios; el trabajo de manera conjunta.
   Estaremos hablando también de procesos de negocio (pruebas a nivel BPM) por lo que debemos verlo como una capa superior a probar.
4. Pruebas de gobernabilidad: la gobernabilidad de SOA es algo muy importante y en buena medida puede ser determinante para la consecución satisfactoria de nuestra arquitectura. Es importante probar las políticas de las distintas capas que se hayan definido, los ciclos de vida y cualquier concepto de gobernabilidad que se haya introducido y deba ser probado.
5. Pruebas de integración: bueno, más o menos tenemos todo probado; solo quedaría verlo en producción sin ningún error.
   Antes de eso es importante hacer pruebas de integración de nuestra arquitectura. El objetivo de estas pruebas es principalmente, determinar el correcto funcionamiento de las interfaces de comunicación de los distintos componentes.

Aunque no lo parezca, probar una arquitectura SOA definiendo diversos niveles y dominios de aplicación es realmente importante; ya que sino podemos encontrarnos con desagradables sorpresas.

Por ello, es recomendable que esta fase de pruebas (el Plan de Pruebas) este siempre presente en la planificación de cualquier arquitectura de este tipo.

Articulos Interesantes:

What is SOA test?
SOA Testing
SOA World - Approaching SOA Testing
Ready to Test SOA, Web Services, ESBs and BI?