Udostępnij przez

Protokół niezawodnego przesyłania wiadomości w wersji 1.1

W tym temacie opisano szczegóły implementacji programu Windows Communication Foundation (WCF) dla protokołu WS-ReliableMessaging lutego 2007 r. (wersja 1.1) niezbędnego do współdziałania przy użyciu transportu HTTP. Program WCF jest zgodny ze specyfikacją WS-ReliableMessaging z ograniczeniami i wyjaśnieniami opisanymi w tym temacie. Należy pamiętać, że protokół WS-ReliableMessaging w wersji 1.1 jest implementowany począwszy od programu .NET Framework 3.5.

Protokół z lutego 2007 roku, oznaczony jako WS-ReliableMessaging, jest zaimplementowany w systemie WCF przez ReliableSessionBindingElement.

Dla wygody temat używa następujących ról:

  • Inicjator: klient, który inicjuje tworzenie sekwencji komunikatów WS-Reliable.

  • Osoba odpowiadająca: usługa, która odbiera żądania inicjatora.

Dokument ten wykorzystuje prefiksy i przestrzenie nazw przedstawione w poniższej tabeli.

Prefiks 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 lub WS-Policy 1.5)

Komunikacja

Tworzenie sekwencji

WCF wykorzystuje komunikaty CreateSequence i CreateSequenceResponse do ustanowienia niezawodnej sekwencji przesyłania komunikatów. Obowiązują następujące ograniczenia:

  • B1101: Inicjator WCF używa tego samego odwołania do punktu końcowego, co komunikat CreateSequence oraz elementy ReplyTo, AcksTo i Offer/Endpoint.

  • R1102: Referencje punktu końcowego AcksTo, ReplyTo i Offer/Endpoint w wiadomości CreateSequence muszą mieć identyczne wartości adresów w reprezentacji ciągów, aby były zgodne oktetowo.

    • Moduł odpowiadający WCF sprawdza, czy część identyfikatora URI w odwołaniach do punktów końcowych AcksTo, ReplyTo i Endpoint jest identyczna przed utworzeniem sekwencji.

  • R1103: Odwołania do punktów końcowych AcksTo, ReplyTo i Offer/Endpoint w komunikacie CreateSequence powinny mieć ten sam zestaw parametrów odwołania.

    • Program WCF nie wymusza, ale zakłada, że parametry referencyjne odniesień punktów końcowych AcksTo, ReplyTo i Offer/Endpoint na CreateSequence są identyczne i używa parametrów referencyjnych z odniesienia punktu końcowego ReplyTo do potwierdzeń i odwrotnych komunikatów sekwencji.

  • B1104: Inicjator WCF nie generuje opcjonalnego elementu Expires lub Offer/Expires w wiadomości CreateSequence.

  • B1105: Podczas uzyskiwania dostępu do komunikatu CreateSequence, odbiornik WCF używa wartości Expires w elemencie CreateSequence jako wartości Expires w elemencie CreateSequenceResponse. W przeciwnym razie moduł odpowiedzi WCF odczytuje i ignoruje Expires oraz Offer/Expires.

  • B1106: Podczas uzyskiwania dostępu do komunikatu CreateSequenceResponse inicjator WCF odczytuje wartość opcjonalną Expires , ale nie używa jej.

  • B1107: Inicjator i Odpowiadający WCF zawsze generują opcjonalny element IncompleteSequenceBehavior w elementach CreateSequence/Offer i CreateSequenceResponse.

  • B1108: WCF używa tylko wartości DiscardFollowingFirstGap i NoDiscard w elemencie IncompleteSequenceBehavior.

    • WS-ReliableMessaging wykorzystuje mechanizm Offer do ustanowienia dwóch przeciwstawnych i skorelowanych sekwencji, które tworzą sesję.

  • B1109: Jeśli CreateSequence zawiera element Offer, jednokierunkowa odpowiedź WCF odrzuca zaoferowaną sekwencję, odpowiadając CreateSequenceResponse bez elementu Accept.

  • B1110: Jeśli odbiorca niezawodnych wiadomości odrzuca oferowaną sekwencję, inicjator WCF powoduje błąd nowo ustanowionej sekwencji.

  • B1111: Jeśli CreateSequence nie zawiera elementu Offer, dwukierunkowy responder WCF odrzuca oferowaną sekwencję, odpowiadając komunikatem o błędzie CreateSequenceRefused.

  • R1112: Gdy jest ustanawiana sekwencja dwóch odwrotnych przy użyciu mechanizmu Offer, właściwość [address] odwołania do punktu końcowego musi być zgodna z docelowym URI komunikatu CreateSequenceResponse/Accept/AcksTo bajt po bajcie.

  • R1113: Gdy dwie sekwencje odwrotne zostaną ustanowione przy użyciu mechanizmu Offer, wszystkie komunikaty w obu sekwencjach przepływające z inicjatora do odpowiadającego muszą być wysyłane do tego samego odwołania do końcowego punktu.

Technologia WCF używa WS-ReliableMessaging do ustanawiania niezawodnych sesji między Inicjatorem a Odpowiednikiem. Implementacja WS-ReliableMessaging WCF zapewnia niezawodną sesję dla wzorców komunikacji jednokierunkowej, żądanie-odpowiedź i pełnego dupleksu komunikatów. Mechanizm WS-ReliableMessaging Offer na CreateSequence i CreateSequenceResponse umożliwia ustanowienie dwóch skorelowanych powiązanych sekwencji i udostępnia protokół sesji odpowiedni dla wszystkich punktów końcowych wiadomości. Ponieważ program WCF zapewnia gwarancję bezpieczeństwa dla takiej sesji, w tym kompleksowej ochrony integralności sesji, praktyczne jest zapewnienie, że komunikaty przeznaczone dla tej samej strony docierają do tego samego miejsca docelowego. To również umożliwia łączenie potwierdzeń sekwencji z komunikatami aplikacyjnymi. W związku z tym ograniczenia R1102, R1112 i R1113 mają zastosowanie do programu WCF.

Przykład komunikatu 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>

Przykład komunikatu 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>

Zamykanie sekwencji

Program WCF używa komunikatów CloseSequence i CloseSequenceResponse do zamknięcia zainicjowanego przez źródło usługi Reliable Messaging. Miejsce docelowe niezawodnej obsługi komunikatów programu WCF nie inicjuje zamknięcia, a źródło niezawodnej obsługi komunikatów WCF nie obsługuje zamknięcia zainicjowanego przez miejsce docelowe usługi Reliable Messaging. Obowiązują następujące ograniczenia:

  • B1201: Źródło WCF Reliable Messaging zawsze wysyła komunikat CloseSequence w celu zamknięcia sekwencji.

  • B1202: Źródło niezawodnej komunikacji czeka na potwierdzenie pełnego zakresu komunikatów w sekwencji przed wysłaniem wiadomości CloseSequence.

  • B1203: Źródło Reliable Messaging zawsze zawiera opcjonalny element LastMsgNumber, chyba że sekwencja nie zawiera komunikatów.

  • R1204: Docelowy punkt wiadomości niezawodnej nie może zainicjować zamknięcia przez wysłanie komunikatu CloseSequence.

  • B1205: Po otrzymaniu komunikatu CloseSequence moduł niezawodnej obsługi wiadomości WCF uznaje sekwencję za niekompletną i wysyła komunikat o błędzie.

Przykład komunikatu 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>

Przykładowy CloseSequenceResponse komunikat:

<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>

Zakończenie sekwencji

WCF używa TerminateSequence/TerminateSequenceResponse uzgadniania głównie po tym, jak zostanie zakończone CloseSequence/CloseSequenceResponse uzgadnianie. Miejsce docelowe niezawodnej obsługi komunikatów WCF nie inicjuje zakończenia, a źródło niezawodnej obsługi komunikatów nie obsługuje zakończenia inicjowanego przez miejsce docelowe niezawodnej obsługi komunikatów. Obowiązują następujące ograniczenia:

  • B1301: Inicjator WCF wysyła wiadomość TerminateSequence tylko po pomyślnym zakończeniu CloseSequence/CloseSequenceResponse uzgadniania.

  • R1302: WCF weryfikuje, czy element LastMsgNumber jest spójny we wszystkich komunikatach CloseSequence i TerminateSequence dla danej sekwencji. Oznacza to, że LastMsgNumber nie jest obecny na wszystkich CloseSequence i TerminateSequence komunikatach, albo jest obecny i identyczny na wszystkich CloseSequence i TerminateSequence komunikatach.

  • B1303: Po odebraniu komunikatu TerminateSequence po zakończeniu uścisku dłoni CloseSequence/CloseSequenceResponse, docelowy punkt w systemie Reliable Messaging odpowiada komunikatem TerminateSequenceResponse. Ponieważ źródło wiadomości niezawodnych ma ostateczne potwierdzenie przed wysłaniem komunikatu TerminateSequence, miejsce docelowe wiadomości niezawodnych wie bez wątpienia, że sekwencja się kończy, i natychmiast odzyskuje zasoby.

  • B1304: Podczas odbierania komunikatu TerminateSequence przed nawiązaniem połączenia CloseSequence/CloseSequenceResponse, odbiorca niezawodnej komunikacji WCF odpowiada komunikatem TerminateSequenceResponse. Jeśli miejsce docelowe niezawodnych komunikatów stwierdzi brak niespójności w sekwencji, oczekuje przez określony czas wskazany przez cel aplikacji przed odzyskaniem zasobów, aby umożliwić klientowi uzyskanie ostatecznego potwierdzenia. W przeciwnym razie miejsce docelowe Reliable Messaging natychmiast odzyskuje zasoby i wskazuje miejsce docelowe aplikacji, że sekwencja kończy się wątpliwością, wywołując zdarzenie Faulted.

Przykład komunikatu 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>

Przykładowy TerminateSequenceResponse komunikat:

<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>

Sekwencje

Poniżej znajduje się lista ograniczeń, które mają zastosowanie do sekwencji:

  • B1401:WCF generuje i uzyskuje dostęp do numerów sekwencji nie wyższych niż maksymalna wartość inkluzywna xs:long, 9223372036854775807.

Przykład nagłówka Sequence .

<wsrm:Sequence s:mustUnderstand="1">
  <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
  <wsrm:MessageNumber>1</wsrm:MessageNumber>
</wsrm:Sequence>

Potwierdzenie otrzymania żądania

Program WCF używa nagłówka AckRequested jako mechanizmu utrzymania aktywności.

Przykład nagłówka AckRequested .

<wsrm:AckRequested>
  <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
</wsrm:AckRequested>

Potwierdzenie Sekwencji

WCF używa mechanizmu "piggy-back" do potwierdzania sekwencji podanych w WS-Reliable Messaging. Obowiązują następujące ograniczenia:

  • R1601: Gdy dwie sekwencje odwrotne zostaną ustanowione przy użyciu mechanizmu Offer, nagłówek SequenceAcknowledgement może zostać dołączony do dowolnego komunikatu aplikacji przesłanego do zamierzonego adresata. Zdalny punkt końcowy musi mieć dostęp do doczepionego nagłówka SequenceAcknowledgement.

  • B1602: WCF nie generuje SequenceAcknowledgement nagłówków zawierających Nack elementy. Program WCF sprawdza, czy każdy Nack element zawiera numer sekwencji, ale w przeciwnym razie ignoruje Nack element i wartość.

Przykład nagłówka 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 błędy

Poniżej znajduje się lista ograniczeń, które mają zastosowanie do implementacji błędów WS-ReliableMessaging w WCF. Obowiązują następujące ograniczenia:

  • B1701: Program WCF nie generuje MessageNumberRollover błędów.

  • B1702: Za pośrednictwem protokołu SOAP 1.2, gdy punkt końcowy usługi osiągnie limit połączenia i nie może przetworzyć nowych połączeń, program WCF generuje zagnieżdżony CreateSequenceRefused kod podrzędny błędów, netrm:ConnectionLimitReachedjak pokazano w poniższym przykładzie.

<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>

błędy WS-Addressing

Ponieważ WS-ReliableMessaging używa adresowania WS, implementacja WS-ReliableMessaging WCF może generować i przesyłać błędy WS-Addressing. W tej sekcji omówiono błędy WS-Addressing, które program WCF jawnie generuje i przesyła w warstwie WS-ReliableMessaging:

  • B1801:WCF generuje i przesyła Message Addressing Header Required błąd, gdy jedna z następujących wartości jest prawdziwa:

    • Brakuje nagłówka w wiadomości CreateSequence, CloseSequence lub TerminateSequence.

    • Brakuje nagłówka w wiadomości CreateSequence, CloseSequence lub TerminateSequence.

    • Brakuje nagłówka CreateSequenceResponse w wiadomości CloseSequenceResponse, TerminateSequenceResponse lub RelatesTo.

  • B1802:WCF generuje i przesyła Endpoint Unavailable błąd, aby wskazać, że nie ma punktu końcowego nasłuchiwania, który może przetwarzać sekwencję na podstawie badania nagłówków adresowania w CreateSequence komunikacie.

Kompozycja protokołu

Kompozycja z WS-Addressing

WCF obsługuje dwie wersje WS-Addressing: WS-Addressing 2004/08 [WS-ADDR] i Rekomendacje W3C WS-Addressing 1.0 [WS-ADDR-CORE] i [WS-ADDR-SOAP].

Chociaż specyfikacja WS-ReliableMessaging wspomina tylko o WS-Addressing 2004/08, nie ogranicza wersji WS-Addressing do użycia. Poniżej znajduje się lista ograniczeń, które mają zastosowanie do programu WCF:

  • R2101: Zarówno WS-Addressing 2004/08, jak i WS-Addressing 1.0 mogą być używane z WS-Reliable Messaging.

  • R2102: Pojedyncza wersja WS-Addressing musi być używana w ramach danej sekwencji WS-ReliableMessaging lub pary sekwencji odwrotnych skorelowanych przy użyciu Offer mechanizmu.

Kompozycja z SOAP

Program WCF obsługuje korzystanie zarówno z protokołu SOAP 1.1, jak i protokołu SOAP 1.2 z WS-Reliable Messaging.

Kompozycja z WS-Security i WS-SecureConversation

Program WCF zapewnia ochronę sekwencji WS-ReliableMessaging przy użyciu bezpiecznego transportu (HTTPS), kompozycji z zabezpieczeniami WS-Security oraz kompozycji z WS-Secure Conversation. Protokół WS-ReliableMessaging 1.1, WS-Security 1.1 i WS-Secure Conversation 1.3 powinny być używane razem. Poniżej znajduje się lista ograniczeń, które mają zastosowanie do programu WCF:

  • R2301: Aby chronić integralność sekwencji WS-ReliableMessaging, oprócz integralności i poufności poszczególnych wiadomości, program WCF wymaga użycia Konwersacji WS-Secure.

  • R2302:AWS-Secure Sesja konwersacji musi zostać nawiązana przed rozpoczęciem WS-ReliableMessaging sekwencji.

  • R2303: Jeśli okres istnienia sekwencji WS-ReliableMessaging przekracza okres istnienia sesji konwersacji WS-Secure, SecurityContextToken ustanowiony za pomocą „Konwersacji” WS-Secure należy odnowić za pomocą odpowiedniego powiązania odnawiania „Konwersacji” WS-Secure.

  • B2304: sekwencjaWS-ReliableMessaging lub para skorelowanych sekwencji odwrotnych jest zawsze powiązana z jedną sesją WS-SecureConversation.

  • R2305: Gdy jest złożony z WS-Secure Konwersacja, odpowiednik WCF wymaga, aby wiadomość CreateSequence zawierała element wsse:SecurityTokenReference i nagłówek wsrm:UsesSequenceSTR.

Przykład nagłówka UsesSequenceSTR .

<wsrm:UsesSequenceSTR></wsrm:UsesSequenceSTR>

Kompozycja z sesjami SSL/TLS

Program WCF nie obsługuje kompozycji z sesjami SSL/TLS:

  • B2401: WCF nie generuje nagłówka wsrm:UsesSequenceSSL .

  • R2402: Inicjator niezawodnej obsługi komunikatów nie może wysyłać komunikatu CreateSequence z nagłówkiem wsrm:UsesSequenceSSL do obiektu odpowiadającego WCF.

Kompozycja z WS-Policy

Program WCF obsługuje dwie wersje usług WS-Policy: WS-Policy 1.2 i WS-Policy 1.5.

Asercja WS-ReliableMessaging WS-Policy

Program WCF używa Asercji WS-ReliableMessaging WS-Policy wsrm:RMAssertion do opisywania możliwości punktów końcowych. Poniżej znajduje się lista ograniczeń, które mają zastosowanie do programu WCF:

  • B3001: WCF dołącza asercję wsrmn:RMAssertion WS-Policy do elementów wsdl:binding. WCF obsługuje załączniki zarówno do elementów wsdl:binding, jak i wsdl:port.

  • B3002: WCF nigdy nie generuje tagu wsp:Optional .

  • B3003: Podczas dostępu do asercji WS-Policy program WCF ignoruje tag wsrmp:RMAssertion i traktuje politykę WS-RM jako obowiązkową.

  • R3004: Ponieważ usługa WCF nie współpracuje z sesjami SSL/TLS, nie akceptuje polityki określającej wartość wsrmp:SequenceTransportSecurity.

  • B3005: Program WCF zawsze generuje wsrmp:DeliveryAssurance element.

  • B3006: WCF zawsze określa wsrmp:ExactlyOnce gwarancję dostarczenia.

  • B3007: Program WCF generuje i odczytuje następujące właściwości asercji WS-ReliableMessaging i zapewnia kontrolę nad nimi w programie WCFReliableSessionBindingElement:

    • netrmp:InactivityTimeout

    • netrmp:AcknowledgementInterval

    Przykład obiektu 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>

Rozszerzenie sterowania przepływem WS-ReliableMessaging

WCF wykorzystuje rozszerzalność WS-ReliableMessaging, aby opcjonalnie zapewnić dodatkową, ściślejszą kontrolę nad przepływem komunikatów w sekwencji.

Sterowanie przepływem jest włączone przez ustawienie ReliableSessionBindingElement.FlowControlEnabled właściwości na true. Poniżej znajduje się lista ograniczeń, które mają zastosowanie do programu WCF:

  • B4001: Po włączeniu niezawodnego sterowania przepływem komunikatów, WCF generuje element netrm:BufferRemaining w rozszerzalności nagłówka SequenceAcknowledgement, jak pokazano w poniższym przykładzie.

    <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: Nawet przy włączeniu kontroli przepływu niezawodnej obsługi komunikatów, program WCF nie wymaga elementu netrm:BufferRemaining w nagłówku SequenceAcknowledgement.

  • B4003: WCF Reliable Messaging Destination używa netrm:BufferRemaining do wskazania, ile nowych komunikatów może buforować.

  • B4004: Gdy włączone jest niezawodne sterowanie przepływem w obsłudze komunikatów, źródło niezawodnej obsługi komunikatów WCF używa wartości netrm:BufferRemaining do ograniczania transmisji komunikatów.

  • B4005: WCF generuje netrm:BufferRemaining wartości całkowite z zakresu od 0 do 4096 włącznie i odczytuje wartości całkowite z zakresu od 0 do xs:intwartości maxInclusive 214748364 włącznie.

Wzorce wymiany komunikatów

W tej sekcji opisano zachowanie programu WCF, gdy WS-ReliableMessaging jest używany dla różnych wzorców wymiany komunikatów. Dla każdego wzorca wymiany komunikatów są brane pod uwagę następujące dwa scenariusze wdrażania:

  • Inicjator nieadresowalny: inicjator znajduje się za zaporą ogniową; Responder może dostarczać komunikaty do inicjatora tylko w odpowiedziach HTTP.

  • Adresowalny inicjator: inicjator i obiekt odpowiadający mogą wysyłać żądania HTTP; innymi słowy, można ustanowić dwa odwrotne połączenia HTTP.

Jednokierunkowy nieadresowalny inicjator

Wiążący

WCF zapewnia jednokierunkowy wzorzec wymiany komunikatów przy użyciu jednej sekwencji za pośrednictwem jednego kanału HTTP. Program WCF używa żądań HTTP do przesyłania wszystkich komunikatów z inicjatora do obiektu odpowiadającego i odpowiedzi HTTP w celu przesłania wszystkich komunikatów z obiektu odpowiadającego do inicjatora.

CreateSequence Exchange

Inicjator WCF przesyła komunikat CreateSequence bez elementu Offer w żądaniu HTTP i oczekuje komunikatu CreateSequenceResponse w odpowiedzi HTTP. Responder WCF tworzy sekwencję i przesyła komunikat CreateSequenceResponse bez elementu Accept w odpowiedzi HTTP.

Potwierdzenie Sekwencji

Inicjator WCF przetwarza potwierdzenia odpowiedzi wszystkich komunikatów z wyjątkiem komunikatów CreateSequence i komunikatów o błędach. Responder WCF zawsze przesyła autonomiczne potwierdzenie na odpowiedź HTTP dla wszystkich sekwencji oraz komunikatów AckRequested.

CloseSequence Exchange

Inicjator WCF przesyła komunikat CloseSequence na żądaniu HTTP i oczekuje komunikatu CreateSequenceResponse w odpowiedzi HTTP. Responder WCF przesyła komunikat CloseSequenceResponse w odpowiedzi HTTP.

TerminateSequence Exchange

Inicjator WCF przesyła komunikat TerminateSequence na żądaniu HTTP i oczekuje komunikatu TerminateSequenceResponse w odpowiedzi HTTP. Responder WCF przesyła komunikat TerminateSequenceResponse w odpowiedzi HTTP.

Jednokierunkowy, adresowalny inicjator

Wiążący

Program WCF zapewnia jednokierunkowy wzorzec wymiany komunikatów przy użyciu jednej sekwencji przez jeden przychodzący i jeden wychodzący kanał HTTP. Program WCF używa żądań HTTP do przesyłania wszystkich komunikatów. Wszystkie odpowiedzi HTTP mają pustą treść i kod stanu HTTP 202.

CreateSequence Exchange

Inicjator WCF wysyła wiadomość CreateSequence bez elementu Offer w ramach żądania HTTP. Element WCF tworzy sekwencję i przesyła wiadomość CreateSequenceResponse bez elementu Accept w żądaniu HTTP.

Dwupoziomowy, adresowalny inicjator

Wiążący

WCF zapewnia w pełni asynchroniczny, dwukierunkowy wzorzec wymiany komunikatów przy użyciu dwóch sekwencji za pośrednictwem jednego przychodzącego i jednego wychodzącego kanału HTTP. Ten wzorzec wymiany komunikatów może być mieszany ze wzorcem wymiany komunikatów Request/ReplyAddressable inicjatora w ograniczony sposób. Program WCF używa żądań HTTP do przesyłania wszystkich komunikatów. Wszystkie odpowiedzi HTTP mają pustą treść i kod stanu HTTP 202.

CreateSequence Exchange

Inicjator WCF przesyła wiadomość CreateSequence z elementem Offer w żądaniu HTTP. Obiekt odpowiadający WCF gwarantuje, że CreateSequence ma element Offer, następnie tworzy sekwencję i przesyła komunikat CreateSequenceResponse z elementem Accept.

Okres istnienia sekwencji

WCF traktuje dwie sekwencje jako jedną w pełni dupleksową sesję.

Generując błąd, który powoduje awarię jednej z sekwencji, program WCF oczekuje, że zdalny punkt końcowy uszkodzi obie sekwencje. Podczas odczytywania błędu, który powoduje uszkodzenie jednej sekwencji, WCF powoduje uszkodzenie obu sekwencji.

Program WCF może zamknąć sekwencję ruchu wychodzącego i kontynuować przetwarzanie komunikatów w sekwencji ruchu przychodzącego. Z drugiej strony program WCF może przetworzyć zamknięcie sekwencji ruchu przychodzącego i kontynuować wysyłanie komunikatów w sekwencji ruchu wychodzącego.

Request-Reply i jednokierunkowy, nieadresowalny inicjator

Wiążący

WCF zapewnia wzorce wymiany komunikatów jednokierunkowych i żądań-odpowiedzi przy użyciu dwóch sekwencji za pośrednictwem jednego kanału HTTP. Program WCF używa żądań HTTP do przesyłania wszystkich komunikatów z inicjatora do obiektu odpowiadającego i odpowiedzi HTTP w celu przesłania wszystkich komunikatów z obiektu odpowiadającego do inicjatora.

CreateSequence Exchange

Inicjator WCF przesyła komunikat CreateSequence z elementem Offer w żądaniu HTTP i oczekuje komunikatu CreateSequenceResponse w odpowiedzi HTTP. Moduł odpowiedzialny WCF tworzy sekwencję i przesyła komunikat CreateSequenceResponse wraz z elementem Accept jako odpowiedź HTTP.

Jednokierunkowa wiadomość

Aby pomyślnie ukończyć jednokierunkową wymianę komunikatów, inicjator WCF przesyła komunikat z sekwencją żądań w żądaniu HTTP i odbiera samodzielny komunikat SequenceAcknowledgement w odpowiedzi HTTP. Element SequenceAcknowledgement musi potwierdzić przesłaną wiadomość.

Osoba odpowiadająca WCF może odpowiedzieć na żądanie z potwierdzeniem, błędem lub odpowiedzią z pustą treścią i kodem stanu HTTP 202.

Komunikaty dwukierunkowe

Aby pomyślnie ukończyć dwukierunkowy protokół wymiany komunikatów, inicjator WCF przesyła komunikat sekwencji żądań w żądaniu HTTP i odbiera komunikat sekwencji odpowiedzi w odpowiedzi HTTP. Odpowiedź musi zawierać SequenceAcknowledgement jako potwierdzenie przesłania wiadomości w sekwencji żądań.

Osoba odpowiadająca WCF może odpowiedzieć na żądanie za pomocą odpowiedzi aplikacji, błędu lub odpowiedzi z pustą treścią i kodem stanu HTTP 202.

Ze względu na obecność komunikatów jednokierunkowych i moment odpowiedzi aplikacji numer sekwencji komunikatu żądania i numer sekwencji komunikatu odpowiedzi nie mają korelacji.

Ponawianie odpowiedzi

WCF opiera się na korelacji http request-reply dla dwukierunkowej korelacji protokołu wymiany komunikatów. Z tego powodu inicjator WCF nie przestaje ponawiać próby wysłania komunikatu sekwencji żądań, gdy komunikat jest potwierdzany, lecz dopiero wtedy, gdy odpowiedź HTTP zawiera SequenceAcknowledgement, odpowiedź aplikacji lub błąd. Obiekt WCF Responder ponownie wysyła odpowiedzi na żądania HTTP, z którymi te odpowiedzi są powiązane.

CloseSequence Exchange

Po otrzymaniu wszystkich komunikatów sekwencji odpowiedzi i potwierdzeń dla wszystkich komunikatów sekwencji żądań jednokierunkowych, inicjator WCF przesyła komunikat CloseSequence dla sekwencji żądań w żądaniu HTTP i oczekuje CloseSequenceResponse na odpowiedź HTTP.

Zamknięcie sekwencji żądań niejawnie zamyka sekwencję odpowiedzi. Oznacza to, że inicjator WCF zawiera końcowy element sekwencji SequenceAcknowledgement odpowiedzi w wiadomości CloseSequence, a sekwencja odpowiedzi nie ma wymiany CloseSequence.

Obiekt Odpowiedzi WCF zapewnia potwierdzenie wszystkich odpowiedzi i przesyła komunikat CloseSequenceResponse w odpowiedzi HTTP.

TerminateSequence Exchange

Po otrzymaniu komunikatu CloseSequenceResponse inicjator WCF przesyła komunikat TerminateSequence dla sekwencji żądań w żądaniu HTTP i oczekuje odpowiedzi TerminateSequenceResponse na odpowiedź HTTP.

Podobnie jak w przypadku CloseSequence wymiany, niejawne zakończenie sekwencji żądań powoduje zakończenie sekwencji odpowiedzi. Oznacza to, że inicjator WCF zawiera końcową sekwencję SequenceAcknowledgement na wiadomości TerminateSequence, a sekwencja odpowiedzi nie ma wymiany TerminateSequence.

Responder WCF przesyła komunikat TerminateSequenceResponse w odpowiedzi HTTP.

Żądanie/odpowiedź, adresowalny inicjator

Wiążący

Program WCF udostępnia wzorzec wymiany komunikatów z odpowiedzią na żądanie przy użyciu dwóch sekwencji za pośrednictwem jednego ruchu przychodzącego i jednego wychodzącego kanału HTTP. Ten wzorzec wymiany komunikatów może być mieszany ze Duplex, Addressable wzorcem wymiany komunikatów inicjatora w ograniczony sposób. Program WCF używa żądań HTTP do przesyłania wszystkich komunikatów. Wszystkie odpowiedzi HTTP mają pustą treść i kod stanu HTTP 202.

CreateSequence Exchange

Inicjator WCF przesyła wiadomość CreateSequence z elementem Offer w żądaniu HTTP. Obiekt odpowiadający WCF zapewnia, że CreateSequence ma element Offer, następnie tworzy sekwencję i przesyła komunikat CreateSequenceResponse z elementem Accept.

Korelacja żądań/odpowiedzi

Następujące elementy dotyczą wszystkich skorelowanych żądań i odpowiedzi:

  • Usługa WCF zapewnia, że wszystkie komunikaty żądań aplikacji mają odniesienie do punktu końcowego ReplyTo oraz MessageId.

  • Program WCF wykorzystuje odwołanie do lokalnego punktu końcowego jako ReplyTo komunikat żądania każdej aplikacji. Odwołanie do CreateSequence lokalnego punktu końcowego jest komunikatem ReplyTo dla inicjatora i komunikatu CreateSequenceTo dla obiektu odpowiadającego.

  • Usługa WCF zapewnia, że przychodzące komunikaty żądań zawierają MessageId oraz ReplyTo.

  • Program WCF zapewnia, że URI odwołania punktu końcowego ReplyTo wszystkich komunikatów żądań aplikacji jest zgodny z lokalnym odwołaniem punktu końcowego zgodnie z wcześniejszą definicją.

  • WCF zapewnia, że wszystkie odpowiedzi mają poprawne nagłówki RelatesTo i To zgodnie z wsa zasadami korelacji zapytań/odpowiedzi.

  • Last updated on