MuleSoft - El proyecto Mule
Las motivaciones detrás del proyecto Mule fueron:
para simplificar las cosas a los programadores,
la necesidad de una solución liviana y modular que pudiera escalar desde un marco de mensajería a nivel de aplicación a un marco altamente distribuible en toda la empresa.
Mule ESB está diseñado como un marco programático y orientado a eventos. Está controlado por eventos porque se combina con una representación unificada de mensajes y se puede expandir con módulos conectables. Es programático porque los programadores pueden implantar fácilmente algunos comportamientos adicionales, como el procesamiento de mensajes específicos o la transformación de datos personalizados.
Historia
La perspectiva histórica del proyecto Mule es la siguiente:
Proyecto SourceForge
El proyecto Mule se inició como el proyecto SourceForge en abril de 2003, y después de 2 años se lanzó su primera versión y se trasladó a CodeHaus. La API de Objeto de mensaje universal (UMO) era el núcleo de su arquitectura. La idea detrás de la API de UMO era unificar la lógica y mantenerlos aislados de los transportes subyacentes.
Versión 1.0
Fue lanzado en abril de 2005 y contenía numerosos transportes. El enfoque clave de muchas otras versiones seguidas fue la depuración y la adición de nuevas funciones.
Versión 2.0 (adopción de Spring 2)
Spring 2 como marco de configuración y cableado se adoptó en Mule 2, pero resultó ser una revisión importante debido a la falta de expresividad de la configuración XML requerida. Este problema se resolvió cuando se introdujo la configuración basada en esquemas XML en Spring 2.
Construyendo con Maven
La mayor mejora que simplificó el uso de Mule, tanto en el desarrollo como en la implementación, fue el uso de Maven. A partir de la versión 1.3, se empezó a construir con Maven.
MuleSource
En 2006, MuleSource se incorporó "para ayudar a respaldar y habilitar a la comunidad en rápido crecimiento que usa Mule en aplicaciones empresariales de misión crítica". Resultó ser el hito clave para Mule Project.
Competidores de Mule ESB
A continuación se muestran algunos de los principales competidores de Mule ESB:
- WSO2 ESB
- Bus de servicio de Oracle
- WebSphere Message Broker
- Plataforma Aurea CX
- Fiorano ESB
- Pasarela de WebSphere DataPower
- Marco de procesos empresariales de Workday
- Bus de servicio empresarial de Talend
- Bus de servicio empresarial JBoss
- Gerente de servicios iWay
Concepto básico de Mule
Como se ha comentado, Mule ESB es una plataforma de integración y bus de servicios empresariales (ESB) basada en Java ligera y altamente escalable. Independientemente de las diversas tecnologías utilizadas por las aplicaciones, Mule ESB permite una fácil integración de las aplicaciones, lo que les permite intercambiar datos. En esta sección, discutiremos sobre el concepto central de Mule que entra en juego para hacer que dicha integración suceda.
Para ello, debemos comprender su arquitectura y los componentes básicos.
Arquitectura
La arquitectura de Mule ESB tiene tres capas, a saber, capa de transporte, capa de integración y capa de aplicación, como se muestra en el siguiente diagrama:
En general, existen los siguientes tres tipos de tareas que se pueden realizar para configurar y personalizar la implementación de Mule:
Desarrollo de componentes de servicio
Esta tarea implica el desarrollo o la reutilización de los POJO existentes o Spring Beans. POJOs es una clase con atributos que genera los métodos get y set, conectores en la nube. Por otro lado, Spring Beans contiene la lógica empresarial para enriquecer los mensajes.
Orquestación de servicios
Esta tarea básicamente brinda el servicio de mediación que implica configurar el procesador de mensajes, enrutadores, transformadores y filtros.
Integración
La tarea más importante de Mule ESB es la integración de varias aplicaciones independientemente de los protocolos que estén utilizando. Para ello, Mule proporciona métodos de transporte que permiten recibir y enviar los mensajes en varios conectores de protocolo. Mule admite muchos métodos de transporte existentes, o también podemos usar un método de transporte personalizado.
Bloques de construcción
La configuración de Mule tiene los siguientes bloques de construcción:
Frijoles de primavera
El uso principal de Spring beans es construir un componente de servicio. Después de construir el componente de servicio de Spring, podemos definirlo a través de un archivo de configuración o manualmente, en caso de que no tenga un archivo de configuración.
Agentes
Básicamente es un servicio creado en Anypoint Studio antes que Mule Studio. Se crea un agente una vez que inicia un servidor y se destruirá una vez que lo detenga.
Conector
Es un componente de software configurado con los parámetros específicos de los protocolos. Se utiliza principalmente para controlar el uso de un protocolo. Por ejemplo, un conector JMS está configurado con unConnection y este conector será compartido entre varias entidades encargadas de la comunicación real.
configuración global
Como su nombre lo indica, este bloque de construcción se utiliza para establecer las propiedades y configuraciones globales.
Puntos finales globales
Se puede usar en la pestaña Elementos globales, que se puede usar tantas veces en un flujo:
Procesador de mensajes global
Como su nombre lo indica, observa o modifica un mensaje o flujo de mensajes. Los transformadores y filtros son ejemplos de Procesador de mensajes global.
Transformers- El trabajo principal de un transformador es convertir datos de un formato a otro. Se puede definir globalmente y se puede utilizar en múltiples flujos.
Filters- Es el filtro que decidirá qué mensaje de Mule se debe procesar. El filtro básicamente especifica las condiciones que deben cumplirse para que un mensaje se procese y se enrute a un servicio.
Modelos
A diferencia de los agentes, es una agrupación lógica de servicios que se crean en Studio. Tenemos la libertad de iniciar y detener todos los servicios dentro de un modelo específico.
Services- Los servicios son los que envuelven nuestra lógica o componentes de negocio. También configura enrutadores, puntos finales, transformadores y filtros específicamente para ese servicio.
Endpoints- Puede definirse como un objeto en el que los servicios recibirán mensajes entrantes y salientes (enviarán). Los servicios están conectados a través de puntos finales.
Fluir
El procesador de mensajes utiliza flujos para definir un flujo de mensajes entre un origen y un destino.
Estructura del mensaje de mula
Un mensaje de Mule, totalmente envuelto en Mule Message Object, son los datos que pasan a través de aplicaciones a través de flujos de Mule. La estructura del mensaje de Mule se muestra en el siguiente diagrama:
Como se ve en el diagrama anterior, Mule Message consta de dos partes principales:
Encabezamiento
No son más que los metadatos del mensaje que además están representados por las siguientes dos propiedades:
Inbound Properties- Estas son las propiedades que configura automáticamente la fuente del mensaje. No pueden ser manipulados ni configurados por el usuario. En la naturaleza, las propiedades entrantes son inmutables.
Outbound Properties- Estas son las propiedades que contienen metadatos como una propiedad de entrada y se pueden establecer durante el curso del flujo. Pueden ser configurados automáticamente por Mule o manualmente por un usuario. En la naturaleza, las propiedades salientes son mutables.
Las propiedades de salida se convierten en propiedades de entrada cuando el mensaje pasa del punto final de salida de un flujo al punto final de entrada de un flujo diferente a través de un transporte.
Las propiedades de salida siguen siendo propiedades de salida cuando el mensaje se pasa a un nuevo flujo a través de una ref de flujo en lugar de un conector.
Carga útil
El mensaje comercial real transportado por el objeto de mensaje se denomina carga útil.
Variables
Puede definirse como los metadatos definidos por el usuario sobre un mensaje. Básicamente, las variables son piezas temporales de información sobre un mensaje que utiliza la aplicación que lo está procesando. No está destinado a transmitirse junto con los mensajes a su destino. Son de tres tipos, como se indica a continuación:
Flow variables - Estas variables se aplican solo al flujo en el que existen.
Session variables - Estas variables se aplican a todos los flujos dentro de la misma aplicación.
Record variables - Estas variables se aplican solo a los registros procesados como parte de un lote.
Archivos adjuntos y carga adicional
Estos son algunos metadatos adicionales sobre la carga útil del mensaje que no necesariamente aparecen siempre en el objeto del mensaje.