Mostrando entradas con la etiqueta Servidor de Aplicaciones. Mostrar todas las entradas
Mostrando entradas con la etiqueta Servidor de Aplicaciones. Mostrar todas las entradas

6.09.2013

Utilizando un cache distribuido en nuestro middleware – Parte 2

Continuando con el post inicial acerca de un cache en una arquitectura distribuida, vamos a continuar haciendo un ejemplo utilizando el chache distribuido del AppFabric. En este caso, vamos a crear un ejemplo muy simple utilizando un proyecto del tipo aplicación de consola.

Configurar el AppFabric

Para iniciar, tenemos que configurar el cache del AppFabric, esto se logra utilizando el wizard de configuración de la herramienta ya sea cuando se instala el AppFabric, o cuando el usuario lo requiera. En nuestro caso, vamos a configurar el AppFabric utilizando un archivo XML para guardar la configuración del mismo ya que este simplemente nos va a solicitar un UNC para llevar a cabo la misma; si se quiere utilizar SQL Server vamos a tener que tener la maquina perteneciendo a un dominio de Active Directory. La regla en general es si vas  a utilizar el  cache del AppFabric en un solo servidor, deberías utilizar el proveedor de XML, si lo vas a usar en varios deberías usar el proveedor de SQL Server. La siguiente figura nos muestra el cache del appFabric configurado en un servidor local utilizando el proveedor XML.

image

Codificar con el Cache del AppFabric

El siguiente paso es codificar pensando en el Cache del AppFabric. Para esto necesitamos agregar una referencia a la librería 

Microsoft.ApplicationServer.Caching;

Luego de esto, tenemos que ingresar el código para manipular los datos que queremos agregar al cache. Para esto empezamos creando un objeto del tipo DataCache, el cual se conectara a nuestro cache configurado en el AppFabric y nos permitirá almacenar datos en el cache para acceso mas rápido. El siguiente código nos muestra como conectarnos al Cache y como obtenemos el objeto para poder interactuar con el AppFabric.


        private static DataCacheFactory _factory;
private static DataCache _cache;

public static DataCache GetCache()
{
if (_cache != null)
return _cache;


var _servers = new List<DataCacheServerEndpoint>(1) {new DataCacheServerEndpoint("drojasmWin8", 22233)};

var _configuration = new DataCacheFactoryConfiguration
{
Servers = _servers,
LocalCacheProperties = new DataCacheLocalCacheProperties()
};

DataCacheClientLogManager.ChangeLogLevel(System.Diagnostics.TraceLevel.Off);

_configuration.ChannelOpenTimeout = TimeSpan.FromMinutes(1);
_configuration.SecurityProperties = new DataCacheSecurity(DataCacheSecurityMode.None, DataCacheProtectionLevel.None);

_factory = new DataCacheFactory(_configuration);

_cache = _factory.GetCache("default");

return _cache;
}





Luego de configurado el Objeto DataCache, procedemos a programar la interacción con el mismo. Normalmente esta interacción se da a nivel de servicios o de lógica de negocios, desde la cual procedemos a revisar las variables antes de comunicarnos con la capa que nos va a dar los servicios para obtener estos datos. En el siguiente método, podemos ver como invocamos al método anterior GetCache. Luego de esto en la linea 6 le preguntamos al cache si tiene una variable llamada países almacenada, si existe procedemos a obtener los datos del cache, en caso contrario, creamos la lista ( en este caso iríamos a la base de datos o al repositorio respectivo ) y guardamos los datos en el cache para que queden disponibles para consultas posteriores. Es importante destacar que el cache no funciona a nivel de usuario, si no a nivel de capa media, con lo cual muchos usuarios van a obtener sus datos del cache, aunque los datos sean cacheados por otro usuario.

static void Main()
{
var _dataCache = GetCache();
if (_dataCache == null) throw new ArgumentNullException("Cache no inicializado");
const string llave = "Paises";
var _obj = _dataCache[llave];
if (_obj == null)
{
_obj = new List<string> {"China", "Peru", "Ecuador"};
_dataCache[llave] = _obj;
Console.WriteLine("No estaba en el cache");
}
else
{
Console.WriteLine("Si estaba en el cache");
}
}





Este escenario es ideal porque nos permite aumentar las escalabilidad – mas que la velocidad – de nuestras aplicaciones, porque nos estamos ahorrando capacidad de procesamiento a la hora de llevar  cabo las consultas. Respecto al tipo de datos que vamos a poner en el cache, normalmente datos que cambian poco, aunque es posible poner datos que son dinámicos, ya que la invocación del cache debería estar supeditada a los servicios y a la lógica de negocios, con lo cual, cuando alguien inserta, modifica o elimina un dato, puede preguntar si el dato esta en el cache y removerlo del mismo, con lo cual mantendríamos siempre los datos actualizados.


Technorati Tags:

5.08.2013

Webcast de Arquitectura

La serie de web cast acerca de arquitectura de software que finalizaron el mes pasado, está disponible en Channel9. Ahí los pueden ver o bajarlos en el formato de su gusto. Les dejo los links de cada uno de los webcasts:

Webcast 1 – Arquitectura de Software – definición y Evolución

http://channel9.msdn.com/Blogs/DevWow/Visual-Studio-para-Arquitectos-de-Software-1-Definicin-y-Evolucin

Webcast 2 – Arquitectura Distribuida

http://channel9.msdn.com/Blogs/DevWow/Visual-Studio-para-Arquitectos-de-Software-2-Arquitectura-Distribuida

Webcast 3 – Workflows de Negocio en la arquitectura de software

http://channel9.msdn.com/Blogs/DevWow/Visual-Studio-para-Arquitectos-de-Software-3-Los-workflows-de-negocios-en-la-arquitectura-de-softwar

Webcast 4 – Diseño y polimorfismo

http://channel9.msdn.com/Blogs/DevWow/Visual-Studio-para-Arquitectos-de-Software-4-Diseo-y-Polimorfsmo-en-nuestras-aplicaciones-de-softwar

Webcast 5 – Seguridad a nivel de software

http://channel9.msdn.com/Blogs/DevWow/Visual-Studio-para-Arquitectos-de-Software-5-Seguridad-a-nivel-de-software

Webcast 6 – Gobernabilidad

http://channel9.msdn.com/Blogs/DevWow/Visual-Studio-para-Arquitectos-de-Software-6-Gobernabilidad-en-la-Arquitectura-de-Software

Webcast 7 – SOA

http://channel9.msdn.com/Blogs/DevWow/Visual-Studio-para-Arquitectos-de-Software-7-Arquitectura-Orientada-a-Servicios-SOA

Webcast 8 Pruebas Unitarias

http://channel9.msdn.com/Blogs/DevWow/Visual-Studio-para-Arquitectos-de-Software-8-Pruebas-Unitarias

 

11.25.2012

Memorias - Arquitectura de Software: !No necesito un Servidor de Aplicaciones

 

Leyendo por ahí un blog de arquitectura en inglés me encontré con una aseveración que me dejó pensando seriamente en como discernir en que leer y que no leer en la web. El autor – un arquitecto de software – daba 4 razones por las cuales el observaba que un servidor de aplicaciones era innecesario. Las razones eran un tanto básicas, pero el blog ha causado hasta cierto punto, movimiento en el sitio. Por este blog sentí un sentido de urgencia en escribir un post acerca del porqué SI debemos tener un servidor de aplicaciones y de eso se tratará este post.

Reutilización de la lógica de negocios

En muchos casos los desarrolladores usan el término reutilización para vender positivamente una idea, y al mismo tiempo pueden usar el término para minimizar el impacto que pueda tener el hecho de reutilizar la lógica de negocios en algún desarrollo. Sin importar si utilizamos un servidor de aplicaciones o no, la reutilización es lo que nos ha motivado a evolucionar a la hora de hacer software; haciendo memoria podemos ver claramente que primero queríamos reutilizar tipos, luego componentes, luego procesos de negocios internos y luego procesos de negocio externos. Es necesario reutilizar para prevenir la duplicación del código, el sobre trabajo y sobre todo para permitir integrar procesos de negocios que nos permitan crear de forma RÁPIDA y CONSISTENTE procesos de negocio para apoyar el buen funcionamiento de los diversos clientes externos e internos que puedan necesitar de los servicios del área. En que casos no es relevante reutilizar – bueno, si tu aplicación es algo monolítico, que nadie más va a necesitar entonces no creo que sea necesario el sobre esfuerzo requerido para hacer una aplicación con servicios reutilizables – una aplicación para estacionamiento o un sistema de inventario para la panadería de la esquina son ejemplos de estos casos.

Gobernabilidad de la solución

La gobernabilidad es una palabra de moda en nuestros días a la hora de desarrollar software, pero nadie puede negar su importancia en una arquitectura de software. El software que construimos debe de ser monitoreable, es decir, debe darnos información suficiente para saber que está ocurriendo con nuestros servicios, que excepciones pasan en nuestro eco sistema, cuál es el servicio que más se utiliza, sobre que protocolo es que más se utiliza – así es, el mundo es más que solo HTTP. Si no tenemos un servidor de aplicaciones me pregunto ¿ Cómo vamos a tener gobernabilidad? En .NET, tenemos el Windows AppFabric para tener gobernabilida sobre los servicios y procesos de negocio que tenemos automatizados, y toda esta información queda en una base de datos SQLServer desde donde tenemos la capacidad de ver en que estado esta nuestra plataforma. Volviendo con la argumentación del blog que leí – y que no les voy a mostrar – no me explico como tener gobernabilidad sin un servidor de aplicaciones.

Escalabilidad

Por supuesto que existen diferentes niveles de escalabilidad en las aplicaciones de software. En una arquitectura distribuida, es necesario tener la posibilidad de que la aplicación pueda escalar pero no a nivel de interface de usuario si no a nivel de procesos de negocio. ¿Qué sentido tiene tener una aplicación web que sea escalable si tengo un proceso instalado en dos servidores distintos ( como suele ocurrir cuando no tengo un servidor de aplicaciones ) y solo en uno de los dos esta escalable? ¿No es mejor tener un solo proceso cacheable, muy escalable, donde todas las aplicaciones que consumen el servicio tengan la misma experiencia a la hora de interactuar con el proceso?

Calidad

El hecho de no tener un servidor de aplicaciones ( o varios ) en donde los procesos automatizados residan y puedan ser reutilizados por todas las aplicaciones que lo requieran nos va a permitir garantizar que la calidad de nuestros productos se va a ir incrementando. Por ejemplo, si tengo un servicio que tiene una operación que me retorne el estado de cuenta de un cliente, y este funciona correctamente en la aplicación 1 – la que inicialmente llevo a crearlo – cual es la probabilidad de que me funciona correctamente desde otra aplicación – 100%.

Movilidad

Indudablemente que uno de los cambios más drásticos en estos días es la incorporación de dispositivos móviles. Si tenemos un servidor de aplicaciones, nuestras aplicaciones móviles serán en su gran mayoría construidas con composición de aplicaciones; es decir, consumiendo servicios y construyendo los servicios que hagan falta. Es claro que estos servicios que consumimos desde nuestros dispositivos móviles son exactamente los mismos que usa nuestro software en la empresa, por lo tanto tenemos garantía de que el software que utilizamos tendrá el mismo comportamiento a nivel de negocio sin importar desde donde se ejecuta. Sin un servidor de aplicaciones los servicios estarán en un limbo en donde nadie sabe que existen ( solo los creadores ) y por lo general nadie los reutiliza, por lo que cada aplicación tiene que desarrollar completamente sus soluciones. Además por lo general, estas soluciones van ligadas al UI seleccionado para desarrollar la aplicación.

Seguridad

La seguridad parece ser uno de los temas más importantes en temas de tecnología, sin embargo, a la hora de analizar como es manejada en cada uno de los sistemas desarrolllados en las empresas, parece que no importante tanto como se preveía. Esto se da principalmente porque la seguridad parece de entrada delegada a las personas encargadas del área de infraestructura y nosotros como desarrolladores olvidamos que somos los primeros responsables de que nuestro software sea seguro. En este aspecto, un servidor de aplicaciones es un componente ideal para poner nuestros procesos de negocios a funcionar de forma correcta, ya que la autenticación y la autorización podemos aplicarla de forma uniforme a los servicios que tenemos funcionando y por lo tanto, todas las aplicaciones que utilicen nuestros servicios utilizarán los mismos mecanismos de seguridad.

Estos son solamente algunas razones por las cuales debería utilizarse un servidor de aplicaciones dentro de la empresa: sin embargo, podríamos escribir un capítulo de un libro – ya en camino Smile - de las razones por las cuales en muchos aspectos más, un servidor de aplicaciones me va a ayudar a tener una plataforma más segura, estable, ágil y escalable.

Technorati Tags: