Blog de Mule

Muy bueno el blog de Mule Soft (el ESB Open Sources) recomendado: http://blogs.mulesoft.org/

Mule ESB

Mule es un Enterprise Service Bus liviano dirigido a eventos y también es una plataforma de integración. Mule es uno de los ESB Open Sources más usados.

Pero para que necesito Mule ESB? Supongamos que tenemos una aplicación que acepta solo XSL-FO y los envía a una cola JMS y yo estoy haciendo una pagina que le debe enviar un mensaje; uso como formato texto por http. Mule puede estar en el medio de esta conversación y traducir texto a XSL-FO y cambiar el protocolo http a JMS haciendo que no tenga que programar las traducciones.

El mensaje pasa por varias capas lógicas, la primera es la capa de modelo. Esta proporciona servicios, tales como las estrategiasde excepción. Además, presta servicios con valores por defecto para simplificar su configuración.

Luego viene la capa de servicios. La capa de servicio se compone de todas las entidades involucradas en el procesamiento, en particular peticiones de maneras predefinidas. En el ejemplo el servicio tendría que actuar como un puente entre la entrada HTTP y los mensajes salientes mensajes JMS.

La capa de transporte es la encargada de la comunicación entrante y saliente. Un transporte se representa en la configuración de los siguientes elementos: conectores, terminales y transformadores.

Un conector es responsable de controlar el uso de un protocolo particular. Está configurado con los parámetros que son específicos de este protocolo. Por ejemplo, un conector JMS está configurado con una conexión, que es compartida por las distintas entidades encargadas de la comunicación real.

Un endpoint representa el uso específico de un protocolo, ya sea para escuchar  o publicar un servicio.
Transformer como su nombre indica, un transformador se encarga de traducir el contenido de un mensaje de una forma a otra.

Los Routers  juegan un papel crucial en el control de la trayectoria de un mensaje es el que controla el transito en Mule.

Los Components son la pieza central de los servicios de mula. Cada servicio se organiza con un componente en su núcleo y los routers de entrada y salida a su alrededor.

Con esto vimos un poco de terminología de mule ESB, luego veremos un caso práctico.

Instalar Mule ESB en linux

Vamos a instalar Mule ESB en linux, Mule es un ESB que funciona muy bien y es el más usado de los ESB open sources.

Primero vamos a bajarlo de : http://www.mulesoft.org/download-mule-esb-community-edition

Luego de descargarlo vamos a copiarlo a opt (utilice root o un usuario con permisos)

mkdir /opt/muleESB
mv Descargas/MuleStudio-CE-for-Linux-64bit_20120120.zip /opt/muleESB/

Descomprimimos:

cd /opt/muleESB
unzip  MuleStudio-CE-for-Linux-64bit_20120120.zip

Ahora damos permisos correspondientes:

chmod u+x MuleStudio/

Y con esto ya estamos. Para utilizar mule tienes que tener configurada la jdk de java. Para esto podemos descargar la jdk del siguiente link: http://www.oracle.com/technetwork/java/javase/downloads/index.html

Cuando descarguemos este .bin solo hay que ejecutarlo y luego configurar la variable de entorno JAVA_HOME.

export JAVA_HOME=/java/sdk/jdk1.6.0_26

Y luego podemos ejecutar Mule

cd  MuleStudio
./muleStudio

Y ya esta!!

Porque utilizar ESB?

En arquitectura SOA el software se ve como funcionalidad colgada en una rul la cual se organiza para solucionar una necesidad del negocio.
Por ejemplo tenemos organizado 4 modulos los cuales se interrelacionan esto se veria de la siguiente forma:

Por que no poner un software que mantenga las rutas de comunicación sería como un router de nuestros servicios.

Se ve mejor no? Ese software que se encuentra en el medio de las comunicaciones de mis servicios es un ESB.



Ahora bien si un servicio expone su funcionalidad con SOAP otro con REST otro con RMI, otro con JMS etc. tengo que escribir mucho código de traducción para poder comunicar servicios. Ya se pongamos esta traducción en el ESB de esta forma el centraliza las traducciones y reutiliza ese código para comunicara diferentes servicios.



De esta forma el ESB nos permite comunicar diferentes piezas de software que se expresan de forma diferente. Ojo esto no es una funcionalidad que tengan todos los ESB por ejemplo Apache Synapsis no la trae. Pero la gran mayoría si.



En resumen esto es un ESB. 

Instalar características opcionales en ServiceMix

Para listar las características de serviceMix desde la consola con este comando:

karaf@root>features:list

Con esto tenemos el listado de características instaladas como las que no estan instaladas.
Para instalar una característica solo con el comando:

karaf@root>features:install webconsole

Con esto por ejemplo instalamos la web consola. Y con el siguiente comando lo verificamos:


karaf@root> features:list | grep webconsole

Agregar ActiveMQ al ejemplo de ServiceMix

Continuando con el ejemplo:
http://emanuelpeg.blogspot.com/2012/03/usando-apache-camel-desde-apache.html

En el anterior ejemplo creamos una ruta que movía un archivo de una carpeta a otra, bueno ahora vamos a crear un evento de ActiveMQ cuando se mueva un archivo.

Por lo tanto el archivo xml que habia llamado copia queda así:

    
      
        
        

        
          
            FileMovedEvent(file: ${file:name}, timestamp: ${date:now:hh:MM:ss.SSS})
          
        
        
      
    

Donde  FileMovedEvent va ser un evento generado por la copia y va a ser publicado en  activemq://events

Si vemos el log no vamos a ver nada porque los eventos no sos consumidos por un cliente por lo que vamos a hacer un cliente:

Guardamos este archivo tambien en la carpeta deploy con el nombre que quieran, yo le voy a poner cliente.xml

Con este cliente vamos a poder ver en el log las copias.
Reiniciamos copia.xml
osgi:stop 156
osgi:start 156

Y listo!

Dejo link de la fuente:
http://servicemix.apache.org/docs/4.4.0/quickstart/

Usando Apache Camel desde Apache ServiceMix

Para mayor comprensión pueden ver el siguiente post:
http://emanuelpeg.blogspot.com/2012/03/primeros-pasos-con-apache-servicemix.html

La idea sería construir un pequeño ejemplo de integración con Apache Camel y vamos a deployarlo en ServiceMix. La idea es copiar un archivo desde la carpeta input a la carpeta output y para mantener un registro escribir un log.

Uno de los caminos más simples para deployear un router de Camel en ServiceMix es definir el router en un Blueprint XML.

Este archivo hay que guardarlo en la carpeta deploy de servicemix yo le puse copia.xml

Ahora a deployear, si ejecutamos osgi:list vamos a ver nuestro servicio llamado “copia.xml”

Con osgi:start y el id del servicio podemos levantar el servicio; en mi caso el número 156

osgi:start 156

y si lo queremos parar con

osgi:stop 156

Ya esta! Si hacemos:

log:display | grep INFO

Podemos ver como se movieron los archivos.

Primeros pasos con Apache ServiceMix

Para instalar ServiceMix vea este post: http://emanuelpeg.blogspot.com/2012/03/instalar-apache-servicemix-en-linux.html

Ya en la consola podemos listar los paquetes o bundles que estan activos y los que no:

karaf@root> osgi:list

Con este comando listamos todos los paquetes instalados. Se muestra el id, estado, si es bluepring o Spring XML , el nivel, nombre y versión del paquete.

Podemos utilizar el pipe y comandos de unix, por ejemplo si necesitamos ver los paquetes de cxf:

karaf@root> osgi:list | grep cxf

Si se quiere trabajar con el log esta el comando:

karaf@root> log:display

Si solo se desea ver excepciones:

karaf@root> log:display-exception

Y también podemos cambiar el nivel de logeo con :

karaf@root> log:set DEBUG
karaf@root> log:display | grep DEBUG

Bueno este fue una primera vista general sobre Apache ServiceMix

Instalar Apache ServiceMix en Linux

Comenzamos bajando servicemix pueden bajarlo de aca: http://apache.dattatec.com//servicemix/servicemix-4/4.4.0/ o con wget pueden directamente usar esta url  http://apache.dattatec.com/servicemix/servicemix-4/4.4.0/apache-servicemix-full-4.4.0.tar.gz

Yo baje el tar, pero pueden bajar el zip para windows. Primero movemos el tar donde lo vamos a instalar   tiene que usar el usuario root o alguno que tenga permisos de escritura en la carpeta destino.

mkdir /opt/servicemix
mv apache-servicemix-full-4.4.0.tar.gz /opt/servicemix /

Y luego desempaquetamos:

tar xvfz apache-servicemix-full-4.4.0.tar.gz

Y borramos el tar:

rm apache-servicemix-full-4.4.0.tar.gz

Luego ejecutamos serviceMix

cd apache-servicemix-4.4.0/bin
./servicemix

Y obtendremos una pantalla así:

Dejo link: 

http://servicemix.apache.org/docs/4.4.0/quickstart/installation.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/

¿Cómo se desarrolla sobre una arquitectura SOA?

El desarrollo sobre una arquitectura SOA debe siempre tener en cuenta las funcionalidades desarrolladas y debe consumir estos servicios y exponer las nuevas funcionalidades. Por lo tanto es importante tener un registro actualizado donde se registran los servicios desarrollados y si la empresa cuenta con sistemas heredados con servicios expuestos se debe realizar un relevamiento de los servicios desarrollados y reflejarlos en el registro. Que el registro esté actualizado y sea visual para todos los desarrolladores es vital para que no exista comportamiento replicado.

El desarrollador esta obligado a pensar los servicios de forma atómica y desacoplada. Un servicio nunca debe depender de una implementación sino de una interfaz que describe a dicha dependencia, agregando más complejidad a la tarea de diseñar pero disminuyendo el esfuerzo de mantenimiento ante un cambio. Promoviendo el desacoplamiento y la mantenibilidad.

El estilo arquitectónico SOA no es intrusivo, no nos obliga a utilizar una forma propia de SOA para desarrollo, ni un Paradigma de programación, ni un lenguaje, ni plataforma. Pero si nos obliga a no repetir funcionalidad publicada y publicar los servicios de tal forma sean útiles a otros sistemas. Por ejemplo podríamos programar con POO y publicar la funcionalidad por medio de servicios o utilizar el patrón facade. En este esquema los servicios van a seguir la arquitectura SOA, dando la libertad de diseñar nuestros objetos independientes de la arquitectura SOA. Lo más recomendado es utilizar una arquitectura en Capas sumado a la arquitectura SOA.

Una arquitectura en capas nos permite separar de forma lógica las incumbencias generales en capas. El objetivo de separar las incumbencias en capas, es el desacoplamiento. De esta forma podríamos cambiar ciertas capas si necesidad de modificar las demás.

Sumado a la arquitectura SOA con la arquitectura en Capas, aprovechamos lo mejor de los dos mundos.
En la actualidad existen gran cantidad de framework que nos permiten desarrollar servicios web (CXF, Spring WS, Apache AXIS 1 y 2, Metro, etc.) y a la vez existen muchas formas de exponer estos servicios REST, SOAP, Mensajería, etc. y también existen diferentes formatos de datos JSON, SOAP, RSS, ATOM, etc. Todas estas tecnologías pueden conformar mis sistemas lo cual dificulta la comunicación ya que diferentes aplicaciones hablan diferentes idiomas.

Dada esta problemática surgió del mercado un estándar llamado Service Component Architecture (SCA), que propone una forma de desarrollo SOA. Basándose en el concepto de componentes promueve que un componente publica servicios que le permiten hablar idiomas diferentes (más usados) y entender la mayoría de los formatos de datos.

También a raíz de la diversidad de tecnologías para exponer servicios nace el ESB, que como dijimos anteriormente es un adaptador de diferentes “lenguajes”. Por lo tanto podríamos decidir utilizar un framework para exponer servicios y un ESB con su adaptador, o desarrollar con SCA. Dependiendo de los requerimientos se debe realizar una elección.

Gobierno SOA

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 ¿cómo se si no existe ya? O ¿existen servicios que pueden ayudar al nuevo servicio? Por lo tanto debo tener un registro donde registrar mis servicios, en el cual puedo buscar los servicios ya 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 gestión de los servicios se le llama gobierno SOA.

Gobierno de SOA es una ampliación del gobierno de IT centrada en el ciclo de vida1 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.
• CEP (Complex Event Processing) y Procesador de flujos de eventos o ESP(Event Stream Processing) son herramientas para diseñar, gestionar y monitorizar los eventos que fluyen a través de un entorno orientado a EDA dado.
• Integración de aplicaciones empresariales o EAI (Enterprise Application Integration) facilita la integración con aplicaciones o bases de datos de una empresa.

A la vez existen muchos frameworks que nos permiten desarrollar servicios SOA, con mayor flexibilidad y rapidez. Permitiendo obtener más fácilmente los beneficios del uso SOA y a la vez preparados para ser Gobernados por el gobierno SOA. En la tesis nos centraremos en el estándar de OASIS4, SCA (Service Component Architecture). SCA es un estándar que simplifica el desarrollo SOA basándose en el concepto de componentes. Nos centraremos en esta especificación dado que brinda gran facilidad en el desarrollo, además promueve el uso de las mejores prácticas.

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

FUSE

FUSE es una comunidad que promueve el uso de productos Apache para el uso de SOA. La idea es crear una comunidad Open Source de uso de SOA, de esta forma poder compartir experiencias, conocimiento, etc.

Dejo el link: http://fusesource.com/

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.

Aprendiendo SOA

Dejo algunos links que vienen bien leer:

http://blogs.tecsisa.com/articulos-tecnicos/¿por-que-soa/
http://blogs.tecsisa.com/articulos-tecnicos/¿por-que-un-enterprise-service-bus

Además les aconsejo un blog, Espacio SOA y además el mio jeje.

http://www.espaciosoa.net