Mule 介绍及架构理解Getting Started
作者：Jacky.Yang
MSN:
目录
Mule是什么？（What is Mule?） (2)
理解消息框架 (3)
理解Mule 架构 (4)
关于SOA (4)
处理数据 (4)
服务组件间路由消息 (5)
从消息中分离业务逻辑 (6)
将全部融合到一起 (7)
参考1： (8)
可以和Mule一起使用的技术 (9)
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基于Enterpri 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是一个基于企业服务总线(Enterpri Service Bus(ESB))思想的消息框架。ESB的关键优势是通过扮演一个在内网或公网应用系统间搬运数据的传输系统，使得不同的应用系统可以交互。Mule的核心是消息总线(Message Bus), 它在应用系统间路由消息。
Mule和传统ESB的不同点之一在于Mule只在需要时才转换数据。典型的ESB, 你必须为每个你连接到总线(Bus)上的应用系统创建一个适配器(Adapter), 适配器转换应用的数据到一个公共的消息格式上。这些Adapter的开发和处理每个消息所需的时间，需要干的时间和努力。
Mule剔除了单个消息格式的需要。信息被发送到任何沟通通道(如：HTTP或JMS), 并只在通道上需要时才进行转换。因此，Mule相比于传统ESB, 提高性能并减少开发时间。
Mule架构和术语使用Gregor Hohpe和Bobby Woolf写的< Enterpri 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包含很多独立的部分，它们处理数据并路由消息。服务的关键部分
是服务组件(rvice 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接受和发送消息的要求完全一样。
