Interoperabilität mit POX-Anwendungen
Bei POX-Anwendungen (POX = Plain Old XML, Kern der XML-Spezifikation) findet die Kommunikation durch Austausch von HTTP-Nachrichten im Rohformat statt, das heißt von Nachrichten, die nur XML-Anwendungsdaten ohne SOAP-Envelope enthalten. Windows Communication Foundation (WCF) kann Dienste und Clients bereitstellen, die POX-Nachrichten verwenden. Beim Dienst kann WCF für die Implementierung von Diensten verwendet werden, die Endpunkte wie Webbrowser und Skriptsprachen, mit denen POX-Nachrichten gesendet und empfangen werden können, für Clients verfügbar machen. Auf dem Client kann das Programmiermodell von WCF zur Implementierung von Clients, die mit POX-basierten Diensten kommunizieren, herangezogen werden.
Dieses Dokument wurde ursprünglich für .NET Framework 3.0 geschrieben. .NET Framework 3.5 verfügt über intergrierte Unterstützung für die Arbeit mit POX-Anwendungen. Weitere Informationen finden Sie unter Webprogrammiermodell. |
POX-Programmierung mit WCF
WCF-Dienste, deren Kommunikation über HTTP unter Verwendung von POX-Nachrichten stattfindet, verwenden ein customBinding element.
<customBinding>
<binding name="poxServerBinding">
<textMessageEncoding messageVersion="None" />
<httpTransport />
</binding>
</customBinding>
Diese benutzerspezifische Bindung enthält zwei Elemente:
- Das httpTransport element und
- das textMessageEncoding element.
Der standardmäßige Textnachrichtenencoder von WCF ist spezifisch für die Verwendung des None-Werts konfiguriert, wodurch XML-Nachrichten ohne SOAP-Envelope verarbeitet werden können.
WCF-Clients, die über HTTP unter Verwendung von POX-Nachrichten kommunizieren, verwenden eine ähnliche Bindung (wie im folgenden imperativen Code zu sehen ist):
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 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 https://localhost:8100/customers erstellen können:
Message request = Message.CreateMessage( MessageVersion.None, String.Empty );
request.Headers.To = “https://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 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.