Reliable Messaging Protocol 1.1 版
本主題說明使用 HTTP 傳輸進行交互操作時所需的 WS-ReliableMessaging February 2007 (1.1 版) 通訊協定的 Windows Communication Foundation (WCF) 實作詳細資料。 WCF 遵循 WS-ReliableMessaging 規範以及本主題所說明的條件約束和聲明。 請注意,WS-ReliableMessaging 1.1 版通訊協定從 .NET Framework 3.5 開始實作。
WS-ReliableMessaging February 2007 通訊協定可透過 ReliableSessionBindingElement 在 WCF 中實作。
為了方便起見,本主題將使用下列角色:
啟動器:啟動 WS-Reliable 訊息序列建立作業的用戶端。
回應程式:接收啟動器要求的服務。
本文件會使用下表的前置詞和命名空間。
Prefix | Namespace |
---|---|
wsrm | http://docs.oasis-open.org/ws-rx/wsrm/200702 |
netrm | http://schemas.microsoft.com/ws/2006/05/rm |
s | http://www.w3.org/2003/05/soap-envelope |
wsa | http://schemas.xmlsoap.org/ws/2005/08/addressing |
wsse | http://docs.oasis-open.org/wss/2004/01/oasis-200401-wssecurity-secext-1.0.xsd |
wsrmp | http://docs.oasis-open.org/ws-rx/wsrmp/200702 |
netrmp | http://schemas.microsoft.com/ws-rx/wsrmp/200702 |
wsp | (WS-Policy 1.2 或 WS-Policy 1.5) |
傳訊
建立序列
WCF 會實作 CreateSequence
和 CreateSequenceResponse
訊息以建立可信賴傳訊序列。 適用下列限制:
B1101:WCF 起始端會使用與
CreateSequence
訊息的ReplyTo
、AcksTo
和Offer/Endpoint
相同的端點參考。R1102:
AcksTo
訊息中的ReplyTo
、Offer/Endpoint
和CreateSequence
端點參照必須具有包含相同字串表示的位址值以符合八位元規格。- WCF 回應端在建立序列之前,會先確認
AcksTo
、ReplyTo
和Endpoint
端點參考的 URI 部分均相同。
- WCF 回應端在建立序列之前,會先確認
R1103:
AcksTo
訊息中的ReplyTo
、Offer/Endpoint
和CreateSequence
端點參照應該具有相同的參照參數集合。- WCF 不會強制執行,但會假定
CreateSequence
上的AcksTo
、ReplyTo
和Offer/Endpoint
端點參考的參考參數均相同,並且將來自ReplyTo
端點參考的參考參數用於認可與反向序列訊息。
- WCF 不會強制執行,但會假定
B1104:WCF 起始端不會在
CreateSequence
訊息中產生選用的Expires
或Offer/Expires
元素。B1105:在存取
CreateSequence
訊息時,WCF 回應端會使用CreateSequence
元素中的Expires
值作為CreateSequenceResponse
元素中的Expires
值。 否則,WCF 回應端會讀取並忽略Expires
和Offer/Expires
值。B1106:在存取
CreateSequenceResponse
訊息時,WCF 起始端會讀取選用的Expires
值,但不會加以使用。B1107:WCF 起始端和回應端一律會在
CreateSequence/Offer
和CreateSequenceResponse
元素中產生選用的IncompleteSequenceBehavior
元素。B1108:WCF 只會使用
IncompleteSequenceBehavior
元素中的DiscardFollowingFirstGap
和NoDiscard
值。- WS-ReliableMessaging 會使用
Offer
機制來建立兩個反向關聯序列以形成工作階段。
- WS-ReliableMessaging 會使用
B1109:如果
CreateSequence
包含Offer
元素,單向 WCF 回應端會透過不含Accept
元素的CreateSequenceResponse
來回應,以拒絕提供的序列。B1110:如果可信賴傳訊回應端拒絕了提供的序列,則 WCF 起始端會將新建立的序列視為出錯。
B1111:如果
CreateSequence
不包含Offer
元素,雙向 WCF 回應端會透過CreateSequenceRefused
錯誤來回應以拒絕提供的序列。R1112:當兩個反向序列都是透過
Offer
機制建立時,[address]
端點參照之CreateSequenceResponse/Accept/AcksTo
屬性的每個位元組必須完全符合CreateSequence
訊息之目的 URI 的每個位元組。R1113:當兩個反向序列都是透過
Offer
機制建立時,從啟動器流向回應程式之雙邊序列上的所有訊息必須傳送至相同的端點參照。
WCF 會使用 WS-ReliableMessaging 在起始端與回應端之間建立可靠的工作階段。 WCF WS-ReliableMessaging 實作會針對單向、要求-回覆與全雙工訊息模式提供可靠的工作階段。 Offer
和 CreateSequence
上的 WS-ReliableMessaging CreateSequenceResponse
機制可讓您建立兩個相互關聯的反向序列,並提供適用於所有訊息端點的工作階段通訊協定。 由於 WCF 會針對此類工作階段提供安全性保證 (包括工作階段完整性的端對端保護),因此可以確保傳給同一方的訊息都會送達相同目的地。 這麼做也可以針對應用程式訊息進行 "piggy-backing" 的序列認可作業。 因此,WCF 適用條件約束 R1102、R1112 和 R1113。
CreateSequence
訊息的範例。
<s:Envelope>
<s:Header>
<wsa:Action s:mustUnderstand="1">http://docs.oasis-open.org/ws-rx/wsrm/200702/CreateSequence</wsa:Action>
<wsa:MessageID>urn:uuid:949cca61-8813-42ff-ab33-18d9e3fa82fa</wsa:MessageID>
<wsa:ReplyTo>
<wsa:Address>http://Business456.com/clientA</wsa:Address>
</wsa:ReplyTo>
<wsa:To s:mustUnderstand="1">http://BusinessABC.com/serviceA</wsa:To>
</s:Header>
<s:Body>
<wsrm:CreateSequence>
<wsrm:AcksTo>
<wsa:Address>http://Business456.com/clientA</wsa:Address>
</wsrm:AcksTo>
<wsrm:Offer>
<wsrm:Identifier>urn:uuid:066b4730-fc82-458a-a5c1-210be4fb4e4e</wsrm:Identifier>
<wsrm:Endpoint>
<wsa:Address>http://Business456.com/clientA</wsa:Address>
</wsrm:Endpoint>
<wsrm:IncompleteSequenceBehavior>DiscardFollowingFirstGap</wsrm:IncompleteSequenceBehavior>
</wsrm:Offer>
</wsrm:CreateSequence>
</s:Body>
</s:Envelope>
CreateSequenceResponse
訊息的範例。
<s:Envelope>
<s:Header>
<wsa:Action s:mustUnderstand="1">http://docs.oasis-open.org/ws-rx/wsrm/200702/CreateSequenceResponse</wsa:Action>
<wsa:RelatesTo>urn:uuid:949cca61-8813-42ff-ab33-18d9e3fa82fa</wsa:RelatesTo>
<wsa:To s:mustUnderstand="1">http://Business456.com/clientA</wsa:To>
</s:Header>
<s:Body>
<wsrm:CreateSequenceResponse>
<wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
<wsrm:IncompleteSequenceBehavior>DiscardFollowingFirstGap</wsrm:IncompleteSequenceBehavior>
<wsrm:Accept>
<wsrm:AcksTo>
<wsa:Address>http://BusinessABC.com/serviceA</wsa:Address>
</wsrm:AcksTo>
</wsrm:Accept>
</wsrm:CreateSequenceResponse>
</s:Body>
</s:Envelope>
關閉序列
WCF 會將 CloseSequence
和 CloseSequenceResponse
訊息用於可信賴傳訊來源啟始的關閉作業。 WCF 可信賴傳訊目的地不會啟始關閉作業,且 WCF 可信賴傳訊來源不支援可信賴傳訊目的地啟始的關閉作業。 適用下列限制:
B1201:WCF 可信賴傳訊來源一律會傳送
CloseSequence
訊息以關閉序列。B1202:可信賴傳訊來源會在傳送
CloseSequence
訊息之前,等候整個序列訊息的認可。B1203:可信賴傳訊來源一律包含選用的
LastMsgNumber
項目 (除非序列不包含訊息)。R1204:可信賴傳訊目的地不可以藉由傳送
CloseSequence
訊息來啟始關閉作業。B1205:在收到
CloseSequence
訊息時,WCF 可信賴傳訊來源會將序列視為不完整,並傳送錯誤。
CloseSequence
訊息的範例。
<s:Envelope>
<s:Header>
<wsa:Action s:mustUnderstand="1">http://docs.oasis-open.org/ws-rx/wsrm/200702/CloseSequence</wsa:Action>
<wsa:MessageID>urn:uuid:6ce1d4c3-e1c1-474f-a8c9-4210e37f7877</wsa:MessageID>
<wsa:ReplyTo>
<wsa:Address>http://Business456.com/clientA</wsa:Address>
</wsa:ReplyTo>
<wsa:To s:mustUnderstand="1">http://BusinessABC.com/serviceA</wsa:To>
</s:Header>
<s:Body>
<wsrm:CloseSequence>
<wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
<wsrm:LastMsgNumber>30</wsrm:LastMsgNumber>
</wsrm:CloseSequence>
</s:Body>
</s:Envelope>
範例 CloseSequenceResponse
訊息:
<s:Envelope>
<s:Header>
<wsrm:SequenceAcknowledgement>
<wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
<wsrm:AcknowledgementRange Lower="1" Upper="30"></wsrm:AcknowledgementRange>
<wsrm:Final></wsrm:Final>
<netrm:BufferRemaining>8</netrm:BufferRemaining>
</wsrm:SequenceAcknowledgement>
<wsa:Action s:mustUnderstand="1">http://docs.oasis-open.org/ws-rx/wsrm/200702/CloseSequenceResponse</wsa:Action>
<wsa:RelatesTo>urn:uuid:6ce1d4c3-e1c1-474f-a8c9-4210e37f7877</wsa:RelatesTo>
<wsa:To s:mustUnderstand="1">http://Business456.com/clientA</wsa:To>
</s:Header>
<s:Body>
<wsrm:CloseSequenceResponse>
<wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
</wsrm:CloseSequenceResponse>
</s:Body>
</s:Envelope>
終止序列
WCF 在完成 CloseSequence/CloseSequenceResponse
交握後主要會使用 TerminateSequence/TerminateSequenceResponse
交握。 WCF 可信賴傳訊目的地不會啟始終止作業,且可信賴傳訊來源不支援可信賴傳訊目的地啟始的終止作業。 適用下列限制:
B1301:WCF 起始端只有在成功完成
CloseSequence/CloseSequenceResponse
交握後,才傳送TerminateSequence
訊息。R1302:WCF 會針對指定的序列,驗證所有
CloseSequence
和TerminateSequence
訊息中的LastMsgNumber
元素是否一致。 也就是說,LastMsgNumber
不是不存在於所有CloseSequence
和TerminateSequence
訊息上,就是存在於所有CloseSequence
和TerminateSequence
訊息上而且全部一樣。B1303:在
TerminateSequence
交握之後收到CloseSequence/CloseSequenceResponse
訊息時,可信賴傳訊目的地會以TerminateSequenceResponse
訊息來回應。 由於可信賴傳訊來源在傳送TerminateSequence
訊息之前已經獲得最後的認可,因此可信賴傳訊目的地毫無疑問地知道序列已結束並立即回收資源。B1304:在
CloseSequence/CloseSequenceResponse
交握之前收到TerminateSequence
訊息時,WCF 可信賴傳訊目的地會以TerminateSequenceResponse
訊息來回應。 如果可信賴傳訊目的地判斷序列中沒有任何不一致的項目,則可信賴傳訊目的地會等候應用程式目的地指定的時間一到再回收資源,以便讓用戶端有機會接收最後的認可。 否則,可信賴傳訊目的地會立即回收資源並引發Faulted
事件以向應用程式目的地指出序列是在不確定的情況下結束。
TerminateSequence
訊息的範例。
<s:Envelope>
<s:Header>
<wsa:Action s:mustUnderstand="1">http://docs.oasis-open.org/ws-rx/wsrm/200702/TerminateSequence</wsa:Action>
<wsa:MessageID>urn:uuid:3597a398-4f3c-40f4-9335-8f1515572fdf</wsa:MessageID>
<wsa:ReplyTo>
<wsa:Address>http://Business456.com/clientA</wsa:Address>
</wsa:ReplyTo>
<wsa:To s:mustUnderstand="1">http://BusinessABC.com/serviceA</wsa:To>
</s:Header>
<s:Body>
<wsrm:TerminateSequence>
<wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
<wsrm:LastMsgNumber>30</wsrm:LastMsgNumber>
</wsrm:TerminateSequence>
</s:Body>
</s:Envelope>
範例 TerminateSequenceResponse
訊息:
<s:Envelope>
<s:Header>
<wsrm:SequenceAcknowledgement>
<wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
<wsrm:AcknowledgementRange Lower="1" Upper="30"></wsrm:AcknowledgementRange>
<wsrm:Final></wsrm:Final>
<netrm:BufferRemaining>8</netrm:BufferRemaining>
</wsrm:SequenceAcknowledgement>
<wsa:Action s:mustUnderstand="1">http://docs.oasis-open.org/ws-rx/wsrm/200702/TerminateSequenceResponse</wsa:Action>
<wsa:RelatesTo>urn:uuid:3597a398-4f3c-40f4-9335-8f1515572fdf</wsa:RelatesTo>
<wsa:To s:mustUnderstand="1">://Business456.com/clientA</wsa:To>
</s:Header>
<s:Body>
<wsrm:TerminateSequenceResponse>
<wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
</wsrm:TerminateSequenceResponse>
</s:Body>
</s:Envelope>
序列
下列清單列出適用於序列的條件約束:
- B1401:WCF 會產生並存取不超過
xs:long
的最大值 9223372036854775807 (含此值) 的序號。
Sequence
標頭的範例。
<wsrm:Sequence s:mustUnderstand="1">
<wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
<wsrm:MessageNumber>1</wsrm:MessageNumber>
</wsrm:Sequence>
要求認可
WCF 會使用 AckRequested
標頭作為 Keep-Alive 機制。
AckRequested
標頭的範例。
<wsrm:AckRequested>
<wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
</wsrm:AckRequested>
SequenceAcknowledgement
WCF 會對 WS-Reliable 訊息中提供的序列認可使用 "piggy-back" 機制。 適用下列限制:
R1601:當兩個反向序列透過
Offer
機制建立時,SequenceAcknowledgement
標頭可包含在任何傳輸至目的收件者的應用程式訊息中。 遠端端點必須能夠存取以 Piggyback 方式傳送的SequenceAcknowledgement
標頭。B1602:WCF 不會產生包含
Nack
元素的SequenceAcknowledgement
標頭。 WCF 會驗證每個Nack
元素是否都包含序號,若否則忽略Nack
元素與值。
SequenceAcknowledgement
標頭的範例。
<wsrm:SequenceAcknowledgement>
<wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
<wsrm:AcknowledgementRange Lower="1" Upper="1"></wsrm:AcknowledgementRange>
</wsrm:SequenceAcknowledgement>
WS-ReliableMessaging 錯誤
以下列出 WCF 實作 WS-ReliableMessaging 錯誤時適用的條件約束。 適用下列限制:
B1701:WCF 不會產生
MessageNumberRollover
錯誤。B1702:在 SOAP 1.2 中,當服務端點達到其連線限制,而且無法處理新的連線時,WCF 就會產生巢狀
CreateSequenceRefused
錯誤子代碼netrm:ConnectionLimitReached
,如下列範例所示。
<s:Envelope>
<s:Header>
<wsa:Action>http://docs.oasis-open.org/ws-rx/wsrm/200702/fault</wsa:Action>
</s:Header>
<s:Body>
<s:Fault>
<s:Code>
<s:Value>s:Receiver</s:Value>
<s:Subcode>
<s:Value>wsrm:CreateSequenceRefused</s:Value>
<s:Subcode>
<s:Value>netrm:ConnectionLimitReached</s:Value>
</s:Subcode>
</s:Subcode>
</s:Code>
<s:Reason>
<s:Text xml:lang="en">Server 'http://BusinessABC.com/serviceA' is too busy to process this request. Try again later.</s:Text>
</s:Reason>
</s:Fault>
</s:Body>
</s:Envelope>
WS-Addressing 錯誤
由於 WS-ReliableMessaging 使用 WS-Addressing,WCF WS-ReliableMessaging 實作可能會產生並傳輸 WS-Addressing 錯誤。 本節說明 WCF 明確產生,並在 WS-ReliableMessaging 層加以傳輸的 WS-Addressing 錯誤:
B1801:當下列任一情形發生時,WCF 就會產生並傳輸
Message Addressing Header Required
錯誤:CreateSequence
、CloseSequence
或TerminateSequence
訊息缺少MessageId
標頭。CreateSequence
、CloseSequence
或TerminateSequence
訊息缺少ReplyTo
標頭。CreateSequenceResponse
、CloseSequenceResponse
或TerminateSequenceResponse
訊息缺少RelatesTo
標頭。
B1802:WCF 會產生並傳輸
Endpoint Unavailable
錯誤,以指出沒有任何一個接聽中的端點可依據CreateSequence
訊息中的定址標頭檢查結果來處理序列。
通訊協定組合
與 WS-Addressing 組合
WCF 支援兩種版本的 WS-Addressing:WS-Addressing 2004/08 [WS-ADDR] 和 W3C WS-Addressing 1.0 建議 [WS-ADDR-CORE] 和 [WS-ADDR-SOAP]。
儘管 WS-ReliableMessaging 規格只提到 WS-Addressing 2004/08,它並未限制要使用的 WS-Addressing 版本。 以下列出適用於 WCF 的條件約束:
R2101:WS-Addressing 2004/08 和 WS-Addressing 1.0 皆可搭配 WS-Reliable 訊息一起使用。
R2102:單一版本的 WS-Addressing 必須透過
Offer
機制,用在整個特定的 WS-ReliableMessaging 序列或是一對相關聯的反向序列上。
與 SOAP 組合
WCF 支援將 SOAP 1.1 和 SOAP 1.2 搭配 WS-Reliable 訊息一起使用。
與 WS-Security 和 WS-SecureConversation 組合
WCF 可透過安全傳輸 (HTTPS)、與 WS-Security 組合,以及與 WS-Secure Conversation 組合,為 WS-ReliableMessaging 序列提供保護。 WS-ReliableMessaging 1.1 通訊協定、WS-Security 1.1 和 WS-Secure Conversation 1.3 通訊協定應該一併使用。 以下列出適用於 WCF 的條件約束:
R2301:除了保護個別訊息的完整性與機密性,為了兼顧 WS-ReliableMessaging 序列的完整性,WCF 要求必須使用 WS-Secure Conversation。
R2302:在建立 WS-ReliableMessaging 序列之前,必須先建立 AWS-Secure Conversation 工作階段。
R2303:如果 WS-ReliableMessaging 序列的存留期超過 WS-Secure Conversation 工作階段的存留期,則使用 WS-Secure Conversation 建立的
SecurityContextToken
必須透過對應的 WS-Secure Conversation 更新繫結來加以更新。B2304:WS-ReliableMessaging 序列或是一對相互關聯的反向序列一律繫結至單一 WS-SecureConversation 工作階段。
R2305:與 WS-Secure Conversation 組合時,WCF 回應端會要求
CreateSequence
訊息包含wsse:SecurityTokenReference
元素和wsrm:UsesSequenceSTR
標頭。
UsesSequenceSTR
標頭的範例。
<wsrm:UsesSequenceSTR></wsrm:UsesSequenceSTR>
與 SSL/TLS 組合
WCF 不支援與 SSL/TLS 工作階段組合:
B2401:WCF 不會產生
wsrm:UsesSequenceSSL
標頭。R2402:可信賴傳訊起始端不可將帶有
wsrm:UsesSequenceSSL
標頭的CreateSequence
訊息傳送至 WCF 回應端。
與 WS-Policy 組合
WCF 支援兩種版本的 WS-Policy:WS-Policy 1.2 和 WS-Policy 1.5。
WS-ReliableMessaging WS-Policy 判斷提示
WCF 使用 WS-ReliableMessaging WS-Policy 判斷提示 wsrm:RMAssertion
來說明端點功能。 以下列出適用於 WCF 的條件約束:
B3001:WCF 會將
wsrmn:RMAssertion
WS-Policy 判斷提示附加至wsdl:binding
元素。 WCF 支援附加至wsdl:binding
和wsdl:port
元素。B3002:WCF 一律不會產生
wsp:Optional
標記。B3003:存取
wsrmp:RMAssertion
WS-Policy 判斷提示時,WCF 會忽略wsp:Optional
標記,並將 WS-RM 原則視為必要原則。R3004:WCF 無法與 SSL/TLS 工作階段組合,因此 WCF 不會接受指定
wsrmp:SequenceTransportSecurity
的原則。B3005:WCF 一律會產生
wsrmp:DeliveryAssurance
元素。B3006:WCF 一律會指定
wsrmp:ExactlyOnce
傳遞保證。B3007:WCF 會產生並讀取 WS-ReliableMessaging 判斷提示的下列屬性,並在 WCF
ReliableSessionBindingElement
提供對這些屬性的控制:netrmp:InactivityTimeout
netrmp:AcknowledgementInterval
RMAssertion
的範例。<wsrmp:RMAssertion> <wsp:Policy> <wsrmp:SequenceSTR/> <wsrmp:DeliveryAssurance> <wsp:Policy> <wsrmp:ExactlyOnce/> <wsrmp:InOrder/> </wsp:Policy> </wsrmp:DeliveryAssurance> </wsp:Policy> <netrmp:InactivityTimeout Milliseconds="600000"/> <netrmp:AcknowledgementInterval Milliseconds="200"/> </wsrmp:RMAssertion>
WS-ReliableMessaging 延伸的流量控制
WCF 會透過 WS-ReliableMessaging 擴充性,選擇性地額外提供對序列訊息流程的進一步嚴格控制。
將 ReliableSessionBindingElement.FlowControlEnabled 屬性設定為 true
,即可啟用流程控制。 以下列出適用於 WCF 的條件約束:
B4001:可信賴傳訊流程控制啟用時,WCF 會在
SequenceAcknowledgement
標頭的元素擴充性中產生netrm:BufferRemaining
元素,如下列範例所示。<wsrm:SequenceAcknowledgement> <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier> <wsrm:AcknowledgementRange Upper="1" Lower="1"/> <netrm:BufferRemaining>8</netrm:BufferRemaining> </wsrm:SequenceAcknowledgement>
B4002:即使啟用了可信賴傳訊流程控制,WCF 也不需要
SequenceAcknowledgement
標頭中的netrm:BufferRemaining
元素。B4003:WCF 可信賴傳訊目的地會使用
netrm:BufferRemaining
來指出它能夠緩衝處理的新訊息數目。B4004:可信賴傳訊流程控制啟用時,WCF 可信賴傳訊來源就會使用
netrm:BufferRemaining
的值來調節訊息傳輸。B4005:WCF 會產生介於 0 到 4096 (含此二值) 之間的
netrm:BufferRemaining
整數值,並讀取介於 0 與xs:int
的maxInclusive
值 214748364 (含此值) 之間的整數值。
訊息交換模式
本節將說明 WCF 在不同訊息交換模式使用 WS-ReliableMessaging 時的行為。 在每個訊息交換模式中,會考慮下列兩種部署案例:
不可定址的啟動器:啟動器位於防火牆後方,回應程式只能透過 HTTP 回應將訊息傳送至啟動器。
可定址的啟動器:可將 HTTP 要求同時傳送給啟動器與回應程式,亦即可建立兩個反向 HTTP 連線。
單向、不可定址啟動器
繫結
WCF 透過在一個 HTTP 通道上使用一個序列的方式,提供單向的訊息交換模式。 WCF 會使用 HTTP 要求將所有訊息從起始端傳輸至回應端,並透過 HTTP 回應將所有訊息從回應端傳輸至起始端。
CreateSequence 交換
WCF 起始端會透過 HTTP 要求傳輸不含 Offer
元素的 CreateSequence
訊息,並預期透過 HTTP 回應接收 CreateSequenceResponse
訊息。 WCF 回應端會建立序列,並透過 HTTP 回應傳輸不含 Accept
元素的 CreateSequenceResponse
訊息。
SequenceAcknowledgement
WCF 起始端會處理所有訊息 (CreateSequence
訊息與錯誤訊息除外) 回覆的認可。 WCF 回應端一律會透過 HTTP 回應將獨立認可傳輸至所有序列和 AckRequested
訊息。
CloseSequence 交換
WCF 起始端會透過 HTTP 要求傳輸 CloseSequence
訊息,並預期透過 HTTP 回應接收 CreateSequenceResponse
訊息。 WCF 回應端會透過 HTTP 回應傳輸 CloseSequenceResponse
訊息。
TerminateSequence 交換
WCF 起始端會透過 HTTP 要求傳輸 TerminateSequence
訊息,並預期透過 HTTP 回應接收 TerminateSequenceResponse
訊息。 WCF 回應端會透過 HTTP 回應傳輸 TerminateSequenceResponse
訊息。
單向、可定址啟動器
繫結
WCF 會透過在一個輸入與一個輸出 HTTP 通道上使用一個序列的方式,提供單向的訊息交換模式。 WCF 會使用 HTTP 要求傳輸所有訊息。 所有的 HTTP 回應都有空本文和 HTTP 202 狀態碼。
CreateSequence 交換
WCF 起始端會透過 HTTP 要求傳輸不含 Offer
元素的 CreateSequence
訊息。 WCF 回應端會建立序列,並透過 HTTP 要求傳輸不含 Accept
元素的 CreateSequenceResponse
訊息。
雙工、可定址啟動器
繫結
WCF 會透過在一個輸入與一個輸出 HTTP 通道上使用兩個序列的方式,提供完全非同步、雙向的訊息交換模式。 在有限的情況下,此訊息交換模式可與 Request/Reply
、Addressable
啟動器訊息交換模式混合使用。 WCF 會使用 HTTP 要求傳輸所有訊息。 所有的 HTTP 回應都有空本文和 HTTP 202 狀態碼。
CreateSequence 交換
WCF 起始端會透過 HTTP 要求傳輸包含 Offer
元素的 CreateSequence
訊息。 WCF 回應端會確定 CreateSequence
包含 Offer
元素,然後建立序列,並傳輸包含 Accept
元素的 CreateSequenceResponse
訊息。
序列存留期
WCF 會將兩個序列視為一個全雙工工作階段。
在產生將某個序列視為出錯的錯誤時,WCF 預期遠端端點會同時將兩個序列視為出錯。 在讀取將某個序列視為出錯的錯誤時,WCF 會同時將兩個序列視為出錯。
WCF 可關閉其輸出序列,並繼續處理其輸入序列上的訊息。 反之,WCF 可處理輸入序列的關閉作業,並繼續傳送其輸出序列上的訊息。
要求-回覆和單向、不可定址啟動器
繫結
WCF 會透過在一個 HTTP 通道上使用兩個序列的方式,提供單向、要求-回覆訊息交換模式。 WCF 會使用 HTTP 要求將所有訊息從起始端傳輸至回應端,並透過 HTTP 回應將所有訊息從回應端傳輸至起始端。
CreateSequence 交換
WCF 起始端會透過 HTTP 要求傳輸包含 Offer
元素的 CreateSequence
訊息,並預期透過 HTTP 回應接收 CreateSequenceResponse
訊息。 WCF 回應端會建立序列,並透過 HTTP 回應傳輸包含 Accept
元素的 CreateSequenceResponse
訊息。
單向訊息
為了成功完成單向訊息交換,WCF 起始端會透過 HTTP 要求傳輸要求序列訊息,並透過 HTTP 回應接收獨立的 SequenceAcknowledgement
訊息。 SequenceAcknowledgement
必須認可傳送的訊息。
WCF 回應端可透過認可、錯誤或是內含空本文與 HTTP 202 狀態碼的回應來回覆要求。
雙向訊息
為了成功完成雙向訊息交換通訊協定,WCF 起始端會透過 HTTP 要求傳輸要求序列訊息,並透過 HTTP 回應接收回覆序列訊息。 回應中必須包含認可傳輸之要求序列訊息的 SequenceAcknowledgement
。
WCF 回應端可透過應用程式回覆、錯誤或是內含空本文與 HTTP 202 狀態碼的回應來回覆要求。
由於單向訊息與應用程式回覆時機的緣故,要求序列訊息的序號與回應訊息的序號彼此並未互相關聯。
重試回覆
WCF 需依賴 HTTP 要求-回覆相互關聯來執行雙向訊息交換通訊協定的相互關聯。 因此,WCF 起始端不會在認可要求序列訊息時停止重試要求序列訊息,而會在 HTTP 回應內含 SequenceAcknowledgement
、應用程式回覆或錯誤時停止重試。 WCF 回應端會在與回覆相互關聯之要求的 HTTP 回應上重試回覆。
CloseSequence 交換
在收到所有單向要求序列訊息的所有回覆序列訊息與認可後,WCF 起始端會透過 HTTP 要求傳輸要求序列的 CloseSequence
訊息,並預期透過 HTTP 回應接收 CloseSequenceResponse
。
隱含地關閉要求序列會一併關閉回覆序列。 也就是說,WCF 起始端會在 CloseSequence
訊息中包含回覆序列的最終 SequenceAcknowledgement
,而且回覆序列不會有 CloseSequence
交換。
WCF 回應端會確定所有回覆都已認可,並透過 HTTP 回應傳輸 CloseSequenceResponse
訊息。
TerminateSequence 交換
在收到 CloseSequenceResponse
訊息之後,WCF 起始端會透過 HTTP 要求傳輸要求序列的 TerminateSequence
訊息,並預期透過 HTTP 回應接收 TerminateSequenceResponse
。
就像 CloseSequence
交換一樣,終止要求序列會隱含地終止回覆序列。 也就是說,WCF 起始端會在 TerminateSequence
訊息中包含回覆序列的最終 SequenceAcknowledgement
,而且回覆序列不會有 TerminateSequence
交換。
WCF 回應端會透過 HTTP 回應傳輸 TerminateSequenceResponse
訊息。
要求/回覆、可定址啟動器
繫結
WCF 會透過在一個輸入與一個輸出 HTTP 通道上使用兩個序列的方式,提供要求-回覆訊息交換模式。 在有限的情況下,此訊息交換模式可與 Duplex, Addressable
啟動器訊息交換模式混合使用。 WCF 會使用 HTTP 要求傳輸所有訊息。 所有的 HTTP 回應都有空本文和 HTTP 202 狀態碼。
CreateSequence 交換
WCF 起始端會透過 HTTP 要求傳輸包含 Offer
元素的 CreateSequence
訊息。 WCF 回應端會確定 CreateSequence
包含 Offer
元素,然後建立序列,並傳輸包含 Accept
元素的 CreateSequenceResponse
訊息。
要求/回覆相互關聯
下列會套用到所有相互關聯的要求及回覆:
WCF 會確定所有應用程式要求訊息都附有
ReplyTo
端點參考和MessageId
。WCF 會將本機端點參考當成每個應用程式要求訊息的
ReplyTo
來套用。 啟動器的本機端點參照是CreateSequence
訊息的ReplyTo
,而回應程式的本機端點參照則是CreateSequence
訊息的To
。WCF 會確定所有傳入的要求訊息都附有
MessageId
和ReplyTo
。WCF 會確定所有應用程式要求訊息的
ReplyTo
端點參考 URI 都符合如先前定義的本機端點參考。WCF 會確定所有回覆都附有正確且遵循
wsa
要求/回覆相互關聯規則的RelatesTo
和To
標頭。