Mule ESB WebService Consumer 结合 DataMapper的使用
微服务治理框架的技术选型
微服务治理框架的技术选型目录微服务治理框架的技术选型 (1)1 RPC (3)2 服务化 (4)3 微服务 (6)SOA服务化和微服务架构已经发展多年，市场上已经有很多成熟的商业和开源产品，我们没有必要从头搭建一套服务化管理和治理平台，完全可以基于开源服务化框架进行定制化，以适应我们的业务需要。
本文介绍各种流行的RPC框架、服务化管理和治理、微服务框架，并通过讲解其特点来帮助我们做技术选型。
1 RPC本节介绍简单的远程服务调用的技术栈。
1. JDKRMI自JDK1.4开始，JDK内置了远程服务调用的技术栈，可以帮助开发者创建基于Java到Java的分布式调用架构，一个Java进程内的服务可以调用其他Java进程内的服务，使用JDK内置的序列化和反序列化协议。
RMI是JEE规范中EJB远程调用的基础，然而，JDK内置的RMI服务并没有得到广泛应用，几乎没有哪家公司采用这种方式来构建服务化平台。
原因如下。
l RMI采用JDK自带的专用序列化协议，不能跨语言。
l使用了底层的网络协议，不如基于文本的HTTP可读，也不如HTTP被广泛认可和应用。
l开源框架的飞速发展，严重削弱了JDK资深技术的流行程度。
2.Hessian及BurlapHessian及Burlap都是Caucho公司提供的开源的远程调用协议，基于HTTP传输，防火墙通常会设置在某个端口上以允许特定的HTTP通信。
其中，Hessian将对象序列化成与语言无关的二进制协议；而Burlap将对象序列化成与语言无关的XML数据，数据是可读的。
两者都是与语言无关的，可以在多种语言的服务中互相调用。
Hessian及Burlap都适合传输较小的对象，对较大、复杂的对象，无论是在序列化方式上还是在传输通道上都没有RMI有优势。
由于服务化架构中大量的服务调用都是大规模、高并发的短小请求，因此，Hessian和Burlap协议在服务化架构中得到了广泛应用。
3. Spring HTTP InvokerSpring HTTP Invoker重用了JDK内置的对象序列化技术传输对象，这与RMI的原理一致，但是，它通过HTTP通道传输数据，在效率上应该略低于RMI，并且由于使用了JDK内置的序列化机制，因此也是不能跨语言的。
MuleESB简介
Mule ESBMule ESB简介什么是Mule ESB？Mule ESB是一种基于java的、轻量级的企业服务总线和集成平台，她允许开发者快速的、简单的连接应用，并能够实现数据的转换。
从2005年发表1.0版本以来，Mule吸引了越来越多的关注者，成为开源ESB中的一支独秀。
目前许多公司都使用了Mule，比如沃尔玛,惠普,索尼,Deutsche Bank 以及CitiBank 等公司。
Mule官方网站：/Mule ESB的主要功能如下：●服务的创建与管理（Service creation and hosting）：用Mule ESB作为一个轻量级的服务容器来暴露和管理可重用的服务。
●服务调解（Service mediation）：隐藏服务消息的格式和协议，将业务逻辑从消息中独立出来，并可以实现本地独立的服务调用。
●消息路由（Message routing）：基于内容和规则的消息路由、消息过滤、消息合并和消息的重新排序。
●数据转换（Data transformation）：在不同的格式和传输协议中进行转换数据。
Mule3Mule近期推出了Mule3，Mule3的新增特点-云连接（Cloud Connect）。
云连接提供了可以用简单安全的方式为企业提供基于云技术的数据和服务。
它的核心是IBeans，一个轻量级、可重用的接口，用于Web技术的连接扩展和数据服务。
Mule云包括以下内容1、Integration Beans （合成bean）：他们是可重用的云接口，可以注入到组件中，可以接受外部的服务，比如说亚马逊、推特、Facebook等，并且是一种简单的接收服务、管理安全机制的方法。
请求验证、数据传输、错误挂起等也可以通过这种方法来实现。
2、Rest / JAX-RS：（REST协议：即REST(Representational State Transfer表述性状态转移)是一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。
ESB Mule 中间件技术
目前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可以访问所集成系统的所有已注册服务。
Enterprise Service Bus 技术介绍
刘刚 Peking University 2011-04-01
提纲
EAI、SOA与ESB
– – – – – – – – – 什么是EAI 什么是SOA EAI向ESB的发展 SOA与ESB的关系 什么是ESB ESB功能模型 ESB最简功能定义 ESB常用技术与规范 其它开源ESB实
4、服务质量
• 事务（原子事务、补偿、Web 服务事务 （WS-Transaction）） • 各种确定的传递范例（例如 Web 服务可靠 消息传递（WS-ReliableMessaging）或对 EAI 中间件的支持）
5、安全性
• • • • • 身份验证 授权 不可抵赖性 机密性 安全标准（例如 Kerberos 和 Web 服务安全 性（WS-Security））
6、服务级别
• • • • 性能 吞吐量 可用性 其他可以构成契约或协定的持久评估方法
基于mule的ESB解决方案
EIP经典案例Load Broker——Mule ESB实践author:mythmoon@Version 0.1(draft)转载保留出处读者背景:具有2年以上J2EE开发背景,熟悉Spring,Hibernate,Jbpm,Axis,Tuscany,Mule 等框架,对EJB,Jms,soap,ws-*,BPM,SCA\SDO等技术规范,对ESB,SOA,通讯网关有一定了解,同时对底层Socket通讯协议HTTP,FTP等也有一定了解.当然对主流数据库也要熟悉,在示例中,使用DB2 V8.1Load Broker案例背景Obtaining a Loan QuoteWhen shopping for a loan, a customer usually calls several banks to find the deal with the best possible interest rate. Each bank asks the customer for his or her social security number, the amount of the loan, and the desired term (i.e., the number of months until the loan has to be paid off). Each bank then investigates the customer's credit background, usually by contacting a credit agency. Based on the requested terms and the customer's credit history, the bank responds with an interest rate quote to the consumer (or declines thankfully). Once the customer has received quotes from all banks, he or she can then select the best offer with the lowest interest rate.A Consumer Talking to Banks to Get a Loan QuoteFigure I-1Because contacting multiple banks with a loan quote request is a tedious task, loan brokers offer this service to consumers. A loan broker is typically not affiliated with any one bank but has access to many lending institutions. The broker gathers the customer data once and contacts the credit agency to obtain the customer's credit history. Based on the credit score and history, the broker presents the request to a number of banks that are best suited to meet the customer's criteria. The broker gathers the resulting quotes from the banks and selects the best offer to pass back to the consumer.A Loan Broker Acting as IntermediaryFigure I-2Load Broker 分析设计Designing the Message FlowWe want to design a loan broker system using integration patterns discussed in the previous chapters. To do this, let's first list the individual tasks that the loan broker needs to perform.1.Receive the consumer's loan quote request.2.Obtain credit score and history from credit agency.3.Determine the most appropriate banks to contact.4.Send a request to each selected bank.5.Collect responses from each selected bank.6.Determine the best response.7.Pass the result back to the consumer.Let's see which patterns could help us design and implement the loan broker. The first step describes how the broker receives the incoming request. "Messaging Endpoints," so for now, let's skip over this step and assume the message is somehow received by the load broker. Next, the broker has to retrieve some additional information: the customer's credit score. A Content Enricher sounds like the ideal choice for this task. Once the broker has the complete information, the broker must determine the appropriate banks to route the request message to. We can accomplish this with another Content Enricher that computes the list of recipients for the request. Sending a request message to multiple recipients and recombining the responses back into a single message is the specialty of the Scatter-Gather. The Scatter-Gather can use a Publish-Subscribe Channel or a Recipient List to send the request to the banks. Once the banks reply with their rate quotes, the Scatter-Gather aggregates the individual rate quotes into a single quote for the consumer using an Aggregator. If we model the message flow using these patterns, we arrive at the following design:Simple Loan Broker DesignFigure I-3We have not yet accounted for the likely event that each bank may use a slightly different message format for the loan request and response. Because we want to separate the routing and aggregation logic from the banks' proprietary formats, we need to insert Message Translators into the communication lines between the broker and the banks. We can use a Normalizer to translate the individual responses into a common format:Complete Loan Broker DesignFigure I-4扩展:核心技术与实现方案Sequencing: Synchronous versus AsynchronousSo far, we have described the flow of the messages and the routing and transformation patterns we can use to describe the design of the loan broker component. We have not yet discussed the timing of the broker operation. We have two primary choices:∙Synchronous (Sequential): The broker asks one bank for the quote and waits for a response before contacting the next bank.∙Asynchronous (Parallel): The broker sends all quote requests at once and waits for the answers to come back.We can use UML sequence diagrams to illustrate the two options. The synchronous option implies a sequential processing of all loan requests (see the following figure). This solution has the advantage of being simpler to manage because we do not have to deal with any concurrency issues or threads. However, it is an inefficient solution because we do not take advantage of the fact that each bank possesses independent processing power and could be executing requests simultaneously. As a result, the consumer might have to wait a long time for an answer.Synchronous, Sequential Processing of Loan RequestsFigure I-5The asynchronous solution issues all requests right away so that each bank can start processing. As the banks finish the computation, they return the results to the loan broker. This solution allows for a much quicker response. For example, if all banks take a similar amount of time to produce a loan quote, this solution is almost n times faster, where n is the number of banks we are dealing with. The loan broker now must be able to accept the loan quote reply messages in any order, because there is no guarantee that responses arrive in the same order that requests were made. The following sequence diagram illustrates this option. The open arrowhead on a loan quote request indicates an asynchronous invocation.Asynchronous, Parallel Processing of Loan RequestsFigure I-6Another significant advantage of using asynchronous invocation via a message queue is the ability to create more than one instance of a service provider. For example, if it turns out that the credit bureau is a bottleneck, we could decide to run two instances of that component. Because the loan broker sends the request message to a queue instead of directly to the credit bureau component, it does not matter which component instance processes the message as long as the response is put back onto the response channel.Addressing: Distribution versus AuctionUsing a Scatter-Gather to obtain the best quote allows us to choose from two addressing mechanisms, a Recipient List or a Publish-Subscribe Channel. The decision primarily depends on how much control we want to exert over the banks who are allowed to participate in a specific loan request. Again, we have a number of choices:∙Fixed: The list of banks is hard-coded. Each loan request goes to the same set of banks.∙Distribution: The broker maintains criteria on which banks are a good match for a specific request. For example, it would not senda quote request for a customer with a poor credit history to a bankthat specializes in premier customers.∙Auction: The broker broadcasts the request using aPublish-Subscribe Channel. Any bank that is interested is allowed to subscribe to the channel and "bid" on the request. Banks can subscribe or unsubscribe at will. Each bank can still apply its own criteria on whether to submit a bid.Figure I-7Which option is best for our scenario? As always, there is no simple "and the answer is...," but the choice is driven by both business and technical preferences and constraints. The first option is simple and gives thebroker control over the list of banks. However, if new banks come and go frequently, the solution can result in an administrative burden. Also, the bank may not be happy to be receiving a bunch of irrelevant requests, because each request incurs a certain internal cost for the bank. Also, to maintain the simplicity of this approach, the aggregation strategy is more likely to require all banks to submit a response. Banks may want to reserve the right to withhold from the bid.A distribution approach (using a Recipient List) gives the broker more control over which bank to involve in each loan request. This allows the broker to be more efficient by reducing the number of requests. It also allows the broker to prefer certain banks based on the business relationship. On the downside, it requires additional business logic to be implemented and maintained inside the loan broker component. Both the distribution and the fixed approach require a separate Message Channel for each participant in order to control the message flow.Using a Publish-Subscribe Channel broadcasts a loan request to all subscribing banks and lets each bank determine which requests to service. Each bank can use a Message Filter or implement a Selective Consumer to filter out undesirable loan requests. This approach renders the loan broker pretty much maintenance-free in cases of adding or removing banks, but it requires more work on the side of the banks. This solution requires only a single Message Channel , but it has to be implemented as a Publish-Subscribe Channel. Many efficient publish-subscribe schemes use IP Multicast that typically does not route across wide-area networks or the Internet. Other implementations emulate a Publish-Subscribe Channel by using an array of Point-to-Point Channels and a Recipient List. This approach preserves the simple semantics of a Publish-Subscribe Channel but is less efficient in its use of channels and network bandwidth. For additional trade-offs between routing and publish-subscribe plus filtering, see the description of the Message Filter.Aggregating Strategies: Multiple Channels versus Single ChannelWhen receiving loan quotes from the bank, we have similar design choices. We can have all banks submit their responses to a single response channel, or we can have a separate response channel for each bank. Using a single channel reduces the maintenance burden of setting up a separate channel for each participating bank but requires each bank's reply message to include a field identifying the bank who issued the quote. If we use a single response channel, the Aggregator may not know how many responsemessages to expect unless the Recipient List passes this information to the Aggregator (we call this an initialized Aggregator). If we use an auction-style Publish-Subscribe Channel , the number of possible responses is unknown to the loan broker, so the Aggregator has to employ a completeness condition that does not depend on the total number of participants. For example, the Aggregator could simply wait until it has a minimum of three responses. But even that would be risky if temporarily only two banks participate. In that case, the Aggregator could time out and report that it received an insufficient number of responses.Managing ConcurrencyA service such as a loan broker should be able to deal with multiple clients wanting to use the service concurrently. For example, if we expose the loan broker function as a Web service or connect it to a public Web site, we do not really have any control over the number of clients and we may receive hundreds or thousands of concurrent requests. We can enable the loan broker to process multiple concurrent requests using two different strategies:∙Execute multiple instances.∙ A single event-driven instance.The first option maintains multiple parallel instances of the loan broker component. We can either start a new instance for each incoming request or maintain a "pool" of active loan broker processes and assign incoming requests to the next available process (using a Message Dispatcher). If no process is available, we would queue up the requests until a process becomes available. A process pool has the advantage that we can allocate system resources in a predictable way. For example, we can decide to execute a maximum of 20 loan broker instances. In contrast, if we started a new process for each request, we could quickly choke the machine if a spike of concurrent requests arrives. Also, maintaining a pool of running processes allows us to reuse an existing process for multiple requests, saving time for process instantiation and initialization.Because much of the processing required by the loan broker is to wait for replies from external parties (the credit bureau and the banks), running many parallel processes may not be a good use of system resources. Instead, we can run a single process instance that reacts to incoming message events as they arrive. Processing an individual message (e.g., a bank quote) is a relatively simple task, so that a single process may be able to service many concurrent requests. This approach uses system resources more efficiently and simplifies management of the solution, since we have tomonitor only a single process instance. The potential downside is the limited scalability because we are tied to one process. Many high-volume applications use a combination of the two techniques, executing multiple parallel processes, each of which can handle multiple requests concurrently.Executing multiple concurrent requests requires us to associate each message in the system to the correct process instance. For example, it may be most convenient for a bank to send all reply messages to a fixed channel. This means that the reply channel can contain messages related to different customers' concurrent quote requests. Therefore, we need to equip each message with a Correlation Identifier to identify which customer request the bank is responding to.Three ImplementationsIn order to implement the loan broker example, we have three main design decisions to make: We have to select a sequencing scheme for the requests, select an addressing scheme for the banks, and define an aggregation strategy. In addition, we have to select a programming language and a messaging infrastructure. In aggregate, these individual options result in a large number of potential implementation choices. We chose to implement three representative solutions to highlight the main trade-offs between the different implementation options. As with all examples in this book, the choice of specific technologies is somewhat arbitrary and does not indicate the superiority of a specific vendor's technology. The following table highlights the characteristics of each solution:Table I-1The first implementation uses synchronous Web services implemented in Java and Apache Axis. The communication with each bank occurs over a separate HTTP channel, which serves as both a request and reply channel. Therefore, the aggregation strategy is based on individual reply channels and does not require correlation. The second implementation uses an asynchronous approach with message queues. We implement it using Microsoft's MSMQ, but an implementationusing JMS or IBM WebSphere MQ could look very similar. The last implementation uses an Auction approach and leverages TIBCO's publish-subscribe infrastructure and the TIB/IntegrationManager tool that implements the Process Manager pattern. In option B and C, all reply messages arrive on a single channel and the implementations use Correlation Identifiers to associate reply messages to customer loan quote inquiries.系统结构设计网络物理结构LoadBroker 包括web主机,ESB主机,流程主机运行在内网中。
ESB的开源框架Mule介绍
2013-8-14
3
ESB实现功能
• 传输器，转换器，路由器三者是ESB的 公共核心功能。 • 还包括事务、安全、异常管理 、JMX管 理架构、服务质量保证、定义和发现已 部署服务等。
2013-8-14
4
开源ESB框架
有三种比较流行的ESB开源框架，分别是 OpenESB ServiceMix Mule
2013-8-14
8
二 Mule介绍
• • • • Mule框架简介 Mule框架作用和强项 Mule框架构成 Mule与SOF框架关系
2013-8-14
9
Mule介绍
Mule 是一个基于ESB架构理念的消息平 台。是开放源码界最早成立的ESB项目 之一。其实现思想是不用更改既有系统， 直接透过组态设定，就可连接各服务端 点。 Mule将POJO对象包装成UMO对象，再 提供简单和一致的接口供外界访问，而 访问者不需要关心实现的细节。
11
Mule应用场景
2013-8-14
12
Mule总体框架
2013-8-14
13
Mule Manager
• Mule Manager是Mule server 实例的中心 (也称为一个Mule Node)。其主要的角色 是管理各种对象，比如Mule实例的连接 器、端点和转换器。这些对象然后被用 来控制进出服务组件的消息流，并且为 Model和它所管理的组件提供服务。
2013-8-14
5
OpenESB
OpenESB项目实现了一个运行期企业服 务总线(Enterprise Service Bus:ESB)使用 JBI(Java业务集成)作为核心基础。 OpenESB可以让你集成企业应用与Web Service松散地连接成复合的应用程序。 这使得你可以无缝地组合与拆解该复合 应用程序，并认识到一个真正面向服务 架构(SOA)的优点
Mule ESB使用手册
Mule ESB Studio v3.3 安装使用手册1***初级教程***如果你还没有做好准备，请到下载免费的社区版Mule ESB，按照网站上的说明启动Mule Studio，并且选择一个工作区（另外，你还可以下载30天免费试用的企业版Mule ESB）2安装Mule Studio安装前，请确认你的机器上已经安装了1.6版本的JDK。
最后请确认你的JDK环境变量配置是否正确2.1 导出将下载的文件解压到你的硬盘分区的根目录下，例如：C:\1. 执行找到C:\MuleStudio目录，运行muleStudio.exe启动Studio2. 选择工作区点击OK使用默认的工作区3使用Studio模板1. 点击File菜单，选择New > Mule Project2. 出现New Mule Project面板后，为你的项目输入名称和一个简短的说明，如图：3. 在Server Runtime选项上选择你将要使用的Mule运行时版本，如图：4. 点击旁边的复选框，根据现有的模板创建项目，单击项目，选择你想要使用的模板创建项目，如图：5. 点击Finish按钮，Mule Studio会创建并打开一个新的项目，完成预创建和预配置的流程6. 在Mule Studio的Package Explorer栏中，右键点击mule-config.mflow文件，选择RunAs > Mule Application7. 停止运行该项目，请在Mule Studio控制台点击红色的Terminate按钮，如图：4运行独立的例子1. 到Mule ESB Standalone目录下，找到Examples目录下你想运行的例子2. 拷贝.zip文件的例子到$MULE_HOME/apps目录下，例如：运行Flight Reservationexample的例子，拷贝mule-example-flight-reservation-3.3.0.zip到$MULE_HOME/apps 目录下，如图：3. 启动Mule，运行这个例子5启动Mule Studio如果你在安装过程中启动了Mule Studio，并且已经在运行了，请跳过本节的其余部分，直接进行：创建新项目如果当前Mule Studio没有启动，通过完成下面的步骤启动应用程序1. 找到Mule Studio安装目录2. 执行muleStudio.exe3. 点击OK使用默认的工作区6创建新项目1. 如果你看到是各种控制组件的应用程序窗口（右下图），请直接进入第2节。
mule——精选推荐
muleMule⼊门⽂档零、前提在按照本⽂进⾏操作之前，假设您的系统已经具备以下前提：已经安装了Sun公司的JDK1.4或JDK5.0版本，推荐使⽤JDK5.0。
正确设置了JAVA_HOME环境变量到JDK⽬录（注意不是JRE⽬录）。
确保%JAVA_HOME%\bin路径在系统寻找路径中。
安装有Eclipse3.2或以上版本的开发环境。
安装有Apache Tomcat 5.0或以上版本，推荐使⽤5.5。
⽂档假设Tomcat的安装⽬录为%TOMCAT_HOME%。
⼀、下载与安装到Mule的官⽅⽹站（/doc/ce7750612.html/display/MULE/Download）上下载Mule 的最新稳定版，⽬前是1.3.3（/doc/ce7750612.html/ccount/click.php?id=17），也可以使⽤社区版的1.4.1（/doc/ce7750612.html/ccount/click.php?id=33）。
本⽂档以1.3.3版为例，1.4.1请参照⽂档⾃⾏修改。
下载后得到⼀个ZIP格式的压缩⽂件mule-1.3.3.zip，将该⽂件解压⾄任⼀⽬录，假设为C:\mule-1.3.3，本⽂档以环境变量MULE_HOME表⽰该⽬录。
⼆、运⾏Echo⽰例Mule⾃带了很多⽰例，从最简单的echo⽰例到⼀个⽐较完整的贷款中介服务loanbroker。
每个⽰例程序都分为ant和maven两个版本，它们分别位于%MULE_HOME%\examples\ant和%MULE_HOME%\examples\maven⽬录下。
⽂档将以ant版本为例说明如何运⾏echo⽰例。
1、到apache官⽅⽹站的ant项⽬下载页（/doc/ce7750612.html/bindownload.cgi）上下载ant1.7.0（/doc/ce7750612.html/ant/binaries/apache-ant-1.7.0-bin.zip），下载后将⽂件解压到任⼀⽬录（假设为C:\apache-ant-1.7.0，⽂档中表⽰为ANT_HOME环境变量）。
Mule简介
Mule简介Mule是什么？Mule是⼀个轻量级的基于Java的ESB消息框架，它允许⽤户快捷地连接多个应⽤并且在这些应⽤之间交换数据。
Mule使⽤了SOA的体系结构思想，可以⽅便的集成已有的应⽤。
它是可升级的、⾼分布式的对象代理，可以通过异步传输消息技术来⽆缝的处理服务与应⽤之间的交互。
Mule框架提供了⼀个可升级的环境，可以把⾃⼰的业务组件部署在⾥⾯。
Mule管理所有组件之间的交互，不管它们是在同⼀个虚拟机中还是在internet上，也不管底层使⽤的传输⽅式。
Mule围绕着企业服务总线（ESB）架构进⾏设计，保证了不同的组件或者应⽤可以通过公共的消息总线进⾏交互，公共的消息总线⼀般是由JMS或者其他消息服务器来实现。
在应⽤中会使⽤不同的技术，包括JMS,Web Services，JDBC，HTTP等等，Mule可以很好地处理他们之间的交互。
Mule有以下的优点：(1)Mule组件可以是你需要的任何类型。
你可以很容易地集成⼀切从⼀个"plain old Java object"（POJO）到另⼀个框架的组件。
(2)Mule和ESB模型允许组件重⽤。
不像其他的框架，mule允许你使⽤⼀个已有的组件⽽不需要改变。
组件不需要任何特定的mule代码，并且没有要求的API。
业务逻辑和消息逻辑保持完全分离。
(3)消息可以是任何格式，从SOAP到⼆进制图像⽂件。
mule对体系结构不强制任何设计限制，⽐如XML消息或者WSDL服务。
(4)你可以以多种拓扑结构开发mule，不仅仅是ESB。
因为它是轻量级的和可嵌⼊的，mule可以有效地减少到市场的时间，并且增强项⽬参评，⽐如安全性，可扩展性。
mulesorce提供了管理⼯具运⾏管理你的开发(Mule HQ)和基础设施(Mule Galaxy)。
理解消息框架应⽤⽹络化的好处是使得⼀个应⽤能够发送数据到另⼀个应⽤。
但是许多应⽤不能够读取和处理另⼀个应⽤的数据。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Mule ESB WebService Consumer 结合 DataMapper的使用（ 一 ）
以下是一个简单的通过http传递参数，调用远程WebService 组件并将查询结果转换为JSON到http页面显示。
以下分别对相应组件的配置做一下说明：
HTTP : 配置一个 监听 ip 地址为： localhost 监听端口为：8081 的，监听uri为： /ws的http 监听组件
在配置的xml文件中，声明一个全局的 http 监听：
<http:listener-config name="HTTP_Listener_Configuration" host="localhost" port="8081" doc:name="HTTP Listener Configuration" />
然后在流程中按以下方法引用：
<http:listener config-ref="HTTP_Listener_Configuration" path="/ws" doc:name="HTTP" />
WebService Consumer :
在connector组件中找到WebService Consumer连接器，双击组件后可以进入编辑页面，按以下填好wsdl请求地址，
其他的功能将由该组件自动完成。
编辑完成之后点击ok，出现如下界面，Operation处选择要执行的方法即可
DataMapper : 配置一个将 http参数转化成 WebService方法接收的参数去请求WebService服务DataMapper 图像化配置界面：
用户自定义Map结构界面配置：
以上步骤配置好了之后，选择下方的Create mapping，会出现下图：
最后，只需在WebService后面接上对应的结果处理或者转换即可，本实例使用了一个内置的XML to JSON转换器，将请求结果转换成json后在
html页面输出。