Dela via


Kö 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.

Queued Application Diagram

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 ServiceModel Metadata Utility (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 gör att meddelandet skickas till överföringskö och överförs 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änståtgärder måste vara enkelriktade eftersom standardbindningen i kö i WCF inte stöder duplexkommunikation med hjälp av köer. Ett dubbelriktad kommunikationsexempel (tvåvägskommunikation) 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 som levereras med WCF kräver till exempel NetMsmqBinding att du konfigurerar bindningarna samt konfigurerar Message Queuing (MSMQ) minimalt.

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 två WCF-slutpunkter för kommunikation med 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 hitta tillräckligt.

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 falsepå gör den köade kanalen ett försök att överföra meddelandet. I det här fallet kan du välja en kö med obeställbara meddelanden.

  • Durable: När den är inställd true på (standard) ser den köade kanalen till att MSMQ lagrar meddelandet 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.

Kommentar

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ö.

Köegenskaper för obeställbara meddelanden

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ö med obeställbara meddelanden för meddelanden som inte levereras till icke-transaktionella köer och en systemomfattande transaktionskö med obeställbara meddelanden för meddelanden som inte levereras till transaktionskö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 kö med obeställbara meddelanden. 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 delar inte olika klienter samma kö med obeställbara meddelanden.

Bindningen har två egenskaper av intresse:

  • DeadLetterQueue: Den här egenskapen är en uppräkning som anger om en kö med obeställbara 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 köer med obeställbara meddelanden för att hantera fel vid meddelandeöverföring

  • CustomDeadLetterQueue: Den här egenskapen är URI-adressen (Uniform Resource Identifier) för den programspecifika kön med obeställbara meddelanden. 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ällningar i dessa egenskaper beror på hur MSMQ har konfigurerats. 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 inkluderar andra MSMQ-specifika egenskaper som exponeras 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 när du använder HTTP-transport för kö-till-kö-överföringar. SRMP secure används när du använder 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 exponeras för MsmqMessage<T> 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