Välj en meddelandekodare
I den här artikeln beskrivs kriterier för att välja bland de meddelandekodare som ingår i Windows Communication Foundation (WCF): binary, text och Message Transmission Optimization Mechanism (MTOM).
I WCF anger du hur du överför data över ett nätverk mellan slutpunkter med hjälp av en bindning, som består av en sekvens med bindningselement. En meddelandekodare representeras av ett bindningselement för meddelandekodning i bindningsstacken. En bindning innehåller valfria protokollbindningselement, till exempel ett säkerhetsbindningselement eller ett tillförlitligt meddelandebindningselement, ett obligatoriskt meddelandekodningsbindningselement och ett obligatoriskt transportbindningselement.
Bindningselementet för meddelandekodning ligger under de valfria protokollbindningselementen och ovanför det obligatoriska transportbindningselementet. På den utgående sidan serialiserar en meddelandekodare utgående Message och skickar den till transporten. På den inkommande sidan tar en meddelandekodare emot den serialiserade formen av en Message från transporten och skickar den till det högre protokollskiktet, om det finns, eller till programmet, om inte.
När du ansluter till en befintlig klient eller server kanske du inte har något val om att använda en viss meddelandekodning eftersom du behöver koda dina meddelanden på ett sätt som den andra sidan förväntar sig. Men om du skriver en WCF-tjänst kan du exponera tjänsten via flera slutpunkter, var och en med en annan meddelandekodning. Detta gör det möjligt för klienter att välja den bästa kodningen för att prata med din tjänst över den slutpunkt som är bäst för dem, samt ge dina klienter flexibiliteten att välja den kodning som är bäst för dem. Med flera slutpunkter kan du också kombinera fördelarna med olika meddelandekodningar med andra bindningselement.
Systembaserade kodare
WCF innehåller tre meddelandekodare som representeras av följande tre klasser:
TextMessageEncodingBindingElement, textmeddelandekodaren, stöder både vanlig XML-kodning och SOAP-kodning. Textmeddelandekodarens oformaterade XML-kodningsläge kallas "vanlig gammal XML" (POX) för att skilja den från textbaserad SOAP-kodning. Om du vill aktivera POX anger du egenskapen MessageVersion till None. Använd textmeddelandekodaren för att samverka med icke-WCF-slutpunkter.
BinaryMessageEncodingBindingElement, den binära meddelandekodaren, använder ett kompakt binärt format och är optimerad för WCF-till WCF-kommunikation och är därför inte driftskompatibel. Detta är också den mest högpresterande kodaren av alla kodare som WCF tillhandahåller.
MtomMessageEncodingBindingElement, bindningselementet, anger teckenkodning och versionshantering av meddelanden med MTOM-kodning. MTOM är en effektiv teknik för överföring av binära data i WCF-meddelanden. MTOM-kodaren försöker skapa en balans mellan effektivitet och samverkan. MTOM-kodningen överför de flesta XML-kodarna i textformat, men optimerar stora block med binära data genom att överföra dem som de är, utan konvertering till text. När det gäller effektivitet, bland kodarna som WCF tillhandahåller, är MTOM mellan text (den långsammaste) och binär (den snabbaste).
Så här väljer du en meddelandekodare
I följande tabell beskrivs vanliga faktorer som används för att välja en meddelandekodare. Prioritera de faktorer som är viktiga för ditt program och välj sedan de meddelandekodare som fungerar bäst med dessa faktorer. Tänk på eventuella ytterligare faktorer som inte anges i den här tabellen och eventuella anpassade meddelandekodare som kan krävas i ditt program.
| Faktor | beskrivning | Kodare som stöder den här faktorn |
|---|---|---|
| Teckenuppsättningar som stöds | TextMessageEncodingBindingElement och MtomMessageEncodingBindingElement stöder endast UTF8- och UTF16 Unicode-kodningarna (big-endian och little-endian). Om andra kodningar krävs, till exempel UTF7 eller ASCII, måste en anpassad kodare användas. En anpassad exempelkodare finns i Anpassad meddelandekodare. | Text |
| Inspektion | Inspektion är möjligheten att undersöka meddelanden under överföringen. Textkodningar, antingen med eller utan användning av SOAP, tillåter att meddelanden inspekteras och analyseras av många program utan att använda specialiserade verktyg. Användningen av överföringssäkerhet, antingen på meddelande- eller transportnivå, påverkar din möjlighet att inspektera meddelanden. Konfidentialitet skyddar ett meddelande från att granskas och integritet skyddar ett meddelande från att ändras. | Text |
| Tillförlitlighet | Tillförlitlighet är motståndskraften hos en kodare för överföringsfel. Tillförlitlighet kan också anges på meddelande-, transport- eller programskiktet. Alla WCF-standardkodare förutsätter att ett annat lager ger tillförlitlighet. Kodaren har liten möjlighet att återställa från ett överföringsfel. | Ingen |
| Enkelhet | Enkelhet representerar hur enkelt du kan skapa kodare och avkodare för en kodningsspecifikation. Textkodningar är särskilt för enkelhetens skull, och POX-textkodningen har den ytterligare fördelen att inte kräva stöd för bearbetning av SOAP. | Text (POX) |
| Storlek | Kodningen avgör mängden omkostnader som läggs på innehåll. Storleken på kodade meddelanden är direkt relaterad till det maximala dataflödet för tjänståtgärder. Binära kodningar är vanligtvis mer kompakta än textkodningar. När meddelandestorleken är premium kan du även komprimera meddelandeinnehållet under kodningen. Komprimering lägger dock till bearbetningskostnader för både meddelandesändaren och mottagaren. | Binära |
| Strömning | Strömning gör att program kan börja bearbeta ett meddelande innan hela meddelandet har anlänt. Effektiv användning av direktuppspelning kräver att viktiga data för ett meddelande är tillgängliga i början av meddelandet så att det mottagande programmet inte behöver vänta tills det tas emot. Dessutom måste program som använder strömmad överföring ordna data i meddelandet stegvis så att innehållet inte har framåtriktade beroenden. I många fall måste du kompromissa mellan strömmande innehåll och att ha minsta möjliga överföringsstorlek för innehållet. | Ingen |
| Stöd för verktyg från tredje part | Stödområden för en kodning inkluderar utveckling och diagnos. Utvecklare från tredje part har gjort stora investeringar i bibliotek och verktyg för att hantera meddelanden som kodas i POX-format. | Text (POX) |
| Samverkan | Den här faktorn avser möjligheten för en WCF-kodare att samverka med icke-WCF-tjänster. | Text MTOM (partiell) |
Obs! När du använder den binära kodaren har inställningen IgnoreWhitespace när du skapar en XMLReader ingen effekt. Om du till exempel gör följande i en tjänståtgärd:
public void OperationContract(XElement input)
{
Console.WriteLine("{0}", input.Value);
int counter = 0;
var xreader = input.CreateReader();
var reader = XmlReader.Create(xreader, new XmlReaderSettings() { IgnoreWhitespace = true });
while (reader.Read())
{
counter++;
}
Console.WriteLine("Read {0} lines with reader", counter);
}
Inställningen IgnoreWhitespace ignoreras.
Komprimering och binär kodare
Från och med WCF 4.5 lägger den binära WCF-kodaren till stöd för komprimering. På så sätt kan du använda gzip/deflate-algoritmen för att skicka komprimerade meddelanden från en WCF-klient och även svara med komprimerade meddelanden från en WCF-tjänst med egen värd. Den här funktionen möjliggör komprimering av både HTTP- och TCP-transporterna. En IIS-värdbaserad WCF-tjänst kan alltid aktiveras för att skicka komprimerade svar genom att konfigurera IIS-värdservern. Typen av komprimering konfigureras med egenskapen BinaryMessageEncodingBindingElement.CompressionFormat . Den här egenskapen är inställd på något av uppräkningsvärdena System.ServiceModel.Channels.CompressionFormat :
Eftersom den här egenskapen endast exponeras på binaryMessageEncodingBindingElement måste du skapa en anpassad bindning som följande för att använda den här funktionen:
<customBinding>
<binding name="BinaryCompressionBinding">
<binaryMessageEncoding compressionFormat ="GZip" />
<httpTransport />
</binding>
</customBinding>
Både klienten och tjänsten måste godkänna att skicka och ta emot komprimerade meddelanden och därför måste egenskapen compressionFormat konfigureras på elementet binaryMessageEncoding på både klient och tjänst. En ProtocolException utlöses om antingen tjänsten eller klienten inte har konfigurerats för komprimering, men den andra sidan är det. Aktivering av komprimering bör övervägas noggrant. Komprimering är mest användbart om nätverksbandbredden är en flaskhals. Om processorn är flaskhalsen minskar komprimering dataflödet. Lämplig testning måste göras i en simulerad miljö för att ta reda på om detta gynnar programmet