Workshop AppFabric: Madrid 28 de mayo, apúntate!

clip_image002clip_image003clip_image004

Next Friday (Madrid, May 28th 2010) we’ll deliver a Workshop about Windows Server AppFabric.

You can register yourself using this page:

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032451744&Culture=es-ES

clip_image006 clip_image008

Agenda (9:30 – 14:00):

– Introduction to AppFabric (Windows Server & Azure) – César de la Torre – Microsoft

– Distributed Cache using AppFabric-Cache (aka. codename ‘Velocity’) – César de la Torre – Microsoft

— Coffee time

Hosting & Monitoring WCF Services (aka. codename ‘Dublin’) – Roberto Gonzalez – Renacimiento

Hosting Workflow-Services 4.0 (aka. codename ‘Dublin’) – Unai Zorrilla – Plain Concepts

Entity Framework: UnitOfWork

Como seguramente muchos sabréis, uno de los elementos más importantes a la hora de trabajar con Entity Framework, en realidad lo mismo aplicaría a otras tecnologías ORM como NHibernate, es decidir, de forma acorde a las necesidades del desarrollo, como gestionar las unidades de trabajo. Para los que no estéis muy familiarizados con este patrón decir que, básicamente lo que propone es una manera de gestionar una colección de objetos durante una transacción de negocio y coordinar la escritura de sus cambios y la posible resolución de problemas de concurrencia. Si lo acercamos a la tecnología, podríamos decir que cualquier ObjectContext de EF, lo mismo con los ISession de NHibernate, es una unidad de trabajo, puesto que mantiene y conoce tantos los cambios en los objetos consultados como cualquier nuevo objeto y objeto que se desea eliminar, retrasando todos estos cambios hasta que se invoca a su método commit, que para el caso de EF se corresponde con SaveChanges y en NH con Flush.

Lógicamente, la gestión del ciclo de vida de nuestras unidades de trabajo tiene una vital importancia, y podría llegar a ser un factor de descisión crítico. En una aplicación rica, cliente servidor nos podríamos plantear gestionar una sola unidad de trabajo, ya que podríamos asumir falta de concurrencia sobre la  misma, sin embargo en una aplicación distribuída o bien en un entorno como ASP.NET esta decisión sería una catastrofe, debido al posible alto grado de concurrencia. En estos últimos entornos, ASP.NET o una fachada de servicios distribuídos, la decisión más acertada, de hecho la única que puedes llegar a tomar, es utilizar unidades de trabajo independientes para cada una de las peticiones que se realizan, iniciar una unidad de trabajo, realizar las operaciones de negocio y comprometer la misma.

Por supuesto, una de las necesidades que pueden surgir, es que dentro de una misma petición, por ejemplo un request ASP.NET o una llamada a servicio, cualquiera de las operaciones de negocio involucradas compartieran la misma unidad de trabajo. Para lograr esta casuística existen diversas formas de afrontarlo, desde el uso de cualquier IoC que fuera capaz de realizarnos esta resolución o bien cualquier solución AdHoc. Empezaremos hablando de las posibles soluciones AdHoc, lo cual nos permitirá entender aún un poco más que mecanismos pueden utilizar los distintos frameworks contenedores de dependencias en la actualidad.

 

Primer intento: ThreadStatic

 

ThreadStatic es un atributo disponible en .NET framework que nos permite hacer uso del almacen local de un hilo de trabajo, Thread Local Storage o TLS,de tal forma, que la información guardada en este almacen no es compartida con otros hilos de trabajo.  Dadas estas premisas se podría pensar en este atributo como una buena forma de establecer nuestras unidades de trabajo, puesto que cada petición a una fachada de servicios o request ASP.NET se realizaría dentro de un hilo de trabajo, sin embargo tanto ASP.NET como WCF utilizan en pool de hilos de .NET y por lo tanto varios usuarios podría reutilizar el mismo hilo de trabajo, lógicamente de forma no concurrente, con lo que esta información contenida en el TLS se podría compartir y por lo tanto podríamos tener distintos tipos de problemas, la mayoria funcionales.

Si hacemos su correspondiente en Unity, el IoC de ‘Microsoft’, sería establecer el LifetimeManager del registro de una dependencia como PerThreadLifetimeManager.

Segundo intento: CallContext

De forma similar a ThreadStatic, CallContext nos ofrece una colección de objetos especializada almacenada para cada ejecución lógica, que no son compartidos con otros CallContext o hilos lógicos. Seguro que usted estimado lector está pensando que esto tiene mejor pinta, puesto que aunque tanto ASP.NET como WCF usen en ThreadPool tenemos una forma de tener una información no compartida.

Sin embargo, CallContext, encierra una serie de problemas que es necesarios mencionarlos. El primero de ellos se refiere a una característica de ASP.NET conocida como Thread-Swaping, mediante la cual por ejemplo el hilo de ejecución de una petición podría cambiar entre los eventos BeginRequest y Load de una página y por lo tanto la información almacenada en CallContext se perdería, le recomiendo la siguiente resumen de una WebCast sobre el manejo de hilos en ASP.NET.

 

Tercer intento: HttpContext y OperationContext

Aunque HttpContext internamente use CallContext, ASP.NET nos garantiza que aunque se podruzca un cambio de hilo de ejecución en nuestra petición ASP.NET la información contenida en el es copiada y por lo tanto permanecerá disponible, por lo tanto este parece el candidato más firma para almacenar y mantener nuestras unidades de trabajo en una petición ASP.NET. la correspondiente versión de este elemento dentro de WCF sería OperationContext.

Aunque en la versión actual de Unity, 1.2, no disponemos de ningun LifetimeManager específico para gestionar de esta forma el ciclo de vida de un objeto, es realmente sencillo crearse uno personalizado como podrá observar en el siguente enlace.

 

Nota: la version 2.0 de Unity dispondrá de un lifetimemanager conocido como PerResolveLifetimeManager que podría servirnos como alternativa a la creación de uno personalizado.

 

Espero que esta información os sea de utilidad,

Unai

XXV Architect Forum ( N Layer DDD Architecture .NET 4.0)

El 13 de Mayo repetimos en Barcelona el evento de arquitectura  realizado hace poco tiempo en las oficinas de Microsoft en Madrid, el cual tuvo una gran cantidad de público.

La agenda y el registro los encontraréis en el siguiente enlace :

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032446174&Culture=es-ES

 

Saludos

Unai