remoting架构探讨二：remoting和webservice选型比较

(文/金延涛)

易用性比较

　　Remoting和Webservice配置部署起来都非常方便，remoting也可以以web服务的方式进行部署，但是这种部署方式相对Webservice来说也只是增加了部署的复杂度，没有什么实际的意义。比较Remoting和webService的易用性，首先我们假设一个前提，无论采用哪种技术都需要获得良好的互操作性和性能，并且不需要增加太大的额外成本，众所周知，remoting具有非常好的可扩展特性和可插入特性，如果花费无限的精力和成本的话，我相信remoting一定能够得取非常好的效果，所以假设在remoting预置内容的基础上进行设计。为了得到较好的互操作性，remoting适宜http通道进行传输，http通道默认使用soap协议。我们从开发、部署和维护上做一个简单比较。

 

　　开发。通常的做法是remoting会定义IDL，分别被服务端和客户端引用，通道组件会自动完成对象的序列化和反序列化处理，并且可以根据需要在服务端或者在客户端保存对象的状态。WebService被引用之后，Web服务内引用的对象会被自动转换，客户端需要做一些繁琐的处理之后才能调用。remoting和Webservice都需要做一些特殊的处理才能调试（比如通过配置的方式，配置为本地调试或者发布等）。相对而言，remoting的开发会更简单方便一些，而且可以满足更多的需求。

　　部署和维护。webservice和remoting的部署和维护都非常方便，webservice的部署依赖于IIS，remoting可以以APP或winservice的方式在服务器上运行，但是remoing的维护可能需要暂停remoting服务端。

扩展性比较

　　相对而言，remoting具有非常好的可扩展特性，在remoting基础结构的每个组件上都可以插入自定义的特性，因此remoting可以满足更丰富的应用。webservice灵活易用，结构简单。

性能比较

　　比较remoting和webservice的效率之后有些出乎意料，本人做了一个测试，remoting和webservice分别测试10次以上，remoting采用http通道，服务端、singleton方式，客户端请求服务端的一个方法，该方法非常简单，方法返回一个对象数组，数组长度为50000，放在公司网络环境下测试，客户端执行时间大概在15000毫秒左右，同样的方法和返回值如果使用web服务，客户端的执行时间只需要1500毫秒左右。如果采用soap协议进行序列化，webservice相对remoting来说可能更具优势。

简要总结

　　remoting可以满足丰富的应用，即使使用http通道进行传输，如果对性能没有太高要求的话，仍然建议使用remoting进行设计；webservice简单易用，方便灵活，在很多场景下也可以采纳。

remoting和webservice存在的问题

　　默认情况下remoting和webservice都存在list传输的问题。

本人根据对remoting和webservice的一些项目经验进行简要总结，比较简单，请各位tx多提意见！