2.27.2009

¿Qué es WCF? – Parte 4. Arquitectura de WCF

Como vimos en los posts anteriores, WCF nos facilita la manera de crear servicios para poder consumirlos de forma sencilla a partir de la generación de un proxy que actúa como interceptor de la llamada y nos abstrae de toda la plomería necesaria para conectarnos con el provedor del servicio y obtener el resultado deseado. En este post vamos a hablar acerca de la arquitectura de WCF.

Todas las características de WCF, entre ellas confiabilidad, administración de la concurrencia, seguridad, y activación de instancias, dependen de la arquitectura de WCF, conocida como arquitectura basada en intercepción. El hecho de que un cliente interactúe con un proxy, significa que WCF siempre esta presente entre el servicio y el cliente, interceptando la llamada y llevando a cabo pre procesamiento y post procesamiento.

Esta “intercepción” inicia cuando el proxy serializa la llamada a un stack frame para un mensaje y envía el mensaje hacia abajo en la cadena de canales. El canal es simplemente un interceptor que tiene como propósito llevar a cabo tareas específicas. Este concepto de canal es algo muy similar al manejo de “pipes” utilizado por Biztalk Server para procesar mensajes.

Cada canal del lado del cliente hace un pre procesamiento del mensaje. La estructura exacta y la composición de la cadena depende en su mayoría del tipo de binding que se este utilizando. Por ejemplo, un canal puede estar encargado de la codificación del mensaje (MTOM, texto, etc.), otro de pasar el contexto de seguridad, otro de propagar las transacciones, otro por manejar la confiabilidad de la sesión, otro para encriptar el mensaje y así sucesivamente. El último canal del lado del cliente es el canal de transporte el cual envia el mensaje a través del transporte configurado en el host.

Del lado del servidor, el mensaje “sube” otra vez por la cadena de canales pero en sentido inverso al channel stack del cliente. Es decir, el primer canal en participar en el server es el canal de transporte, el cual recibe el mensaje.  Los canales subsecuentes llevan a cabo las tareas inversas realizadas en el cliente; por ejemplo, si en el cliente se encripto el mensaje, en el server se desencripta el mensaje. Igualmente, en esta ruta del mensaje se activa la instancia del servicio requerida para consumir el servicio. El último canal en el servidor pasa el mensaje a un elemento conocido como el dispatcher. El dispatcher es el elemento que administra la ejecución de servicio. El dispatcher convierte el mensaje en un stack frame ( lo deserializa. y llama la instancia del servicio creada para completar el llamado). En la siguiente figura se puede ver este proceso.

image Como se puede ver, el servicio no sabe que fue llamado por un cliente externo, y el cliente no sabe que se esta comunicando con un cliente externo. Ambos, ven los componentes localmente para comunicarse – el cliente en el proxy y el servicio en el dispatcher. Este concepto de intercepción en ambos lados, cliente y servidor, garantiza que ambos obtiene el ambiente de ejecución que se requiere para operar correctamente.

Por último, en el proceso de respuesta, la instancia del servicio ejecuta la llamada y retorna el control al dispatcher, el cual a su vez convierte los valores retornados y la información del error – si existe – en el mensaje de regreso. El proceso se invierte siendo el dispatcher el que inicia la cadena del llamado, y el proxy el último en contestarle al cliente.

Para concluir podemos destacar que esta arquitectura nos permite extensibilidad en el modelo, ya que podríamos crear canales personalizados para interacciones propietarias o propias de un negocio o plataforma en específico.

2.25.2009

Nuevo Look de Visual Studio 2010

Como muchos de ustedes saben, en el 2010 saldrá la nueva versión de VS, la versión 4.0. Mucho se ha especulado acerca de esta herramienta, ya que el UI de la herramienta ha sido reescrito utilizando WPF. Leyendo blogs en msdn, me encontré las primeras fotos del look de VS 2010 escrito en WPF. Aquí les dejo el link para que lo puedan ver.

http://blogs.msdn.com/jasonz/archive/2009/02/20/a-new-look-for-visual-studio-2010.aspx

2.22.2009

¿Qué es WCF? – Parte 3

En el post anterior finalizamos hablando de proxies y metadata de manera general. En este post vamos a hablar acerca de como es que funciona Windows Comunication Foundation en conjunto con mi aplicación.

En primera instancia vamos a conversar acerca de como se relacionan WCF y mi aplicación. Vamos también a incluir otros componentes como el Framework y el sistema operativo. La siguiente figura nos muestra como funcionan mi aplicacion en relación a todas las partes que intervienen cuando se envía una solicitud de mensaje y cuando la otra parte recibe esta solicitud.

imageComo podemos ver, todo inicia con la aplicación que nosotros construimos y que se va a encargar de enviar una solicitud de mensaje – cliente - al host del servicio. Este envío utiliza los assemblies de WCF, los cuáles tienen como objetivo facilitar el desarrollo de mis aplicaciones orientadas a servicios. Físicamente, WCF es un grupo de assemblies que exponen tipos y funcionalidades. Estos tipos y estas funcionalidades me permiten desarrollar aplicaciones sin preocuparme por la plomería necesaria para hacer que el mensaje que yo voy a enviar al host llegue sin problemas. Cuando hablo de plomería me refiero a las actividades relacionadas con abrir y cerrar la conexión, rutear el mensaje, seguridad del mensaje, etc. Por supuesto, WCF esta desarrollado sobre el framework de .NET, el cual a su vez utiliza las API’s del sistema operativo para poder llevar a cabo todas sus tareas.

Del otro lado, en el host de un servicio desarrollado en WCF sucede lo mismo. Un mensaje llega, y WCF, a través del sistema operativo y utilizando el framework de .NET, procesa el mensaje y de ser necesario, construye y envía una respuesta.

Así es como se relaciona WCF con el resto de los componentes necesarios para poder construir aplicaciones que utilizan servicios. En el próximo post vamos a conversar acerca de la arquitectura de WCF.

2.12.2009

¿Qué es WCF ? – Parte 2

En el post anterior publicamos el primer post acerca de lo que es WCF. En este post vamos a continuar con la parte 2 de esta serie de articulos.

En el contrato especificado en el post de la parte 1, usamos un tipo de retorno del tipo List<Usuario>. Usuario es una clase que escribí que representa una entidad de negocios la cual me permite almacenar los datos en detalle que acepto o envio desde el servicio generado. La estructura de este objeto como veremos en un post posterior va a viajar en formato XML con el wsdl, para que el consumidor del servicio tenga acceso al tipo de datos predefinido como tipo de retorno en mi servicio. Esta información del servicio en conjunto con el detalle del endpoint – definido en el post anterior – van a conformar la metadata del servicio.

Hay que tomar en cuenta que para que el “Usuario” vaya por la red, este debe de ser serializable. Ser serializable significa que el estado del objeto en un momento determinado puede ser persistido en algún medio, ya sea un archivo o un stream de bytes o en una instancia de una clase ya activa (Si nosotros como humanos fueramos serializables, entonces podríamos teletransportarnos :) ).

Con esta metadata del servicio, un consumidor del servicio puede ahora generar un Proxy. Ahora, ¿qué es un proxy en este contexto? Un proxy en WCF es un cliente generado a partir de la metadata expuesta por el servicio que hereda de la clase ClientBase<T>, por ejemplo:

[System.Diagnostics.DebuggerStepThroughAttribute( )]
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "3.0.0.0")]
public partial class ServiciosSeguridadClient : System.ServiceModel.ClientBase<WPF_ClienteSeguridad.ReferenciaServiciosDeSeguridad.IServiciosSeguridad>, WPF_ClienteSeguridad.ReferenciaServiciosDeSeguridad.IServiciosSeguridad




Este proxy nos abstrae toda la lógica necesaria para conectarse con el servicio que se desea consumir, desde el manejo de la dirección del servcio a consumir hasta el endpoint necesario para poder conversar con el servicio. Igualmente, cuando tenemos tipos compuestos en el retorno o en los parámetros del servicio, estos tipos son generados automáticamente por el proxy para así poder utilizarlos del lado del cliente, es decir, para que la aplicación que consume el servicio “compile” cuando utilizamos el servicio. Podemos decir entonces, que el proxy es un puente que nos expone todas las operaciones en un servicio, y abstrae la serialización y el envío a traves de la red. Finalmente debemos decir que un proxy utiliza un único endpoint.



Por último, el cliente y el host hablan entre sí a través de varios canales. Además, alrededor de estos canales, se pueden tener comportamientos – behaviors – asociados con el servicio. Un canal es el medio por el cual el mensaje viaja entre el cliente y el ente que hostea el servicio. La comunicación se lleva a través de de un modelo conocido como el channel stack el cual estaremos revisando en detalle en post posteriores. Un comportamiento sirve para modificar un mensaje cuando el mensaje viaja por el channel stack.



En resumen podemos decir que vamos a tener un cliente y un host los cuales se ponen de acuerdo en un contrato. El host expone endpoints los cuales tienen una combinación de dirección, binding y contrato – ABC. El cliente utiliza un proxy que esta ligado a un endpoint, por lo tanto esta ligado a un contrato en particular. Por último, todos los detalles relacionados con la comunicación se abstraen a través de los canales y los comportamientos.



En el siguiente post vamos a profundizar en el tema del channel stack para comprender como es que funciona la parte de comunicación en WCF.

2.08.2009

¿Qué es WCF? – Parte 1

Una de las preguntas más comúnes cuando hablamos de servicios y arquitecturas orientadas a servicios en tecnologías Microsoft es: ¿Qué es WCF? Pues vamos a tratar de dar una breve introducción referente a que es WCF.

WCF significa Windows Comunication Foundation. Esta disponible desde la versión 3.0 del framework de .NET. Muchos gurús de SOA incluso dicen que WCF es un framework aparte al framework de .NET – algo con lo que coincido – escencialmente por que el framework de .NET conoce de componentes y no de servicios.

Se preguntarán entonces, para que otra forma de comunicación entre componentes si ya hemos tenido DCOM, Remoting, Servicios Web, WSE, etc. La respuesta corta a esta pregunta es SOA. WCF es diferente de las versiones anteriores antes mencionadas para comunicar componentes. Aunque ya definimos que es SOA en este post, vamos a simplificarlo para explicar que es WCF y por que es tan diferente como estamos intentando explicarlo. Pensemos en SOA como diferentes piezas de código ( servicios ) que estan corriendo alrededor del mundo y los clientes pueden hacer uso de estos servicios ( consumirlos ). El ente que hostea el servicio lleva a cabo las complejidades internas, y la infraestructura de comunicación  permite cosas tales como versionamiento, seguridad, ruteo, etc. Así, uno de los principales doctrinas de SOA es el aislamiento. ¿Por qué? Vamos a decir que estamos consumiendo un servicio web que acepta un parámetro cédula de identidad para buscar una persona en una base de datos de cliente y que este servicio retorna la persona encontrada. Todo lo que tiene que tiene que hacer el cliente es preocuparse por el parámetro de ingreso y por el dato que se le va a regresar. Más allá de este modelo solicitud/respuesta, el hosteador del servicio nunca habla con el cliente. Es por esto que decimos que existe una asilamiento entre el cliente y el servidor, y ellos interoperan solamente con lo acordado para interoperar es decir, el contrato.

En WCF se utiliza el término contrato para referirse a lo que el servicio hace. Usualmente en WCF un contrato es implementado como una interface decorado por el atributo [ServiceContract]. Un contrato por ejemplo luce como el siguiente código.

[ServiceContract]
public interface IServiciosSeguridad
{
[OperationContract]
List<Usuario> ObtenerUsuarios( );

}



En realidad se requieren al menos 3 piezas de información antes de poder utilizar un servicio:





  • La dirección: donde puedo encontrar el servicio.




  • El binding: cuál protocolo utilizar para poder consumir este servicio.




  • El contrato: cuando ya se donde esta el servcicio, y como voy a conversar con él, el contrato me dice que puedo hacer con el servicio.




Esto en WCF es conocido como el ABC ( Address, Binding, Contract) del servicio. Estos 3 componentes juntos conforman lo que se conoce como un EndPoint. Un EndPoint es como el que expone el servicio ( host del servicio ) expone un servicio para que muchos clientes puedan invocar las operaciones definidas en el contrato.



En el siguiente post vamos a seguir conversando acerca de WCF, principalmente de Proxies, canales y comportamientos.



 



2.02.2009

Controles para Silverlight – Mac Style

Normalmente no escribo acerca de controles o utilidades de terceros que yo utilizo para desarrollar aplicaciones en .NET, pero esta vez voy a hacer una excepción. Esta excepión se debe a que estoy utilizando un par de controles para silverlight que me parecen impresionantes. Esto son los controles de WebAqua. Estos controles me permiten tener un desktop web con el “look and feel” del sistema operativo de Mac Leopard.

En realidad son dos controles que me permiten tener formas de navegación idénticas al MacOS. El primero es el WebFishEye, que es algo así como el toolbar de aplicaciones que aparece en las Mac. La siguiente figura es un ejemplo de una aplicación WEB que utiliza este control. Si quieres ver el demo funcional, aquí lo puedes probar.

image

El segundo control es el WebCoverFlow, el cual permite tener una interface similar al del IPhone para desplegar imágenes. En la siguiente figura se puede ver una combinación del WebVoverFlow y el WebFishEye funcionando. Si quieres ver el demo funcional lo puedes ver aquí.

image

Espero les sirva para futuros desarrollos web.