Mulesoft 简明教程

Mule项目始于2003年4月的SourceForge项目，两年后其第一版发布并转移到CodeHaus。通用消息对象（UMO）API是其架构的核心。UMO API背后的理念是统一逻辑，同时使它们与底层传输保持隔离。

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

Spring 2作为配置和连接框架被采纳到Mule 2中，但它被证明是一次重大的检修，因为缺少对必需的XML配置的表达力。当基于XML架构的配置被引入Spring 2时，此问题得到解决。

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

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

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

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

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

Spring bean 的主要用途是构建服务组件。构建 Spring 服务组件后，如果用户没有配置文件，可以通过配置文件或手动定义服务组件。

它最初是 Anypoint Studio 中在 Mule Studio 之前创建的服务。一旦服务器启动，将会创建一个代理，一旦服务器停止，将会销毁该代理。

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

顾名思义，这个构建块用于设置全局属性和设置。

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

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

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

Filters - 它是一个过滤器，将决定应该处理哪条 Mule 消息。过滤器基本上指定消息必须满足的条件，然后才能处理并路由到服务。

与代理相反，它是工作室中创建的服务的逻辑分组。我们有权启动和停止特定模型中的所有服务。

Services - 服务是封装业务逻辑或组件的服务。它还专门为该服务配置了路由器、端点、转换器和过滤器。

Endpoints - 可以将其定义为一个对象，服务将在其上入站（接收）和出站（发送）消息。服务通过端点连接。

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

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

Inbound Properties - 这些属性由消息源自动设置。它们不能由用户操作或设置。本质上，入站属性是不可变的。

Outbound Properties - 这些属性是包含元数据的属性，比如入站属性，可以在流程期间设置。它们可以由 Mule 自动设置，也可以由用户手动设置。本质上，出站属性是可变的。

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

当消息通过 flow-ref 而不是连接器转到新流程时，出站属性仍保持出站属性。

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

它可以定义为关于消息的用户自定义元数据。基本上，变量是有关于由正在处理该消息的应用程序使用的消息的暂时信息片段。它不应该与消息一起传递到其目的地。它们有以下三种类型 −

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

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

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

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