Interoperabilidad con aplicaciones POX
Las aplicaciones de “XML simple” (POX) se comunican mediante el intercambio de mensajes HTTP sin formato que sólo contienen datos de aplicación XML que no se encierran en una envoltura SOAP. Windows Communication Foundation (WCF) pueden proporcionar servicios y clientes que utilizan mensajes POX. En el servicio, WCF se puede utilizar para implementar servicios que exponen extremos a clientes como exploradores web y lenguajes de script que envían y reciben mensajes POX. En el cliente, el modelo de programación de WCF se puede utilizar para implementar clientes que se comuniquen con servicios basados en POX.
.gif "Aa738456.note(es-es,VS.90).gif") |
|---|
| Este documento se redactó inicialmente para .NET Framework 3.0. .NET Framework 3.5 intregra compatibilidad para trabajar con aplicaciones POX. Para obtener más información acerca de este aspecto, consulte Modelo de programación web |
Programación POX con WCF
Los servicios de WCF que se comunican sobre HTTP mediante mensajes POX utilizan un customBinding element.
<customBinding>
<binding name="poxServerBinding">
<textMessageEncoding messageVersion="None" />
<httpTransport />
</binding>
</customBinding>
Este enlace personalizado contiene dos elementos:
El codificador de mensajes de texto de WCF estándar se configura especialmente para utilizar el valor None, que le permite procesar cargas útiles de mensajes XML que no llegan ajustadas dentro de una envoltura SOAP.
Los clientes de WCF que se comunican sobre HTTP mediante mensajes POX utilizan un enlace similar (mostrado en el código imperativo siguiente).
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 } );
}
Dado que los clientes POX deben especificar explícitamente los URI a los que envían los mensajes, normalmente deben configurar HttpTransportBindingElement como un modo de direccionamiento manual estableciendo la propiedad ManualAddressing en true en el elemento. Esto permite direccionar los mensajes explícitamente mediante código de aplicación y no es necesario para crear un nuevo ChannelFactory cada vez que una aplicación envía un mensaje a un URI HTTP diferente.
Dado que los mensajes POX no utilizan encabezados SOAP para llevar información protocolar importante, los clientes y servicios POX a menudo deben manipular partes de la solicitud HTTP subyacente utilizada para enviar o recibir un mensaje. La información protocolar específica de HTTP, como los encabezados HTTP y los códigos de estado aparecen en el modelo de programación de WCF a través de dos clases:
- HttpRequestMessageProperty, que contiene información sobre la solicitud HTTP, como el método HTTP y los encabezados de la solicitud.
- HttpResponseMessageProperty, que contiene información sobre la respuesta HTTP, como el código de estado HTTP y la descripción del estado, así como cualquier encabezado de respuesta HTTP.
El ejemplo de código siguiente muestra cómo crear un mensaje de solicitud HTTP GET que se dirija 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 );
Primero, se crea un Message de solicitud vacío llamando a CreateMessage. El parámetro None se utiliza para indicar que no se requiere una envoltura SOAP y el parámetro Empty se pasa como la Acción. El mensaje de solicitud se direcciona a continuación estableciendo el encabezad To en el URI deseado. Luego, se crea una HttpRequestMessageProperty y el Method se establece en el método de verbo HTTP GET y el SuppressEntityBody se establece en true para indicar que no se deberían enviar datos en el cuerpo del mensaje de la solicitud HTTP de salida. Finalmente, la propiedad de solicitud se agrega así a la colección Properties del mensaje de solicitud para que pueda influenciar en la forma en la que el Transporte HTTP envía la solicitud. El mensaje está listo para su envío sobre una instancia adecuada de IRequestChannel.
Se pueden utilizar técnicas similares en el servicio para extraer la HttpRequestMessageProperty de un mensaje entrante y construir una respuesta.