ESB Mule 中间件技术_服务器软件

PPT 内容

1. Enterprise Service Bus 技术介绍刘刚 Peking University 2011-04-01
2. 提纲EAI、SOA与ESB 什么是EAI 什么是SOA EAI向ESB的发展 SOA与ESB的关系 ESB的概念什么是ESB ESB功能模型 ESB最简功能定义 ESB常用技术与规范其它开源ESB实 ESB实现 Mule定义 Mule的工作原理
3. Mule ESB 案例分析 — Mule ESB Hello Wrold详解 Mule ESB的总结 — 什么时候用ESB架构 —Mule的优点和缺点
4. EAI、SOA与ESB
5. 软件开发的演变历史面向机器语言(Monolithic)的开发模式面向过程(Procedure)的开发模式面向对象(Object)的开发模式面向组件(Component)的开发模式面向方面（AOP）的开发模式面向服务(SOA)的模式
6. 什么是EAIEAI是(Enterprise Application Integration)企业应用集成。 EAI 技术是软件行业首次尝试将市场上各种不同中间件解决方案整合为单一产品套件。当各公司开始寻求在不同的自动化系统间交换信息时，对 EAI 的需求也就应运而生了。在上世纪的九十年代，企业范围内诸如客户关系管理 (CRM) 和企业资源计划 (ERP) 等业务举措是促使 EAI 系统诞生的主要驱动因素。在 EAI 面世之前，中间件的蓝图主要是由一系列协议栈（例如 CORBA、Tuxedo 和 MQ）以及数据格式（XML、XDR、固定格式、可变格式等）构成的。这些技术中的每一项都能够在很大程度上满足企业自身的集成需要，但是这需要选定的协议和数据格式在企业中完全通用才能够实现。事与愿违，实际情况却是，大中型 IT 企业都不可避免的具有异构特点。
7. 图 1：EAI 代理程序充当交换中心角色如图 1 所示，EAI 采用了一种简单有效的方式来解决不同应用程序间的集成问题。EAI 软件创建了一个交换中心，用于转换不同应用程序间的数据和消息。EAI 交换中心使用这些适配程序将所有进入数据的格式重新转换为一种 EAI 交换中心内部和外发适配程序都可以理解的通用格式，并将其称为规范格式。每个适配程序都是一个有自主权的实体软件，存在多个分别负责管理各种应用程序特定交互操作的管理层，同时还另具有一些传输层，用于管理与应用程序和交换中心的连接。
8. 什么是SOAService Oriented Architecture 一种以服务为基础的架构服务边界清晰服务自治，低耦合服务通过Schema和Contract发布，而不是Class和Type
9. SOA将业务应用拆分为动态的和可重用的服务 1、将应用分解为模块和可重用的函数以及服务；2、组合服务和模块以符合业务需求；3、重用现有的服务和模块以满足变化的业务需求；4、SOA是软件行业为应对单一大型应用程序的管理问题产生的解决方案；
10. 为什么会有ESB假如我们按照SOA的思想提炼了各种服务，并把它暴露出来，那我们怎么调用呢？方案一：图3节点间互联
11. 图3的结构只有服务，而服务的请求者和服务的提供者之间仍然需要这种显式的点到点调用。设想：如果我们用一个中间层，能够智能化管理这些不同的服务。此时我想到了HUB-Spoke结构，在SOA架构中的各个服务之间设置一个类似于Hub的中间件，由它来充当整个SOA架构的中央管理器的作用。如下图：
12. 方案二图4采用中间层
13. 如图4所示，现在服务的请求者和提供者之间有了一个智能的中转站，服务的请求者不需要了解服务提供的细节，这看上去是一个很好的SOA结构，其实和我在前面讲的EAI企业解决方案的思想是一样的。问题又来了：选择Hub的模式来构建SOA基础架构，从逻辑的角度可能会出现哪些问题呢？从性能方面看 —每个服务的请求都要经过中央Hub的中转，Hub的负担会很重，速度会随着服务的怎多而俞来愈慢。
14. 从可用性来分析 — 这样的系统很脆弱，一旦Hub出错，整个SOA架构就会瘫痪。从开放性来分析 —这样的架构会破坏SOA的开放性原则，参与者运行在一个相对封闭的环境中，扩展起来十分麻烦。因此，这个也不是理想的SOA架构。为了设计一个理想的SOA架构产生了ESB，如下图：
15. 图5 ESB应用
16. ESB与前面的Hub结构有什么不同？它比单一的Hub形式更开放，总线结构有无限扩展的可能。真正体现了SOA的理念，一切皆是服务，服务在总线中处于平等的地位。即使我们需要一些Hub，那么他们也是以某种服务的形式部署在总线上。
17. SOA与ESB的关系SOA的概念面向服务架构，实际上强调的是软件的一种架构，一种支撑软件运行的相对稳定的结构，表面含义如此，其实SOA是一种通过服务整合来解决系统集成的一种思想。不是具体的技术，本质上是一种策略、思想。 ESB的概念企业服务总线，像一根“聪明”的管道，用来连接各个“愚笨”的节点。为了集成不同系统，不同协议的服务，ESB做了消息的转换解释与路由等工作，让不同的服务互联互通。
18. 目前ESB与SOA的确切概念依然没有。但可以明确的说SOA就是一种服务集成思想，它的不同实现方式可能差别很大，目前SOA最常见的实现方式是SCA和JBI。首先，ESB不是SOA。SOA的最常见的实现方式方式是SCA和JBI，而SCA的实现需要ESB，相反JBI则不需要ESB。其次，因为IBM和Oracle（收购了BEA和SUN的牛X公司）都推崇SCA模式的SOA，因此SCA实际上已经成为SOA的事实标准，说道SOA，最先想到的就是SCA模式了。最后，ESB是SCA架构实现不可缺少的一部分，ESB产品脱离了具体的应用外，没有任何意义。ESB的作用在于实现服务间智能化集成与管理的中介。通过ESB可以访问所集成系统的所有已注册服务。
19. ESB概念
20. Enterprise Service BusESB全称为Enterprise Service Bus，即企业服务总线。 ESB是传统中间件技术与XML、Web服务等技术相互结合的产物，用于实现企业应用不同消息和信息的准确、高效和安全传递。一个ESB是一个预先组装的SOA实现，它包含了实现SOA分层目标所必需的基础功能部件。 ESB是一种松耦合的服务和应用之间标准的集成方式。
21. ESB要解决的问题
22. ESB功能的简单描述在服务与服务之间路由消息。在请求者与服务者之间转换传输协议。在请求者与服务者之间转换消息格式。处理来自各种异构源的业务事件。
23. ESB功能模型定义
24. 1、通信路由寻址通信技术、协议和标准（例如 JMS、HTTP 和 HTTPS）发布/订阅响应/请求 Fire-and-Forget，事件同步和异步消息传递
25. 2、服务交互服务接口定义（例如，Web 服务描述语言（Web Services Description Language，WSDL））支持替代服务实现通信和集成所需的服务消息传递模型（例如 SOAP 或企业应用程序集成 (EAI) 中间件模型）服务目录和发现
26. 3、集成数据库服务聚合遗留系统和应用程序适配器 EAI 中间件的连接性服务映射协议转换应用程序服务器环境（如 J2EE 和 .NET）服务调用的语言接口（如 Java /C/C++/C#）
27. 4、服务质量事务（原子事务、补偿、Web 服务事务（WS-Transaction））各种确定的传递范例（例如 Web 服务可靠消息传递（WS-ReliableMessaging）或对 EAI 中间件的支持）
28. 5、安全性身份验证授权不可抵赖性机密性安全标准（例如 Kerberos 和 Web 服务安全性（WS-Security））
29. 6、服务级别性能吞吐量可用性其他可以构成契约或协定的持久评估方法
30. 7、消息处理编码的逻辑基于内容的逻辑消息和数据转换有效性中介：提供位置透明性的服务路由和定位服务；多种消息传递形式；支持广泛使用的传输协议。对象标识映射数据压缩
31. 8、管理和自治服务预置和注册记录、测量和监控服务发现系统管理和管理工具的集成自监控和自管理
32. 9、建模对象建模通用业务对象建模数据格式库 B2B 集成的公共与私有模型开发和部署工具
33. 10、基础架构智能业务规则（EIP）策略驱动的行为，特别是对于服务级别、服务功能的安全和质量（例如 Web 服务策略（WS-Policy））
34. ESB的架构模型
35. 最简单ESB功能构成
36. 支持SOA的最低功能的ESB实现原则 ESB 是一种逻辑体系结构组件，它提供与 SOA 的原则保持一致的集成基础架构。 SOA 原则需要使用与实现无关的的接口、强调位置透明性和可互操作性的通信协议、相对粗粒度和封装可重用功能的服务定义。 ESB 可以作为分布式的异构基础架构进行实现。 ESB 提供了管理服务基础架构的方法和在分布式异构环境中进行操作的功能。
37. 最低的ESB功能通信提供位置透明性的路由和寻址服务控制服务寻址和命名的管理功能至少一种形式的消息传递范型（例如，请求/响应、发布/订阅等等）支持至少一种可以广泛使用的传输协议集成支持服务提供的多种集成方式，比如 Java 2 连接器、Web 服务、异步通信、适配器等等服务交互一个开放且与实现无关的服务消息传递与接口模型，它应该将应用程序代码从路由服务和传输协议中分离出来，并允许替代服务的实现。
38. ESB常用技术与规范XML/SOAP Web Service（技术与相关规范） JMS/Servlet/EJB JBI /SCA JBI SUN公司解决SOA的方案 SCA BEA、IBM、Oracle等知名中间件厂商联合制定的一套符合SOA思想的规范 EIP Routing Rules Mediation Rules
39. ESB应用ESB在不同领域具有非常广泛的用途：电信领域：电信行业OSS的应用整合，是理想的电信级应用软件承平台。电力领域：电力行业EMS的数据整合，是理想的SCADA系统数据交换平台。金融领域：银企间业务处理平台的流程整合，是理想的B2B交易平台。电子政务：支持电子政务应用软件业务基础平台、信息共享平台、决策分析支持平台和政务门户的平台化实现。其它领域
40. ESB的应用前景企业级应用系统一直是中国软件产业发展的主要方向之一，占有至关重要的地位。同时，它也受到整个世界IT发展潮流的影响，当前IT软件领域的主要技术趋势是SOA和ESB，原因是信息技术的不断发展和成熟使各个企业有机会在更大的范围内整合自己的资源，提高经营运行效率。
41. ESB的开源实现有哪些它是一个轻量级的消息框架和整合平台，基于EIP（Enterprise Integeration Patterns,由Hohpe和Woolf编写的一本书）而实现的。Mule的核心组件是UMO(Universal Message Objects，从Mule2.0开始UMO这一概念已经被组件Componse所代替)，UMO实现整合逻辑。UMO可以是POJO,JavaBean等等。它支持20多种传输协议(file,FTP,UDP,SMTP,POP,HTTP,SOAP,JMS等)，并整合了许多流行的开源项目，比如 Spring,ActiveMQ,CXF, Axis,Drools等。虽然Mule没有基于JBI来构建其架构，但是它为JBI容器提供了JBI适配器，应此可以很好地与JBI容器整合在一起。而 Mule更关注其灵活性，高效性以及易开发性。从2005年发表1.0版本以来，Mule吸引了越来越多的关注者，成为开源ESB中的一支独秀。目前许多公司都使用了Mule，比如Walmart,HP,Sony,Deutsche Bank 以及 CitiBank等公司。官方网站：http://mule.codehaus.org/ Mule
42. Apache ServiceMix 它是JBI规范的一种实现。它包涵了许多JBI组件，这些组件支持多种协议，比如JMS,HTTP,FTP,FILE等。同时也实现了EIP，规则和调度。自从JBI被JCP接收后，2005年末Apache ServiceMix才被Apache作为其卵化项目，到2007年9月，它已经成为Apache的顶级项目。ApacheServiceMix 也整合了其他的开源项目，比如Apache ActiveMQ,Apache CXF,Apahe Camel,Apache ODE以及Apache Geronimo。说起Apache ServiceMix,就会使我想到LogicBlaze公司。它曾经是Apache ServiceMix和Apache ActiveMQ的商业支持者。2006年LogicBlaze被IONA成功收购后，IONA负责为Apache ServiceMix提供支持和服务。同时IONA也将Apache ServiceMix作为FUSE平台中的一员，FUSE旗下还包括Apache ActiveMQ,Apache CXF,Apahe Camel,FUSE 官方网站：http://servicemix.apache.org/
43. Mule和Apache ServiceMix 是目前最流行的ESB开源的实现。此外还有： SUN 公司的 Open ESB。 Apache Synapse,它是构建在Apache Axis2之上。 Jobss 公司的 Jobss ESB。
44. 一个轻量级的ESB实现 --开源Mule
45. What is mule？Mule is a lightweight Java-based messaging framework that allows you to quickly and easily connect your applications and enable them to exchange data. Mule uses a service-oriented architecture(SOA), enabling easy integration of your existing systems.
46. Regardless of the different technologies the applications use, including JMS, Web Services, JDBC, HTTP, and more, Mule seamlessly handles interactions among them all.
47. (本页无文本内容)
48. Mule的关键特性基于J2ee1.4的企业消息总线和消息代理。可插入性链接，如JMS、JDBC、SMTP等。支持任何传输之上的异步，同步和请求响应时间处理机制。支持Axis或者Glue的Web Service。灵活的部署结构包括Client/Server、P2P、ESB等。支持声明性和编程性事务，还支持分布式事务XA。
49. 对事件的路由、传输和转换的端到端支持。 Spring集成框架，可以做ESB的容器，此外mule可以很容易的嵌套到Spring应用中。使用基于SEDA处理模型的高度可伸缩的企业服务器。支持REST API来提供技术独立和语言中立的基于web的对Mule事件的访问。强大的基于EIP模式的事件路由机制。动态、声明性的，基于内容和基于规则的路由选项。强大的应用集成框架。完整可扩展的开发模式。
50. Mule ESB架构图5 mule esb 架构图
51. Mule ESB 是一个消息ESB框架，一个消息代理，一个分级事务驱动的框架(SEDA)。SEDA定义了一个依照分级队列、高度并行的企业级平台。 Mule ESB 超出了传统意义上的ESB，我们更愿意把它定义为一个轻量级的消息架构，它的目的是管理消息组件，这些组件通常为UMO(Universal Message Objects)，他们可以共存在同一个VM中或者分散在你的网络中。UMO和其他应用软件系统之间的通信都是通过endpoints进行的。
52. Mule ESB的主要内容通用消息对象(UMO)API:定义了所有被Mule ESB管理的服务和对象交互。通用消息对象(UMO)组件：在Mule系统中，UMO组件可以是任何在系统中接收、处理和发送事件消息的组件。 Mule服务器：一个在Mule应用环境中自动加载的服务器应用程序。描述器：描述器组件描述一个Mule ESB UMO 属性。新的Mule ESB UMO对象能被他们所关联的描述器初始化。一个描述器包含：UMO组件名，UMO组件版本，UMO组件的实现类，异常策略，入站和出站提供者，入站和出站路由器，拦截器，接收和发送切入点，入站和出站转换器等特性。
53. 连接器：连接器是一些组件，他们可以连接到外部系统或其他协议、管理那些系统和协议的状态。一个连接器负责发送消息到外部消息接收器、管理消息接收器的注册和注销。提供者：提供者是一些组件，管理把事件数据发送到外部系统、从外部系统接受事件数据和转换事件数据等。终端调解者：当UMO组件接受到一个事件时，终端调解者决定去调用它的什么方法。转换器：转换器组件负责双向转换消息或事件的有效载荷。当一个事件到达接受的对象之前，转换器可以链接到一起去执行一系列的转换操作。
54. 消息设备器：消息设备器提供一种公共的方式去读外部系统的异构数据。消息接收器：消息接收器是一系列终端监听线程，负责从外部系统接收数据。消息调度者：消息调度者发送(同步)或派遣(异步)事件到下层系统。消息路由器：消息路由器是一系列组件，可以使被配置的UMO组件依据消息或其他配置路由一个消息到不同的提供者。代理：代理是一些绑定到外部服务的组件，例如JME服务器。
55. Mule 模型：一个Mule ESB模型封装和管理一个Mule ESB服务器实例运行时的行为。一个模型包含：描述器、UMO组件、一个终端调解者、一个生命周期设备器工厂、一个组件调节器、一个池化工厂、一个异常策略。 Mule 管理器：Mule ESB 管理器，它维护提供以下服务：代理提供者、连接器、终端、转换器、拦截器堆栈、一个Mule ESB模型、一个Mule ESB服务器、事务管理器、应用程序属性、Mule ESB配置。如下图：
56. Mule ESB 管理器
57. Mule ESB 工作原理
58. Mule ESB架构简图外围系统的服务请求通过Mule ESB的Transport接入，Mule通过Transformer进行数据的格式转换，然后经过Inbound Router进行消息过滤（内部通过配置filter实现）后交给Mule的Component进行业务逻辑处理，处理后的结果通过Outbound Router确定传递给哪个接收方，然后通过Transformer进行数据格式转换，通过Transport连接至接收方，传递信息。此图描述的是Mule中的一个典型场景的处理过程，涵盖了Mule中的各个关键组件。其中某些处理步骤不是必须的，如Inbound Router、Transformer。后续可以看到一些其他场景的处理。
59. Mule ESB 的TransportTransport管理消息的接收和发送，数据转换的过程也是在Transport中通过调用Transformer完成的。图 Transport
60. 传输提供者(Provider)它主要包含以下几个要素：Connector:用来连接底层的资源；Message Receiver：从系统接收事件；Connector Dispatchers：给系统传递数据；Transformers：用来转换输入输出的数据。消息连接器(Connector) —通过通道接收和传送数据；一个消息接收器和一个连接器以及一个由传输提供者组成的转换器器紧密结合；连接器主要作用是发送数据给一个资源和管理连接器的监听器以便从资源处接收数据。
61. 消息接收器(Message Receiver) — 从应用系统处接收数据并支持多种传输提供者。消息调度者 (Dispatcher) —他是一个接口主要是用来分发事件给底层支持的协议，该接口定义了三个重要的方法：Dispath():异步发送数据给外部系统；Send():同步发送数据给外部系统并返回响应信息；Receive()：发送请求给底层所支持的技术并返回得到的结果。这个方法有可配置的响应时间。
62. 消息传输器(Transformers) —用来将接收到的原数据转换成UMO组件需要的数据对象；在端点处进行配置以保证UMO组件能得到它所需要的数据对象；在输出端点处进行配置可以保证在分发事件前端点所接收到的数据对象是正确的；可以在同一个端点配置多个转换者，只需要在两个转换者之间加入空格就可以了。如下图：
63. 路由(Router)端点(Endpoints) —定义了发送和接收消息的通道入站路由器(Inbound router) —控制服务如何处理入站信息(incoming)，例如：有选择的只消费符合特定条件的消息或者在将消息转发给服务器之前将拥有同一group ID的消息聚合在一起。出站路由器(Outbound router) —控制如何分发经服务处理过的消息，比如，将消息发送到一个接受者列表，或者将消息分解成多个部分，并将它们分别发送至不同的端点。
64. 异步回复路由器（Asynchronous reply router） —常用于request/response场景。在这些场景中，发送一个请求会触发一个或者更多的请求，并且在返回响应之前，需要考虑这些请求的结果。典型的例子是请求发送后，会并行执行任务（task）。在返回响应之前，必须执行完每个任务，处理完结果。 Catch-all策略 —在当前消息找不到路由路径时才被调用。入站和出站端点都可以配置catch-all策略，因此可以捕获到任何孤立的消息，并将这些消息路由到一个共同的位置。过滤器(Filter) —提供用于调用特定路由器的逻辑。通过逻辑过滤器AndFilter、OrFilter和NotFilter可以将过滤器组合在一起使用。并非所有的路由器都需要使用过滤器，但是所有的路由器都支持过滤器。
65. Mule ESB Router 图 Router
66. Mule ESB Component在介绍Component组件之前先了解一下Model和Service。 Model表示托管各个服务的运行时环境。
67. Service是用来处理服务请求的基本单位，它调用各个组件进行服务请求的处理。
68. Component是Service的核心部件，是Service的业务逻辑的实现。Component可以是Java Class（POJO、Spring Bean）、Web Service、Script等。 Component可定义自己的生命周期：initialise、start、stop、dispose，不过需要实现Mule的LifeCycle接口。Mule 3.0版本开始提供@PostConstruct和@PreDestroy的注解，对应生命周期的initialise和dispose阶段，不需要实现Mule的LifeCycle接口了。
69. Mule ESB Flow(@since3.0)Flow是Mule 3.0新引入的，包含一个消息源（Message Source）和多个消息处理器组成的处理器链。
70. Flow 是Mule3.0中新增的一个处理消息的形式，它是区别一之前版本的service，可以以不同的方式来处理service中能够处理的消息。 Flow里面可以配置入站、出站信息， Flow 是不知道如何处理web服务调用的，所以我们一般修要一个像CXF这样的过滤器，因为CXF中有内置的支持去理解Get请求。
71. Mule 服务器端端点(Endpoints) 一个逻辑的、可配置的实体，它绑定在组件或外部资源上。他有下面几个属性： —Enpoints URI：表示一个资源提供者或者本地或远程接收者的地址。他必须是合法的URI； —Connector：用来连接底层所支持的传输。 —Filter：对端点接收到的数据进行过滤。
72. —Transaction:当一个事件发送或被接收时可以一个事务就可以开始执行； —Properties：根据不同端点实例的连接者的需求不同可以对需要的特性进行重新设置。通用消息对象组件(UMO Component) —UMO 代表Universal Message Object；它是一个可以接收来自于任何地方的消息的对象。UMO组件就是你的业务对象。这些组件是标准的JavaBean，组件中并没有任何Mule ESB特定的代码。Mule ESB基于你的组件的配置处理所有进出组件事件的路由和转换。
73. Mule 管理器(Mule ESB Manager) —它是Mule ESB Server实例的中心，主要的角色是管理各种对象，例如：Mule ESB 实例的连接器、端点和转换器。这些对象然后被用来控制进出你的服务组件的消息流，并且为Model和它所管理的组件提供服务。 Mule 模型(Mule ESB Model) —Model是管理和执行组件的容器。他控制进出组件的消息流、管理线程、生命周期和缓冲池。默认的Mule ESB Model是基于SEDA的，它使用一个有效地基于事件的队列模型来获取的最大性能和直通性。
74. Mule ESB服务器通知(Mule Motification Manager) —Mule ESB 有一个内置的消息机制，通过它可以接近服务器通知消息，例如：添加组件，初始化模型或者启动管理者的通知消息。 Mule ESB安全管理(Mule Sercurity Manager) —端点利用传输的特定细节或普通的认证方法对请求信息进行验证。 —在Mule ESB管理者处定义安全管理者。 —配置安全过滤器。
75. Mule ESB事务(Mule Transaction Manager) —对底层事务管理者来说是不可知的，在输入端点处进行配置。 Mule ESB 事件(Mule Event) —异步：许多事件可以在同一时间被同一组件以不同的线程进行处理； —同步：所有的事件在同一个执行线程中执行； —请求—响应：发送的请求必须在事先定好的时间内响应。
76. Mule ESB 案例
77. Hello World的代码结构
78. 数据类型：ChatString、NameString Transformer：ChatStringToString、ExceptionToString、HttpRequestToNameString、NameStringToChatString、 StdinToNameString、StringToNameString Service：ChitChater、Greeter 另外的一个类是LocaleMessage是一个从资源bundle中提取字符串的类，与mule没有直接关系。
79. Hello World案例详解Hello World的流程图
80. 即客户端中发出http请求，访问http://localhost:8888/?name=liugang，通过Http Transport把一个http请求传递给Hello World flow，一个能够把HttpRequest转化为NameString的transformer转换数据类型，交由一个POJO类Greeter.java处理，这个类产生了一个“Hello,Ross”的NameString，将这个笑傲西通过VM Transport（即JVM中的过程调用方法，速度较快）交给ChitChat flow处理，这个流程中做了两次的类型转换，分别从NameString转换到ChatString，从ChatString转换到String，产生一个字符串“Hello,Ross,How are you?”，返回给服务调用者，也就是浏览器，这个过程就算完成了，如出现一些错误，就做一些错误处理。
81. Hello World mule-config.xml全局连接器此处就可以使用标准输入输出的连接器，只需要以stdio为前缀全局自定义转换器
82. 配置服务实体
83. 配置inbound section 此处指定了该服务使用何种transport（HTTP）、消息起源（http://localhost:8888）、使用何种transformer（HttpRequestToNameString）、此处不需要使用connector、消息交换模式（此处HTTP需要同步response）。
84. 配置组件组件可以使普通的JAVA类、Spring Bean、Java Script、web service等等，如此处用了POJO。
85. 配置outbound section如果消息payload被正确的转换成NameString，消息router就使用vm transport把消息转发给chitchat（vm是JVM中的内部消息传递，速度快，若是在不同的JVM则需要使用JMS），如果消息没有正确地被转换，就把消息传递给userErrorHandler。
86. MuleClient client = new MuleClient(muleContext); client.send("vm://greeter", “liugang", null); MuleMessage response = client.send("vm://greeter", “liugang", null); System.out.println("response = " + response.getPayload()); 配置VM 传输然后用Mule Client API 去调用服务:
87. Mule场景集成两个或者多个需要互相通信的或者多个现有的系统。需要完全和周围环境去耦合的应用，或者需要在系统中伸缩不止一个组件的系统。开发人员不知道未来是否会将其应用分发或者伸缩需求的单VM应用。
88. Mule的优缺点 Mule ESB是一个以Java为中心的ESB，这让Java开发者能很容易地上手。它拥有强大的XML模式集合，它们创建了一个真正清洁可读的XML配置并提供了代码补全支持。当你想实现一项转换逻辑或者路由逻辑时，你能够很轻易地开发出一个简单的Java类/Spring bean/脚本文件，把它引入到XML配置中。必须要指出Mule的一个不足之处，那就是缺乏对于热部署的支持。如果Mule集成OSGi或者其他方法，就能很容易的更新集成流程，这将是一个大大的加分点。Mule3.0里面加入了OSGI的热部署功能。
89. Q&Thanks!

ESB Mule 中间件技术

thp520

贡献于2012-11-27

ESB Mule 中间件技术

PPT 内容

PPT 图集

相关PPT