El propósito de este artículo es presentar el método de prueba funcional y el método de prueba de rendimiento de Enterprise Service Bus. El método de prueba se desarrolla en base a un proyecto de cliente real y ha demostrado ser efectivo.

Yu Hong Song, Test Lead, IBM  

Yu Hong SongYu Hong Song is a test lead in IBM China. She joined IBM as a software engineer with master degree in 2007. She is part of Global Business Solution Center (GBSC) of GBS. Currently she is working on ITS solution testing.



Tao (Jerry) Liu, Advisory I/T Architect, IBM  

Tao (Jerry) LiuTao (Jerry) Liu is an accredited IT Architect in IBM China. He joined IBM as a research engineer with master degree in 2003. He is part of Global Business Solution Center (GBSC) of GBS. Currently he is working on ESB asset of common technology enabler initiative.



Jingfeng Zhang , Software Engineer, IBM  

Jingfeng Zhang Jingfeng Zhang is a Software Engineer in IBM China. He has more than 7 years of software development experience and joined IBM in 2007. He mainly focuses on the J2EE, MQ, WMB, SOA, ESB, EAI. He is a member of Global Business Solution Center (GBSC).



03-08-2011

Método funcional ESB

Como muestra la Figura 1, dentro de una arquitectura orientada a servicios, los solicitantes y proveedores de servicios se comunican entre sí a través de un ESB. Las principales capacidades que ofrece ESB son la transformación de mensajes, la conversión de protocolos y el ruteo de servicios. Las rutinas de integración se desarrollan en base al middleware ESB para mediar entre los solicitantes y proveedores de servicios. En este artículo se describen los distintos métodos de prueba de verificación funcional de ESB usados para probar las mencionadas rutinas de integración. Para desarrollar los lineamientos de prueba se empleó WebSphere Message Broker como ejemplo de middleware ESB.

Figura 1. Ejemplos de mensaje y protocolos de red en SOA
Ejemplos de mensaje y protocolos de red en SOA

Flujo de mensaje de JMS al servicio web

La Figura 2 muestra el flujo de mensaje correspondiente a la correlación entre JMS (consumidor) y el servicio web (proveedor) dentro de ESB. El solicitante del servicio envía la solicitud a ESB, la convierte en mensaje SOAP y la transfiere para invocar al servicio web (proveedor). El proveedor envía un mensaje de respuesta SOAP a ESB, lo transforma en XML y lo envía a la cola de respuestas del solicitante.

Figura 2. Flujo de mensaje 1
Flujo de mensaje 1

Para poder probar la función del flujo de mensaje, primero deberán identificarse las ramas de prueba de éste. La Figura 2 muestra dos ramas válidas. Una de ellas envía el mensaje a la cola de solicitudes del solicitante y recibe el mensaje de respuesta de la cola de respuestas del solicitante. La otra envía el mensaje a la cola de solicitudes del solicitante y recibe el mensaje de error de la cola de respuestas del solicitante.

En segundo lugar, deberán diseñarse distintos tipos de mensajes de entrada para las distintas ramas. Por ejemplo, para la primera rama, se diseñarán tipos de mensajes XML de entrada a ser convertidos en los distintos tipos de mensajes SOAP para recibir distintas respuestas del servicio. Al diseñar la entrada de prueba, deberán tomarse en cuenta el límite de entrada y la clasificación. En la segunda rama, los mensajes XML de entrada inválidos se convertirán en el mensaje SOAP inválido del servicio.

Nuestros casos de prueba están diseñados para verificar la función de los flujos de mensajes. Primero, limpie la cola de solicitudes del solicitante y luego envíe el mensaje de entrada a la cola. Obtenga el mensaje de solicitud SOAP convertido en el punto de verificación 1 de la Figura 2 y compruebe que el mensaje SOAP se convierta en el mensaje esperado. En el punto de verificación 2 de la Figura 2, el cliente de prueba recibe el mensaje de Respuesta/Error de la cola de respuestas del solicitante y luego verifica si el mensaje es el esperado.

Flujo de mensaje del servicio web a JMS

La Figura 3 muestra el flujo de mensaje correspondiente a la correlación entre el servicio web y JMS. Un servicio web (consumidor) envía el mensaje de solicitud SOAP a ESB, convierte el mensaje SOAP en un mensaje XML y lo envía a la cola de solicitudes del proveedor. El proveedor del servicio recibe el mensaje de solicitud y envía el mensaje de respuesta a ESB. ESB transforma el mensaje de respuesta en un mensaje SOAP y lo envía como respuesta SOAP del servicio web. Para probar el tipo de automatización de flujos, se implementó un simulador de proveedor que envía el mensaje de respuesta del proveedor.

Figura 3. Flujo de mensaje 2
Flujo de mensaje 2

En el flujo de mensaje de la Figura 3 pueden identificarse dos ramas de prueba. En una se indica que el mensaje de solicitud SOAP es inválido, ESB administra la excepción y envía el resultado de error como respuesta. En la otra, el servicio web envía el mensaje de solicitud SOAP inválido y recibe el mensaje de respuesta SOAP válido a través de ESB.

Los mensajes de entrada de la rama de excepciones deben diseñarse para cubrir las situaciones de excepciones. En lo que respecta a la rama válida, el límite de entrada y la clasificación son factores que deberán tomarse en cuenta y cubrirse al diseñar el mensaje SOAP de entrada.

Como muestra la Figura 3, en estos casos de prueba existen dos puntos de verificación en el flujo válido. Cuando la solicitud SOAP se convierte en mensaje XML, el cliente de prueba recibe un mensaje que le indica que verifique que la XML se haya convertido correctamente y que el contenido cumpla con lo requerido por el proveedor del servicio. En el otro punto de verificación se revisa que el mensaje de respuesta convertido en SOAP sea correcto. En la rama inválida, el punto de verificación 2 debe revisarse. El cliente de prueba debe verificar que el resultado de respuesta de error se genere correctamente.

Flujo de mensaje de MQ/JMS a MQ/JMS

ESB también puede transferir el mensaje de una cola a otras colas (locales/remotas). La Figura 4 muestra el flujo de mensaje unidireccional. El mensaje de entrada se diseñará para verificar que el mensaje se transfiera correctamente. El mensaje de entrada se envía a la cola de solicitudes del consumidor y el cliente de prueba recibe el mensaje de la cola de solicitudes del proveedor que le indica verificar que el formato y el contenido del mensaje se hayan transformado y transferido correctamente.

Figura 4. Flujo de mensaje 3
Flujo de mensaje 3

La Figura 5 muestra el flujo de mensaje de correlación en ESB. El consumidor del servicio envía la solicitud de servicio a través de JMS y el mensaje de solicitud se transfiere y transforma a través de ESB. El proveedor del servicio recibe el mensaje de solicitud de la cola de solicitudes del proveedor y envía el mensaje de respuesta a la cola de respuestas del proveedor. ESB transfiere el mensaje de respuesta al consumidor del servicio. Nuestro caso de prueba está diseñado para cubrir este flujo.

El mensaje de entrada está diseñado en base a un esquema de contratación. El cliente verifica si el proveedor recibe los mensajes correctos en el punto de verificación 1. El cliente crea un simulador para enviar el mensaje de respuesta. El mensaje de respuesta del consumidor debe verificarse si el formato y el contenido es el esperado en el punto de verificación 2.

Figura 5. Flujo de mensaje 4
Flujo de mensaje 4

Flujo de mensaje de FTP a FTP

Como muestra la Figura 6, es posible transferir archivos del consumidor al proveedor por FTP a través de ESB. El cliente de prueba carga los archivos de la carpeta fuente correspondiente. ESB transfiere el archivo al destino esperado. El cliente de prueba recibe los archivos del destino y verifica que estos coincidan con los archivos de entrada realizando una comparación de bytes. Se diseñan tres tipos de archivos de entrada: un archivo de tamaño 0, un archivo normal, un archivo de gran tamaño para verificar la función de transformación.

Figura 6. Flujo de mensaje 5
Flujo de mensaje 5

Flujo de mensaje de FTP a JMS

La Figura 7 muestra una conversión de FTP a JMS. ESB recibe los archivos por FTP y convierte los archivos en mensaje y los envía a las colas del proveedor. El cliente de prueba debe diseñar distintos tipos de archivos (tamaño cero, tamaño normal, tamaño grande) para conformar la entrada. Luego obtiene el mensaje convertido de las dos colas y verifica que los archivos se hayan convertido y transferido correctamente.

Figura 7. Flujo de mensaje 6
Flujo de mensaje 6

Método de prueba de rendimiento de ESB

Control de cargas de trabajo simultáneas

En esta prueba de rendimiento, verificaremos los flujos de mensajes aquí analizados en una situación extrema en la que todas las solicitudes de los flujos de mensajes se envían al broker de mensajes al comienzo de la prueba sin ningún tiempo de procesamiento. Por ejemplo, el flujo de mensaje IRS_CRM_AccountCreationRequest posee 1000 solicitudes en hora pico. En esta situación, los 1000 mensajes de solicitud se enviarían a la cola de entrada del flujo de mensaje sin detenerse al iniciar la prueba. Al mismo tiempo, también se envían los mensajes de solicitud de otros más de 20 flujos de mensaje al destino especificado. En este caso, la tensión de los flujos de mensajes al inicio de la prueba sería muy elevada.

Flujo de mensaje unidireccional

Como muestra la Figura 8 a continuación, el flujo de mensaje unidireccional suele contener un nodo de entrada MQ y un nodo de salida MQ.

Figura 8. Flujo de mensaje unidireccional
Flujo de mensaje unidireccional

En el script de prueba, se registra el período t0 que indica el comienzo del envío de un mensaje de solicitud a la cola de solicitudes. Además se registra el período t1 , el cual indica el tiempo de recuperación del mensaje de respuesta de la cola de respuesta. Los otros mensajes de solicitud también se registran de la forma descripta. La suma total del tiempo de respuesta de todos los flujos de mensajes se calcula de la siguiente manera: ? (t1-t0) . Supongamos que enviamos un total de m mensajes hacia este flujo. Entonces, el tiempo de respuesta promedio (ast) se calculará de la siguiente forma: ast= ? (t1-t0)/m .

Flujo de mensaje de correlación

Como muestra la siguiente figura, el flujo de mensaje de correlación suele contener 2 nodos de entrada MQ y 2 nodos de salida MQ.

Figura 9. Flujo de mensaje de correlación
Flujo de mensaje de correlación

A la derecha, se muestra un simulador que construye un mensaje de respuesta a partir del mensaje de solicitud proporcionado. El simulador simplemente establece el ID de correlación del mensaje de respuesta con el ID del mensaje de solicitud y luego coloca el mensaje de respuesta en la cola de respuestas del proveedor. Se registran los períodos t0 y t1 como se describe en el punto 3.2. Además se registra el período ds ,el cual indica el tiempo total que usa el simulador para construir el mensaje y enviarlo como respuesta. Supongamos que enviamos un total de m mensajes hacia este flujo. El tiempo de respuesta promedio (ast) se calcularía de la siguiente manera: ast= (? (t1-t0)-ds) /m .

Flujo de mensajes del proveedor de servicios web

El flujo de mensajes del proveedor de servicios web suele enviar el mensaje de solicitud SOAP al nodo de entrada SOAP y recibir un mensaje de respuesta SOAP del nodo de respuesta de SOAP, como se muestra a continuación. El nodo de entrada MQ y el nodo de salida MQ se usan para enviar los mensajes transformados al consumidor del servicio y recibir el mensaje de respuesta del consumidor.

Figura 10. Flujo de mensaje del proveedor de servicios web
Flujo de mensaje del proveedor de servicios web

El simulador actúa como el consumidor del servicio y construye un mensaje de respuesta como se vio en el punto 3.3. El período t0 se usa para registrar el momento en que se envía el mensaje de solicitud SOAP, mientras que t1 es el período que demora la respuesta del nodo de respuesta SOAP. Asimismo, ds registra el tiempo total usado por el simulador para construir el mensaje y enviar la respuesta. Supongamos que enviamos un total de m mensajes hacia este flujo. Entonces, el tiempo de respuesta promedio (ast) se calcularía de la siguiente manera: ast= (? (t1-t0)-ds) /m .

Flujo de mensaje del consumidor del servicio web

El flujo de mensaje del consumidor del servicio web suele contener un nodo de entrada MQ y un nodo de salida MQ, como se muestra a continuación. El nodo del servicio web consume los mensajes de solicitud MQ y envía los mensajes de respuesta al nodo de salida MQ.

Figura 11. Flujo de mensajes del consumidor del servicio web
Flujo de mensajes del consumidor del servicio web

Al igual que en los casos anteriores, se registran los períodos t0 y t1 como se describió en el punto 3.2. Además, ws registrará el tiempo total usado por el simulador de servicios web para construir el mensaje y enviar la respuesta. Supongamos que enviamos un total de m mensajes hacia este flujo. Entonces, el tiempo de respuesta promedio (ast) se calculará de la siguiente manera: ast= (? (t1-t0)-ws) /m .


Resumen

Este documento describe los métodos de prueba funcional y prueba de rendimiento. El método de prueba puede implementarse mediante JUnit y ejecutarse automáticamente. En el proyecto de cliente Road User Charging, se implementó el sistema ESB, el cual lleva a cabo un rol de importador en el proyecto.

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

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=SOA y servicios web
ArticleID=465352
ArticleTitle=Mejores prácticas de pruebas de ESB
publish-date=08032011