基于Http替补新闻WebService数据交换

该系统的工作之间的相互作用。随着信息化建设的发展，而业界SOA了解并带来低TOC（总拥有成本）其他优势。越来越多的高层次的信息使用者关注。

这里暂且不提SOA这种架构规划。在系统间集成协议简单的讨论。

或成为系统之间的集成互动（互联），信息化系统诞生的时候，就已经出现，仅仅是并不明显，或者因为早期开发平台、开发语言等的单一性。这样的需求并没有很大的爆发出来。

随着信息化建设的发展。以及各种不同的开发语言的发展，跨语言的不同业务系统之间的交互，成为了摆在CIO们面前的一个大问题。

早期。为了保证数据或者消息在不同的业务系统间传递的安全、有效、稳定，往往使用基于MQ的Message进行消息传递。这期间IBM的MQ产品，成为跨业务系统信息交互的重要媒介。

可是，使用MQ的前提是。MQ已经提供了针对特定开发语言的API包。如MQ没有提供。则无法使用。

而且，MQ产品本身作为一个商业产品，其成本也是很高的。因为MQ支持XA事务。因此。其数据传递的有效性还是可以得到保障的。

后来。人们開始探讨使用基于RDBMS的“前置机”方式。

即须要交互的两方，使用一个脱离于各自业务系统的“中间数据库”，将须要读写的数据，读写入中间数据库。再进行兴许的操作。

使用RDBMS的长处是，直接利用关系型数据库这样的支持事务的平台，而且关系型数据库相同支持XA事务。保证数据在不同数据库之间传递的有效性。缺点是须要额外处理一套专门的中间表或者中间数据库。而且有时并不能解决所有的问题。而且，当须要交互的系统超过3个时。每一个系统都须要处理多于1个中间表体系。对系统厂商造成大量的工作。

WebService以前觉得是解决异构系统间整合的最佳解决方式。不依赖于第三方不论什么系统的支持（不须要额外部署专门的MQ或者RDBMSserver），大家仅仅须要依照官方的规范。就可以完毕相互之间的数据交互。

可是，webService存在的问题是，使用SOAP须要对消息进行多层次的封装，webservice之间进行数据交互的效率受到了严重的影响。

尽管，webservice可以交互的数据格式多种多样，基本也不存在数据格式不支持的情况。

可是，webservice的效率及其webservice的超时等问题。还是困扰了系统厂商。

随着httpclient的出现，以及JSON等数据格式的大范围使用。基于http的消息接口，逐渐被大家所青睐。

一方面是因为。直接使用httpclient可以模拟浏览器的数据操作与封装；还有一方面使用基于http的消息。可以借助于http的成熟、可靠、开源的web集群解决方式来提升整体的效率。

还有，就是基于http的消息格式，差点儿不受不论什么限制，常规应用的各种消息格式。基本都能直接使用基于http的消息进行传递。

眼下，大部分PaaS平台，所提供的API接口。实际上就是使用基于Http的JSON消息，来进行数据传递的。

针对基于http的消息及WebService的性能问题，笔者以前做过測试。

在一台配置较低的PC上。同一时候开启服务端与客户端，10000条数据。使用基于http的消息逐条进行传递，从開始传递至所有接收并处理完毕，大概须要465秒的时间；而在同一台机器上。使用WebService进行交互，则须要1180秒。整体的性能大概查了接近60%。

因此。笔者大胆推測。未来随着基于http进行消息传递的技术逐步完好，以及相关业界标准的进一步完好，新http消息格式将逐渐取代webservice，主流。