VEMN Team Blog

Introducción a Windows Communication Foundation

PARTE 1

• Web Services Seguros
• Aplicaciones distribuidas transaccionables y confiables
• Interoperabilidad basada en Web Services (WS-*)
• Variedad de transportes
• Varias posibilidades para alojar nuestros servicios (en IIS, en una Aplicación de WinForms, etc.)
• Conjunto de clases accesibles a través del namespace System.ServiceModel para desarrollar nuestros servicios. 

• Transporte
• Sistemas de seguridad
• Patrones de mensajería
• Sistemas de representación de datos
• Modelos de alojamiento 

1. Los límites son explícitos: los sistemas distribuidos orientados a servicios interactúan enviando mensajes a través de límites formales y explícitos, no debemos considerar que hay detrás (la implementación) ya que esto es justamente lo que preserva la flexibilidad. Cruzar éstos límites tiene un costo en tiempo de procesamiento y en las comunicaciones. Por esto las llamadas a servicios deben ser simples y eficientes. Cada interacción implica un cruce de límites. 

1. Los servicios son autónomos: los servicios se despliegan, administran y versionan en forma independiente. Los servicios no deberían fallar si cualquier servicio dependiente no está disponible. No existe una entidad controladora de servicios. Deben tener contemplado el manejo de los errores, ya sean internos propios del servicio, o errores generados por los clientes por mal formación de los mensajes, etc. 

1. Los servicios comparten Esquemas y Contratos, no clases y tipos: los servicios utilizan contratos para pasar datos y especificar comportamientos, no pasan clases o tipos. Los servicios no tienen ningún conocimiento del entorno de ejecución del cliente u otro servicio,  ya que la información que se intercambia es independiente de la plataforma. 

1. Compatibilidad basada en políticas: cada servicio brinda una política, descripción de si mismo, de sus capacidades y requerimientos. Esto permite que dos sistemas encuentren un área común para poder interactuar. Las políticas separan las interacciones que puede tener de las restricciones. 

1. Aislamiento: la modificación del comportamiento de un servicio no implica modificar o recompilar otros servicios o clientes. 

1. Independencia de ubicación: es transparente si un servicio se ejecuta localmente o en un equipo remoto, la forma de utilización es la misma. 

1. Flexibilidad de transporte: en cuanto a protocolo y formato de representación, ya que existen varias alternativas o incluso pueden crearse en forma personalizada. 

1. Independencia de la plataforma e implementación: no necesitamos conocer el contexto de ejecución del servicio para poder interactuar con el. 

1. Independencia del tiempo: un servicio no necesita estar en línea para poder interactuar con el. Por ejemplo si utilizamos MSMQ. 

1. Capa de Contratos: define los puntos en común que tienen que tener los servicios y clientes para poder interactuar.
   1. Data Contract: define los objetos y estructuras complejas comunes.
   2. Message Contract: define cual información viaja en la cabecera y cual en el cuerpo de los mensajes.
   3. Service Contract: define el comportamiento que el servicio expondrá al entorno.
   4. Policy y Binding: define las características del canal de comunicaciones y requisitos que hay que cumplir para poder interactuar con el servicio. 

1. Capa de ejecución del servicio: esta capa describe el comportamiento del servicio cuando está operando. Opera principalmente sobre el cuerpo de un mensaje recibido.
   1. Throlling behavior: define la cantidad de mensajes que podrá procesar el servicio.
   2. Error behavior: define que hacer en caso de error y como se lo informa al cliente.
   3. Metadata behavior: define como el servicio publicará una descripción de si mismo.
   4. Instante behavior: define la forma en que se instanciará el servicio propiamente dicho, es decir la clase que implementa un contrato.
   5. Transaction behavior: define las operaciones que podrán formar parte de transacciones y realizar un rollback en caso de error.
   6. Dispatch: controla como WCF procesará un mensaje.
   7. Message inspection: permite inspeccionar las distintas partes de un mensaje.
   8. Parameter filtering: permite que ocurra una acción predefinida según el contenido de la cabecera de los mensajes. 

1. Capa de Mensajería: esta capa esta formada por canales de comunicaciones y opera sobre la cabecera y el cuerpo del mensaje. Permite formar un stack con características de un canal de comunicaciones acorde a los requerimientos de nuestro sistema.
   1. WS-Security Channel: implementación de la especificación de WS que permite seguridad a nivel de mensaje.
   2. WS-Reliable Messaging Channel: implementación de la especificación de WS que permite asegurar la entrega de mensajes.
   3. Encoders: define el conjunto de formatos de representación de datos que podemos utilizar.
   4. Http Channel: define que el transporte de mensajes se realizará a través del protocolo Http.
   5. TCP Channel: define que el transporte de mensajes se realizará utilizando el protocolo Tcp.
   6. Transaction Flow Channel: define el patrón de los mensajes para posibilitar transacciones.
   7. NamedPipe Channel: posibilita la comunicación entre procesos a través de tuberías.
   8. MSMQ Channel: posibilita la interacción con un servicio a través de una cola de mensajes. 

1. Hosting y Activación: esta capa define las posibles formas de ejecutar y activar un servicio
   1. Self-Hosted: a través de un archivo ejecutable (.exe)
   2. Administrado: a través de un agente externo (Internet Información Service o Windows Activation Service).
   3. Servicio de Windows
   4. Los componentes COM+ pueden ser alojados como un servicio WCF

WCF wcf