該系統的工作之間的相互作用。隨著信息化建設的發展，而業界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，主流。

版權聲明：本文博主原創文章，博客，未經同意不得轉載。

總結

以上是生活随笔為你收集整理的基于Http替补新闻WebService数据交换的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。