Pruebas en SOA(Arquitecturas orientadas en servicios)

En arquitecturas orientadas en servicios, la realización de pruebas de Web Services es crucial. El performance, interoperabilidad y la identificación de vulnerabilidades son los pilares de un buen SOA Testing. Solo su comprensión asegura que la infraestructura sea robusta, escalable, interoperable y segura.

Los tipos de pruebas mas comunes que deben ser aplicadas en este tipo de arquitecturas son:

Pruebas carga: El objetivo de las pruebas de carga es determinar el rendimiento del sistema bajo condiciones de carga que se aproximan a la realidad esperada en producción. Esto nos permite:

1. Determinar la escalabilidad del sistema en TX / seg vs. #Usuarios concurrentes.
2. Validar que el dimensionamiento de la infraestructura de hardware fue el adecuado.
3. En este tipo de pruebas, a diferencia de las pruebas de estabilidad, la carga se va aumentando cada vez más para determinar la escalabilidad del sistema.Una vez determinada la escalabilidad de la plataforma, se usa este valor para las pruebas de estabilidad.

Pruebas de Volumen: Encontrar debilidades en el sistema al momento de manejar grandes volúmenes de datos durante prolongados períodos de tiempo, el objetivo principal es determinar si la plataforma de integración se degrada o deja de funcionar al manejar grandes volúmenes de datos.

Pruebas de Estabilidad: Miden la estabilidad de los servicios con una fuerte carga sostenida en el tiempo (la carga no cambia). Los servicios no deben fallar y los tiempos de respuesta para una carga constante deben permanecer constantes. Gráfica tipo: tiempo de respuesta de un WS vs. tiempo (debe tender a líneas de pendiente 0).

Las aserciones que deben considerarse para realizar pruebas unitarias en web services son:

1. Conformidad con el XML Schema.
2. Contenido simple, Expresiones Xpath.
3. SOAP Fault.
4. Transacción por segundo (TPS).
5. Máximo Tiempos de Respuesta (Response Time).
6. Máximo numero de errores.
7. Average o promedio.

Saludos Mijanautas.

Arquitecturas Agiles

Las organizaciones deben ser ágiles operacionalmente, deben proteger sus inversiones; deben poder evolucionar y mantenerse, sin que los cambios tecnologicos las afecten. Para cumplir con estos lineamientos, es necesario que la organizacion desarrolle arquitecturas ágiles.

Una arquitectura ágil, debe ser una desacoplada, adaptable y de tecnología neutral, la cual; no se vea afectada ante cambios de productos y tecnologías. Esta debe permitir una disminución significativa en la complejidad y dependencia tecnológica de los ambientes heterogéneos.El marco de arquitectura ágil debe proporcionar:

1. Simplicidad.
2. Flexibilidad y mantenibilidad (Tolerancia ante Cambios).
3. Reusabilidad.
4. Desacoplamiento.
5. Extensibilidad.

Para desarrollar una arquitectura ágil, es necesario contar con un conjunto de lineamientos y criterios de éxito que minimicen riegos y garanticen una especificación más formal y sólida.

Criterios de Éxito

1. Debe poseer capacidades de Plug-in.
2. Capacidad de interoperar con vendedores distintos (conectores / Adaptadores, etc.).
3. Debe proporcionar un modelo desacoplado entre componentes.
4. Los componentes no deben interactuar con otros componentes directamente.
5. La semántica debe estar basada en mensajes.
6. La definición de la secuencia de mensajes durante la ejecución de una operación debe estar basada en MEP.
7. Clara separación entre la lógica de negocio (procesamiento) de la lógica de comunicación.
8. Debe existir una clara separación entre los proveedores y consumidores de servicios.
9. El modelo de intercambio de mensajes basado en WSDL 1.1 o 2.0.
10. No usar metadatos propietarios en la definición de objetos de negocio (Xml Schemas).
11. Modelo de implementación no-intrusivo.
12. Ensamblado de servicios desde otro servicio, basado en reglas de negocio.
13. Soporte de servicios sincronos, asíncronos, y conversacionales.
14. Automatización de la transformación entre estructuras de datos dispares (semántica).
15. Soporte para la simulación, testing y debuging.
16. Definición del servicio con independencia de su implementación, localización o uso.
    

Recomendaciones y Consideraciones para elevar el nivel de desacoplamiento de la arquitectura.

1. El marco de arquitectura debe estar basado en arquitecturas SOA.
2. Debe estar basado en las especificaciones y estándares (ws-i, w3c, oasis, etc.).
3. Debe estar soportado sobre un bus de servicios y un modelo de servicios horizontal.
4. Debe tener capacidades de inversion de control “Inversion of Control Containers”.
5. Debe tener capacidades de inyeccion de dependencias “Dependency Injection pattern”.
6. Capacidades y soporte para arquitecturas Event-driven architecture (EDA) y service-oriented architecture (SOA).
7. Integración con JBI.
8. Estandarización de la arquitectura para el enrutamiento de mensajes.

Para mas informacion:

http://en.wikipedia.org/wiki/Enterprise_service_bus
http://en.wikipedia.org/wiki/JBI
http://en.wikipedia.org/wiki/Message_Exchange_Pattern
http://www.ws-i.org/
http://www.oasis-open.org/home/index.php

Saludos.

Google venezolano

Necesitamos un google venezolano, un equipo de gente visionaria, que potencie la creación de un territorio creativo y de innovación, con una visión socialista e integracionista, gente que investigue y desarrolle sobre una vigilia tecnológica sistemática, gente que disemine su experiencia en todos los estratos de la sociedad, de la nación, del país.

La vigilancia tecnológica es vital y estratégica para el estado, ella estimula la innovación y la creatividad, generando ideas, productos libres, independencia tecnológica.