Puebas de carga y rendimiento con SOAPUI y WSO2.

En esta entrada veremos cómo podemos usar SOAPUI para realizar pruebas sobre los servicios web.

Usaremos el servicio creado en la entrada anterior, pueden usar el servicio seguro o inseguro, como gusten.

Seleccionan un mensaje request y le dan clic derecho y seleccionan “Add to TestCase”

Ahí le ponen un nombre o dejan el que está, porque estaremos creando una suite de pruebas y luego un caso de prueba. Verán entonces lo siguiente:

Les aparecen varias opciones, algunas son aserciones que permiten validar contra el XSD definido dentro del servicio, en el caso de la segunda opción que la marcaré, y en el caso de la primera se valida que el mensaje de respuesta  sea un mensaje SOAP y no un SOAPFault por ejemplo.

Luego dan OK.

Como verán se agrega una suite de prueba con un caso de prueba que tiene además un paso de prueba que se corresponde con la operación que usamos como base.

Si hacen una prueba verán como les devuelve un mensaje de respuesta válido. Además de que nos pone en verde las 2 aserciones que especificamos cuando creábamos el caso de prueba.

Ahora daremos clic derecho encima de “Load Test” y seleccionamos “New Load Test” , ponen un nombre y verán lo siguiente:

Ahora debemos ajustar los parámetros en funcion de nuestras necesidades.

Si queremos simular varios clientes consumiendo el servicio, vamos a la opción señalada en negro, por defecto aparecen 5 pero ustedes puedan variar ese número a discreción, tengan en cuenta que mientras más hilos más consumo del CPU.

Si queremos especificar una demora entre una petición y otra vamos a la opción señalada en rojo. Tengan en cuenta que es en milisegundos.

Si queremos determinar el tiempo de duración del servicio vamos a la opción señalada en verde y aquí se muestra que solo durará 60 segundos pero pueden cambiarla para especificar la cantidad de peticiones por hilo por ejemplo.

Luego es solo cosa de correr la prueba, como mismo se ejecuta una petición a un servicio y esperar los resultados.

En este caso hice una prueba con solo 1 hilo, con una demora de 1ms y con 100 ejecuciones por hilo. Ustedes varíen a su discreción y revisen sus resultados.

Read More [...]

Posted in pruebas, servicios web, SOAPUI, WSO2

Usando SOAPUI para consumir servicios seguros en la plataforma de WSO2.

En esta entrada quería abordar un tema pendiente de la entrada anterior y es el uso de la herramienta SOAPUI para las pruebas en los servicios web y cubrir el cómo acceder a un servicio asegurado con UserNameToken.

Luego de descargarse la herramienta, como pueden ver estoy usando la versión 4.5.1, se les abre una ventana donde pueden ver las siguientes opciones en el menú superior:

Si ya tienen el WSDL de un servicio entonces podemos crear un escenario de pruebas para el servicio.

Haremos lo siguiente:

1. Crearemos un proyecto a partir del WSDL del servicio.Usaremos un servicio sin seguridad, en nuestro caso el servicio de acceso a datos y lo consumiremos desde el SOAPUI. 
2. Luego crearemos otro proyecto para el WSDL del servicio proxy que ya viene con seguridad. 
3. Realizaremos las configuraciones necesarias para especificar la información requerida para poder consumir el servicio.

Comencemos!!!

Paso 1:

Crear un proyecto es muy fácil, dan clic en File y luego en “New soapui Project”

Aquí buscamos el WSDL del servicio ya sea desde el filesystem o desde una URL, como en mi caso ya que voy al AS y copio la URL del WSDL del servicio creado.

Le damos OK y listo.

Verán cómo se crea la estructura del proyecto.

Como ven se han creado dos definiciones, una por cada binding contenido en el WSDL del Servicio, una para SOAP11 y otra para SOAP12. Cada una con todas las operaciones del servicio.

Ahora vamos a consumir el servicio de forma insegura, para eso seleccionamos la operación select_all_datos_operation del SOAP12 y le damos al signo de +, ahí verán que ya hay un mensaje Request creado, cuando dan doble clic encima de este mensaje se les muestra lo siguiente:

Ahora solo tienen que darle al signo que se muestra como un triángulo verde en la ventana recién abierta y eso le envía un mensaje al servicio y verán como inmediatamente se obtiene la respuesta.

Además de ver el mensaje de respuesta también se muestra la demora en el consumo del servicio, en este caso 9 milisegundos.

Es lo mismo para el resto de las operaciones lo que en esos casos deberán de introducir los parámetros en el XML del mensaje request.

Paso 2:

Ahora en vez de usar el WSDL del servicio de acceso a datos usaremos el WSDL del servicio proxy seguro para crear un nuevo proyecto en el SOAPUI.

Esta es la estructura del proyecto.

Si volvemos a consumir la operación del paso anterior  veremos lo siguiente:

Nos está diciendo que el mensaje de request no contiene los encabezados de seguridad necesarios. Veamos cómo se agregan.

Paso 3:

Deben ir a la raíz del proyecto y dan doble clic y seleccionan la pestaña “WS-Security Configuration”

Ahí crearemos una configuración de salida dándole al signo + señalado en rojo

Le ponen un nombre y luego dan clic en el círculo marcado en azul.

Se mostrará una ventana con varios encabezados que se pueden agregar, como se muestra en la siguiente imagen.

Nosotros usaremos:

Timestamp: especifican un “Time to live”  (3000)que determinará el periodo de tiempo en el cual el mensaje se considerará válido. Esto evita que se use el mensaje luego de ese periodo con fines no muy agradables. Solo imagínense que enviamos un mensaje con un descuento de nuestra tarjeta y luego alguien usa ese mismo mensaje y nos vuelve a descontar. Como ya dije, nada agradable :-D

Username: ahí deben especificar el usuario, la contraseña y el formato de la contraseña.

Luego guardan todo y vuelven al request que nos falló en el paso 3.

Lo importante que hay que hacer es en la sección del mensaje request seleccionar en “Outgoing WSS” la configuración que acabamos de crear.

Si vuelven a probar a enviar un mensaje usando esta configuración verán lo siguiente:

Como pueden observar ya el servicio se pudo consumir al agregarle los Header de seguridad, usando la configuración UT que creamos, y en el mensaje de respuesta se pueden ver los encabezados de seguridad que en el mensaje de respuesta incluye un timestamp.

Y bueno eso es todo. Cada vez que necesiten como parte de sus pruebas consumir un servicio seguro con la política usernametoken estos son los pasos que tienen que seguir.

Read More [...]

Posted in seguridad, servicios web, SOAPUI, WSO2

Introducción al ESB de WSO2 a través de ejemplos prácticos. II

En esta entrada estaremos viendo cómo crear un servicio proxy en el ESB de WSO2 que primero de acceso al servicio final, para luego incluirle el escenario de seguridad UT garantizando así que los usuarios tengan que autenticarse para acceder al servicio seguro.

Los pasos básicos son los siguientes:

1. Usaremos el servicio final que creamos en esta entrada y que está desplegado en el AS.
2. Descargaremos el ESB y lo iniciaremos de la misma forma que se inician todas las herramientas de la suite de WSO2, explicado aquí al inicio.  
3. Crearemos el servicio proxy en el ESB a través de la UI de administración.
4. Probaremos el consumo del servicio proxy sin seguridad y veremos la traza de los mensajes tanto en el ESB como en el AS. 
5. Le asignaremos el escenario de seguridad UT al servicio proxy y veremos las modificaciones a realizar para que funcione correctamente.

Comencemos.!!!

Paso 1:

El servicio ya lo tenemos creado y este es su dashboard en el AS.

Paso 2:

El ESB lo pueden descargar de aquí y luego de descompactarlo lo inician siguiendo las instrucciones antes mencionadas. Verán al final de los logs de inicio de la herramienta la url a través de la cual podrán acceder a su administración. Recuerden que por defecto el usuario es admin y la contraseña es admin.

Paso 3:

Para crear el servicio proxy vayan a la opción del menú que está en la pestaña  Main y ahí en Services/Add/Proxy Service. Verán lo siguiente:

Seleccionen la opción Custom Proxy.

Como pueden apreciar la creación de un servicio proxy pasa por 3 pasos, este que es el primero nos permite especificar el nombre del servicio proxy, el WSDL que expondrá, algunos parámetros generales y los protocolos que podrán ser usados.

Lo más importante aquí es especificar el WSDL. Hay 3 formas de hacerlo:

• Especificarlo de forma inline, o sea escribir o copiar el WSDL del servicio en una caja que se habilita para esto, lo bueno que tiene es que no se pierde el WSDL

• Especificar una URL que apunta al WSDL del servicio. Si la URL está offline entonces al reiniciarse el ESB el servicio proxy da error.

• Primero guardar el WSDL en el registro del ESB y luego obtenerlo del registro. Se puede gestionar en el registro del ESB

Usaremos la segunda opción y apuntaremos a la URL del WSDL del servicio de datos que ya tenemos creado.

Dan clic en Next y verán lo siguiente.

Llegados a este punto quisiera explicar brevemente el flujo básico de los mensajes en el  ESB.

Se usa el concepto de tuberías y filtros porque los mensajes cuando entran al ESB llegan a una tubería identificada por una secuencia de entrada, In Sequence, y a esta secuencia se le pueden aplicar un conjunto de filtros que vendrían siendo los mediadores que posee el ESB. Luego el mensaje sale y llega al servicio final. La respuesta de este servicio llega al ESB y pasa por una secuencia de salida o out Sequence donde se le pueden aplicar filtros hasta que llega al consumidor del servicio. Esto lo pueden apreciar en la siguiente imagen.

Una vez dicho esto vamos a especificar una secuencia de entrada y una secuencia de salida.

En la imagen del paso 2 de 3 seleccionamos en la secuencia de entrada la opción “Define Inline” y veremos cómo nos da la opción de crear la secuencia.

Damos clic en Create y comenzaremos a definir la secuencia de entrada:

Si dan clic en Add Child verán lo siguiente:

Esta es la clasificación de los diferentes mediadores que existen en el ESB, cuando se paren encima de una de estas clasificaciones se les desplegará el listado. Para este ejemplo solo quiero guardar un log del paso del servicio por esta secuencia. Dan clic en la clasificación Core y luego en Log.

Si quieren ver que es cada una de estas opciones pueden dar clic en Help y verán una página donde les explican. En mi caso lo dejare como está y daré clic en Save & Close.

Ahora vamos a definir el endpoint hacia donde debe ser enviado el mensaje, en este caso el servicio de acceso a datos. Nuevamente seleccionamos la opción Inline

Y damos clic en Create.

Como pueden ver hay varios tipos de endpoint, usaré la primera opción dando clic en ella e introduciré el endpoint del servicio de acceso  a datos.

Nuevamente si quieren ver que son cada una de las opciones pueden dar clic en Help. Yo doy Save & Close y listo. Volvemos a la pantalla del paso 2 de 3 y damos Next.

Aquí es casi lo mismo que en la secuencia de entrada. Seleccionaremos la opción “Define inline” para la secuencia de salida, iremos a la categoría Core y seleccionaremos el mediador Send, que es para que nos envíe el mensaje al endpoint antes definido.

Aquí no tenemos que especificar un endpoint por eso dejamos marcada la opción None.

Damos Save & Close, luego finish y ya tenemos creado nuestro servicio proxy.

Como ven en la imagen anterior el servicio aparece marcado como proxy, nos dice que es inseguro, nos da acceso a los WSDL 1.1 y 2.0, podemos probar el servicio, y también podemos entrar a editarlo ya sea a través de la interfaz gráfica anterior o usando la vista de código fuente. Quiero mostrarles como se ve el servicio así que selecciono esta última opción:

Salimos de ahí dando clic en Cancel y vamos a la opción Try it.

Como pueden ver se muestran las mismas operaciones del servicio de acceso a dato y podemos hacer las mismas cosas. Los invito a probarlo.

Si van a la consola del ESB verán los mensajes de Log que se generan debido al uso del mediador Log en la secuencia de entrada. Pueden editar el servicio proxy y variar sus características y ver como cambie el mensaje de los logs en la consola.

Una vez terminado esto realizaremos el último paso que es asignarle seguridad al servicio web. Volvemos al listado de los servicios y en la fila de nuestro servicio proxy

Daremos clic en Unsecured.

Ya esto lo hemos visto antes así que en la ventana que nos aparece seleccionamos Yes.

Y luego seleccionamos el escenario 1.

Damos clic en Next y seleccionamos los roles que podrán acceder al servicio proxy.

Damos finish y listo. Ya nuestro servicio proxy es seguro.

Ahora verán en su dashboard como solo queda el endpoint que utiliza https.

Lo que hemos hecho es añadirle al WSDL del servicio una política de seguridad como pueden ver a continuación.

Básicamente estamos pidiendo que se use https y se incluya un username token en los mensajes.

Llegado a este punto el servicio está configurado correctamente pero cuando pruebo nuevamente la funcionalidad del try it introduciendo mi usuario y contraseña curiosamente no funciona. Cosas del opensource. Puede ser que la funcionalidad del try it esté rota en la versión 4.6.0 del ESB. Pero esto solo me da pie a usar otra herramienta para probar el servicio: el SOAPUI.

Como no era objetivo de esta entrada introducir esta herramienta no lo haré pero si les dejaré las pantallas de las pruebas y en otra entrada explicaré como usarla.

Luego de creado el proyecto en SOAPUI vemos lo siguiente si intentamos consumir el servicio.

Nos está diciendo que faltan los encabezados de seguridad. Luego de configurarlos vemos lo siguiente:

Ya aquí pueden ver que luego de configurado el proyecto podemos consumir el servicio sin problema confirmándonos que el teníamos un problema con el Try it del ESB.

Read More [...]

Posted in ESB, servicio proxy, WSO2

Introducción al ESB de WSO2 a través de ejemplos prácticos. I

Estaré elaborando una serie de entradas donde iré mostrando las principales funcionalidades vinculadas al ESB de WSO2 usando un ejemplo que se irá enriqueciendo poco a poco.

Imagínense que tienen una empresa dividida en dominios(finanzas, recursos humanos, comercial, etc) y que por políticas corporativas los servicios brindados por un dominio no pueden ser accedidos libremente desde otro dominio, mientras que en el mismo dominio si se puede hacer.

En un dominio A se ha implementado un servicio de acceso a datos usando el Application Server o el Data Service Server y este servicio puede ser accedido de forma insegura dentro del mismo dominio, pero si se desea acceder al servicio desde un dominio B resulta imposible pues se violaría una política corporativa de seguridad. El servicio de A tampoco se puede modificar para permitir el acceso desde B.

Una solución ya conocida es el uso de un ESB o Bus de Servicios Empresariales que incorpora facilidades como:

• Crear un servicio proxy que actué como un mecanismo de indirección entre el consumidor de un servicio y el servicio final.

• Incorporar al servicio proxy un mecanismo de seguridad que permita autenticar a los usuarios, determinar si tienen autorización de consumo del servicio final y guardar información de la petición para fines de auditoria.

• Realizar transformaciones del protocolo de transporte. Ej.: de SOAP a JMS para garantizar la entrega de los mensajes.

• Transparencia de ubicación para garantizar que el consumidor del servicio no necesite saber dónde está desplegado el servicio final.

• Enriquecimiento de mensajes para a partir de una sola petición obtener más información que la que se podría obtener originalmente si se consumiera directamente el servicio final.

• Transformación de mensajes para garantizar que ninguno de los extremos del intercambio de mensajes tengan que reajustar sus formatos en los esquemas de datos utilizados.

• ……

En este ejemplo en cuestión la solución consiste en poner un ESB que actúe como intermediario.

En otra entrada veremos cómo crear un servicio proxy en el ESB de WSO2.

Read More [...]

Posted in ESB, WSO2