Taller de Sistemas de Información 1

Clase 5 WCF

Que es WCF?
Windows Communication Foundation (WCF) es un SDK para el desarrollo y puesta en producción de servicios en plataforma Windows  WCF provee un runtime para los servicios, permitiendo exponer tipos CLR como servicios, y consumir otros servicios como tipos CLR

INCO - Facultad de Ingeniería – Montevideo, Uruguay

2

Que es WCF?

Aunque podemos construir servicios sin WCF, en la practica construirlos utilizando WCF es significativamente mas sencillo

INCO - Facultad de Ingeniería – Montevideo, Uruguay

3

Uruguay 4 . marshalling. unmarshalling. interacción entre servicios. INCO . protocolos. etc.Que es WCF?  WCF es la implementación de Microsoft de un set de estándares de la industria.Facultad de Ingeniería – Montevideo. conversión de tipos. que definen entre otras cosas.

comparado con plataformas similares INCO .Que es WCF?  Una de las ventajas que provee WCF.Facultad de Ingeniería – Montevideo. Uruguay 5 . es que simplifica de sobremanera el trabajo con servicios.

Que es WCF?  La mayoría de la funcionalidad de WCF esta incluida en un solo assembly.dll en el namespace System.Facultad de Ingeniería – Montevideo.ServiceModel INCO . Uruguay 6 .ServiceModel. System.

Que es WCF? WCF es parte de . y además requiere . como ser Windows Vista (cliente y servidor).0.NET 2. Windows Server 2003 SP1. Uruguay 7 .0  Solo puede ejecutar en sistemas operativos que los soporten. Windows XP SP2.Facultad de Ingeniería – Montevideo. etc.  INCO .NET 3.

Facultad de Ingeniería – Montevideo.Servicios Un servicio es una unidad de funcionalidad. Uruguay 8 . a objetos a componentes a servicios  INCO . es el próximo paso evolutivo en el pasaje de funciones. expuesta al mundo  En ese aspecto.

Uruguay 9 .Facultad de Ingeniería – Montevideo.Servicios  Arquitectura general… INCO .

Computación distribuida La esencia de este tipo de soluciones. Uruguay 10 . esta en que los proveedores de servicios y los consumidores de servicios. se encuentran en locaciones físicas diferentes  Generalmente la comunicación es resuelta a través de una red  INCO .Facultad de Ingeniería – Montevideo.

Uruguay 11 .Corba INCO .Facultad de Ingeniería – Montevideo.

.Facultad de Ingeniería – Montevideo. Uruguay 12 .NET Remoting INCO .

Uruguay 13 .Facultad de Ingeniería – Montevideo. es un set abstracto de principios y buenas practicas.Servicios  La orientación a servicios. para la construcción de aplicaciones orientadas a servicios INCO .

Facultad de Ingeniería – Montevideo. agrega servicios en una unidad (aplicación) lógica  Es similar a la forma en que un componente o una aplicación orientada a objetos.Servicios Una aplicación orientada a servicios (SOA). combina objetos  INCO . Uruguay 14 .

Facultad de Ingeniería – Montevideo.Servicios INCO . Uruguay 15 .

Servicios Un servicio puede ser local o remoto  Puede estar desarrollado por una o múltiples partes. utilizando una o múltiples tecnologías  Inclusive puede ejecutar en diferentes líneas de tiempo  INCO .Facultad de Ingeniería – Montevideo. Uruguay 16 .

entre servicios. Uruguay 17 . vamos a encontrar conceptos como o o o o o Lenguajes Tecnologías Plataformas Versiones Frameworks  Sin embargo.Servicios  Dentro de un servicio.Facultad de Ingeniería – Montevideo. solo los mecanismos de comunicación establecidos son los que valen INCO .

Servicios
El cliente de un servicio es simplemente la entidad que consume su funcionalidad  El cliente puede ser casi cualquier cosa .NET o no .NET

o

Un Windows form, una pagina ASP.NET, otro servicio, etc.

INCO - Facultad de Ingeniería – Montevideo, Uruguay

18

Servicios
Los servicios WCF pueden comunicarse sobre una variedad de protocolos, no solo HTTP  Los clientes WCF pueden interoperar con servicios WCF, y los servicios WCF pueden interactuar con clientes no WCF

INCO - Facultad de Ingeniería – Montevideo, Uruguay

19

Servicios
Como la implementación de un servicio es opaca al mundo exterior, un servicio WCF expone generalmente metadatos  Estos metadatos describen la funcionalidad disponible, así como posibles formas de comunicarse con el servicio

INCO - Facultad de Ingeniería – Montevideo, Uruguay

20

Servicios  Los metadatos son publicados utilizando un formato predefinido. utilizando WSDL sobre HTTP-GET. o algún otro estándar de la industria para intercambio de metadatos INCO . neutral tecnológicamente. por ejemplo. Uruguay 21 .Facultad de Ingeniería – Montevideo.

Facultad de Ingeniería – Montevideo. solo que este puede importar la información y consumirla como clases CLR  INCO . creando los tipos de datos necesarios para poder interactuar con el servicio  Lo mismo ocurre con un cliente WCF. Uruguay 22 . puede importar los datos en su ambiente nativo.Servicios Un cliente no WCF.

el cliente nunca interactuara con el servicio directamente. así como otros métodos administrativos  INCO . Uruguay 23 .Execution Boundaries Con WCF. el cual se encarga de forwardear la llamada al servicio  El proxy expone las mismas operaciones que el servicio. aun en casos locales. o ejecución in-memory  En vez de esto.Facultad de Ingeniería – Montevideo. el cliente siempre habla con un proxy.

Uruguay 24 .Facultad de Ingeniería – Montevideo.Execution Boundaries Ejecución en la misma maquina INCO .

Facultad de Ingeniería – Montevideo.Execution Boundaries Ejecución en múltiples maquinas INCO . Uruguay 25 .

Transparencia locacional  En el pasado.Facultad de Ingeniería – Montevideo. Uruguay 26 . sin importar si el objeto es remoto o local INCO . Remoting) aspiraban a proveer el mismo ambiente de programación para el cliente. las anteriores tecnologías para computación distribuida (DCOM.

Uruguay 27 . el cliente utilizaba una referencia directa al objeto  Cuando tenia que interactuar con un objeto remoto. utilizaba un proxy  INCO .Facultad de Ingeniería – Montevideo.Transparencia locacional En el caso de una llamada local.

Facultad de Ingeniería – Montevideo. Uruguay 28 . es que la comunicación remota es mucho mas compleja que la local  Tratar de llevar el modelo remoto en local.Transparencia locacional El problema con este enfoque. presentando problemas tanto de desarrollo e implementación  INCO . no es sencillo.

Uruguay 29 . todo porque tratamos de simular un modelo local INCO .Transparencia locacional  Tenemos aspectos complejos. como o o o o o Ciclo de vida de los objetos Confiabilidad Manejo del estado Escalabilidad Seguridad  Todo esto es mucho mas complejo.Facultad de Ingeniería – Montevideo.

Facultad de Ingeniería – Montevideo. toma el modelo de programación remota. y lo lleva al caso local  Siempre debemos comunicarnos a través de un proxy  INCO . sin importar donde este localizado el servicio  Sin embargo.Transparencia locacional WCF trata de proveerle al cliente el mismo modelo de programación. Uruguay 30 . el enfoque de WCF es el opuesto.

Facultad de Ingeniería – Montevideo. Uruguay 31 .Transparencia locacional INCO .

Uruguay 32 .Transparencia locacional INCO .Facultad de Ingeniería – Montevideo.

Facultad de Ingeniería – Montevideo. todo servicio esta asociado con una dirección única  La dirección provee dos elementos importantes  o o La localización del servicio El protocolo de transporte (transport schema) usado para comunicarnos con el servicio INCO . Uruguay 33 .Direcciones En WCF.

Uruguay 34 .Transport schemas  WCF soporta los siguientes esquemas o o o o o HTTP TCP Peer network IPC (Inter-Process Communication sobre named pipes) MSMQ INCO .Facultad de Ingeniería – Montevideo.

Uruguay 35 .Facultad de Ingeniería – Montevideo.Direcciones  Las direcciones siempre tienen el formato: o [base address]/[optional URI]  La dirección base siempre esta en este formato: o [transport]://[machine or domain][:optional port] INCO .

Facultad de Ingeniería – Montevideo.tcp://localhost:8002/MyService  net.msmq://localhost/private/MyService  net.pipe://localhost/MyPipe  net.msmq://localhost/MyService  INCO .Direcciones http://localhost:8001  http://localhost:8001/MyService  net. Uruguay 36 .

Facultad de Ingeniería – Montevideo. Uruguay 37 .Contratos En WCF. todos los servicios exponen contratos  Un contrato es una forma estándar de describir lo que hace el servicio  Esta descripción es neutral a nivel de plataforma  INCO .

Facultad de Ingeniería – Montevideo. Uruguay 38 .Contratos  WCF define cuatro tipos de contrato o o o o Service contracts Data contracts Fault contracts Message contracts INCO .

Service Contract [ServiceContract] interface IMyContract { [OperationContract] string MyMethod(string text). } public string MyOtherMethod(string text) { return "Cannot call this method over WCF". } class MyService : IMyContract { public string MyMethod(string text) { return "Hello " + text. Uruguay 39 . string MyOtherMethod(string text). } } INCO .Facultad de Ingeniería – Montevideo.

Facultad de Ingeniería – Montevideo.Service Contract El atributo ServiceContract mapea una interfaz o una clase CLR a un contrato independiente de la tecnología  En este proceso de exposición. no interesan aspectos como la visibilidad de la clase o la interfaz  INCO . Uruguay 40 .

Facultad de Ingeniería – Montevideo. a menos que lo especifiquemos explícitamente  Debemos hacerlo utilizando el atributo OperationContract. Uruguay 41 .Service Contract En conjunto con lo anterior. ningún miembro de la clase o interfaz será parte del contrato. el cual podemos aplicar a métodos  INCO .

Uruguay 42 . } public string MyOtherMethod(string text) { return "Cannot call this method over WCF".Facultad de Ingeniería – Montevideo. } } INCO .Operation Contract [ServiceContract] interface IMyContract { [OperationContract] string MyMethod(string text). } class MyService : IMyContract { public string MyMethod(string text) { return "Hello " + text. string MyOtherMethod(string text).

Data Contract Permite definir los elementos intercambiados en los diferentes contratos de los servicios  Es una forma de normalizar la serialización de la información a través de la conexión  INCO . Uruguay 43 .Facultad de Ingeniería – Montevideo.

.        //.Data Contract [DataContract] public class User {       [DataMember]       public string Name. }  INCO . Uruguay 44 .etc..      [DataMember]        public string Address.Facultad de Ingeniería – Montevideo.

Uruguay 45 .Facultad de Ingeniería – Montevideo.Fault Contract Permite definir los diferentes tipos de errores que puedo recibir a la hora de interactuar con un servicio  Es una forma independiente de la tecnología de definir las “excepciones” que una operación puede provocar  INCO .

Uruguay 46 . return a/b.Fault Contract [ServiceContract] public class CalculatorService { [OperationContract] int Divide(int a. int b) { if (b==0) throw new Exception(“Division by zero!”). } } INCO .Facultad de Ingeniería – Montevideo.

} set { problemType = value. [DataMember] public string Operation { get { return operation. Uruguay 47 .Fault Contract // Define a math fault data contract [DataContract(Namespace="http://Microsoft.Facultad de Ingeniería – Montevideo.ServiceModel. } } } INCO . private string problemType.Samples")] public class MathFault { private string operation. } } [DataMember] public string ProblemType { get { return problemType. } set { operation = value.

Fault Contract  En la función ponemos… [OperationContract] [FaultContract(typeof(MathFault))] int Divide(int n1. int n2). Uruguay 48 . INCO .Facultad de Ingeniería – Montevideo.

Facultad de Ingeniería – Montevideo. Uruguay 49 . “Division by zero”)). INCO .Fault Contract  Lo que nos habilita a hacer… throw new FaultException<MathFault>( new MathFault( “Division”.

catch (FaultException<MathFault> mathFault) { Console. en forma similar a una excepción try { .ProblemType).WriteLine(mathFault...Faults  Estas pueden ser procesadas por el cliente cuando ocurran.Detail. } INCO .Abort().Facultad de Ingeniería – Montevideo. wcfClient. Console. Uruguay 50 .ReadLine().

Facultad de Ingeniería – Montevideo. el host process  Un solo host process puede hostear múltiples servicios.Hosting La clase que implementa el servicio WCF no puede existir en un vacío  Todo servicio WCF debe ser hosteado en un proceso de Windows. Uruguay 51 . denominado. y el mismo servicio puede ser hosteado por múltiples host processes  INCO .

Uruguay 52 . en un proceso Windows provisto por el desarrollador INCO .Hosting  El hosting puede ser provisto por o o o IIS (Internet Information Services) WAS (Windows Activation Service) O.Facultad de Ingeniería – Montevideo.

sin que el desarrollador deba preocuparse del proceso INCO .IIS Hosting  Este hosting es muy interesante. ya que permite que todo el ciclo de vida sea controlado por el IIS. Uruguay 53 .Facultad de Ingeniería – Montevideo.

es creando un directorio virtual en el IIS. el cual identifica el code behind que provee la implementación del servicio  El enfoque es muy similar al utilizado por los servicios web ASMX  INCO .IIS Hosting La forma de realizar el deploy.Facultad de Ingeniería – Montevideo.svc. y colocando alli un archivo . Uruguay 54 .

Facultad de Ingeniería – Montevideo.cs" Service = "MyService" %> INCO .IIS Hosting <%@ ServiceHost Language = "C#" Debug = "true" CodeBehind = "~/App_Code/MyService. Uruguay 55 .

Facultad de Ingeniería – Montevideo.Bindings  Existen múltiples aspectos en la comunicación entre dos servicios o o o Tenemos varios patrones de comunicación. Tenemos múltiples protocolos de transporte para los mensajes Tenemos varios formatos de encoding en los mensajes INCO . etc. asincrónicos. sincrónicos. Uruguay 56 .

Facultad de Ingeniería – Montevideo. Uruguay 57 .Bindings  … o o o o Tenemos varias opciones para el tema de la seguridad La entrega del mensaje puede ser confiable o no confiable Podemos tener que interoperar con otros servicios y o clientes Podemos tener que interoperar con clientes legados INCO .

Uruguay 58 .Bindings Si empezamos a contar todas las opciones posibles.Facultad de Ingeniería – Montevideo. cliente y servicio deben estar alineados. veremos que las combinaciones son muchas (varios cientos tal vez)  Algunas de estas opciones son mutuamente excluyentes. y algunas otras requeridas  Claramente. si queremos tener una comunicación exitosa  INCO .

Facultad de Ingeniería – Montevideo.Bindings  Para simplificar este proceso de elección. Uruguay 59 . WCF agrupa estos aspectos de comunicación. en grupos denominados bindings INCO .

Facultad de Ingeniería – Montevideo. consistente entre si.Bindings  Un binding es un conjunto de opciones. Uruguay 60 . relacionadas con: o o o o o o o protocolo de transporte encoding de mensajes patrones de comunicación confiabilidad seguridad propagación de transacciones interoperabilidad INCO .

Facultad de Ingeniería – Montevideo.Bindings por defecto          Basic binding TCP binding Peer network binding IPC binding Web Service (WS) binding Federated WS binding Duplex WS binding MSMQ binding MSMQ integration binding INCO . Uruguay 61 .

y modificar alguna de sus propiedades.Bindings Los bindings son altamente extensibles  Podemos tomar uno existente.Facultad de Ingeniería – Montevideo. Uruguay 62 . en lugar de comenzar de 0  INCO .

Facultad de Ingeniería – Montevideo. Uruguay 63 .Encodings disponibles INCO .

Selección del binding INCO .Facultad de Ingeniería – Montevideo. Uruguay 64 .

Facultad de Ingeniería – Montevideo. Uruguay 65 .Entonces… Todo servicio esta asociado con una dirección (address) que define donde se encuentra el servicio  Un binding que define como comunicarnos con el servicio  Un contrato (contract) que define que hace el servicio  INCO .

se conoce como el ABC del servicio  WCF formaliza esta relación en la forma de un endpoint  El endpoint es la fusión de la address. Uruguay 66 . el binding y el contract  INCO .Endpoints Esta terna que gobierna el servicio.Facultad de Ingeniería – Montevideo.

Facultad de Ingeniería – Montevideo. Uruguay 67 .Endpoints INCO .

serviceModel> INCO .serviceModel> <services> <service name = "MyNamespace.IMyContract" /> </service> </services> </system.MyService"> <endpoint address = "http://localhost:8000/MyService/" binding = "wsHttpBinding" contract = "MyNamespace. Uruguay 68 .Facultad de Ingeniería – Montevideo.Endpoint  Se configura declarativa y/o programaticamente al construir el servicio <system.

tcp://localhost:8001/MyService/" binding = "netTcpBinding" contract = "IMyContract" /> <endpoint address = "net. Uruguay 69 .Endpoint <service name = "MyService"> <endpoint address = "http://localhost:8000/MyService/" binding = "wsHttpBinding" contract = "IMyContract" /> <endpoint address = "net.tcp://localhost:8002/MyService/" binding = "netTcpBinding" contract = "IMyOtherContract" /> </service> INCO .Facultad de Ingeniería – Montevideo.

Uruguay 70 .Facultad de Ingeniería – Montevideo.Arquitectura de WCF INCO .

Sign up to vote on this title
UsefulNot useful