Udostępnij za pośrednictwem

Reliable Messaging Protocol w wersji 1,1

  • Artykuł

W tym temacie opisano szczegóły implementacji programu Windows Communication Foundation (WCF) dotyczące protokołu WS-ReliableMessaging z 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ół WS-ReliableMessaging z lutego 2007 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://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)

Obsługa komunikatów

Tworzenie sekwencji

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

  • B1101: Inicjator WCF używa tego samego odwołania do punktu końcowego co CreateSequence komunikat i AcksToReplyToOffer/Endpoint.

  • R1102: AcksToReplyTo odwołania do punktu końcowego i Offer/Endpoint w CreateSequence komunikacie muszą mieć wartości adresów z identycznymi reprezentacjami ciągów, tak aby były zgodne z oktetem-wise.

    • Obiekt odpowiadający WCF sprawdza, czy część identyfikatora URI odwołań do AcksTopunktu ReplyTo końcowego i jest Endpoint identyczna przed utworzeniem sekwencji.

  • R1103: AcksToReplyTo odwołania do punktu końcowego i Offer/Endpoint w CreateSequence komunikacie powinny mieć ten sam zestaw parametrów odwołania.

    • Program WCF nie wymusza, ale zakłada, że parametry referencyjne odwołań do elementu i Offer/Endpoint punktu końcowego są CreateSequence identyczne i używają parametrów AcksToReplyTo odwołania z ReplyTo odwołania do punktu końcowego do potwierdzenia i komunikatów sekwencji odwrotnych.

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

  • B1105: Podczas uzyskiwania dostępu do komunikatu CreateSequence funkcja odpowiadająca WCF używa Expires wartości w CreateSequence elemecie jako Expires wartości w elemecie CreateSequenceResponse . W przeciwnym razie obiekt odpowiadający WCF odczytuje i ignoruje Expires wartości i Offer/Expires .

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

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

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

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

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

  • B1110: Jeśli element odpowiadający reliable messaging odrzuca oferowaną sekwencję, inicjator WCF błędy nowo ustanowionej sekwencji.

  • B1111: Jeśli CreateSequence element nie zawiera Offer elementu, dwukierunkowy obiekt odpowiadający WCF odrzuca oferowaną sekwencję, odpowiadając na CreateSequenceRefused błąd.

  • R1112: Po ustanowieniu Offer dwóch sekwencji odwrotnych przy użyciu mechanizmu [address] właściwość CreateSequenceResponse/Accept/AcksTo odwołania do punktu końcowego musi być zgodna z docelowym identyfikatorem URI bajtu komunikatu CreateSequence dla bajtu.

  • R1113: Po ustanowieniu Offer dwóch sekwencji odwrotnych przy użyciu mechanizmu wszystkie komunikaty w obu sekwencjach przepływających z inicjatora do obiektu odpowiadającego muszą być wysyłane do tego samego odwołania do punktu końcowego.

WCF używa funkcji WS-ReliableMessaging do ustanawiania niezawodnych sesji między inicjatorem a obiektem odpowiadającym. Implementacja usługi WCF WS-ReliableMessaging zapewnia niezawodną sesję dla wzorców jednokierunkowych, żądań i pełnych dwukierunkowych komunikatów. Mechanizm WS-ReliableMessaging Offer w systemie CreateSequence i 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" potwierdzenia sekwencji komunikatów aplikacji. 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 niezawodnej obsługi komunikatów CloseSequence WCF zawsze wysyła komunikat, aby zamknąć sekwencję.

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

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

  • R1204: Miejsce docelowe reliable messaging nie może zainicjować zamknięcia przez wysłanie komunikatu CloseSequence .

  • B1205: Po otrzymaniu komunikatu CloseSequence źródło niezawodnej obsługi komunikatów programu WCF uznaje sekwencję za niekompletną i wysyła błąd.

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 przede wszystkim uzgadniania po zakończeniu CloseSequence/CloseSequenceResponse uzgadniania. Miejsce docelowe niezawodnej obsługi komunikatów WCF nie inicjuje zakończenia, a źródło reliable messaging nie obsługuje zakończenia inicjowanego przez miejsce docelowe usługi Reliable Messaging. Obowiązują następujące ograniczenia:

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

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

  • B1303: Podczas odbierania komunikatu TerminateSequenceCloseSequence/CloseSequenceResponse po uścisku dłoni miejsce docelowe Reliable Messaging odpowiada komunikatem TerminateSequenceResponse . Ponieważ źródło reliable messaging ma ostateczne potwierdzenie przed wysłaniem komunikatu TerminateSequence , miejsce docelowe reliable messaging wie bez wątpienia, że sekwencja kończy się i natychmiast odzyskuje zasoby.

  • B1304: Podczas odbierania komunikatu TerminateSequence przed CloseSequence/CloseSequenceResponse uściskiem dłoni miejsce docelowe niezawodnej obsługi komunikatów programu WCF odpowiada komunikatem TerminateSequenceResponse . Jeśli miejsce docelowe reliable messaging określi, że w sekwencji nie ma niespójności, miejsce docelowe reliable messaging czeka na określony czas docelowy aplikacji przed odzyskaniem zasobów, aby umożliwić klientowi uzyskanie ostatecznego potwierdzenia. W przeciwnym razie miejsce docelowe reliable messaging natychmiast odzyskuje zasoby i wskazuje na miejsce docelowe aplikacji, że sekwencja kończy się wątpliwości, podnosząc Faulted zdarzenie.

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ż xs:longmaksymalna wartość inkluzywna, 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 żą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>

Sequenceacknowledgement

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

  • R1601: Po ustanowieniu Offer dwóch sekwencji odwrotnych przy użyciu mechanizmu SequenceAcknowledgement nagłówek może zostać dołączony do dowolnego komunikatu aplikacji przesłanego do zamierzonego adresata. Zdalny punkt końcowy musi mieć dostęp do nagłówka piggybacked 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>

Błędy WS-ReliableMessaging

Poniżej znajduje się lista ograniczeń, które mają zastosowanie do implementacji WCF błędów WS-ReliableMessaging. 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 adresowania WS

Ponieważ usługa WS-ReliableMessaging używa adresowania WS, implementacja usługi WCF WS-ReliableMessaging może generować i przesyłać błędy adresowania WS. W tej sekcji omówiono błędy adresowania WS, 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:

    • CloseSequence Brak CreateSequencenagłówka , lub TerminateSequence komunikatuMessageId.

    • CloseSequence Brak CreateSequencenagłówka , lub TerminateSequence komunikatuReplyTo.

    • W CreateSequenceResponsenagłówku brakuje nagłówka RelatesTo , CloseSequenceResponselub TerminateSequenceResponse .

  • 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 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-ReliableMessaging 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 niezawodną obsługą komunikatów WS.

  • R2102: Pojedyncza wersja adresowania WS musi być używana w danej sekwencji WS-ReliableMessaging lub para 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 obsługą niezawodnych komunikatów WS.

Kompozycja z zabezpieczeniami usług WS i WS-SecureConversation

Program WCF zapewnia ochronę sekwencji WS-ReliableMessaging przy użyciu bezpiecznego transportu (HTTPS), kompozycji z zabezpieczeniami WS-Security oraz kompozycji z funkcją WS-Secure Conversation. Protokół WS-ReliableMessaging 1.1, WS-Security 1.1 i WS-Secure Conversation 1.3 należy używać 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 bezpiecznej konwersacji WS.

  • R2302: Przed ustanowieniem sekwencji WS-ReliableMessaging należy ustanowić sesję bezpiecznej konwersacji na platformie AWS.

  • R2303: Jeśli okres istnienia sekwencji WS-ReliableMessaging przekracza okres istnienia sesji konwersacji zabezpieczonej w programie WS, SecurityContextToken ustanowiony przy użyciu bezpiecznej konwersacji WS musi zostać odnowiony przy użyciu odpowiedniego powiązania odnawiania konwersacji zabezpieczonej w systemie WS.

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

  • R2305: W przypadku skomponowania się z funkcją WS-Secure Conversation osoba odpowiadająca WCF wymaga, aby CreateSequence komunikat zawierał wsse:SecurityTokenReference element i wsrm:UsesSequenceSTR nagłówek.

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ć CreateSequence komunikatu z nagłówkiem do obiektu odpowiadającego wsrm:UsesSequenceSSL WCF.

Kompozycja z usługą WS-Policy

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

WS-ReliableMessaging WS-Policy Assertion

WCF używa funkcji WS-ReliableMessaging WS-Policy Assertion wsrm:RMAssertion do opisania 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 wsrmn: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: WCF nigdy nie generuje tagu wsp:Optional .

  • B3003: Podczas uzyskiwania wsrmp:RMAssertion dostępu do asercji WS-Policy program WCF ignoruje wsp:Optional tag i traktuje zasady WS-RM jako obowiązkowe.

  • R3004: Ponieważ program WCF nie komponuje się z sesjami ssl/TLS, program WCF nie akceptuje zasad określających wsrmp:SequenceTransportSecuritywartość .

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

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

  • 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 WS-ReliableMessaging sterowania przepływem

WCF używa rozszerzalności WS-ReliableMessaging, 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 , 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 w przypadku włączenia kontrolki przepływu niezawodnej obsługi komunikatów program WCF nie wymaga netrm:BufferRemaining elementu w nagłówku SequenceAcknowledgement .

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

  • B4004:Po włączeniu niezawodnego sterowania przepływem obsługi komunikatów źródło niezawodnej obsługi komunikatów używa wartości do ograniczania transmisji komunikatów netrm:BufferRemaining .

  • 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 funkcja WS-ReliableMessaging 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ą; Osoba odpowiadająca 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 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 CreateSequence komunikat bez Offer elementu w żądaniu HTTP i oczekuje komunikatu CreateSequenceResponse w odpowiedzi HTTP. Obiekt odpowiadający WCF tworzy sekwencję i przesyła CreateSequenceResponse komunikat bez Accept elementu w odpowiedzi HTTP.

Sequenceacknowledgement

Inicjator WCF przetwarza potwierdzenia odpowiedzi wszystkich komunikatów z wyjątkiem komunikatów CreateSequence i komunikatów o błędach. Obiekt odpowiadający WCF zawsze przesyła autonomiczne potwierdzenie odpowiedzi HTTP do wszystkich sekwencji i AckRequested komunikatów.

CloseSequence Exchange

Inicjator WCF przesyła CloseSequence komunikat w żądaniu HTTP i oczekuje CreateSequenceResponse komunikatu w odpowiedzi HTTP. Obiekt odpowiadający WCF przesyła CloseSequenceResponse komunikat w odpowiedzi HTTP.

TerminateSequence Exchange

Inicjator WCF przesyła TerminateSequence komunikat w żądaniu HTTP i oczekuje TerminateSequenceResponse komunikatu w odpowiedzi HTTP. Obiekt odpowiadający WCF przesyła TerminateSequenceResponse komunikat w odpowiedzi HTTP.

Jeden ze sposobów, adresowalny inicjator

Wiązanie

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 przesyła CreateSequence komunikat bez Offer elementu w żądaniu HTTP. Obiekt odpowiadający WCF tworzy sekwencję i przesyła CreateSequenceResponse komunikat bez Accept elementu w żądaniu HTTP.

Dwupoziomowy, adresowalny inicjator

Wiązanie

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 CreateSequence komunikat z elementem Offer w żądaniu HTTP. Obiekt odpowiadający WCF gwarantuje, że CreateSequence element zawiera Offer element, a następnie tworzy sekwencję i przesyła CreateSequenceResponse komunikat za pomocą Accept elementu.

Okres istnienia sekwencji

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

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.

Request-Reply and One-Way, Non-Addressable Initiator

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 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 CreateSequence komunikat z elementem Offer żądania HTTP i oczekuje komunikatu CreateSequenceResponse w odpowiedzi HTTP. Obiekt odpowiadający WCF tworzy sekwencję i przesyła CreateSequenceResponse komunikat za pomocą Accept elementu w odpowiedzi HTTP.

Jednokierunkowa wiadomość

Aby pomyślnie ukończyć jednokierunkową wymianę 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. W związku z tym inicjator WCF nie przestaje ponawiać próby komunikatu sekwencji żądań, gdy komunikat sekwencji żądań jest potwierdzany, ale raczej wtedy, gdy odpowiedź HTTP prowadzi SequenceAcknowledgement, odpowiedź aplikacji lub błąd. Obiekt odpowiadający WCF ponawia próbę odpowiedzi na odpowiedź HTTP żądania, do którego jest skorelowana odpowiedź.

CloseSequence Exchange

Po otrzymaniu wszystkich komunikatów sekwencji odpowiedzi i potwierdzenia dla wszystkich komunikatów sekwencji żądań w jeden sposób inicjator WCF przesyła CloseSequence komunikat dla sekwencji żądań w żądaniu HTTP i oczekuje CloseSequenceResponse odpowiedzi HTTP.

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

Obiekt odpowiadający WCF zapewnia, że wszystkie odpowiedzi są potwierdzane i przesyłają CloseSequenceResponse komunikat w odpowiedzi HTTP.

TerminateSequence Exchange

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

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

Obiekt odpowiadający WCF przesyła TerminateSequenceResponse komunikat w odpowiedzi HTTP.

Żądanie/odpowiedź, adresowalny inicjator

Wiązanie

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 CreateSequence komunikat z elementem Offer w żądaniu HTTP. Obiekt odpowiadający WCF gwarantuje, że CreateSequence element zawiera Offer element, a następnie tworzy sekwencję i przesyła CreateSequenceResponse komunikat za pomocą Accept elementu.

Korelacja żądań/odpowiedzi

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

  • Usługa WCF zapewnia, że wszystkie komunikaty żądań aplikacji mają ReplyTo odwołanie do punktu końcowego MessageIdi .

  • Program WCF stosuje odwołanie do lokalnego punktu końcowego jako komunikat ReplyTożą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ń mają element MessageId i ReplyTo.

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

  • Program WCF zapewnia, że wszystkie odpowiedzi mają poprawne RelatesTo nagłówki i To następujące wsa reguły korelacji żądań/odpowiedzi.