Udostępnij przez

Reliable Messaging Protocol w wersji 1.0

W tym temacie opisano szczegóły implementacji programu Windows Communication Foundation (WCF) dla protokołu WS-Reliable Messaging luty 2005 (wersja 1.0) niezbędnego do współdziałania przy użyciu transportu HTTP. Program WCF jest zgodny ze specyfikacją WS-Reliable Messaging z ograniczeniami i wyjaśnieniami opisanymi w tym temacie. Należy pamiętać, ż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 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://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

Komunikacja

Sekwencja komunikatów o ustanowieniu

Program WCF implementuje CreateSequence i CreateSequenceResponse komunikaty, aby ustanowić niezawodną sekwencję wiadomości. Obowiązują następujące ograniczenia:

  • B1101: Inicjator WCF nie generuje opcjonalnego elementu Expires w CreateSequence komunikacie lub w przypadkach, gdy CreateSequence komunikat zawiera Offer element, opcjonalny Expires element w elemencie 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.

WS-Reliable Messaging wprowadza Offer mechanizm do ustanowienia dwóch odwrotnych skorelowanych sekwencji, które tworzą sesję.

  • R1103: Jeśli CreateSequence zawiera element Offer, Odbiorca niezawodnych komunikatów musi zaakceptować sekwencję i odpowiedzieć za pomocą CreateSequenceResponse zawierającego element wsrm:Accept, tworząc dwie przeciwnie skorelowane sekwencje, lub odrzucić żądanie CreateSequence.

  • R1104: SequenceAcknowledgement i komunikaty aplikacji przepływające na sekwencji odwrotnej ReplyTo 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 oktet po oktet.

    WCF Responder sprawdza, czy część identyfikatora URI AcksTo i ReplyTo EPR są identyczne przed utworzeniem sekwencji.

  • R1106: Referencje punktu końcowego AcksTo i ReplyTo w CreateSequence powinny mieć ten sam zestaw parametrów referencyjnych.

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

  • R1107: Kiedy dwie sekwencje odwrotne są ustanawiane przy użyciu mechanizmu Offer, SequenceAcknowledgement a komunikaty aplikacyjne przepływające na tych sekwencjach muszą być wysyłane do punktu końcowego ReplyTo obiektu CreateSequence.

  • R1108: Po ustanowieniu dwóch sekwencji odwrotnych przy użyciu mechanizmu Oferty, właściwość [address] podrzędnego elementu Odwołania Punktu Końcowego elementu wsrm:AcksTo musi być zgodna bajtowo z docelowym identyfikatorem URI elementu wsrm:Accept.

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

    WCF używa WS-Reliable Messaging do ustanawiania niezawodnych sesji między inicjatorem i odpowiadającym. Implementacja obsługi komunikatów WS-Reliable WCF zapewnia niezawodną sesję dla jednokierunkowych, żądanie-odpowiedź i pełnych dupleks wzorców komunikatów. Mechanizm WS-Reliable Messaging Offer na CreateSequence/CreateSequenceResponse umożliwia ustanowienie dwóch skorelowanych sekwencji konwersacyjnych 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. Umożliwia to również dołączanie potwierdzeń sekwencji do komunikatów 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>

Kolejność

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ż maksymalna wartość xs:long włącznie, 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 element LastMessage, jeśli identyfikator URI akcji nie jest http://schemas.xmlsoap.org/ws/2005/02/rm/LastMessage.

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, który zawiera element AckRequestedMessageNumber, program WCF ignoruje wartość elementu MessageNumber, 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 potwierdzeń sekwencji podanych w WS-Reliable Messaging.

  • R1401: Gdy przy użyciu mechanizmu Offer ustanowione zostaną dwie sekwencje odwrotne, nagłówek SequenceAcknowledgement może zostać uwzględniony w każdym komunikacie aplikacji przesłanym do zamierzonego adresata.

  • B1402: Kiedy WCF musi wygenerować potwierdzenie przed odebraniem jakichkolwiek komunikatów sekwencyjnych (na przykład w celu spełnienia komunikatu AckRequested), WCF generuje nagłówek SequenceAcknowledgement zawierający zakres 0-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 nagłówków SequenceAcknowledgement zawierających element Nack, ale obsługuje elementy Nack.

WS-ReliableMessaging błędy

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

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

  • Punkt końcowy B1502: WCF może generować błędy CreateSequenceRefused, jak opisano w specyfikacji.

  • 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 WS-Addressing

Ponieważ WS-Reliable Messaging używa adresowania WS, implementacja komunikatów WCF WS-Reliable może generować błędy WS-Addressing. W tej sekcji omówiono błędy WS-Addressing, które usługa WCF generuje jawnie w warstwie komunikacyjnej WS-Reliable.

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

    • Brak w komunikacie nagłówka Sequence i nagłówka Action.

    • Brak nagłówka CreateSequence w wiadomości MessageId.

    • Brak nagłówka CreateSequence w wiadomości ReplyTo.

  • B1602: WCF generuje błąd: Akcja Nieobsługiwana w odpowiedzi na komunikat, który nie ma nagłówka Sequence i ma nagłówek Action, który nie jest zgodny ze specyfikacją Messaging WS-Reliable.

  • 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 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-Reliable Messaging 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.

  • pl-PL: R2102: Pojedyncza wersja WS-Addressing musi być używana w ramach danej sekwencji WS-Reliable komunikatów lub pary sekwencji odwrotnych skorelowanych przy użyciu mechanizmu wsrm:Offer.

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-Reliable Messaging przy użyciu bezpiecznego Transportu (HTTPS), kompozycji z użyciem zabezpieczeń WS-Security oraz kompozycji z użyciem WS-Secure Conversation. Poniżej znajduje się lista ograniczeń, które mają zastosowanie do programu WCF:

  • R2301: Aby chronić integralność sekwencji komunikatów WS-Reliable oraz integralność i poufność poszczególnych wiadomości, program WCF wymaga użycia WS-Secure Conversation.

  • R2302:AWS-Secure Sesja konwersacji musi zostać ustanowiona przed ustanowieniem WS-Reliable sekwencji wymiany wiadomości.

  • R2303: Jeśli czas trwania sekwencji wiadomości WS-Reliable przekracza czas trwania sesji konwersacji WS-Secure, SecurityContextToken ustanowiony przy użyciu WS-Secure konwersacja musi zostać odnowiony za pomocą odpowiedniego powiązania odnowienia konwersacji WS-Secure.

  • B2304: sekwencja komunikatówWS-Reliable lub para skorelowanych sekwencji odwrotnych jest zawsze powiązana z jedną sesją WS-SecureConversation.

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

  • R2305: Gdy skomponowane z WS-Secure Konwersacja, wiadomość CreateSequence musi zawierać element wsse:SecurityTokenReference.

obsługa komunikatów WS-Reliable asercji WS-Policy

WCF używa WS-Reliable Messaging WS-Policy Assertion 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ę wsrm: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 obsługuje następujące opcjonalne właściwości asercji WS-Reliable Messaging i umożliwia ich kontrolę w WCFReliableMessagingBindingElement:

    • wsrm:InactivityTimeout

    • wsrm:AcknowledgementInterval

    Poniżej przedstawiono przykład.

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

Rozszerzenie komunikatów sterowania przepływem WS-Reliable

WCF używa rozszerzalności komunikatów WS-Reliable, aby zapewnić opcjonalnie dodatkową, bardziej ścisłą kontrolę nad ruchem 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 wiadomości, program WCF generuje element netrm:BufferRemaining w rozszerzalności nagłówka SequenceAcknowledgement.

  • B4002: Po włączeniu sterowania przepływem dla niezawodnej obsługi komunikatów WCF nie wymaga obecności elementu netrm:BufferRemaining w nagłówku SequenceAcknowledgement, 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: WCF używa netrm:BufferRemaining do wskazania, ile nowych komunikatów może buforować miejsce docelowe w usłudze 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 niezawodnego przesyłania wiadomości buforuje wiadomości, a wartość elementu spada 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 usługi WCF, gdy używane jest WS-Reliable Messaging 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:

  • Nieadresowalny inicjator: Inicjator znajduje się za zaporą; 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 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, że CreateSequence nie ma oferty przed utworzeniem sekwencji. Responder WCF odpowiada na żądanie CreateSequence komunikatem CreateSequenceResponse.

Potwierdzenie Sekwencji

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

Komunikat TerminateSequence

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

Jednokierunkowy, adresowalny inicjator

Wiążący

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. Responder WCF zapewnia, że CreateSequence nie zawiera żadnej oferty przed utworzeniem sekwencji. Responder WCF przesyła wiadomość CreateSequenceResponse w żądaniu HTTP z odniesieniem do punktu końcowego ReplyTo.

Dwupoziomowy, adresowalny inicjator

Wiążący

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ą. Odpowiedź WCF zapewnia, że CreateSequence ma ofertę przed utworzeniem sekwencji. WCF wysyła CreateSequenceResponse w żądaniu HTTP skierowanym do odwołania do punktu końcowego CreateSequenceReplyTo.

Okres istnienia sekwencji

Program WCF traktuje dwie sekwencje jako jedną dwudupleksową 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.

Żądanie-odpowiedź, inicjator nieadresowalny

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 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ą. Odpowiedź WCF zapewnia, że CreateSequence ma ofertę przed utworzeniem sekwencji. Responder WCF odpowiada na żądanie CreateSequence 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 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 wysyłania komunikatu sekwencji żądań, gdy komunikat sekwencji jest potwierdzany, lecz dopiero wtedy, gdy odpowiedź HTTP zawiera potwierdzenie, komunikat użytkowy lub błąd. Obiekt odpowiadający WCF ponawia próbę odpowiedzi na część żądania HTTP, z którym odpowiedź jest skorelowana.

LastMessage Exchange

Inicjator WCF generuje i przesyła ostatni komunikat o pustej treści w ramach żądania HTTP. Program WCF wymaga odpowiedzi, ale ignoruje rzeczywisty komunikat odpowiedzi. Obiekt odpowiadający WCF odpowiada na ostatnią pustą wiadomość sekwencji żądań ostatnią pustą wiadomością sekwencji odpowiedzi.

Jeśli obiekt odpowiadający WCF otrzyma ostatni komunikat, w którym identyfikator URI akcji nie jest http://schemas.xmlsoap.org/ws/2005/02/rm/LastMessage, WCF odpowiada ostatnim komunikatem. 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.

Reagujący WCF nie wymaga potwierdzenia dla ostatniej wiadomości w sekwencji odpowiedzi, która ma pustą treść.

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. The WCF Responder odpowiada na komunikat sekwencji żądań TerminateSequence, wysyłając komunikat sekwencji odpowiedzi TerminateSequence.

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

Żądanie/odpowiedź, adresowalny inicjator

Wiążący

WCF zapewnia wzorzec wymiany komunikatów typu żądanie-odpowiedź, wykorzystując dwie sekwencje na odpowiednich dla nich kanałach HTTP — przychodzących i wychodzących. 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ą. Odpowiedź WCF zapewnia, że CreateSequence ma ofertę przed utworzeniem sekwencji. WCF wysyła CreateSequenceResponse w żądaniu HTTP skierowanym do odwołania do punktu końcowego CreateSequenceReplyTo.

Korelacja żądań/odpowiedzi

Inicjator WCF zapewnia, że wszystkie komunikaty żądań aplikacji mają MessageId i ReplyTo odwołanie do punktu końcowego. 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ń zawierały MessageId oraz ReplyTo. Obiekt odpowiadający WCF zapewnia, że identyfikator URI odwołania do punktu końcowego dla elementu CreateSequence oraz wszystkich komunikatów żądań aplikacji są identyczne.

  • Last updated on