关于Mule3.0中WebService Proxy的实现机制和实例浅析

作者：nereus.chen@gmail.com honnom@163.com

时间：2010-10-23

首发：http://blog.csdn.net/honnom

转发：该blog已经转发到新博客，旧博客将不再维护

关键词：OpenSource、Mule 、WebService Proxy

一、WebSevice Proxy 简介

WebService Proxy 是ESB中最常见的使用场景之一，即通过 ESB 直接转发 WebService Client 的 SOAP 请求，并将 WebServcie

Provider 的 SOAP 响应转发给 WebService Client ，此时的ESB就是一个WebService Proxy。

二、WebSevice Proxy 在 Mule 中的产生背景

Mule3.0 新增了一些比较有亮点的新特性 ，其中包括“

pattern-based configuration ”这个概念。 pattern-based configuration

的主要目是将常用的功能模式化，达到简化配置文件的目的，主要包括四种模式：
Simple Service 、
Web Service Proxy 、 Bridge
和

Validator。 Web Service Proxy Pattern 正是本文中提到的 WebService Proxy ，这里
有关于它的更多介绍。

三、Web Service Proxy 的 实现

1、WSProxy 的实现机制

WSProxy 实现机制的组件图如下所示



在Mule中WSProxy 由 3 个组件组成：

(1) MessageSource

它通过 MessageLister 接收或者产生 MuleMessage ，本实例中采用 DefaultInboundEndpoint 作为 MessageSource ，并通过

socket 接收 SOAP消息。这里
有关于 MessageSource 的介绍。

(2) AbstractProxyRequestProcessor

负责处理MuleEvent，重写WSDL地址。其实现类有两个，分别是： StaticWsdlProxyRequestProcessor 和

DynamicWsdlProxyRequestProcessor ，本实例中采用的是 DynamicWsdlProxyRequestProcessor 。

(3) OutboundEndpoint

负责分发和接收SOAP消息。

2、WSProxy 运行期数据流图

运行期数据流图如下所示



运行期数据流：

(1)在 DefaultInboundEndpoint 中， HttpServerConnection 负责在 http://localhost:8080 上接收 SOAP 请求，

MessageProcessorChain 是一系列的 MessageProcessor ，对 MuleEvent 进行处理，主要包括：

ExceptionHandlingMessageProcessor 、 InboundEndpointMimeTypeCheckingMessageProcessor 、

InboundEndpointPropertyMessageProcessor 、 InboundLoggingMessageProcessor 等 MessageProcessor 。

(2)在 MessageProcessorChain 中，通过 DynamicWsdlProxyRequestProcessor 重写 WSDL 访问地址，即将 proxy WSDL 地址重新为

remote WSDL 地址。

(3)在 DefaultOutboundEndpoint 中，主要通过 HttpClientMessageDispatcher 调用 HttpClient 发送和接收 SOAP 消息。

四、实例分析

1、实例场景

通过 Mule 的 WSProxy 实现天气预报查询。 http://www.webxml.com.cn 提供了常用的 WebService ，比如国内手机号码归属地查询、城

市天气预报查询以及 股票行情数据 查询的 WebService 。

本实例中通过 http://webservice.webxml.com.cn/WebServices/WeatherWS.asmx 查询北京的天气预报 ( 北京的代码号是 792) 。

Mule 通过 http://localhost:8080 为客户端提供访问地址，负责接收发送到该 URL 上的 SOAP 请求消息，并转发到天气预报查询的

WebService 上，最好将 SOAP 响应消息转发给客户端。

本实例中，我们使用 SoupUI 作为客户端访问 Mule 。

proxy URL: http://localhost:8080
remote URL: http://webservice.webxml.com.cn/WebServices/WeatherWS.asmx

2、Mule的配置文件

ws:proxy简化了Mule的配置文件，只需要配置两个基本属性 inboundAddress和 outboundAddress，当然还可以配置接收线程池和分

发线程池。

本实例中的基本配置文件：

<ws:proxy name="muleWsProxy" inboundAddress="http://localhost:8080"

outboundAddress="http://webservice.webxml.com.cn/WebServices/WeatherWS.asmx"/>

inboundAddress ：是提供给客户端访问的 URL ，是 proxy 地址。

outboundAddress: 是天气查询服务的 URL, 是 remote 地址。

3、运行结果

通过SoupUI将查询北京天气的SOAP消息发送到Mule的proxy地址（http://localhost:8080）上，通过Mule的WebService Proxy机制

处理后，返回天气查询结果。

五、 WSProxy 实现机制的优点和弊端

1、优点：

(1) 基于模式的配置 (pattern-based configuration) 简化了 mule 的配置文件。

(2) Mule3.0 采用了 pipe-filter 的架构，通过 MessageProcessor 对 MuleEvent 进行处理，架构更加

清晰和轻量级。

2、弊端：

(1)HTTP 的实现不支持 NIO 。虽然在 http 的 inbound 和 outbound 上可以分别配置接收线程池（ receiverThreadingProfile）和分发线

程池（ dispatcherThreadingProfile ），但仍然采用每请求每线程的模式处理 HTTP 消息，不能极大程度地提高 Mule 的吞吐量。目前也

没有看到 Mule 要将 HTTP 的实现基于 MINA 或者 NETTY 的计划，只能希望在不久的将来可以提供基于 NIO 的 HTTP 实现。

(2) 采用大量的 MessageProcessorChain 。在 DefaultInbound 和 DefaultOutbound 上都采用了 MessageProcessorChain ，每个

MessageProcessorChain 中包括数个 MessageProcessor ，这无疑增加了处理 MuleEvent 的链路长度。如果能以配置的方式屏蔽这些

MessageProcessor ，那么可以根据实际情况启用必要的 MessageProcessor 。