El patrón arquitectónico Event-Driver

Leyendo el libro, "Software Architecture Patterns" les dejo este pequeño resumen:

El patrón arquitectónico Event-Driver se utiliza para crear arquitecturas escalables, se puede utilizar  en grandes aplicaciones como en pequeñas.

Este patrón arquitectónico tiene 2 topologías, el mediador y el broker (corredor, como es una fea traducción dejo su nombre en ingles).

La topología del mediador se utiliza comúnmente cuando se necesita orquestar múltiples pasos dentro de un evento a través de un mediador central, mientras que la topología de broker se utiliza cuando se desea encadenar sucesos sin el uso de un mediador central. Debido a que las características de la arquitectura y las estrategias de implementación difieren entre estas dos topologías, es importante entender cada una de ellas para saber cuál es la más adecuada para cada  situación particular.

La topología del mediador es útil para eventos que tienen varios pasos y requieren algún nivel de orquestación para procesar el evento.

Hay cuatro tipos principales de componentes de arquitectura dentro de la topología del mediador: colas de eventos, un mediador de eventos, canales de eventos y procesadores de eventos. El flujo de eventos comienza con un cliente que envía un evento a una cola de eventos, que se utiliza para transportar el evento al mediador de eventos. El mediador de eventos recibe el evento inicial y orquesta dicho evento enviando eventos asíncronos adicionales a los canales de eventos para ejecutar cada paso del proceso. Los procesadores de eventos, que escuchan en los canales de eventos, reciben el evento del mediador de eventos y ejecutan lógica empresarial específica para procesar el evento.

La implementación más simple y más común del mediador de eventos es a través de frameworks open source como Spring Integration, Apache Camel o Mule ESB. Los flujos de eventos en estos frameworks se implementan típicamente a través de código Java o un DSL (lenguaje específico de dominio). Para una mediación y una orquestación más sofisticadas, puede utilizar BPEL (lenguaje de ejecución de procesos empresariales) junto con un motor BPEL open source como Apache ODE. BPEL es un lenguaje XML estándar que describe los datos y los pasos necesarios para procesar un evento inicial. Para aplicaciones muy grandes que requieren una orquestación mucho más sofisticada (incluyendo pasos que involucran interacciones humanas), puede implementar el mediador de eventos utilizando un gestor de procesos empresariales (BPM) como jBPM.

La topología broker se diferencia de mediador porque no hay un mediador central y único, sino que el flujo de eventos esta distribuido a través de los componentes del procesador de eventos de una manera similar a una cadena a través de un agente de mensajes ligero (por ejemplo, ActiveMQ, HornetQ, etc.). Esta topología es útil cuando se tiene un flujo de procesamiento de eventos relativamente simple y no desea (o necesita) orquestación de eventos centrales.

Hay dos tipos principales de componentes de arquitectura dentro de la topología de intermediario: un componente de broker y un componente de procesador de sucesos. El componente de broker puede centralizarse o federarse y contiene todos los canales de eventos que se utilizan en el flujo de eventos.

El patrón de arquitectura event-driver es un patrón relativamente complejo de implementar, principalmente debido a su naturaleza asincrónica distribuida. Al implementar este patrón, debe abordar varios problemas de arquitectura distribuida, como la disponibilidad de procesos remotos, la falta de capacidad de respuesta y la lógica de reconexión de intermediarios en caso de un fallo del intermediario o mediador.

Una consideración a tener en cuenta al elegir este patrón de arquitectura es la falta de transacciones atómicas para un solo proceso de negocio. Debido a que los componentes del procesador de eventos están altamente disociados y distribuidos, es muy difícil mantener una unidad transaccional de trabajo a través de ellos. Por esta razón, al diseñar su aplicación utilizando este patrón, debe pensar continuamente sobre qué eventos pueden y no pueden ejecutarse de forma independiente y planificar la granularidad de los procesadores de sucesos en consecuencia. Si descubre que necesita dividir una sola unidad de trabajo en los procesadores de eventos, es decir, si utiliza procesadores independientes para algo que debería ser una transacción indivisa, probablemente no sea el patrón adecuado para su aplicación.

Dejo link: http://radar.oreilly.com/2015/02/variations-in-event-driven-architecture.html

Apache ServiceMix

Apache ServiceMix es un flexible ESB open source, que integra funcionalidad de diversos productos de Apache como Apache ActiveMQ, Camel, CXF, ODE y Karaf. Provee el funcionamiento de un ESB integrado a una herramienta OSGI.

Las características de Apache ServiceMix son:

• Mensajería segura gracias a Apache ActiveMQ
• Mensajería, enrrutamiento y patrones de integración para Empresas con Apache Camel
• ServiceMix NMR incluye eventos ricos, mensajería y auditoría lo que permite una integración con bajo acoplamiento.
• Completo WS-BPEL con Apache ODE.
• Basado en OSGI con la utilización Apache Karaf.

Además es licencia Apache 2.


Dejo Link:

http://servicemix.apache.org/

Aprendiendo SOA

Dejo una serie de libros y links para la persona que quiere empezar con SOA

Libros:

Open Source SOA.

Autor: Jeff Davis

Publicado por Manning Publications corp.

ISBN: 1933988541

Java SOA cookbook

Autor: Eben Hewitt

Publicado por O’Reilly Media, Inc.

ISBN: 978-0-596-52072-4

Service-Oriented Architecture: Concepts, Technology, and Design

Autor: Thomas Erl

Publicado por Prentice Hall PTR

ISBN: 0-13-185858-0

Service-Oriented Architecture Governance for the Services Driven Enterprise

Autor: Eric E. Marks

Publicado por Wiley Publishing.

ISBN 978-0-470-17125-7

Adopción de SOA para Dummies.

Autores:Miko Matsumura, Bjoern Brauel y Jignesh Shah

ISBN: 978-0-470-48334-3

Publicado por Wiley Publishing.

Introducción a BPM para Dummies.

Autores: Kiran Garimella, Michael Lees y Bruce Williams

ISBN: 978-0-470-37359-0

Publicado por Wiley Publishing.

Papers:

Introducing SCA

autor: David Chappell

Url: http://www.davidchappell.com/articles/introducing_sca.pdf

BPM and SOA

Autor: Mike Rosen

Url:http://www.bptrends.com/publicationfiles/04-08-COL-BPMandSOA-OrchestrationorChoreography-%200804-Rosen%20v01%20_MR_final.doc.pdf

Oracle SCA – The Power of the Composite

Autor: Pat Shepherd

Url: http://www.oracle.com/technetwork/topics/entarch/whatsnew/oracle-sca-the-power-of-the-composi-134500.pdf

Fabric3 Reference
 Guide

Url: http://dist.codehaus.org/fabric3/releases/doc/1.6/fabric3-reference-1-6.pdf

Sitios Web:

http://msdn.microsoft.com/webservices/

http://complexevents.com/

http://www.soapatterns.org

http://www.osoa.org/

http://tuscany.apache.org/

http://wso2.com/

http://www.oasis-opencsa.org/

http://blogs.tecsisa.com/

BPEL

Business Process Execution Language (lenguaje de ejecución de procesos de negocio), se trata de un lenguaje XML para la especificación de procesos de negocio ejecutables, aplicado principalmente a la orquestación de los servicios web. BPEL es un subconjunto de BPM. Definido para representar workflows de servicios web.

La interacción entre servicios web puede ser descripta de dos formas: procesos de negocio ejecutable y procesos de negocio abstracto.

• Proceso de negocio ejecutable: es el comportamiento real de un participante de una interacción.
• Proceso de negocio abstracto: es el proceso que no está destinados a ser ejecutados, puede ocultar algunos de los detalles necesarios de las operaciones concretas. Los Procesos abstractos desempeñan una función descriptiva, con más de un caso de uso posible, incluyendo el comportamiento observable y plantilla de proceso. Un proceso abstracto que incluye información como cuándo es mejor esperar para mensajes, cuándo enviar mensajes, cuándo compensar las transacciones fallidas, etc.

BPEL provee un lenguaje para la especificación de Procesos de negocios Ejecutables y Abstractos. De este modo, se extiende el modelo de servicios Web y la posibilidad de interacción para apoyar las transacciones comerciales. WS-BPEL define un modelo de integración interoperable que debería facilitar la expansión de la integración de procesos automatizados, tanto dentro como entre las empresas.

Bpel fue diseñado con los siguientes objetivos:

1. Definir procesos de negocio que interactúan con entidades externas a través de operaciones de Web services definidas en archivos WSDL, y que se manifiestan en los servicios Web definen utilizando WSDL.
2. Esta basado en xml. No define una representación gráfica de procesos, ni provee algún particular metodología de diseño.
3. Definir una serie de conceptos de orquestación de servicios Web que pretenden ser usados por vistas internas o externas de un proceso de negocio.
4. Proveer sistemas de control jerárquicos y de estilo grafo, que permitan que su uso sea lo más fusionado e inconsútil posible. Esto reduciría la fragmentación del espacio del modelado de procesos.
5. Proveer funciones de manipulación simple de datos, requeridas para definir datos de procesos y flujos de control.
6. Soportar un método de identificación de instancias de procesos que permita la definición de identificadores de instancias a nivel de mensajes de aplicaciones. Los identificadores de instancias deben ser definidos por socios y pueden cambiar.
7. Brindar la posibilidad de la creación y terminación implícitas de instancias de procesos, como un mecanismo básico de ciclo de vida. Operaciones avanzadas de ciclo de vida como por ejemplo "suspender" y "continuar" pueden agregarse en futuras versiones para mejorar el manejo del ciclo de vida.
8. Definir un modelo de transacción de largo plazo que se base en técnicas probadas tales como acciones de compensación y ámbito, de tal manera a brindar recuperación a fallos para partes de procesos de negocios de largo plazo.
9. Usar servicios Web como modelo para la descomposición y ensamblaje de procesos.
10. Construir sobre estándares de servicios Web (aprobados y propuestos) tanto como sea posible, de manera modular y extensible.

BPEL es una herramienta concebida para diseñar workflows basados en web services, esto lo hace una herramienta más apta que BPM para la orquestación de servicios SOA. BPM es más amplio y menos específico para SOA por estas razones nace BPEL. Un lenguaje más específico que suple las deficiencias que tiene BPM.

Orquestación y Coreografía

La integración se debe llevar a cabo mediante un mecanismo que permita que los servicios cooperen entre ellos. Para ello comúnmente se utilizan dos términos: La orquestación y la coreografía. Hablamos de orquestación de servicios cuando es controlado por una única unidad, es decir un cliente y un servicio establecen un acuerdo con respecto al transporte de mensajes y al contenido. Un proceso es una coreografía de servicios cuando las colaboraciones son definidas entre cualquier tipo de aplicaciones.

La coreografía brinda reglas que revelan como múltiples componentes pueden colaborar entre pares, lo que denominamos peer-to-peer, y de que forma o en que secuencia. Esta colaboración se realiza mediante el intercambio de mensajes. Una coreografía describe la colaboración entre más de un servicio para lograr un objetivo común. Por lo tanto no se centra en un servicio en particular, pero si en un objetivo que tiene que cumplir el flujo de proceso. Para ello, la lógica de control es distribuida sobre los servicios participantes. Para diseñar una coreografía, se debe describir primero las interacciones que los servicios tienen que realizar entre sí para cumplir el objetivo y las relaciones que existen entre estas interacciones. Una coreografía no describe las acciones que son realizadas internamente por el servicio principal para realizar el flujo de procesos.

Si usted alguna vez pudo apreciar una presentación de ballet, puede haberse percatado como cada integrante del equipo (servicios) inicia y finaliza un conjunto de movimientos (flujo de proceso), estos movimientos siguen una trilla (interacciones entre los servicios) musical determinada.

Una orquestación describe el comportamiento que el servicio principal implementa para realizar un flujo de proceso. Esto quiere decir, que el enfoque se centra sobre un servicio en particular, y la lógica de control es centralizada sobre el servicio principal el cual implementa el comportamiento. Para diseñar una orquestación, se describe las interacciones que el servicio principal tiene con las otras partes (servicios, adaptadores, interfaces, etc.) y las acciones que el servicio principal realiza internamente para realizar el flujo de proceso. Una orquestación es ejecutada por una máquina de orquestación. Por lo que es llamado proceso ejecutable.

Para entender mejor la definición de orquestación, imagine como un maestro de una orquesta sinfónica dirige y controla a cada uno de los integrantes (servicios) de la orquesta con el fin de poder lograr un objetivo común (un flujo de proceso), que es el de poder establecer una melodía armoniosa basada en un conjunto de especificaciones (objetivo principal y interrelaciones entre servicios) que contienen las notas, que instrumentos deben tocarse, que notas deben tocar cada uno de esos instrumentos y cuando deben iniciar o detener sus melodías.

Coreografía nos permite especificar las reglas de unión y trabajo colaborativo (entendiendo por colaboración, una función/es de negocio surgidas de la interacción cooperativa de múltiples actores). Es lo que normalmente se entiende por un proceso de negocio global donde se modela el estado de negocio de diversos servicios web.
La orquestación es un mecanismo para el intercambio de mensajes desde una visión más detallada a través de un proceso (un flujo de control). La Orquestación podría verse como la ejecución de un proceso de negocio definido en BPM o BPEL y que puede ser ejecutado por un motor BPM o BPEL.

La coreografía se define mediante WS-CDL y la orquestación puede definirse con BPM o BPEL.

WSO2 Business Process Server

Estuve probando WSO2 Business Process Server (BPS) y quede gratamente sorprendido. No tengo experiencia en soluciones BPEL pero por lo pronto este producto me gusto.

WSO2 Business Process Server (BPS) es un Open Source Business Process Server fácil de usar que ejecuta procesos de negocios escritos siguiendo WS-BPEL estándar.

WS-BPEL esta emergiendo como un estándar por defecto para componer múltiples servicios asíncronos o síncronos, dentro de un flujo de procesos colaborativo y transaccional que incrementa la flexibilidad y agilidad de nuestra SOA (Service Oriented Architecture).

WSO2 BPS esta formado por Apache ODE e incluye una interfaz administrativa basada en la Web y funcionalidades de simulación. Además disponible con licencia Apache v2.

La versión actual de BPS es la 1.1.1

Dejo Link:

http://wso2.com/products/business-process-server/

Productos BPM Open Sources

En el mercado existen gran variedad de herramientas BPM y BPEL open source, las más importantes son:

• Intalio BPM (edición community) : Herramienta BPM rica en funcionalidades que utiliza la noción de modelado de procesos de negocio BPMN para generar orquestaciones basadas en BPEL. Al ser una versión open source de un producto comercial utiliza librerías de la versión de pago, este software fue concebido para permitir el desarrollo y luego cuando se ponga en producción se compre la versión estándar.
• Motor ActiveBPEL: Motor BPEL eficiente y sumamente cuidado. Los modelos pueden diseñarse utilizando su herramienta Designer que es gratuita pero no es open source. La funcionalidad más importante, como puede ser las instancias de procesos persistentes a una base de datos o el control de versión de los procesos, únicamente esta disponible en la versión Enterprise.
• Apache ODE: Apache ODE (Orchestation Director Engine) es un motor BPEL de ejecución de procesos. Su API permite extenderlo de muchas maneras y por lo tanto, no esta limitado a utilizar únicamente SOAP. Es un motor liviano que puede integrarse fácilmente con productos de Apache como Service Mix. Apache ODE no posee editor gráfico para deseñar los procesos pero se puede contar con un plugin que se puede instalar en Eclipse.
• Jboss JBPM: Es un motor de workflow maduro, eficiente y ligero que va siempre de la mano de la herramienta de modelado basado en Eclipse. Usa su propio lenguaje de grafo en xml llamado jPDL (jBPM process Definition Language) y tiene soporte para todos los nodos de modelado principales, como puede ser las decisiones y las bifurcaciones. Se puede extender de manera sencilla y no está restringido su uso a ningún entorno de despliegue. A diferencia de otras alternativas, no existe una actualización a la versión comercial y no hay ninguna funcionalidad que esté restringida.
• ObjectWeb Bonita: Se trata de un motor de workflow potente y compatible con XPDL. Es un proyecto maduro y bien documentado. Incluye excelente integración con herramientas graficas de actividades humanas (por ejemplo, un generador de formularios) No dispone de ningún editor de software libre y necesita el servidor de aplicaciones JOnAS (Java Open Application Server)
• WSO2 Bussiness Process Server: El producto está basado en Apache ODE e incluye una interfaz administrativa basada en la Web y funcionalidades de simulación.

La pregunta del millon es cual usar? Lo mejor es elegir los 100% libres, y a la vez que tenga madurez en el mercado si tomamos estas dos premisas JBPM de la gente de JBoss es el ganador. Aunque yo antes de tomar una decisión de lleno jugaría con Apache ODE.

Ustedes usan uno de estos framework? Cual y porque?

Servicios y Gobierno SOA

Los servicios son funcionalidad necesaria para la empresa, es decir son funcionalidad expuesta a otros servicios, sistemas o una interfaz gráfica. Los cuales fueron concebidos para solucionar un requerimiento. Los servicios son los ladrillos de nuestra arquitectura SOA. Ellos pueden contener lógica de negoció, acceso a bases de datos, accesos a otros servicios, etc.

Los servicios están descriptos en una interfaz que indica como utilizarlos. Pero los servicios nunca exponen su funcionamiento; son una caja negra. Lo que permite cambiar un servicio fácilmente por otro, favoreciendo la mantenibilidad y agilidad de desarrollo. Los servicios exponen como se utilizan pero no exponen como funcionan.

Los servicios pueden acoplarse para formar nuevos servicios, que solucionan nuevos requerimientos, esto ayuda a que no se duplique el código. Los servicios son atómicos y sin estado lo que permite distribuirlos en diferentes maquinas favoreciendo la escalabilidad de los sistemas.

Los servicios por si solos son incompletos, necesitan una arquitectura que los mantenga y soporte sus ventajas. Por ejemplo a la hora de desarrollar un nuevo servicio ¿como se si no existe ya? O ¿si existen servicios que pueden ayudar? Por lo tanto debo tener un registro a donde registrar mis servicios, en el cual puedo buscar los servicios existentes.

El gobierno SOA es el conjunto de roles, políticas y procedimientos que sirven de guía para la adopción de la SOA. Al implementar los componentes tecnológicos de gobierno, está creando la infraestructura para soportar y aplicar estos roles, políticas y procedimientos en toda su SOA.

Luego de desarrollar los servicios hay que gestionarlos, la gestion de los servicios se le llama gobierno SOA.

Gobierno de SOA es una ampliación del gobierno de IT centrada en el ciclo de vida de los servicios y en las aplicaciones compuestas en una arquitectura orientada a servicios (SOA) de una organización. La función del gobierno de SOA es definir:

• Derechos para tomar decisiones para el desarrollo, el despliegue y la gestión de nuevos servicios.
• La supervisión y notificación de procesos para capturar y comunicar los resultados del gobierno. Debido a que las aplicaciones SOA están intrínsecamente fragmentadas, introducen nuevos retos de gobierno. No obstante, con políticas, principios, estándares y procedimientos adecuados, los empresarios pueden darse cuenta de todas las ventajas que ofrece la arquitectura orientada a servicios. Una plataforma de gobierno de SOA eficaz no sólo ayuda a los equipos de IT y negocio a identificar mejor qué proyectos contribuyen más a los objetivos empresariales, sino que también dotan de más facilidades a los empleados para trabajar y colaborar de forma más eficaz definiendo claramente sus roles y sus responsabilidades.

El Gobierno SOA pretende dotar de los mecanismos de control, procesos, procedimientos y métodos probados en la práctica para garantizar el orden en las decisiones que se tomen en una iniciativa SOA, evitando el caos en cualquier proyecto SOA que se plantee, logrando la efectividad y agilidad esperada en la transición hacia SOA.

El Gobierno se refiere a los procesos que una empresa establece para garantizar que las acciones realizadas se adhieren a las mejores prácticas, normativas, estándares y principios de arquitectura, con objeto de gobernar la adopción e implementación de SOA.

La ausencia del Gobierno SOA puede desembocar en los siguientes problemas:

• El Programa SOA entrega resultados inconsistentes
• Crecimiento caótico a nivel de infraestructura y servicios
• Servicios con funcionalidad redundante
• Disponer de servicios que no se pueden reutilizar en la organización
• Inconsistencia en la identificación, diseño y uso de los servicios
• No se definen métricas para cuantificar el éxito
• Ausencia de coordinación entre proyectos

La definición de una Estrategia de Gobierno SOA proporciona la coherencia necesaria para todas las acciones que se lleven a cabo en un Plan de Adopción SOA, siguiendo un enfoque incremental de adopción en distintas fases para reducir riesgos, y proporcionando un modelo de gobierno que constituya un marco de referencia para las decisiones que se tomen.

Por lo tanto podríamos definir a SOA como la suma de servicios y gobierno SOA.

El Gobierno SOA comprende varias herramientas que permiten gobernar los servicios:

• Registro de servicios, permite registrar nuestros servicios y consultar servicios existentes.
• Bus de servicios o ESB (Enterprise Service Bus) facilita la comunicación entre diferentes servicios.
• Orquestación y coreografía, herramienta que permite definir la interoperabilidad de los servicios.
• Procesador de flujos de eventos o ESP(Event Stream Processing) herramienta para diseñar, gestionar y monitorizar los eventos que fluyen a traves de un entorno orientado a EDA(Event-Driver Architecture) dado.
• Integración de aplicaciones empresariales o EAI (Enterprise Application Integration) facilita la integración con aplicaciones o bases de datos legacy.

No necesariamente se deben tener todos las herramientas descriptas para conformar el gobierno SOA. Se deben adoptar las herramientas que satisfagan las necesidades propias de la empresa que adopta SOA.

Apache ODE

Apache ODE (Orchestration Director Engine) es un motor BPEL de ejecución de proceso, ejecuta proceso BPEL estándar. Su API permite extenderlo de muchas maneras y por lo tanto , no es limitado a utilizar únicamente SOAP. El motor es suficientemente ligero como para ser publicado mediante la integración empresarial de java JBI (Java business Integration) con Apache ServiceMix (un excelete Bus ESB de Apache). Apache ODE no posee herramienta de diseño pero se puede utilizar un plugin de eclipse para BPEL.

La licencia de Apache ODE es licencia Apache.