What is Mule?

(相关资料图)

Mule有两个版本，社区版和企业版。 社区版是免费，企业版是收费的，企业版相比于社区版功能丰富许多，它们的比较如下：

1、相比同类框架而言，提供很多优势，包含：

Mule近期推出了Mule3，Mule3的新增特点-云连接（Cloud Connect） 提供了可以用简单安全的方式为企业提供基于云技术的数据和服务。它的核心是IBeans，一个轻量级、可重用的接口，用于Web技术的连接扩展和数据服务。

Mule云包括以下内容 1、 Integration Beans （合成bean）：他们是可重用的云接口，可以注入到组件中，可以接受外部的服务，比如说亚马逊、推特、Facebook等，并且是一种简单的接收服务、管理安全机制的方法。请求验证、数据传输、错误挂起等也可以通过这种方法来实现。 2、 Rest / JAX-RS：（REST协议：即REST(Representational State Transfer表述性状态转移)是一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。） 现在Jersey 已经是Mule核心部署的一部分，提供本地化的对REST和JAX-RS的支持，例如Apache CXF。Jersey现在已经在易配置和高可扩展性方面做的非常优秀。Jersey现在使用一种包含很多Jersey资源的接口实现组件来替代终端类型的实现方式。 3、 AJAX：Mule现在直接融合了Javascript应用。Mule3包括了服务终端和Javascript客户端允许事件被直接发布到浏览器，并且事件可以从浏览器进行发布。 4、 Web Service：现在对Web Service的发布的配置将更加容易，其扩展性也进一步加强。 5、 ATOM and RSS：Mule 3 现在能够较好的支持ATOM了。 6、 JSON Support：Mule3包含对JSON数据绑定和JSON传输的支持。 7、 JAXB Support：支持组件XML绑定将自动进行，并且也添加了新的JAXB传输。 其他的一些支持： 1、FLOW：配置的流程化。 2、Patterns：配置的模式化，可以极大简化配置，将不同情况的配置进行模式化划分。 3、Annotation：改进后新的注释方法对组件中的注入反转、transformers的发布、组件方法的Pol有很大作用。 4、Deployment：支持单一服务和组服务的热部署。同时支持部署模型定义。 结构上的提高： 5、Message Processor API：消息处理API，Mule3其内部处理方式较为灵活，能够在将来其他模式调整时适应外部服务组件。 6、Message Exchange Patterns：消息交换模式，消息在Mule3中的流转将更加精确和灵活。 7、Message Property Scoping：消息属性作用域。较好的实现了属性的作用范围。 8、Lifecycle Improvements：生命周期的改进。优化了Mule的开启和关闭行为，热部署也在这方面得以展现，并支持JSR-250 生命周期注释方法。 9、Exception Handing：异常处理，异常处理的兼容性更好，并且有错误行为预处理功能。 10、Automatic Transformation：自动转换，Mule3增强了自动转换引擎，用于进行数据绑定，例如XML/JAX、JSON，并支持自定义。 11、CXF Now a Module：CXF现在在Mule3中作为一个模块，在Mule3中对CXF进行了优化，使得CXF的用户与普通的管道/过滤器元素一样。 12、REST：Mule的开发团队十分看好REST，在其文档中使用了“enjoy”这个单词来形容REST，可见使用REST协议开发Mule3服务应该是比较合适的。 Mule3其他的一些变化： 1、Message factories：消息工厂，从底层将消息翻译成MuleMessage格式。所有MuleMessage都是由消息工厂创建的。 2、XQuery Support：对XQuery支持。 3、Dynamic Endpoints：动态终端，Mule中的终端可以动态构造，通过Mule传输的消息可以构造终端地址。 4、JBoss jBPM：文档中说明Mule从很早以前就开始与JBoss jBPM进行整合了，但是在Mule3中，对其进行了改善，并将JBoss jBPM版本升级到了4.4版本。 5、Transaction Enhancements：Transaction被增强，通过配置元素属性，Mule可获知在Mule外部Transaction已经开始了。 6、AXIS Code Removed from Mule：AXIS代码在Mule3中被移除，其将作为一个独立模块存在。

• Mule 组件可以是任何你想要的类型。你可以简单的集成任何东西, 从POJO到其他框架的组件。• Mule 和 ESB 模型使得重大的组件重用。不象其他的框架，Mule允许你在不做任何变化的情况下使用已存组件。组件不强制要求有Mule特性的代码，就可以在Mule中运行，没有程序式的API强制要求。业务逻辑和消息逻辑完全分离。• 消息（Messages）可以是任何格式，从SOAP到二进制图片文件（binary image files）。Mule没有强制任何架构上的设计约束，例如XML消息或 WSDL服务约束。• 可以一些拓扑结构上部署Mule，不仅仅是ESB。因为它是轻量级 和 嵌入式的，Mule能降低上线时间，提高生产力，为工程提供安全 可伸缩的应用系统，它适应变化，在需要时提高或降低系统规模。

Mule ESB是基于Java的轻量级消息框架——允许你简单 快速的连接应用系统，使得他们（应用系统）可以交换数据。Mule使用SOA(Service-Oriented Architecture-面向服务架构)——使得简单集成已存应用系统成为可能。

特性

功能强大，易于使用(Easy to learn, powerful to use)

集成、部署非常方便(Integrate with anything, deploy anywhere)： 提供了超过120个用来集成协议、应用的连接器和模板，足够应对常见的企业级应用集成问题，支持云端。

拖拽式的图形化界面设计器(Drag-and-drop graphical design)： 使用Anypoint Studio这个图形化设计的IDE，开发人员可以高效地创建集成流程。

使用常见的工具(Use the tools you know)： Mule ESB使用的是一些主流的开发工具，如Eclipse、Maven, Spring and Ant，开发人员可以很容易上手。

专为开发者而设计，被全球企业所选择(Designed for developers, chosen by global enterprises)

一个安全的平台(A secure platform)： 系统会阻止未经授权的访问，保护敏感的数据，通过Anypoint Enterprise Security的安全管理机制主动防御潜在的攻击。

可扩展的、可靠的、可用的(Scalable, reliable, available)： 高吞吐量和高度分布式环境的架构。

Mule ESB的内置高可用性集群和数据网格可以确保不会有消息丢失。 内置可见性(Built-in visibility)：提供查看运行性能的界面，监控关键的统计数据，并可以设置SLA报警，为诊断和解决性能问题提供极大便利。 封装性——管理应用系统和组件之间的交互，不管它们是否在同一个VM(Visual Machine-虚拟机，即JVM-Java虚拟机)或在Internet上，不管底层使用的传输协议。不管应用系统使用的是哪些不同的技术，包括：JMS Web Services JDBC HTTP 等，Mule可以无缝的在他们之间进行处理交互动作。高度可扩展性——允许你以很小的规模开始，随着时间的推移，连接更多的应用系统。

2、Mule基于Enterprise Service Bus(ESB)架构思想。

补充：【见ppt即可】

0、软件开发的演变历程面向机器语言(Monolithic)的开发模式需要根据不同平台的机器语言来开发代码。 面向过程(Procedure)的开发模式使用独立于机器的程序语言来进行开发，如C、Pascal，用过程来代表一个抽象的代码集合，包装重用现成的代码。 面向对象(Object)的开发模式用更接近现实的对象来表述一个相对完整的事物，面向对象的语言(C++，Java等)，提供了更抽象的封装和重用模式。面向对象的开发强调从现实世界问题域到软件程序的直接映射，更接近人类的自然思维方式。 面向组件(Component)的开发模式随着软件开发规模的扩大，在涉及分布式、异构等复杂特征的环境中，代码级别的重用性差，可维护性差，效率低的弱点是不可逾越的，因此人们以架构运行环境(如.Net，J2EE等)来提供完善的支撑平台，从而把开发者解放出来，更专注于业务核心的开发。而这些业务功能(Business Function) 以组件的形式(DCOM， EJB等)发布运行在架构运行环境中。软件开发的重用模式也上升到业务组件的级别。 面向服务(Service)的模式

1、面向服务架构SOAService-Oriented Architecture，面向服务的体系结构

一种架构模型，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。

SOA架构有哪些基本的要求？ SOA在相对较粗的粒度上对应用服务或业务模块进行封装与重用 服务间保持松散耦合，基于开放的标准， 服务的接口描述与具体实现无关 灵活的架构 -服务的实现细节，服务的位置乃至服务请求的底层协议都应该透明

2、ESB：图1：已经按照SOA的思想提炼出了各种业务服务，公布出来，同样，你发现其他很多人也做了同样的事情。大家都很振奋，开始踊跃的尝试，我调用你的一个服务，你调我的一个服务。啊哈！大家都SOA了。且慢，那么这个SOA给你们带来了什么好处呢？Ok，现在我可以在J2EE环境里调用.Net的组件了，但是原来没有SOA的时候也可以做到的呀。只要两个节点之间互相认可对方的方式，即使不存在公开/统一的服务界面也可以实现点到点的互联。因此我们不得不承认，如果我们只有服务，而服务的请求者和服务的提供者之间仍然需要这种显式的点到点的调用，那么这就不是一个典型的SOA架构。服务的参与双方都必须建立1对1 的联系。

在SOA中，我们还需要这样一个中间层，能够帮助实现在SOA架构中不同服务之间的智能化管理。最容易想到的是这样一个HUB-Spoke结构，在SOA架构中的各服务之间设置一个类似于Hub的中间件，由它充当整个SOA架构的中央管理器的作用。

图2：现在服务的请求者和提供者之间有了一个智能的中转站， 服务的请求者不再需要了解服务提供者的细节。 可能会出现哪些问题呢？首先，整个SOA架构的性能，如果每个服务的请求都经过中央Hub的中转，那么Hub的负担会很重，速度会随着参与者的增多而愈来愈慢；其次，这样的系统会很脆弱，一旦Hub出错，整个SOA架构都会瘫痪；最后，这样的架构会破坏SOA的开放性原则，参与者运行在一个相对封闭的环境中，扩展起来十分麻烦。

图3： MuleESB是一种在松散耦合的服务和应用之间标准的集成方式(即使我们需要一些Hub，那么它们也是以某种服务的形式部署在总线上，相比上面的结构要灵活的多 ) - 比单一Hub的形式更开放，总线结构有无限扩展的可能 - 真正体现了SOA的理念， 一切皆为服务，服务在总线(BUS)中处于平等的地位

ESB可以作用于：

面向服务的架构（分布式的应用由可重用的服务组成）面向消息的架构（应用之间通过ESB发送和接受消息）事件驱动的架构（应用之间异步地产生和接收消息）

//见ppt 首先，在ESB系统中，被集成的对象被明确定义为服务，而不是传统EAI中各种各样的中间件平台，这样就极大简化了在集成异构性上的考虑，因为不管有怎样的应用底层实现，只要是SOA架构中的服务，它就一定是基于标准的。

其次，ESB明确强调消息(Message)处理在集成过程中的作用，这里的消息指的是应用环境中被集成对象之间的沟通。传统的EAI系统中的消息处理大多是被动的，消息的处理需要各自中间件的私有方式支持，例如API的方式。ESB系统由于集成对象统一到服务，消息在应用服务之间传递时格式是标准的，直接面向消息的处理方式成为可能。如果ESB能够在底层支持现有的各种通讯协议，那么对消息的处理就完全不考虑底层的传输细节，而直接通过消息的标准格式定义来进行。这样，在ESB中，对消息的处理就会成为ESB的核心，因为通过消息处理来集成服务是最简单可行的方式。这也是ESB中总线(Bus)功能的体现。ESB的概念不仅仅是提供消息交互的通道，更重要的是提供服务的智能化集成基础架构。

最后，事件驱动成为ESB的重要特征。通常服务之间传递的消息有两种形式，一种是调用(Call)， 即请求/回应方式，这是常见的同步模式。还有一种我们称之为单路消息(One-way)，它的目的往往是触发异步的事件， 发送者不需要马上得到回复。考虑到有些应用服务是长时间运行的，因此，这种异步服务之间的消息交互也是ESB必须支持的。除此之外，ESB的很多功能都可以利用这种机制来实现，例如，SOA中服务的性能监控等基础架构功能，需要通过ESB来提供数据，当服务的请求通过ESB中转的时候，ESB很容易通过事件驱动机制向SOA的基础架构服务传递信息。

3、主要功能

Mule是一个轻量级的集成平台，Mule不是用来创建多个系统、服务、APIs或者设备之间的点对点集成，而是用来智能管理节点之间的消息路由、数据映射、编排以及使消息可靠地、安全地传递。其他系统和应用接入Mule，让Mule处理所有系统之间的通信，并且可以跟踪和监控发生的一切。

使用Mule，可以：

4、Mule基础4.1 Anypoint平台Anypoint Platform是一个完整的用于SOA、SaaS和APIs的集成平台，提供了一组功能强大的工具和服务来实现以下集成目标：  集成SaaS和本地应用程序；  现代化的遗留服务(legacy services)；  编排业务流程和服务；  为终端用户、B2B应用和移动端应用设计和发布API；  创建API代理使实现脱离业务流的编排(Create API proxies to separate implementation from orchestration)；  Engage consumers of your API  管理API的运行时策略(Govern APIs with runtime policies)

4.2 几个重要的概念流程和消息(Flows and Messages)