Blogs Ándago blog-andago

El segundo día (22 de Octubre)

 

El día siguiente nos centramos en Apache Camel  (FUSE Mediaton Router) y su integración o uso en ServiceMix 4 (FUSE ESB). El proyecto Apache Camel es un DSL(Domain Specific language) orientado a la implementación de EIP's (Enterprise Integration patterns) que además integra una serie de tecnologías tales como JMS, HTTP, FTP, SOAP, FILE, ...

 

Las ventajas de usar Camel son:

• Reduce el tiempo de creación de flujos de integración.
• Reduce la complejidad de los flujos de integración y su mantenimiento.
• Las rutas pueden ser desplegadas en distintos tipos de contenedores java (Ostia, JEE, Servilleta...)

 

Una ruta en Camel puede entenderse como un recorrido paso a paso de un mensaje. Existe un "listener" que consume el mensaje, un destino que produce la salida y además pueden existir entre medias toda una serie de componentes que procesan y/o redirigen el mensaje. Para la especificación de dichas rutas se pueden utilizar ficheros de configuración (Spring) o el lenguaje Java DSL (Domain Specific Language).

 

En Camel existe toda una serie de componentes que dan soporte a distintas tecnologías:

• Web Services
• JMS/ActiveMQ
• E-mail
• HTTP
• JBI
• Java Beans
• Velocity / XSLT
• Jakarta logging
• ...

 

Para definir las rutas en Camel se utilizan endpoints, puntos de entrada y salida que utilizan los componentes para comunicarse con los demás. Su definición es simple y basta con seguir la siguiente nomenclatura:

 

prefix:uri[?options]

 

donde:

• prefix: Identifica el componente (jms, jetty, activemq, jbi...)
• uri: restante de la dirección, su significado depende del componente
• options: opciones del tipo nombre=valor

 

 

Ejemplo de nomenclatura del componente file que permite manejar ficheros :

 

• file:///directoryPath[?options]

 

Ejemplo de nomenclatura del componente log que permite dejar mensajes de log :

 

• log:logingCategory[?options]

 

Y otro ejemplo más de otro componente que nos permite trabajar con un servidor FTP:

 

• ftp:url[?options]

 

El componente JBI y NMR permiten a Camel enviar mensajes entre bundles. Ambos están basados en el NMR (Normalized Message Router), utilizan mensajes normalizados y facilitan el uso asíncrono de comunicación, pero la gran diferencia es que mientras el componente JBI se despliega en el contenedor JBI de ServiceMix, el componente NMR ha de ser desplegado en el contenedor OSGi de ServiceMix. Se recomienda utilizar el NMR por cuestiones de rendimiento.

 

Aunque queden muchos aspectos que se han quedado en el tintero espero haber dado las suficientes pinceladas para explicar de forma resumida y muy general la utilidad y la potencia de FUSE ESB (Apache ServiceMix) y el FUSE Mediation Router (Apache Camel) y en particular algunos aspectos tratados en el curso.

 

Recomiendo a todo aquél interesado en Apache ServiceMix 4 y Apache Camel a uno de los cursos de formación que programan periódicamente. Aun siendo la formación en Inglés, el instructor hablaba claro y pausado y no tuve ningún problema en seguir las explicaciones, si en algún momento necesitabas alguna aclaración podías "levantar la mano", interrumpirle y realizar tu pregunta. Incluso Adrian Trenaman tuvo la consideración de quedarse tras el curso conectado al canal de IRC habilitado para el curso y contestar a nuestras dudas pendientes y otros temas no relacionados directamente con el curso.

 

Y por último, si me tengo que quedar con una frase del curso, aunque no haya hablado de BPEL en este artículo yo me quedo con: "Trust me, BPEL is a Devil's invention" ( "Créeme, BPEL es un invento del Diablo" ).

 

 

El primer día

 

El curso empezó con una introducción a FUSE ESB: Solución open source basado en el Bus de Servicios Corporativos (Enterprise Service Bus) Apache ServiceMix 4 basado en la tecnología OSGi. FUSE ESB es capaz de soportar múltiples modelos de componentes:

 

- OSGi bundles

- Artefactos JBI

- Servlets

- Spring beans

- Rutas Camel (http://camel.apache.org)

- Servicios Web CXF

- ...

 

FUSE ESB posee una arquitectura por capas dividida en dos grandes bloques. El "core" se basa en OSGí como plataforma de ejecución con una serie de características añadidas para el manejo y gestión de OSGi bundles y la capa llamada "tecnológica", que se sitúa sobre ella, engloba una serie de componentes que dan soporte a distintas tecnologías:

 

 

 

El kernel de FUSE ESB extiende la capa OSGí con las siguientes características:

 

- Logging

- Provisionamiento de instalables

- Configuración dinámica

- Administración

- Despliegue de componentes

 

Para trabajar con el kernel se puede utilizar la consola de comandos que permite tratar con cada uno de las características antes mencionadas ya se de forma local o remota. Está basado en "GShell" por lo que es fácilmente extensible y cada subsistema del kernel posee su propio repertorio (sub-shell) de comandos. El aspecto que presenta esta consola al arrancar el kernel es la siguiente:

 

 

 

 

Cabe mencionar con respecto al provisionamiento que ServiceMix usa el término de "feature" para referirse a un mecanismo de agrupación de "bundles" (componentes osgi instalables). Éstas "features" permiten a través de un descriptor XML definir todos aquéllos bundles que forman una aplicación o solución y ser manejados como conjunto. Una herramienta muy útil cuando trabajas con un elevado número de bundles que agrupados definen tu solución.

 

Existen diferentes implementaciones de la especificación OSGi:

 

- Apache Felix (Apache Software Fundation)

- Equinox (Eclipse Fundation)

- ...

 

ServiceMix empezó utilizando Equinox pero ya utiliza Apache Felix en las versiones mas recientes aunque puede ser desplegado sobre otras implementaciones.

 

¿Qué es un bundle? Un bundle no es más que un empaquetado "jar" con alguna información extra (meta-datos) en su MANIFEST.MF. Los meta-datos que debe incluir el este fichero de texto plano (MANIFEST.MF) son:

 

- BundleName: Nombre descriptivo y amigable del bundle.

- Bundle-Symbolic-Name: Nombre único que identifica el bundle

- Bundle-Version: Version del bundle en formato X.X.X

- Export-Package: Lista de paquetes java que quedan visibles del bundle y pueden ser utilizados por otros bundles.

- Import-Package: Lista de paquetes java que requiere el bundle, aquéllos que corresponden con java.* son importados por defecto siempre.

 

El sistema de exportación e importación de paquetes entre bundles da lugar a un sistema de class-loading en forma de grafo en contraposición a la estructura en árbol que presenta el modelo de class-loading de la maquina virtual de java (evitando así los típicos problemas de dependencias de librerías y respectivas versiones desplegadas en múltiples niveles del árbol). En definitiva OSGí provee de una serie de mecanismos de despliegue de componente java de una forma modular. Se encarga de dependencias, versionado, control del classpath..., está entrando con fuerza en el espacio del software corporativo y tiene una gran comunidad que lo respalda. La prueba de ello es que existen ya una serie de herramientas libres a nuestra disposición que dan soporte a la creación de OSGí bundles como Maven, Eclipse, Bnd, Ops4j, etc.

 

 

 

En Ándago estamos trabajando en nuestra plataforma ESB denominada PIEL para la integración de las distintas plataformas y backoffices (como por ejemplo servicios de terceros). ESB son las siglas de Enterprise Service Bus (Bus de Servicios Corporativos). Un Open Source ESB podríamos definirlo como una plataforma de integración centrada en estándares abiertos que combina las arquitecturas SOA (Services Oriented Architecture) y EDA (Event Driven Architecture) que se debería de encargar de:

 

- La localización transparente de los servicios

- La conversión de protocolos de transporte

- La transformación de mensajes

- El enrutado de mensajes

- La mejora de los mensajes

- La seguridad

- La gestión y monitorización

 

Para llevar a cabo nuestro proyecto hemos elegido FUSE ESB. FUSE ESB además de basarse en Apache ServiceMix, es una solución ofrecida por los propios commiters de ServiceMix cuya principal ventaja es que presenta con mayor frecuencia versiones que arreglan bugs y otras con nuevas características que luego se van incorporando finalmente a siguientes versiones de Apache ServiceMix. Por lo tanto FUSE ESB está más orientado al mundo empresarial y ServiceMix es el proyecto de la comunidad en el que se basan y también contribuyen al mismo tiempo. Además FuseSource ofrece otros servicios de soporte al desarrollo e implantación de sus productos como por ejemplo cursos de formación.

 

Por ello nos animamos a participar en el curso online de FuseSource "Developer Training for ServiceMix 4.x with Camel" que se impartía el 21 y 22 de Octubre. Se trataba de un curso online interactivo intensivo de dos días que a través de una sesión WebEx, un canal IRC para comunicarnos con otra persona para resolver dudas si nos retrasábamos y también existía la opción de llamar por teléfono al instructor Adrian Trenaman.

 

Continuará ...

 

 

Se acaba de aprobar el Real Decreto que fija las pautas a seguir para alcanzar la ansiada interoperabilidad entre las diferentes administraciones públicas. El enfoque que se ha seguido en dicho esquema es definir la interoperabilidad entre diferentes organizaciones, utilizando tecnologías semánticas y promoviendo el uso de estándares abiertos y tecnologías que permitan dicha interoperabilidad.

Se cubren también otros temas como la reutilización de las tecnologías o los esquemas de compatibilidad de firma electrónica y certificados, así como la gestión documental.

Hoy justo empezamos un curso sobre ESB en Ándago, una de las tecnologías clave a la hora de alcanzar esta interoperabilidad y poder montar plataformas SaaS abiertas y escalables. Tendremos muy en cuenta este tipo de esquemas de interoperabilidad para garantizar su cumplimiento.

Años de proclamar los estándares abiertos, leyes como la Ley 11/2007 LACSP (Ley de Acceso del Ciudadano a los Servicios Públicos) que promueve la interoperabilidad entre todos las aplicaciones del Sector Público, principios como el "DATO" debe ser de la AAPP y   no del software de un fabricante determinado, y todavía en cualquier proyecto de Modernización Administrativa te enfrentas a las reticencias de los fabricantes de backoffice a que las AAPP puedan interoperar con sus software.

Muchos fabricantes de software de gestión para el sector público, tales como gestión municipal, frenan la posibilidad de interoperar con sus aplicaciones porque tienen a  miedo a la entrada de nuevos proveedores dentro de una organización. El problema no es que haya que pagar el desarrollo de dichos mecanismos de integración, sino que muchos de ellos intentan mantener su posición en los clientes frenando la integración de las decenas de aplicaciones existentes para cubrir todas las áreas de gestión, y sólo ofreciendo la posibilidad de nuevas funcionalidades que sólo funcionan con sus backoffice existentes.

Las administraciones públicas deben obligar a sus proveedores a ofrecer mecanismos de interoperabilidad e integración en cada uno de sus aplicaciones. Esta apertura no sólo es buena para la AAPP y la ciudadanía en general al ofrecer nuevos Servicios Públicos Digitales, sino para todos los proveedores de tecnología incluidos aquellos que ofrecen dichos mecanismos, ya que podrán ofrecer nuevas funcionalidades en sus aplicaciones utilizando servicios ofrecidas por otras aplicaciones o servicios externos. A corto plazo, frenar la interoperabilidad no sólo será contraprudecente para el proveedor por la sensación de  "esclavitud del proveedor" que genera en el cliente, sino que perderá muchas nuevas funcionalidades que ofrecer a los clientes en un modo de interoperabilidad. Pero en un futuro no muy lejano, seguro que los pliegos de adquisición de software para el sector público obliga a que el software ofrezca dichos mecanismos.

Otro aspecto importante es que se haga un esfuerzo por la definición de "interfaces de interoperabilidad" para distintos dominios de aplicación (padrón, tributos, ....) para que todas la aplicaciones las implemente, y se puedan crear nuevas funcionalidades mediante la orquestación de servicios.

A la espera de liderazgo por determinadas administraciones en esta definición en Ándago estamos definiendo un conjunto de "Dominios de Interoperabilidad" y de implementaciones para determinados backoffice dentro de nuestra iniciativa SOA Open Source para gestión municipal denominada PIEL (Plataforma de Interoperabilidad en Entidades Locales).   Invitamos a administraciones, fabricantes de sotware, e integradores a colaborar en la definición y desarrollo compartido de dominios de interoperabilidad y conectores que permitan crear Servicios Públicos Digitales mejor integrados y avanzados para los ciudadanos.

 

http://piel.andago.com