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

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/

BPM

BPM (Business Process Management) podría ser definido como un Flujo de trabajo o workflow1, es una forma de representar los procesos, los cuales son seguidos por el sistema. Permitiendo en tiempo de ejecución modificar el workflow y que se aplique estos cambios sin volver a compilar ni a bajar o subir la aplicación.

BPM marca al sistema el orden de ejecución de procesos dando la flexibilidad para poder modificar este orden cuando se lo desee. Esto permite centrarse en la lógica de negocio dando el poder de decisión al usuario final el cual por medio de un editor puede modificar el workflow como crea más conveniente. Se centra en el negocio.
BPM es un concepto muy sencillo. Es un conjunto de métodos, herramientas y tecnologías utilizados para diseñar, representar, analizar y controlar procesos de negocio operacionales; un enfoque centrado en los procesos para mejorar el rendimiento que combina las tecnologías de la información con metodologías de proceso y gobierno.

El objetivo de una solución para la gestión de procesos de negocio es proporcionar, dentro de las TI, implementaciones automatizadas de procesos de negocio de la vida real, como por ejemplo los procesos de pedidos y cobros, o de gestión de reclamaciones. Combinada con una SOA, esta forma de proporcionar funcionalidades de TI, con una visión orientada a procesos.

La tecnología BPM incluye lo necesario para diseñar, representar, analizar y controlar los procesos de negocio operacionales:

• El diseño y modelado de procesos posibilitan que, de forma fácil y rigurosa, pueda definir procesos que abarcan cadenas de valor y coordinar los roles y comportamientos de todas las personas, sistemas y otros recursos necesarios.
• La integración le permite incluir en los procesos de negocio cualquier sistema de información, sistema de control, fuente de datos o cualquier otra tecnología. La arquitectura orientada a servicios (SOA) lo hace más rápido y fácil.
• La ejecución convierte de forma directa los modelos en acción del mundo real, coordinando los procesos en tiempo real.
• La supervisión de la actividad de negocio (BAM) realiza el seguimiento del rendimiento de los procesos mientras suceden, controlando muchos indicadores, mostrando las métricas de los procesos y tendencias clave y prediciendo futuros comportamientos.
• El control le permite responder a eventos en los procesos de acuerdo a las circunstancias, como cambio en las reglas, notificaciones, excepciones y transferencia de incidentes a un nivel superior.

Para soportar esta estrategia es necesario contar con un conjunto de herramientas que den el soporte necesario para cumplir con el ciclo de vida de BPM. Este conjunto de herramientas son llamadas Business Process Management System y con ellas se construyen aplicaciones BPM.

BPM no esta acoplado al mundo SOA, se puede controlar procesos de una aplicación usando BPM sin tener servicios web. Pero BPM se puede utilizar para modelar flujo de trabajo llamando servicios web. Permitiendo una gran flexibilidad el flujo de trabajo no depende de una aplicación sino que esta constituido por servicios referenciados por una URI. El motor BPM no esta acoplado a implementaciones sino que conoce solo interfaces dadas por WSDLs o otros descriptores desacoplando el motor BPM de los servicios. Además se puede extender el motor BPM para que ofrezca información del workflow por servicios web. Proporcionando funcionalidades completas por servicios web.

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.

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.

BPM

BPM (Business Process Management) es lo que normalmente llamabamos workflow, es decir es un a forma de representar los procesos, los cuales son seguidos por el sistema. Permitiendo en tiempo de ejecución modificar el workflow y que se aplique estos cambios sin volver a compilar ni a bajar o subir la aplicación.

BPM marca al sistema el orden de ejecución de procesos dando la flexibilidad para poder modificar este orden cuando se lo desee. Esto permite centrarse en la lógica de negocio dando el poder de decisión al usuario final el cual por medio de un editor puede modificar el workflow como crea más conveniente. Se centra en el negocio. Faculta a los individuos de cualquier rincón de una empresa para alcanzar un mayor éxito. Reúne a personas y sistemas. BPM es donde se condensan todas las elevadas ambiciones y mejores estrategias.

BPM es un concepto muy sencillo. Es un conjunto de métodos, herramientas y tecnologías utilizados para diseñar, representar, analizar y controlar procesos de negocio operacionales; un enfoque centrado en los procesos para mejorar el rendimiento que combina las tecnologías de la información con metodologías de proceso y gobierno.

El objetivo de una solución para la gestión de procesos de negocio es proporcionar, dentro de las TI, implementaciones automatizadas de procesos de negocio de la vida real, como por ejemplo los procesos de pedidos y cobros, o de gestión de reclamaciones. Combinada con una SOA, esta forma de proporcionar funcionalidades de TI, con una visión orientada a procesos.

La tecnología BPM es el resultado de muchos años de experiencia en desarrollo y aplicación; el producto de los avances más actuales en sistemas y procesamiento de información; la cumbre de todas las arquitecturas, lenguajes y protocolos informáticos. La tecnología BPM constituye un gran avance, y un nuevo paradigma en cuanto a flexibilidad, gestión y control de información y datos.

BPM, como práctica de gestión integral, es el resultado de la combinación de avances técnicos con métodos y prácticas establecidos, de un modelo empresarial centrado en el proceso.

La tecnología BPM incluye todo lo que necesita a la hora de diseñar, representar, analizar y controlar los procesos de negocio operacionales:

• El diseño y modelado de procesos posibilitan que, de forma fácil y rigurosa, pueda definir procesos que abarcan cadenas de valor y coordinar los roles y comportamientos de todas las personas, sistemas y otros recursos necesarios.
• La integración le permite incluir en los procesos de negocio cualquier sistema de información, sistema de control, fuente de datos o cualquier otra tecnología. La arquitectura orientada a servicios (SOA) lo hace más rápido y fácil que nunca. No es necesario desprenderse de las inversiones ya realizadas; todo se puede reutilizar.
• Los entornos de trabajo de aplicaciones compuestas le permiten construir e implementar aplicaciones basadas en web casi de forma instantánea, completamente funcionales y sin necesidad de código.
• La ejecución convierte de forma directa los modelos en acción en el mundo real, coordinando los procesos en tiempo real.
• La supervisión de la actividad de negocio (BAM) realiza el seguimiento del rendimiento de los procesos mientras suceden, controlando muchos indicadores, mostrando las métricas de los procesos y tendencias clave y prediciendo futuros comportamientos.
• El control le permite responder a eventos en los procesos de acuerdo a las circunstancias, como cambio en las reglas, notificaciones, excepciones y transferencia de incidentes a un nivel superior.

Libro Gratuito de Soap y BPM

Encontré un par de libros gratuitos sobre BPM y SOA que nos brinda de forma gratuita la gente de Software AG.

http://www.softwareag.com/es/res/books/soa_adoption_for_dummies/default.asp
http://www.softwareag.com/es/res/books/bpm_for_dummies/default.asp

Que los disfruten!!!