4.21.2011

¿Qué es el Windows AppFabric?

 

En realidad el AppFabric es un producto que viene a llenar un vacío que existe en la tecnología Microsoft desde la salida de .NET. Antes de esto, cuando desarrollábamos aplicaciones componentizadas utilizábamos el Transaction Server de Microsoft, el cual era un producto que me permitía tener componentes Com/Com+ de forma centralizada y mis aplicaciones podían consumirlos de forma remota. La imagen siguiente tomada de internet nos recuerda como era la interface del Transaction Server.

Cuando se empezó a programar en .NET, muchos desarrolladores empezaron a buscar alternativas para tener sus servicios de forma centralizada utilizando tecnologías como Remoting, Servicios Web ASMX, WCF, Colas – nServiceBus por ejemplo, y algunas otras más. Sin embargo, ninguna llenaba por completo – nServiceBus siendo tal vez la más completa – las necesidades de tener un servidor de aplicaciones distribuido.

Con la llegada del Windows AppFabric – Nótese que se indica Windows AppFabric y no Azure AppFabric – se obtiene un producto que en conjunto con WAS y IIS me permite tener mis componentes de negocio centralizados para uso distribuido por parte de mi aplicación. Ahora mis aplicaciones pueden consumir lógica de negocios a través de WCF llendo al AppFabric sin necesidad de tener los componentes corriendo de forma local. Además, puedo orquestar procesos de negocio utilizando Workflow foundation y mis componentes de lógica de negocios. Como podemos ver en la siguiente imagen tomada del MSDN, el AppFabric funciona sobre IIS/WAS y se basa en las tecnologías de .NET ASP.NET, WCF y WF.

Architecture overview illustration

Ahora nuestra arquitectura física y lógica lucirá de la siguiente forma:

image

Como podemos ver en la figura anterior, ahora tenemos la posibilidad de exponer nuestros servicio a través de endpoints con protocolos diversos tales como MSMQ, TCP, HTTP(s), etc. Físicamente ahora podemos decir que nuestra aplicación si esta distribuida y que todos nuestros componentes residen en nuestro servidor de aplicaciones. Con esto podemos accederlos directamente a través de servicios expuestos a través de WCF o a través de aplicaciones que consumen estos servicios y brindan funcionalidad a los usuarios finales.

image

Es muy importante destacar que el AppFabric NO ES UN ESB, algo que estaremos comentando en post posteriores

Etiquetas de Technorati: ,

4.10.2011

¿Qué es el Patrón MVC?

Continuando con la serie de post acerca del MVC en ASP.NET voy a proceder a explicar en detalle que es el patrón Model View Controller y que ventajas nos ofrece.

En primera instancia el patrón MVC es una forma de dividir y distribuir la funcionalidad de la capa de presentación en diferentes componentes; estos componentes son:

  1. Model: Contiene la información de una aplicación. En esta capa se incluyen los datos, las reglas de validación y el acceso a los datos.
  2. View: Encapsula la presentación de la aplicación; por ejemplo, en ASP.NET es el HTML.
  3. Controller: Contiene la lógica que controla el flujo del programa. Interactúa con el modelo y las vistas para controlar como fluye la información y como se ejecuta la aplicación.

El siguiente diagrama nos muestra como interactúan las partes del patrón MVC

image

¿Cómo funciona el MVC en ASP.NET?

En general, la vista es responsable de pintar la interface de usuario. La vista depende del modelo y este – el modelo - es el responsable de traer los datos a la vista; por ejemplo, el modelo puede ser una entidad que representa una película y la vista toma las propiedades de este modelo y lo despliega en el HTML. El modelo proviene del Controller. El controller es el responsable de construir un modelo y seleccionar la vista para pintarlo. El controller es como un orquestador. Podemos decir que el controller es como el director de una orquesta; no hace la música, pero coordina para que todos los músicos estén alineados y hagan que la melodía suene como debe sonar. El controller además es el responsable de recibir solitudes del usuario, en ASP.NET solicitudes HTTP. Aquí nos surge otra duda: ¿Cómo el runtime del MVC sabe que controller debe de atender la solicitud HTTP? Esto se logra a través de las rutas en ASP.NET las cuales están definidas en el namespace System.Web.Rounting. Estas “rutas” se direccionan las solicitudes HTTP a los controladores específicos en base a la definición de la ruta que el desarrollador haya hecho a la hora de crear su aplicación en el archivo global.asax.cs y en base al URL especificado a la hora de hacer el submit de la forma – algo que estaremos profundizando en post próximos. En el siguiente código se puede ver el código por defecto generado por el ASP.NET a la hora de crear un proyecto con MVC 2.

public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

routes.MapRoute(
"Default", "{controller}/{action}/{id}",

new { controller = "Home", action = "Index", id = UrlParameter.Optional } );
}

A partir de la definición de las rutas en el archivo asax, el framework MVC de ASP.NET sabe cual controller debe de invocar y con que acción debe de llamarse el controller especificado. Luego de esto, cada una de las acciones pueden retornar una vista, contenido o cualquier otro tipo de ActionResult definido en nuestra aplicación a través del controller.

public ActionResult About()
{
return View(modelo);
}

Seguidamente desplegamos la información utilizando las vistas desarrolladas y enviándole al View el modelo construido en la acción del controller que fue ejecutada. En este caso el controller se construye a partir de múltiples orígenes; pero en el mejor de los casos se construye a partir de la invocación a un método de nuestra lógica de negocios.


Es muy importante destacar que el patrón MVC no tiene ningún impacto en la lógica de negocios ni en la capa de acceso a datos.


Etiquetas de Technorati: ,

4.03.2011

Programación Imperativa en Workflow Foundation 4.0

Es sorprendente la cantidad de nuevas características que tiene el nuevo Windows Workflow Foundation para desarrollar workflows para nuestras aplicaciones de negocios. Una de las más impresionantes es la capacidad de crear código imperativo. Esto nos permite crear workflows y flujos de trabajo de forma dinámica y ejecutarlos de forma dinámica. Por ejemplo, supongamos que queremos un simple workflow que va a escribir dos textos enviados por parámetro al método que lo crea y lo ejecuta. Si lo quisiéramos hacer sin usar código imperativo simplemente escribiríamos una función como esta:

private static void EscribirEnConsola(string p, string p_2)
{
Console.WriteLine(p);
Console.WriteLine(p_2);
}

Ahora, si queremos crearlo utilizando las capacidades de código imperativo de WF4, escribiríamos un código un poco más grande pero más dinámico ya que se basa en actividades y no en instrucciones. Primero vamos a tener que agregar referencia a un dll llamado System.Activities. Seguidamente agregamos a los using las siguientes instrucciones

using System.Activities;
using System.Activities.Statements;

Ahora ya podemos programar de forma imperativa.

private static void EscribirAConsolaConWF(string p, string p_2)
{
var s = new Sequence
{
Activities = {
new WriteLine{ Text = p},
new WriteLine{ Text = p_2}
}
};
WorkflowInvoker.Invoke(s);
}

Como podemos ver en el código anterior, primero recibimos el texto que debemos escribir al dispositivo de salida configurado, luego creamos una secuencia de actividades y por último dentro de la secuencia, creamos dos actividades para escribir el Texto que nos envían por parámetro. Ahora, la pregunta que nos viene es: ¿y qué ventajas tengo con este tipo de programación? y la respuesta es obviamente muchas; por ejemplo, supongamos que las actividades anteriores no las queremos ejecutar de forma secuencial si no de forma paralela. Para esto, simplemente cambiamos la estructura del workflow de sequence a Parallel y ahora no vamos a crear actividades si no más bien Branches que se van a ejecutar de forma paralela.

private static void EscribiriAConsolaConWFParalelo(string p1, string p2)
{
var s = new Parallel
{
Branches =
{
new WriteLine{ Text = p1},
new WriteLine{ Text = p2},
new WriteLine{ Text = "Paralelo"}
}
};
WorkflowInvoker.Invoke(s);
}

Todo el soporte para el manejo de memoria y threads en el código anterior lo hace el runtime de WF4 y nosotros nos despreocupamos de la necesidad de programar muchas cosas que son carpintería y no tienen nada que ver con la lógica de negocios que queremos construir.


Etiquetas de Technorati: