Mulesoft 简明教程
MuleSoft - The Mule Project
Mule项目的动机如下−
The motivations behind the Mule project were −
-
to make things simpler for the programmers,
-
the need of lightweight and modular solution that could scale from an application-level messaging framework to an enterprise-wide highly distributable framework.
Mule ESB的设计基于事件驱动和以编程为基础的框架。它基于事件驱动，因为它结合了消息的统一表示方式，并且可以通过可插入模块进行扩展。它以编程为基础，因为程序员可以轻松地植入一些附加行为，例如特定消息处理或自定义数据转换。
Mule ESB is designed as an event-driven as well as programmatic framework. It is event-driven because it is combined with unified representation of messages and can be expandable with pluggable modules. It is programmatic because programmers can easily implant some additional behaviors such as specific message processing or custom data transformation.
History
Mule项目的背景如下−
The historical perspective of Mule project is as follows −
SourceForge project
Mule项目始于2003年4月的SourceForge项目，两年后其第一版发布并转移到CodeHaus。通用消息对象（UMO）API是其架构的核心。UMO API背后的理念是统一逻辑，同时使它们与底层传输保持隔离。
The Mule project was started as the SourceForge project in April 2003, and after 2 years its first version was released and moved to CodeHaus. Universal Message Object (UMO) API was at the core of its architecture. The idea behind UMO API was to unify the logic while keeping them isolated from the underlying transports.
Version 1.0
它于2005年4月发布，其中包含许多传输。随后许多其他版本的主要重点是调试和添加新功能。
It was released in April 2005 containing numerous transports. The key focus of many other versions followed by it, was on debugging and adding new features.
Version 2.0 (Adoption of Spring 2)
Spring 2作为配置和连接框架被采纳到Mule 2中，但它被证明是一次重大的检修，因为缺少对必需的XML配置的表达力。当基于XML架构的配置被引入Spring 2时，此问题得到解决。
Spring 2 as configuration and wiring framework was adopted in Mule 2 but it proved to be a major over-haul because of the lack of expressiveness of the required XML configuration. This issue was resolved when XML Schema-based configuration has been introduced in Spring 2.
Competitors of Mule ESB
以下是Mule ESB的主要竞争对手−
Following are some of the major competitors of 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’s Core Concept
如上所述，Mule ESB是一个基于Java的轻量级且高度可扩展的企业服务总线（ESB）和集成平台。无论应用程序使用何种技术，Mule ESB都能轻松集成应用程序，使其能够交换数据。在本节中，我们将讨论Mule的核心概念，以实现这种集成。
As discussed, Mule ESB is a lightweight and highly scalable Java-based enterprise service bus (ESB) and integration platform. Regardless of various technologies used by applications, Mule ESB enables easy integration of applications, enabling them to exchange data. In this section, we will discuss about Mule’s core concept coming into play to make such integration happen.
为此，我们需要了解其架构及构建块。
For this, we need to understand its architecture as well as building blocks.
Architecture
Mule ESB的架构具有三层，即传输层、集成层和应用程序层，如下图所示−
The architecture of Mule ESB has three layers namely, Transport layer, Integration layer and Application layer as shown in the following diagram −
通常，可以执行以下三类任务来配置和定制Mule部署−
Generally, there are following three types of tasks that can be performed to configure and customize Mule deployment −
Service Component Development
此项任务涉及开发或重复使用现有的POJO或Spring Bean。POJO是一个带有属性的类，该属性生成get和set方法、云连接器。另一方面，Spring Bean包含用于丰富消息的业务逻辑。
This task involves development or re-using the existing POJOs, or Spring Beans. POJOs is a class with attributes that generates the get and set methods, cloud connectors. On the other hand, Spring Beans contains the business logic to enrich messages.
Service Orchestration
此项任务基本提供了涉及配置消息处理器、路由器、转换器和过滤器的服务中介。
This task basically provides the service mediation that involves configuring the message processor, routers, transformers and filters.
Integration
Mule ESB的最重要任务是集成各种应用程序，无论它们使用的协议如何。为此，Mule提供了传输方法，允许在各种协议连接器上接收和分发消息。Mule支持许多现有的传输方法，或者我们还可以使用自定义传输方法。
The most important task of Mule ESB is the integration of various applications regardless of the protocols they are using. For this purpose, Mule provides transport methods that allow receiving and dispatching the messages on various protocol connectors. Mule supports many existing transport methods, or we may also use a custom transport method.
Building Blocks
Mule配置具有以下构建块−
Mule configuration has the following building blocks −
Spring beans
Spring bean 的主要用途是构建服务组件。构建 Spring 服务组件后，如果用户没有配置文件，可以通过配置文件或手动定义服务组件。
The main use of Spring beans is to construct service component. After constructing spring service component, we can define it through a configuration file or manually, in case you do not have configuration file.
Agents
它最初是 Anypoint Studio 中在 Mule Studio 之前创建的服务。一旦服务器启动，将会创建一个代理，一旦服务器停止，将会销毁该代理。
It is basically a service created in Anypoint Studio before Mule Studio. An agent is created once you start a server and will be destroyed once you stop the server.
Connector
它是一个软件组件，配置为特定于协议的参数。它主要用于控制协议的使用。例如，JMS 连接器配置有 Connection ，该连接器共享在负责实际通信的不同实体之间。
It is a software component configured with the parameters that are specific to protocols. It is mainly used for controlling the usage of a protocol. For example, a JMS connector is configured with a Connection and this connector will be shared among various entities in charge of actual communication.
Global Configuration
顾名思义，这个构建块用于设置全局属性和设置。
As the name implies, this building block is used to set the global properties and settings.
Global Endpoints
它可以在“全局元素”选项卡中使用，该选项卡可以在流程中多次使用：
It can be used in Global Elements tab which can be used as many times in a flow −
Global Message Processor
顾名思义，它观察或修改消息或消息流。转换器和过滤器是全局消息处理程序的示例。
As the name implies, it observes or modifies a message or message flow. Transformers and filters are the examples of Global Message Processor.
Transformers - 转换器的主要工作是将数据从一种格式转换成另一种格式。可以在全局中定义，并可以在多个流程中使用。
Transformers − The main job of a transformer is to convert data from one format to another. It can be defined globally and can be used in multiple flows.
Filters - 它是一个过滤器，将决定应该处理哪条 Mule 消息。过滤器基本上指定消息必须满足的条件，然后才能处理并路由到服务。
Filters − It is the filter that will decide which Mule message should be processed. Filter basically specifies the conditions that must be met for a message to be processed and routed to a service.
Models
与代理相反，它是工作室中创建的服务的逻辑分组。我们有权启动和停止特定模型中的所有服务。
In contrast to Agents, it is a logical grouping of services which are created in studio. We have the liberty to start and stop all the services inside a specific model.
Services - 服务是封装业务逻辑或组件的服务。它还专门为该服务配置了路由器、端点、转换器和过滤器。
Services − Services are the one that wrap our business logic or components. It also configures Routers, Endpoints, transformers and filters specifically for that service.
Endpoints - 可以将其定义为一个对象，服务将在其上入站（接收）和出站（发送）消息。服务通过端点连接。
Endpoints − It may be defined as an object on which services will inbound (receive) and outbound (send) messages. Services are connected through endpoints.
Mule Message Structure
Mule 消息完全包装在 Mule 消息对象中，是通过 Mule 流程传递到应用程序中的数据。Mule 消息的结构在以下图表中显示：
A Mule message, totally wrapped under Mule Message Object, is the data that passes through applications via Mule flows. The structure Mule’s message is shown in the following diagram −
正如上述图表中所示，Mule 消息包含两个主要部分：
As seen in the above diagram, Mule Message consists of two main parts −
Header
它只不过是消息的元数据，由以下两个属性进一步表示：
It is nothing but the metadata of the message which is further represented by the following two properties −
Inbound Properties - 这些属性由消息源自动设置。它们不能由用户操作或设置。本质上，入站属性是不可变的。
Inbound Properties − These are the properties which are automatically set by the message source. They cannot be manipulated or set by the user. In nature, inbound properties are immutable.
Outbound Properties - 这些属性是包含元数据的属性，比如入站属性，可以在流程期间设置。它们可以由 Mule 自动设置，也可以由用户手动设置。本质上，出站属性是可变的。
Outbound Properties − These are the properties that contain metadata like an inbound property and can set during the course of flow. They can be set automatically by Mule or manually by a user. In nature, outbound properties are mutable.
当消息通过一个流程的出站端点通过传输转到另一个流程的入站端点时，出站属性将变为入站属性。
Outbound properties become inbound properties when the message passes from the outbound endpoint of one flow to the inbound endpoint of a different flow via a transport.
当消息通过 flow-ref 而不是连接器转到新流程时，出站属性仍保持出站属性。
Outbound properties remain outbound properties when the message is passed to a new flow via a flow-ref rather than a connector.
Payload
消息对象承载的实际业务消息称为有效负载。
The actual business message carried by message object is called payload.
Variables
它可以定义为关于消息的用户自定义元数据。基本上，变量是有关于由正在处理该消息的应用程序使用的消息的暂时信息片段。它不应该与消息一起传递到其目的地。它们有以下三种类型 −
It may be defined as the user-defined metadata about a message. Basically, variables are temporary pieces of information about a message used by the application that is processing it. It is not meant to be passed along with the messages to its destination. They are of three types as given below −
Flow variables − 这些变量仅适用于它们存在的流。
Flow variables − These variables apply only to the flow in which they exist.
Session variables − 这些变量适用于同一应用程序中的所有流。
Session variables − These variables apply across all the flows within the same application.
Record variables − 这些变量仅适用于作为一个批处理的一部分处理的记录。
Record variables − These variables apply only to records processed as part of a batch.