MuleSoft - Mule 项目

Mule 项目背后的动机是 −

  • 让程序员的工作更简单,

  • 需要轻量级和模块化的解决方案,可以从应用程序级消息传递框架扩展到企业范围内高度可分布的框架。

Mule ESB 被设计为事件驱动和编程框架。它之所以是事件驱动的,是因为它结合了消息的统一表示,并且可以通过可插入模块进行扩展。它是可编程的,因为程序员可以轻松植入一些额外的行为,例如特定的消息处理或自定义数据转换。

历史

Mule 项目的历史视角如下 −

SourceForge 项目

Mule 项目于 2003 年 4 月作为 SourceForge 项目启动,两年后其第一个版本发布并移至 CodeHaus。通用消息对象 (UMO) API 是其架构的核心。UMO API 背后的想法是统一逻辑,同时使它们与底层传输隔离。

版本 1.0

它于 2005 年 4 月发布,包含多种传输。随后的许多其他版本的主要重点是调试和添加新功能。

版本 2.0(采用 Spring 2)

Mule 2 采用了 Spring 2 作为配置和布线框架,但由于所需 XML 配置缺乏表现力,因此被证明是一次重大改革。当在 Spring 2 中引入基于 XML Schema 的配置时,此问题得到了解决。

使用 Maven 构建

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

MuleSource

2006 年,MuleSource 成立,"以帮助支持和推动在关键任务企业应用程序中使用 Mule 的快速增长社区"。事实证明,这是 Mule 项目的关键里程碑。

Mule ESB 的竞争对手

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

  • WSO2 ESB
  • Oracle Service Bus
  • WebSphere Message Broker
  • Aurea CX Platform
  • Fiorano ESB
  • WebSphere DataPower Gateway
  • Workday Business Process Framework
  • Talend Enterprise Service Bus
  • JBoss Enterprise Service Bus
  • iWay Service Manager

Mule 的核心概念

如上所述,Mule ESB 是一个轻量级且高度可扩展的基于 Java 的企业服务总线 (ESB) 和集成平台。无论应用程序使用何种技术,Mule ESB 都可以轻松集成应用程序,使它们能够交换数据。在本节中,我们将讨论 Mule 的核心概念如何发挥作用,以实现这种集成。

为此,我们需要了解其架构以及构建块。

架构

Mule ESB 的架构分为三层,即传输层、集成层和应用层,如下图所示 −

Mule 核心概念

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

服务组件开发

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

服务编排

此任务基本上提供服务中介,涉及配置消息处理器、路由器、转换器和过滤器。

集成

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

构建块

Mule 配置具有以下构建块 −

Building Blocks

Spring beans

Spring beans 的主要用途是构建服务组件。构建 spring 服务组件后,我们可以通过配置文件定义它,或者如果您没有配置文件,也可以手动定义它。

代理

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

连接器

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

全局配置

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

全局端点

它可以在"全局元素"选项卡中使用,该选项卡可以在流中使用多次 −

全局消息处理器

顾名思义,它观察或修改消息或消息流。转换器和过滤器是全局消息处理器的示例。

转换器 − 转换器的主要工作是将数据从一种格式转换为另一种格式。它可以全局定义,并可用于多个流。

过滤器 − 过滤器将决定应该处理哪条 Mule 消息。过滤器基本上指定了处理消息并将其路由到服务所必须满足的条件。

模型

与代理不同,它是在工作室中创建的服务的逻辑分组。我们可以自由地启动和停止特定模型内的所有服务。

服务 − 服务是包装我们的业务逻辑或组件的服务。它还专门为该服务配置路由器、端点、转换器和过滤器。

端点 − 它可以定义为服务将在其上传入(接收)和传出(发送)消息的对象。服务通过端点连接。

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

Mule 消息结构

Mule 消息完全包装在 Mule 消息对象下,是通过 Mule 流通过应用程序的数据。Mule 消息的结构如下图所示 −

消息结构

如上图所示,Mule 消息由两个主要部分组成 −

Header

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

入站属性 − 这些是由消息源自动设置的属性。它们不能由用户操纵或设置。本质上,入站属性是不可变的。

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

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

当消息通过 flow-ref 而不是连接器传递到新流时,出站属性仍为出站属性。

有效负载

消息对象携带的实际业务消息称为有效负载。

Variables(变量)

它可以定义为有关消息的用户定义元数据。基本上,变量是处理该消息的应用程序使用的有关该消息的临时信息。它不打算与消息一起传递到其目的地。它们有以下三种类型 −

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

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

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

附件和额外有效负载

这些是关于消息有效负载的一些额外元数据,不一定每次都出现在消息对象中。