Interoperabilità con applicazioni POX
Le applicazioni "Plain Old XML" (POX) comunicano scambiando messaggi HTTP non elaborati che contengono solo dati di applicazioni XML non inclusi all'interno di una SOAP envelope. Windows Communication Foundation (WCF) può fornire servizi e client che utilizzano messaggi POX. Nel servizio, WCF può essere utilizzato per implementare servizi che espongono endpoint a client, ad esempio browser Web e linguaggi di script che inviano e ricevono messaggi POX. Nel client, il modello di programmazione WCF può essere utilizzato per implementare client che comunicano con servizi basati su POX.
Questo documento è stato inizialmente scritto per .NET Framework 3.0. .NET Framework 3.5 dispone di supporto incorporato per l'utilizzo di applicazioni POX. Per ulteriori informazioni , vedere Modello di programmazione Web |
Programmazione POX con WCF
I servizi WCF che comunicano su HTTP tramite messaggi POX utilizzano un customBinding element.
<customBinding>
<binding name="poxServerBinding">
<textMessageEncoding messageVersion="None" />
<httpTransport />
</binding>
</customBinding>
Questa associazione personalizzata contiene due elementi:
Il codificatore dei messaggi di testo WCF standard è configurato per l'utilizzo del valore None che consente di elaborare payload di messaggi XML che non arrivano incapsulati in una SOAP envelope.
I client WCF che comunicano su HTTP tramite messaggi POX utilizzano un'associazione simile (illustrata nel codice imperativo seguente).
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 } );
}
Poiché i client POX devono specificare in modo esplicito gli URI ai quali inviano messaggi, devono in genere configurare HttpTransportBindingElement come modalità di indirizzamento manuale impostando la proprietà ManualAddressing su true nell'elemento. Ciò consente ai messaggi di essere indirizzati in modo esplicito dal codice dell'applicazione e non sarà quindi necessario creare un nuovo ChannelFactory ogni volta che un'applicazione invia un messaggio a un URI HTTP diverso.
Poiché i messaggi POX non utilizzano intestazioni SOAP per trasmettere informazioni importanti sul protocollo, i client e i servizi POX spesso devono modificare parti della richiesta HTTP sottostante utilizzata per inviare o ricevere un messaggio. Le informazioni sul protocollo specifiche di HTTP, ad esempio le intestazioni e i codici di stato HTTP, nel modello di programmazione WCF assumono la forma di due classi:
- HttpRequestMessageProperty che contiene informazioni sulla richiesta HTTP, ad esempio le intestazioni di metodo e di richiesta HTTP.
- HttpResponseMessageProperty che contiene informazioni sulla risposta HTTP, ad esempio il codice di stato e la descrizione dello stato HTTP, come pure qualsiasi intestazione di risposta HTTP.
Nell'esempio di codice seguente viene illustrato come creare un messaggio di richiesta HTTP GET indirizzato a https://localhost:8100/customers.
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 );
In primo luogo viene creata una richiesta vuota Message chiamando CreateMessage. Il parametro None viene utilizzato per indicare che non è necessaria una SOAP envelope e il parametro Empty viene passato come Action. Il messaggio di richiesta viene quindi indirizzato impostando l'intestazione To sull'URI desiderato. Viene quindi creato HttpRequestMessageProperty e Method viene impostato sul metodo del verbo HTTP GET e SuppressEntityBody viene impostato su true per indicare che nessun dato deve essere inviato nel corpo del messaggio di richiesta HTTP in uscita. Infine la proprietà della richiesta viene aggiunta all'insieme Properties del messaggio di richiesta in modo da influire sull'invio della richiesta da parte del trasporto HTTP. Il messaggio è quindi pronto per essere inviato su un'istanza appropriata di IRequestChannel.
È possibile utilizzare tecniche simili nel servizio per estrarre HttpRequestMessageProperty da un messaggio in ingresso e creare una risposta.