3.31.2011

POST Número 100

 

100 colones

Después de 4 años de haber iniciado con este blog hoy me he dado cuenta que estoy en 99 posts; es decir, este será mi post número 100. Ha sido una gran experiencia en la cual he aprendido mucho de este tema de los blogs y sobre todo he tenido la oportunidad de compartir con mucha gente que por otros medios hubiera sido imposible de conocer. El blog igualmente ha crecido mucho y en la actualidad recibe alrededor de 3000 visitas mensuales. Espero poder seguir escribiendo por un buen rato más.

Agradezco a todos el tiempo que se toman para leer los post, hacer comentarios y hacerme consultas por correo.

3.30.2011

Utilizando WCF y MSMQ

Una de las características más relevantes y más sub utilizadas de WCF es su capacidad de interactuar con el servidor de colas de Windows – MSMQ. Existen muchas aplicaciones que están desarrolladas bajo un esquema sincrónico cuando en realidad no es necesario estrictamente hablando el utilizarlo. Esto se da en casos en donde por ejemplo se puede procesar algún mensaje y el cliente no necesita una confirmación de la operación ya que si el mensaje pudo ponerse en la cola, se puede tener plena seguridad que más temprano que tarde este será procesado.

Algunos ejemplos en donde se puede aplicar este tipo de operaciones son

  • Procesamiento de Órdenes – Ejemplo: Amazon.
  • Auditoría de Sistemas – Ejemplo: Guardar rastros de la ejecución de operaciones
  • Registro de Actividades – Recibir solicitudes cuyo procesamiento puede ser desde inmediato hasta tardar días o meses.

WCF y MSMQ

WCF se puede integrar con el servidor de colas de Microsoft de una manera muy sencilla, simplemente creando un endpoint extra al servicio y especificando en el mismo la dirección de la cola que queremos utilizar. Además, cuando un cliente invoca un servicio a través de un endpoint de msmq, en realidad no se esta comunicando con el servicio en sí, si no que esta poniendo un mensaje en la cola especificada por el endpoint generado del lado del cliente; del lado del servicio, existe un “listener” que escucha en la cola si hay mensajes para consumir por parte del servicio. Este esquema nos permite tener alta disponibilidad en nuestra aplicación, porque si el servicio no esta disponible, los mensajes siempre van a ser puestos en la cola y cuando el servicio vuelva a estar disponibles, estos son consumidos por WCF.

image

Por otro lado, las operaciones de WCF utilizando MSMQ son operaciones de una sola vía, por lo tanto no se reciben respuestas ni excepciones provocadas por el servicio.

Instalando Msmq

Para poder crear colas e integrarlas con WCF, tenemos que tener instalado el servidor de colas del sistema operativo; esto se logra desde agregar programas y habilitar funcionalidades de Windows.

image

Una vez instalado el servidor de colas de Windows procedemos a ir a crear nuestra cola de procesamiento en el mismo. Para esto, vamos a darle botón derecho sobre la opción equipo en el menú inicio y luego procedemos a seleccionar administrar. Luego nos aparece la pantalla de administración del equipo donde seleccionamos Message Queue Server.

image

Ahora vamos a proceder a crear la cola. En msmq existen dos tipos de colas: públicas y privadas. Las colas públicas son las que pueden accederse desde otros equipos, las colas privadas son las que están construidas para consumo local. En nuestro caso vamos a utilizar una cola privada, ya que para publicar una cola pública se requieren varias cosas extras como un controlador de dominio de colas y especificar el esquema de seguridad de la misma. Para crear una cola privada le damos botón derecho sobra el folder de colas privadas y en la pantalla de agregar cola digitamos el nombre de la cola y la ponemos transaccional; el nombre de la cola será requestqueue.

image

Una vez creada la cola esta debe de aparecer en el servidor como disponible.

image

Como podemos ver en la figura anterior, podemos acceder nuestra cola privada en la dirección private$\requestqueue.

Creando el Servicio

El siguiente paso es crear el servicio en WCF. Para esto simplemente vamos a crear un contrato con una operación, al ser las pilas asincrónicas y de una vía debemos definir estas operaciones como de una vía en el contrato, caso contrario vamos a tener un error del tipo InvalidOperationException a la hora de levantar el servicio.

[ServiceContract]
public interface IProcesarRegistros
{
[OperationContract(IsOneWay = true)]
void ProcesarRegistro(int id);

}

El siguiente paso es la implementación del servicio, el cual en este caso simplemente hará un trace del mensaje en la ventana de output de visual studio.

using System.Diagnostics;

namespace ColasPrueba
{
public class ProcesarRegistros : IProcesarRegistros
{
public void ProcesarRegistro(int id)
{
Trace.WriteLine( string.Format("Registro {0} Procesado", id.ToString()));
}
}
}


El siguiente paso es crear el endpoint para acceder a la cola creada anteriormente.

 <endpoint address="net.msmq://localhost/private/requestqueue"
binding="netMsmqBinding"
contract="ColasPrueba.IProcesarRegistros"
bindingConfiguration="msmqSinSeguridad" />

Como podemos ver, la dirección de la cola especifica que vamos a utilizar el protocolo msmq y que vamos a poner mensajes en una cola privada llamada requestqueue. Además agregamos un atributo llamado bindingConfiguration en donde vamos a especificar que la cola no tiene seguridad – las colas normalmente hay que asegurarlas, pero para este post vamos a usarla sin ningún tipo de control de acceso.

</services>
<
bindings>
<
netMsmqBinding>
<
binding name="msmqSinSeguridad">
<
security mode="None" />
</
binding>
</
netMsmqBinding>
</
bindings>
<
behaviors>

Con esto ya podemos ejecutar nuestro servicio para poder crear un cliente y hacer una referencia al mismo.


image


Creando el Cliente


Ahora procedemos a crear el cliente que va a consumir el servicio. En nuestro caso, vamos a consumir el metadata del servicio a a través del endpoint mex, que en nuestro caso utiliza la dirección base que es del tipo HTTP. El cliente para este ejemplo será una aplicación de consola y vamos a agregar la referencia al servicio de msmq copiando la dirección expuesta en el cliente de pruebas de WCF – pantalla anterior.


image


En el código creamos el proxy e invocamos el método ProcesarRegistro.

using ClienteColas.ReferenciaServicioColas;

namespace ClienteColas
{
class Program
{
static void Main(string[] args)
{
ReferenciaServicioColas.ProcesarRegistrosClient _proxy
= new ProcesarRegistrosClient("NetMsmqBinding_IProcesarRegistros");
_proxy.ProcesarRegistro(43);
Console.WriteLine("Mensaje Enviado");
}
}
}


Cuando ejecutamos la aplicación vemos que en la ventana de output se hace el trace del registro.


image


image


Por último, para probar la tolerancia a fallos de este esquema, vamos a apagar el servicio y vamos a ejecutar el cliente con el servicio detenido. Cuando esto sucede, el mensaje llega a la cola, pero esta no lo entrega porque no hay que este escuchando para consumirlo. El mensaje lo podemos ver almacenado en la cola.


image


Cuando levantamos de nuevo el servicio, el mensaje se procesa y desaparece de la cola.




Etiquetas de Technorati: ,

3.22.2011

ASP.NET MVC: El MVC no es una forma de Arquitectura

En estos días se ha puesto muy de moda el uso del MVC con ASP.NET y muchos lectores del blog me han solicitado que empiece una serie de posts similares a los del Entity Framework { los cuales no he terminado}.  Es por esta razón que decidí iniciar una secuencia de artículos relacionados con el MVC en ASP.NET y además me decidí a iniciar relacionando la arquitectura de software y el MVC.

Cuando uno observa los desarrolladores de diferentes empresas trabajando con el MVC, se da cuenta que es muy común que se mezcle de forma errónea el término patrón con el término arquitectura. Esto principalmente porque el desarrollar tiende a pensar que porque esta haciendo una separación de componentes esta trabajando con una arquitectura n-layer lo cual no es correcto. Para entender un poco más este tema vamos a ver una típica arquitectura n-Layer de un post anterior dentro de este mismo sitio.

En este caso las capas están bien definidas y si uso es específico a la funcionalidad que cada una puede brindar. Si tuviéramos que colocar el MVC dentro de esta arquitectura tendríamos que modificar la capa de presentación para que luciera como se ve a continuación.

image

Como vemos en la imagen anterior, el patrón MVC es un patrón para ser utilizado en la capa de presentación, por lo tanto; en una arquitectura n-layer, la capa de presentación es la única beneficiada con el uso de este patrón.

Resumiendo, tener un patrón de software mejora la forma en que se comporta tu arquitectura de software, pero un patrón nunca debe reemplazar una arquitectura ya que por lo general un patrón se utiliza en una capa específica; por ejemplo, el singleton se puede utilizar o en la capa de acceso a datos, o en la lógica de negocios o incluso en el UI, pero el hecho de utilizar el patrón singleton no implica que no debas tener una arquitectura n-layer para tu aplicación.

Etiquetas de Technorati: ,

3.14.2011

Azure: Hola Mundo

Últimamente he tenido la oportunidad de estar presente como expositor en charlas o cursos de introducción a la computación en la nube utilizando Azure. Quizás la pregunta más común es como hacer para iniciar el desarrollo en Azure. Por esta razón  voy a escribir un post explicando que se requiere para desarrollar aplicaciones en la Nube utilizando Windows Azure.

Configurando el Ambiente de Desarrollo

En primera instancia debemos configurar nuestro ambiente de desarrollo para poder desarrollar aplicaciones en Azure. El primer paso es instalar el SDK de Azure y las herramientas de Azure para Visual Studio – 2010 en nuestro caso. Para llevar esto a cabo, vamos a crear un nuevo proyecto en Visual Studio 2010, luego procedemos a seleccionar la opción Cloud en el ventana de proyectos y luego procedemos a instalar las herramientas necesarias para crear nuestra aplicación.

image

Cuando le damos Ok a la creación del proyecto, este nos lleva a la siguiente página Web dentro del Visual Studio para que descarguemos las herramientas requeridas.

image

Procedemos a la descarga. Si no tenemos instalado el Web Platform Installer procedemos a instalarlo.

image

Seguidamente el WPI va a darnos la opción de instalar Azure vía su interfaz gráfica.

image

Procedemos a instalar las herramientas de Visual Studio.

image

Otra forma más simple de instalar el conjunto completo de herramientas requerido para desarrollar aplicaciones en Azure es buscar el sitio Web propio de descargas del SDK de Azure y descargarlo desde ahí.

image

En el caso anterior, el instalador más grande trae consigo todo lo requerido para el desarrollo en Azure; es decir, instalará el SDK de Windows Azure y las herramientas de Visual Studio para Azure.

Desarrollando Mi Primera Aplicación con Azure

Una vez instalados tanto el SDK de Azure como las herramientas para Visual Studio, procedemos a crear nuestro proyecto de Azure. Vamos de nuevo a seleccionar File –> New –> Proyect y en la pantalla de plantillas seleccionamos Cloud y luego seleccionamos Windows Azure Project.

image

Seguidamente procedemos a seleccionar el tipo de proyecto de Azure que nos aparece luego de seleccionar Ok en la pantalla de New Project.

image

Como podemos ver en la pantalla anterior, Visual Studio nos va a presentar una serie de opciones disponibles para desarrollar nuestras aplicaciones utilizando Azure. Las opciones disponibles son:

  • Web Role ASP.NET: Nos permite crear aplicaciones ASP.NET y ponerlas a funcionar en Azure.
  • Web Role ASP.NET MVC: Nos permite crear aplicaciones ASP.NET que utilizan el patrón MVC para la capa gráfica.
  • WCF Service Web Role: Nos permite crear un servicio WCF que se va a exponer desde Windows Azure.
  • Worker Role: Nos permite crear un proyecto con el cual podremos crear un servicio que procese información a nivel de Windows – similar a un Windows Service.
  • CGI Web  Role: nos permite crear proyectos que basan su modelo de procesos en sabores de Linux – ej PHP.

Para nuestro ejemplo vamos a escoger un Web Role ASP.NET. Le damos Ok y esperamos que Visual Studio nos haga la solución.

Una vez creada la solución, nuestra estructura de proyecto se verá de la siguiente forma:

image

La solución creada tiene dos proyectos; uno es el típico proyecto ASP.NET con Web Forms, y el otro es un proyecto específico para la nube. En este último se encuentra toda la configuración que vamos a subir a la nube y que le va a permitir a la aplicación ASP.NET ejecutarse correctamente en Azure. En el archivo cscfg del proyecto de cloud,  vamos a ver toda la configuración relacionada con nuestra aplicación tal como hileras de conexión o variables de configuración creadas a nivel de instancia. Nótese que aunque la aplicación Web tiene un archivo Web.config, podemos agregar variables a nivel de instancia en nuestro archivo de extensión cscfg – de hecho es recomendable agregarlo a nivel de instancia en la nube que a nivel de config de la aplicación porque para que se refresque un cambio en el archivo no es necesario hacer un re deploy de la aplicación.

image

Por otro lado, si le damos doble clic al archivo WebRole1, vamos a tener la configuración a nivel de la instancia(s) del proyecto a ejecutar en la nube. Por ejemplo, aquí podremos elegir con cuantas y con que tipo de instancia deseamos iniciar el deployment de nuestra aplicación.

image 

Por último para modificar nuestra aplicación, simplemente vamos a agregar un mensaje de bienvenida en nuestra página aspx tal y como lo hacemos normalmente cuando desarrollamos aplicaciones Web con ASP.NET y Visual Studio.

image

Ahora procedemos a ejecutar nuestra aplicación dando F5 en VS, el resultado al ejecutar esta aplicación es el siguiente:

image

Cuando inicia nuestra aplicación automáticamente se levanta el emulador de Azure Compute – para correr instancias – y del Azure Storage – para guardar datos en la instancia {esto es diferente a SqlAzure}

image

Cuando se instalan los componentes de Azure en la máquina local, estamos creando un ambiente simulado al que Microsoft nos ofrece en la nube. Esto quiere decir, que cuando desarrollamos la aplicación en nuestra máquina, no la probamos en la nube, si no que más bien, estamos utilizando componentes instalados por el SDK de Azure que nos permiten “simular” el comportamiento de nuestra aplicación en la nube. En próximos post vamos a analizar los emuladores de Azure.

Etiquetas de Technorati: ,

3.05.2011

El Entity Framework en una Arquitectura n-Layer – Parte 7 –{ Polimorfismo por Herencia }

Siguiendo con el post anterior, vamos a proceder a guardar una entidad heredada utilizando el polimorfismo por herencia en el Entity Framework. Dado que en el post anterior modificamos el esquema de entidades generado por el Entity Framework para agregar herencia, podemos aprovecharnos de esta característica para hacer métodos polimórficos en la lógica de Negocios.

Polimorfismo en .NET

En realidad existen 3 formas de polimorfismo presentes en .NET: Polimorfismo por herencia, polimorfismo por Abstracción y polimorfismo por interface – mi preferida. En este caso vamos a utilizar el polimorfismo por herencia, dado que como podemos ver en la siguiente figura una vez hecho el cambio de la herencia de las entidades del post anterior, ambas entidades creadas – contratista y empleado regular– heredan de Empleado.

image

El primer paso es crear la clase de negocios para la entidad Empresa, ya que todos los empleados tienen una empresa asociada y esto se tiene que utilizar en el UI que vamos a crear para agregar empleados contratistas.

image

Ahora en la clase EmpresaBL procedemos a agregar el código necesario para acceder a la colección de empresas presentes en la base de datos.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using HerenciaEF.DAL;

namespace HerenciaEF.BL
{
public class EmpresaBL
{
public List<Empresa> ObtenerEmpresas( )
{
var _empresas = from e in EFCommon.ObtenerContexto().Empresa select e;
return _empresas.ToList();
}
}
}

Nótese que esta vez ya no estamos creando una instancia del modelo del entity framework si no que estamos utilizando un método estático de la clase EFCommon llamado ObtenerContexto. Entonces primero debemos crear una clase que se llame EFCommon


image


Seguidamente procedemos a codificar el manejo del contexto dentro de nuestra nueva clase.

using HerenciaEF.DAL;

namespace HerenciaEF.BL
{
public static class EFCommon
{
static Ejemplos_BlogEntities1 _contexto = null;
public static Ejemplos_BlogEntities1 ObtenerContexto( )
{
if (_contexto == null)
_contexto = new Ejemplos_BlogEntities1();
return _contexto;
}

}
}

Algo importante de destacar, que aquí se utiliza un singleton porque estamos utilizando una aplicación desktop, lo que no es recomendable de hacer en una aplicación Web por ejemplo – tema que trataremos en post posteriores.


Seguidamente procedemos a agregar el método para agregar los nuevos empleados. Igualmente los métodos para obtener los diferentes tipos de empleados se cambiaron para que utilicen la clase EFCommon.

public List<EmpleadoDePlanta> ObtenerEmpleados( )
{
var empleadosDePlanta = EFCommon.ObtenerContexto().Empleado.OfType<EmpleadoDePlanta>();
return empleadosDePlanta.ToList();
}

public List<EmpleadoContratista> ObtenerEmpleadosContratistas( )
{
var empleadosContratistas = EFCommon.ObtenerContexto().Empleado.OfType<EmpleadoContratista>();
return empleadosContratistas.ToList<EmpleadoContratista>();
}

public int GuardarEmpleado( Empleado pEmpleado )
{
EFCommon.ObtenerContexto().AddObject( "Empleado", pEmpleado );
return EFCommon.ObtenerContexto().SaveChanges();
}

Y en el método GuardarEmpleado esta el polimorfismo. Nótese que no estamos esperando una instancia de empleado contratista o de empleado de planta, si no que esperamos una instancia de empleado. Esto se puede hacer porque ambas entidades heredan de Empleado y pueden convertirse a la clase base y viceversa sin perder su estado – Que poderoso es el polimorfismo :P -


El siguiente paso es crear una pantalla para guardar un empleado contratista


image


Luego agregamos el código para llenar el combo de las empresas para que el usuario final pueda seleccionar la empresa del contratista a agregar.

public AgregarContratista( )
{
InitializeComponent();
EmpresaBL _empresas = new EmpresaBL();
cmbEmpresa.DisplayMemberPath = "Nombre";
cmbEmpresa.ItemsSource = _empresas.ObtenerEmpresas();
}

Seguidamente agregamos el código para agregar el empleado que se desea ingresar a la base de datos.

private void btnGuardar_Click( object sender, RoutedEventArgs e )
{
EmpleadoContratista _contratista = new EmpleadoContratista();
_contratista.Nombre = txtNombre.Text;
_contratista.Telefono = txtTelefono.Text;
_contratista.Email = txtEmail.Text;
_contratista.CostoXHora = Convert.ToDecimal( txtCostoXHora.Text );
_contratista.Empresa = cmbEmpresa.SelectedItem as Empresa;

EmpleadoBL _empleadoBL = new EmpleadoBL();
_empleadoBL.GuardarEmpleado( _contratista );
}

Importante destacar -  y no me voy a cansar de hacerlo – que pese a que el tipo del parámetro del método GuardarEmpleado es empleado y el tipo que se le envía es empleado contratista, el método funciona sin problema; ya que como comenté antes se esta utilizando polimorfismo, lo cual es algo que siempre deberíamos considerar a la hora de crear aplicaciones.


Por último procedemos a ejecutar la pantalla para agregar nuevos contratistas.


image


Luego de ingresar el nuevo contratista, así aparece en nuestro Grid el cuál fue creado en el post anterior.


image


Un punto a destacar, es que si hacemos el query a la tabla de la base de datos, nos damos cuenta que el campo tipo empleado se lleno de forma automática por medio del EntityFramework, el cual utilizó la regla de mapeo creada en el capítulo 6 para hacer la inserción. En la siguiente figura se ve como al empleado Ernesto se le agrega como tipo “Contratista”.


image


Como podemos ver en este ejemplo, la herencia y sobre todo el polimorfismo son conceptos que debemos utilizar a la hora de crear nuestras aplicaciones, ya que esto le dará posibilidad de crecer sin necesidad de restructurar; ya que por ejemplo ahora al método AgregarEmpleado se le puede pasar cualquier entidad que herede de empleado sin necesidad de reescribir el código y recompilar.