Mule是什么？（What is Mule?）
Mule 框架是高度可扩展的，允许你以很小的规模开始，随着时间的推移，连接更多的应用系统。 Mule管理应用系统和组件之间的交互，不管它们是否在同一个VM(Visual Machine-虚拟机，即JVM-Java虚拟机)或在Internet上，不管底层使用的传输协议。
Mule相比同类框架而言，提供很多优势，包含：Mule ESB是基于Java的轻量级消息框架，它允许你简单 快速的连接应用系统，使得他们（应用系统）可以交换数据。Mule使用SOA(Service-Oriented Architecture-面向服务架构)，使得简单集成已存应用系统成为可能。不管应用系统使用的是哪些不同的技术，包括：JMS Web Services JDBC HTTP 等，Mule可以无缝的在他们之间进行处理交互动作。
Mule基于Enterprise Service Bus(ESB)架构思想。ESB的主要特性是通过扮演一个中转系统的角色，允许不同的应用系统交互，中转系统在内网或Internet上的应用系统间搬运数据。 目前市场上有一些商业的ESB实现。尽管如此，大部分提供有限的功能，或在已存应用服务器／消息服务器之上构建，将你锁定在特定的供应商（将你固定的ESB厂商）。Mule是供应商中立的，因此不同厂商的实现可以插入进来。当你使用Mule时，永远不会锁定的特定的供应商。
Mule相比同类框架而言，提供很多优势，包含：
• Mule 组件可以是任何你想要的类型。你可以简单的集成任何东西, 从POJO到其他框架的组件。
• Mule 和 ESB 模型使得重大的组件重用。不象其他的框架，Mule允许你在不做任何变化的情况下使用已存组件。组件不强制要求有Mule特性的代码，就可以在Mule中运行，没有程序式的API强制要求。业务逻辑和消息逻辑完全分离。
• 消息（Messages）可以是任何格式，从SOAP到二进制图片文件（binary image files）。Mule没有强制任何架构上的设计约束，例如XML消息或 WSDL服务约束。
• 可以一些拓扑结构上部署Mule，不仅仅是ESB。因为它是轻量级 和 嵌入式的，Mule能降低上线时间，提高生产力，为工程提供安全 可伸缩的应用系统，它适应变化，在需要时提高或降低系统规模。
MuleSoft也提供管理工具，允许你管理你的部署(Mule HQ)，并控制你得基础结构(Mule Galaxy)。
理解消息框架
将你的应用系统联网的优势是一个应用系统可以向另一个应用系统发送数据。然而，很多应用系统没有读取和处理从其他系统发送过来的数据的能力。 Mule ESB通过提供一个消息框架读取、转换、并以消息的形式在应用间发送数据。消息仅仅就是一个数据包，它在应用间的一个特定的通道（渠道）上可以被处理和发送。
在最简单的情况， 当你的系统连接到Mule时， Mule从一个源系统读取数据，需要时Mule转换数据到目标系统可以读取的格式上, 然后发送数据到目标系统。这允许你几成所有类型的应用系统，甚至那些没有内置集成的。
Mule是一个基于企业服务总线(Enterprise Service Bus(ESB))思想的消息框架。ESB的关键优势是通过扮演一个在内网或公网应用系统间搬运数据的传输系统，使得不同的应用系统可以交互。Mule的核心是消息总线(Message Bus), 它在应用系统间路由消息。
Mule和传统ESB的不同点之一在于Mule只在需要时才转换数据。典型的ESB, 你必须为每个你连接到总线(Bus)上的应用系统创建一个适配器(Adapter), 适配器转换应用的数据到一个公共的消息格式上。这些Adapter的开发和处理每个消息所需的时间，需要干的时间和努力。
Mule剔除了单个消息格式的需要。信息被发送到任何沟通通道(如：HTTP或JMS), 并只在通道上需要时才进行转换。因此，Mule相比于传统ESB, 提高性能并减少开发时间。
Mule架构和术语使用Gregor Hohpe和Bobby Woolf写的< Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions >一书中的描述原理。这本书对于任何工作中涉及到企业消息解决方案的人，强烈建议阅读<译者注：随后会进行本书的翻译工作>。
理解Mule 架构
这一部分描述Mule ESB架构的不同部分，以及它如何处理消息和消息的数据。 以下图解，使用一个公司的例子，要为客户订单生成发货单，在这些发货单上有一些操作，然后为了完成订单，发送它们到发货部门。
这一部分包含如下主题:
• 关于 SOA
• 处理数据
• 服务组件间路由消息
• 从消息中分离业务逻辑
• 将全部融合到一起
关于 SOA
Mule ESB 是基于Service-Oriented Architecture(SOA)概念的。使用SOA方法开发，允许IT组织将应用功能组件或服务融合在一起来开发应用系统。服务是不连续的功能集合，彼此完全分离，并能在同一对象上协同工作。例如：如果你需要处理发货单，你可能有一个服务，它将数据库的客户数据合并到发货单中，另外一个服务检查存货数据库，看看发货单中的项目是否有存货。
因为每个服务是独立的，服务可以被用来构建多个处理的处理块，而不需要重新创建每种类型的处理或消息。例如：合并客户数据到发货单的服务也能用来合并客户数据到报表、信件或其他的文档。 这个模块化的方法允许你一次创建功能，重用多次，流水线式的开发。
使用SOA, 企业可以实现开发成本大大节省，在开发新的应用系统时，可以通过重用和重新配置现有服务，快速的适应业务条件的变化。
SOA还可以更好的整合企业IT资源，包括先前孤立的应用系统和遗留系统。 Mule全面支持SOA方式，并使服务间协调的协作, 让你很容易就将应用系统捆绑在一起。
处理数据
当消息从应用系统被发送时，Mule ESB获取到消息，发送到使用特定业务逻辑处理它的服务中, 接着将它路由到正确的应用系统。 Mule包含很多独立的部分，它们处理数据并路由消息。 服务的关键部分是服务组件(service component)。Service Component 在消息上执行业务逻辑，例如读取发货单对象，从客户数据库中添加信息到发货单对象，然后将它转交给订单完成应用系统。
Service Component 的重要特性是它不需要有任何Mule特性(如：Mule的某一个接口)的代码; 它可以简单到是一个POJO, Spring Bean, Java Bean 或以特定方式处理数据的业务逻辑。Mule管理Service Component，将它和配置设置捆绑并暴露为服务，并确保传入正确的信息，从Service Component传出的消息基于你在Mule配置文件中的特定配置。
你可以有很多执行不同业务逻辑的不同Service Component, 例如：一个验证发货单中的项目是否有库存，另一个更新不同的客户数据库中的订单历史。 发货单， 被封装在消息中，可以从一个Service Component流向下一个，知道所有必要的处理完成。
服务组件间路由消息
如前所述，Service Component包含在消息上处理数据的业务逻辑， 它不包含任何关于接受或发送消息的信息。
为了确保该Service Component接收正确的消息，并在处理后妥善路由消息，当你配置Mule ESB的Service Component时可以指定入站路由器(inbound router)和出站路由器(outbound router)。
Inbound Router指定这个Service Component将要处理的消息。然后可以过滤进来的消息并聚集它们，然后在路由消息到Service Component之前将他们重新排序。例如，Service Component，如果一个Service Component支持RSS feed, Inbound Router可能过滤那些从那个feed中发来的消息。
Service Component处理完消息之后，Outbound Router指定将消息发送到哪里。例如：它可能路由正式地址的发货单到一个发货部门，路由所有其他的发货单到另一个发货部门。你能定义多个Inbound和Outbound路由器，甚至连接在一起，使Service Component接受和发送消息的要求完全一样。
从消息中分离业务逻辑
Mule ESB 众多优势中的一个就是它能处理多种协议发送来的消息。 例如：发货单可能总是XML的格式，但是他可能通过HTTP发送，或者作为一个JMS消息，这依赖于制作发货单的应用系统。 如果Service Component仅处理业务逻辑和数据，而不是信息本身，它如何知道怎样读取接收到的各种格式的消息？
答案是Service Component不知道如何阅读消息，因为通常消息格式对于Service Component是完全屏蔽的。 取而代之的是，一个Transport携带消息一起，然后在路由器将消息传递到Service Component之前， Transformers以Service Component可以读取的格式改变消息的负载(Payload, 例如发货单)。
例如：如果XML发货单通过HTTP发送过来， HTTP Transport携带消息一起，直接路将此消息路由到需要处理它的每一个Service Component，然后Transformers在前进的道路上对于每一个Service Component必要的改变发货单（如：从XML转换到Java对象）。
Transformers是交换数据的关键， 因为它允许Mule转换数据到另外一个组件或应用程序可以理解的格式上。最重要的是， 数据只在必要时做转换。代替将每个消息转换到一个公共的消息格式上的是：消息和他们的数据只在该消息的目标组件或应用程序需要时做转换。
最后你可以使用多种类型的Transports来处理不同的通道（Channels）, 如：在HTTP上发送消息(Mule在HTTP上接收到消息)，经过Customer Data service component的处理，将它作为一个JMS消息转发。
将业务逻辑与发送和消息转换的分离，就带来更大的灵活性，你如何设置你的架构，并使其更加简单来定制业务逻辑，而不必担心可能到来的各种消息格式。
如果需要，你的Service Component可以使用消息的原始数据，但不是必须的。
将全部融合到一起
Endpoints是将所有的服务融合到一起的关键配置元素。你在Inbound和Outbound Router上指定Endpoints, 来告诉Mule ESB, 使用哪一个Transport，发送消息到哪里，哪些消息是Service Component应该接受。 Endpoint的主要部分是地址，表示为一个URI(统一资源标识符, Uniform Resource Indicator (URI)), 它表示要使用的Transport， 位置(一个Transport特性的资源)，以及其他额外的参数。
例如： 如果服务的Inbound Router指定Endpoint [http://myfirm.com/mule], HTTP Transport会将发送到那个URL的所有消息转发到Service中。如果Inbound Router指定为file://myserver/files/, File Transport将会观察那个目录，转发任何在那个目录中创建的新文件到Service中。你在Outbound Router中指定的Endpoint标识消息要走的下一步 - 消息会到达有着和前一个Service的Outbound Endpoint相同的Inbound Endpoint的Service, 像如下图解所示。
Service可以使用不同的Transports接收消息。对于每种Service将用到的Transport，你必须指定一个或多个分离的Endpoint。例如：如果你想要你的一个Service能够处理从HTTP和JMS通道过来的消息，你需要在这个Service的Inbound Router上指定至少一个HTTP Endpoint和至少一个JSM Endpoint。
Mule在这个Service上注册这些Endpoints, Transport运行时使用这些注册信息来配置自身并决定发送和接收消息的位置。Router或Endpoint能包含过滤器(Filters), 这进一步指定发送和接受哪些消息。例如：你可以指定Service Component只接受来自于特定作者的RSS消息。
为你的Services指定Routers和Endpoints，需要简单编辑一个XML文件。你不需要编写任何Java代码。 如前所述，你的Service Components代码仍然与消息和路由完全分离，你只需要处理Mule配置。
总而言之，Mule提供了一个简单、轻量级的方式来编写处理数据的Service Components, 他们不需要担心数据的发送和接收、数据格式、以及发送或接收数据中使用到的技术。
然而，很多供应商和集成技术提供连接到不同的数据源的能力，但通常都要求额外的编码信息以达到想要的获取消息和分发数据的效果。Mule允许你快速开发Service Components，通过简单的XML配置而不是编写Java代码。
原文地址：
[urlhttp://www.mulesoft.org/documentation/display/MULE3INTRO/Understanding+the+Messaging+Framework[/url]
[urlhttp://www.mulesoft.org/documentation/display/MULE3INTRO/Understanding+the+Mule+Architecture[/url]
本文PDF版本下载：
Mule 框架是高度可扩展的，允许你以很小的规模开始，随着时间的推移，连接更多的应用系统。 Mule管理应用系统和组件之间的交互，不管它们是否在同一个VM(Visual Machine-虚拟机，即JVM-Java虚拟机)或在Internet上，不管底层使用的传输协议。
Mule相比同类框架而言，提供很多优势，包含：Mule ESB是基于Java的轻量级消息框架，它允许你简单 快速的连接应用系统，使得他们（应用系统）可以交换数据。Mule使用SOA(Service-Oriented Architecture-面向服务架构)，使得简单集成已存应用系统成为可能。不管应用系统使用的是哪些不同的技术，包括：JMS Web Services JDBC HTTP 等，Mule可以无缝的在他们之间进行处理交互动作。
Mule基于Enterprise Service Bus(ESB)架构思想。ESB的主要特性是通过扮演一个中转系统的角色，允许不同的应用系统交互，中转系统在内网或Internet上的应用系统间搬运数据。 目前市场上有一些商业的ESB实现。尽管如此，大部分提供有限的功能，或在已存应用服务器／消息服务器之上构建，将你锁定在特定的供应商（将你固定的ESB厂商）。Mule是供应商中立的，因此不同厂商的实现可以插入进来。当你使用Mule时，永远不会锁定的特定的供应商。
Mule相比同类框架而言，提供很多优势，包含：
• Mule 组件可以是任何你想要的类型。你可以简单的集成任何东西, 从POJO到其他框架的组件。
• Mule 和 ESB 模型使得重大的组件重用。不象其他的框架，Mule允许你在不做任何变化的情况下使用已存组件。组件不强制要求有Mule特性的代码，就可以在Mule中运行，没有程序式的API强制要求。业务逻辑和消息逻辑完全分离。
• 消息（Messages）可以是任何格式，从SOAP到二进制图片文件（binary image files）。Mule没有强制任何架构上的设计约束，例如XML消息或 WSDL服务约束。
• 可以一些拓扑结构上部署Mule，不仅仅是ESB。因为它是轻量级 和 嵌入式的，Mule能降低上线时间，提高生产力，为工程提供安全 可伸缩的应用系统，它适应变化，在需要时提高或降低系统规模。
MuleSoft也提供管理工具，允许你管理你的部署(Mule HQ)，并控制你得基础结构(Mule Galaxy)。
理解消息框架
将你的应用系统联网的优势是一个应用系统可以向另一个应用系统发送数据。然而，很多应用系统没有读取和处理从其他系统发送过来的数据的能力。 Mule ESB通过提供一个消息框架读取、转换、并以消息的形式在应用间发送数据。消息仅仅就是一个数据包，它在应用间的一个特定的通道（渠道）上可以被处理和发送。
在最简单的情况， 当你的系统连接到Mule时， Mule从一个源系统读取数据，需要时Mule转换数据到目标系统可以读取的格式上, 然后发送数据到目标系统。这允许你几成所有类型的应用系统，甚至那些没有内置集成的。
Mule是一个基于企业服务总线(Enterprise Service Bus(ESB))思想的消息框架。ESB的关键优势是通过扮演一个在内网或公网应用系统间搬运数据的传输系统，使得不同的应用系统可以交互。Mule的核心是消息总线(Message Bus), 它在应用系统间路由消息。
Mule和传统ESB的不同点之一在于Mule只在需要时才转换数据。典型的ESB, 你必须为每个你连接到总线(Bus)上的应用系统创建一个适配器(Adapter), 适配器转换应用的数据到一个公共的消息格式上。这些Adapter的开发和处理每个消息所需的时间，需要干的时间和努力。
Mule剔除了单个消息格式的需要。信息被发送到任何沟通通道(如：HTTP或JMS), 并只在通道上需要时才进行转换。因此，Mule相比于传统ESB, 提高性能并减少开发时间。
Mule架构和术语使用Gregor Hohpe和Bobby Woolf写的< Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions >一书中的描述原理。这本书对于任何工作中涉及到企业消息解决方案的人，强烈建议阅读<译者注：随后会进行本书的翻译工作>。
理解Mule 架构
这一部分描述Mule ESB架构的不同部分，以及它如何处理消息和消息的数据。 以下图解，使用一个公司的例子，要为客户订单生成发货单，在这些发货单上有一些操作，然后为了完成订单，发送它们到发货部门。
这一部分包含如下主题:
• 关于 SOA
• 处理数据
• 服务组件间路由消息
• 从消息中分离业务逻辑
• 将全部融合到一起
关于 SOA
Mule ESB 是基于Service-Oriented Architecture(SOA)概念的。使用SOA方法开发，允许IT组织将应用功能组件或服务融合在一起来开发应用系统。服务是不连续的功能集合，彼此完全分离，并能在同一对象上协同工作。例如：如果你需要处理发货单，你可能有一个服务，它将数据库的客户数据合并到发货单中，另外一个服务检查存货数据库，看看发货单中的项目是否有存货。
因为每个服务是独立的，服务可以被用来构建多个处理的处理块，而不需要重新创建每种类型的处理或消息。例如：合并客户数据到发货单的服务也能用来合并客户数据到报表、信件或其他的文档。 这个模块化的方法允许你一次创建功能，重用多次，流水线式的开发。
使用SOA, 企业可以实现开发成本大大节省，在开发新的应用系统时，可以通过重用和重新配置现有服务，快速的适应业务条件的变化。
SOA还可以更好的整合企业IT资源，包括先前孤立的应用系统和遗留系统。 Mule全面支持SOA方式，并使服务间协调的协作, 让你很容易就将应用系统捆绑在一起。
处理数据
当消息从应用系统被发送时，Mule ESB获取到消息，发送到使用特定业务逻辑处理它的服务中, 接着将它路由到正确的应用系统。 Mule包含很多独立的部分，它们处理数据并路由消息。 服务的关键部分是服务组件(service component)。Service Component 在消息上执行业务逻辑，例如读取发货单对象，从客户数据库中添加信息到发货单对象，然后将它转交给订单完成应用系统。
Service Component 的重要特性是它不需要有任何Mule特性(如：Mule的某一个接口)的代码; 它可以简单到是一个POJO, Spring Bean, Java Bean 或以特定方式处理数据的业务逻辑。Mule管理Service Component，将它和配置设置捆绑并暴露为服务，并确保传入正确的信息，从Service Component传出的消息基于你在Mule配置文件中的特定配置。
你可以有很多执行不同业务逻辑的不同Service Component, 例如：一个验证发货单中的项目是否有库存，另一个更新不同的客户数据库中的订单历史。 发货单， 被封装在消息中，可以从一个Service Component流向下一个，知道所有必要的处理完成。
服务组件间路由消息
如前所述，Service Component包含在消息上处理数据的业务逻辑， 它不包含任何关于接受或发送消息的信息。
为了确保该Service Component接收正确的消息，并在处理后妥善路由消息，当你配置Mule ESB的Service Component时可以指定入站路由器(inbound router)和出站路由器(outbound router)。
Inbound Router指定这个Service Component将要处理的消息。然后可以过滤进来的消息并聚集它们，然后在路由消息到Service Component之前将他们重新排序。例如，Service Component，如果一个Service Component支持RSS feed, Inbound Router可能过滤那些从那个feed中发来的消息。
Service Component处理完消息之后，Outbound Router指定将消息发送到哪里。例如：它可能路由正式地址的发货单到一个发货部门，路由所有其他的发货单到另一个发货部门。你能定义多个Inbound和Outbound路由器，甚至连接在一起，使Service Component接受和发送消息的要求完全一样。
从消息中分离业务逻辑
Mule ESB 众多优势中的一个就是它能处理多种协议发送来的消息。 例如：发货单可能总是XML的格式，但是他可能通过HTTP发送，或者作为一个JMS消息，这依赖于制作发货单的应用系统。 如果Service Component仅处理业务逻辑和数据，而不是信息本身，它如何知道怎样读取接收到的各种格式的消息？
答案是Service Component不知道如何阅读消息，因为通常消息格式对于Service Component是完全屏蔽的。 取而代之的是，一个Transport携带消息一起，然后在路由器将消息传递到Service Component之前， Transformers以Service Component可以读取的格式改变消息的负载(Payload, 例如发货单)。
例如：如果XML发货单通过HTTP发送过来， HTTP Transport携带消息一起，直接路将此消息路由到需要处理它的每一个Service Component，然后Transformers在前进的道路上对于每一个Service Component必要的改变发货单（如：从XML转换到Java对象）。
Transformers是交换数据的关键， 因为它允许Mule转换数据到另外一个组件或应用程序可以理解的格式上。最重要的是， 数据只在必要时做转换。代替将每个消息转换到一个公共的消息格式上的是：消息和他们的数据只在该消息的目标组件或应用程序需要时做转换。
最后你可以使用多种类型的Transports来处理不同的通道（Channels）, 如：在HTTP上发送消息(Mule在HTTP上接收到消息)，经过Customer Data service component的处理，将它作为一个JMS消息转发。
将业务逻辑与发送和消息转换的分离，就带来更大的灵活性，你如何设置你的架构，并使其更加简单来定制业务逻辑，而不必担心可能到来的各种消息格式。
如果需要，你的Service Component可以使用消息的原始数据，但不是必须的。
将全部融合到一起
Endpoints是将所有的服务融合到一起的关键配置元素。你在Inbound和Outbound Router上指定Endpoints, 来告诉Mule ESB, 使用哪一个Transport，发送消息到哪里，哪些消息是Service Component应该接受。 Endpoint的主要部分是地址，表示为一个URI(统一资源标识符, Uniform Resource Indicator (URI)), 它表示要使用的Transport， 位置(一个Transport特性的资源)，以及其他额外的参数。
例如： 如果服务的Inbound Router指定Endpoint [http://myfirm.com/mule], HTTP Transport会将发送到那个URL的所有消息转发到Service中。如果Inbound Router指定为file://myserver/files/, File Transport将会观察那个目录，转发任何在那个目录中创建的新文件到Service中。你在Outbound Router中指定的Endpoint标识消息要走的下一步 - 消息会到达有着和前一个Service的Outbound Endpoint相同的Inbound Endpoint的Service, 像如下图解所示。
Service可以使用不同的Transports接收消息。对于每种Service将用到的Transport，你必须指定一个或多个分离的Endpoint。例如：如果你想要你的一个Service能够处理从HTTP和JMS通道过来的消息，你需要在这个Service的Inbound Router上指定至少一个HTTP Endpoint和至少一个JSM Endpoint。
Mule在这个Service上注册这些Endpoints, Transport运行时使用这些注册信息来配置自身并决定发送和接收消息的位置。Router或Endpoint能包含过滤器(Filters), 这进一步指定发送和接受哪些消息。例如：你可以指定Service Component只接受来自于特定作者的RSS消息。
为你的Services指定Routers和Endpoints，需要简单编辑一个XML文件。你不需要编写任何Java代码。 如前所述，你的Service Components代码仍然与消息和路由完全分离，你只需要处理Mule配置。
总而言之，Mule提供了一个简单、轻量级的方式来编写处理数据的Service Components, 他们不需要担心数据的发送和接收、数据格式、以及发送或接收数据中使用到的技术。
然而，很多供应商和集成技术提供连接到不同的数据源的能力，但通常都要求额外的编码信息以达到想要的获取消息和分发数据的效果。Mule允许你快速开发Service Components，通过简单的XML配置而不是编写Java代码。
原文地址：
[urlhttp://www.mulesoft.org/documentation/display/MULE3INTRO/Understanding+the+Messaging+Framework[/url]
[urlhttp://www.mulesoft.org/documentation/display/MULE3INTRO/Understanding+the+Mule+Architecture[/url]
本文PDF版本下载：
