Mdulo 3

DEFINIR E IMPLEMENTAR CONTRATOS EN WCF

Qu es un contrato en WCF?

Tipos de Contratos en WCF:

Contratos de Servicio

Contratos de Datos

Contratos de Mensaje

Patrones de intercambio de mensajes

Diseo de contratos en WCF

Laboratorio: Diseo de contratos en WCF

 Contenido

Qu es un Contrato en WCF?

Tipos de Contratos en WCF:

Contratos de Servicio
Contratos de Dato
Contrato de Fallo
Contratos de Mensaje

Patrones de intercambio de
mensajes

Diseo de Contratos en WCF

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

La arquitectura de WCF esta conducido por los principios de Arquitectura Orientados a

Servicios (SOA), y una de las caractersticas dice que el servicio comparte su esquema y
contrato pero no su clase, esto significa que el servicio debera declarar que es capaz de
ofrecer la forma de contrato (mtodos), usualmente Web Services Description Language
(WSDL). Tambin cuales con los esquemas que este espera ser recibido y retornado.

Servicio es datos de entrada y datos de salida

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.

Que es lo que un contrato define?

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

El contrato de servicio es un acuerdo entre el cliente y el servicio de cmo llamar al servicio y

como hacer la transferencia de un lado a otro.
 Transferencia de informacin en un
Contrato

Un contrato que se declara para un servicio, este implica una combinacin

de diferentes contratos, donde cada contrato es responsable para un tipo
especfico de informacin que el servicio expone acerca de si mismo.
Operaciones expuestas por el servicio: Define que puede hacer el servicio
Representacin del dato: Define cual es el dato que el servicio requiere para sus
diferentes operaciones y como transferir este dato al servicio
(una manera es serializar en formato XML)
Tipos de errores (faults): Define la informacion extra que el servicio provee al
cliente en caso de occurrir una excepcion.
Patrones de mensaje: Define como el cliente y servicio intercambian los mensajes
(ejemplo: el cliente necesita esperar una respuesta? O este continuar sin hacer
caso si este recibe respuestas al mensaje enviado)

La declaracin de contrato para un servicio es una combinacin de varios contratos, y cada

contrato es responsable del tipo de informacin que este expone, los tipos de contratos son:

Operations: Define que es lo que hace el servicio

Data representation: Define el dato que el servicio requiere para sus operaciones, y
como transferir este dato hacia el servicio (serializado en un formato XML).
Errors (fault): Define cuales es la informacin adicional que provee el servicio hacia el
cliente en caso de que una excepcin suceda.

Nota: en WCF usualmente se utiliza la palabra faults en lugar de Exceptions.

Messaging Patterns: Define el intercambio de mensajes entre un cliente y servicio

(ejemplo, necesita el cliente esperar una respuesta? O continuar corriendo sin tomar en
cuanta si este recibe o no una respuesta al mensaje que se envi).
Si este mtodo fue expuesto como una operacin de servicio, entonces el contrato de servicio
incluye:

1. El nombre de la operacin PerformResult y nombre de parmetro request

2. El dato que el servicio acepta del tipo ComputationRequest y el dato que servicio
retorna del tipo ComputationResult
3. La representacin del dato como los Operators enum ser representado en XML
dato.
4. Las posibles excepciones (faults) que el servicio podra lanzar retornando como una
falla en SOAP.
5. La informacin acerca de cmo esta especfica operacin de las funciones recibe un
mensaje y retorna un mensaje. (esto se ver con ms detalle ms adelante).

Un contrato de servicio comprende de toda la informacin anteriormente mencionada.

 Contrato de Servicio (Service)

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.

Escribiendo un Contrato de Servicio:

Para escribir un contrato se necesita crear una interface que actuar como contrato, este
puede ser escrito en cualquier lenguaje .Net.

Nota: Para hacer uso de ServiceContractAttribute y OperationContractAtribute, es

necesario hacer referencia a System.ServiceModel assembly, el cual es parte de Microsoft
.Net Framework.
Para que esta interfaz sea valido como Contrato de Servicio primero es necesario:

Decorar la interface con ServiceContractAttribute

Decorar los mtodos de la interface con OperationContractAtribute. Los mtodos que
no son decorados con este atributo no sern considerados como operaciones de
servicio, y no sern expuestos en el contrato.

Nota: El ServiceContractAttribute puede ser aplicado tanto en la interfaz como en la clase

que lo implementa, en lugar de escribir la interface y la clase en diferentes clases separados.

El ServiceContractAttribute

Se puede inicializar el atributo ServiceContract con diferentes parmetros, los mismos se

describen a continuacin:

Atributo Descripcin

Name Especifica el nombre para el elemento <portType> en WSDL

Namespace Especifica el espacio de nombre del elemento <portType> en WSDL
Especifica el nombre utilizado para localizar el servicio en una aplicacin de
ConfigurationName
configuracin de archivo.
Especifica si el binding para el contrato soporta el valor de la propiedad
HasProtectionLevel
ProtectionLevel.
Indica si el miembro tiene un ProtectionLevel asignado. La propiedad
ProtectionLevel especifica el grado de encriptacin, firmas digitales o
ProtectionLevel
ambos que requiere el contrato Binding para los endpoints que el contrato
expone.
CallBackContract Especifica el tipo de contrato callback cuando el contrato es dplex.
SessionMode Especifica si las sesiones son permitidos, no permitidos o requeridos.

Ejemplo: el siguiente contrato muestra el uso de estos parmetros en uso.

El OperationContractAttribute

El atributo OperationContract tiene la lista de propiedades en la siguiente tabla:

Atributo Descripcin

Action Especifica la accin WS-Addressing del mensaje requerido

 Indica que una operacin es implementado asincrnicamente utilizando un
AsyncPattern par de mtodos Begin<methodName> y End<nethodName> en el
servicio de contrato
Indica si el mensaje para esta operacin tiene un especifico
HasProtectionLevel
ProtectionLevel
Obtiene o configura un valor que indica si el mtodo implementa una
IsInitiating operacin que puede iniciar una sesin en el servidor si es que ya existe
uno.
IsOneWay Indica si una operacin no retorna una respuesta de mensaje.
Indica si la operacin del servicio causa cerrar la sesin del servidor
IsTerminating
despus de responder el mensaje.
Name Especifica el nombre de la operacin.
Especifica si los mensajes de la operacin debe ser encriptado, formado o
ProtectionLevel
ambos.
Especifica el valor de la accin de SOAP para responder al mensaje de la
ReplyAction
operacin.

Ejemplo: el siguiente contrato muestra el uso de estos parmetros en uso.

 Contrato de Dato (Data)

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

Tanto ServiceContractAttribute y OperationContractAttribute especifican cuales son las

operaciones que un servicio expone. El Contrato de Dato especifica la forma del dato que pasa
como parmetro a las operaciones de los servicios y es retornado por estas operaciones.

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.

Ejemplo: declaracin de una tipo de enumeracin (enum):

Los DataContratAttribute, DataMemberAttribute y EnumMemberAttribute no son parte del

mismo WCF, pero son parte de Data Contract Serializer. En WCF el mecanismo de
serializacion no se refiere a XmlSerializer, este es utilizado ampliamente en .Net, (por ejemplo
para implementar un ASP.NET Web Service, y utilizar estos atributos, es necesario aadir una
referencia a este assembly System.Runtime.Serialization).

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.

El atributo DataContract tiene las siguientes propiedades:

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.

Note: Es necesario dar un espacio de nombre principal como ser:

http://my.domain.name/product/year/month/component.

La siguiente tabla lista las propiedades adicionales del atributo DataMember:

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.

Nota: Cuando adicionamos un nuevo miembro a un Contrato de Dato existente despus de

que el servicio ya haya sido completado y utilizado por los clientes, es necesario configurar la
propiedad IsRequired con un valor false, si no, los varios de los clientes podran fallar cuando
estn llamando al servicio y el servicio no tendr una compatibilidad hacia atrs.
En .NET 3.5 SP1, el Data Contract Serializer tambin soporta la deserializacin del dato sin la
necesidad de decorar la clase y sus miembros con los atributos DataContract y DataMember.

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.

Entonces se podra escoger un inclusive approach o un exclusive approach:

Inclusive approach: Especifica el atributo DataContract y aplicar el DataMember a

cada miembro que necesita ser serialiazado.
Exclusive Approach: No utiliza DataContract y configura el atributo
IgnoreDataMember en propiedades y campos pblicos que no se requiere serializar.

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:

Un Contrato de Fallo describe la informacion del error de la seccion de mensaje SOAP

Contratos de Fallo son definidos utilizando un contrato estandar de dato y
el atributo FaultContract decorando la operacion

[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.

Despus de activar la bandera, el mensaje de falla retornado se puede observar en el siguiente

cdigo. (El contenido de la excepcin variar de acuerdo a una excepcin especfica).
Nota: En este mensaje, las fallas de SOAP contiene un elemento detail que oncluye todos los
detalles de la instancia que lanza la excepcion, esto es muy importante para debugging de los
escenarios y puede ayudar a detectar los problemas del servicio mas rapidamente, recuerda
que no es prudente pasar informacion con excepciones sensitivos hacia el cliente.

En lugar de activar activar la bandera includeExceptionDetailInFaults, se puede lanzar una

excepcion FaultException que describir la razon del problema, como se describe en el
siguiente ejemplo:

Lanzando una excepcin FaultException en lugar de una excepcin estndar permitir al

servicio incluir el texto de la excepcin en la seccin de fallo de SOAP sin revelar la informacin
sensitiva de la excepcin como ser la pila de excepciones.

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

Cuando un mensaje es enviado desde un cliente a un servicio o desde un servicio a un cliente,

el contenido del mensaje esta envuelto en un sobre SOAP, como se muestra en el ejemplo
siguiente:

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.

Si se requiere que un miembro especfico est disponible dentro de la cabecera de SOAP,

entonces ese miembro necesita ser decorado con el atributo MessageHeader, ahora si es
necesario que un miembro est disponible en el cuerpo de SOAP, entonces este debe ser
decorado don el atributo MessagebodyMember.
Este nivel de control sobre la manera en que un mensaje es construido soporta escenarios
donde uno de los lados (tanto el cliente o el servicio) requiere una pieza de dato a ser colocado
fuera de la seccin body, por ejemplo se podra usar el contrato de mensaje para posicionar
todos los datos sensibles dentro del cuerpo de SOAP y encriptar, y dejar desencriptado los
datos que necesitan ser validados por los firewalls en la cabecera de mensaje.

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.

El atributo MessageContract soporta las siguientes propiedades, listados en la siguiente tabla:

Atributo Descripcin

HasProtectionLevel Indica si el mensaje tiene un nivel de proteccin.

IsWrapped Especifica si el cuerpo de mensaje tiene un elemento de envoltura.

ProtectionLevel Especifica si el mensaje debe ser encriptado, firmado o ambos.
WrapperName Especifica el nombre del elemento de envoltura del cuerpo de mensaje.

WrapperNamespace Especifica el espacio de nombre del elemento envoltura del cuerpo del mensaje.

Es posible configurar el atributo MessageHeader despus, utilizando las propiedades que se

listan a continuacin:

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.

Es posible configurar el atributo MessageBodyMember despus, utilizando las siguientes

propiedades listado a continuacin:

Atributo Descripcin

HasProtectedLevel Indica si el miembro tiene asignado un nivel de proteccin.

Name Especifica el nombre del elemento que corresponde a este miembro.
Especifica el espacio de nombre del XML del elemento que corresponde a este
Namespace
miembro.
Indica la posicin en el cual el miembro es serializado dentro del cuerpo de
Order
SOAP.
Especifica si el miembro esta como debe ser transmitido, firmado, o firmado y
ProtectionLevel
encriptado.

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

Los patrones de mensajes describen el intercambio de informacin entre el cliente y servicio.

En ASP.NET Web Services solamente exista un mensaje de patrn. El patron request-
response es cuando el cliente enva un mensaje al servicio y espera una respuesta (reply) del
servicio WCF soporta 2 adicionales patrones de mensajes: los patrones one-way y dplex
(callback).
 Patrones de mensajes soportado en WCF

Que es Patron de Mensajes?

Los patrones de mensajes describen la manera en que los Clientes y Servicios

WCF soporta 4 patrones de mensajes:

Request-Response
One-Way
Duplex
Streaming

El Patron de mensajes es utilizado como parte del Contrato:

Los patrones de mensajes describen la manera en que los Clientes y Servicios
intercambian la informacion (ASP Web Services solo hay un patron request-response)

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:

Es el patron mas popular

El servicio no conoce al cliente
Amigable en firewalls
Este patron es un bloqueo al servicio de llamada:
Ejemplo real: Simple request de la web
Introduce problemas de escalabilidad

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

Nota: Si el patron no es especificado de otra manera, request-response es el patron de

mensaje por defecto que ser aplicado a la operacin de servicio.

El request-response tiene sus ventajas:

El servicio no necesita saber la informacin de los endpoints de los clientes cuando se

est retornar una respuesta de regreso hacia el cliente.
Cada request es respondido por una simple respuesta. (La respuesta puede contener
dato o estar vacio si la operacin est configurado para retornar un void)
Usar este patron es similar a una llamada a una funcin, en cliente enviar un request
(call) y esperar hasta que la operacin (funcion) termine su trabajo y retorne una
respuesta (return value).
Este patron permite un simple modelo de hilos, aunque podra aplicarse el patron
asncrono de .NET, de modo que el cliente puede ejecutar otras tareas mientras el
trabajo est trabajando.

Como trabaja request-response:

El mecanismo request-response utiliza contextos de operacin El actual contexto

conversacin entre el cliente y el servicio. WCF deja la sesin abierta hasta la operacin de
servicio complete su trabajo y enva una respuesta hacia el cliente a travs de esa sesin.

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.

Nota: es posible manejar las situaciones de bloqueos utilizando servicios asncronos.

Ejemplo, como implementar el patron Request-Response:

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.

Cuando el mensaje llega al servicio, este ejecutar los siguientes pasos:

1. Direccionar el mensaje a una apropiada operacin de servicio (por ejemplo, un

mtodo particular en una instancia del servicio).
2. Invocar la operacin y retornar una respuesta (return value) a la capa de modelo
de servicio de WCF (la capa es la responsable de pasar llamadas a los mtodos
del servicio y pasar las respuestas hacia el cliente).
3. Transformar la respuesta a un mensaje de respuesta, y enviar esto de regreso
hacia el cliente, el siguiente ejemplo muestra como es respondido a la operacin
Add.

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 servicio de operacin no retorna un resultado, pero el cliente puede continuar su

trabajo su hacer caso si su trabajo fue completado o esta en progreso.
El servicio de operacin necesita retornar un resultado al cliente, pero el cliente no
necesariamente necesita una respuesta inmediatamente o el servicio necesita enviar
una respuesta a otro request.

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.

Beneficios del patron one-way:

Usando el patron one-way, el cliente no es bloqueado y continua corriendo mientras que el

servicio contina haciendo su trabajo.

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

Desventajas del patron one-way:

Implementar un servicio que utiliza el patron de mensajes one-way es ms complicado, porque

el servicio necesita saber cmo comunicarse de regreso con el cliente, y cul es el cliente
correcto al cual debera enviarse la respuesta.
Si el servicio responde abriendo un canal hacia el cliente, esta necesita mantener un registro
para saber si el cliente aun esta activo y asegurarse que no hay Firewall que prevenga la
apertura de canales (este caso ocurre frecuentemente cuando el cliente puede llamar al
servicio pero no viceversa, por seguridad).

Aunque implementar el patron de mensajes one-way es ms complicado que utilizar un

estndar patron de mensajes request-response, esto algunas veces ofrece mejor
escalabilidad para tu servicio.

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.

Implementar el patron one-way:

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:

Nota: el contrato de servicio y contrato de operacin no implica como el servicio enviar la

respuesta de vuelta hacia el cliente (una respuesta ser la respuesta ser enviado a todos). A
menos que se use el patron de mensaje Duplex, entonces ser necesario hacer conocer a los
clientes la tcnica que ha sido escogido para enviar respuestas de regreso al cliente.
Enviar una Response Back al cliente:

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.

Con el objetivo de que un servicio llame a un cliente, el cliente necesitar:

1. Declarar el contrato de servicio y el contrato de operacin para la respuesta la

operacin necesitar ser una operacin one-way.
2. Crear una implementacin de servicio que utilizar la respuesta de alguna manera, y
correlacionar esto con un flujo natural de aplicacin (por ejemplo, desplegar el mensaje
en un MsgBox).
3. Alojar el servicio dentro de la aplicacin.

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:

Este patron implementa el diseo de callback

Este patron es establecido junto con la llamada al servicio
Este canal debe mantenerse vivo durante toda la llamada del servicio
No permite bloqueo de llamadas
Escalable

El patron de mensajes dplex en WCF implementa el patron de diseo de callback. Esto

significa que una funcin callback es invocado despus de que ciertas funciones complete su
trabajo. El patron callback es utilizado en ampliamente en .NET.

El modelo de programacin asncrono en .NET utiliza callbacks (BeginInvoke y

EndInvoke).
El cache de ASP.NET causa callbacks para indicar cuando los tems son removidos
del cache.
ASP.NET Ajax soporta clientes callbacks cuando este llama al servidor.
WPF utiliza callbacks en su mecanismo de dependencia de propiedad

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.

En el lado del servicio, ser necesario ejecutar los siguientes pasos:

1. Cuando un cliente llama a un servicio, guarda el canal callback en algn lugar en el

servicio, hasta que este sea necesario.
2. Una vez que el servicio est listo, el servicio recuperar el canal callback, abrir el canal
hacia el cliente, y entonces llamar la operacin callback.
Implementar el patron Duplex Channel:

El siguiente contrato define tanto el contrato de servicio y contrato de callback:

Ambos contratos de servicios y callback utiliza operaciones one-way para comunicar

entre el cliente y servicio.
En el contrato que el servicio implementa (el primer contrato del cdigo anterior), es
necesario adicionar la propiedad CallbackContract al atributo ServiceContract, el
valor de CallbackContract es el tipo del contrato que el cliente implementa (el
segundo contrato del ejemplo anterior).

Hay situaciones donde el cliente y el servicio, ambos hacen uso del contrato, como en el
siguiente ejemplo:

Proceso de Mensaje Duplex (del lado del Cliente):

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.

El constructor de InstanceContext recibe la instancia de la clase que implementa el contrato

de callback, en este ejemplo, ya que la implementacin de la clase es el actual Windows
aplicacin que est en ejecucin, donde la palabra this es utilizado para esto.

Proceso de Mensaje Duplex (del lado del Servicio):

Para soportar la comunicacin dplex en el lado del servicio, es necesario utilizar uno de los
bindings que soporte crear un canal dplex. En WCF se puede utilizar tanto el canal TCP con
el netTcpBinding, o el canal HTTP con wsDualHttpBinding.

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:

WCF soporta el patron de mensaje Streaming para transmitir

mensajes muy grandes.
Este patron utiliza parametros de operacion (o valores de retorno)
de tipo System.IO.Stream

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

Objetivos del laboratorio:

Ejercicio 1: Crear contrato de servicios

Ejercicio 2: Crear contrato de datos
Ejercicio 3: Implementar Intercambio de mensajes

Tiempo estimado: 45 minutos

Objetivos del laboratorio:

Crear un contrato de servicio por operaciones de request-response y one-way

Crear un contrato de fallo
Desplegar el contrato como un documento WSDL
Observar la realizacin del contrato observando la transferencia de mensajes entre el
servicio y cliente

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.

Ejercicio 1: Crear Contratos de Servicios:

Tarea 1: Abrir la solucin

1. Abrir la solucin ServiceContract.sln del folder
C:\WCF\Modulo03\Lab03\ServiceContracts

Tarea 2: Renombrar el nombre del contrato

1. Abrir la interfaz ITemperatureService
2. Encima del contrato de servicio adicionar el siguiente cdigo:

[ServiceContract(Name = "WeatherReport",
Namespace = "http://www.fundacion-jala.com/wcf")]

3. Seleccionar el proyecto WindowsClient Service References y actualizar

las referencias del servicio (Update Service References)
4. Revisar si las nuevas referencias fueron actualizados en la clase
Reference.cs:
 5. Seleccionar y abrir el archivo Form1 y eliminar la siguiente declaracin:

TemperatureServiceClient proxy = null;

6. Y Reemplazar por la siguiente declaracin de cdigo en la clase Form1

WeatherReportClient proxy = null;

7. Eliminar la siguiente declaracin de cdigo en el evento Form1_Load

proxy = new TemperatureServiceClient (

"WSHttpBinding_ITemperatureService");

8. Y Reemplazar por la siguiente declaracin de cdigo en la clase Form1

proxy = new WeatherReportClient("WSHttpBinding_WeatherReport");

9. Verificar el cdigo Rebuild WindowsClient y el resultado exitosamente

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

4. Actualizar los cambios del servicio en la clase TemperatureService

5. Cambiar el tipo de dato del mtodo GetCurrentTime() a double,
6. Abrir la clase TemperatureService, y del mtodo GetCurrentTemp() eliminar
el siguiente cdigo:

var randomNumber = new Random();

return randomNumber.Next(20, 80);

7. Despus de eliminar el cdigo anterior, reemplazar por el siguiente:

var randomNumber = new Random();

double currentTemp = randomNumber.Next(20, 80) * .8;

return currentTemp;
 8. Implementar el mtodo del nuevo mtodo que se adicion en la interfaz
ITemperatureService:

public double GetForecast()

{
var randomNumber = new Random();
double forecastTemp = randomNumber.Next(30, 90) * .8;

return forecastTemp;
}

9. Abrir la clase Form1 en modo diseo y adicionar un componente Label y

renombrar a temperatureLabel
10. Editar la clase Form1, y aadir el siguiente cdigo dentro del mtodo
getTempButton_Click

forecastLabel.Text = String.Format("The forecast is {0:F1}",

proxy.GetForecast());

11. Verificar el cdigo Rebuild WindowsClient y los resultados exitosamente

Tarea 4: Aadir ms parmetros en el servicio y actualizar en el cliente

1. Abrir la interfaz ITemperatureService
2. En el contrato GetCurrentTime() aadir un parmetro city de tipo string

[OperationContract]
double GetCurrentTemp(string city);

3. Editar la clase TemperatureService actualizar este cambio (string city).

4. Asimismo, en esta clase TemperatureService aadir ms cdigo, como sigue:

5. Verificar el cdigo Rebuild WindowsClient y no existe errores en el servicio

6. Seleccionar el proyecto WindowsClient Service References y actualizar
los cambios del servicio en el cliente (Update Service References)
7. Verificar el cdigo Rebuild WindowsClient y existen errores del nuevo
parmetro que se adicion en el servicio.
8. Seleccionar y abrir el archivo Form1 en modo diseo, y aadir un textBox y
asignarle como nombre cityTextBox
 9. En el mtodo evento getTempButton_Click, hacer uso de este componente
cityTextBox, y el mismo que se muestra de la siguiente manera:

10. Verificar el cdigo Rebuild WindowsClient y los resultados exitosamente.

Ejercicio 2: Crear Contrato de Datos:

Tarea 1: Abrir la solucin y revisar las referencias en el cliente

1. Abrir la solucin ServiceContract.sln del folder
C:\WCF\Modulo03\Lab03\DataContracts
2. Verificar que los tipos de datos definidos en el lado del servicio son idnticos
en el lado del cliente.
En el lado de servicio revisar la interfaz ITemperatureService
En el lado de cliente revisar el esquema TemperatureService.xsd

3. Verificar que la aplicacin guarda la informacin de la temperatura y pronostico

del tiempo en un archivo XML en la direccin C:\Forecast for <Ciudad>

Tarea 2: Aadir nuevos contratos de datos en el servicio y reflejar en el cliente:

1. Seleccionar el proyecto TemperatureServiceLibrary y editar la interfaz
ITemperatureService
2. Aadir un nuevo contrato de dato, el cdigo es como sigue:

[DataMember]
public string Author { get; set; }

3. Implementar el tipo de dato Author en la clase TemperatureService, aadir la

siguiente lnea de cdigo new XElement("Author", forecast.Author), en el
mtodo SaveForecast:

4. Verificar el cdigo Rebuild WindowsClient y sin errores en el servicio

5. Ejecutar el programa F5, y revisar si Author es actualizado en el archivo XML
(por ejemplo, podemos utilizar la C:\Forecast for Cochabamba.xml)
6. Author no se actualiza en el archivo XML porque el cliente no es actualizado
7. Seleccionar el proyecto WindowsClient Service References
TemperatureService y actualizar los cambios del servicio.
8. Revisar que el nuevo tipo de dato Author existe en el cliente (editar el archivo
TemperatureService.xsd)
9. En el archivo Form1 y aadir los controles Label y TextBox, como se muestra
a continuacin.

Label: Name = Author

TextBox: Name = authorTextBox

10. Editar el formulario Form1 en modo texto y aadir una lnea en el evento
saveForecastButton_Click:

11. Verificar la solucin Rebuild WindowsClient y sin errores

12. Ejecutar la aplicacin cliente con F5, y revisar si Author es actualizado en el
archivo XML, como en el siguiente ejemplo:
 Tarea 3: Eliminar cdigo en el servicio y revisar en el cliente:
1. Seleccionar el proyecto TemperatureServiceLibrary y editar la clase
TemperatureService
2. Comentar el cdigo de Author, como sigue a continuacin:

3. No actualizar este cambio del servicio en el cliente.

4. Verificar la solucin Rebuild WindowsClient y sin errores
5. Ejecutar la aplicacin cliente con F5, y revisar si Author es actualizado en el
archivo XML.
S? Porque?
No? Porque?

6. Ahora s, actualizar las referencias del servicio en el cliente.

7. Presionar F5, y que resultado se obtiene?
8. Realice las modificaciones necesaria para su correcto funcionamiento

Tarea 4: Adicionar propiedades de los contratos de datos:

1. Seleccionar el proyecto TemperatureServiceLibrary y editar la interfz
ITemperatureService
2. Aadir la propiedad IsRequired en el contrato de dato Author:

[DataMember(IsRequired=true)]
public string Author { get; set; }

3. En la clase TemperatureService, descomentar la lnea de Author

 4. No actualizar este cambio del servicio en el cliente.
5. Verificar la solucin Rebuild WindowsClient y sin errores
6. Ejecutar la aplicacin cliente con F5, y revisar si Author es actualizado en el
archivo XML.
S? Porque?
No? Porque?

7. Ahora s, actualizar las referencias del servicio en el cliente.

8. Presionar F5, y que resultado se obtiene?

9. Ahora, En el contrato del servicio comentar el contrato Author:

//[DataMember(IsRequired=true)]
public string Author { get; set; }

1. No actualizar este cambio del servicio en el cliente.

2. Verificar la solucin Rebuild WindowsClient y sin errores
3. Ejecutar la aplicacin cliente con F5, y revisar si Author es actualizado en el
archivo XML.
S? Porque?
No? Porque?

4. Ahora s, actualizar las referencias del servicio en el cliente.

5. Presionar F5, y que resultado se obtiene?

Ejercicio 3: Crear Contrato de Fallo:

Tarea 1: Abrir la solucin y revisar las referencias en el cliente

1. Abrir la solucin FaultContract.sln del folder
C:\WCF\Modulo03\Lab03\FaultContract
2. Seleccionar el proyecto CustomerServiceLibrary y editar la interface
ICustomersService, y aadir dos tipos de datos:

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

3. En la interface ICustomersService aadir el atributo FaultContract, en cada

contrato definido, al final esto se ver como sigue:
4. Verificar la solucin Rebuild WindowsClient y sin errores

5. Seleccionar y editar el archivo Customersservice.cs y aadir cdigo en la

clase CustomersService, es decir la implementacin de la clase
ConnectionFault, especficamente dentro del primer bloque catch:

6. Tambin aadir cdigo para implementar la clase DataFault dentro del

segundo bloque catch:

7. Verificar la solucin Rebuild WindowsClient y sin errores

8. Seleccionar el proyecto WindowsClient ServiceReferences y actualizar los
cambios del servicio en el cliente
9. Verificar que los FaultContracts son actualizados en el lado del cliente (revisar
el archivo CustomersService.wdsl)

10. Del mtodo evento (listCustomersButton_Click), actualizar cdigo del

bloque catch, al final se ve como sigue:
 11. Verificar la solucin Rebuild WindowsClient y sin errores
12. Presionar Ctrl + F5, y verificar que los resultados esperados se cumplen.

Ejercicio 3: Implementar intercambio de mensajes (Duplex):

Tarea 1: Abrir la solucin y revisar las referencias en el cliente

1. Abrir la solucin PatronDuplexMessage.sln del folder
C:\WCF\Modulo03\Lab03\PatronDuplexMessage
2. Verificar que la aplicacin cliente obtiene datos del servicio satisfactoriamente.

Tarea 2: En el servicio implementar contratos para mensajes dplex

1. En el proyecto CustomerServiceLibrary y editar el archivo ICustomersService, y
aadir el contrato NotifyCustomer() con la propiedad IsOneWay:

2. Debajo de la interfaz ICustomersService, aadir una nueva interfaz llamado

ICustomersServiceCallback sin el atributo [ServiceContract]

public interface ICustomersServiceCallback

{
[OperationContract(IsOneWay = true)]
void NotifyCustomerCallback(string message);
}
 3. Relacionar esta interfaz ICustomersServiceCallback con la interfaz
ICustomersService

4. En la clase CustomersService, implementar el contrato NotifyCustomer(),

con el siguiente cdigo:

5. Editar el archivo Web.config y actualizar el binding a wsDualHttpBinding:

6. Verificar la solucin Rebuild WindowsClient y sin errores

7. Verificar que el servicio esta arriba sin errores (CustomersService.svc View in Browser)

Tarea 3: En el servicio implementar contratos para mensajes dplex

1. Seleccionar el proyecto WindowsClient ServiceReferences y actualizar los
cambios hechos en el servicio.
2. Verificar que el binding wsDualHttpBinding es actualizado en app.config
3. Adicionar una nueva clase llamado CustomersServiceCallback y aadir el
espacio de nombres using WindowsClient.CustomersService;
4. Implementar la interfaz ICustomersServiceCallback, con el siguiente cdigo:
 5. Seleccionar el archivo Form1.cs y ubicarse en el evento Form1_Load

6. En el evento saveChangesButton_Click, implementar el mtodo NotifyCustomer().

7. Verificar la solucin Rebuild WindowsClient y sin errores

8. Ejecutar el programa con F5, y verificar los resultados

Ejercicio 4: Implementar Bindings personalizados en cdigo:

Tarea 1: Abrir la solucin y revisar las referencias en el cliente

1. Abrir la solucin CustomBinding.sln del folder
C:\WCF\Modulo03\Lab03\CustomBindingDemo
2. Verificar que la aplicacin cliente obtiene datos del servicio satisfactoriamente.

Tarea 2: En el servicio implementar binding personalizados

1. En el proyecto ConsoleHost y editar el archivo Program, y aadir el cdigo para
crear un binding personalizado, el mismo se muestra a continuacin en rojo:
 2. Verificar la solucin WindowsConsole Rebuild y sin errores

3. Ejecutar el programa con F5, y verificar los resultados

Tarea 3: Actualizar los cambios dl servicio en el cliente

1. En el proyecto ConsoleClient
2. Seleccionar el proyecto ConsoleClient Service References
CalculatorService y Update Service Reference

3. Verificar la solucin Rebuild WindowsClient y sin errores

4. Ejecutar el programa con F5, y verificar los resultados