Udostępnij za pośrednictwem

Reliable Messaging Protocol w wersji 1.0

  • Artykuł

W tym temacie opisano szczegóły implementacji programu Windows Communication Foundation (WCF) dotyczące protokołu WS-Reliable Messaging z lutego 2005 r. (wersja 1.0) niezbędnego do współdziałania przy użyciu transportu HTTP. Program WCF jest zgodny ze specyfikacją usługi WS-Reliable Messaging z ograniczeniami i wyjaśnieniami opisanymi w tym temacie. Pamiętaj, że protokół WS-ReliableMessaging w wersji 1.0 jest implementowany począwszy od systemu WinFX.

Protokół WS-Reliable Messaging z lutego 2005 r. jest implementowany w programie WCF przez program ReliableSessionBindingElement.

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

  • Inicjator: klient, który inicjuje tworzenie sekwencji komunikatów niezawodnych WS

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

W tym dokumencie użyto prefiksów i przestrzeni nazw w poniższej tabeli.

Prefiks Przestrzeń nazw
Wsrm http://schemas.xmlsoap.org/ws/2005/02/rm
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

Obsługa komunikatów

Sekwencja komunikatów o ustanowieniu

Program WCF implementuje CreateSequence i CreateSequenceResponse komunikaty w celu ustanowienia niezawodnej sekwencji komunikatów. Obowiązują następujące ograniczenia:

  • B1101: Inicjator WCF nie generuje opcjonalnego elementu Wygasa w CreateSequence komunikacie lub w przypadkach, gdy CreateSequence komunikat zawiera Offer element, opcjonalny Expires element w elemecie Offer .

  • B1102: Podczas uzyskiwania dostępu do komunikatu CreateSequence program WCFResponder wysyła i odbiera oba Expires elementy, jeśli istnieją, ale nie używa ich wartości.

Usługa WS-Reliable Messaging wprowadza Offer mechanizm ustanawiania dwóch skorelowanych sekwencji, które tworzą sesję.

  • R1103: Jeśli CreateSequence zawiera Offer element, osoba odpowiadająca na niezawodne komunikaty musi zaakceptować sekwencję i odpowiedzieć za pomocą CreateSequenceResponse elementu zawierającego wsrm:Accept element, tworząc dwie skorelowane sekwencje odwrotne lub odrzucić CreateSequence żądanie.

  • R1104: SequenceAcknowledgement i komunikaty aplikacji przepływające na odwrotnej ReplyTo sekwencji muszą być wysyłane do odwołania do punktu końcowego .CreateSequence

  • R1105: AcksTo i ReplyTo odwołania do punktu końcowego w elemencie CreateSequence muszą mieć wartości adresów zgodne z oktetem-mądry.

    Obiekt odpowiadający WCF sprawdza, czy część AcksTo identyfikatora URI i ReplyTo epR są identyczne przed utworzeniem sekwencji.

  • R1106: AcksTo odwołania ReplyTo do punktu końcowego w obiekcie CreateSequence powinny mieć ten sam zestaw parametrów referencyjnych.

    WCF nie wymusza, ale zakłada, że [parametry referencyjne] AcksTo i ReplyTo włączone CreateSequence są identyczne i używają [parametrów referencyjnych] z ReplyTo odwołania do punktu końcowego do potwierdzenia i komunikatów sekwencji odwrotnych.

  • R1107: Po ustanowieniu Offer dwóch sekwencji odwrotnych przy użyciu mechanizmu, SequenceAcknowledgement a komunikaty aplikacji przepływające na odwrotnych sekwencjach muszą być wysyłane do odwołania do ReplyTo punktu końcowego obiektu CreateSequence.

  • R1108: Po ustanowieniu dwóch sekwencji odwrotnych przy użyciu mechanizmu [address] oferty właściwość wsrm:AcksTo elementu wsrm:Accept podrzędnego Odwołanie punktu końcowego elementu CreateSequenceResponse elementu musi być zgodna z bajtem docelowy identyfikator URI CreateSequenceelementu .

  • R1109: Po ustanowieniu Offer dwóch sekwencji odwrotnych przy użyciu mechanizmu komunikaty wysyłane przez inicjatora i potwierdzenia do komunikatów przez obiekt odpowiadający muszą być wysyłane do tego samego odwołania do punktu końcowego.

    Program WCF używa funkcji WS-Reliable Messaging do ustanawiania niezawodnych sesji między inicjatorem i obiektem odpowiadającym. Implementacja usługi WS-Reliable Messaging w programie WCF zapewnia niezawodną sesję dla jednokierunkowych, żądań i pełnych dwukierunkowych wzorców obsługi komunikatów. Mechanizm WS-Reliable Messaging Offer w systemie CreateSequence/CreateSequenceResponse umożliwia ustanowienie dwóch skorelowanych sekwencji odwrotnych i zapewnia protokół sesji odpowiedni dla wszystkich punktów końcowych komunikatów. 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. Umożliwia to również piggy-backing sekwencji potwierdzenia w komunikatach aplikacji. W związku z tym ograniczenia R1104, R1105 i R1108 mają zastosowanie do programu WCF.

Przykład komunikatu CreateSequence .

<s:Envelope>
  <s:Header>
    <a:Action s:mustUnderstand="1">
      http://schemas.xmlsoap.org/ws/2005/02/rm/CreateSequence
    </a:Action>
    <a:ReplyTo>
      <a:Address>
         http://Business456.com/clientA
      </a:Address>
    </a:ReplyTo>
    <a:MessageID>
      urn:uuid:addabbbf-60cb-44d3-8c5b-9e0841629a36
    </a:MessageID>
    <a:To s:mustUnderstand="1">
      http://Business456.com/clientA
    </a: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:0afb8d36-bf26-4776-b8cf-8c91fddb5496
      </wsrm:Identifier>
     </wsrm:Offer>
   </wsrm:CreateSequence>
  </s:Body>
</s:Envelope>

Przykład komunikatu CreateSequenceResponse .

<s:Envelope>
  <s:Header>
    <a:Action s:mustUnderstand="1">
      http://schemas.xmlsoap.org/ws/2005/02/rm/CreateSequenceResponse
    </a:Action>
    <a:RelatesTo>
      urn:uuid:addabbbf-60cb-44d3-8c5b-9e0841629a36
    </a:RelatesTo>
    <a:To s:mustUnderstand="1">
      http://Business456.com/clientA
    </a:To>
  </s:Header>
  <s:Body>
   <wsrm:CreateSequenceResponse>
    <Identifier>
     urn:uuid:eea0a36c-b38a-43e8-8c76-2fabe2d76386
    </Identifier>
    <Accept>
    <AcksTo>
      <a:Address>
        http://BusinessABC.com/serviceA
      </a:Address>
    </AcksTo>
    </Accept>
   </wsrm:CreateSequenceResponse>
  </s:Body>
</s:Envelope>

Sequence

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

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

  • B1202:WCF zawsze generuje ostatni komunikat o pustym ciele z identyfikatorem URI akcji .http://schemas.xmlsoap.org/ws/2005/02/rm/LastMessage

  • B1203: Program WCF odbiera i dostarcza komunikat z nagłówkiem sekwencji zawierającym LastMessage element, o ile identyfikator URI akcji nie http://schemas.xmlsoap.org/ws/2005/02/rm/LastMessagejest .

Przykład nagłówka sekwencji.

<wsrm:Sequence>
  <wsrm:Identifier>
    urn:uuid:addabbbf-60cb-44d3-8c5b-9e0841629a36
  </wsrm:Identifier>
  <wsrm:MessageNumber>
    10
  </wsrm:MessageNumber>
  <wsrm:LastMessage/>
 </wsrm:Sequence>

Nagłówek AckRequested

WCF używa AckRequested nagłówka jako mechanizmu utrzymania aktywności. Program WCF nie generuje opcjonalnego MessageNumber elementu. Po otrzymaniu komunikatu z nagłówkiem zawierającym AckRequestedMessageNumber element program WCF ignoruje MessageNumber wartość elementu, jak pokazano w poniższym przykładzie.

<wsrm:AckRequested>
  <wsrm:Identifier>
    urn:uuid:addabbbf-60cb-44d3-8c5b-9e0841629a36
  </wsrm:Identifier>
</wsrm:AckRequested>

Nagłówek SequenceAcknowledgement

WCF używa mechanizmu piggy-back na potrzeby potwierdzania sekwencji udostępnianych w usłudze WS-Reliable Messaging.

  • R1401: Po ustanowieniu Offer dwóch sekwencji odwrotnych przy użyciu mechanizmu SequenceAcknowledgement nagłówek może zostać uwzględniony w każdym komunikacie aplikacji przesłanym do zamierzonego adresata.

  • B1402: Gdy WCF musi wygenerować potwierdzenie przed odebraniem jakichkolwiek komunikatów sekwencji (na przykład w celu spełnienia komunikatu AckRequested ), program WCF generuje SequenceAcknowledgement nagłówek zawierający zakres od 0 do 0, jak pokazano w poniższym przykładzie.

    <wsrm:SequenceAcknowledgement>
  <wsrm:Identifier>
    urn:uuid:addabbbf-60cb-44d3-8c5b-9e0841629a36
  </wsrm:Identifier>
  <wsrm:AcknowledgementRange Upper="0" Lower="0"/>
</wsrm:SequenceAcknowledgement>

  • B1403: WCF nie generuje SequenceAcknowledgement nagłówków zawierających element, Nack ale obsługuje Nack elementy.

Błędy WS-ReliableMessaging

Poniżej znajduje się lista ograniczeń, które mają zastosowanie do implementacji WCF błędów WS-Reliable Messaging:

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

  • Punkt końcowy B1502:WCF może generować CreateSequenceRefused błędy zgodnie ze specyfikacją.

  • B1503: Gdy punkt końcowy usługi osiągnie limit połączenia i nie może przetworzyć nowych połączeń, program WCF generuje dodatkowy CreateSequenceRefused kod podrzędny błędów, netrm:ConnectionLimitReachedjak pokazano w poniższym przykładzie.

    <s:Envelope>
  <s:Header>
    <wsa:Action>
      http://schemas.xmlsoap.org/ws/2005/08/addressing/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">
          [Reason]
        </s:Text>
      </s:Reason>
    </s:Fault>
  </s:Body>
</s:Envelope>

Błędy adresowania WS

Ponieważ usługa WS-Reliable Messaging używa adresowania WS, implementacja WCF WS-Reliable Messaging może generować błędy adresowania WS. W tej sekcji opisano błędy adresowania WS generowane jawnie przez usługę WCF w warstwie niezawodnej obsługi komunikatów WS:

  • B1601:WCF generuje nagłówek komunikatu o błędzie Wymagany, gdy jest spełniony jeden z następujących warunków:

    • Brak nagłówka i nagłówka Sequence komunikatu Action .

    • Brak CreateSequence nagłówka komunikatu MessageId .

    • Brak CreateSequence nagłówka komunikatu ReplyTo .

  • B1602:WCF generuje akcję błędu Nieobsługiwana w odpowiedzi na komunikat, który nie Sequence ma nagłówka i ma Action nagłówek, który nie jest rozpoznawany w specyfikacji niezawodnej obsługi komunikatów WS.

  • B1603:WCF generuje punkt końcowy błędu Niedostępny, aby wskazać, że punkt końcowy nie przetwarza sekwencji na podstawie badania CreateSequence nagłówków adresowania komunikatu.

Kompozycja protokołu

Kompozycja z adresowania WS

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

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

  • R2101: Zarówno adresowanie WS-2004/08, jak i WS-Addressing 1.0 mogą być używane z obsługą niezawodnych komunikatów WS.

  • R2102: Pojedyncza wersja adresowania WS musi być używana w ramach danej sekwencji komunikatów niezawodnych WS lub pary sekwencji odwrotnych skorelowanych przy użyciu wsrm: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 usługą WS-Reliable Messaging.

Kompozycja z zabezpieczeniami usług WS i WS-SecureConversation

Program WCF zapewnia ochronę sekwencji komunikatów niezawodnych WS przy użyciu bezpiecznego transportu (HTTPS), kompozycji z zabezpieczeniami WS-Security i kompozycji z funkcją WS-Secure Conversation. Poniżej znajduje się lista ograniczeń, które mają zastosowanie do programu WCF:

  • R2301: Aby chronić integralność sekwencji komunikatów niezawodnych WS oprócz integralności i poufności poszczególnych komunikatów, program WCF wymaga użycia bezpiecznej konwersacji WS.

  • R2302:Sesja konwersacji bezpiecznej na platformie AWS musi zostać ustanowiona przed ustanowieniem sekwencji komunikatów niezawodnych WS.

  • R2303: Jeśli okres istnienia sekwencji niezawodnej obsługi komunikatów WS przekracza okres istnienia sesji bezpiecznej konwersacji WS, SecurityContextToken ustanowiony przy użyciu bezpiecznej konwersacji WS musi zostać odnowiony przy użyciu odpowiedniego powiązania odnawiania konwersacji zabezpieczonej w usłudze WS.

  • B2304: Sekwencja niezawodnej obsługi komunikatów WS lub para skorelowanych sekwencji odwrotnych jest zawsze powiązana z pojedynczą sesją WS-SecureConversation.

    Źródło programu WCF generuje wsse:SecurityTokenReference element w sekcji rozszerzalności elementu komunikatu CreateSequence .

  • R2305: W przypadku skomponowania z funkcją konwersacji zabezpieczonej w programie WS komunikat CreateSequence musi zawierać wsse:SecurityTokenReference element .

WS-Reliable Messaging WS-Policy Assertion

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

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

  • B3002: Program WCF obsługuje następujące opcjonalne właściwości asercji WS-Reliable Messaging i zapewnia kontrolę nad nimi w programie WCFReliableMessagingBindingElement:

    • wsrm:InactivityTimeout

    • wsrm:AcknowledgementInterval

    Poniżej przedstawiono przykład.

    <wsrm:RMAssertion>
  <wsrm:InactivityTimeout Milliseconds="600000" />
  <wsrm:AcknowledgementInterval Milliseconds="200" />
</wsrm:RMAssertion>

Rozszerzenie niezawodnego obsługi komunikatów sterowania przepływem

WCF używa rozszerzalności komunikatów niezawodnych WS, aby zapewnić opcjonalną dodatkową ściślejszą kontrolę nad przepływem komunikató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 obsługi komunikatów program WCF generuje netrm:BufferRemaining element w rozszerzalności elementu nagłówka SequenceAcknowledgement .

  • B4002: Po włączeniu niezawodnego sterowania przepływem obsługi komunikatów program WCF nie wymaga netrm:BufferRemaining , aby element był obecny w SequenceAcknowledgement nagłówku, jak pokazano w poniższym przykładzie.

    <wsrm:SequenceAcknowledgement>
  <wsrm:Identifier>
    http://fabrikam123.com/abc
  </wsrm:Identifier>
  <wsrm:AcknowledgementRange Upper="1" Lower="1"/>
  <netrm:BufferRemaining>
    8
  </netrm:BufferRemaining>
</wsrm:SequenceAcknowledgement>

  • B4003: program WCF używa netrm:BufferRemaining funkcji , aby wskazać, ile nowych komunikatów może buforować miejsce docelowe usługi Reliable Messaging.

  • B4004: Usługa WCF Reliable Messaging ogranicza liczbę komunikatów przesyłanych, gdy aplikacja docelowa Reliable Messaging nie może szybko odbierać komunikatów. Miejsce docelowe reliable messaging buforuje komunikaty, a wartość elementu spadnie do 0.

  • 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 usługa WS-Reliable Messaging jest używana 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 inny niż adresowalny: inicjator znajduje się za zaporą; Obiekt odpowiadający 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, nienależący do adresu inicjator

Wiązanie

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 usługi RMS do usługi RMD i odpowiedzi HTTP w celu przesyłania wszystkich komunikatów z usługi RMD do usługi RMS.

CreateSequence Exchange

Inicjator WCF generuje CreateSequence komunikat bez oferty. Obiekt odpowiadający WCF zapewnia, CreateSequence że nie ma oferty przed utworzeniem sekwencji. Obiekt odpowiadający WCF odpowiada na CreateSequence żądanie z komunikatem CreateSequenceResponse .

Sequenceacknowledgement

Inicjator WCF przetwarza potwierdzenia odpowiedzi wszystkich komunikatów z wyjątkiem komunikatów CreateSequence i komunikatów o błędach. Odpowiedź WCF zawsze generuje autonomiczne potwierdzenie w odpowiedzi zarówno na sekwencję, jak i AckRequested komunikaty.

Komunikat TerminateSequence

WCF traktuje TerminateSequence jako jednokierunkową operację, co oznacza, że odpowiedź HTTP ma pustą treść i kod stanu HTTP 202.

Jeden ze sposobów, adresowalny inicjator

Wiązanie

Program WCF zapewnia jednokierunkowy wzorzec wymiany komunikatów przy użyciu jednej sekwencji dla ruchu przychodzącego i wychodzącego kanału 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 generuje CreateSequence komunikat bez oferty. Obiekt odpowiadający WCF gwarantuje, że CreateSequence nie ma oferty przed utworzeniem sekwencji. Obiekt odpowiadający WCF przesyła CreateSequenceResponse komunikat w żądaniu HTTP adresowanym przy użyciu odwołania do punktu końcowego ReplyTo .

Dwupoziomowy, adresowalny inicjator

Wiązanie

Program WCF zapewnia w pełni asynchroniczny wzorzec wymiany komunikatów dwukierunkowych przy użyciu dwóch sekwencji dla ruchu przychodzącego i wychodzącego kanału 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 generuje CreateSequence komunikat z ofertą. Osoba odpowiadająca WCF gwarantuje, że oferta jest CreateSequence oferowana przed utworzeniem sekwencji. Program WCF wysyła CreateSequenceResponse żądanie HTTP skierowane do odwołania do punktu końcowegoCreateSequenceReplyTo.

Okres istnienia sekwencji

Program WCF traktuje dwie sekwencje jako jedną w pełni dwudupleksowej sesji.

Podczas generowania błędu, który uszkodzi jedną sekwencję, program WCF oczekuje, że zdalny punkt końcowy będzie uszkodzić obie sekwencje. Podczas odczytywania błędu, który uszkodzi jedną sekwencję, błędy WCF obie sekwencje.

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.

Żądanie-odpowiedź, inicjator nienależący do adresu

Wiązanie

WCF zapewnia wzorzec 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 komunikatów sekwencji żądań i używa odpowiedzi HTTP do przesyłania komunikatów sekwencji odpowiedzi.

CreateSequence Exchange

Inicjator WCF generuje CreateSequence komunikat z ofertą. Osoba odpowiadająca WCF gwarantuje, że oferta jest CreateSequence oferowana przed utworzeniem sekwencji. Obiekt odpowiadający WCF odpowiada na CreateSequence żądanie z komunikatem CreateSequenceResponse .

Jednokierunkowa wiadomość

Aby pomyślnie ukończyć jednokierunkowy protokół wymiany komunikatów, inicjator WCF przesyła komunikat sekwencji żądań w żądaniu HTTP i odbiera autonomiczny SequenceAcknowledgement komunikat 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 potwierdzenie przesłanej wiadomości 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 chronometraż odpowiedzi aplikacji numer sekwencji żądań i numer sekwencji komunikatu odpowiedzi nie mają korelacji.

Ponów próbę 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 komunikatu sekwencji żądań, gdy komunikat sekwencji żądań jest potwierdzany, ale raczej wtedy, gdy odpowiedź HTTP prowadzi potwierdzenie, komunikat użytkownika lub błąd. Obiekt odpowiadający WCF ponawia próbę odpowiedzi na nogę żądania HTTP żądania, do którego jest skorelowana odpowiedź.

LastMessage Exchange

Inicjator WCF generuje i przesyła pusty komunikat o ostatnim ciele na nodze żądania HTTP. Program WCF wymaga odpowiedzi, ale ignoruje rzeczywisty komunikat odpowiedzi. Obiekt odpowiadający WCF odpowiada na pustą wiadomość sekwencji żądań z ostatnią wiadomością z pustą wiadomością sekwencji odpowiedzi.

Jeśli obiekt odpowiadający WCF otrzyma ostatni komunikat, w którym identyfikator URI akcji nie http://schemas.xmlsoap.org/ws/2005/02/rm/LastMessagejest , funkcja WCF odpowiada za pomocą ostatniego komunikatu. W przypadku dwukierunkowego protokołu wymiany komunikatów ostatni komunikat przenosi komunikat aplikacji; w przypadku jednokierunkowego protokołu wymiany komunikatów ostatnia wiadomość jest pusta.

Obiekt odpowiadający WCF nie wymaga potwierdzenia dla ostatniego komunikatu pustą sekwencję odpowiedzi.

TerminateSequence Exchange

Gdy wszystkie żądania otrzymały prawidłową odpowiedź, inicjator WCF generuje i przesyła komunikat sekwencji żądań TerminateSequence w nodze żądania HTTP. Program WCF wymaga odpowiedzi, ale ignoruje rzeczywisty komunikat odpowiedzi. Obiekt odpowiadający WCF odpowiada na komunikat sekwencji żądań TerminateSequence z komunikatem sekwencji TerminateSequence odpowiedzi.

W normalnej sekwencji zamykania oba TerminateSequence komunikaty niosą pełny zakres SequenceAcknowledgement.

Żądanie/odpowiedź, adresowalny inicjator

Wiązanie

Program WCF udostępnia wzorzec wymiany komunikatów z odpowiedzią na żądanie przy użyciu dwóch sekwencji dla ruchu przychodzącego i wychodzącego kanału 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 generuje CreateSequence komunikat z ofertą. Osoba odpowiadająca WCF gwarantuje, że oferta jest CreateSequence oferowana przed utworzeniem sekwencji. Program WCF wysyła CreateSequenceResponse żądanie HTTP skierowane do odwołania do punktu końcowegoCreateSequenceReplyTo.

Korelacja żądań/odpowiedzi

Inicjator WCF zapewnia, że wszystkie komunikaty żądań aplikacji mają MessageId odwołanie do punktu końcowego ReplyTo i . Inicjator WCF stosuje odwołanie do punktu końcowego komunikatu CreateSequenceReplyTo dla każdego komunikatu żądania aplikacji. Obiekt odpowiadający WCF wymaga, aby przychodzące komunikaty żądań nosiły MessageId element ReplyToi . Obiekt odpowiadający WCF zapewnia, że identyfikator URI odwołania do punktu końcowego dla wszystkich CreateSequence komunikatów żądań aplikacji i jest identyczny.