Delen via

Interoperabiliteit met POX-toepassingen

  • Artikel

PoX-toepassingen (Plain Old XML) communiceren door onbewerkte HTTP-berichten uit te wisselen die alleen XML-toepassingsgegevens bevatten die niet in een SOAP-envelop zijn geplaatst. Windows Communication Foundation (WCF) kan zowel services als clients bieden die GEBRUIKMAKEN van POX-berichten. Op de service kan WCF worden gebruikt om services te implementeren die eindpunten beschikbaar maken voor clients, zoals webbrowsers en scripttalen die POX-berichten verzenden en ontvangen. Op de client kan het WCF-programmeermodel worden gebruikt om clients te implementeren die communiceren met op POX gebaseerde services.

Notitie

Dit document is oorspronkelijk geschreven voor .NET Framework 3.0. .NET Framework 3.5 biedt ingebouwde ondersteuning voor het werken met POX-toepassingen. Zie WCF Web HTTP Programming Model voor meer informatie.

POX-programmering met WCF

WCF-services die via HTTP communiceren met BEHULP van POX-berichten, gebruiken een customBinding>.<

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

Deze aangepaste binding bevat twee elementen:

De standaard WCF Text Message Encoder is speciaal geconfigureerd voor het gebruik van de None waarde, zodat de nettoladingen van XML-berichten die niet in een SOAP-envelop terechtkomen, kunnen worden verwerkt.

WCF-clients die via HTTP communiceren via POX-berichten, gebruiken een vergelijkbare binding (weergegeven in de volgende imperatieve code).

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 } );
}

Omdat POX-clients expliciet de URI's moeten opgeven waarnaar ze berichten verzenden, moeten ze meestal de HttpTransportBindingElement naar een handmatige adresseringsmodus configureren door de ManualAddressing eigenschap true in te stellen op het element. Hierdoor kunnen berichten expliciet worden verwerkt door toepassingscode. Het is niet nodig om telkens wanneer een toepassing een bericht naar een andere HTTP-URI verzendt, een nieuw ChannelFactory bericht te maken.

Omdat POX-berichten geen SOAP-headers gebruiken om belangrijke protocolinformatie over te brengen, moeten POX-clients en -services vaak delen bewerken van de onderliggende HTTP-aanvraag die wordt gebruikt voor het verzenden of ontvangen van een bericht. HTTP-specifieke protocolinformatie, zoals de HTTP-headers en statuscodes, worden in het WCF-programmeermodel weergegeven via twee klassen:

  • HttpRequestMessageProperty, die informatie bevat over de HTTP-aanvraag, zoals de HTTP-methode en aanvraagheaders.

  • HttpResponseMessageProperty, die informatie bevat over het HTTP-antwoord, zoals de HTTP-statuscode en de beschrijving van de status, evenals eventuele HTTP-antwoordheaders.

In het volgende codevoorbeeld ziet u hoe u een HTTP GET-aanvraagbericht maakt dat is geadresseerd aan http://localhost:8100/customers.

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 );

Eerst wordt een lege aanvraag Message gemaakt door aan te roepen CreateMessage(MessageVersion, String). De None parameter wordt gebruikt om aan te geven dat een SOAP-envelop niet vereist is en Empty dat de parameter wordt doorgegeven als de actie. Het aanvraagbericht wordt vervolgens geadresseerd door de header in te stellen To op de gewenste URI. Vervolgens wordt er een HttpRequestMessageProperty gemaakt en wordt deze Method ingesteld op de GET-methode van het HTTP-werkwoord en wordt deze SuppressEntityBody ingesteld om aan te true geven dat er geen gegevens moeten worden verzonden in de hoofdtekst van het uitgaande HTTP-aanvraagbericht. Ten slotte wordt de aanvraageigenschap toegevoegd aan de Properties verzameling van het aanvraagbericht, zodat deze van invloed kan zijn op de manier waarop het HTTP-transport de aanvraag verzendt. Het bericht is vervolgens gereed om te worden verzonden via een geschikt exemplaar van de IRequestChannel.

Vergelijkbare technieken kunnen op de service worden gebruikt om het HttpRequestMessageProperty uit een binnenkomend bericht te extraheren en een antwoord samen te stellen.