Introduktion till routning

Routningstjänsten tillhandahåller en allmän SOAP-mellanhand som kan dirigera meddelanden baserat på meddelandeinnehåll. Med routningstjänsten kan du skapa komplex routningslogik som gör att du kan implementera scenarier som tjänstaggregering, tjänstversionshantering, prioritetsroutning och multicast-routning. Routningstjänsten innehåller också felhantering som gör att du kan konfigurera listor över säkerhetskopieringsslutpunkter, till vilka meddelanden som skickas om ett fel inträffar när du skickar till den primära målslutpunkten.

Det här avsnittet är avsett för de som är nya i routningstjänsten och omfattar grundläggande konfiguration och värd för routningstjänsten.

Konfiguration

Routningstjänsten implementeras som en WCF-tjänst som exponerar en eller flera tjänstslutpunkter som tar emot meddelanden från klientprogram och dirigerar meddelandena till en eller flera målslutpunkter. Tjänsten tillhandahåller en RoutingBehavior, som tillämpas på tjänstslutpunkterna som exponeras av tjänsten. Det här beteendet används för att konfigurera olika aspekter av hur tjänsten fungerar. För enkel konfiguration när du använder en konfigurationsfil anges parametrarna i RoutingBehavior. I kodbaserade scenarier anges dessa parametrar som en del av ett RoutingConfiguration objekt, som sedan kan skickas till en RoutingBehavior.

När du startar lägger det här beteendet SoapProcessingBehaviortill , som används för att utföra SOAP-bearbetning av meddelanden, till klientslutpunkterna. På så sätt kan routningstjänsten överföra meddelanden till slutpunkter som kräver en annan MessageVersion än slutpunkten som meddelandet togs emot över. RoutingBehavior registrerar också ett tjänsttillägg, , RoutingExtensionsom tillhandahåller en tillgänglighetspunkt för att ändra konfigurationen av routningstjänsten vid körning.

Klassen RoutingConfiguration ger ett konsekvent sätt att konfigurera och uppdatera konfigurationen av routningstjänsten. Den innehåller parametrar som fungerar som inställningar för routningstjänsten och används för att konfigurera RoutingBehavior när tjänsten startar eller skickas till RoutingExtension för att ändra routningskonfigurationen vid körning.

Routningslogik som används för att utföra innehållsbaserad routning av meddelanden definieras genom att flera MessageFilter objekt grupperas i filtertabeller (MessageFilterTable<TFilterData> objekt). Inkommande meddelanden utvärderas mot de meddelandefilter som finns i filtertabellen och för varje MessageFilter som matchar meddelandet vidarebefordras till en målslutpunkt. Filtertabellen som ska användas för att dirigera meddelanden anges med hjälp av antingen RoutingBehavior i konfigurationen eller via kod med hjälp av objektet RoutingConfiguration .

Definiera slutpunkter

Även om det kan tyckas att du bör starta konfigurationen genom att definiera den routningslogik som du ska använda, bör ditt första steg faktiskt vara att fastställa formen på slutpunkterna som du dirigerar meddelanden till. Routningstjänsten använder kontrakt som definierar formen på de kanaler som används för att ta emot och skicka meddelanden, och därför måste indatakanalens form matcha utdatakanalens form. Om du till exempel dirigerar till slutpunkter som använder kanalformen request-reply måste du använda ett kompatibelt kontrakt på de inkommande slutpunkterna, till exempel IRequestReplyRouter.

Det innebär att om målslutpunkterna använder kontrakt med flera kommunikationsmönster (till exempel att blanda enkelriktade och dubbelriktade åtgärder) kan du inte skapa en enda tjänstslutpunkt som kan ta emot och dirigera meddelanden till dem alla. Du måste bestämma vilka slutpunkter som har kompatibla former och definiera en eller flera tjänstslutpunkter som ska användas för att ta emot meddelanden som ska dirigeras till målslutpunkterna.

Kommentar

När du arbetar med kontrakt som anger flera kommunikationsmönster (till exempel en blandning av enkelriktade och dubbelriktade åtgärder) är en lösning att använda ett duplex-kontrakt i routningstjänsten, IDuplexSessionRoutertill exempel . Det innebär dock att bindningen måste kunna kommunicera duplex, vilket kanske inte är möjligt för alla scenarier. I scenarier där detta inte är möjligt kan det vara nödvändigt att räkna in kommunikationen i flera slutpunkter eller ändra programmet.

Mer information om routningskontrakt finns i Routningskontrakt.

När tjänstslutpunkten har definierats kan du använda RoutingBehavior för att associera en specifik RoutingConfiguration med slutpunkten. När du konfigurerar routningstjänsten med hjälp av en konfigurationsfil används RoutingBehavior för att ange den filtertabell som innehåller routningslogik som används för att bearbeta meddelanden som tagits emot på den här slutpunkten. Om du konfigurerar routningstjänsten programmatiskt kan du ange filtertabellen med hjälp av RoutingConfiguration.

I följande exempel definieras de tjänst- och klientslutpunkter som används av routningstjänsten både programmatiskt och med hjälp av en konfigurationsfil.

<services>
  <!--ROUTING SERVICE -->
  <service behaviorConfiguration="routingData"
            name="System.ServiceModel.Routing.RoutingService">
    <host>
      <baseAddresses>
        <add baseAddress="http://localhost:8000/routingservice/router"/>
      </baseAddresses>
    </host>
    <!-- Define the service endpoints that are receive messages -->
    <endpoint address=""
              binding="wsHttpBinding"
              name="reqReplyEndpoint"
              contract="System.ServiceModel.Routing.IRequestReplyRouter" />
  </service>
</services>
<behaviors>
  <serviceBehaviors>
    <behavior name="routingData">
      <serviceMetadata httpGetEnabled="True"/>
      <!-- Add the RoutingBehavior and specify the Routing Table to use -->
      <routing filterTableName="routingTable1" />
    </behavior>
  </serviceBehaviors>
</behaviors>
<client>
<!-- Define the client endpoint(s) to route messages to -->
  <endpoint name="CalculatorService"
            address="http://localhost:8000/servicemodelsamples/service"
            binding="wsHttpBinding" contract="*" />
</client>

//set up some communication defaults
string clientAddress = "http://localhost:8000/servicemodelsamples/service";
string routerAddress = "http://localhost:8000/routingservice/router";
Binding routerBinding = new WSHttpBinding();
Binding clientBinding = new WSHttpBinding();
//add the endpoint the router uses to receive messages
serviceHost.AddServiceEndpoint(
     typeof(IRequestReplyRouter),
     routerBinding,
     routerAddress);
//create the client endpoint the router routes messages to
ContractDescription contract = ContractDescription.GetContract(
     typeof(IRequestReplyRouter));
ServiceEndpoint client = new ServiceEndpoint(
     contract,
     clientBinding,
     new EndpointAddress(clientAddress));
//create a new routing configuration object
RoutingConfiguration rc = new RoutingConfiguration();
….
rc.FilterTable.Add(new MatchAllMessageFilter(), endpointList);
//attach the behavior to the service host
serviceHost.Description.Behaviors.Add(
     new RoutingBehavior(rc));

I det här exemplet konfigureras routningstjänsten så att den exponerar en enskild slutpunkt med adressen http://localhost:8000/routingservice/router, som används för att ta emot meddelanden som ska dirigeras. Eftersom meddelandena dirigeras till slutpunkter för begärandesvar använder IRequestReplyRouter tjänstslutpunkten kontraktet. Den här konfigurationen definierar också en enskild klientslutpunkt http://localhost:8000/servicemodelsample/service för meddelanden som dirigeras till. Filtertabellen (visas inte) med namnet "routingTable1" innehåller den routningslogik som används för att dirigera meddelanden och är associerad med tjänstslutpunkten med hjälp av RoutingBehavior (för en konfigurationsfil) eller RoutingConfiguration (för programmatisk konfiguration).

Routningslogik

Om du vill definiera routningslogik som används för att dirigera meddelanden måste du fastställa vilka data som finns i inkommande meddelanden som kan hanteras unikt. Om till exempel alla målslutpunkter som du dirigerar för att dela samma SOAP-åtgärder är värdet för åtgärden i meddelandet inte en bra indikator på vilken specifik slutpunkt meddelandet ska dirigeras till. Om du måste dirigera meddelanden unikt till en specifik slutpunkt bör du filtrera efter data som unikt identifierar målslutpunkten som meddelandet dirigeras till.

Routningstjänsten innehåller flera MessageFilter-implementeringar som inspekterar specifika värden i meddelandet, till exempel adress, åtgärd, slutpunktsnamn eller till och med en XPath-fråga. Om ingen av dessa implementeringar uppfyller dina behov kan du skapa en anpassad MessageFilter-implementering . Mer information om meddelandefilter och en jämförelse av de implementeringar som används av routningstjänsten finns i Meddelandefilter och Välja ett filter.

Flera meddelandefilter ordnas tillsammans i filtertabeller, som associerar varje MessageFilter med en målslutpunkt. Du kan också använda filtertabellen för att ange en lista över säkerhetskopieringsslutpunkter som routningstjänsten försöker skicka meddelandet till i händelse av ett överföringsfel.

Som standard utvärderas alla meddelandefilter i en filtertabell samtidigt. Du kan dock ange en Priority som gör att meddelandefiltren utvärderas i en viss ordning. Alla poster med högsta prioritet utvärderas först och meddelandefilter med lägre prioritet utvärderas inte om en matchning hittas på en högre prioritetsnivå. Mer information om filtertabeller finns i Meddelandefilter.

I följande exempel används MatchAllMessageFilter, som utvärderas till true för alla meddelanden. Det här MessageFilter läggs till i filtertabellen "routingTable1", som associerar MessageFilter med klientslutpunkten med namnet "CalculatorService". RoutingBehavior anger sedan att den här tabellen ska användas för att dirigera meddelanden som bearbetas av tjänstslutpunkten.

<behaviors>
  <serviceBehaviors>
    <behavior name="routingData">
      <serviceMetadata httpGetEnabled="True"/>
      <!-- Add the RoutingBehavior and specify the Routing Table to use -->
      <routing filterTableName="routingTable1" />
    </behavior>
  </serviceBehaviors>
</behaviors>
<!--ROUTING SECTION -->
<routing>
  <filters>
    <filter name="MatchAllFilter1" filterType="MatchAll" />
  </filters>
  <filterTables>
    <table name="routingTable1">
      <filters>
        <add filterName="MatchAllFilter1" endpointName="CalculatorService" />
      </filters>
    </table>
  </filterTables>
</routing>

//create a new routing configuration object
RoutingConfiguration rc = new RoutingConfiguration();
//create the endpoint list that contains the endpoints to route to
//in this case we have only one
List<ServiceEndpoint> endpointList = new List<ServiceEndpoint>();
endpointList.Add(client);
//add a MatchAll filter to the Router's filter table
//map it to the endpoint list defined earlier
//when a message matches this filter, it is sent to the endpoint contained in the list
rc.FilterTable.Add(new MatchAllMessageFilter(), endpointList);

Kommentar

Som standard utvärderar routningstjänsten endast meddelandehuvudena. Om du vill tillåta att filtren får åtkomst till meddelandetexten måste du ange RouteOnHeadersOnly till false.

Multicast

Många routningstjänstkonfigurationer använder exklusiv filterlogik som dirigerar meddelanden till endast en specifik slutpunkt, men du kan behöva dirigera ett visst meddelande till flera målslutpunkter. För att multicasta ett meddelande till flera mål måste följande villkor vara uppfyllda:

• Kanalformen får inte vara begärandesvar (men kan vara enkelriktad eller duplex) eftersom endast ett svar kan tas emot av klientprogrammet som svar på begäran.

• Flera filter måste returneras true när meddelandet utvärderas.

Om dessa villkor uppfylls dirigeras meddelandet till alla slutpunkter för alla filter som utvärderas till true. I följande exempel definieras en routningskonfiguration som resulterar i att meddelanden dirigeras till båda slutpunkterna om slutpunktsadressen i meddelandet är http://localhost:8000/routingservice/router/rounding.

<!--ROUTING SECTION -->
<routing>
  <filters>
    <filter name="MatchAllFilter1" filterType="MatchAll" />
    <filter name="RoundingFilter1" filterType="EndpointAddress"
            filterData="http://localhost:8000/routingservice/router/rounding" />
  </filters>
  <filterTables>
    <table name="routingTable1">
      <filters>
        <add filterName="MatchAllFilter1" endpointName="CalculatorService" />
        <add filterName="RoundingFilter1" endpointName="RoundingCalcService" />
      </filters>
    </table>
  </filterTables>
</routing>

rc.FilterTable.Add(new MatchAllMessageFilter(), calculatorEndpointList);
rc.FilterTable.Add(new EndpointAddressMessageFilter(new EndpointAddress(
    "http://localhost:8000/routingservice/router/rounding")),
    roundingCalcEndpointList);

SOAP-bearbetning

För att stödja routning av meddelanden mellan olika protokoll lägger RoutingBehavior som standard till alla SoapProcessingBehavior klientslutpunkter som meddelanden dirigeras till. Det här beteendet skapar automatiskt en ny MessageVersion innan meddelandet dirigeras till slutpunkten, samt skapar en kompatibel MessageVersion för alla svarsdokument innan det returneras till det begärande klientprogrammet.

Stegen för att skapa en ny MessageVersion för det utgående meddelandet är följande:

Bearbetning av begäranden

• Hämta MessageVersion för utgående bindning/kanal.

• Hämta brödtextläsaren för det ursprungliga meddelandet.

• Skapa ett nytt meddelande med samma åtgärd, brödtextläsare och en ny MessageVersion.

• Om Addressing != Addressing.None kopierar du rubrikerna Till, Från, FaultTo och RelatesTo till det nya meddelandet.

• Kopiera alla meddelandeegenskaper till det nya meddelandet.

• Lagra det ursprungliga begärandemeddelandet som ska användas när svaret bearbetas.

• Returnera det nya begärandemeddelandet.

Svarsbearbetning

• Hämta MessageVersion för det ursprungliga begärandemeddelandet.

• Hämta brödtextläsaren för det mottagna svarsmeddelandet.

• Skapa ett nytt svarsmeddelande med samma åtgärd, brödtextläsare och MessageVersion för det ursprungliga begärandemeddelandet.

• Om Addressing != Addressing.None kopierar du rubrikerna Till, Från, FaultTo och RelatesTo till det nya meddelandet.

• Kopiera meddelandeegenskaperna till det nya meddelandet.

• Returnera det nya svarsmeddelandet.

Som standard läggs SoapProcessingBehavior automatiskt till i klientslutpunkterna av RoutingBehavior när tjänsten startar. Du kan dock styra om SOAP-bearbetning läggs till i alla klientslutpunkter med hjälp SoapProcessingEnabled av egenskapen . Du kan också lägga till beteendet direkt till en specifik slutpunkt och aktivera eller inaktivera det här beteendet på slutpunktsnivå om en mer detaljerad kontroll av SOAP-bearbetning krävs.

Kommentar

Om SOAP-bearbetning har inaktiverats för en slutpunkt som kräver en annan MessageVersion än det ursprungliga begärandemeddelandet måste du ange en anpassad mekanism för att utföra alla SOAP-ändringar som krävs innan du skickar meddelandet till målslutpunkten.

I följande exempel används egenskapen soapProcessingEnabled för att förhindra att SoapProcessingBehavior läggs till automatiskt i alla klientslutpunkter.

<behaviors>
  <!--default routing service behavior definition-->
  <serviceBehaviors>
    <behavior name="routingConfiguration">
      <routing filterTableName="filterTable1" soapProcessingEnabled="false"/>
    </behavior>
  </serviceBehaviors>
</behaviors>

//create the default RoutingConfiguration
RoutingConfiguration rc = new RoutingConfiguration();
rc.SoapProcessingEnabled = false;

Dynamisk konfiguration

När du lägger till ytterligare klientslutpunkter eller behöver ändra filtren som används för att dirigera meddelanden måste du ha ett sätt att uppdatera konfigurationen dynamiskt vid körning för att förhindra att tjänsten avbryts till de slutpunkter som för närvarande tar emot meddelanden via routningstjänsten. Det räcker inte alltid att ändra en konfigurationsfil eller koden för värdprogrammet, eftersom någon av metoderna kräver att programmet återanvänds, vilket skulle leda till potentiell förlust av meddelanden som för närvarande överförs och risken för stilleståndstid i väntan på att tjänsten ska startas om.

Du kan bara ändra RoutingConfiguration programmatiskt. Du kan först konfigurera tjänsten med hjälp av en konfigurationsfil, men du kan bara ändra konfigurationen vid körning genom att konstruera en ny RoutingConfiguration och skicka den som en parameter till den ApplyConfiguration metod som exponeras av RoutingExtension tjänsttillägget. Alla meddelanden som för närvarande överförs fortsätter att dirigeras med hjälp av den tidigare konfigurationen, medan meddelanden som tas emot efter anropet till ApplyConfiguration använder den nya konfigurationen. I följande exempel visas hur du skapar en instans av routningstjänsten och sedan ändrar konfigurationen.

RoutingConfiguration routingConfig = new RoutingConfiguration();
routingConfig.RouteOnHeadersOnly = true;
routingConfig.FilterTable.Add(new MatchAllMessageFilter(), endpointList);
RoutingBehavior routing = new RoutingBehavior(routingConfig);
routerHost.Description.Behaviors.Add(routing);
routerHost.Open();
// Construct a new RoutingConfiguration
RoutingConfiguration rc2 = new RoutingConfiguration();
ServiceEndpoint clientEndpoint = new ServiceEndpoint();
ServiceEndpoint clientEndpoint2 = new ServiceEndpoint();
// Add filters to the FilterTable in the new configuration
rc2.FilterTable.add(new MatchAllMessageFilter(),
       new List<ServiceEndpoint>() { clientEndpoint });
rc2.FilterTable.add(new MatchAllMessageFilter(),
       new List<ServiceEndpoint>() { clientEndpoint2 });
rc2.RouteOnHeadersOnly = false;
// Apply the new configuration to the Routing Service hosted in
routerHost.routerHost.Extensions.Find<RoutingExtension>().ApplyConfiguration(rc2);

Kommentar

När du uppdaterar routningstjänsten på det här sättet går det bara att skicka en ny konfiguration. Det går inte att ändra endast valda element i den aktuella konfigurationen eller lägga till nya poster i den aktuella konfigurationen. du måste skapa och skicka en ny konfiguration som ersätter den befintliga.

Kommentar

Alla sessioner som öppnats med den tidigare konfigurationen fortsätter att använda den tidigare konfigurationen. Den nya konfigurationen används endast av nya sessioner.

Felhantering

Om något CommunicationException påträffas vid försök att skicka ett meddelande utförs felhantering. Dessa undantag indikerar vanligtvis att ett problem påträffades vid försök att kommunicera med den definierade klientslutpunkten, till exempel en EndpointNotFoundException, ServerTooBusyExceptioneller CommunicationObjectFaultedException. Felhanteringskoden fångar också upp och försöker skicka igen när en inträffar, vilket är ett TimeoutException annat vanligt undantag som inte härleds från CommunicationException.

När något av de föregående undantagen inträffar redundansväxlar routningstjänsten över till en lista över slutpunkter för säkerhetskopiering. Om alla slutpunkter för säkerhetskopiering misslyckas med ett kommunikationsfel, eller om en slutpunkt returnerar ett undantag som indikerar ett fel i måltjänsten, returnerar routningstjänsten ett fel till klientprogrammet.

Kommentar

Funktionen för felhantering samlar in och hanterar undantag som inträffar vid försök att skicka ett meddelande och när du försöker stänga en kanal. Felhanteringskoden är inte avsedd att identifiera eller hantera undantag som skapats av de programslutpunkter som den kommunicerar med. en FaultException som genereras av en tjänst visas i routningstjänsten som en FaultMessage och flödas tillbaka till klienten.

Om ett fel uppstår när routningstjänsten försöker vidarebefordra ett meddelande kan du få ett FaultException på klientsidan, i stället för ett EndpointNotFoundException som du normalt skulle få i avsaknad av routningstjänsten. En routningstjänst kan därför maskera undantag och inte ge fullständig transparens om du inte undersöker kapslade undantag.

Spårningsfel

När det inte går att skicka ett meddelande till en slutpunkt i en lista spårar routningstjänsten resulterande undantagsdata och bifogar undantagsinformationen som en meddelandeegenskap med namnet Undantag. Detta bevarar undantagsdata och tillåter programmatisk åtkomst via en meddelandekontroll. Undantagsdata lagras per meddelande i en ordlista som mappar slutpunktsnamnet till undantagsinformationen som påträffades när ett meddelande skulle skickas till den.

Slutpunkter för säkerhetskopiering

Varje filterpost i filtertabellen kan också ange en lista över slutpunkter för säkerhetskopiering, som används i händelse av ett överföringsfel när de skickas till den primära slutpunkten. Om ett sådant fel inträffar försöker routningstjänsten överföra meddelandet till den första posten i listan över slutpunkter för säkerhetskopiering. Om det här sändningsförsöket också stöter på ett överföringsfel provas nästa slutpunkt i listan över säkerhetskopior. Routningstjänsten fortsätter att skicka meddelandet till varje slutpunkt i listan tills meddelandet har tagits emot, alla slutpunkter returnerar ett överföringsfel eller ett icke-överföringsfel returneras av en slutpunkt.

I följande exempel konfigureras routningstjänsten för att använda en säkerhetskopieringslista.

<routing>
  <filters>
    <!-- Create a MatchAll filter that catches all messages -->
    <filter name="MatchAllFilter1" filterType="MatchAll" />
  </filters>
  <filterTables>
    <!-- Set up the Routing Service's Message Filter Table -->
    <filterTable name="filterTable1">
        <!-- Add an entry that maps the MatchAllMessageFilter to the dead destination -->
        <!-- If that endpoint is down, tell the Routing Service to try the endpoints -->
        <!-- Listed in the backupEndpointList -->
        <add filterName="MatchAllFilter1" endpointName="deadDestination" backupList="backupEndpointList"/>
    </filterTable>
  </filterTables>
  <!-- Create the backup endpoint list -->
  <backupLists>
    <!-- Add an endpoint list that contains the backup destinations -->
    <backupList name="backupEndpointList">
      <add endpointName="realDestination" />
      <add endpointName="backupDestination" />
    </backupList>
  </backupLists>
</routing>

//create the endpoint list that contains the service endpoints we want to route to
List<ServiceEndpoint> backupList = new List<ServiceEndpoint>();
//add the endpoints in the order that the Routing Service should contact them
//first add the endpoint that we know is down
//clearly, normally you wouldn't know that this endpoint was down by default
backupList.Add(fakeDestination);
//then add the real Destination endpoint
//the Routing Service attempts to send to this endpoint only if it
//encounters a TimeOutException or CommunicationException when sending
//to the previous endpoint in the list.
backupList.Add(realDestination);
//add the backupDestination endpoint
//the Routing Service attempts to send to this endpoint only if it
//encounters a TimeOutException or CommunicationsException when sending
//to the previous endpoints in the list
backupList.Add(backupDestination);
//create the default RoutingConfiguration option
RoutingConfiguration rc = new RoutingConfiguration();
//add a MatchAll filter to the Routing Configuration's filter table
//map it to the list of endpoints defined above
//when a message matches this filter, it is sent to the endpoints in the list in order
//if an endpoint is down or does not respond (which the first endpoint won't
//since the client does not exist), the Routing Service automatically moves the message
//to the next endpoint in the list and try again.
rc.FilterTable.Add(new MatchAllMessageFilter(), backupList);

Felmönster som stöds

I följande tabell beskrivs de mönster som är kompatibla med användningen av slutpunktslistor för säkerhetskopiering, tillsammans med anteckningar som beskriver information om felhantering för specifika mönster.

Mönster	Session	Transaktion	Ta emot kontext	Säkerhetskopieringslista stöds	Kommentar
Enkelriktad				Ja	Försöker skicka meddelandet igen på en slutpunkt för säkerhetskopiering. Om det här meddelandet är multicast flyttas endast meddelandet på den misslyckade kanalen till dess mål för säkerhetskopiering.
Enkelriktad		✔️		Nej	Ett undantag genereras och transaktionen återställs.
Enkelriktad			✔️	Ja	Försöker skicka meddelandet igen på en slutpunkt för säkerhetskopiering. När meddelandet har tagits emot slutför du alla mottagna kontexter. Om meddelandet inte tas emot av någon slutpunkt slutför du inte mottagarkontexten. När det här meddelandet multicastas slutförs endast mottagarkontexten om meddelandet tas emot av minst en slutpunkt (primär eller säkerhetskopiering). Om ingen av slutpunkterna i någon av multicast-sökvägarna tar emot meddelandet slutför du inte mottagarkontexten.
Enkelriktad		✔️	✔️	Ja	Avbryt den föregående transaktionen, skapa en ny transaktion och skicka alla meddelanden igen. Meddelanden som påträffade ett fel skickas till ett mål för säkerhetskopiering. När en transaktion har skapats där alla överföringar lyckas slutför du mottagarkontexterna och genomför transaktionen.
Enkelriktad	✔️			Ja	Försöker skicka meddelandet igen på en slutpunkt för säkerhetskopiering. I ett multicast-scenario är endast meddelandena i en session som påträffade ett fel eller i en session vars sessionsstängning misslyckades att skickas tillbaka till säkerhetskopieringsmål.
Enkelriktad	✔️	✔️		Nej	Ett undantag genereras och transaktionen återställs.
Enkelriktad	✔️		✔️	Ja	Försöker skicka meddelandet igen på en slutpunkt för säkerhetskopiering. När alla meddelanden har skickats utan fel anger sessionen inga fler meddelanden och routningstjänsten stänger alla utgående sessionskanaler, alla mottagna kontexter har slutförts och den inkommande sessionskanalen stängs.
Enkelriktad	✔️	✔️	✔️	Ja	Avbryt den aktuella transaktionen och skapa en ny. Skicka om alla tidigare meddelanden i sessionen. När en transaktion har skapats där alla meddelanden har skickats och sessionen inte anger några fler meddelanden stängs alla utgående sessionskanaler, ta emot kontexter slutförs med transaktionen, den inkommande sessionskanalen stängs och transaktionen checkas in. När sessionerna multicastas skickas meddelandena som inte hade något fel till samma mål som tidigare, och meddelanden som påträffade ett fel skickas till säkerhetskopieringsmål.
Dubbelriktad				Ja	Skicka till ett mål för säkerhetskopiering. När en kanal returnerar ett svarsmeddelande returnerar du svaret till den ursprungliga klienten.
Dubbelriktad	✔️			Ja	Skicka alla meddelanden i kanalen till ett mål för säkerhetskopiering. När en kanal returnerar ett svarsmeddelande returnerar du svaret till den ursprungliga klienten.
Dubbelriktad		✔️		Nej	Ett undantag genereras och transaktionen återställs.
Dubbelriktad	✔️	✔️		Nej	Ett undantag genereras och transaktionen återställs.
Duplex				Nej	Duplex-kommunikation som inte är en session stöds inte för närvarande.
Duplex	✔️			Ja	Skicka till ett mål för säkerhetskopiering.

Värd

Eftersom routningstjänsten implementeras som en WCF-tjänst måste den antingen vara lokalt installerad i ett program eller vara värd för IIS eller WAS. Vi rekommenderar att routningstjänsten finns i antingen IIS, WAS eller ett Windows Service-program för att dra nytta av de automatiska funktionerna för start och livscykelhantering som är tillgängliga i dessa värdmiljöer.

I följande exempel visas värd för routningstjänsten i ett program.

using (ServiceHost serviceHost =
                new ServiceHost(typeof(RoutingService)))

För att vara värd för routningstjänsten i IIS eller WAS måste du antingen skapa en tjänstfil (.svc) eller använda konfigurationsbaserad aktivering av tjänsten. När du använder en tjänstfil måste du ange RoutingService med hjälp av parametern Tjänst. Följande exempel innehåller en exempeltjänstfil som kan användas som värd för routningstjänsten med IIS eller WAS.

<%@ ServiceHost Language="C#" Debug="true" Service="System.ServiceModel.Routing.RoutingService,
     System.ServiceModel.Routing, version=4.0.0.0, Culture=neutral,
     PublicKeyToken=31bf3856ad364e35" %>

Routningstjänst och personifiering

WCF-routningstjänsten kan användas med personifiering för att både skicka och ta emot meddelanden. Alla vanliga Windows-begränsningar för personifiering gäller. Om du hade behövt konfigurera tjänst- eller kontobehörigheter för att använda personifiering när du skrev en egen tjänst måste du utföra samma steg för att använda personifiering med routningstjänsten. Mer information finns i Delegering och personifiering.

Personifiering med routningstjänsten kräver antingen användning av ASP.NET personifiering i ASP.NET kompatibilitetsläge eller användning av Windows-autentiseringsuppgifter som har konfigurerats för att tillåta personifiering. Mer information om ASP.NET kompatibilitetsläge finns i WCF-tjänster och ASP.NET.

Varning

WCF-routningstjänsten stöder inte personifiering med grundläggande autentisering.

Om du vill använda ASP.NET personifiering med routningstjänsten aktiverar du ASP.NET kompatibilitetsläge i tjänstvärdmiljön. Routningstjänsten har redan markerats som tillåten ASP.NET kompatibilitetsläge och personifiering aktiveras automatiskt. Personifiering är den enda användning av ASP.NET integrering med routningstjänsten som stöds.

Om du vill använda Personifiering av Windows-autentiseringsuppgifter med routningstjänsten måste du konfigurera både autentiseringsuppgifterna och tjänsten. Objektet för klientautentiseringsuppgifter (WindowsClientCredentialsom är tillgängligt från ChannelFactory) definierar en AllowedImpersonationLevel egenskap som måste anges för att tillåta personifiering. Slutligen måste du konfigurera ServiceAuthorizationBehavior beteendet för att ställa in ImpersonateCallerForAllOperations på true. Routningstjänsten använder den här flaggan för att bestämma om klienter ska skapas för vidarebefordran av meddelanden med personifiering aktiverat.

Se även

• Meddelandefilter
• Routningskontrakt
• Välja ett filter