Introducción a la Plataforma de WSO2. II

En la entrada anterior explicaba brevemente que era WSO2 y las herramientas que tenía en su desarrollo. En esta entrada quiero seguir describiendo brevemente algunas de sus herramientas.

1.       WSO2 Developer Studio: esta herramienta es diferente de las demás porque es un plugin para el eclipse. Y la idea es que se puedan desarrollar usando este plugin un conjunto de componentes que también pueden ser desarrollados desde las herramientas. Entre las principales cosas que se pueden realizar se pueden incluir las siguientes:

·         Desarrollo de servicios de datos.

·         Desarrollo de servicios axis2.

·         Desarrollo de clientes para servicios web.

·         Diseño de procesos en BPEL.

·         Desarrollo de servicios proxy.

·         Desarrollo de servicios de reglas de negocio.

·         Desarrollo de componentes de interfaz de usuario para las herramientas.

·         Creación de componentes .car que permiten el despliegue del resto de los componentes desarrollados en las herramientas.

·         Conexión local a las herramientas así como su ejecución, y conexión remota a las herramientas permitiendo el despliegue de los componentes desarrollados.

2.       Governance Registry: esta herramienta sirve fundamentalmente para el almacenamiento de los meta datos de los servicios web, lo que permite que también se puedan gestionar estos servicios a partir de definir ciclos de vida de los mismos y controlar su desarrollo y versionado. Implementa  2 mecanismos de descubrimiento de los servicios UDDIv3 y WS-Discovery. Este último permite que los servicios desplegados o desarrollados en otras herramientas sean registrado automáticamente en el Governance Registry y además permite obtener los endpoint de los servicios desde lo clientes en tiempo de ejecución apoyando aún más la transparencia de ubicación que se logra con el ESB.

3.       Message Broker: la herramienta permite la creación de colas de mensajería basadas en el estándar JMS así como topics para la implementación de patrones de integración basados en mensajes. Esto potencia la comunicación asíncrona así como esquemas de arquitectura basados en el patrón de publicación/subscripción.

4.       Elastic Load Balance: en arquitecturas de alto rendimiento y alta disponibilidad siempre hace falta un balanceador de carga que enrute los mensajes hacia sus destinos finales, en este caso los diferentes nodos de uno o varios clústeres. Eso es lo que permite esta herramienta que se puede poner enfrente de uno o varios clústeres de las herramientas de la suite y permite el balanceo de carga entre ellos. Además tiene la característica de ser elástico, o sea que en función del nivel de carga puede configurarse para que agregue o elimine nodos de un clúster previa configuración de las condiciones que se deben cumplir.

Read More [...]

Posted in developer studio, Elastic Load Balancer, ELB, Governance Registry, GREG, MB, Message Broker, WSO2

Rendimiento y alta disponibilidad con WSO2.

Uno de los temas menos avanzados según lo que he visto en materia de arquitectura en algunas instituciones que he revisado son los de alta disponibilidad a través de la clusterización.

Concretamente en un trabajo realizado un colega de trabajo y yo hemos logrado configurar un entorno de clusterización basado en el enfoque actual de WSO2:

1. Se usa el ELB o Elastic Load Balancer para el tema del balanceo de carga. Algo interesante es que 1 solo ELB puede servir para diferentes clústeres de las herramientas de WSO2.
2. Se pueden configurar dominios y subdominios en cada herramienta en dos configuraciones básicas: management y workers. Los management tienen la tarea de gestionar los artefactos clusterizados, sirve para añadir un artefacto, modificarlo o eliminarlo. Es quien escribe en el mecanismo de sincronización. Los workers son los que sirven a las peticiones realizadas al clúster y se actualizan del mecanismo de sincronización.
3. Como mecanismo de sincronización se usa el subversion, los management tienen permiso de escritura y los workers tienen permiso de lectura.

Pueden ver en esta imagen el esquema que hemos probado y la configuración básica en el ELB. En este caso hemos usado el Application Server de WSO2 versión 5.0.0 y el ELB versión 2.0.3.

Hemos montado un entorno local, lo que implica por un lado que no existe latencia en la red significativa pero por otro existe una limitación y competencia por los recursos de mi laptop.

Aquí pueden ver algunas corridas que he realizado desde un cliente en el Eclipse a un servicio desplegado en 1 manager, que no sirve a las peticiones, y 2 workers que si sirven las peticiones enviadas por el ELB. La cantidad de peticiones hechas es de 100 000.

Tengan en cuenta que tengo todo esto corriendo en 4GB lo siguiente:

1 ELB, 1 AS como manager, 3 AS como workers y una instancia del eclipse con un cliente del servicio. Este cliente ejecuta un ciclo de 100 000 peticiones.

Algunas gráficas de los datos anteriores.

Estoy esperando a poder montar este  esquema en un ambiente real. Donde cada nodo esté en un server diferente y tengamos la red de por medio para poder valorar realmente este despliegue.

Queremos implementar este esquema a nivel empresarial como parte de una Arquitectura de Integración que propongo.

Algunas pruebas de su funcionamiento hasta el momento son:

1. Balancear las peticiones entre nodos workers.
2. Añadir un nuevo nodo cuando se están procesando peticiones. Funciona muy bien.
3. Eliminar un nodo cuando se están procesando peticiones. Funciona muy bien.

Como el ELB es elástico, o sea que se puede configurar para que en función de la carga pueda agregar o eliminar nodos, una de las cosas más interesantes a realizar será probar esta funcionalidad.

Read More [...]

Posted in alta disponibilidad, ELB, rendimiento, WSO2