5.20.2009

Alternativas para Iniciar con una Arquitectura Orientada a Servicios - SOA

Cuando en una empresa se habla de establecer una arquitectura orientada a servicios surgen muchas dudas respecto a como implementar este tipo de arquitectura. Una de las primeras preguntas que me hacen dentro de la organización cuando llego a ayudar en este tipo de tareas es:

Pero si al prinicipio vamos a tener unos cuantos servicios, por que tenemos que comprar un ESB, que por lo general cuesta mucho dinero.

Efectivamente, una de las principales limitantes a la hora de implementar una arquitectura orientada a servicios – aparte de las limitaciones técnicas – es la compra del software requerido para poder iniciar en SOA.

Normalmente, las empresas empiezan teniendo unos pocos servicios Web, los cuales brindan información ya sea a lo interno o a lo externo; estos servicios se hostean en el IIS. Aunque suene tentador, el hecho de tener solamente servicios web que son consumidos por clientes internos y externos, no implica que tengamos una arquitectura SOA; en realidad estamos creando una arquitectura punto a punto, en donde los clientes consumen directamente los servicios expuestos y quedan totalmente dependientes de la configuración de estos servicios; ya que por ejemplo, si cambian el servidor donde se hostean estos servicios, los clientes tienen que ser actualizados o no funcionarán del todo.

Ahora, conforme crecen la cantidad de servicios que estamos utilizando, empieza a crearse la necesidad de darles seguimiento, de tener un inventario para saber cuales servicios tengo disponibles y puedo reutilizar, de tener métricas de los servicios para poder medir mis SLAs con otros clientes, y muchas otras características típicas de una arquitectura SOA las cuáles nos indican que es hora de ir pensando en un ESB – ver el post de ESB para entender más a fondo que es un ESB – La pregunta que surge es ¿ Cuando debo migrar a un ESB ? ¿por que tengo que pasar de un modelo donde solo tengo que preocuparme por el IIS a un modelo donde tengo que tener otro servidor y debo comprar Biztalk Server y agregarle el ESB guidance? ¿ Por qué no existe un paso intermedio entre ambos, que me de el Governance necesario para poder iniciar con mi arquitectura SOA para poder demostrarle a la gerencia los beneficios de esta arquitectura?

Estas preguntas son totalmente válidas y aplican practicamente en cualquier tecnología sobre la cual estemos interesados en “montar” una arquitectura orientada a servicios. En general cuando me hacen este tipo de preguntas, me pregunto por que no existe un contenedor liviano para ese tipo de soluciones.

Pues resulta que ahora, el equipo de Microsoft Services SOA Solution Team ha creado un producto que viene a llenar ese vacío. Este producto es algo así como el paso intermedio entre la arquitectura punto a punto y la arquitectura SOA en toda su expresión, utilizando un ESB, orquestando servicios y todos los demás beneficios que vienen con una arquitectura orientada a servicios – bien aplicada. Esta herramienta esta en versión CTP y se llama el Microsoft Service Engine – MSE. Esta herramienta es una herramienta para facilitar la adopción de SOA en la empresa, todo a través de algo que se conoce como virutalización de servicios. El MSE esta construida sobre WCF y la plataforma de Windows Server. Se integra de forma natural con Biztalk y el ESB Guidance para cuando en etapas posteriores se desea aumentar la capacidad de governance, ruteo, transformación, etc.

El siguiente screen shot es una muestra de este tool.

MSE SOA

Este tool tiene otras 2 ventajas externas a lo técnico: Es Open source y es gratis. El sitio web donde se puede obtener información al respecto esta aquí en codeplex.

En post posteriores voy a profundizar acerca de las funcionalidades de esta herramienta, como configurarlo y como ponerlo a funcionar para poder adoptar una arquitectura SOA dentro de nuestras organizaciones.

Technorati Tags: ,,,

5.14.2009

Personalizando el DataGrid del WPF ToolKit

En el post pasado, creamos una interface gráfica para exponer todos los usuarios que están registrados en nuestro sistema de ejemplo. Esta pantalla estaba compuesta por un grid que mostraba esta información. El grid utilizado, es el grid del WPF Toolkit, el cuál contiene un conjunto de controles sumamente útiles que podemos utilizar de forma gratuita en nuestras aplicaciones desarrolladas con WPF.

En este post vamos a modificar esta pantalla para que el datagrid solo nos muestre los datos relevantes y no todo lo que nos devuelve el objeto desde la entidad proveniente desde el EF. Además vamos cambiar la forma en que luce el grid modificando sus propiedades visuales desde el código XAML.

La ventana en el post anterior lucía de la siguiente manera:

image

El primer cambio que le vamos a hacer al datagrid es mostrar solamente las columnas que le interesan al usuario de la aplicación, por lo tanto en este caso vamos a eliminar las columnas relacionadas con EF, tales como las relaciones y el EntityState, además vamos a eliminar la columna de borrado lógico Activo. Para lograr esto primeramente debemos poner la propiedad AutoGenerateColumns en falso.

<my:DataGrid Margin="12,51,21,27" Name="dgUSuarios" AutoGenerateColumns="False">


Seguidamente tenemos que definir las columnas que deseamos ligar al grid desde el resultado del método de consulta creado en la lógica de negocios. Esto se logra indicandole a la propiedad Binding a cual propiedad de la entidad devuelta debe de ligarse, tal y como lo muestra el siguiente código:



<my:DataGrid.Columns>
<
my:DataGridTextColumn Header="Id" Binding="{Binding Id}" IsReadOnly="True" />
<
my:DataGridTextColumn Header="Nombre" Binding="{Binding Nombre}" IsReadOnly="True" />
<
my:DataGridTextColumn Header="Primer Apellido" Binding="{Binding Apellido1}" IsReadOnly="True" />
<
my:DataGridTextColumn Header="Segundo Apellido" Binding="{Binding Apellido2}" IsReadOnly="True" />
<
my:DataGridTextColumn Header="Correo Electrónico" Binding="{Binding Email}" IsReadOnly="True" />
</
my:DataGrid.Columns>


Ahora vamos a pintar cada una de las filas con un color alternativo, en este caso, una fila de un color verde en gradiente y la siguiente de un color verde sin gradiente. El código XAML para lograr esto es el siguiente:



<my:DataGrid Margin="12,51,21,27" Name="dgUSuarios" AutoGenerateColumns="False" 
RowBackground="#FF70947A" AlternatingRowBackground="{StaticResource GradienteVerde}">


El gradiente verdes esta en los recursos del grid, es decir en el <Grid.Resources> y su contenido es el siguiente:



<LinearGradientBrush x:Key="GradienteVerde" EndPoint="1,0.5" StartPoint="0,0.5">
<
GradientStop Color="#FF227D2C" Offset="0"/>
<
GradientStop Color="#FF046B0E" Offset="1"/>
</
LinearGradientBrush>



La pantalla debe de lucir de la siguiente manera:



image Por último vamos a cambiarle el estilo al header del grid. El primer paso para lograr esto, es crear un estilo para poder asignarselo al grid. El estilo a utilizar lo vamos a definir en el archivo app.xml en la seccion de recursos de la aplicación.



<Application.Resources>
<
LinearGradientBrush x:Key="GridBackGround" EndPoint="1,0.5" StartPoint="0,0.5">
<
GradientStop Color="#FF000000" Offset="0"/>
<
GradientStop Color="#FF121111" Offset="1"/>
<
GradientStop Color="#FF605D5D" Offset="0.50"/>
</
LinearGradientBrush>
<
Style x:Key="HeaderStyle" TargetType="{x:Type Primitives:DataGridColumnHeader}">
<
Setter Property="VerticalContentAlignment" Value="Center" />
<
Setter Property="Background" Value="{StaticResource GridBackGround }" />
<
Setter Property="Foreground" Value="Orange" />
</
Style>
</
Application.Resources>



Como podemos ver en el estilo, las propiedades de background y foreground han sido cambiadas para que el header el background del header se vea de acuerdo al gradiente GridBackGround y el foreground se establece de color naranja.



Seguidamente lo agregamos el estilo al grid.



ColumnHeaderStyle="{StaticResource HeaderStyle}" 


Para lograr esto, establecemos la propiedad ColumnHeaderStyle con el valor del estilo que definimos en el bloque de código anterior.



La pantalla de resultado es la siguiente:



image



Technorati Tags: ,,

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: ,,,