Interoperabilität mit POX-Anwendungen

POX-Anwendungen („Plain Old XML“) kommunizieren durch den Austausch von HTTP-Nachrichten im Rohformat, d. h. von Nachrichten, die nur XML-Anwendungsdaten ohne einen SOAP-Umschlag enthalten. Windows Communication Foundation (WCF) kann sowohl Dienste als auch Clients bereitstellen, die POX-Nachrichten verwenden. Beim Dienst kann WCF zum Implementieren von Diensten verwendet werden, die Endpunkte für Clients wie Webbrowser und Skriptsprachen verfügbar machen, die POX-Nachrichten senden und empfangen. Auf dem Client kann das WCF-Programmiermodell zum Implementieren von Clients verwendet werden, die mit POX-basierten Diensten kommunizieren.

Hinweis

Dieses Dokument wurde ursprünglich für .NET Framework 3.0 geschrieben. .NET Framework 3.5 bietet integrierte Unterstützung für die Arbeit mit POX-Anwendungen. Weitere Informationen dazu finden Sie unter WCF-Web-HTTP-Programmiermodell.

POX-Programmierung mit WCF

WCF-Dienste, die über HTTP mithilfe von POX-Nachrichten kommunizieren, verwenden eine <customBinding>.

<customBinding>
   <binding name="poxServerBinding">
       <textMessageEncoding messageVersion="None" />
       <httpTransport />
   </binding>
</customBinding>

Diese benutzerspezifische Bindung enthält zwei Elemente:

Der standardmäßige WCF-Textnachrichten-Encoder ist speziell für die Verwendung des Werts None konfiguriert. Dies ermöglicht ihm die Verarbeitung von XML-Nachrichtennutzlasten, die nicht in einen SOAP-Umschlag eingeschlossen sind.

WCF-Clients, die über HTTP mithilfe von POX-Nachrichten kommunizieren, verwenden eine ähnliche Bindung (wie im folgenden imperativen Code gezeigt wird).

private static Binding CreatePoxBinding()
{
    TextMessageEncodingBindingElement encoder =
        new TextMessageEncodingBindingElement( MessageVersion.None, Encoding.UTF8 );
    HttpTransportBindingElement transport = new HttpTransportBindingElement();
    transport.ManualAddressing = true;
    return new CustomBinding( new BindingElement[] { encoder, transport } );
}

Da POX-Clients die URIs, an die Nachrichten gesendet werden, explizit angeben müssen, muss das HttpTransportBindingElement in der Regel so konfiguriert werden, dass eine manuelle Adressierung möglich ist. Hierfür wird im Element die ManualAddressing-Eigenschaft auf true festgelegt. Auf diese Weise kann die Adresse für die Nachricht explizit über Anwendungscode angegeben werden, und es muss nicht jedes Mal, wenn eine Anwendung eine Nachricht an einen anderen HTTP-URI sendet, eine neue ChannelFactory erstellt werden.

Da bei POX-Nachrichten keine SOAP-Header für die Übermittlung wichtiger Protokollinformationen verwendet werden, müssen POX-Clients und -Dienste häufig Teile der zugrunde liegenden HTTP-Anforderung, die zum Senden und Empfangen einer Nachricht verwendet wird, manipulieren. HTTP-spezifische Protokollinformationen wie die HTTP-Header und -Statuscodes werden im WCF-Programmiermodell durch zwei Klassen bereitgestellt:

  • HttpRequestMessageProperty, die Informationen zur HTTP-Anforderung wie die HTTP-Methode und Anforderungsheader enthält.

  • HttpResponseMessageProperty, die Informationen zur HTTP-Antwort enthält wie den HTTP-Statuscode und die Statusbeschreibung sowie alle HTTP-Antwortheader.

Das folgende Codebeispiel zeigt, wie Sie eine HTTP GET-Anforderungsnachricht mit der Adresse http://localhost:8100/customers erstellen können.

Message request = Message.CreateMessage( MessageVersion.None, String.Empty );
request.Headers.To = "http://localhost:8100/customers";

HttpRequestMessageProperty property = new HttpRequestMessageProperty();
property.Method = "GET";
property.SuppressEntityBody = true;
request.Properties.Add( HttpRequestMessageProperty.Name, property );

Zuerst wird die leere Anforderung Message durch Aufruf von CreateMessage(MessageVersion, String) erstellt. Der None-Parameter zeigt an, dass kein SOAP-Envelope erforderlich ist. Der Empty-Parameter wird als Aktion übergeben. Anschließend wird die Adresse für die Anforderungsnachricht angegeben, indem im To-Header der gewünschte URI festgelegt wird. Dann wird eine HttpRequestMessageProperty erstellt. Method wird auf die HTTP GET-Methode festgelegt, und für SuppressEntityBody wird der Wert true festgelegt, um anzuzeigen, dass keine Daten im Text der ausgehenden HTTP-Anforderungsnachricht gesendet werden sollen. Anschließend wird noch die Anforderungseigenschaft zur Properties-Auflistung der Anforderungsnachricht hinzugefügt, damit gesteuert werden kann, auf welche Weise der HTTP-Transport die Anforderung sendet. Die Nachricht kann nun über eine geeignete Instanz von IRequestChannel gesendet werden.

Auf ähnliche Weise kann beim Dienst die HttpRequestMessageProperty aus der eingehenden Nachricht extrahiert und eine Antwort erstellt werden.