Adopción de mejores prácticas y lecciones aprendidas de SOA

Mudarse a una arquitectura orientada a servicios (SOA) genera numerosos beneficios para las empresas y aumenta la alineación y la agilidad de las soluciones. Para lograr una transición sin problemas, es necesario poner especial atención en la calidad y tomar conciencia de los singulares desafíos que implican las pruebas dentro de una SOA. Con frecuencia, los ajustes necesarios para probar competencias no son evidentes ni planificados. Las empresas deben comprender las metas y los desafíos específicos de la arquitectura de servicios, que está en permanente evolución, así como las implicancias de la manera en que realizan las pruebas. En este artículo, analizaremos los desafíos relacionados con la garantía de calidad (QA) que se deben abordar con la adopción de una SOA, así como las mejores prácticas recomendadas y las lecciones aprendidas.

Salil Ahuja, SOA Solutions Architect, IBM

Salil Ahuja photoSalil Ahuja es Technical Enablement Specialist dentro del grupo AIM Customer Programs de IBM y se especializa en WebSphere Dynamic Process Edition. Salil ayuda a los clientes con las nuevas versiones de las herramientas de gestión de procesos de negocios de IBM para dar mayor satisfacción a sus necesidades de negocios. Además, tiene años de experiencia de trabajo con importantes empresas del área de la salud. Comuníquese con Salil a sahuja@us.ibm.com.



04-08-2011

Introducción

A veces es tentador tratar los proyectos que implican una Arquitectura orientada a servicios (SOA) como cualquier otro proyecto anterior. Sin embargo, si se tienen presentes los singulares desafíos que presentan los proyectos en relación con las pruebas, es posible optimizar las prácticas de pruebas para satisfacer los requisitos de QA específicos de cada proyecto. El primer paso consiste en asegurarse de que los equipos de desarrollo y de pruebas estén familiarizados con todos los aspectos del proyecto que presenta desafíos. Entre estos aspectos podemos nombrar:

  1. Interfaces simples y de fácil consumo que esconden la complejidad
  2. Reutilización futura sin límites
  3. Complejidad técnica de la implementación en cada sistema de soporte
Figura 1. Complejidad y conexiones heterogéneas
Complejidad y conexiones heterogéneas
  1. Necesidad de coordinación entre las diferentes líneas de negocios
  2. Diferencia entere lógica de flujos de servicios y lógica de aplicación subyacente
  3. Necesidades de seguridad de servicios diferentes de seguridad de aplicaciones de soporte
Figura 2. Lógica y seguridad en múltiples ubicaciones
Lógica y seguridad en múltiples ubicaciones
  1. Los servicios como componentes de TI con gestión independiente

Los desafíos relacionados con las pruebas pueden ser consecuencia de estos atributos, tomados en conjunto o por separado. En este artículo se analizan algunos de los desafíos más comunes, así como las mejores prácticas que se pueden usar para solucionar los problemas.


Desafíos únicos de las pruebas en SOA

En los entornos SOA, el equipo de pruebas va más allá de las tradicionales pruebas de rendimiento y funcionalidad, que se centran en las aplicaciones. SOA requiere pruebas de integración de interfaces y servicios que sirvan para auxiliar y orquestar diversos sistemas y plataformas, junto con las normas de seguridad correspondientes.

Esto presenta desafíos únicos a la hora de probar estas aplicaciones.

Es posible que los servicios no tengan interfaz de usuario

Tradicionalmente, las aplicaciones cuentan con una interfaz gráfica de usuario (GUI) o una interfaz de usuario relacionada que se puede potenciar para realizar pruebas funcionales de manera manual o automática. En el caso de una SOA, los servicios del entorno no siempre tienen una interfaz. Los testers trabajan con protocolos de red y mensajes de diferentes tecnologías, como SOAP y servicios web. Además, los servicios expuestos encapsulan el proceso subyacente; por lo tanto, asegurar una cobertura de pruebas suficiente puede ser un desafío.

Se pueden usar herramientas de pruebas basadas en normas, como SOAPUI, para abordar los desafíos que se presentan cuando se trabaja con servicios web. Estas herramientas proporcionan la capacidad de generar clientes de prueba sobre la base del archivo Web Service Description Language (WSDL) del servicio, que ayuda a los testers a comprender las operaciones del servicio web e invocar este servicio.

Recopilación de datos

Un entorno SOA puede potenciar diferentes tecnologías y diferentes formatos de datos a partir de participantes internos y externos. Esto requiere que el equipo de QA valide la integración de todas estas tecnologías y formatos de datos. Es fundamental para este ejercicio recopilar los datos pertinentes antes de la implementación a fin de ejecutar todos los escenarios de prueba. Si los datos de prueba se recopilan con anterioridad, se garantiza que el ciclo de vida de QA no se verá afectado por la falta de disponibilidad de datos para ciertos ciclos de prueba.

Todo esto exige una fase de diseño más amplia y una gobernanza de SOA con participación conjunta del equipo de QA y las partes involucradas. La gobernanza de SOA está representada por un equipo central que preside todo el proceso de gestión y supervisión de SOA. El equipo de pruebas debe identificar sus necesidades de datos de pruebas y colaborar con los involucrados para obtener datos a medida que se implementa el servicio. El proceso de gobernanza de SOA debe asegurar la satisfacción de las necesidades del equipo de QA. Estas prácticas garantizan que, cuando el servicio esté listo para las pruebas de integración, el equipo de QA tendrá los datos necesarios.

Un mayor nivel de de integración requiere una mejor planificación y estrategia para abordar los problemas de disponibilidad

En un contexto tradicional, los testers prevén que la aplicación o la funcionalidad de negocios serán entregadas mediante un proyecto único en un solo servidor de aplicaciones expuesto a través de una interfaz Web. Con una SOA, la lógica de las aplicaciones está ubicada dentro del nivel intermedio, funcionando con un número indeterminado de tecnologías, residiendo fuera del departamento o incluso fuera de la empresa. Por este motivo, las pruebas de extremo a extremo, incluso en el entorno de prueba, dependen de terceros. Si un sistema externo crítico no se encuentra disponible, tendrá el potencial de interrumpir un ciclo de QA en caso de que el equipo de QA no esté preparado. Por eso, el equipo de QA deberá estar preparado para todas las situaciones.

Figura 3. Dependencia externa del flujo de procesos de servicios
Dependencia externa del flujo de procesos de servicios

Para que los equipos de QA puedan ejecutar ciclos de prueba con esa interrupción, es imprescindible que todos los involucrados sean proactivos en la comunicación y en la planificación de sus tiempos de inactividad. Existen ciertas herramientas, como SOAPUI y Rational Application Developer (RAD), que sirven para crear falsos servicios de marcadores a fin de adaptarse al tiempo de inactividad y a la falta de disponibilidad de ciertos servicios.

Los falsos servicios ayudan a los equipos de QA a reducir la dependencia respecto de los involucrados cuando se ejecuta la prueba de extremo a extremo. El equipo de QA puede crear servicios de marcadores que se comportan de manera similar a los servicios reales. Estos servicios son generados usando los esquemas reales (WSDL y compatibles) del servicio original. Luego se dota al falso servicio de un conjunto de respuestas, que se utiliza para responder a la solicitud del falso servicio. Las respuestas pueden ser aleatorias, consistir en una operación por turnos o basarse en ciertas reglas o directivas.

Figura 4. Dependencia externa del flujo de procesos de servicios: falso servicio
Dependencia externa del flujo de procesos de servicios: falso servicio

Se puede usar un falso servicio si, por cualquier motivo, el servicio original no está disponible. Esto contribuye a garantizar que los ciclos de QA no se vean afectados por el tiempo de inactividad de ciertos servicios. Los testers pueden crear servicios, una vez definidas las interfaces de servicio, a fin de alcanzar la solución de extremo a extremo sin necesidad de esperar el desarrollo del servicio real.

Los falsos servicios también sirven para aislar defectos mientras se depuran errores y se investiga su origen. Al estar tan controlados, los falsos servicios contribuyen a la creación de un entorno más controlado, especialmente al momento de diagnosticar defectos. De esta manera, los testers pueden impulsar escenarios de extremo a extremo y tener menos dependencias respecto de potenciales problemas en ubicaciones externas. Se recomienda generar un falso servicio para cada servicio web del proyecto.

Desafíos de seguridad

Dada la naturaleza de los entornos SOA que potencian los servicios independientes, la seguridad es un desafío todavía mayor. La solución de seguridad debe abordar todos los aspectos de seguridad típicos, es decir, autenticación, autorización, identificación correcta, integridad de mensaje, no rechazo, confidencialidad/privacidad y soporte de auditoría. Esto requiere el establecimiento a conciencia de relaciones de confianza, por lo general utilizando las normas de WS-Security. El conocimiento y las habilidades relativos a las normas, los protocolos y las convenciones que se utilizan son fundamentales para poder probar las medidas de seguridad.

Asimismo, los servicios están basados en la web, por lo que se requiere una diligencia similar a la de cualquier solución web. Las vulnerabilidades que se prueban con herramientas como Rational AppScan [5] se pueden seguir aplicando.

Es necesario incluir casos generales de prueba negativos respecto de las vulnerabilidades de seguridad. En esta lista se incluirían pruebas que garanticen:

  1. que las repeticiones sean denegadas, es decir, un mensaje copiado que se vuelve a enviar no debería ser aceptado
  2. que no se produzcan ataques de tipo “man-in-the-middle”
  3. que los mensajes sean confidenciales y no puedan ser modificados sin previo aviso
  4. que solo los usuarios legítimos puedan acceder a los servicios (incluida la denegación de esquemas de falsificación)

Necesidad de asegurar una excelente gestión de excepciones

Cuando interactúan diferentes servicios a través de un nivel común, es esencial probar/validar las condiciones de excepción y garantizar que el código use especificaciones basadas en normas para gestionar las condiciones de proceso perimetrales/negativas. Los flujos de procesos de negocios ayudan a modelar los servicios subyacentes que colaboran con los eventos de la secuencia de negocios. Si algún servicio no responde de la manera deseada, el proceso debería ser lo suficientemente sólido para gestionar esas condiciones y proporcionar notificaciones de esos errores. Cuando se pone a prueba el proceso, es esencial que estas condiciones perimetrales sean identificadas y probadas.

Desafíos de reutilización

La reutilización es uno de los principales beneficios de la SOA. Un servicio puede ser usado por varias aplicaciones, o quizás por algunas al comienzo de la adopción de la SOA, pero es posible que inmediatamente algunos servicios sean consumidos por una decena de aplicaciones o más. Si esos servicios no han sido diseñados y probados para su rendimiento con esa carga, algunas de las aplicaciones pueden verse afectadas por tiempos de respuesta inaceptables. En el peor de los casos, si los servicios no fueron probados a fondo y se produce un error en producción, el impacto de ese error puede ser catastrófico para toda la empresa, ya que varias aplicaciones se verían afectadas al mismo tiempo.

Curva de aprendizaje

Algunas tecnologías y normas, como SOAP, los servicios web, XML, BPEL y WS-Policy están en constante evolución. La adopción de estas tecnologías ha sido lenta y, por lo tanto, cuando las empresas hacen esfuerzos de modernización, deben tener en cuenta la correspondiente curva de aprendizaje. Los miembros del equipo de QA deben tener un profundo conocimiento de estas tecnologías y de sus beneficios, lo que les permitirá probar las soluciones SOA de manera eficaz.


Mejores prácticas

Impartir capacitación en visión y tecnología SOA

Como se mencionó en la introducción, es importante tener un conocimiento de los aspectos y las expectativas comunes de SOA para poder concentrar la atención 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 están involucradas, los sistemas que participan en la prestación de servicios y los sistemas que serán nuevos consumidores de servicios. También deben conocer las normas, las instrucciones y la gobernanza implementadas con la iniciativa.

Además de la capacitación en la iniciativa SOA, los equipos deber sentirse seguros con las tecnologías de servicios web que se requieren para las pruebas. Entre ellas están XML (estructura, espacios de nombres y esquemas) y WSDL.

Así, la planificación de la capacitación en estas áreas es una parte permanente de la iniciativa SOA.

Mantener suites de pruebas de integración de servicios automatizadas

Los servicios estratégicos principales tienen una expectativa de fácil consumo, así como una mayor reutilización a lo largo del tiempo. Sus sencillas interfaces deben esconder las complejidades de la integración en los diferentes sistemas de back-end subyacentes. Por este motivo existe un riesgo más alto para la calidad de los servicios que debe ser contenido. Un cambio producido dentro de cualquier nivel de la pila de implementación de un servicio podría originar una regresión en las capacidades del servicio. En esta situación, es necesario detectar la regresión tempranamente y aislarla de inmediato para determinar e implementar los ajustes necesarios antes de la siguiente actualización de los sistemas.

A fin de gestionar la calidad de cada uno de los servicios estratégicos, se recomienda mantener una suite automatizada de pruebas junto con el servicio (en [2] encontrará instrucciones específicas para crear esta suite con servicios compuestos). La suite debe ser ejecutable según las necesidades, con escaso o nulo tiempo de configuración, y debe “impactar” en los principales componentes dentro de cada nivel de la pila de servicio.

Una práctica de gobernanza relacionada consiste en certificar un servicio para su uso solo cuando se verifique que su suite de pruebas de integración automatizada existe y se mantiene.

Adoptar un marco de pruebas de servicios

A fin de automatizar y mantener suites de pruebas de integración 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 aplicación
  2. Generación de mensajes de prueba, basados en la descripción del servicio (WSDL)
  3. Variación de datos de entrada, usando una tabla de datos
  4. Scripts de desmontaje y configuración de datos
  5. Datos de salida de informes de pruebas
  6. Definición de resultados esperados
  7. Ejecución de pruebas en cada nivel integrado de la pila (por lo general, a través de un entorno de prueba unitaria)
  8. Emulación de servicios externos (falsos)
  9. Inspección y validación de mensajes de servicio de aplicaciones consumidoras
  10. Envío de múltiples mensajes de prueba a través de subprocesos separados

Estas capacidades vienen empaquetadas en un marco integrado de pruebas (ITF, por su sigla en inglés). Por lo general, el marco está compuesto de herramientas comerciales o de código abierto combinadas con personalizaciones para satisfacer las necesidades específicas 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 más 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)
Marco integrado de pruebas (ITF)

Usar falsos servicios para probar consumidores antes de la integración con proveedores

Los falsos servicios permiten ejecutar pruebas cuando el proveedor real no está disponible. Esto contribuye al desarrollo de pruebas de servicio, pero también puede ayudar a aislar las pruebas de consumidores antes de la integración con el servicio completo.

En el caso de una sincronización 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 producción de falsos servicios debería ser una capacidad del ITF para su uso en esas situaciones.

Figura 6. Falso servicio
Falso servicio

Usar suites de pruebas para probar servicios adecuadamente antes de integrar consumidores

Durante el desarrollo del servicio, también se debería desarrollar una versión emergente de la suite de pruebas de integración automatizada. De esta manera se simplificará el proceso necesario para la determinación y depuración de problemas. En caso contrario, resultará más difícil 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. También es necesario tomar en consideración las pruebas de rendimiento con los nuevos consumidores, ya que los diversos consumidores pueden tener diferentes características de carga.

El ITF debería incluir la capacidad de escalar el número de solicitudes paralelas.

Es necesario tomar medidas de rendimiento para la implementación del servicio de manera temprana y permanente. No se puede esperar hasta el final, ya que los cambios de diseño pueden ser costosos.

Asignar tiempo suficiente para la configuración y la validación de seguridad

En el caso de las implementaciones de seguridad del servicio, se deben tener en cuenta una serie de lecciones:

  1. Puede ser difícil depurar los protocolos de enlace del servicio cuando la solución está asegurada de extremo a extremo, p. ej., en el caso de los perfiles de símbolo (token)
  2. Los escenarios de casos de prueba negativos son mucho más 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 solución 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 código 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 parámetros del lado del consumidor para reducir los esfuerzos de depuración

Diseñar capacidades de instrumentación y registro

A fin de identificar y reducir los problemas de manera rápida dentro de las implementaciones SOA, especialmente en el caso de flujos de procesos complejos, se recomienda usar un registro. El registro debería ser intercambiable en múltiples niveles de detalle y debería permitir la correlación de información de seguimiento en los diferentes sistemas, p. ej., a través 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 integración, como Enterprise Service Bus (ESB) y puertas de enlace. Dadas las numerosas partes móviles, las pruebas de estos componentes, antes de la implementación completa dentro de cada entorno, deberían ser las habituales. La reducción de problemas puede volverse más difícil y larga si no se han validado los componentes de entorno y de integración con anterioridad.

Adoptar prácticas generales de desarrollo controlado por pruebas

Varias de las prácticas descriptas en este artículo pueden clasificarse como prácticas generales de desarrollo generado por pruebas (TDD). TDD recomienda efectuar las pruebas de una manera temprana y constante, como en el caso de cada compilación 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 están listas para el horario central.

Teniendo en cuenta la complejidad y los requisitos de coordinación de muchos proyectos SOA, no es rara la aplicación de prácticas de desarrollo incrementales o iterativas. Se recomienda usar principios TDD para complementar esos proyectos, permitiéndoles obtener comentarios instantáneos 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 versión, como las responsabilidades de las pruebas y los tipos de pruebas que se deben realizar. Debería incluir planes relativos a la capacitación, la generación de suites de pruebas de integración de servicios, las pruebas de consumidores independientes, las pruebas de rendimiento, la seguridad y la gestión 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 prácticas predeterminadas en cada escenario posible. Esto incluiría:

  • Pruebas y mediciones de pruebas para cada nuevo servicio
  • Generación y ejecución de suites integradas de pruebas para cada nuevo servicio
  • Ejecución 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

En la actualidad, las instrucciones detalladas de la planificación de pruebas están integradas dentro de las versiones actuales de SOMA [1], una tecnología de IBM.

Recursos

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=WebSphere
ArticleID=428425
ArticleTitle=Adopción de mejores prácticas y lecciones aprendidas de SOA
publish-date=08042011