Windows Communication

Foundation in Visual
Studio 2010
Audiencia
Este curso est orientado a personas en la rama de informtica y desarrolladores que quieran
desenvolver las habilidades de programacin utilizando Visual Studio 2010 (C#). Es
recomendable que tengan experiencia previa en el rea de programacin y/o trabajar como
desarrolladores.

Prerrequisitos
Las siguientes herramientas son necesarias para el desarrollo de los laboratorios de este
curso:
Conocimientos suficientes de Programacin Orientada a objetos con versiones
anteriores a Microsoft Visual Studio 2008.
Conocimientos suficientes de programacin de T-SQL y Administracin de Microsoft
SQL Server 2005 o 2008.
Conocimientos suficientes en la administracin de Internet Information Service (IIS 7.0
y IIS 7.5)

Descripcin del laboratorio

En el laboratorio existen 20 maquinas reales identificadas con un IP Address y nombre de
computadora, los mismos ya tienen instalado Microsoft Visual Studio 2010, SQL 2008 y IIS 7.0,
de acuerdo a la siguiente distribucin:

Computadora IP Address Usuario Contrasea

C305-01 172.20.140.11 Administrator Pa$$w0rd

C305-02 172.20.140.12 Administrator Pa$$w0rd

C305-03 172.20.140.13 Administrator Pa$$w0rd

C305-04 172.20.140.14 Administrator Pa$$w0rd

C305-05 172.20.140.15 Administrator Pa$$w0rd

C305-06 172.20.140.16 Administrator Pa$$w0rd

C305-07 172.20.140.17 Administrator Pa$$w0rd

C305-08 172.20.140.18 Administrator Pa$$w0rd

C305-09 172.20.140.19 Administrator Pa$$w0rd

C305-10 172.20.140.20 Administrator Pa$$w0rd

C305-11 172.20.140.21 Administrator Pa$$w0rd

C305-12 172.20.140.22 Administrator Pa$$w0rd

C305-13 172.20.140.23 Administrator Pa$$w0rd

 C305-14 172.20.140.24 Administrator Pa$$w0rd

C305-15 172.20.140.25 Administrator Pa$$w0rd

C305-16 172.20.140.26 Administrator Pa$$w0rd

C305-17 172.20.140.27 Administrator Pa$$w0rd

C305-18 172.20.140.28 Administrator Pa$$w0rd

Nota: Las cuentas de SQL Server son las siguientes:

Server: WIN2008R2
Usuario: sa
Contrasea: Sql2@@8

Materiales de en el laboratorio
Hacer uso de snippets en las demostraciones y para cada laboratorio
Hacer uso de los proyectos creados, los mismos ubicados en C:\WCF

Mdulo 1: Introduccin a WCF

Laboratorio: Ciclo de vida del desarrollo de un servicio
Tiempo estimado: 60 minutos

Mdulo 2: Hosting de servicios WCF

Laboratorio: Hosting servicios en IIS 7.0, WAS, Windows Service y Console
Tiempo estimado: 120 minutos

Mdulo 3: Definir en implementar contratos en WCF

Laboratorio:
Tiempo estimado: 60 minutos

Mdulo 4: Endpoints y Behaviors

Laboratorio:
Tiempo estimado: 60 minutos

Mdulo 5: Testing and troubleshooting de servicios WCF

Laboratorio:
Tiempo estimado: 60 minutos

Mdulo 6: Seguridad
Laboratorio:
Tiempo estimado: 60 minutos

Mdulo 7: Introduccin a tpicos avanzados en WCF

Laboratorio:
Tiempo estimado: 60 minutos

Mdulo 8: Programacin en la Web

Laboratorio:
Tiempo estimado: 60 minutos
Mdulo 1
INTRODUCCION A WCF CON VISUAL STUDIO 2010

Introduccin General

Que es SOA? y sus beneficios

Escenarios y estndares

Qu es WCF?

Introduccin a WCF

Arquitectura de WCF

Contrato de servicio y su implementacin

Alojar servicios WCF

Behaviors WCF

Consumir servicios WCF

Laboratorio: Crear un simple Servicio y Cliente en Visual Studio 2010

 Contenido

Introduccin General

Arquitectura Orientado a Servicios (SOA)

Qu es WCF?

Demostracin

Laboratorio: Crear un simple Servicio y Cliente en

Visual Studio 2010
 Introduccin General

Un poco de Historia

Los components COM

Web Services

Web Services vs. WCF

Windows Communication Foundation (WCF) se refiere a la programacin a cerca de servicios,

entonces usted ser capaz de responder las siguientes preguntas:

Qu son los Servicios?

Diferencia entre desarrollo de servicios y desarrollo de aplicaciones?
Diferencias entre la arquitectura de Servicios y Aplicaciones?

Un poco de Historia:

Un poco d cronologa del progreso de las aplicaciones distribuidas.

Los componentes COM:

Las aplicaciones monolticas dieron una manera para construir aplicaciones

utilizando componentes COM.
Desktop COM dio una manera de distribuir COM (DCOM).
DCOM es envuelto dentro de COM+ e integrado con Micrsoft Transaction Server.
Los components .Net pueden utilizar Enterprise Services para aprovechar COM+.

Despues de los components COM:

.Net Remoting consiste de un cliente y objetos remotos alojados en un servidor

remoto, donde el cliente puede acceder a esos objetos remotos como si fueran
locales.
Enterprise Services y .Net Remoting requiere un que el cliente, components y dato
estn en la misma red. Pero el proble surge cuando los componentes no estan en
la misma red.
Este problema es resuelto con Web Services, donde te permite pasar el dato como
XML por internet. SOAP (Simple Object Access Protocol), define la estructura de
los mensajes XML que se pasan entre el cliente y el servicio
Un servicio es un programa que ejecuta una tarea y que puede interactuar con
mensajes bien definidos.
 Que esta mal con lo que se tiene hasta ahora?

Muchas maneras de crear aplicaciones distribuidas

o Web services (SOA)
o Enterprise Services, .Net Remoteing (not SOA)

Cual deberia utilizar y cuando?

Si es necesario interoperability (si mi cliente es .Net, entonces utilizara .Net

Remoting, si mi cliente es Java entonces se recomienda utilizar Web Services).
Tu aplicacin necesita correr cobre Internet o TCP?
Acceder a los servicios internamente o externamente? Si es externo, se
recomeinda utilizar web services.

Cuan fcil es moverse de una tecnologa a otro?

No mucho, en muchos casos es necesario escribir d nuevo el cdigo.

Que falcencias actuales cubre WCF?

WCF provee un modelo de programacin unificado para construir servicios

orientados a aplicaciones.
Un modelo si la comunicacin es internal o external, no importa si es por TCP o
HTTP, es reconfigurablew.
El mismo servicio puede ser expuesto sobre multiples protocolos duplicando
esfuerzo y cambio de tencologas.

Web Services vs. WCF:

WCF envia mensajes no solamente por HTTP, si no que tambin por TCP y otros
protocolos, mientras quw Web Services solamente soporta HTTP.
Web Services envia solamente mensajes con formatos SOAP. Mientras qie WCF
aparte de SOAP tambin enva mensajes por Representational State Transfer
(REST) y Plain Old XML (POX).
Web service solamente puede ser alojado en un servidor web, mientras que WCF
no esta limitado a un solo hosting, este soports otros hosts aparte de un servidor
web.
WCF Construido para soportar transacciones y sesiones confiables. Y Web
Services no.
 Arquitectura Orientado a Servicios

Qu es SOA

Los beneficios de SOA

Escenarios y Estndares

Qu es SOA?

Arquitectura Orientada a Servicios (SOA) es una interaccin de aplicaciones distribuidas,

interaccin desacoplada, preocupaciones separadas, compartir y reutilizacin.

1. Desafo en la construccin de aplicaciones empresariales:

Si dos compaas queran trabajar juntos, las unidades de IT eran las ms
afectadas
Requerimiento de los clientes de implementar aplicaciones complejas y a menor
costo
Interaccin de diferentes aplicaciones en plataformas diferentes (Java, PHP,
.Net)

Debido a estas complicaciones, SOA fue introducido para reducir estos desafos,
integrando aplicaciones distribuidas de una manera confiable, escalable y segura.

2. Objetivos de Arquitectura Orientado a Servicios

SOA es un estilo de arquitectura que fue desarrollado para resolver los desafos que
presentaban las aplicaciones distribuidas.

SOA provee algunos beneficios como ser:

Agilidad: Segn los principios de SOA, este permite adaptarse inmediatamente a

los cambios del ambiente o cambio de negocios.

Productividad: Adoptando SOA algunas veces puede tomar mas tiempo de lo

previsto que otras estilos de arquitecturas. Con SOA es posible implementar
aplicaciones complejas en menor tiempo y fcilmente.

Reutilizacin: Con SOA es posible reutilizar los servicios en otros dominios en lugar
de re-escribir cdigo nuevamente en cada sistema.
 Reduccin de costo: Con SOA inicialmente tiene su costo, pero al pasar el tiempo,
los servicios se implementan fcilmente reduciendo el costo en la unidad de IT.

3. Qu es un Servicio?

SOA esta basado en Servicios, un servicio es algo que expone una funcionalidad y
puede ser consumido por otros sistemas (llamados clientes).

4. Qu es un Cliente?

Cliente son considerados todos aquellos sistemas que consumen el servicio expuesto.

5. Los servicios se comunican con los clientes a travs de Edges:

El acceso otros sistemas (clientes) a un servicio es a travs de Edges, los Edges son
puntos de acceso al servicio, es donde ah ocurren las interacciones entre el cliente y
servicio. Asimismo el Edge controla protocolo de acceso al servicio, el nmero de
clientes que puede utilizar el Edge a la vez, y otros parmetros.

Los Servicios pueden tener mas de un Edge, y cada Edge puede tener sus propias
caractersticas y configuraciones

Los beneficios de SOA:

SOA se ocupa de muchos aspectos en cmo desarrollar, probar e implementar un servicio.

Para esto existen varios criterios para identificar si el servicio implementado esta correcto:

1. SOA mejora la productividad

Los servicios son autnomos, este previene el cdigo spaghetti

Los servicios con interoperables, utiliza tu tecnologa favorita para el desarrollo
de servicios
Entorno de desarrollo (incluyendo VS2010)
Servicio autnomo facilita el ambiente de prueba

2. SOA permite agilidad

Un cliente depende solamente del contrato, el cambio en la implementacin del

servicio es libre.
Un servicio puede mover, esto significa que un repositorio del servicio provee
la direccin correcta cuando este es requerido.
Los clientes pueden cambiar dinmicamente el servicio a consumir.
Las instancias del servicio pueden ser creados y destruidos dinmicamente
segn el orden fueron cargados en el servidor donde est alojado el servicio.

3. SOA reduce los costos de IT

Un caso comn en muchas organizaciones es que tienen mltiples sistemas

ejecutando la misma actividad y manejar el mismo dato.

4. SOA permite comunicacin entre barias tecnologas

 Diferentes Edges pueden diferentes tecnologas de conexin (ejemplo: HTTP
para clientes de internet y TCP para clientes de intranet)
Varios mensajes de patrones pueden ser utilizados (ejemplo: one-way,
request-response y duplex)
Diferentes Edges pueden tener diferentes polticas de seguridad y tecnologas
de autenticacin
Los Edges permiten el balanceo de cargas entre los servicios

Nota: En WCF, los Edges son conocidos como endpoints, y la tecnologa para
implementar endpoints en WCF es expresado utilizando bindings y behaviors.

5. SOA soporta gran escalabilidad

Los servicios pueden ser duplicados, y como los servicios son independientes
y aislados, mltiples instancias de un servicio pueden coexistir
Los servicios pueden ser organizados en varias tecnologas para mejorar la
escalabilidad, esto significa que las nuevas instancias sern accesibles
Mensajes de una va (one-way) es un patrn de escalabilidad

6. SOA maneja interoperabilidad entre sistemas

Los servicios reciben y retornan dato (no objetos), de modo que ellos son
interoperables con otras tecnologas. Los objetos dependen especficamente
de La implementacin de una tecnologa, mientras que los datos no.
Los datos que un servicio enva y recibe tiene que ser en especfico y en un
mismo formato segn el estndar de codificacin (ejemplo: UTF-8)

7. SOA Provee confiabilidad en el Servicio

Aunque los servicios no pueden ser 100% confiables, existen algunas maneras
de mejorar la confiabilidad, una de ellas es tener un backup. Esto significa
proveer multiples instancias en los servidores fsicos. Donde los clientes o
routers pueden utilizar cualquiera de ellos en caso uno falle.
Los reintentos hasta llegar al lmite permitido para los reintentos
Persistencia de mensajes, cuando el servicio es invadido de muchos
requerimientos de sus clientes, el servicio rechaza estos requerimientos, de
esta manera el cliente esta enterado que el dato no llego a su destino

Escenarios y Estndares:

Existen varios escenarios para el desarrollo de las aplicaciones web. Por ejemplo un servicio
podra estar disponible para internet o para redes intranet. Adems de estos escenarios existen
varios estndares tanto para los servicios y clientes.

1. Estndares WS-* para integrar Web Services:

Los estndares WS-* es un grupo de especificaciones que define la manera en

que la informacin es intercambiada entre los servicios y clientes.
Los estndares WS-* estn basados en XML, cada estndar tiene sus propios
espacios de nombres y un conjunto de elementos y atributos.
 Los estndares WS-* son muy utilizado en SOAP para el intercambio de
mensajes adicionales que requiere el servicio como ser informacin sobre
seguridad y confiabilidad.
Los estndares WS-* son conocidos por muchas plataformas .Net, Java
permitiendo a sus servicios a ser interoperables con otras tecnologas.
OASIS nos provee muchos de estos estndares, los cuales se detallan en la
siguiente tabla:

Especificacin Presentado por Descripcin

Provee servicio web y direcciones de mensajes que

es un transporte neutral. Esta especificacin
WS-Addresing W3C
transmite au propia informacion de ruteo en lugar
de confiar en el ruteo de transporte.
Adiciona integridad y confiabilidad a los mensajes
SOAP. Tambin te permite encriptar y aadir una
WS-Security OASIS firma digital en los mensajes, permitiendo asi enviar
mensajes sensitivos como ser datos o identidades
de usuarios.
Define extensiones para WS-Secutiry para proveer
WS-Trust OASIS una infraestructura para solicitar una emisin de
fichas de seguridad
Define protocolos que permite una coordinacin de
aplicaciones distribuidas, por ejemplo, este
WS-Coordination OASIS
protocolo define como las transacciones son
coordinadas entre servicios.
Define el protocolo de descubrimiento utilizado
WS-Discovery OASIS
para localizar servicios.
Define protocolos que permiten mensajes a ser
WS-ReliableMessaging OASIS transmitidos confiablemente entre nodos utilizando
varias tcnicas de entrega de mensajes y seguras.
Web Service Description Language (WSDL), define
WSDL W3C un languaje basado en XML para la descripcin de
servicios, sus endpoints y sus operaciones.
Esta especificacin es una parte del estndar WS-
Security el cual define protocolos que permiten
WS-Federation OASIS diferentes mbitos de seguridad para permitir el
acceso a otros recursos utilizar una identidad
federada.
Define un modelo general que permite un servicio
describir las polticas de sus endpoints. Por
ejemplo, WS-Policy es utilizado en los documentos
WS-Policy W3C
WSDL para describir cuales de los protocolos WS-
Security utilizan y como ellos deberan aplicar a los
mensajes.
 Introduccin a WCF

Introduccin a WCF y su modelo de comunicacin

Contrato de Servicio y su implementacin

Alojar Servicios de WCF

Behaviours en WCF

Consumir Servicios WCF

Laboratorio: Crear servicio y su implementacion

WCF apareci para permitir la creacin de servicios interoperables para aplicaciones

distribuidas en el mundo.

Introduccin a WCF y su modelo de comunicacin de WCF:

1. Que es WCF

Es un framework de .Net para construir aplicaciones orientadas a servicios, el cual fue

introducido desde framework 3.0. WCF soporta diferentes patrones de comunicacin
sin afectar el cdigo y soporte de diferentes tecnologas cliente.

2. Objetivos de la implementacin de servicios

El modelo de WCF es extensible por la implementacin de canales, behaviors

y protocolos de comunicacin. El corazn de WCF esta implementado en el
espacio de nombres System.ServiceModel.
WCF est diseado para adherirse a los principios de SOA, siendo este
interoperable por diseo, soportando diferentes estndares WS-* y diferentes
protocolos de comunicacin y arquitecturas como ser SOAP and REST.

3. El modelo de comunicacin de WCF

La base de WCF son la Address, Binding y Contracts (ABC):

Address especifica la ubicacin del servicio (Dnde).

Binding indica la conectividad y los requerimientos para enviar y recibir el
servicio (Como).
Contracts que determina la funcionalidad del servicio (Que).
Contrato de servicio y su implementacin:

Como primer paso para empezar a construir un servicio WCF es necesario crear un contrato,
Un contrato un conjunto de operaciones y estructuras de datos que el servicio expone el cual
ser ledo por los clientes, donde los clientes necesitan saber qu es lo que hace el servicio.

Existe un ciclo de vida para el desarrollo de los servicios, esto es como sigue:

Contrato: Aqu se definen las operaciones que tendr el servicio y definir los
parmetros de cada operacin, como ser que tipo de dato es esperado desde el lado
del cliente y que tipo de respuesta o fallo de dato es retornado por el servicio.

Dentro de los contratos existen otras derivaciones de contratos:

- Contrato de Servicio: Las operaciones disponibles en el servicio, expresado en

interfaces en C#.

Ejemplo: Definicin de contrato de servicio ICalculatorService:

[ServiceContract]
public interface ICalculatorService
{
[OperationContract]
double Add(double n1, double n2);

[OperationContract]
double Sub(double n1, double n2);

[OperationContract]
double Mul(double n1, double n2);

[OperationContract]
double Div(double n1, double n2);
}

- Contrato de Dato: Es la representacin de los datos, representado en clases en

C#. Cuando un cliente accede a un servicio, los parmetros que el cliente necesita
enviar a las operaciones del servicio son serializados en formato XML y enviado al
servicio. Cuando el servicio retorna dato al cliente el dato tambin es serializado en
formato XML.

Ejemplo: Definicin de contrato de datos Person:

 [DataContract]
public class Person
{
[DataMember]
public int Age { get; set; }

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

public int Salary { get; set; }

}

- Atributos: Son utilizados para convertir entidades C# en declaraciones de WCF.

Ejemplo: Atributo de Contrato de Servicio: [ServiceContract]

Ejemplo: Atributo de Contrato de Dato: [DataContract]

Implementacin: Una vez definido las operaciones, estos se deben implementar la

funcionalidad que es expuesto a los clientes. Esta implementacin se la realiza en
clases en C# o VB.

Ejemplo: Implementacin de un servicio CalculatorService.cs:

public class CalculatorService : ICalculatorService

{
public double Add(double n1, double n2) { return n1 + n2; }
public double Sub(double n1, double n2) { return n1 - n2; }
public double Mul(double n1, double n2) { return n1 * n2; }
public double Div(double n1, double n2) { return n1 / n2; }
}

Alojar (Hosting): Despus de la implementacin del servicio, el servicio necesita tener

vida, como estar disponible para el mundo exterior. Existen varias maneras de alojar un
servicio (IIS, Self-Hosting, Windows Service), veremos ms adelante con ms detalle.

Prueba: Pasamos a la prueba una ves alojado el servicio, es necesario testear cada
unos de los contratos, para esto Visual Estudio 2010 posee varias herramientas, los
cuales se vern mas adelante.

Consumir por el cliente: Despues de la prueba, hacer conocer a los clientes que el
servicio esta listo para su consumo, el consumo depende la tecnologa de los clientes
(existe WCF client para .Net).

Alojar servicios de WCF:

Definir contratos en el servicio e implementarlos no es suficiente para tener corriendo el

servicio. Para que un servicio reciba mensajes de los clientes, el servicio necesita escuchar
cada requerimiento, y para escuchar requerimientos el servicio debe estar alojado y este le dir
como escuchar.

1. Responsabilidades del Hosting WCF:

 Un Host le da la vida a un servicio, por lo tanto un host necesita escuchar los
requerimientos de los clientes por algn tipo de puerto (por ejemplo para TCP:
8080), los hosts pueden escuchar requerimientos de los clientes por mas de un
puerto al mismo tiempo y en diferentes tipos de comunicacin, estas
combinaciones de comunicacin y puertos estn dentro de los endpoints.

La principal responsabilidad de un host es crear esos endpoints, escuchar

todos los requerimientos que recibe de los clientes, luego este se los pasa a la
operacin que le corresponda.

Que es un endpoint?

Un endpoint consta de 3 componentes Address, Binding y Contract (ABC).

Cada endpoint se refiere a un especfico contrato de servicio, de esta manera
el host sabe qu tipo de operaciones espera o recibe en el requerimiento.

Un endpoint tambin es definido para un especfico Binding. Un binding se

refiere al tipo de transporte que es utilizado para la comunicacin (ejemplo:
TCP, HTTP, Named Pipes). Por lo tanto un endpoint solo puede escuchar a un
tipo especfico de transporte.

Cada Endpoint tiene una direccin (Address), esta direccin identifica

nicamente a un endpoint de todos los endpoints que un host escucha, esta
direccin es en formato URL, y debe coincidir con el tipo de transporte utilizado
por el binding.

Ejemplo 1: Direccin asignada a un endpoint que hace uso del binding HTTP

http://localhost:8081/myService

Ejemplo 2: Direccin asignada a un endpoint que hace uso del binding TCP

net.tcp://localhost:9001/myService

2. Comunicacin Cliente-Servidor va mensajes:

Cuando un cliente necesita comunicarse con un servicio, este enva al servicio

un mensaje que contiene informacin a cerca de la operacin que requiere y el
dato requerido para la ejecucin de la operacin.

En respuesta al mensaje del cliente, el servicio enva un mensaje de retorno

con resultados de la ejecucin de la operacin, o en su caso un mensaje de
error en caso que la operacin haya fallado.
3. Mensajes son intercambiados entre endpoints:

Un endpoint es un punto de entrada al servicio, este recibe mensajes de un

canal de comunicacin, y este transfiere el mensaje a la implementacin del
servicio para su procesamiento.

Un servicio puede tener varios endpoints, cada endpoint escuchando diferentes

tipos de comunicacin (ejemplo: HTTP, HTTPS o TCP), cada endpoint tiene
diferente direccin para diferenciarse de las dems endpoints del servicio y de
otros servicios corriendo en la mismo servidor.

El cliente debe estar familiarizado con uno o mas endpoints del servicio para
poder comunicarse con el servicio. El cliente no necesita conocer todos los
endpoints del servicio, solamente necesita conocer aquellos que necesita.

4. Address, Binding y Contract:

Un endpoint de WCF es una abstraccin de que es lo que est expuesto, como est
expuesto y donde esta expuesto.

Qu. Cada endpoint esta relacionado a un contrato de servicio, todos los

requerimientos enviados al endpoint deben coincidir con alguno de los
contratos disponibles en el servicio, de otra manera este fallar.

Como. Cada endpoint puede utilizar diferentes tecnologas para escuchar a los
clientes (ejemplo: HTTP, HTTPS, TCP), tambin la forma codificar el mensaje
(ejemplo: texto plano o binario), tambin si el mensaje va encriptado o no. Toda
esta informacin esta almacenada en los Bindings.

Dnde. Los clientes necesitan saber una direccin especfica para poder
acceder a los endpoints. Cada endpoint tiene una direccin nica que identifica
al endpoint, ya que podra existir varios endpoints corriendo en el mismo
servidor.
 Un servicio podra tener muchos endpoints, cada uno con su propio Address,
Binding y Contract (ABC), por ejemplo:

- Dos endpoints para el mismo contrato, cada uno con diferentes

direcciones y Bindings.

- Tres endpoints, cada uno con diferente contrato y con diferentes

direcciones, pero todos ellos utilizando el mismo Binding

5. Responsabilidades del Binding:

Cuando un cliente necesita enviar un mensaje al servicio, este necesita manejar

muchas tecnologas de envo de mensajes, como ser que tipo de transferencia de
protocolo utilizar, el mensaje ser enviado a todos o no? El mensaje ser enviado en
formato XML, texto plano o binario? El mensaje necesita cabecera de seguridad?

Todas estas opciones pueden ser manejadas fcilmente por los Bindings WCF. Donde
los bindings encapsulan todos estos requerimientos para enviar l mensaje del punto A
al punto B.

El binding define que transporte utilizar para el envo de mensajes

El binding define como codificar los mensajes

El binding define que protocolos son requeridos, como ser seguridad y

sesiones

El binding define el canal de comunicacin y propiedades del mensaje, como

ser timeouts y tamao mximo de mensajes.

En WCF, la configuracin de los bindings pueden hacerse tanto en un archivo

de configuracin o en cdigo.

6. Mensaje Pipeline:

En WCF el mensaje que llega al servicio se mueve a travs de una pila de capas hasta
que este alcanza la implementacin del servicio. Cada una de estas capas de la pila
tiene un objetivo y propsito.
7. Elementos del Binding:

Los mensajes esta del binding estn construidos en base a tres elementos de los
bindings.

Transporte: Este elemento determina que tecnologa de transporte ser

utilizado para la comunicacin entre el cliente y el servicio (TCP, HTTP,,
Named Pipes, MSMQ)

Codificacin: Este elemento determina de que manera un mensaje es

codificado, usualmente el mensaje esta en un formato XML, pero cuando este
esta viajando por la red, este XML debe ser codificado.

Ejemplo: Segn la codificacin de texto, como se ser ASCII, UTF8 o UTF6 (por
defecto es el UTF8). El siguiente ejemplo muestra una respuesta XML
codificado en texto plano:

Protocolo: Este elemento es responsable para manejar una tarea especifica,

por ejemplo seguridad, transacciones y sesiones. Los mismos que se
describen en las especificaciones WS-Security y WS-ReliableMessaging.

8. Elementos del Binding como canales:

Existen tres tipos de elementos en los Bindings, El protocolo, codificacin y transporte.

En el canal de transporte es responsable de recibir y enviar mensajes desde y hacia el
cliente, este contiene los protocolos de Codificacin y Transporte.
 Por ejemplo, si los elementos del Binding son: HTTP Transporte, Codificacin Texto y
protocolos de Seguridad y Reliability, los canales que se utilizarn ser Canal de
Protocolos (elemento de Reliability), Canal de Protocolo (elemento de Seguridad) y
Canal de Transporte (HTTP y elemento de texto). Cuando el mensaje es enviado este
pasa por la pila de canal de transportes. El Binding que se selecciona para los
endpoints es una representacin de una composicin de canales.

9. Bindings pre-definidos y Bindings personalizados:

WCF ofrece varios Binding ya construidos, de los mas comunes podran implementarse
en su dominio, los cuales se mencionan a continuacin:

Basic Http Binding: HTTP Transporte con codificacin texto y no tiene

protocolos.
Ws Http Binding: Similar a Basic Http Binding, pero este contiene protocolo de
Seguridad.
Tcp Binding: TCP Transporte, codificacin binaria y algunos protocolos como
ser Seguridad.
Adadad: as

Estos Bindings ya pre-definidos por defecto podran ser personalizados segn las
necesidades de uno. Ejemplo, el HTTP Binding tiene configurado protocolo de
seguridad a none, pero se podra personalizar a transport, de manera asegurar que el
servicio corra sobre HTTPS en lugar de HTTP.

Asimismo, WCF tambin te permite construir su propio Binding desde cero, estos se
llaman Custom Bindings.

Nota: Si construye Custom Binding con HTTP y Binary encoding, esto es

recomendado para clientes .Net que no utilizan el transporte TCP, ya que este reducir
considerablemente los mensajes permitiendo una comunicacin mas eficiente entre el
cliente y servicio.

10. Bindings comnmente utilizados:

WCF ofrece bindings ya predefinidos listos para ser aplicados en escenarios bsicos y
no tan bsicos, los cuales se detallan a continuacin:

Binding Resumen

basicHttpBinding HTTP transport, text encoding

wsHttpBinding HTTP transport with WS-* support

netTcpBinding TCP transport, binary encoding, WS-* support

netMsmqBinding MSMQ transport, binary encoding, WS-* support

netNamedPipesBinding IPC transport, binary encoding, WS-* support

netTcpRelayBinding TCP transport with Windows Azure, WS-* support

netTcpContextBinding TCP transport with context correlation for Workflow Services

 Como elegir el Binding ms adecuado depende del requerimiento:

Tecnologas: Si el cliente no es .Net, entonces no es recomendable utilizar el

Binary Encoding, y debera ser utilizado el WS HTTP Binding.
Topologas de red: Si su red tiene un firewall limitado y solo permite la
comunicacin va HTTP, entonces es recomendable utilizar cualquiera de los
HTTP Bindings.
Performance: Si se tiene dos servicios corriendo en la misma mquina, y existe
comunicacin entre ellas, es preferible utilizar Named Pipes Binding, y que es
ms rpido que TCP y HTTP.
Requerimientos funcionales: Si el servicio necesita utilizar MSMQ, entonces es
recomendable utilizar el MSMQ Binding

11. Configuracin de Bindings en un archivo de configuracin:

Todos los bindings por defecto que provee WCF, ya estn pre-configurados. Pero esto
es posible personalizar aun mas segn el requerimiento del usuario. Una manera de
cambiar estas configuraciones es utilizando el archivo de configuracin (app.conf o
web.conf, este depende de la aplicacin que aloja al servicio):

Ejemplo: A continuacin se muestra como configurar el HTTP Binding (web.conf).

El elemento binding necesita ser colocado despus del elemento system.serviceModel

en el archivo de configuracin.

Donde NoCookies es el nombre de la definicin del binding y es referenciado al

servicio dentro del elemento services.
 Nota: Despus de modificar el archivo de configuracin en el servicio, es necesario
replicar este cambio en los clientes, la forma ce hacerlo se ver mas adelante.

12. Configuracin de Bindings en cdigo:

Adems de configurar los bindings en un archivo de configuracin, tambin es posible

hacerlo en cdigo, todos los bindings predefinidos son expuestos en clases de .Net.

Ejemplo: Como configurar un basic HTTP Binding.

Estas clases estn disponibles en el espacio de nombres System.ServiceModel, pero

en algunos casos especiales, por ejemplo NetTcpRelayBinding puede ser encontrado
en el espacio de nombres Microsoft.ServiceBus.

13. Crear un Binding personalizado:

Si los bindings estndares provistos por WCF se ajustan a sus necesidades, y si

configurando en el archivo de configuracin o cdigo tampoco cubre sus necesidades.
Entonces, es posible crear sus propios Bindings de acuerdo a sus necesidades ya sea
a travs de un archivo de configuracin o cdigo:

A travs de un archivo de configuracin:

 A travs de cdigo:

14. Definir un endpoint:

Para alojar (host) un servicio es necesario declarar por lo menos un Endpoint, si no

existe ningn endpoint los cliente no podrn consumir el servicio. Un endpoint se puede
declarar a travs de un archivo de configuracin o cdigo.

Declaracin de un endpoint a travs de un archivo de configuracin (ejemplo:

web.conf)

Declaracin de un endpoint a travs de cdigo:

Si desea aadir una configuracin adicional al binding, se puede utilizar el

atributo bindingConfiguration, como se ve en el siguiente ejemplo:
 Cuando se utiliza ms de un endpoint para su servicio y alguno de ellos utilizan
el mismo mecanismo de transporte, entonces es posible utilizar direcciones
relativas en lugar de direcciones absolutas, ejemplo:

Donde las direcciones de los endpoints se muestran como sigue:

http://localhost:8080/simple
http://localhost:8080/complex

Nota: Visual Estudio 2010 provee una herramienta grafica que nos permite
crear y editar los archivos de configuracin (web.conf o app.conf), esta
herramienta esta ubicado en Tools WCF Service Configuration Editor.

15. Crear un Servicio Hosting (Alojamiento del servicio):

Para que un servicio este disponible para los clientes a travs de su configuracin de
sus endpoints, es necesario que este alojado en alguna aplicacin. Un servicio podra
ser alojado en algn ambiente donde exista un proceso de Windows.

Aplicaciones con interfaz, como ser aplicaciones de consola, aplicaciones de

formulario de Windows (ejemplo WPF). Es decir, que mientras la aplicacin
 est activa el servicio estar disponible, pero cuando este se cierre o termine,
el servicio tambin se cierra.

Windows Service (NT Services), Un servicio puede ser alojado dentro de un

servicio de Windows, de esta manera el servicio estar disponible cuando el
Sistema Operativo este activo y estar abajo cuando el Sistema Operativo ya
no est activo.

Hosts comerciales, como ser IIS, WAS o Windows Server AppFabric, este tipo
especial de hosting adems de alojar, tambin toma en cuenta el manejo de
algunos problemas que podra tener el servicio, como ser registro, rendimiento
y gestin de la salud del mismo servicio.

Cuando el servicio no est alojado ya sea en IIS o WAS, es necesario cargar el

servicio por uno mismo, y abrir este utilizando el mtodo Open(), ya que tanto el IIS
y WAS ya realiza estas actividades automticamente. La clase base para
administrar los hosts WCF es la clase ServiceHost que hereda de la clase
abstracta ServiceHostBase.

El siguiente ejemplo muestra como instanciar una instancia de ServiceHost:

El parmetro ComplexCalc que se le pasa al constructor es el tipo del servicio que

se quiere alojar. La informacin acerca del endpoint es extrada automticamente
del archivo de configuracin (web.conf o app.conf, dependiendo de la aplicacin)

16. Abrir un Servicio Hosting (Abrir servicio alojado):

Para alojar un servicio es obligatorio instanciar un objeto ServiceHost, si tiene mas de

un servicio es necesario tener diferentes instancias de ServiceHost para cada servicio.

Como instanciar un servicio y abrir el servicio:

Para adicionar endpoints, a travs de cdigo utilizar el mtodo

AddServiceEndpoint:

Nota: Si no se especifica ningn endpoint ya sea por cdigo o en archivo de

configuracin no ser posible abrir el servicio.
Behaviours en WCF:

WCF se encarga de muchas actividades que ocurren por detrs cuando se implementan
servicios, por ejemplo:

Cuntos requerimientos pueden ser procesados simultneamente?

Qu certificado debera ser utilizado para ser identificado en canales seguros?

El servicio se ejecutar como multi-threaded o single-threaded?

WCF se refiere a todos tems como capa del modelo de servicio, esta capa de modelo se
servicio est compuesto de diferentes componentes llamados dispatchers y cada uno de estos
dispatchers es responsable de una tarea especfica y cada uno de ellas tiene una configuracin
por defecto para el cual opera.

En momentos es necesario cambiar las configuraciones por defecto de un dispatcher, y esto se

hace a travs de los behaviours.

1. Dispatchers y la pila de canales:

Anteriormente definimos que un mensaje es enviado a travs de la pila de varios

canales, donde el canal de transporte es el nico responsable para leer y transmisin
del mensaje, luego pasando al canal de protocolos. El canal de protocolos es el nico
responsable de revisar el contenido del mensaje para identificar los bindings
(seguridad, transaccin y confiabilidad).

Una vez que el mensaje alcanza la cima de la pila de protocolos y antes de que este
sea recibido por la implementacin del servicio, existen otras cuestiones relacionados a
la implementacin del servicio necesitan ser tomados en cuenta, el dato del mensaje
necesita ser deserializado y el servicio necesita ser implementado y una apropiada
operacin de servicio necesita ser invocado.

En WCF, para permitir que un mensaje obtenga la funcionalidad de la operacin del

servicio, el mensaje debe ser procesado por todos los dispatchers que son
relacionados al servicio. Los dispatchers WCF son responsables de varios aspectos del
servicio, los cuales se resume los ms importantes a continuacin:

Creacin de instancias: La decisin de cual instancia ser utilizado para

invocar al servicio.

Concurrencia: Permite el control si el servicio correr en modo single-threaded

o modo multi-threaded, es necesario seleccionar modo apropiado para la
implementacin del servicio.

Throttling: Permite decidir cuantas llamadas concurrentes o instancias pueden

ser servidos por el servicio en un determinado tiempo.

Seguridad: Permite decidir qu mecanismos de autenticacin utilizar.

Serializacin: Establece la manera en que los mensajes con serializados y

deserializados.

Metadata: Define como el metadata del servicio WSDL (Web Services

Decription Language) es expuesto.
2. Utilizar Behaviours para configurar dispatchers WCF (Cdigo y Archivo):

Sabemos que el mecanismo para configurar los dispatchers se llama behaviours. WCF
ofrece un rango de behaviours que le permite controlar diferentes aspectos del servicio.
Asimismo, es posible configurar algunos behaviours aplicando atributos en el servicio y
configurar otros a travs de archivos de configuracin:

Configurar un behaviour a travs de cdigo, con el uso de atributos, en el siguiente

ejemplo demuestra como configurar el modo de instancia en el servicio.

Configurar un behaviour utilizando un archivo de configuracin (web.conf o app.conf),

por debajo del elemento Behaviours. En el siguiente ejemplo se muestra como
configurar el behaviour debug, incluyendo la informacin sobre un-handled excepcin
que ser retornado hacia los clientes.

Cuando un behaviour no tiene nombre en el atributo name en el elemento behaviour,

este afectar a todos los servicios que estn y sern alojados.

Tomar en cuenta que existen behaviours orientados a desarrollo (Instancias y

concurrencias) y Behaviors orientados al hosting (Throttling y metadata), ver un
ejemplo orientado hosting configurando el behaviour medatada.

Nota: Un servicio solamente puede tener un archivo de configuracin, si existen

situaciones donde se necesitan diferentes grupos de behaviours, considerar construir
un grupo especial de behaviours para ese servicio especifico.
Consumir servicios WCF:

WCF no solamente te ayuda a construir servicios, sino tambin a consumir servicios. Si un

servicio fue construido en otra tecnologa (ejemplo Java) bajo el estndar SOAP, es posible
consumir este servicio utilizando WCF desde el lado del cliente.

WCF ofrece diferentes maneras para consumir servicios utilizando el patrn de proxy.

1. El patrn Proxy:

Este proxy refleja el contrato del servicio implementando la misma interface que el
servicio expone, pero esta vez en el lado del cliente. Adems de ejecutar algunos
actividades extras e internos para poder comunicarse con el servicio.

Los pasos requeridos para comunicarse con el servicio son:

Serializar el requerimiento a un objeto mensaje

Abrir el canal al servicio, y enviar el mensaje al servicio, segn los
requerimientos de transporte y otras configuraciones de los bindings, por
ejemplo seguridad.
Esperar la respuesta del servicio al requerimiento realizado por el cliente y el
cliente reenva de nuevo una respuesta de confirmacin hacia el servicio.
Deserializar el mensaje y retornar el valor en la llamada.

2. Adicionando una referencia del servicio:

Si desea utilizar el patrn proxy para consumir un servicio, entonces es necesario

construir un proxy, es decir implementar una clase que implemente los contratos del
servicio, el cual ser responsable para todas las transformaciones con el servicio.
 WCF puede construir esta clase utilizando la herramienta Add Service Reference.
Esta herramienta lee los documentos WSDL, extrae los contratos del servicio y crea
proxys que coincidan con los contratos.

Nota: Para poder crear la referencia proxy el servicio debe estar arriba y en un host, si
el servicio no esta disponible, entonces no ser posible obtener su metadato y el proxy
no ser creado.

Nota: Si se quiere construir nuestro propio servicio, entonces verificar que el servicio
exponga el documento WSDL, para exponer este documento el servicio debe tener
esta bandera httpGetEnabled configurado a true en el behaviour serviceMetadata.

3. Contenido de la referencia del servicio:

Una vez creada la referencia de proxy a travs de la herramienta Add Service

Reference, WCF crear los contratos adecuados al servicio, un proxy por contrato.

Cada Proxy que se haya generado ser llamado segn el nombre de contrato y
aadiendo el sufijo Client, por ejemplo CalcClient. Ahora si el servicio expone algn
contrato de dato, WCF tambin generar clases para cada contrato, cada clase ser
llamada segn el nombre del contrato de dato, sin ningn sufijo o prefijo.

WCF tambin generar un archivo de configuracin del cliente que contiene la lista de
todos los endpoints del servicio, de modo que se pueda seleccionar fcilmente el
conjunto de endpoints que necesite el cliente, este archivo se ver como sigue:
 Despues de construir los proxy clases y contratos de datos la herramienta Add Service
References tambin adiciona los espacios de nombres System.ServiceModel y
System.Runtime.Serialization, los cuales son requeridos para el desarrollo de WCF
desde el lado de cliente.

Utilizar el proxy: Una vez que el proxy fue creado, este esta listo para su uso, el
siguiente ejemplo muestra como utilizar la clase proxy CalcClient.

Nota: Es aconsejable cerrar la clase proxy despus de haber hecho su uso.

Si se quiere a acceder a un servicio donde existen varios endpoints listados en

el archivo de configuracin, entonces es necesario especificar cual endpoint
desea que el proxy utilice. (El nombre del endpoint puede ser encontrado en el
archivo de configuracin dentro del elemento endpoint).

Actualizar el proxy: Si en el lado del servicio el contrato tiene cambios, y se

quiere que estos nuevos estados de los contratos de servicio y dato sean
reflejados en el cliente, no es necesario borrar toda la referencia y adicionar la
referencia de nuevo. La herramienta Add Service Reference tiene soporte de
actualizar llamado Update Service Reference.

4. Demostracin:

Crear un servicio WCF en Visual Studio 2010.

o Contrato de Servicio
o Contrato de Dato

Alojar el servicio.
o Windows service

Crear un cliente WCF en Visual Studio 2010.

o Crear el proxy con la herramienta Add Service Reference

Actualizar los contratos en el servicio

o Actualizar el proxy con la herramienta Add Service Reference

5. Construir un Proxy utilizando un Channel Factory:

Algunas veces es preferible no utilizar la generacin de cdigo automatico, por ejemplo

cuando el cliente y servicio de desarrollan juntos. En estos casos WCF ofrece una
diferente manera de crear proxy, utilizando el tipo ChannelFactory<T>. El
 ChannelFactory<T> crea canales de objetos (proxys), donde T es la interface del
contrato de servicio.

Para trabajar con ChannelFactory<T>, el cliente necesita tener una referencia del
contrato de servicio y contrato de dato y conocer que endpoints tiene el servicio.

Nota: Utilizar el mismo contrato ayudar a mantener una buena sincronizacin entre el
cliente y servicio, pero cuando existen cambios en el lado del servicio, cada cambio
deber ser actualizado manualmente en el lado del cliente.

El siguiente ejemplo demuestra como utilizar el cannel factory para instanciar

un canal.

Tambien es posible crear un objeto de ChannelFactory<T> y utilizar esto para

crear muchos canales.

Si no se quiere especificar los endpoints por cdigo, se puede hacer esto a

travs del archivo de configuracin refirindose al nombre del endpoint.

Nota: Tambien puede utilizar la herramienta WCF Service Configuration Editor

(SvcConfigEditor.exe), para editar las configuracin en el lado del cliente.

6. Utilizar el Channel Factory correctamente:

Cuando se utiliza el tipo ChannelFactory<T> para construir un proxy, es necesario

proveer toda la informacin necesaria a cerca del contrato, el binding y la direccin del
servicio, ya sea a travs de cdigo o en un archivo de configuracin. Utilizando el
ICommunicationObject, se puede manejar eventos como ser abrir, abrir y falla, como
se demuestra en el siguiente ejemplo.
7. Demostracin:

Construir un proxy instanciando un canal a travs de cdigo.

Construir un proxy instanciando varios canales, leyendo endpoints desde un
archivo de configuracin.
Implementar los eventos que provee la interface ICommunicationObject.
 Ayuda: Herramientas de prueba

Para pruebas del servicio:

WcfTestClient.exe
http://localhost:8000/CalculatorService/metadataEndpoint/mex
Para crear referencias en el cliente:
svcutil.exe http://localhost:8000/CalculatorService/
metadataEndpoint/mex /directory:FolderName

svcutil.exe http://localhost:8000/CustomersService?wsdl
/directory:C:\TestFolder
Otros:
WcfSvcHost.exe , SvcTraceViewer.exe y SvcConfigEditor.exe
Mas referencias en:
http://msdn.microsoft.com/es-es/library/aa347733.aspx
 Lab: Ciclo de vida de
desarrollo de Servicios
Tareas:

1. Definir los contratos de servicio y dato para el servicio

2. Implementar el servicio y verificar el estado del servicio
3. Consumir el servicio

Credenciales:
Usuario: Administrator
Contrasea: Pa$$w0rd

Tiempo estimado: 60 mins

Despues de este laboratorio, usted ser capaz de:

Definir contratos de servicio y dato

Implementar un servicio
Alojar un servicio IIS 7.0
Crear un proxy utilizando la herramienta Add Reference Service
Actualizar el proxy utilizando la herramienta Update Reference Service

Ejercicio 1: Definir los contratos de servicio y dato para el servicio:

Tarea 1: Armar la base inicial para el servicio en Visual Studio 2010

1. Ingresar a su mquina del laboratorio.
2. Abrir el folder C:\WCF\Modulo01\Lab01\CalculatorService\ y abrir la solucin
Lab_CalculatorService.sln
3. Aadir nuevo proyecto: File Add New Proyect
4. En la caja de texto Name escribir CalculatorService, y en Location escribir
C:\WCF\Modulo01\Lab01\CalculatorService
5. Borrar los estos dos archivos IService1.cs y Service1.cs
6. Seleccionar el proyecto CalculatorService Add New Item
7. En el dialogo desplegado, seleccionar el tem WCF Service.
8. En Name escribir CalculatorService.svc y presionar el botn Add

9. Hasta ahora tenemos la base de las clases, y se mostrar asi.

10. Seleccionar del men de Visual Studio Build Rebuild Solution, y ningn
error deber listarse en la ventana de errores
 Tarea 2: Crear el contrato de servicio
1. Seleccionar y editar el archivo ICalculatorService.cs
2. Excribir cuatro contratos

[ServiceContract]
public interface ICalculatorService
{
[OperationContract]
double Add(double n1, double n2);

[OperationContract]
double Sub(double n1, double n2);

[OperationContract]
double Mul(double n1, double n2);

[OperationContract]
double Div(double n1, double n2);
}

3. El cdigo completo en el archivo ICalculatorService.cs se ver como sigue:

4. Seleccionar del men de Visual Studio Build Rebuild Solution, existen

algunos errores relacionados a la implementacin .

Tarea 3: Crear el contrato de dato

1. Seleccionar y editar el archivo ICalculatorService.cs
2. Excribir un contrato de dato, como se ve a continuacin:

[DataContract]
public class OtherOperation
{
[DataMember]
public int FisrtOperation { get; set; }

[DataMember]
public int SecondOperation { get; set; }
}
 3. El cdigo completo en el archivo ICalculatorService.cs se ver como sigue

4. Seleccionar del men de Visual Studio Build Rebuild Solution, existen

algunos errores relacionados a la implementacin .

Resultados: Despues de estos ejercicios realiazados, usted ser capaz de crear

contratos de servicio y contrato de dato.

Ejercicio 2: Implementar el servicio y verificar el estado del servicio:

Tarea 1: Implementar los contratos de servicios

1. Abrir y editar el archivo CalculatorService.svc
2. Borrar el mtodo que existe por defecto, cuando se crearon los archivos

public void DoWork()

{
}

3. Implementar la interface que se ha creado en el ejercicio 1.

 4. Luego de implementar la interface el cdigo en la clase CalculatorService es:

public class CalculatorService : ICalculatorService

{
public double Add(double n1, double n2) { throw new NotImplementedException(); }

public double Sub(double n1, double n2) { throw new NotImplementedException(); }

public double Mul(double n1, double n2) { throw new NotImplementedException(); }

public double Div(double n1, double n2) { throw new NotImplementedException(); }

public OtherOperation Op1() { throw new NotImplementedException(); }

}

5. Borrar esta sentencia throw new NotImplementedException(); de los mtodos

anteriores e implementar funcionalidad de las operaciones correspondientes:

namespace CalculatorService
{
public class CalculatorService : ICalculatorService
{
public double Add(double n1, double n2) { return n1 + n2; }
public double Sub(double n1, double n2) { return n1 - n2; }
public double Mul(double n1, double n2) { return n1 * n2; }
public double Div(double n1, double n2) { return n1 / n2; }

public OtherOperation NewOperation()

{
OtherOperation opt = new OtherOperation();
opt.FisrtOperation = 1000;
opt.SecondOperation = 2000;
return opt;
}
}
}

6. Seleccionar del men de Visual Studio Build Rebuild Solution.

Tarea 2: Verificar que el servicio esta disponible para ser consumido

1. Seleccionar el archivo CalculatorService.svc
2. Click derecho y seleccionar la opcin View in Browser
3. El servicio is abierto en el browser (con otro puerto en su browser)
4. Si le sali el anterior resultado, el servicio esta listo para ser consumido.
5. Tambien es posible utilizar la herramienta de Microsoft (WcfTestClient.exe)
para ver si el servicio esta disponible para su consumo, (en el ejemplo anterior
http://localhost:5848/CalculatorService.svc)

6. Si el servicio puede ser consumido por el cliente, el siguiete resultado deber

desplegarse con todos los Contratos de servicio y datos correspondientes.
 7. Los contratos El servicio esta listo para ser consumido

Resultados: Despus de este ejercicio, usted ser capaz de implementar un contrato

de servicio y sus tipos de datos, probar si el servicio esta listo para ser consumido y
finalmente si un cliente escucha al servicio.

Ejercicio 3: Consumir el servicio:

Tarea 1: Crear una aplicacin cliente (Console Application).

1. Aadir nuevo proyecto File Add New Proyect:

2. Seleccionar del men de Visual Studio Build Rebuild Solution.

Tarea 2: Crear la referencia del proxy (Add Service Reference).

1. Verificar que el servicio esta disponible y corriendo en el broswer

2. Seleccionar el proyecto ClientConsole

3. Click derecho y seleccionar la opcin Add Service Reference
4. Copiar la URL del browser donde el servico esta activo y pegar en el dialogo de
Add Service Reference.
5. En la caja de texto Namespace, escribir un nombre intuitivo para el espacio de
nombres de la clase proxy.

Ejemplo: en nuestro lab la URL es: http://localhost:5848/CalculatorService.svc

6. Presionar el botn Go.

7. Todos los contratos son listados.

8. Presionar el botn OK. y la referencia del servicio (clase proxy) es creado,
aadindose varios nuevos items y referencias.
 9. Seleccionar del men de Visual Studio Build Rebuild Solution.

Tarea 3: Configurar el proyecto que se ejecutar primero en Visual Studio 2010.

1. Seleccionar el proyecto ClientConsole.
2. Click derecho y seleccionar la opcin Set as StartUp Project.

Tarea 4: Implementar y verificar la funcionalidad del servicio en el cliente.

1. Abrir y editar el archivo Program.cs
2. Dentro del mtodo Main, codifcar el siguiente cdigo.
 double n1 = 10, n2 = 20;

CalculatorService.CalculatorServiceClient proxy;
proxy = new CalculatorService.CalculatorServiceClient();
//proxy.Op1();

// Verify Data Contracts

CalculatorService.OtherOperation OpClient;
OpClient = new CalculatorService.OtherOperation();
OpClient.FisrtOperation = 5000;
OpClient.FisrtOperation = 1000;

// Review functionalities
Console.WriteLine("Add = {0}", proxy.Add(n1, n2));
Console.WriteLine("Sub = {0}", proxy.Sub(n1, n2));
Console.WriteLine("Mul = {0}", proxy.Mul(n1, n2));
Console.WriteLine("Div = {0}", proxy.Div(n1, n2));
Console.WriteLine();
Console.WriteLine("First Operation = {0}", OpClient.FisrtOperation);
Console.WriteLine("Fisrt Operation = {0}", OpClient.FisrtOperation);
Console.WriteLine();
Console.WriteLine("Press any key in order to finish the application");
Console.ReadKey();

3. Seleccionar del men de Visual Studio Build Rebuild Solution.

4. Presionar F5. y se tiene los resultados esperados:

Tarea 5: Actualizar la referencia del proxy (Update Service Reference).

1. Seleccionar el proyecto CalculatorService
2. Editar el archivo ICalculatorService.cs
3. En la clase OtherOperation aadir la siguiente lnea de cdigo (en amarillo)
antes de la sentencia return.

4. Compilar el proyecto CalculatorService, sin errores.

5. Seleccionar del men de Visual Studio Build Rebuild Solution.

Nota: Si no existen errores, proseguir con el siguiente paso

6. Seleccionar el proyecto ClientConsole Service References

CalculatorService Update Service Reference.
 7. Las referencias se actualizan en el proyecto del cliente.

8. Seleccionar del men de Visual Studio Build Rebuild Solution.

9. Presionar F5 y verificar los resultados de la actualizacin:

10. Adicionar el siguiente fragmento de XML en el elemento Behaviors

Resultados: Despus de este ejercicio, usted habr comprendido los siguientes

puntos:

Crear un servicio
Hosting un servicio en una aplicacin web
Consumir un servicio utilizando la herramienta de Microsoft Add Service
Reference
Actualizar el servicio utilizando la herramienta de Microsoft Update Service
Reference
Verificar las que las actualizaciones en cdigo en el lado de cliente.