淺談Web異步服務調用的分析試用(一)

淺談Web異步服務調用的分析試用

一、項目概述

（一）研究背景

現代企業面臨的環境變得越來越復雜，他們的大多數信息系統都是多平臺和多系統的復雜環境。這就要求公司的解決方案具有廣泛的兼容能力，并且可以支持不同的系統平臺和多種連接方法，使數據格式實現系統的松散耦合。

（二）研究目標和意義

本文的目標是在支持Web服務/ HTTP模型的同步調用的所有環境中實現簡單方便的AIM接口，它支持Web服務/ HTTP模式性同步調用，這一點的重要性在于改進Web服務/ HTTP，作為一個整體的異步服務呼叫系統：

1.使用AIM實現客戶端和服務器之間的并行計算。客戶端向服務器發送服務請求后，您可以繼續進行后續的任務處理，當服務器收到服務請求時，它會計算服務請求。此時，客戶端和服務器處于全并行計算狀態，提高了系統的整體處理能力和資源利用率。

2.客戶端可以同時提交多個服務請求，縮短多個服務請求的總等待時間，提高任務的并發度。當客戶端向另一個服務器發送異步請求時，多個服務器可以執行并行計算，這可以提高多個任務的并發性。

3.充分利用網絡帶寬資源。由于客戶端可以同時向服務器發送請求，所以網絡帶寬資源比SIM更充分地利用。Web服務/ HTTP AIM實現是進一步擴展和深化Web服務在SOA的動態電子商務和企業應用程序集成中的應用的基礎。

二、Web Service服務調用現狀

盡管基本的通信協議不能在Web服務架構標準下運行，但HTTP被廣泛用作標準通信協議，但它也具有通過防火墻的優勢（對于B2B應用尤其如此這很重要）。因此，在Web服務的實際應用中，在大多數情況下，HTTP被用作基本的傳輸通信協議。因此，本文重點介紹基于HTTP的Web服務服務。

（一）Web服務調用過程

圖2-1顯示了Web服務/ HTTP服務提供者和服務請求者之間的服務調用過程（圖中省略了查詢服務注冊中心以獲取服務的WSDL的過程）。

圖2-1：Web Services/HTTP的服務調用過程

首先，服務請求者以SOAP消息的形式通過HTTP網絡協議向HTTP服務器發送服務請求（包括服務提供者的地址、服務名稱和相應的參數等）。接下來，在HTTP服務器偵聽并解釋HTTP消息之后，將SOAP請求傳遞給SOAP引擎，并且SOAP引擎調用相應服務提供者實現的特定服務。最后，SOAP引擎收到服務提供者返回的計算結果后，將其編碼成一個包含SOAP響應的HTTP消息并傳遞給它，HTTP服務器通過HTTP服務器返回到SOAP客戶端。SOAP客戶端從HTTP響應消息中獲取SOAP響應，解碼請求的結果并將其返回給服務請求者。

（二）缺少現有的Web服務調用模型

目前，Web服務提供了單向模型和同步請求/響應調用模型，但實際使用異步通信模型的ACM異步通信模型是不可避免的。客戶需要長期計算和需要等待的服務，即使需要人為干預，同步請求/響應模型顯然不足以滿足需求。在基本上由兩個不同層次組成的異步通信模型的情況下，異步通信模型：針對異步呼叫模型的基于媒體/事件服務MES的低層和上層中間件。前者不需要持久存儲和消息轉發，易于實現，易于使用，性能良好，但控制功能相對簡單。后者使存儲轉發機制變得復雜而且糟糕，但它可以被使用。中間件提供了滿足各種復雜需求的各種消息控制策略。

考慮一個典型的B2B電子商務場景：兩個電子商務合作伙伴A和B還包括B及其電子商務應用自動化系統，每個電子商務應用自動化系統都向多個合作伙伴發送電子訂單雖然有必要，但它可以提供一個調用模型現有的Web服務（即B可以發送一個合作伙伴的請求并發送處理結果），B同步請求您可以發送請求來訂購這些合作伙伴。如果每個合作伙伴的訂單處理系統的響應時間足夠快，這個請求 - 需求模型基本上是可以接受的。然而，即使某些響應（專有原因或網絡緩慢）這些電子訂單處理系統也需要人工干預（如批準等），仍然只有一個正如合作伙伴所要求的那樣，整個過程將非常長，因此A處理一系列訂單所需的時間幾乎是不可接受的。在這種情況下，AIM可以解決這個問題：A，在下一個請求發送到訂單總等待時間單訂單處理之前，而不是等待請求返回結果，您可以將請求發送給多個合作伙伴。最長處理時間不是所有訂單處理時間的總和，A在等待期間不需要阻塞，您可以繼續處理其他服務。

三、Web Services的異步調用模型

Web服務的現有AIM沒有統一的標準和實現，并且一些現有的AIM實現也有其不足之處，特別是對于最常用的基于HTTP的Web服務，AIM仍然沒有完整的設計和實現系統，以下描述了現有Web服務的各種AIM實施方案。

（一）基于JAXM的實現