这一次，我们需要跨平台通用远程调用框架的神话么？

这一次，我们需要跨平台通用远程调用框架的神话么？

事情起因是开发各方讨论系统中的两种接口

接口基本需求：1、用户数据的同步接口 2、业务接口，包含客户端对服务器端的控制接口和服务器端对客户端的实时状态汇报接口。

接口非功能性需求：跨平台，第二类接口中客户端可能在企业内网，要求穿越防火墙、NAT、并且可能没有外部IP。

拿到这样的一个需求，HTTP基本的通信协议基本是必选，对上层应用协议，大家首先想到的都是SOAP。于是有了下面的解决方案：

1、 对第一类接口定义了SOAP接口，并对用户属性的变化进行了预计设计。接口类似如下update(propertyList list)，propertyList定义为KEY/Value的值对。好处如下是客户端和服务器端与服务器端之间只保存一个WSDL文件，在用户数据发生变化的时候，该接口不用发生变化。

2、 第二类接口不能直接使用SOAP，并且服务器端到客户端的状态推送需要使用HTTP推的技术。有人提出了定义一个XML SCHEMA，该SCHEMA描述的接口如FuncName（param1,param2,param3……）来作为第二类接口，好处是：任何业务相关的控制状态信息都可以通过该接口通信，客户端与服务器端之间只维护一份XML SCHEMA

上述方案中，第一类接口和第二类接口是类似的思路，都是定义一个通用的远程调用函数接口，并且从远程调用的角度去分析其优缺点。在这些冠冕堂皇的优点后面大家都甘之如饴，以为跨平台通用远程调用框架发挥了化腐朽为神奇的作用。然而恕我直言，消息传输就是消息传输，面向消息的通信方式可以解决的问题，完全没有必要扯上远程过程调用，在上述的场合直接的HTTP+业务数据已经可以很简洁的解决问题。由于第二类接口中打算自造轮子实现通用远程调用框架，和用SOAP实现没有本质的区别，归作一类进行分析：

1、 如果把HTTP+XML业务消息的通信方式描述成函数Post（XML DATA），update(propertyList list)这种接口和Post（XML DATA）一样都具有下面的特性：

a)接口也很稳定

通用的通信协议原本就具有通用远程过程调用接口梦寐以求的特性。

2、 通用远程调用框架下的通信消息的消息结构可以是HTTP+基于XML通用远程调用层+业务消息的结构。比起HTTP+XML的通信方式多了一个基于XML通用远程调用层，这层的实现可以使用SOAP类库，但是由于定义成通用的SOAP接口并只有一个WSDL文件，消息只能分发到一个函数入口，虽然添加了庞大的SOAP处理引擎，但无法利用现成的SOAP类库将请求分发到后端的各个不同业务处理函数，因此这种模式下仍然必须手工实现对消息的分发。而在HTTP+XML的方式中，也需要分发机制，然而却简洁很多。可以说，由于平白无故增加了基于XML通用远程调用层增加了性能消耗和处理复杂度，无比辛苦的把XML消息映射成具体平台相关的数据结构（这个映射耗费性能并且带来互操作性的问题）之后，还是需要做消息的分发，起点并没有比HTTP+XML高。 

3、 一个WSDL文件能够适应所有情况的“银弹”。

WSDL文件本意是定义客户端与服务器端的消息约束文件。换成了通用的WSDL文件之后，WSDL文件无法告知服务器端能接收什么样的消息。例如update(propertyList list)，propertyList定义为KEY/Value的值对。这种接口客户端看了WSDL文件其实还是不知道服务器端能接收什么样的消息，它能接收什么的KEY NAME？每个KEY对应的Value是什么类型的数据？这一部分的信息接口完全没有涉及。因此仍然需要一个约束的文档描述具体的业务消息约束，在非通用的远程过程调用的场合，这个业务消息约束是WSDL，在HTTP+XML通信中，则可以定义成普通的XMLSCHEMA。

面向操作的开发模式中WSDL和具体语言的具体操作接口绑死，导致修改WSDL需要重新使用工具导出具体语言的接口。这个是SOAP实现的远程过程调用本身带来的问题，面向消息的处理机制中则从来没有这方面的问题。

4、 其他优缺点比较a) 通用远程过程调用通信框架如果用SOAP实现则引入SOAP在不同平台下的互操作性的问题。为了最大限度的避免互操作性的问题，必须遵守WebService Base Profile 1.x系列标准，但是仍然不是彻底解决SOAP的互操作性问题。

b) 通用远程过程调用通信框架如果用SOAP实现则通信协议实际上是绑死了HTTP。上述第一类接口其实含有一个隐含的架构需求，数据的批量处理，和减少服务器之间的连接数。HTTP+XML业务数据的通信方式其实很容易移植到UDP+XML业务数据、TCP+XML业务数据和FTP+XML业务数据文件等批量数据快捷处理方式。SOAP协议虽然号称设计上预计在不同传输协议上传输，应用上却没有见过其他协议上成功应用。

c) HTTP+XML业务消息模式中XML处理实现上可以更灵活，XML数据处理可以使用通用的XML引擎，也可以在每个业务方法中使用XML PULL机制加速XML数据处理速度，XML PULL 资料可以参见http://www.extreme.indiana.edu/xgws/xsoap/xpp/mxp1/。

d)HTTP+XML业务消息中可以多个XML业务消息放到同一个HTTP请求中，减少连接数和通信量，而在通用的WSDL方案中，多个数据放到同一个HTTP消息中则导致一个庞大的XML消息，庞大的XML消息处理在还原成内存中的数据结构的时候很可能有占用太大的缓存的问题。