Dela via

Köhantering i WCF

I det här avsnittet beskrivs hur du använder köad kommunikation i Windows Communication Foundation (WCF).

Köer som en WCF-transportbindning

I WCF anger kontrakten vad som utbyts. Kontrakt är affärsberoende eller programspecifika meddelandeutbyten. Den mekanism som används för att utbyta meddelanden (eller "hur") anges i bindningarna. Bindningar i WCF kapslar in information om meddelandeutbytet. De exponerar konfigurationsknoppar för användaren för att kontrollera olika aspekter av transporten eller protokollet som bindningarna representerar. Köer i WCF behandlas som alla andra transportbindningar, vilket är en stor fördel för många köprogram. I dag skrivs många köprogram annorlunda än andra RPC-liknande distribuerade program, vilket gör det svårare att följa och underhålla. Med WCF är formatet för att skriva ett distribuerat program ungefär detsamma, vilket gör det enklare att följa och underhålla. Genom att ta hänsyn till mekanismen för utbyte separat från affärslogik är det dessutom enklare att konfigurera transporten eller göra ändringar i den utan att påverka programspecifik kod. Följande bild illustrerar strukturen för en WCF-tjänst och -klient som använder MSMQ som transport.

Diagram över köhanteringsapplikation

Som du ser från föregående bild måste klienten och tjänsten endast definiera programsemantiken, det vill: kontraktet och implementeringen. Tjänsten konfigurerar en köbindning med önskade inställningar. Klienten använder Verktyget för ServiceModel-metadata (Svcutil.exe) för att generera en WCF-klient till tjänsten och för att generera en konfigurationsfil som beskriver bindningarna som ska användas för att skicka meddelanden till tjänsten. För att skicka ett köat meddelande instansierar klienten därför en WCF-klient och anropar en åtgärd på den. Detta orsakar att meddelandet skickas till transmissionskön och förs vidare till målkön. Alla komplexiteter i köad kommunikation är dolda från programmet som skickar och tar emot meddelanden.

Varningar om köbindning i WCF inkluderar:

  • Alla tjänstoperationer måste vara enkelriktade eftersom standardköbindningen i WCF inte stöder duplexkommunikation med hjälp av köer. Ett tvåvägskommunikationsexempel (Two-Way Communication) visar hur du använder två enkelriktade kontrakt för att implementera dubbelriktad kommunikation med hjälp av köer.

  • För att generera en WCF-klient med metadatautbyte krävs ytterligare en HTTP-slutpunkt för tjänsten så att den kan frågas direkt för att generera WCF-klienten och hämta bindningsinformation för att korrekt konfigurera köad kommunikation.

  • Baserat på den köade bindningen krävs extra konfiguration utanför WCF. Klassen NetMsmqBinding som levereras med WCF kräver till exempel att du konfigurerar bindningarna och minimalt konfigurerar Message Queuing (MSMQ).

I följande avsnitt beskrivs de specifika köbindningar som levereras med WCF, som baseras på MSMQ.

MSMQ

Den köade transporten i WCF använder MSMQ för sin köade kommunikation.

MSMQ levereras som en valfri komponent med Windows och körs som en NT-tjänst. Den samlar in meddelanden för överföring i en överföringskö och för leverans i en målkö. MSMQ-köcheferna implementerar ett tillförlitligt protokoll för meddelandeöverföring så att meddelanden inte går förlorade i överföringen. Protokollet kan vara antingen inbyggt eller SOAP-baserat, till exempel SOAP Reliable Message Protocol (SRMP).

I MSMQ kan köer vara transaktionella eller icke-transaktionella. En transaktionskö gör att meddelanden kan samlas in och levereras i en transaktion och sedan lagras korrekt i kön. Meddelanden som skickas till en transaktionskö överförs exakt en gång i ordning. Du kan använda en icke-transaktionell kö för att skicka både flyktiga och varaktiga meddelanden. Ett meddelande som skickas till en icke-transaktionell kö har inga tillförlitliga överföringsgarantier. därför kan meddelanden gå förlorade.

MSMQ-köer kan också skyddas med hjälp av en Windows-identitet som registrerats med Active Directory-katalogtjänsten. När du installerar MSMQ kan du installera Active Directory-integrering, vilket kräver att datorn ingår i ett Windows-domännätverk.

Mer information om MSMQ finns i Installera Message Queuing (MSMQ).

NetMsmqBinding

<netMsmqBinding är den köade bindningen> som WCF tillhandahåller för kommunikation mellan två WCF-slutpunkter med hjälp av MSMQ. Bindningen exponerar därför egenskaper som är specifika för MSMQ. Men inte alla MSMQ-funktioner och egenskaper exponeras i NetMsmqBinding. Den kompakta NetMsmqBinding är utformad med en optimal uppsättning funktioner som de flesta kunder bör uppleva som tillfredsställande.

Manifestet NetMsmqBinding visar de grundläggande köbegrepp som diskuterats hittills i form av egenskaper för bindningarna. Dessa egenskaper kommunicerar i sin tur med MSMQ hur du överför och levererar meddelandena. En diskussion om egenskapskategorierna finns i följande avsnitt. Mer information finns i konceptavsnitten som beskriver specifika egenskaper mer fullständigt.

Egenskaper för ExactlyOnce och Durable

Egenskaperna ExactlyOnce och Durable påverkar hur meddelanden överförs mellan köer:

  • ExactlyOnce: När det är inställt på true (standard) ser den köade kanalen till att meddelandet, om det levereras, inte dupliceras. Det säkerställer också att meddelandet inte går förlorat. Om meddelandet inte kan levereras, eller om meddelandet Time-To Live upphör att gälla innan meddelandet kan levereras, registreras det misslyckade meddelandet tillsammans med orsaken till leveransfelet i en kö med obeställbara meddelanden. När den är inställd till false gör den köade kanalen ett försök att överföra meddelandet. I det här fallet kan du valfritt välja en dead-letter-kö.

  • Durable: När den är inställd till true (standardvärde) ser den köade kanalen till att MSMQ lagrar meddelandet hållbart på disken. Om MSMQ-tjänsten skulle stoppa och starta om överförs meddelandena på disken till målkön eller levereras till tjänsten. När de är inställda falsepå lagras meddelandena i ett flyktigt arkiv och går förlorade när MSMQ-tjänsten stoppas och startas om.

För ExactlyOnce tillförlitlig överföring kräver MSMQ att kön är transaktionell. MSMQ kräver också att en transaktion läser från en transaktionskö. När du använder NetMsmqBindingmåste du därför komma ihåg att en transaktion krävs för att skicka eller ta emot meddelanden när ExactlyOnce är inställd på true. På samma sätt kräver MSMQ att kön inte är transaktionell för bästa möjliga garantier, till exempel när ExactlyOnce är false och för flyktiga meddelanden. När du anger ExactlyOnce till false eller beständig till falsekan du därför inte skicka eller ta emot med hjälp av en transaktion.

Anmärkning

Se till att rätt kö (transaktionell eller icke-transaktionell) skapas baserat på inställningarna i bindningarna. Om ExactlyOnce är trueanvänder du en transaktionskö, annars använder du en icke-transaktionell kö.

Dead-Letter köegenskaper

Kön med obeställbara meddelanden används för att lagra meddelanden som inte levereras. Användaren kan skriva kompenserande logik som läser meddelanden från kön med obeställbara meddelanden.

Många kösystem tillhandahåller en systemomfattande kö med obeställbara meddelanden. MSMQ tillhandahåller en systemomfattande icke-transaktionell kö för obeställbara meddelanden för meddelanden som inte levereras till icke-transaktionella köer och en systemomfattande transaktionell kö för obeställbara meddelanden för meddelanden som inte levereras till transaktionella köer.

Om flera klienter som skickar meddelanden till olika målköer delar MSMQ-tjänsten, går alla meddelanden som skickas av klienterna till samma dead-letter queue. Detta är inte alltid att föredra. För bättre isolering tillhandahåller WCF och MSMQ i Windows Vista en anpassad kö med obeställbara meddelanden (eller programspecifik kö med obeställbara meddelanden) som användaren kan ange för att lagra meddelanden som inte levereras. Därför har olika klienter inte samma kö med obeställbara meddelanden.

Bindningen har två egenskaper av intresse:

  • DeadLetterQueue: Den här egenskapen är en uppräkning som indikerar om en kö för icke-levererbara meddelanden begärs. Uppräkningen innehåller också typen av kö med obeställbara meddelanden, om en sådan begärs. Värdena är None, Systemoch Custom. Mer information om tolkningen av dessa egenskaper finns i Använda Dead-Letter köer för att hantera fel vid meddelandeöverföring

  • CustomDeadLetterQueue: Den här egenskapen är Uniform Resource Identifier (URI)-adressen för den programspecifika dead-letter-kön. Detta krävs om DeadLetterQueue. Custom väljs.

Egenskaper för hantering av giftmeddelanden

När tjänsten läser meddelanden från målkön under en transaktion kan tjänsten misslyckas med att bearbeta meddelandet av olika skäl. Meddelandet sätts sedan tillbaka i kön för att läsas igen. För att hantera meddelanden som misslyckas upprepade gånger kan en uppsättning egenskaper för hantering av giftmeddelanden konfigureras i bindningen. Det finns fyra egenskaper: ReceiveRetryCount, MaxRetryCycles, RetryCycleDelayoch ReceiveErrorHandling. Mer information om dessa egenskaper finns i Hantering av giftmeddelanden.

Säkerhetsegenskaper

MSMQ exponerar sin egen säkerhetsmodell, till exempel åtkomstkontrollistor (ACL: er) i en kö eller skickar autentiserade meddelanden. Exponerar NetMsmqBinding dessa säkerhetsegenskaper som en del av dess transportsäkerhetsinställningar. Det finns två egenskaper i bindningen för transportsäkerhet: MsmqAuthenticationMode och MsmqProtectionLevel. Inställningarna i de här egenskaperna beror på hur MSMQ konfigureras. Mer information finns i Skydda meddelanden med transportsäkerhet.

Förutom transportsäkerhet kan själva SJÄLVA SOAP-meddelandet skyddas med hjälp av meddelandesäkerhet. Mer information finns i Skydda meddelanden med hjälp av meddelandesäkerhet.

MsmqTransportSecurity exponerar också två egenskaper, MsmqEncryptionAlgorithm och MsmqHashAlgorithm. Det här är uppräkningar av olika algoritmer att välja för överföringskryptering från kö till kö av meddelanden och hashning av signaturerna.

Andra egenskaper

Förutom de föregående egenskaperna visas andra MSMQ-specifika egenskaper i bindningen.

  • UseSourceJournal: En egenskap som anger att källjournaler är aktiverade. Källjournaler är en MSMQ-funktion som håller reda på meddelanden som har överförts från överföringskö.

  • UseMsmqTracing: En egenskap som anger att MSMQ-spårning är aktiverat. MSMQ-spårning skickar rapportmeddelanden till en rapportkö varje gång ett meddelande lämnar eller anländer till en dator som är värd för en MSMQ-köhanterare.

  • QueueTransferProtocol: En uppräkning av protokollet som ska användas för meddelandeöverföringar från kö till kö. MSMQ implementerar ett inbyggt protokoll för överföring från kö till kö och ett SOAP-baserat protokoll med namnet SOAP Reliable Messaging Protocol (SRMP). SRMP används vid användning av HTTP-transport för kö-till-kö-överföringar. SRMP secure används vid användning av HTTPS för kö-till-kö-överföringar.

  • UseActiveDirectory: Ett booleskt värde som anger om Active Directory måste användas för köadressmatchning. Som standard är detta inaktiverat. Mer information finns i Tjänstslutpunkter och Köadressering.

MsmqIntegrationBinding

MsmqIntegrationBinding Används när du vill att en WCF-slutpunkt ska kommunicera med ett befintligt MSMQ-program skrivet i C-, C++-, COM- eller System.Messaging-API:er.

Bindningsegenskaperna är samma som för NetMsmqBinding. Följande skillnader gäller dock:

  • Åtgärdskontraktet för MsmqIntegrationBinding är begränsat till att ta en enskild parameter av typen MsmqMessage<T> där typparametern är brödtexttypen.

  • Många av MSMQ:s inbyggda meddelandeegenskaper görs tillgängliga via MsmqMessage<T> för användning.

  • För att hjälpa till med serialisering och deserialisering av meddelandetexten tillhandahålls serialiserare som XML och ActiveX.

Exempelkod

Stegvisa instruktioner för hur du skriver WCF-tjänster som använder MSMQ finns i följande avsnitt:

Ett färdigt kodexempel som illustrerar användningen av MSMQ i WCF finns i följande avsnitt:

Se även