5.06.2009

El Entity Framework en una Arquitectura n-layer – Parte 4

En el post anterior iniciamos el desarrollo de la capa de UI utilizando WPF como tecnología. En este post vamos a continuar agregando funcionalidad al UI del sistema que estamos desarrollando.

En esta oportunidad, vamos a agregar una pantalla para ver todos los usuarios que hemos insertado dentro de la aplicación.

Creando la Pantalla de Administración de Usuarios

El primer paso es crear una nueva pantalla en el proyecto y llamarla AdministracionDeUsuarios. Esta pantalla va a tener un grid el cual nos va a presentar todos los usuarios que existen en nuestra aplicación. El grid que vamos a utilizar es el DataGrid del toolkit de WPF. A este datagrid le vamos a llamar dgUsuarios. Una vez creada la pantalla esta lucirá de la siguiente forma:

image

El siguiente paso es llenar el datagrid con los datos de usuarios que tenemos incluidos en nuestra base de datos. Para lograr esto vamos a utilizar el método ObtenerUsuarios de nuestra clase de lógica de negocios para el usuario. El código para llevar a cabo esta tarea es el que se presenta a continuación:

using System.Windows;
using LogicaDeNegocios;

namespace Cliente_WPF
{
public partial class AdministracionDeUsuarios : Window
{
public AdministracionDeUsuarios( )
{
InitializeComponent( );
}

private void Window_Loaded( object sender, RoutedEventArgs e )
{
UsuarioBL usuarioBL = new UsuarioBL( );
dgUSuarios.ItemsSource = usuarioBL.ObtenerUsuarios( );

}
}
}



Como se puede ver en el código anterior, solamente necesitamos crear una instancia de la clase UsuarioBL y ligar el datagrid con los datos que nos retorna el método ObtenerUsuarios el cual definimos en el post 2 de esta serie. Si ejecutamos la aplicación poniendo como forma de arranque la forma recién creada el resultado será el siguiente:



image



Como podemos ver en la imagen anterior, no solo se presentan los datos propios de la entidad en el grid, si no las relaciones existentes entre el usuario y el historial de casos de uso, el estado de la entidad que es utilizado para persistir cambios en el back end, y la llave de la entidad.



En el próximo post vamos a trabajar mejorando la presentación de este datagrid.



Technorati Tags: ,,,

5.04.2009

El Entity Framework en una Arquitectura n-layer – Parte 3

En los posts anteriores creamos la capa para la lógica de negocios y la capa de acceso a datos utilizando el entity framework. En este post, vamos a crear la capa de presentación de la aplicación de ejemplo utilizando WPF.

El primer paso es crear un nuevo proyecto dentro de la solución en la cual hemos venido trabajando. El proyecto a crear es una aplicación WPF.

image

Seguidamente, eliminamos la forma que se crea por defecto, y creamos una nueva pantalla. En este caso, vamos a crear una pantalla para agregar un usuario. Como podemos ver en el primer post, un usuario tiene básicamente los siguiente campos:

  • Id
  • Nombre
  • Apellido1
  • Apellido2
  • Email
  • Activo.

De estos campos, el Id es autogenerado y el campo de activo es para borrado lógico por lo que en la inserción por defecto, el campo se guarda con un valor de “Y”.

La pantalla que vamos a crear por lo tanto deberá lucir como se ve en la siguiente figura:

image Seguidamente vamos a agregar el código necesario para agregar la entidad ingresada en la forma, pero antes de esto, debemos agregar una referencia a la capa de lógica de negocios y a la capa de acceso a datos. A esta última la tenemos que agregar por que las entidades son el “medio de transporte” entre las capas, y como no tenemos una capa de entidades separada, entonces tenemos que agregarla desde la capa de acceso a datos. Además se debe de agregar una referencia a la librería System.Data.Entity. El código lucirá de la siguiente forma:

using System.Windows;
using CapaDeAccesoADatos;
using LogicaDeNegocios;

namespace Cliente_WPF
{
public partial class DetalleUsuario
{
public DetalleUsuario( )
{
InitializeComponent( );
}
private void btnOk_Click( object sender, RoutedEventArgs e )
{
Usuario usuario = new Usuario( );
usuario.Nombre = txtNombre.Text;
usuario.Apellido1 = txtApellido1.Text;
usuario.Apellido2 = txtApellido2.Text;
usuario.Email = txtEmail.Text;
usuario.Activo = "Y";
UsuarioBL usuarioBL = new UsuarioBL( );
usuarioBL.AgregarUsuario(usuario);

}
}
}



Como podemos ver, lo único que hacemos es crear una entidad, crear una instancia de la clase usuario de la lógica de negocios e invocar el método agregar usuario pasando de parámetro la entidad del usuario recién creada. Este código, además de simple, es sencillo de mantener y permite que todos los desarrolladores que estén trabajando en el proyecto, tengan un estilo similar para programar, lo que facilita el hecho de que una persona no este disponible para modificar o agregar funcionalidad a una pantalla.



Si ejecutamos la pantalla anterior, veremos la siguiente pantalla en ejecución:



image



Si ingresamos datos, y le damos ok, vamos a recibir el siguiente error de parte del entity framework:




The specified named connection is either not found in the configuration, not intended to be used with the EntityClient provider, or not valid.




Esto quiere decir que el entity framework no esta encontrando el conection string para pegarse a la base de datos. Este connection string se encuentra en el archivo app.config de la librería de acceso a datos; pero en este caso, como no tenemos configurada la salida de todos los proyectos al mismo directorio – algo de lo que vamos a ir conversando en post posteriores – entonces la aplicación no lo logra localizar. Para solucionar este problema de forma rápida – y temporal -  debemos simplemente agregar un archivo app.config al proyecto del cliente WPF y copiar el connection string desde el app.config de la capa de acceso a datos.



El primer paso es agregar el archivo config al cliente de WPF.



image



Seguidamente copiamos desde el archivo app.config de la capa de acceso a datos, el string de conexión al archivo recién creado



<connectionStrings>
<
add name="UseCasesEntities" connectionString="metadata=res://*/UseCasesModel.csdl|res://*/UseCasesModel.ssdl|res://*/UseCasesModel.msl;provider=System.Data.SqlClient;provider connection string=&quot;Data Source=diego-pc\sqlserver2008;Initial Catalog=UseCases;Integrated Security=True;MultipleActiveResultSets=True&quot;" providerName="System.Data.EntityClient" />
</
connectionStrings>


Seguidamente, procedemos a ejecutar la aplicación y a insertar los usuarios que vayamos a necesitar.



En el siguiente post, vamos a crear una pantalla para que se nos muestre a través de el DataGrid del toolkit de WPF, todos los usuarios ingresado en la base de datos.



Technorati Tags: ,,,

4.26.2009

El Entity Framework en una Arquitectura n-layer – Parte 2

En el post anterior, iniciamos el desarrollo de una aplicacion n-layer utilizando en Entity Framework. En el post mencionado definimos y construimos la capa de acceso a datos la cual esta compuesta principalmente por el Entity Framework – aunque como veremos en futuros post, esta capa se va a extender con clases que le agrega funcionalidad el Entity Framework. En este post vamos a construir la capa de lógica de negocios para la aplicación que estamos desarrollando.

La capa de negocios es la capa en la cual vamos a crear los métodos unitarios que llevan a cabo las tareas correspondiente de cada una de las entidades. Estas tareas incluyen desde las operaciones CRUD – create, retrieve, update, delete – hasta procesos de negocios más elaborados.

Para crear esta capa de negocios, vamos a crear una librería utilizando los mismos pasos que hicimos en el post anterior, pero vamos a llamar la libreria como LogicaDeNegocios.

image Al igual que hicimos en la librería de la capa de acceso a datos, vamos a eliminar la clase que es creada por defecto cuando creamos el componente. La solución ahora debería lucir así:

image Seguidamente vamos a crear las clases de lógica de negocios para poder llevar a cabo operaciones que se requieran para cada entidad. En este caso, vamos a crear la clase de lógica de negocios para la entidad Usuario. Para crear esta clase, le damos click derecho sobre el proyecto de lógica de negocios y seleccionamos agregar nuevo ítem –> Agregar Clase. En el diálogo de agregar clase escribimos UsuarioBL como nombre de la clase, para poder identificar la clase de lógica de negocio para el usuario en las capas de presentación que vayamos a crear o incluso en la capa de servicios si deseamos crear una para permitir que nuestra funcionalidad de negocios se pueda acceder a través de servicios.

image El siguiente paso es agregar una referencia a la capa de acceso a datos para así poder tener visibilidad de las operaciones existentes dentro del modelo de entidades creado en esa librería. Para lograr esto, le damos click derecho al proyecto de lógica de negocios y seleccionamos la opción agregar referencia del menu contextual. En el dialogo de agregar referencias seleccionamos la cejilla de proyectos y escojemos el proyecto para capa de acceso a datos.

image La referencia debe poder verse en la carpeta de referencias del proyecto como se muestra a continuación.

imageUna vez agregada la referencia, procedemos a agregar el uso de la librería en la clase recién creada. Esto se logra a través de la instrucción using, seguidamente creamos una propiedad automática para tener acceso al modelo de entitdades que creamos anteriormente en la capa de acceso a datos.

imageComo se puede ver en la figura anterior, es requerido agregar la librería System.Data.Entities para poder hacer uso de las entidades presentes en la capa de acceso a datos. En post posteriores vamos a analizar con un poco más de profundidad el entity framework y estos detalles. Para agregar esta librería seguimos el mismo proceso que llevamos a cabo anteriormente para agregar la referencia a la capa de acceso a datos, solo que esta vez vamos a buscar la librería en la cejilla de .NET.

image Una vez agregada esta referencia, la clase actual para manejar la lógica de de negocios del usuario ya compila.

image

Un aspecto a destacar, es que agregamos una propiedad dinámica para tener acceso al modelo de entidades que acabamos de agregar desde la capa de acceso a datos, y además instanciamos el modelo de entidades generado desde el constructor de la clase. Este comportamiento puede no ser el deseado ya que puede producirnos trabajo extra a la hora de agregar relaciones que se obtienen desde otras clases de lógica de negocios por que cada clase va a venir de diferentes instancias del modelo, es decir desde diferentes contextos. En el post de como extender y mejorar el EF en una arquitectura n-layer vamos a ver cuales pueden ser las posibles soluciones para manejar estos casos.

Seguidamente procedemos a crear los métodos principales de CRUD en la lógica de negocios. Primeramente vamos a crear el método para agregar un usuario.Este método recibe una entidad del tipo Usuario, y la agrega al contexto instanciado utilizando el método generado AddToUsuario. Finalmente, procedemos a persistir los cambios en la base de datos utilizando el metodo SaveChanges.

image En muchas ocasiones surge la pregunta, ¿por qué recibir un usuario y no los campos para agregar a la entidad? La respuesta esta relacionada con la adaptabilidad al cambio de parte de la aplicación. Puede ser que en un futuro se requiera quitar o agregar campos a la entidad usuario; si estamos utilizando lo campos en lugar de una entidad, vamos a tener que modificar todos los métodos donde interactuamos con la entidad para modificar, actualizar, seleccionar, etc. Sin embargo, si utilizamos una entidad, los puntos que varían son la entidad, el UI en donde construimos la entidad y la capa de acceso a datos donde agregamos los campos al repositorios – si estamos usando el EF, no se requieren cambios en la capa de acceso a datos ya que el EF actualiza los métodos desde el modelo – con lo que nuestra aplicación es más fácil para modificar.

Seguidamente procedemos a crear los métodos necesarios para obtener todos los usuarios que existen en la base de datos, y el método que me retorna un usuario en específico.

Inicialmente agregamos la referencia a la librería System.Linq, esto para tener acceso a los métodos de extensión

using System.Collections.Generic;
using CapaDeAccesoADatos;
using System.Linq;


Seguidamente creamos los métodos mencionados anteriormente. En este caso vamos a utilizar la sintaxis del EF para acceder a los datos. En post posteriores vamos a utilizar LinqToEntities para llevar a cabo las mismas tareas.



public List<Usuario> ObtenerUsuarios( )
{
var usuarios = ModeloEntidades.Usuario;
return usuarios.ToList( );
}

public Usuario ObtenerUsuario( int id )
{
var usuario = ModeloEntidades.Usuario.Where(u => u.Id == id).FirstOrDefault( );
return usuario;
}



Con estos métodos ya tenemos un conjunto de funcionalidad suficiente para poder trabajar con nuestra capa de UI. Digo suficiente por que por supuesto faltan los métodos para actualizar y borrar usuarios, además los correspondientes métodos para asociar los usuarios a las entidades correspondientes. Estos métodos los vamos a agregar en futuros post.



La solución de la aplicación debe de lucir de la siguiente manera:



image



En el próximo post vamos a crear la capa de UI utilizando WPF.



Technorati Tags: ,,

4.19.2009

El Entity Framework en una Arquitectura n-Layer – Parte 1

En el post anterior acerca del Entity Framework en una arquitectura n-layer, describí el rol que juega el EF en una arquitectura n-layer. En este post vamos a crear un ejemplo para mostrar como se plasma en código las ideas expuestas en el post anterior.

En este caso, vamos a trabajar en el desarrollo de una “mini” aplicación que administra los casos de uso de n empresas – al menos desarrollar un poquito de funcionalidad de la aplicación para ilustrar los conceptos expuestos.

La Base de Datos

El primer paso es crear una base de datos para persistir la información de los proyectos. Vamos a crear una base de datos utilizando SQLServer2008. Esta base de datos se llamará UseCases. El diagrama inicial de la base de datos es el siguiente.

image

En este caso, vamos a decir que una empresa puede tener varios proyectos, y que cada proyecto tiene muchos casos de uso. Cada caso de uso tiene un historial de acciones que se graba cada vez que se realiza un cambio en el caso de uso ( esto suponiendo una base de datos completa, en donde se guardan los diferentes flujos del caso de uso, sus actores, etc). Por último, cada registro del historial de cambios tiene un usuario asociado que es precisamente el que realizó el cambio.

Desarrollando la Solución

Para el desarrollo de la solución vamos a utilizar Visual Studio 2008 SP1. El primer paso es crear una solución vacía para ir agregando los diversos proyectos que vamos a ir requiriendo en el desarollo de la aplicación. Para crear una solución vacía seleccionamos: new project –> visual studio solutions –> Blank Solution.

image

Creando la capa de Acceso a Datos

Una vez que tenemos la solución, vamos a crear la capa de acceso a datos ( que por lo general es el primer bloque que se crea cuando se realiza un proyecto con arquitectura n-layer). Para agregar el proyecto, seleccionamos con el botón derecho del mouse la solución recién creada y seleccionamos del menú contextual agregar nuevo proyecto.

imageCuando aparece la opción de seleccionar el tipo de proyecto deseado seleccionamos la opción de class library en el tipo de proyecto Windows bajo C#. Al proyecto le vamos a poner de nombre CapaDeAccesoADatos.

image Después de creada la capa de acceso a datos – al menos el proyecto – procedemos a agregar el modelo del entitiy framework. Debemos recordar, que en el post anterior mencioado al principio de este post, indicabamos que el EF sustituye a la capa de acceso a datos. Por esta razón en este componente de acceso a datos, solamente vamos a tener el modelo generado por el EF; en post posteriores vamos a extender el EF con clases adicionales que se agregarán a esta librería.

Para crear un modelo de entitidades le damos clic y botón derecho al proyecto recién creado y seleccionamos agregar nuevo ítem.

image En el diálogo de seleccionar ítem escojemos la opción ADO.NET Entity Model. Le vamos a llamar UseCasesModel.

image Cuando inicia el “wizard” del EF en el primer paso seleccionamos la opción generar desde base de datos. Seguidamente creamos una nueva conexión a la base de datos que recién acabamos de crear; le decimos además al wizard que agregue el string de conexión al archivo app.config con el nombre UseCasesEntities.

image Seleccionamos Next y procedemos a seleccionar las tablas que vamos a utilizar en nuestro modelo. En este caso, vamos a mapear en el modelo, todas las tablas creadas en el diseño de la base de datos hecha en SQLServer.

image El modelo generado es el siguiente

image Podríamos caer en la tentanción de pensar que lo único que el EF hace es mapear las tablas en clases y ponerlas a nuestra disposición para las tareas tradicionales que llevamos normalmente a cabo en una base de datos tales como el CRUD. Pero si vemos el modelo generado con atención, podemos ver que han sucedido cosas interesantes gracias a la forma en que ser tratan las relaciones entre objetos y entre tablas. Tal vez el cambio que esta más a la vista, es que los campos que manejan las llaves foráneas en la base de datos, fueron sustituidas por objetos de navegación. Esto nos permite una mayor flexibilidad ya que podemos navegar en ambas direcciones en la tabla, y el EF se encarga de administrar las relaciones a nivel de tablas.

En el paso que estamos, la solución debería lucir de la siguiente manera:

image En este momento solo tenemos una librería – dll – que va a convertirse en mi capa de acceso a datos. En el próximo post, vamos a desarrollar la capa de lógica de negocios.

Technorati Tags: ,

4.11.2009

¿Qué es un ESB – Enterprise Service Bus?

Cuando se habla de arquitecturas orientadas a servicios, se habla intrínsicamente de los componentes necesarios para tener una arquitectura SOA. Sin duda alguna, uno de los componentes más importantes de una arquitectura orientada a servicios es el Enterprise Service Bus - ESB.

Conforme las organizaciones van moviéndose hacia las arquitecturas orientadas a servicios, se dan cuenta que están trabajando con un “mix” entre lo nuevo y lo viejo. Un ESB es básicamente la integración de lo nuevo y lo viejo, brindándo un lugar central para los servicios, las aplicaciones, y recursos de TI en general que se desean conectar. En otras palabras, lo que se busca es una infraestructura y un sistema de eventos que me permitan conectar cualquier recurso de TI sin importar la tecnología que utiliza el recurso. Esta infraestructura debería permitir administrar los cambios en los requerimientos sin causar problemas a los servicios ya instalados. Esta infraestructura debe de ser confiable y robusta. Aquí es donde entra el concepto de ESB.

Un ESB no solamente permite combinar y re ensamblar servicios, sino que también debe permitir conectar nuevas aplicaciones, servicios web y cualquier otro tipo de aplicaciones tales como aplicaciones LOB ( Line of Business ), archivos batch, legacy middleware a través de adaptadores; todo esto manteniendo la abstracción del manejo de mensajes a través del patrón publicar-suscribir.

Siendo más concretos, podemos decir que un ESB ofrece las siguientes funcionalidades:

  • Transparencia de Ubicación: El ESB ayuda a desligar el consumidor del servicio de la ubicación del proveedor del servicio. El ESB provee una plataforma central para comunicarse con cualquier aplicación requerida sin ligar el recibidor del mensaje con el que envía el mensaje.
  • Conversión de Protocolo de Transporte: Un ESB debe de tener la capacidad de integrar de forma transparente a través de diferentes protocolos de transporte tales como HTTP(s), JMS, FTP, SMTP, TCP, etc.
  • Transformación de Mensaje: El ESB brinda funcionalidad para transformar mensajes desde un formato hasta otro formato basado en estándares tales como XSLT y XPath.
  • Ruteo de Mensajes: El ESB determina el destino de los mensajes entrantes.
  • Mejora del Mensaje: El ESB puede brindar funcionalidad para agregar información faltante basado en los datos del mensaje de entrada.
  • Seguridad: Autenticación, autorización, y funcionalidad de encriptación se proveen a través del ESB para asegurar los mensajes entrantes. Igualmente estas funcionalidades se aplican a mensajes salientes para satisfacer requerimientos de seguridad del proveedor del servicio a consumir.
  • Monitoreo y Administración: Un ambiente de monitoreo y administración del ESB es fundamental para configurar el ESB para que sea confiable y tenga un alto desempeño; al mismo tiempo, nos permite monitorear la ejecución de los mensajes y su flujo dentro del ESB.

La siguiente figura nos muestra un “big picture” de lo que es un ESB.

image

Dadas estas funcionalidades de un ESB, ¿cuándo necesito utilizar un ESB?

Conforme las organizaciones van adoptando servicios, se va creando la necesidad de una arquitectura orientada a servicios. Hay una gran diferencia entre el uso casual de servicios y llevar la organización a correr sobre servicios. Conforme se avanza hacia una arquitectura orientada a servicios, van a surgir muchos contratiempos, entre los cuales podemos enumerar como manejar una gran cantidad de servicios de una manera adecuada evitando la duplicación de funcionalidad, como medir y forzar los SLA´s –Service Level Agreement –, como forzar politicas organizacionales dentro de la colección de servicios que se tiene y a la cual se le van agregando servicios.

Además, en el mundo Microsoft existe WCF, el cual es un framework excelente para comunicaciones distribuidas, pero es solo eso, un framework.

Normalmente, cuando se empiezan a tener una cantidad de servicios que deja de ser pequeña y más bien podríamos considerarla de mediana a grande, se empiezan a tener problemas que no se tenían cuando solamente se manejaban un grupo pequeño de servicios. Entre los problemas que se dan más comúnmente podemos enumerar proliferación de servicios por toda la organización sin control, los cuales utilizan diferentes protocolos y tecnologías para su desarrollo e implementación. No hay governance, las configuraciones no son estándar, no hay versionamiento de servicios, etc. Cuando se empiezan a tener este tipo de problemas, y la organización empieza a dar un paso más serio hacia el uso de servicios como plataforma para sus aplicaciones, se empieza a necesitar más y más una arquitectura orientada a servicios.

3.15.2009

Como agregar un binding TCP de forma programada a un sitio web en IIS 7.0

La información del binding en un sitio web es indispensable para indicar cuales protocolos pueden ser utilizados para comunicarse con el sitio Web. En el contexto de WCF esto significa, que tipos de protocolos vamos a poder utilizar para consumir los servicios desarrollados en WCF y hosteados en IIS 7.0 y WAS.

En días pasados conversando con algunas personas que usan IIS 7.0 para hostear servicios en WAS utilizando el protocolo TCP, me preguntaron como agregar el binding de TCP a un sitio web utilizando el API de IIS 7.0 y C#. La consulta me pareció muy útil por que permite crear instaladores que hagan deploy de los servicios de forma transparente, incluso creando sus sitios webs a la hora de la instalación y agregando el binding deseado con este instalador. Aquí esta la solución a esta consulta.

Primeramente, vamos ver que es lo que necesitamos para tener el protocolo TCP habilitado en el sitio web. Para esto, en el archvio applicationHost.config  existe la sección bindings la cual existe por sitio web definido y tiene el siguiente formato:

<bindings>
    <binding protocol="http" bindingInformation="*:80:" />
    <binding protocol="net.tcp" bindingInformation="808:*" />
    <binding protocol="net.pipe" bindingInformation="*" />
    <binding protocol="net.msmq" bindingInformation="localhost" />
    <binding protocol="msmq.formatname" bindingInformation="localhost" />
</bindings>

Como podemos ver en el elemento XML anterior, existe una etiqueta binding para cada protocolo que queremos soportar en el sitio web. Además, cada elemento tiene dos atributos: protocol y bindginInformation. El protocolo define el protocolo que se utiliza para comunicarse con el sitio web, y el bindingInformation contiene la dirección IP, el número del puerto y opcionalmente el host header para el sitio web.

Para poder agregar TCP al sitio web deseado debemos primeramente buscar el elemento que contiene los sitios web en el archivo de configuración del servidor, seguidamente buscamos el sitio web deseado, y procedemos a agregarle el binding. El código para esta operación es el siguiente:

public static void AgregarBindiingASitioWeb( string nombreSitioWeb, string protocolo, string bindingInformation )
{
using (ServerManager server = new ServerManager( ))
{
Configuration hostConfiguration = server.GetApplicationHostConfiguration( );
ConfigurationSection sitesSection = hostConfiguration.GetSection("system.applicationHost/sites"); //utilizamos XPath para obtener el elemento
ConfigurationElementCollection sitesCollection = sitesSection.GetCollection( ); //Obtenemos todos los sitios web en el archivo
//Buscamos el sitio web deseado
ConfigurationElement siteElement = FindElement(sitesCollection, "site", "name", @nombreSitioWeb);
//Si no existe, lanzamos una excepción y abortamos el método.
if (siteElement == null) throw new InvalidOperationException("Sitio no encontrado!");
//Obtenemos la configuración del binding del sitio web
ConfigurationElementCollection bindingsCollection = siteElement.GetCollection("bindings");
//Creamos un elemento de binding para el sitio y le establecemos los valores deseados
ConfigurationElement bindingElement = bindingsCollection.CreateElement("binding");
bindingElement["protocol"] = @protocolo;
bindingElement["bindingInformation"] = @bindingInformation;
//Agregamos el binding a la colección de bindings del sitio web
bindingsCollection.Add(bindingElement);
//Guardamos los cambios en el archivo applicationHost.config
server.CommitChanges( );
}
}


private static ConfigurationElement FindElement( ConfigurationElementCollection collection, string elementTagName, params string[] keyValues )
{
//Iteramos sobre la coleccion de elementos para buscar la etiqueta site que tenga en el atributo
//name el valor pasado por parámetro
foreach (ConfigurationElement element in collection)
{
//Si el elemento encontrado es el sitio
if (String.Equals(element.ElementTagName, elementTagName, StringComparison.OrdinalIgnoreCase))
{
bool matches = true;
//Entonces buscamos el atributo deseado
for (int i = 0; i < keyValues.Length; i += 2)
{
object o = element.GetAttributeValue(keyValues[i]);
string value = null;
if (o != null)
{
value = o.ToString( );
}
if (!String.Equals(value, keyValues[i + 1], StringComparison.OrdinalIgnoreCase))
{
matches = false;
break;
}
}
if (matches)
{
return element;
}
}
}
return null;
}


El código para llamar al método de crear binding es:



AgregarBindiingASitioWeb("MiNuevositioWeb", "net.tcp", "808:*");



Antes de ejecutar el código anterior, el elemento Site de MiNuevoSitioWeb lucía así:



image Después de ejecutar el código anterior el resultado es:



imageComo podemos ver en la figura anterior, el binding para TCP se agregó al elemento del sitio web solicitado.

3.08.2009

Eclipse y Silverlight

Normalmente, cuando pensamos en silverlight pensamos en .NET. Resulta ser, que una empresa francesa en conjunto con Microsoft, desarrolló un plug in para Eclipse que permite desarrollar aplicación silverlight utilizando Java.

El articulo que nos muestra que contiene este plug in se puede ver en el sitio de la empresa que desarrolla el plug in. Los pasos para utilizar este plug in con eclipse se pueden ver en el blog de somasegar en el msdn.

También es interesante destacar un producto llamado eFace de esta empresa, que permite desarrollar UI’s utilizando XAML en Java. El link de este producto – el cual tiene una versión gratuita – se puede ver acá.

3.02.2009

Utilizando el API de IIS 7 para crear Web Sites Aplicaciones, Directorios Virtuales y para explorar mi servidor Web desde .NET

En días pasados tuve la necesidad de crear una aplicación que me permitiera llevar a cabo acciones sobre el IIS para poder realizar acciones tales como crear un Sitio Web desde una aplicación desarrollada en C#. Es por eso, que en este post decidí escribir un poco acerca de como llevar a cabo estas tareas utilizando VS 2008, C#, IIS 7.0 y el API manejado para acceder las funcionalidades del IIS – al menos algunas.

El API de IIS 7.0 es una librería localizada en el directorio C:\Windows\System32\inetsrv\ – Asumiendo que la instalación de Windows esta en el disco C – y es un assemblie que se llama Microsoft.Web.Administration.dll. Esta vez, vamos a hacer una aplicación de consola que nos permita realizar un par de tareas contra el IIS.

Una vez creada la aplicación de consola procedemos a agregar una referencia al componente que nos va a exponer la funcionalidad disponible del IIS, es decir, el Microsoft.Web.Administration.dll. La siguiente figura nos muestra la referencia agregada al proyecto de ejemplo.

image

Una vez agregada esta referencia, procedemos agregar la referencia a la libreria para poder utilizarla en nuestra aplicación tal y como se muestra en el siguiente código:

using System;
using Microsoft.Web.Administration;



Luego a agregar funcionalidad a nuestra aplicacion para acceder al IIS 7.0. Lo primero que vamos a hacer es desplegar la lista de sitios web que han sido creados en el IIS con el que vamos a interactuar, en este caso, el servidor Web local. El código para llevar a cabo este procedimiento es el siguiente.



static void Main( string[] args )
{
ListarSitiosWeb( );
}

private static void ListarSitiosWeb( )
{
using (ServerManager server = new ServerManager( ))
{
foreach (Site site in server.Sites)
{
Console.WriteLine("Sitio Web:{0}", site.Name);
}
}
}



Como se ve en el código anterior, lo primero que debemos hacer es crear una instancia de la clase ServerManager, la cual representa el servidor Web instalado en mi máquina. Seguidamente, para imprimir el nombre de los sitios web creados en el servidor Web simplemente recorro la colección de Sites presente en mi servidor web. La salida de este código es:



image





Para crear un Sitio web desde mi aplicación en .NET utilizo el siguiente código.



/// <summary>
///
Permite crear un web site utilizando el API de IIS 7
/// </summary>
/// <param name="siteName">
El nombre del sitio web</param>
public static void CreateSite( string siteName )
{
try
{
using (ServerManager mgr = new ServerManager( ))
{
Site newSite = mgr.Sites.CreateElement( );
newSite.Id = DateTime.Now.Second;
newSite.SetAttributeValue("name", siteName);
mgr.Sites.Add(newSite);
mgr.CommitChanges( );
}
}
catch (Exception ex)
{
Console.WriteLine("Error: {0}", ex.ToString( ));
}
}


Este código permite crear un sitio web con el nombre que viene por parámetro – siteName – y con un Id obtenido del segundo en que fue creado el sitio web. Seguidamente agregamos el sitio a la colección de sitios del IIS, y le damos CommitChanges para refrescar el sitio web.



Otra funcionalidad con la que tenemos que trabajar cuando creamos es crear una Aplicación. Una aplicación en IIS es un agrupamiento de contenido en un sitio Web. Estas aplicaciones tienen una ruta física para el contenido y propiedades que son específicas al contenido indicado. Para crear una aplicación en el sitio web antes creado agregamos el siguiente código.



private static void AgregarAplicacion( string sitioWeb )
{
try
{
using (ServerManager server = new ServerManager( ))
{
server.Sites[sitioWeb].Applications.Add("/", @"C:\Proyectos\MiSitio");
server.CommitChanges( );
}
}
catch (Exception ex)
{
Console.WriteLine("Error creando aplicación {0}: {1}", sitioWeb, ex.ToString( ));
}
}



En este código, el método Add de la colección de aplicaciones del sitio web recibe dos parámetros, el primero es la ruta dentro del servidor web donde se va a administrar el contenido – en este caso en el directorio raíz del sitio web - , y el segundo parámetro que indica la ubicación física del contenido.



Por último, le vamos a agregar un directorio virtual a la aplicación que acabamos de crear.



public static void AgregarDirectorioVirtual( string nombreSitioWeb, string aplicacion )
{
using (ServerManager server = new ServerManager( ))
{
Site sitioWeb = server.Sites[nombreSitioWeb];
Application app = sitioWeb.Applications[aplicacion];
app.VirtualDirectories.Add("/ASPX", @"C:\Proyectos\MiSitio");
server.CommitChanges( );
}
}


Este código agregar un directorio virtual llamado ASPX, en la ruta física C:\Proyectos\MiSitio, por lo tanto va a estar mapeado a esta dirección física.

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