Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel werden Kriterien für die Auswahl zwischen den Nachrichtenkodierern erläutert, die in Windows Communication Foundation (WCF) enthalten sind: Binär-, Text- und MTOM-Kodierer.
In WCF geben Sie an, wie Daten über ein Netzwerk zwischen Endpunkten über eine Bindung übertragen werden, die aus einer Abfolge von Bindungselementen besteht. Ein Nachrichtenencoder wird von einem Nachrichtencodierungs-Bindungselement im Bindungsstapel dargestellt. Eine Bindung enthält optionale Protokollbindungselemente, z. B. ein Sicherheitsbindungselement oder ein zuverlässiges Nachrichtenbindungselement, ein erforderliches Nachrichtencodierungsbindungselement und ein erforderliches Transportbindungselement.
Das Nachrichtencodierungsbindungselement befindet sich unterhalb der optionalen Protokollbindungselemente und oberhalb des erforderlichen Transportbindungselements. Auf der ausgehenden Seite serialisiert ein Nachrichtenencoder die ausgehende Message und übergibt sie an den Transport. Auf der eingehenden Seite empfängt ein Nachrichten-Encoder die serialisierte Form eines Message-Objekts vom Transport und übergibt sie an die höhere Protokollebene, sofern vorhanden, oder an die Anwendung, falls nicht.
Wenn Sie eine Verbindung mit einem bereits vorhandenen Client oder Server herstellen, haben Sie möglicherweise keine Wahl, eine bestimmte Nachrichtencodierung zu verwenden, da Sie Ihre Nachrichten so codieren müssen, dass die andere Seite erwartet. Wenn Sie jedoch einen WCF-Dienst schreiben, können Sie Ihren Dienst über mehrere Endpunkte verfügbar machen, jeweils mit einer anderen Nachrichtencodierung. Auf diese Weise können Clients die beste Codierung für die Kommunikation mit Ihrem Dienst über den Endpunkt auswählen, der für sie am besten geeignet ist, und Ihren Clients die Flexibilität geben, die für sie am besten geeignete Codierung auszuwählen. Durch die Verwendung mehrerer Endpunkte können Sie auch die Vorteile verschiedener Nachrichtencodierungen mit anderen Bindungselementen kombinieren.
Vom System bereitgestellte Encoder
WCF enthält drei Nachrichten-Encoder, die durch die folgenden drei Klassen dargestellt werden:
TextMessageEncodingBindingElement, der Textnachrichten-Encoder unterstützt sowohl einfache XML-Codierung als auch SOAP-Codierung. Der Nur-XML-Codierungsmodus des Textnachrichten-Encoders wird als "einfaches altes XML" (POX) bezeichnet, um ihn von der textbasierten SOAP-Codierung zu unterscheiden. Um POX zu aktivieren, legen Sie die MessageVersion Eigenschaft auf None. Verwenden Sie den Textnachrichten-Encoder, um mit Nicht-WCF-Endpunkten zu arbeiten.
BinaryMessageEncodingBindingElement, der binäre Nachrichten-Encoder verwendet ein kompaktes Binärformat und ist für WCF-Kommunikation optimiert und daher nicht interoperabel. Dies ist auch der effizienteste Encoder unter allen von WCF bereitgestellten Encodern.
MtomMessageEncodingBindingElement, das Bindungselement, gibt die Zeichencodierung und Nachrichtenversionsverwaltung für Nachrichten mit MTOM-Codierung an. MTOM ist eine effiziente Technologie zum Übertragen von Binärdaten in WCF-Nachrichten. Der MTOM-Encoder versucht, ein Gleichgewicht zwischen Effizienz und Interoperabilität zu schaffen. Die MTOM-Kodierung überträgt den Großteil der XML-Daten in Textform, optimiert jedoch große Blöcke von Binärdaten, indem sie diese direkt als as-isüberträgt, ohne eine Konvertierung in Text vorzunehmen. Was die Effizienz angeht, liegt MTOM unter den Encodern, die WCF bereitstellt, zwischen Text (am langsamsten) und Binär (am schnellsten).
Wie man einen Nachrichtenkodierer auswählt
In der folgenden Tabelle werden allgemeine Faktoren beschrieben, die zum Auswählen eines Nachrichten-Encoders verwendet werden. Priorisieren Sie die Faktoren, die für Ihre Anwendung wichtig sind, und wählen Sie dann die Nachrichten-Encoder aus, die am besten mit diesen Faktoren funktionieren. Berücksichtigen Sie unbedingt alle zusätzlichen Faktoren, die in dieser Tabelle nicht aufgeführt sind, sowie benutzerdefinierte Nachrichten-Encoder, die in Ihrer Anwendung möglicherweise erforderlich sind.
| Faktor | BESCHREIBUNG | Encoder, die diesen Faktor unterstützen |
|---|---|---|
| Unterstützte Zeichensätze | TextMessageEncodingBindingElement und MtomMessageEncodingBindingElement unterstützen nur die UTF8- und UTF16-Unicode-Codierungen (big-endian und little-endian). Wenn andere Codierungen erforderlich sind, z. B. UTF7 oder ASCII, muss ein benutzerdefinierter Encoder verwendet werden. Ein beispiel für einen benutzerdefinierten Encoder finden Sie unter Custom Message Encoder. | Text |
| Inspektion | Die Inspektion ist die Möglichkeit, Nachrichten während der Übertragung zu untersuchen. Textcodierungen, entweder mit oder ohne die Nutzung von SOAP, ermöglichen es, dass Mitteilungen von vielen Anwendungen untersucht und analysiert werden können, ohne dass spezielle Werkzeuge erforderlich sind. Die Verwendung der Übertragungssicherheit auf Nachrichten- oder Transportebene wirkt sich auf ihre Fähigkeit zum Überprüfen von Nachrichten aus. Vertraulichkeit schützt eine Nachricht davor, dass sie untersucht wird, und die Integrität schützt eine Nachricht davor, dass sie verändert wird. | Text |
| Zuverlässigkeit | Zuverlässigkeit ist die Resilienz eines Encoders für Übertragungsfehler. Zuverlässigkeit kann auch auf der Nachrichten-, Transport- oder Anwendungsschicht bereitgestellt werden. Alle standardmäßigen WCF-Encoder gehen davon aus, dass eine andere Ebene Zuverlässigkeit bereitstellt. Der Encoder hat keine Möglichkeit, sich von einem Übertragungsfehler wiederherzustellen. | Nichts |
| Einfachheit | Einfachheit stellt die Einfachheit dar, mit der Sie Encoder und Decoder für eine Codierungsspezifikation erstellen können. Textcodierungen sind besonders vorteilhaft für die Einfachheit, und die POX-Textcodierung hat den zusätzlichen Vorteil, dass keine Unterstützung für die Verarbeitung von SOAP erforderlich ist. | Text (POX) |
| Größe | Die Codierung bestimmt den Aufwand für Inhalte. Die Größe codierter Nachrichten hängt direkt mit dem maximalen Durchsatz von Dienstvorgängen zusammen. Binäre Codierungen sind im Allgemeinen kompakter als Textcodierungen. Wenn die Nachrichtengröße begrenzt ist, sollten Sie auch den Inhalt der Nachricht während der Kodierung komprimieren. Bei der Komprimierung werden jedoch Verarbeitungskosten sowohl für den Absender als auch für den Empfänger der Nachricht erhöht. | Binär |
| Streamen | Mit Dem Streaming können Anwendungen mit der Verarbeitung einer Nachricht beginnen, bevor die gesamte Nachricht eingegangen ist. Die effektive Nutzung von Streaming erfordert, dass die wichtigen Daten für eine Nachricht am Anfang der Nachricht verfügbar sind, damit die empfangende Anwendung nicht darauf warten muss, bis sie eintreffen. Darüber hinaus müssen Anwendungen, die streamte Übertragungen verwenden, Daten in der Nachricht inkrementell organisieren, sodass der Inhalt keine Weiterleitungsabhängigkeiten aufweist. In vielen Fällen müssen Sie einen Kompromiss zwischen Streaming-Inhalten und der kleinstmöglichen Übertragungsgröße dieser Inhalte eingehen. | Nichts |
| Unterstützung von Drittanbietertools | Zu den Supportbereichen für eine Codierung gehören Entwicklung und Diagnose. Entwickler von Drittanbietern haben große Investitionen in Bibliotheken und Toolkits für die Verarbeitung von Nachrichten im POX-Format vorgenommen. | Text (POX) |
| Interoperabilität | Dieser Faktor bezieht sich auf die Fähigkeit eines WCF-Encoders, mit Nicht-WCF-Diensten zu arbeiten. | Text MTOM (teilweise) |
Hinweis: Bei Verwendung des Binären Encoders hat die Verwendung der Einstellung "IgnoreWhitespace" beim Erstellen eines XMLReader keine Auswirkung. Wenn Sie z. B. folgendes innerhalb eines Dienstvorgangs ausführen:
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);
}
Die Einstellung "IgnoreWhitespace" wird ignoriert.
Komprimierung und binärer Encoder
Ab WCF 4.5 fügt der WCF-Binäre Encoder Unterstützung für die Komprimierung hinzu. Auf diese Weise können Sie den Gzip/Deflate-Algorithmus zum Senden komprimierter Nachrichten von einem WCF-Client verwenden und auch mit komprimierten Nachrichten von einem selbst gehosteten WCF-Dienst antworten. Dieses Feature ermöglicht die Komprimierung sowohl für den HTTP- als auch für den TCP-Transport. Ein von IIS gehosteter WCF-Dienst kann immer zum Senden komprimierter Antworten aktiviert werden, indem er den IIS-Hostserver konfiguriert. Der Komprimierungstyp wird mit der BinaryMessageEncodingBindingElement.CompressionFormat Eigenschaft konfiguriert. Diese Eigenschaft wird auf einen der System.ServiceModel.Channels.CompressionFormat Enum-Werte festgelegt.
Da diese Eigenschaft nur für das binaryMessageEncodingBindingElement verfügbar gemacht wird, müssen Sie eine benutzerdefinierte Bindung wie die folgende erstellen, um dieses Feature zu verwenden:
<customBinding>
<binding name="BinaryCompressionBinding">
<binaryMessageEncoding compressionFormat ="GZip" />
<httpTransport />
</binding>
</customBinding>
Sowohl der Client als auch der Dienst müssen dem Senden und Empfangen komprimierter Nachrichten zustimmen und daher muss die CompressionFormat-Eigenschaft für das binaryMessageEncoding-Element sowohl für den Client als auch für den Dienst konfiguriert werden. Eine ProtocolException wird ausgelöst, wenn entweder der Dienst oder der Client nicht für die Komprimierung konfiguriert ist, während die andere Seite konfiguriert ist. Das Aktivieren der Komprimierung sollte sorgfältig überlegt werden. Die Komprimierung ist meist nützlich, wenn die Netzwerkbandbreite ein Engpass ist. In dem Fall, in dem die CPU der Engpass ist, verringert die Komprimierung den Durchsatz. Geeignete Tests müssen in einer simulierten Umgebung durchgeführt werden, um herauszufinden, ob diese Anwendung vorteile hat.