WCF – Message Contracts y Clase Binding

Message Contract

l  Describe la estructura del mensaje.

l  Define el contenido de la cabecera y el cuerpo del mensaje SOAP.

l  Interoperabilidad con otras plataformas.

l  Convierte la clase en un mensaje SOAP.

Trabajando con servicios, al enviar un mensaje, WCF se encarga de su creación, entrega, etc., lo cual no presenta problema alguno, a menos que estos mensajes deban tener alguna estructura, en especial para poder realizar la comunicación entre las partes.

Es por eso por lo que se encuentra el Contrato de Mensaje, que permite crear o definir la estructura del mensaje por enviar, y evitar problemas de compatibilidad entre las partes.

Al poderse controlar el mensaje, el contenido de éste, tanto en la cabecera como en el cuerpo, se puede representar en un formato específico, y lograr así la interoperabilidad con diferentes plataformas o sistemas.

Los mensajes tipados brindan facilidad de uso, ya que no se tiene que manipular el mensaje XML porque los datos del mensaje están enlazados dentro de su estructura.

Se declara por medio de una clase con las etiquetas que se verán a continuación, y éste luego es convertido en un mensaje SOAP con el formato definido en la clase.

Message Contracts – Atributos

El atributo [MessageContract] declara una clase como una estructura de mensaje.

[MessageHeader] permite definir el contenido del encabezado del mensaje.

[MessageBody] permite definir el contenido del cuerpo del mensaje.

Demo:

namespace RMS.Service.MessageContract

{

    [MessageContract]

    public class SolicitudItem

    {

        [MessageHeader]

        public string NroItem;

        [MessageBodyMember]

        public Item ItemSolicitado;

    }

}

—–

[ServiceContract]

    public interface IEjemploContrato

    {

        [OperationContract(IsOneWay = true)]

        void ProcesarMensaje(SolicitudItem message);

    }

[MessageContract] – Parámetros

Action(string): especifica la acción que realizará el mensaje.

WrapperElement: incluye todos los elementos del cuerpo del mensaje cuando el mensaje es formateado en un documento XML.

El cuerpo del mensaje puede ser formateado en varios estilos (por medio de la propiedad Style de [ServiceContract]) al ser convertido a formato XML. Los WrapperElements agrupan toda la información del cuerpo del mensaje dentro del elemento definido.        

Por medio del WrapperElementNameSpace se define un namespace para el WrapperElement, y con el WrapperElementName se establece el nombre del elemento.

[MessageHeader] – Parámetros

Actor(string): los mensajes SOAP tienen la propiedad Actor, que dentro del encabezado define el mensaje a un endpoint específico. La propiedad Actor recibe un URI (string).

MustUnderstand(boolean): por medio de esta propiedad, se le indica al receptor que debe reconocer el miembro del encabezado determinado.

Relay(boolean): si la propiedad tiene el valor true, cada endpoint indicado en la propiedad Actor, al recibir y terminar de procesar el mensaje, deberá reenviar el mensaje al próximo endpoint.

Clase Binding y miembros

Como mencionamos anteriormente, los bindings son los encargados de describir de qué manera se comunicarán los EndPoints de un servicio.

Los bindings determinan el método de transporte, la codificación del mensaje, los requerimientos de seguridad, las sesiones confiables y las transacciones.

Los bindings están compuestos por elementos binding. Podemos crear bindings personalizados, pero contamos con nueve bindings estándar para los escenarios más comunes.

Los bindings pueden ser programados por código o mediante archivo de configuración.

Un binding está compuesto por un nombre, un namespace y una colección de elementos binding.

El nombre y su namespace identifican al binding en la metadata del servicio.

Cada elemento binding restante describe cómo un EndPoint se comunicará con el exterior.

Especificaciones de bindings

l  Transporte de comunicación utilizado.

l  Requerimientos de seguridad.

l  Requerimientos de sesiones confiables.

l  Requerimientos de transacciones.

l  Forma de codificación.

Perfiles de bindings

profilebinding_01

En la imagen se observan los tres elementos que componen el BasicProfileBinding.

Éste es el único binding estándar que es compatible con la primera generación de Web Services. Esta gran interoperabilidad con la que cuenta este perfil tiene su costo. Seguridad SOAP, confiabilidad y novedades de transacción no están disponibles. Este perfil permite seguridad HTTPS. El transporte utilizado es HTTP o HTTPS, y los mensajes tienen “text encoding” o codificación de texto.

Windows Communication Foundation provee nueve tipos de perfiles estándar para los escenarios más comunes.

profilebinding_02

Si ninguno de los perfiles estándar se ajustara a las necesidades de nuestro entorno, podríamos crear perfiles propios.

Programando bindings

Los desarrolladores pueden hacer uso de los bindings estándar, pero también tienen la posibilidad de crear bindings personalizados. Éstos pueden ser definidos, configurados y especificados mediante código o archivo de configuración.

Cuando un binding es definido para un endpoint en código, éste debe crearse de una de las clases binding. Existen clases binding para cada uno de los bindings estándar, como también una clase CustomBinding para bindings estándar.

Especificando un binding para un endpoint en un archivo de configuración

Clientes y servicios tienen que definir endpoints. Los servicios deben crear endpoints y los clientes deben acceder a ellos. Esta información puede ser especificada en código o en un archivo de configuración.

Cuando definimos un binding para un endpoint en un archivo de configuración, debemos especificar el tipo de binding. Esto es posible haciendo uso del atributo Binding del elemento endpoint.

<endpoint address="http://localhost/MyService/service.svc"

          contract="ISampleContract" binding="wsProfileBinding"></endpoint>

Creando un binding por código

Los bindings en código son creados utilizando una de las clases estándar mostradas en la tabla anteriormente.

En el código de ejemplo, el binding es creado instanciando la clase WSProfileBinding y luego agregando un endpoint al servicio.

WSProfileBinding binding  = new WSProfileBinding();

  service.addEndpoint(typeof(IMyService), binding, address);

Creando un binding personalizado por código

Los custom bindings son creados con la clase CustomBinding. El constructor acepta un número variable de elementos binding. El código aquí presentado crea un custom binding con sesiones confiables, composite duplex y transporte HTTP.

Cuando se crea un custom binding, es importante que los elementos se agreguen a éste en el siguiente orden:

          Flujo de contexto.

          Sesiones confiables.

          Seguridad.

          Duplex compuesto.

          Transporte.

          Codificación del mensaje.

CustomBinding binding = new CustomBinding(new ReliableSessionBindingElement()

   new CompositeDuplexBindingElement(), new HttpTransportBindingElement()));

  service.addEndpoint(typeof(IMyService), binding, address);

Estableciendo propiedades estándar

Tenemos la posibilidad de ajustar con precisión el behavior de un binding modificando sus propiedades. Cabe aclarar que no todos los bindings contienen cada una de estas propiedades, esto depende del tipo de binding.

Aquí presentamos algunas de las tantas propiedades que podemos ajustar:

          HttpAuthentication: esta propiedad es utilizada para configurar opciones de autenticación HTTP. Se aplica sólo cuando el modo de seguridad es HttpAuthenticationOverHttps.

          MaxConnections: esta propiedad controla el número máximo de conexiones. El valor por default es 10.

          SecurityMode: esta propiedad se utiliza para especificar qué tipo de seguridad se usará. Las opciones varían dependiendo del binding. Muchos bindings tienen, por default, seguridad Windows.

          SessionInactivityTimeout: aquí se especifica el tiempo máximo que puede pasar antes de que se termine una sesión por inactividad. El valor predeterminado es 5 minutos.

          TransferTimeout: esta propiedad especifica el tiempo máximo de transporte que puede demandar un mensaje. El valor predeterminado es 10 minutos.

About justindeveloper

I am MCP (Microsoft Certified Professional). MCTS (Microsoft Certified Technology Specialist) and MCPD (Microsoft Certified Professional Developer), also I am SAP Business One Certified!! Desarrollando desde el IDE de Visual Studio NET 2003 hasta ahora con el Visual Studio NET 2010. Desde Microsoft SQL Server 2000 hasta ahora con el Microsoft SQL Server 2008 R2 y tambien con SharePoint, desde WSS 3.0 y MOSS 2007 y ahora familirizandome con el Sharepoint Foundation 2010 & Sharepoint Server 2010. The software development will follow being every time more wonderful!
This entry was posted in Development. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s