几种RPC模型的使用与比较(3)

调用:

ApplicationContext context = new ClassPathXmlApplicationContext("classpath:applicationContext.xml"); HessianService service = (HessianService)context.getBean("myHessianClient"); System.out.println(service.justHadEnoughParties());

console输出:

对于Burlap，几乎与Hessian的配置没什么区别；
只需要把HessianServiceExporter改为BurlapServiceExporter,
并将HessianProxyFactoryBean改为BurlapProxyFactoryBean即可。

RMI使用Java的序列化，而Hessian/Burlap则为了不同语言之间通信而使用私有的序列化。
如果我需要基于HTTP，但我并不需要多语言支持，我只想用Java...

HttpInvoker

我应该说这是基于Http的RMI吗?
虽然看起来两全其美，但也存在让人"遗憾"的地方，
(事实上不怎么遗憾的说，我曾经做过没有Spring的项目，连持久层框架都是自己实现，做得越久越痛苦...)
他没有所谓"原生"的实现，他是Spring的一部分，只能在Spring应用中使用。

Spring为这些RPC通信模型提供的相关类在命名上都有一致，都是:

服务端:*ServiceExporter

客户端:*ProxyFactoryBean

自然地，HttpInvoker将用到

org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter

org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean

基于HttpInvoker的服务也像Hessian那样由DispatcherServlet进行分发。
鉴于很多相同的地方，我打算继续使用在上一篇中用Hessian通信的接口和实现类。

我几乎不用做任何工作，URL映射也不需要修改，我只需要将服务端的配置修改一下:

<bean id="myHessianServiceImpl" class="pac.king.common.rpc.impl.MyHessianServiceImpl" /> <!-- <bean p:service-ref="myHessianServiceImpl" p:serviceInterface="pac.king.common.rpc.MyHessianService" /> --> <bean id="myHessianService" class="org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter" p:service-ref="myHessianServiceImpl" p:serviceInterface="pac.king.common.rpc.MyHessianService" />

相应地，客户端也只需要修改一下class:

<!-- <bean p:serviceUrl="http://localhost:8080/runtrain/service" p:serviceInterface="pac.test.HessianService" /> --> <bean id="myHessianClient" class="org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean" p:serviceUrl="http://localhost:8080/runtrain/service" p:serviceInterface="pac.test.HessianService" />

这样就保证了效率又解决了防火墙的问题，
后来我听有人说，他们用Hessian做跨语言通信时，基于Http这个特征并不能解决防火墙的问题。
不知道他们具体情况如何，似乎没说到一块儿...

看了Hessian之后突然感觉Web service这种东西好笨重啊(虽然也有一些方法可以克服部分问题)。
既然有Hessian，那为什么还要用Web service这种东西呢?
我突然开始怀疑起他存在的意义。
搜了一下，结果都是比较RPC通信模型的效率，没有人说他们为什么还要用(都应该有存在的意义吧)...
如果仅仅是效率的话都用Hessian不就得了？
带着这个问题我逛了逛stackoverflow，然后我得到了下面几种答案。

多数人手中拿着锤子的时候，他们倾向于将所有问题都当作钉子，他们通常不会试着去寻找别的工具。导致Web service泛滥的原因也是这个。

我觉得你应该重新看看Web service的优势(结果有人说了跨语言和SOA...果然关键还是相对什么做比较...)

Web service比那些non-xml的通信方式慢？这种相对的速度问题更多的取决于业务需求和你自己的代码实现(这个说法也同样适用于反射)。

最后我还是没有得到让我满意的答案，倒是复习了Web service...
很多类似场景下人们都将Web service视为"standard"option。 既然如此...那就看看Web service吧。

JAX-WS

看来使用web service是不可避免的。
我曾对这个有些抵触，因为他给我印象总是麻烦+慢(后来虽然方便了许多，但还是很慢)。
然后再去搜索"advantages of web service"什么的试着再让自己接受他。
简单记录一下如何用Spring导出Endpoint。