MuleSoft - Mule项目

---

---

Mule 项目背后的动机是 -

• 为程序员简化工作，

• 需要轻量级、模块化的解决方案，该解决方案可以从应用程序级消息传递框架扩展到企业级高度可分配框架。

Mule ESB 被设计为一个事件驱动的同时也是一个编程框架。它之所以是事件驱动的，是因为它与统一的消息表示相结合，并可以通过可插拔模块进行扩展。它之所以是编程性的，是因为程序员可以轻松地植入一些附加行为，如特定消息处理或自定义数据转换。

历史

Mule 项目的历史视角如下 -

SourceForge 项目

Mule 项目于 2003 年 4 月启动，作为 SourceForge 项目，并且在其首个版本发布并移至 CodeHaus 2 年之后。通用消息对象 (UMO) API 是其架构的核心。UMO API 背后的想法是在将逻辑统一起来的同时，将其与底层传输保持隔离。

1.0 版

该版本于 2005 年 4 月发布，其中包含许多传输。随后的许多其他版本的关键重点在于调试和添加新功能。

2.0 版（采用 Spring 2）

Spring 2 作为配置和接线框架在 Mule 2 中被采用，但由于缺少所需的 XML 配置的可表达性，这被证明是一个重大的改进。在 Spring 2 中引入基于 XML 模式的配置时，这个问题得到了解决。

通过 Maven 构建

简化 Mule 使用的最大改进（在开发和部署时间）是使用 Maven。从 1.3 版本开始，它开始通过 Maven 构建。

MuleSource

2006 年，MuleSource 成立，“以帮助支持和帮助快速增长的社区在关键任务企业应用程序中使用 Mule”。它被证明是 Mule 项目的一个关键里程碑。

Mule ESB 的竞争对手

以下是 Mule ESB 的一些主要竞争对手 -

• WSO2 ESB
• Oracle 服务总线
• WebSphere 消息代理
• Aurea CX 平台
• Fiorano ESB
• WebSphere DataPower Gateway
• Workday 业务流程框架
• Talend 企业服务总线
• JBoss 企业服务总线
• iWay 服务管理器

Mule 的核心概念

如前所述，Mule ESB 是一款轻量且高度可扩展的基于 Java 的企业服务总线 (ESB) 和集成平台。Mule ESB 无论应用程序使用何种技术，都能轻松集成应用程序，使应用程序之间能够交换数据。在本节中，我们将讨论使此类集成得以实现的 Mule 核心概念。

为此，我们需要了解其架构和构建基块。

架构

Mule ESB 架构包含三层，即传输层、集成层和应用程序层，如下所示 −

通常，可以执行以下三类任务来配置和自定义 Mule 部署 −

服务组件开发

此任务涉及开发或重新使用现有 POJO 或 Spring Bean。POJO 是一个包含生成 get 和 set 方法以及云连接器的带有属性的类。而 Spring Bean 则包含用于丰富消息的业务逻辑。

服务编排

此任务基本提供服务中介，涉及配置消息处理器、路由器、转换器和筛选器。

集成

Mule ESB 最重要的任务是集成各种应用程序，无论它们使用何种协议。为此，Mule 提供传输方法，允许在各种协议连接器之上接收和分派消息。Mule 支持许多现有传输方法，我们也可以使用自定义传输方法。

构建基块

Mule 配置具有以下构建基块 −

Spring Bean

Spring Bean 的主要用途是构建服务组件。构建 Spring 服务组件后，我们可以通过配置文件对它进行定义，或者在没有配置文件的情况下手动进行定义。

代理

它基本上是在 Mule Studio 之前在 Anypoint Studio 中创建的服务。代理是在启动服务器后创建的，在停止服务器后将被摧毁。

连接器

它是一个配置有特定于协议的参数的软件组件。它主要用于控制协议的使用。例如，JMS 连接器已配置有一个“连接”，该连接器将在负责实际通信的各种实体之间共享。

全局配置

顾名思义，此构建基块用于设置全局属性和配置。

全局终结点

它可以在“全局元素”选项卡中使用，可以在流程中多次使用 −

全局消息处理器

顾名思义，它观察或修改消息或消息流程。转换器和筛选器是全局消息处理器的示例。

转换器 − 转换器的主要工作是将数据从一种格式转换为另一种格式。它可以在全局进行定义，并可以在多个流程中使用。

筛选器 − 它是一个将决定应处理哪条 Mule 消息的筛选器。筛选器基本上会指定消息必须满足的条件，然后才会对消息进行处理并将其路由到服务。

模型

它与代理形成对比，它是在 Studio 中创建的服务的一个逻辑分组。我们可以自由启动和停止特定模型内的所有服务。

服务 − 服务是包装我们的业务逻辑或组件的服务。它还会专门针对该服务配置路由器、终结点、转换器和筛选器。

端点 − 它是可以定义为服务将入站（接收）和出站（发送）消息的对象。服务通过端点连接。

流程

消息处理器使用流程来定义源与目标之间的消息流程。

Mule 消息结构

Mule 消息完全封装在 Mule 消息对象中，是通过 Mule 流程在应用程序间传递的数据。Mule 消息的结构在以下图表中显示 −

如图所示，Mule 消息包含两个主要部分 -

头部

它只是该消息的元数据，由以下两个属性进一步表示 −

入站属性 − 这些是由消息源自动设置的属性。它们不能被用户修改或设置。实际上，入站属性是不可变的。

出站属性 − 这些属性包含元数据，如入站属性，可以在流程中设置。它们可以由 Mule 自动设置，也可以由用户手动设置。实际上，出站属性是可变的。

当消息通过传输从一个流程的出站端点传递到另一个流程的入站端点时，出站属性变为入站属性。

当消息通过流引用而不是连接器传递到新流程时，出站属性仍然是出站属性。

有效载荷

消息对象承载的实际业务消息称为有效载荷。

变量

它可以定义为用户定义的关于消息的元数据。基本上，变量是应用程序在处理消息时使用的有关消息的临时信息片段。它不应连同消息一起传递给其目标位置。它们有三种类型，如下所示 −

流程变量 − 这些变量仅适用于它们所存在的流程。

会话变量 − 这些变量适用于同一应用程序中的所有流程。

记录变量 − 这些变量仅适用于作为批处理一部分处理的记录。

附件和额外有效载荷

这些是有关消息有效载荷的一些额外元数据，而不是每次都会出现在消息对象中。