基于SOA的系统开发越来越成为了分布式系统开发的提纲，在系统继承平台项目中，我们也很好的实现了这一理念。在这个项目中，各个系统之间的交互主要依赖的是webservice，由其是基础系统为考试系统，评教系统提供数据支持的情况，并且随着业务的不断扩展，我们将提供越来越多的webservice，在这种情况下如果依然让各个系统之间持有webservice的wsdl以此访问webservice在后期会造成严重的维护问题，并且考虑到继承以前遗留的异构系统我们最终选择了使用ESB来成立一个webservice管理中心，所有webservice都在ESB管理中心进行注册，而所有的客户端所持有的都是ESB对外发布的统一接口，这样通过将webservice的服务端与客户端解耦，大大提高了维护效率。ESB为我们带来的最明显好处是当我们的webservice的wsdl的地址发生改变的时候我们不用再费力的在各个调用该webservice的客户端修改其持有的wsdl，而只需要在ESB的管理中心更改一处就可以达到目的。下面我就来介绍一下ESB通过webservice代理实现系统集成的功能。
首先新建一个Mule Project，然后打开flows文件夹下的.mflow文件，这个文件的配置有两种方式，既可以通过拖拽的方式进行流程控制，也可以直接在xml中进行配置。并且ESB发布webservice的方式也并非一种，这里我们选用一种最简单的方式。来看该文件的核心配置：
<?xml version="1.0" encoding="UTF-8"?>
<pattern:web-service-proxy
name="weather-forecast-ws-proxy"
inboundAddress="http://localhost:8082/WSServiceService"
outboundAddress="http://localhost:8080/YCHWebServiceServer/changshou"
wsdlLocation="http://localhost:8080/YCHWebServiceServer/changshou?wsdl"
/>
</mule>
上面这种方式是最简单的webservice代理的发布方式，其中inboundAddress就是esb发布的代理端口，outblundAddress是我们实际发布的webservice地址，然后以mule application方式启动这个mule工程，在浏览器中输入outboundAddress地址回车，然后在新窗口输入esb的代理地址，如果这二者都能成功访问webservice则说明我们的发布的esb代理成功。这里的发布webservice方式我完全用的是在之前的博客《CXF
WebService实战》中的webservice，测试客户端也同样是该篇文章中的测试客户端，本文中测试代码就不再赘述，通过测试无论我们在客户端持有的真正的webservice地址还是还是esb的webservice代理地址都能成功完成webservice的调用，这样我们就实现了通过esb代理来实现系统集成的功能。