閱讀287 返回首頁    go 阿裏雲 go 技術社區[雲棲]


WCF如何克服HTTP傳輸協議的局限提供對不同消息傳輸模式的實現

WCF采用消息作為通信的唯一手段,它支持不同的消息交換模式(MEP:Message Exchange Pattern),比較典型的有以下三種MEP:One-Way、Request/Reply和Duplex。消息會被WCF的信道層發送到傳輸層,並通過相應的傳輸協議發送到目的地。對於TCP協議來說,其本身就能提供一個雙工通道,所以能夠對以上三種MEP原生的支持。而HTTP協議,大家都知道它天生就基於Request/Reply模式的,那麼它是如何能夠突破自己的局限,為One-Way和Duplex消息交換模式提供支持呢?

一、HTTP如何實現One-Way消息交換模式?

image One-Way模式是最簡單的消息交換模式,又稱為發送/遺忘(Send/Forget)或者數據報模式(Datagram)。One-Way模式基於從一個源到一個或者多個目的地的單向消息傳輸。如右圖所示,在One-Way模式下,消息的發送方將消息發送到接收方,並不希望收到對象的回複。數據報模式具有一些變型,比較典型的包括以下一些消息交換的方式: 單目的地模式(一個消息的發送方將消息發送給單一的接收方)、多投模式(一個消息發送方將消息發送給一係列預定義的接收方)和廣播模式(和多投模式相似,隻是接收方的範圍更加寬泛)。One-Way模式一般采用異步的消息發送方式,並不希望接收到對方的回複消息,在個別情況下甚至不關心消息能否正常地被接收。

image

但是,關於HTTP有一點必須有一個清醒的認識,那就是HTTP隻能采用Request/Reply模式進行工作,這是由其協議本身的實現決定的。那麼,當我們采用基於HTTP的綁定(BasicHttpBinding、WSHttpBinding和WS2007HttpBinding等)調用One-Way服務操作的時候,傳輸層(HTTP Transport)是如何工作的呢?實際上很簡單:客戶端照常向服務端發送基於SOAP的HTTP Request,服務端在接收到清之後,會返回一個狀態為202(表示成功請求成功接受)的空HTTP Response。整個請求回複過程如左圖所示。

實際上我們可以利用一些消息攔截工具,截獲客戶端和服務端往來的消息來分析它們之間真正采用的消息交換方式,在這裏我們采用的是Fiddler這麼一個廣受大家喜愛的HTTP Debug Proxy。現在,我們需要通過Fiddler探測進行基於One-way服務操作調用采用的消息交換方式,假設服務契約定義如下:

using System.ServiceModel;
namespace Artech.MessageInspection.Sender
{
    [ServiceContract(Namespace="https://www.artech.com/")]
    interface ICalculator
    {
        [OperationContract(IsOneWay = true)]
        void Add(double x, double y);
    }
}

服務實現、服務寄宿和服務調用的相關代碼我們就省了。現在,客戶端通過創建的服務代理,簡單地調用Add(1,2)這麼一個簡單的服務操作。下圖反映了Fiddler對該過程進行攔截得到的截圖,可以看到整個過程還是經典的Request/Reply方法,而回複的是一個空的HttpResponse。下麵是整個HttpResponse的內容:

HTTP/1.1 202 Accepted
Content-Length: 0
Server: Microsoft-HTTPAPI/2.0
Date: Tue, 20 Apr 2010 14:31:36 GMT

image

二、 HTTP如何實現Duplex消息交換模式?

image 如果采用Duplex的消息交換模式,在進行消息交換過程中,任何一方都可以向對方發送消息,如右圖所示。雙工通信使服務端回調客戶端操作成為可能。比較典型Duplex通信是我們熟悉的訂閱/發布模式。訂閱/發布模式下的消息交換雙方的角色從傳統的發送方和接收方變成了訂閱方和發布方。訂閱方向發布方發送訂閱消息定於某一主題進行訂閱,發布方接收到訂閱消息後將訂閱方添加到訂閱列表之中。主題發布的時候,發布方提取當前主題的所有訂閱方,對它們進行消息廣播。

image消息的交換依賴於網絡傳遞,不同的網絡傳輸協議對雙工通信具有不同的支持方式。對於TCP協議來說,其協議本身就是全雙工的網絡通信協議,所以能夠提供雙工通信原生的支持。但是對於HTTP來說,它本身就是簡單的基於請求/回複的網絡協議,是不支持雙工通信的。WCF通過WsDualHttpBinding實現了基於HTTP協議的雙工通信,實際上是采用了兩個HTTP通道實現的。 Duplex消息交換模式實際上是由兩個簡單模式(One-Way或者Request/Reply)組合而成的。WCF通過雙工通信實現了服務端對客戶端的回調。假設客戶端采用One-way的方式調用服務,而服務端同樣以One-Way的方式對客戶端進行回調。在這個過程中,正常的服務調用和回調實現上是在不同的HTTP通道中進行的。從消息交換的角度講,客戶端調用服務端和服務端對客戶端進行回調,本質上是一樣的。所以,從HTTP傳輸層看,真正的消息交換方式如左圖所示。如果同樣采用Fiddler這樣的工具,你會看到對於服務的正常調用是一個HttpRequest/HttpREsponse(Status:202),回調也對應著一個HttpRequest/HttpREsponse(Status:202),隻是兩者的方向相反而已。


作者:蔣金楠
微信公眾賬號:大內老A
微博:www.weibo.com/artech
如果你想及時得到個人撰寫文章以及著作的消息推送,或者想看看個人推薦的技術資料,可以掃描左邊二維碼(或者長按識別二維碼)關注個人公眾號(原來公眾帳號蔣金楠的自媒體將會停用)。
本文版權歸作者和博客園共有,歡迎轉載,但未經作者同意必須保留此段聲明,且在文章頁麵明顯位置給出原文連接,否則保留追究法律責任的權利。
原文鏈接

最後更新:2017-10-27 15:04:28

  上一篇:go  使命必達: 深入剖析WCF的可靠會話[概念篇]
  下一篇:go  使命必達: 深入剖析WCF的可靠會話[協議篇](下)