12.30.2013

Configurando el portal de Azure localmente con el Windows Service Bus

Todos hemos escuchado alguna vez de las ofertas de nubes publicas las cuales van desde Amazon Web Services hasta Windows Azure. Sin embargo, por diversas razones que van desde seguridad, regulaciones legales y hasta poco conocimiento del tema por parte del equipo de TI de la empresa, siempre se ha buscado de alguna forma tener las ventajas de la nube publica pero de forma privada. Aunque hay muchas definiciones de lo que es una nube privada podríamos decir que es una infraestructura dedicada al uso de una organización, la cual puede ser administrada y operada por la organización, por un tercero o por una combinación de ambos; igualmente la organización puede ser dueña de la infraestructura o un tercero puede ser el propietario de la misma.

Para poder tener una nube privada con tecnologías de Windows Azure, Microsoft ha liberado el Windows Azure pack, el cual nos permite tener servicios que son consistentes con la oferta publica de Azure.

En este post vamos a instalar el Windows Azure Pack localmente y vamos a configurarlo con el Windows Service Bus.

Instalación

Para instalar el Windows Azure Pack se procede desde el Web Platform Installer; en este escogemos la opción Windows Azure y ahí seleccionamos el Windows Azure Pack y API Express. Esta es la opción mas simple para llevar a cabo la instalación.

image

Una vez instalado ingresamos al sitio web de configuración del portal, el cual nos dará una alerta de seguridad por un tema de un certificado digital vencido pero que no representa ningún peligro, por lo que procedemos a ingresar al sitio.

image

Ya en el portal de configuración procedemos a configurar el portal indicando el servidor de base de datos donde se hará todo el proceso, el usuario y la frase que se utiliza para agregar mas maquinas a esta instalación.

image

Una vez finalizada la configuración procedemos a ingresar al portal de Azure Management Pack, en donde se ven todas las opciones que tenemos de configuración. Como se ve en la siguiente figura, la dirección es el nombre de la maquina apuntando al puerto 30091 por defecto.

image

Ahora procedemos a agregar nuestro Windows Service Bus local instalado previamente – ver post anteriores – al portal de administración recién instalado. Para esto seleccionamos la opción agregar después de haber seleccionado Service Bus en la barra de la izquierda.

image

Seguidamente se nos solicita la información de la instancia del bus a la que nos queremos conectar. Le ponemos un nombre descriptivo a la conexión, luego ponemos el endpoint del service bus ( stsEndpoint ) y seguidamente el usuario administrador y el usuario inquilino.

image

Una nota aparte acerca de los usuarios a ingresar en esta parte del proceso. Estos usuarios son creados cuando se configura la instancia del service bus y se le indica que este bus será administrado por el portal del management pack. En la siguiente figura se puede ver el momento en donde se crean estos dos usuarios.

image 

Una vez puestos correctamente los datos procedemos a conectarnos al bus configurado. Si el resultado es exitoso procederemos a ver el bus en el portal que acabamos de configurar.

image

Si le damos click a la instancia del bus, podemos ver mas información de la instancia que se esta ejecutando como por ejemplo cuantos nodos están conectados, la información de la base de datos del service bus y como esta configurado el service bus.

image

En este post vimos como configurar el portal de Azure Pack de manera local y agregamos una instancia del service bus de forma local. Hasta aquí el bus todavía no esta 100% administrado desde el portal, por lo que en el próximo post vamos a crear un plan y vamos a establecer las opciones necesarias para administrar completamente el service bus desde el portal del Windows Azure Management Pack.

12.06.2013

Evento CloudDay Guayaquil

En este post quiero aprovechar para invitarlos a participar el próximo martes 10 de diciembre en el evento CloudDay Guayaquil en el cual estaré brindando 4 charlas. El evento esta orientado a la computación en la nube utilizando las plataformas Microsoft. Nuestra empresa – Arc3Labs – será patrocinador del mismo y yo estaré de expositor en el mismo con 4 charlas. Mis charlas serán orientadas al tema del middleware en la nube y dispositivos móviles

Las charlas que voy a dar son las siguientes:

  1. BizTalk Services: En esta charla les estaré presentando de que se trata BizTalk Services y como utilizar el Servidor BizTalk desde la nube.
  2. Incorporando dispositivos móviles al middleware de la empresa: En esta charla vamos a hablar de como crear aplicaciones que le aporten valor a la empresa, conectando a través del bus de Azure un dispositivo móvil a un sistema legacy. Para la demo utilizaremos MacOs, iOS, y Java.
  3. Middleware Híbridos: En esta demo vamos a ver como crear middleware híbridos utilizando Azure Service Bus y BizTalk Server. Esta combinación resulta sumamente interesante porque con poca inversión permite a las empresas tener una capa media con una capacidad transaccional altísimo y una escalabilidad casi indefinida.
  4. Gobernabilidad: Administración y monitoreo de aplicaciones de Windows Azure con System Center: En esta charla vamos a hablar del potencial de una herramienta como System Center, con la cual podemos monitorear no solo herramientas “on premises” si no también nuestro middleware en la nube ( con lo que los middleware híbridos pueden ser monitoreados de forma completa

Para los que estén por Guayaquil ese día, aquí les dejo el registro: http://www.thecloudday.com/Charlas.aspx#

Para los que no puedan llegar luego del evento voy a subir las presentaciones.

Etiquetas de Technorati: ,,,

8.04.2013

Monitoreo del Middleware (Introducción) - Parte 1

Uno de los requisitos fundamentales para poder tener un middleware que funcione correctamente es la gobernabilidad. En internet podemos encontrar muchísimas definiciones de lo que es gobernabilidad, pero en este post lo vamos a resumir diciendo que es la capacidad que tengo para saber en que estado se encuentra mi middleware en un momento determinado.

Ahora bien, existen muchas dudas respecto a las herramientas que tengo para tener algún nivel de gobernabilidad. En las tecnologías Microsoft tenemos varias opciones, dependiendo de las herramientas que estemos utilizando y la capacidad de inversión que tengamos.

Herramientas disponibles en el “stack” de Microsoft

Como se indico anteriormente, la capacidad de gobernabilidad que podemos tener esta limitada por las tecnologías que estamos usando para monitoreo y gobernabilidad, sin embargo, podemos enumerarlas y describirlas de acuerdo a la combinación de las mismas que estemos utilizando; vamos a ir describiéndolas una a una. En la siguiente figura podemos ver las herramientas de monitoreo disponibles y en que tecnologías aplican.

image

A continuación se describe cada una de las herramientas disponibles en el grafico anterior. Esta descripción es breve ya que dedicare al menos un post posterior para mostrar el potencial de cada una de las herramientas expuestas.

Windows AppFabric

Inicialmente tenemos la herramienta del AppFabric, que nos da capacidades extras de hosting sobre IIS y nos permite monitorear el comportamiento de servicios WCF y workflows de Workflow Foundation que se hostean en el IIS. Esta herramienta nos permite ver información tal como:

  • Servicios Disponibles
  • Estado de los servicios
  • Estado de los workflows
  • Workflows y servicios ejecutados exitosamente
  • Workflows y servicios fallidos
  • Throtling de los servicios
  • Detalle de ejecución de un workflow
  • Seguimiento de variables

El AppFabric es extensible y se pueden agregar características extra asociadas con el contexto de negocio en donde se crean y ejecutan los flujos. También se puede destacar que el AppFabric guarda todos sus datos en SQL Server y por lo tanto toda la información esta disponible para poder desplegarla desde diferentes medios, por ejemplo SharePoint, dispositivos móviles, Excel, etc. Un punto importante es que el producto esta disponible en el Windows Server y no requiere comprar licencias adicionales.

System Center

El siguiente producto es el System Center. Este producto nos va a permitir darle seguimiento al AppFabric, a BizTalk Server y al Windows/Azure Service bus con el “Operational manager”. A diferencia del AppFabric y dle BAM de BizTalk server este nos permite conocer no solo aspectos relacionados con el negocio si no también desde el punto de vista de Infraestructura, tales como estado del BizTalk, estado del AppFabric, estado del cache del AppFabric, estado del BAM de BizTalk, estado del Windows Service Bus, etc. Además, debemos agregarle que el mismo nos permite hacer monitoreos de nuestras aplicaciones corriendo en Azure. La herramienta contiene una serie de características adicionales importantes como por ejemplo creación de alertas para poder notificar de situaciones excepcionales en nuestro middleware o en el caso de BizTalk Server el porcentaje de CPU que utiliza una orquestación en un momento determinado. En mi opinión esta es una de las herramientas mas útiles que posee Microsoft en su “stack” y al mismo tiempo una de las mas sub utilizadas, ya que la mayoría de las empresas solamente lo utiliza para temas de infraestructura y dejan de lado todo el potencial que nos puede proveer esta herramienta. Esta herramienta no es gratuita y debe de ser adquirida para poder ser utilizada.

BizTalk Server BAM

El BizTalk Server BAM – Business Activity Monitoring es una herramienta muy avanzada que esta especializada en seguimiento de ejecución de diversos componentes en el mundo .NET. Con el BAM de BizTalk puede monitorear:

  • Mensajes de BizTalk Server
  • Orquestaciones de BizTalk Server
  • Servicios de WCF
  • Workflows de Workflow Foundation
  • Aplicaciones .NET

El monitoreo que puedo hacer con el BAM de BizTalk es avanzado y orientado a los negocios; es decir, el tema de la infraestructura no esta incluido – tal como si lo hace el System Center. La herramienta es muy avanzada y funciona a través de Vistas creadas a partir de las actividades definidas en Excel, lo que permite que personal del negocio y que es experto en Excel pueda recibir una capacitación y establecer los modelos de monitoreo de los procesos de negocio dentro de la empresa a través del BAM. A nivel de gobernabilidad esta es la herramienta que personalmente mas recomiendo ya que permite a las empresas tener un control mas granular del estado de su middleware y las aplicaciones que lo sustentan. Para utilizarla hay que tener licenciado BizTalk Server lo cual inicialmente puede ser una limitante para una empresa, pero esta demostrado que el retorno de la inversión con el BAM se alcanza de forma rápida y sencilla por el inmenso valor agregado que le aporta a la organización en temas de inteligencia de negocios, seguimiento de procesos.

Otras Herramientas – BizTalk 360

Existen varias herramientas de terceros que son muy útiles a la hora de monitorear el estado de un middleware. Una de las mas conocidas es BizTalk 360, la cual nos permite ver el estado del middleware a través de una interface Web. La herramienta es de uso exclusivo con BizTalk server y tiene diversas características que la hacen interesante y casi necesaria en las empresas donde tienen BizTalk Server o piensan poner un middleware y están considerando BizTalk Server. La herramienta tiene un costo bastante accesible y se recomienda su uso para aumentar el nivel de gobernabilidad en la empresa.

A que tipo de monitoreo me refiero?

Cada vez que hablo de gobernabilidad y monitoreo, encuentro gente que se confunde en el termino y comparan las herramientas antes mencionadas con herramientas que permiten darle trazabilidad al código de las aplicaciones .NET y permiten cosas tales como ver en que línea sucedió un error, cual aplicación esta caída, cuales servicios se reportan como intermitentes, etc. Las herramientas antes mencionadas no solo dan seguimiento del estado de las aplicaciones sino que también pueden hacer cosas como mostrar la trazabilidad completa de un workflow para reconstruir una transacción, establecer el tiempo promedio de ejecución de un servicio especifico, el porcentaje de tiempo en que una orden dura entregándose desde la empresa hasta el proveedor, etc. Así que hay una clara diferencia entre productos que sirven para ver el estado de un recurso, y herramientas que monitorean la capa media como un todo.

7.29.2013

Leer un archivo de configuración de una librería dll – C#

Una pregunta que siempre ronda nuestras labores de desarrolladores es como hago para cargar datos de un archivo config si este archivo esta asociado a un dll y yo estoy invocándolo desde una aplicación que carga su propio archivo config. Para ilustrarlo de mejor manera veamos el siguiente diagrama:

image

En este caso, una aplicación web invoca una librería que para poder acceder un recurso ( una base de datos, servicio WCF, etc ) requiere un dato que esta en un archivo de configuración. En estos casos lo que sucede es que la aplicación web carga su propio archivo config y cuando tratamos de obtener los valores que necesitamos se produce un error indicándonos que no encuentra los valores buscados.

La solución mas común es copiar esas parejas de valores dentro del config de la aplicación web para que estos puedan ser cargados; sin embargo, en muchos casos esta solución no es viable porque se utiliza un archivo distribuido para todas las aplicaciones, con lo cual es mas fácil el mantenimiento, pero un poquito mas complicada la programación.

La solución

Es posible cargar un archivo de configuración que pertenece a otro componente – el tema de si es adecuado o no lo dejamos para otro post -  utilizando la clase ConfigurationManager y una instancia de la clase ExeConfigurationFileMap. El código para cargar un archivo de configuración es el siguiente:

   1:  public  class AdministradorDeConfig

   2:      {

   3:          public string ObtenerValor(string pNombreVariable)

   4:          {

   5:              try

   6:              {

   7:                  var _path = Assembly.GetExecutingAssembly().Location + ".config";

   8:   

   9:                  var _configMap = new ExeConfigurationFileMap

  10:                      {

  11:                          ExeConfigFilename = _path 

  12:                      };

  13:   

  14:                  var _configuracion = ConfigurationManager.OpenMappedExeConfiguration(_configMap, ConfigurationUserLevel.None);

  15:                  var _settings = _configuracion.AppSettings;

  16:   

  17:                  return _settings.Settings[pNombreVariable].Value;

  18:              }

  19:              catch (Exception _e)

  20:              {

  21:                  Console.WriteLine(_e);

  22:                  return string.Empty;

  23:              }

  24:          }

  25:      }



Como podemos ver, obtenemos el nombre del archivo de configuración utilizando Reflection – normalmente los archivos de configuración de las librerias se copian con el siguiente formato –> [Libreria.dll.config]. Luego procedemos a crear una instancia de la clase ExeConfigurationFileMap, la cual nos permite definir una estructura para mapear las configuraciones del archivo para poder cargarlo, en este caso simplemente le asignamos la ruta donde esta el archivo config y su nombre.


Luego procedemos a abrir el archivo de configuración con el método ConfigurationManager.OpenMappedExeConfiguration al cual le pasamos el FileMap y una variable que nos permite definir el nivel del usuario con el archivo por si desea llevar acciones tales como editar exclusivo, etc. Esta variable le asignamos None como configurationUserLevel y procedemos a trabajar con el archivo, que en este caso es solamente ir a traer la variable de la sección AppSettings que nos solicitan vía parámetro.  Las variables disponibles se ven a continuación:


   1:  <?xml version="1.0" encoding="utf-8" ?>

   2:  <configuration>

   3:    <appSettings>

   4:      <add key="Valor1" value="Contenido del valor 1"/>

   5:      <add key="Valor2" value="Contenido del valor 2"/>

   6:    </appSettings>

   7:  </configuration>



En nuestro caso vamos a usar una prueba unitaria para acceder a las variables. El código de la prueba unitaria se ve a continuación:


   1:  [TestClass]

   2:      public class Pruebas_ConfigFiles

   3:      {

   4:          [TestMethod]

   5:          public void SolicitarVariable1_RetornaContenido1()

   6:          {

   7:              var _adminConfig = new AdministradorDeConfig();

   8:   

   9:              var _resultado = _adminConfig.ObtenerValor("Valor1");

  10:   

  11:              Assert.IsTrue( _resultado.Length > 0);

  12:          }

  13:      }






Como podemos ver, cuando ejecutamos la prueba unitaria el resultado es positivo:


image 


Technorati Tags: ,

error X2003: #error: "Errors exist for one or more children." BizTalk Server

Creando un demo para un webcast me dio el siguiente error

Errors exist for one or more children

Este error aparecía en el output de visual studio y si le daba doble clic al error, me llevaba al código XLANG de la orquestación, tal y como se ve en la siguiente figura:

image

El error se da por un trozo de código mal escrito en un “Expression Shape” que sin embargo fue corregido pero por alguna razón el compilador no lograba detectar el cambio; entonces daba el error y no permitía construir la orquestación aunque no decía cual era el mismo.

Para solucionarlo simplemente se borra la línea que contiene el mensaje de error y se procede a recompilar. Con esto ya podemos generar el dll y hacer deployment de la solución.

Technorati Tags: ,,

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.30.2013

Registering multiple adapter types within the same process is not a supported configuration – BizTalk Server

Trabajando en un proyecto de BizTalk Server, me encontré un error un poco peculiar, ya que al parece toda la configuración estaba correcta. El mensaje de error que recibía era el siguiente:

The Messaging Engine failed to register an adapter "WCF-BasicHttp". Details: "Registering multiple adapter types within the same process is not a supported configuration.

Buscando un poco la causa del problema, me di cuenta que el fondo del asunto andaba en el IIS  - ya que era un proceso de ruteo a través de un servicio WCF y que guardaba en una base de datos SQL Server utilizando un WCF-Custom adapter. Al estar el sitio web funcionando normalmente – se podía obtener el WSDL sin ningún problema -, supuse que el problema estaba en el application pool ya que el puerto de recibo estaba funcionando correctamente en el servidor BizTalk y además la indicación del error hacia referencia al proceso en donde escuchaba el adaptador.

El problema radica en que no se puede tener adaptadores diferentes corriendo en el mismo proceso; y en este caso, ya tenia otro servicio WCF exponiendo otro adaptador en el mismo sitio web pero en una aplicación web diferente y ambos utilizaban el mismo application pool. En este escenario, estaba registrando dos adaptadores en el mismo application pool y por lo tanto se generaba el error antes descrito.

La solución al problema es simplemente crear otro aplication pool y asignarlo al nuevo sitio web en donde se esta exponiendo el servicio.

Technorati Tags:

5.21.2013

Webcast Arquitectura Distribuida - Channel9

Como les comente en un post anterior, los videos del webcast de arquitectura están disopnibles en channel9. Sin embargo, me tomo la libertad de ponerles el video en el blog para que lo puedan visualizar desde aca – aunque en “streamming” desde channel9.

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

 

4.30.2013

Utilizando un cache distribuido en nuestro middleware – Parte 1

Cuando creamos un middleware para exponer servicios y procesos de negocios estamos aprovechándonos de las capacidades que nos brindan los componentes centralizados de estas arquitecturas – servidores de aplicaciones, bus de servicios, etc. Por ejemplo, del servidor de aplicaciones podemos aprovecharnos de las capacidades adicionales de hosting y trazabilidad, y del bus de servicios ruteo, escalabilidad, desempeño, etc. Sin embargo, existe una característica muy común que normalmente aplicaciones solo a a nivel de aplicación web: el caching.

El caching a nivel web es muy utilizado a través del objeto cache. Sin embargo, este cache esta limitado al uso por parte de la aplicación que lo contiene; es decir, normalmente cuando ponemos variables o recursos en el cache, lo hacemos para que estos puedan ser accedidos por usuarios de un sistema en particular. Por ejemplo, si tenemos varias aplicaciones en un servidor Web, y dos aplicaciones requieren la lista de países, normalmente cada aplicación pone en cache esta lista, por lo tanto la vamos a tener “duplicada”. La siguiente figura nos muestra este escenario.

image

Cache Distribuido

La opción para tener cache en arquitectura distribuida es utilizar un cache que me permita hacer “caching” a nivel de servicio y no a nivel de aplicación. En este esquema, como las diversas capas de presentación solamente consumen servicios entonces vamos a aprovechar la posibilidad que se abre a la hora de que muchos UI ( pantallas ) puedan consumir datos del mismo cache, por lo tanto la aplicación móvil de POS puede acceder el cache de países de la misma forma que el sistema web de compras y facturación lo van a utilizar. Esto garantiza que el uso del cache sea lo más optimizado posible. En el siguiente diagrama se ven las diferencias a la hora de utilizar el caching a nivel de servicios y lógica de negocios.

image

Opciones Disponibles

A nivel de componentes de cache distribuido existen varias opciones como Oracle Coherencia y el Windows AppFabric. Ambas soluciones nos permiten crear un cache de acceso rápido distribuido; es decir, permiten crear un cache compuesto de una hasta cierta cantidad de maquinas – varia por producto – siendo la memoria de estos el espacio total que se tiene para utilizar el cache. En post posteriores vamos a profundizar en el tema de cache de AppFabric y el Oracle Coherencia para .NET.

2.07.2013

WebCast de Arquitectura

Los invito a participar en una serie de webcast que estaré brindando acerca del tema de arquitectura de software. En el mismo se van a estar tocando temas tales como:

  • ¿Qué es arquitectura?
  • ¿Que hace un arquitecto de software?
  • Arquitectura distribuida
  • Buses de Servicio
  • BPM
  • Seguridad
  • Gobernabilidad
  • Computación en la nube
  • Pruebas

y muchos temas más. Son 10 sesiones, las cuales quedarán grabadas y se podrán ver en el mismo url. El link de registro es el siguiente:

http://msdn.microsoft.com/es-ar/jj920131(es-ar) 

Etiquetas de Technorati:

1.12.2013

Namespaces–Windows Service Bus

 

A la hora de trabajar con el Service Bus – tanto en Windows Server como en Windows Azure – vamos a lidiar con varios conceptos que son nuevos desde el punto de vista del bus de servicios, ya que en otros contextos ya es de todos conocidos el término. El primer concepto sin duda será el de los “Namespaces”. Los Namespaces se utilizan en el service bus para hacer todo el trabajo relacionado con direccionamiento, aislamiento y administración. Todas las entidades que se crean lo hacen dentro del alcance de un namespace de un servicio.

Aislamiento

Tal y como se explica en el msdn[1], un bus de servicio en Windows Server puede servir como una plataforma de mensajes para varias aplicaciones. Para poder aislar cada una de estas aplicaciones se utilizan los namespaces, los cuales identifican las aplicaciones dentro del bus de servicios – cada aplicación tiene un namespace único.

Direccionamiento

A nivel de direccionamiento, el bus de servicios utiliza los namespaces para direccionar los mensajes a las entidades correspondientes. Esta dirección – o ruta – inicia con el nombre del namespace del servicio. Además, se permite utilizar nombres específicos de servidores en la ruta. Un ejemplo de una ruta es el que se muestra a continuación:

Endpoint=sb://WIN-A07V80FKRPL/ServiceBusDefaultNamespace;StsEndpoint=https://WIN-A07V80FKRPL:9355/ServiceBusDefaultNamespace;RuntimePort=9354;ManagementPort=9355

Como podemos ver en la dirección anterior, se agrega el nombre del servidor y el namespace del servicio a la dirección en el endpoint.

Administración

A nivel de administración, cuando se crea un namespace se debe indicar cuales usuarios o administradores serán los propietarios del namespace. Los administradores de un namespace puede crear, modificar o eliminar entidades – colas y tópicos {más de esto en los siguientes temas}. Los administradores también pueden definir reglas de autorización para cada una de las entidades del namespace dentro del bus de servicios.

Ejemplo – Crear un Namespace

Para ilustrar el tema, vamos a trabajar directamente en un ejemplo de un namespace en el bus de servicios de Windows. En primera instancia, debemos validar cuales namespaces ya existen dentro del bus, ya que como dijimos anteriormente, los namespaces deben de ser únicos. Para esto, vamos a utilizar Power Shell en la consola creada para el Windows Service Bus.

clip_image002

Una vez en la consola digitamos el comando get-SBNamespace el cual nos va a enumerar todos los namespaces que existen en el bus en el momento de la consulta. En nuestro caso, no existe ninguno, solamente el que se crea por defecto cuando se instala el bus de servicios.

clip_image004

Ahora procedemos a crear nuestro nuevo Namespace, el cual llamaremos Arc3LabsDemo. Para esto, digitamos en Power Shell el siguiente comando:

New-SBNamespace –Name Arc3LabsDemo –ManageUsers Adminstrator

clip_image006

En este caso, estamos creando un namespace que se llama Arc3LabsDemo y estamos agregando al administrador del servidor como propietario del mismo. En la pantalla anterior se puede ver la ejecución del comando y el resultado del mismo.

Ahora que ya tenemos el namespace podemos utilizar Power Shell para ver el namespace con el comando get-SBNamespace, sin embargo, vamos a utilizar una herramienta creada por Paolo Salvatori llamada el Service Bus Explorer la cual nos permite ver de forma visual nuestros namespaces, nuestras entidades y muchas cosas más que iremos abarcando posteriormente. El link de la aplicación es el siguiente à http://code.msdn.microsoft.com/windowsazure/Service-Bus-Explorer-f2abca5a

Una vez descargado, lo ejecutamos y procedemos a conectarnos al namespace correspondiente vía File à Connect. Tenemos varias opciones para esto, pero ya que tenemos creado el namespace, podemos utilizar Power Shell para generar el endpoint del namespace y con este endpoint procedemos vía Service Bus Explorer a visualizar nuestro namespaces y respectivas entidades. Para esto, procedemos a ejecutar el siguiente comando:

clip_image008

Este comando nos va a generar un archivo de configuración con todos los endpoints para todos los namespaces que existen en nuestro bus de servicios. El siguiente archivo nos muestra dos endpoints, uno para el namespace creado por defecto, y otro para el ARc3LabsDemo el cual recién creamos.

clip_image010

Ahora copiamos el endpoint de Arc3LabsDemo y procedemos a pegarlo en el ServiceExplorer tal y como se ve en la siguiente figura.

clip_image011

Como se puede ver en la figura anterior, seleccionamos la opción ServiceBusForWindowsConnectionString y procedemos a pegar la hilera generada en el archivo de configuración. Al darle click al botón Ok, vamos a poder ver todas las entidades que tenemos en nuestro espacio de nombres.

clip_image012

En el siguiente post continuamos trabajando con las colas y los tópicos en el bus de servicios.


[1] http://msdn.microsoft.com/en-us/library/windowsazure/jj193009(v=azure.10).aspx

Etiquetas de Technorati: