Documente Academic
Documente Profesional
Documente Cultură
Qu es un contrato en WCF?
Contratos de Servicio
Contratos de Datos
Contratos de Mensaje
Qu es un Contrato en WCF?
Patrones de intercambio de
mensajes
Laboratorio
Que es un Contrato en WCF?
Conceptos clave:
Un Contrato es un acuerdo entre el Cliente y el Servicio de como llamar al Servicio y como transferir
el dato de un lado a otro
Decidir que operaciones sern expuestas, datos requeridos y datos a retornar
Los desarrolladores que construyen aplicaciones Cliente hacen uso de los contratos, que ofrece el
servicio y asi poder determinar como el Cliente interactuar con el Servicio, especifcamente con los
mensajes del Servicio y como responder a esos mensajes
Los Contrados de Servicio deben estar diseados para soportar aplicaciones distribuidos, y soportar
aplicaciones Cliente independiente de su tecnologa
Tipos de Contratos son:
Contrato de Servicio (Service)
Contrato de Dato (Data)
Contrato de Mensaje (Message)
Contrato de Fallo (Fault)
Antes de empezar a escribir en WCF, primero es necesario conocer cules son las operaciones
que expondr el servicio, que datos requiere el servicio y que informacin retornar el servicio.
Asimismo, es necesario definir que patrones de mensajes utilizar para el servicio en cada una
de las operaciones. Estas decisiones hacen referencia a los que se llama contratos del servicio.
En WCF es necesario definir varios contratos, pero primero es necesario definir el Contrato de
servicio, sin esta definicin los clientes nunca sabrn las operaciones o mtodos que el servicio
expone, tambin cuales con los tipos de datos que el servicio espera o debe retornar. Tambin,
la aplicacin del cliente no necesariamente necesita estar en la misma tecnologa (.Net), ya que
la transmisin de informacin es en XML
Segn SOA, cada operacin (mtodo) en tu servicio puede recibir dato y enviar dato (basado
en las declaraciones de las operaciones), este es el concepto bsico de un servicio, una vez
que se declare que dato tiene ser enviado y recibido, ya no es necesario conocer como este
implementa de la funcionalidad y cual tecnologa es utilizado, porque la informacin viaja en
formato XML.
Notas:
- Los mensajes que se envan de WCF entre el cliente y el servicio estn basado en
XML, esto no significa que la informacin es enviada en texto claro o simples cadenas,
estos son codificados en diferentes maneras (text encoding y binary encoding), el
encoding que un servicio utiliza depende del protocolo de transporte y otras
configuraciones.
- En WCF, usted puede implementar un servicio con capacidades bsicas sin utilizar
seguridad u otros estndares WS-*. Este tipo de servicios establecer el contrato de un
Microsoft ASP.NET Web Service.
El contrato que es declarado por el servicio que define una lista de operaciones que el servicio
puede ejecutar, es decir, la lista de mtodos que el servicio expone a sus clientes. El contrato
tambin define la forma del dato que es esperado y retornado por el servicio. Por ltimo, un
contrato declara los patrones de mensajes que los clientes necesitan utilizar cuando el cliente
est conectado al servicio. (Patrones pueden variar entre mltiples operaciones de servicios).
Conceptos clave:
Coleccion de Operaciones expuestos hacia los clientes
Describe que operaciones es soportado por el Servicio, Patrones en el intercambio
de mensajes utilizados para dar formato a cada mensaje
ServiceContract atributo que marca una interface como un Contrato de Servicio
OperationContract atributo que expone los mtodos de la interface
[ServiceContract]
public interface IService1
[OperationContract]
string sayHello(string yourName);
El contrato de servicio describe las operaciones que el servicio ejecuta, la funcionalidad que
este expone al mundo, Invocar una operacin de servicio requiere enviar un especfico XML al
servicio, esto significa que un contrato de servicio no solamente describe cuales son las
operaciones que este expone, sino tambin como un cliente debera llamar un servicio
solicitando una determinada operacin.
Ejemplo: El siguiente fragmento de XML envi al servicio que la operacin requerida es Add.
Para escribir un contrato se necesita crear una interface que actuar como contrato, este
puede ser escrito en cualquier lenguaje .Net.
El ServiceContractAttribute
Atributo Descripcin
El OperationContractAttribute
Atributo Descripcin
Conceptos clave:
Describe la forma del dato dentro de los mensajes de envio y recepcin
(Cmo los tipos .NET son convertidos a mensajes)
Permitir serializados y deserializados de tipos de datos complejos
Definido como clase (o structs) decorado con atributos DataContract y DataMember
DataContract atributo que identifica cada clase a ser serializado
DataMember atributo que identifica los miembros expuestos de la clase
[DataContract]
public class customer{
[DataMember]
public string CustomerID {get; set;}
[DataMember]
public string CompanyName {get; set;}
}
Para declarar un tipo de dato como un contrato de dato, es necesario decorar con este atributo
DataContractAttribute. Si una clase o estructura es decorado, entonces es necesario decorar
cada miembro que se desea exponer con este atributo DataMemberAttribute.
Por defecto, cuando se utiliza el atributo DataContract, solamente los miembros marcados con
el atributo DataMember son serializados, El DataMember puede ser aplicado en ambas
propiedades y campos, ambos pblicos y privados.
IsReference: Indica si preserva la referencia del objeto dato que utilizado para soportar
las referencias circulares.
Name: Especifica el nombre del contrato de dato por el tipo.
Namespace: Especifica el espacio de nombres del contrato de dato por el tipo.
Ejemplo: El siguiente cdigo es un ejemplo de contrato de dato y su correspondiente
representacin en XML.
Atributo Descripcin
Especifica si serializar el valor por defecto para un campo o propiedad a ser serializado
EmitDefaultValue (por ejemplo, configurar la propiedad a false no serializar los campos numricos o
propiedades que tengan un valor de 0, o tipo de referencia que tiene un valor null)
Instruye que el motor de serializacin que el miembro debe estar presente cuando es
IsRequired deserializado, si el miembro no est presente cuando est deserializando, una
excepcin ser lanzado
Name Especifica el nombre del data member
Especifica el orden de serializacin y deserializacin de un miembro. Por defecto si este
Order
no est configurado, este ser organizado alfabticamente en el resultado de XML
Ejemplo: En el siguiente ejemplo se demuestra que un tipo Employee con un miembro Name
ser serializado como un elemento FullName y un miembro Age que debe existir en la salida
del XML.
Cuando una clase no es decorado con el atributo DataContract, El Data Contract Serializer
serializar automticamente todas las propiedades pblicas y los campos que este encuentre
en la clase.
Escoger cual approach utilizar depende de las caractersticas de la clase, cual extenso es,
cuantos nuevos miembros sern aadidos despus y cul es la distribucin de los miembros de
serializado y no serializado, usualmente es preferible escoger usar una tcnica y aplicar esto a
todas las clases para prevenir confusiones.
Contrato de fallas (Fault)
Conceptos de Fallo:
[OperationCotract]
[FaultContract (typeof(ErrorInformation))]
int Add (int a, int b)
[DataContract]
public class ErrorInformation{
[DataMember]
public string ErrorMessage {get; set;}
}
Cuando un servicio est corriendo y este servicio encuentra problemas, este usualmente
lanzar alguna clase de excepcin, este podra ser una excepcin no planificado (por ejemplo,
si la base de datos pierde la conexin), o una excepcin planificada (por ejemplo, si el cliente
enva el valor del parmetro incorrecto del servicio, esto es inaceptable).
Por defecto, lanzando una excepcin hacia el cliente, este resultar en el servicio retornando
un cdigo HTTP 500 con un mensaje de falla en SOAP, conteniendo un mensaje arbitrario,
como se ve en el siguiente mensaje:
Este mensaje se obtendr por defecto, porque los servicios WCF no expone la excepcion que
fue lanzado dentro del codigo de servicio por razones de seguridad, este podria contener datos
sensibles que tu no quieres exponer a los clientes. Sin embargo si tu deseas retornar el
mensaje original de la excepcion y la pila de almacenamiento para propsitos de debugging,
puedes activar la bandera includeExceptionDetailsFault en la configuracion del
comportamiento del servicio.
Sin embargo algunas veces solo escribiendo un cadena de fallas no es suficiente, y se requiere
una falla que contenga ms informacin, como ser el problemas relacionados a los datos
causados por la excepcin, un identificador especial y nico del error que puede ser usado
para contactar al administrador del servicio para una futura investigacin y otro posible dato, en
este caso se podra utilizar este excepcin de clase genrica FaultException<T> que permite
especificar un contrato de dato que mantendr informacin acerca del error, por ejemplo el
siguiente cdigo causa un objeto ErrorInfo (un contrato de dato personalizado) a ser retornado
al cliente en la seccin de falla de SOAP.
Para el cliente reconocer estos contratos de datos y la invocacin de servicios con el bloque
try/catch que manejan estas excepciones especficas, tambin es necesario adicionar esos
contratos de datos especiales (llamado contrato de fallas) a tu contrato de servicio, como en sl
siguiente ejemplo:
Adicionando estos contratos de fallos permitir a los clientes manejar excepciones de fallos
especficos.
Contrato de Mensajes (Message)
Conceptos clave:
Un Contrato de Mensaje describe el dato como un mensaje SOAP
(como los tipos CLR son emitidos a los mensajes SOAP)
Definir una clase (o estructura) decorado con los siguiente atributos:
MessageContract
MessageHeader
MessageBodyMember
[MessageContract]
public class Employee
{
[MessageHeader]
public string Name {get; set;}
[MessageBodyMember]
public int Age {get; set;}
}
El sobre SOAP contiene una cabecera y un cuerpo, usualmente el cuerpo contiene el dato que
es enviado al servicio, mientras que la cabecera contiene informacin especfica de la
aplicacin, como ser autenticacin y transaccin de la informacin.
Los contratos de datos son automticamente colocados dentro del elemento body de SOAP.
Sin embargo, cuando uno necesita que un miembro especfico del contrato de dato sea
colocado dentro de la cabecera de SOAP, es posible utilizar contratos de mensajes en lugar de
Contratos de Datos para especificar cules son los miembros de tu tipo de dato que ser
colocado dentro de la cabecera y cuerpo de SOAP respectivamente.
Los contratos de datos son las proyecciones de los tipos Common Language Runtime (CLR)
dentro de una declaracin de XML Schema Definition Language (XSD), los mensajes de
contrato son proyecciones de los tipos CLR dentro de la envoltura de SOAP.
Ejemplo: El siguiente contrato de mensaje causar el miembro Name a ser emitido dentro de la
cabecera de SOAP, mientras el miembro Age ser colocado dentro del cuerpo de SOAP.
Atributo Descripcin
WrapperNamespace Especifica el espacio de nombre del elemento envoltura del cuerpo del mensaje.
Atributo Descripcin
Especifica un URI que indica el nodo en el cual la cabecera is colocado (rol de la
Actor
cabecera del atributo para SOAP 1.2 y la cabecera de actor para SOAP 1.1).
HasProtectedLevel Indica si el miembro tiene asignado un nivel de proteccin.
Especifica si el nodo est actuando en el rol de Actor, este debe entender esta
MustUnderstand
cabecera.
Name Especifica el nombre del elemento para este miembro.
Namespace Especfica el espacio de nombre del XML para del elemento para este miembro.
Especifica si el miembro esta como debe ser transmitido, firmado o firmado y
ProtectionLevel
encriptado.
Relay Especifica si esta cabecera debe ser transmitida hacia los nodos inferiores.
Atributo Descripcin
Por ejemplo, para encriptar el cuerpo del mensaje sin encriptar la cabecera del mensaje, tu
puedes escribir un contrato de mensaje similar al siguiente cdigo.
Contrato de Mensajes (Message)
Conceptos clave:
Un Contrato de Mensaje describe el dato como un mensaje SOAP
(como los tipos CLR son emitidos a los mensajes SOAP)
Definir una clase (o estructura) decorado con los siguiente atributos:
MessageContract
MessageHeader
MessageBodyMember
[MessageContract]
public class Employee
{
[MessageHeader]
public string Name {get; set;}
[MessageBodyMember]
public int Age {get; set;}
}
Cuando se escribe una operacin de servicio, es necesario tomar en cuenta como deberan
interactuar el cliente y el servicio de operacin.
El cliente necesita esperar una respuesta de los servicios? O puede este seguir su
curso y recibir las respuestas mas tarde? Por ejemplo por mail.
Cada request realizado desde el lado del cliente estn esperando una respuesta del
servicio de operacin? O el cliente quiere utilizar el patron Publisher/Subscriber para
obtener mltiples respuestas que corresponden a un simple request?
El cliente necesita esperar por una respuesta aun si la operacin no retorne ningn
dato? Asimismo el cliente necesita saber que la operacin fue completado
satisfactoriamente? O es suficiente para el cliente saber que el servicio recibi el dato y
esta trabajando en ello?
EL servicio de operacin retorna mucha informacin que debera ser distribuido hacia
los clientes? O el cliente necesita distribuir mucha informacin hacia el servicio en
lugar de enviar todo esto en un solo bloque.
WCF te permite seleccionar un adecuado patron para el envo de mensajes para soportar los
escenarios descritos arriba y muchos otros, en la siguiente tabla se describen todos los
patrones de mensajes disponibles en WCF:
Atributo Descripcin
Request-Response El cliente llama al servicio y es bloqueado hasta que el servicio complete la operacin.
One-Way El cliente llama al servicio sin esperar que la operacin fue completado
El cliente llama al servicio utilizando tanto los patrones request-response y el patron
one-way. Cuando el servicio tiene un mensaje para enviar al cliente, este utiliza ambos
Duplex (Callback) patrones para enviar el mensaje de respuesta hacia el cliente. Utilizando el patron
dplex, el servicio puede enviar independientemente el mensaje hacia el cliente.
Utilizando el patron dplex significa que ambos terminan de actuar como un servicio.
Tanto el cliente como el servicio (o ambos) envan datos utilizando una tcnica de
Streaming distribucin, es posible utilizar este patron en conjuncin con cualquier otro patron
descritos arriba.
Note: aunque el patron Streaming no es aplicado de la misma manera como el resto de los
patrones (este es definido en Bindings y no en el contrato de servicios o contrato de operacin),
este es aun considerado un patron de envo de mensajes porque este define la manera en que el
cliente y servicio intercambian la informacin.
Patron (1): Request-Response
Conceptos claves:
Este patron tambin conocido como request-reply, es uno de loa patrones de mensaje mas
utilizados en los servicio de WCF y en la Web. (la comunicacin en HTTP esta basado en este
patrn de request-response, asi ASP.NET y tambin las tecnologas de servicios web).
Porque el iniciador de la sesin fue el cliente y el servicio apenas acepta el request y retorna
una respuesta adecuada, esta tcnica tambin trabajar cuando se tenga un Firewall que
previene la maquina del server abriendo conexiones hacia afuera.
Desventajas de request-response:
Request-Response bloquea al cliente mientras espera que el servicio responda. Por lo tanto
esto no es muy bueno, porque aparecen grades retardos en repuestas desde el lado de
servidor, los usuarios de interfaces se congelan, o en el peor de las casos las operaciones que
toman tiempos largos en la ejecucin de las operaciones causando timeouts y excepciones en
el lado de cliente.
Si muchos clientes envan requests al servidor al mismo tiempo, el servicio utiliza grandes
cantidades de recursos para manejar todos esos requests concurrentemente, este tipo de
situaciones pueden causar altos tiempos de respuesta inclusive timeouts. Si el servicio hace
uso de otros servicios para obtener dato, y estos servicios tambin utilizan el patron request-
response y as sucesivamente.
Como se puede observar no existe otro atributo o una configuracin especial en el servicio de
operaciones para utilizar el patron request-response. WCF utiliza el patron request-response
por defecto para todas las operaciones.
Si se llama la operacin Add desde el cliente, el cliente enviar el siguiente mensaje al servicio.
Notar que WCF crea un elemento XML con el nombre de la operacin seguido por el
sufijo Response por defecto, y eso retorna el valor de la operacin envuelto en un
elemento donde cuyo nombre es el nombre de la operacin seguido por el sufijo
Result.
Nota: el ejemplo anterior de XML muestra la respuesta de una manera simplificada, el mismo
que se ve cuando se llama un servicio utilizando el mtodo HTTP GET, si WCF es llamado
utilizando el mtodo HTTP POST envuelto con SOAP, se obtendr una respuesta envuelto en
SOAP.
Patron (2): One-way
Conceptos claves:
Con este patron el Cliente enva un request y no espera una respuesta
El server puede responder por otro canal
No existe bloqueo en las llamadas, resolviendo los problemas de escalabilidad
Este patron es complicado:
No es amigable con Firewall
El servicio debe conocer donde enviar el resultado
Introduce problemas de escalabilidad
Ejemplo real: email
El patron one-way permite a un cliente enviar un mensaje al servicio sin esperar una respuesta
este patron de mensajes es muy til en los siguientes casos:
El patron one-way significa que el cliente no espera una respuesta del servidor, y esto no
implica nada de que hace el servicio una vez la operacin es completado. El servicio puede:
Enviar una simple respuesta de alguna manera (ejemplo un mail o enviar fuera un
archivo).
Abrir un canal one-way de regreso hacia el cliente y enviar la respuesta a travs de ese
canal (este implica un patron de mensaje dplex).
Enviar mas de una respuesta utilizando una de las tcnicas ya descritas arriba
(ejemplo, el patron Publisher/Subscriber).
No hacer nada.
Si el cliente no espera una respuesta, el servicio puede hacer lo que quiera con este request
(ejemplo, el uso de MSMQ binding se aplica aqui).
Nota: one-way aun requiere que el servicio responda a un request con un conocimiento de la
respuesta, por ejemplo cuando se utiliza el binding HTTP, servicio responder con un mensaje
de HTTP 200 OK, asi aunque one-way parece no bloquear las llamadas del cliente, la
llamada es en realidad bloqueada hasta que el cliente reciba el conocimiento del servicio. Este
conocimiento puede ser retrasado si existe problemas en la red o si el servicio est manejando
muchos requests y no est disponible para las respuestas-
Nota: Lanzar excepciones en una operacin de one-way causar que la operacin falle, pero
ninguna excepcin ser retornada hacia el cliente. Es una buena prctica atrapar esas
excepciones y registrarlos, y notificar a un administrador que ha ocurrido una excepcin
guardando la excepcin le permitir reenviar el mensaje a la operacin del servicio cuando el
problema fue arreglado.
Declarar una operacin de servicio como una operacin one-way, aqu es necesario configurar
la propiedad IsOneWay del atributo OperationContract a true.
Notar que cada una de las operaciones one-way estn marcados con IsOneWay=true. Esto es
necesario configurar en cada operacin que ser utilizado por el patron one-way.
Note que porque un patron one-way no retorna una respuesta, entonces el valor de retorno de
la operacin debe ser de manera obligatoria un void, si se trata de retornar un valor de una
operacin one-way, entonces la siguiente excepcin es lanzado:
Cuando se usa el patron de mensaje one-way, habr casos donde el servicio necesitar enviar
respuestas de regreso hacia el cliente.
En este caso, adems de una operacin de servicio one-way que el servicio expone, el cliente
tambin exponer su propia one-way operacin de modo que el servicio podra abrir un canal
hacia el cliente y enviar dato, el siguiente cdigo muestra contratos tanto para cliente y servicio.
Porque el cliente aloja un servicio y expone un endpoint, el servicio el cual necesita retornar la
respuesta necesitar conocer este endpoint su direccin, binding y contrato y debera ser
capaz de alcanzar a travs de la red con Firewall.
Patron (3): Duplex channel
Conceptos claves:
La implementacin de este callback del patron de dplex channel puede ser visto en un
mundo distribuido.
Para permitir que el servicio use un callback que reside en el lado del cliente, el servicio
necesita abrir una conexin hacia el cliente. Hacer esto posible, el cliente necesita ejecutar dos
acciones:
1. Crear un servicio y alojar esto dentro de una aplicacin de cliente, el servicio ser
capaz de abrir un canal de modo que el servicio y enviar un mensaje al cliente.
2. Enviar informacin a cerca de la direccin del cliente al servidor, as el servidor sabr
cmo llamar al cliente.
Nota: cuando se utiliza un canal dplex, WCF automticamente incluye informacin acerca
del cliente callback en cada mensaje que es enviado al servicio.
Hay situaciones donde el cliente y el servicio, ambos hacen uso del contrato, como en el
siguiente ejemplo:
Para permitir una comunicacin dplex, el cliente tambin debe implementar en contrato
callback, el cual fue definido en el servicio.
Por ejemplo, si el cliente es una aplicacin WCF, su implementacin podra ser similar al
siguiente cdigo:
El cliente necesita implementar el contrato callback el cual puede ser hecho creando una clase
separada que implementar la interfaz, o implementar la interfaz en una clase existente, como
ser un formulario que ser utilizado para desplegar los resultados del callback, esto fue
demostrado en el cdigo anterior configurando la clase MainWindows implementando la
interfaz ICalcDuplexCallback.
Cuando el cliente utiliza un canal dplex para comunicarse con el servicio, en cada llamada
que el cliente hace al servicio, la informacin acerca del canal callback es pasado al servicio
para permitir la comunicacin two-way.
Con el objetivo de instanciar el canal, el cliente necesita pasar un parmetro que contiene
informacin acerca del canal callback. Este es el objeto InstanceContext que es pasado en el
ejemplo.
Nota: el consorcio del estndar W3C previene el uso de HTTP como un canal dplex; este
solamente puede ser utilizado como request-response, canal stateless. Para implementar
un canal dplex utilizando HTTP, el wsDualHttpBinding realmente crea dos canales de
request-response, uno para llamar al servicio y el otro para recibir llamadas del servicio.
Patron (4): Streaming
Conceptos claves:
En caso de enviar mensajes con grandes cantidades de informacin desde el cliente al servicio
o viceversa ejemplo cargar o descargar archivos aqu podra considerarse enviar dato
utilizando el transporte de streaming en lugar de utilizar el estndar cache transporte.
Demo: Patrn de mensajes
Conceptos Clave:
Request-Response / Request-Reply
Espera respuesta, si no timeout / frozen
One Way
Contratos void
Duplex Channel
Tanto cliente y servicio actan como servicios
Streaming
Se implementa en configuracion
Lab: Disear e implementar un contrato
Introduccin:
En este laboratorio consiste en crear contratos de servicio, dato y fallo para mostrar un servicio.
Luego implementar el contrato y exponerlo utilizando el documento WSDL.
Una vez que el servicio est listo observar como son transferidos los mensajes entre el cliente
y el servicio, y verificar que cumplen con el contrato.
[ServiceContract(Name = "WeatherReport",
Namespace = "http://www.fundacion-jala.com/wcf")]
Tarea 3: Actualizar los cambios en el cliente segn los cambios del servicio
1. Abrir la interfaz ITemperatureService
2. Cambiar el tipo de dato del mtodo GetCurrentTime() de int a double
3. Adicionar un nuevo contrato
[OperationContract]
double GetForecast();
return currentTemp;
8. Implementar el mtodo del nuevo mtodo que se adicion en la interfaz
ITemperatureService:
return forecastTemp;
}
[OperationContract]
double GetCurrentTemp(string city);
[DataMember]
public string Author { get; set; }
10. Editar el formulario Form1 en modo texto y aadir una lnea en el evento
saveForecastButton_Click:
[DataMember(IsRequired=true)]
public string Author { get; set; }
//[DataMember(IsRequired=true)]
public string Author { get; set; }
[DataContract]
public class ConnectionFault
{
[DataMember]
public string Operation;
[DataMember]
public string Reason;
[DataMember]
public string Details;
}
[DataContract]
public class DataFault
{
[DataMember]
public string Operation;
[DataMember]
public string Reason;
[DataMember]
public string Details;
}