Mostrando entradas con la etiqueta Arquitectura. Mostrar todas las entradas
Mostrando entradas con la etiqueta Arquitectura. Mostrar todas las entradas

4.24.2020

Principios SOLID en .NET Core - Parte 1

Los principios SOLID están conformados de 5 principios individuales para escribir "mejor" software en el mundo de la orientación a objetos principalmente. El objetivo de los mismos es proveer al desarrollador con una guía para crear software que pueda ser probado y mantenible con el paso del tiempo.  Pero, ¿Qué es SOLID?
SOLID es un acrónimo para recordar los cinco principios para el desarrollo de software en lenguajes orientados a objetos. Estos principios son los que se enumeran a continuación y estarán detallados cada uno en publicaciones posteriores. 
SRP --> Single Responsibility Principle (Principio de responsabilidad única)
OCP --> Open Close Principle ( Principio cerrado abierto)
LSP --> Liskov Substitution Principle (Principio de substitución de Liskov)
ISP --> Interface Segregation Principle (Principio de segregación de interfaces)
DIP --> Dependency Inversion Principle (Principio de inversión de dependencia)
Es común ver referencias a cada uno de estos principios por su acrónimo; es decir, SRP, OCP, LSP, etc.
Una pregunta común entre desarrolladores es ¿Cuándo aplicar estos principios? La respuesta no es sencilla; sin embargo, creo que primero se debe resolver el problema que estamos trabajando de la forma más sencilla posible, y luego optimizar el código conforme se van encontrando oportunidades al crecer la aplicación. Conforme avanza el tiempo y el desarrollador adquiere más experiencia en el uso de estos principios, usualmente estos emergen solos cuando estamos diseñando el aplicativo.
En el próximo post vamos a enfocarnos en SRP o el principio de la responsabilidad única.

12.07.2014

El desarrollador o el usuario

En muchas situaciones me preguntan cual framework es el mejor para x tarea, o cual framework utilizo yo para desarrollar una aplicación. Algunas veces son mas puntuales y preguntan cosas como utilizas el Entity Framework? Usas Sencha para las apps o Apache Cordova? Estas preguntas van acompañadas siempre con el “en que te basas para escoger un framework” donde quizás la pregunta es mas orientada al tipo de preguntas que un arquitecto de software tiene que hacerse y ayudar a responder a los equipos de desarrollo con los cuales trabaja.

Personalmente utilizo algunos frameworks para desarrollar aplicaciones tales como Dapper de stackoverflow; sin embargo, normalmente trato de utilizar la tecnología recomendada por el vendedor para desarrollar aplicaciones en su plataforma. Aquí es cuando los desarrolladores “levantan” la mano y dicen pero porque o usas x o y framework si al final te ayuda a terminar tus aplicaciones de forma más rápida? La respuesta es sencilla: Yo hago aplicaciones para usuarios y no para desarrolladores y no puedo sacrificar al usuario final para beneficiar al desarrollador.

Enfoque desde el punto de vista de un arquitecto: Es bueno terminar en tiempo y en forma los proyectos en los cuales trabajamos, pero no debo entregar aplicaciones con menos capacidades al usuario final por el simple hecho de utilizar un framework que permite que los desarrolladores escriban menos código; es decir, la aplicación debe tener el máximo desempeño que puede dar en la plataforma seleccionada en temas tales como velocidad de ejecución, interacción con repositorio de datos, consumo de energía – para dispositivos móviles, consumo de datos – para dispositivos móviles, manejo de transacciones, manejo de errores, manejo de esquemas de auditoria, seguridad e interacción con el usuario final. Este tema es relevante tanto para aplicaciones locales (on premises), aplicaciones móviles y aplicaciones que corren en la nube.

Etiquetas de Technorati: ,

8.18.2014

Webcast Implementando SOA con el Windows Service Bus–Grabación

Para los que me consultaron, el link con el webcast del primer webcast es el siguiente: https://www149.livemeeting.com/cc/wwe_us/view.asx?scan=scanhff 

Lo pueden ver en línea o descargarlo

Etiquetas de Technorati:

8.13.2014

Windows Service Bus: Mejora del Mensaje

Una de las ventajas de los buses de servicio es que permiten mejorar los mensajes que pasan por el “middleware”. En los buses de integración como BizTalk Server se usan “mappers” los cuales a través de XSLT y otros elementos mejoran o convierten un mensaje. En el Windows Service Bus esto se logra a través de los tópicos y las acciones a partir de cada subscripción al tópico. En este post vamos a ver como mejorar un mensaje que ingresa al service bus usando un tópico.

Creación del Tópico

Lo primero que vamos a hacer es crear un tópico y agregarle 3 subscripciones tal y como se ve en la siguiente figura.

SNAGHTML2ea4d48

El primer tópico recibe todos los mensajes y por lo tanto no tiene ningún filtro especial ni ninguna acción especial sobre el mensaje.

SNAGHTML2f0e584

El segundo tópico si tiene un filtro particular y una acción para ese filtro. En este filtro vamos a recibir los mensajes que tengan en la propiedad país el código ´CRC´de Costa Rica y cuando el filtro se cumpla vamos a establecer la propiedad del mensaje código con el numero 506.

image

Algo similar llevaremos a cabo con el siguiente filtro, en el cual vamos a filtrar los mensajes con código de país PTY de Panamá y vamos a establecer el código con el numero 507.

image

Código de envío y recibo del mensaje

Ahora procedemos a enviar los mensajes a la cola del bus de servicios. Para esto creamos un nuevo mensaje y le agregamos el país y el código que luego se modificara se inicializa con el valor 0.

image

El siguiente paso es programar el recibo de mensajes de la subscripción donde llegan todos los mensajes y no tiene acción.

image

Ahora procedemos a programar el recibo de mensajes desde la subscripción con un filtro de código de país = a ‘CRC’.

image

Por ultimo, programamos el recibo de los mensajes que llegan a la subscripción de PTY.

image

El código del método desplegar mensaje es el siguiente:

image

Si ejecutamos la forma anterior, podemos ver que los mensajes se reciben de acuerdo a su destino y que el código de país se modifica como corresponde en la acción asociada al filtro.

image

Etiquetas de Technorati:

7.17.2014

Nueva serie de Webcast de arquitectura

Gracias al excelente recibimiento de la serie de webcast de arquitectura producida el año pasado se ha decidido hacer una nueva serie con temas relacionados y que están presentes en los temas a diario que enfrentamos arquitectos y desarrolladores. La nueva serie de webcast será en vivo igual que la anterior y los videos también serán hosteados en Channel9. Esta serie inicia el próximo 6 de agosto y a continuación pueden ver la información y le link de registro para el evento.

image

El link de registro para el evento es el siguiente:

Serie - Arquitectura de Software: Implementando SOA con el Windows Service Bus

Para los que desean información de los links del año anterior los pueden ver en channel 9 en esta dirección.

5.14.2014

BizTalk Hosts y Host Instances

Uno de los términos que mas confunde dentro del vocabulario utilizado a la hora de utilizar BizTalk Server es el concepto de Host y su relación y diferencia con el concepto del Host Instance. En este post vamos a definir que es cada uno de ellos y cual es su función dentro de BizTalk Server.

BizTalk Host

Un grupo de BizTalk puede tener muchos host. Los Host son contenedores lógicos donde varias tareas de BizTalk Server pueden ser asignadas. Existen dos tipos de Host:

  • Isolated Host
  • In-Process Host

El host de tipo in-process es utilizado por la mayoría de las tareas de BizTalk Server y esto quiere decir que todas las tareas a ejecutar, se van a llevar a cabo dentro del mismo proceso de BizTalk –> es decir, el mismo proceso de Windows asignado para BizTalk Server. Por otra parte, el Isolated Host va a llevar a cabo su trabajo por medio de otro proceso; por ejemplo, IIS. Cuando el IIS recibe un mensaje, el host de IIS utiliza los módulos de BizTalk Server y procesa el mensaje siguiendo los mismos pasos que cuando se utiliza un “Host in-process”; es decir, pasando por el adaptador, el pipeline y llegando al “Message Box”.

Los Isolated Host disponibles por defecto en la instalación del BizTalk Server son los siguientes:

  • HTTP Receive
  • SOAP Receive
  • WCF-BasicHttp Receive
  • WCF-CustomIsolated Receive
  • WCF-WSHttp

Estos adaptadores reciben los mensajes a través del IIS y no a través de un servicio de Windows. Cada host debe tener al menos un “host instance” ejecutándose.  Un host instance del tipo “in process” no es mas que un servicio Windows ejecutándose en uno o mas servidores BizTalk y llevando a cabo las tareas asignadas al host.

Cuando se crea un “host instance” se crea tanto en el servidor de BizTalk y en las bases de datos de datos de BizTalk Server.

Etiquetas de Technorati: ,,

5.01.2014

AMQP 1.0 se convierte en estándar internacional

En los últimos meses he tenido la oportunidad de trabajar en proyectos usando el protocolo AMQP el cual como explique en un post anterior tiene una serie de ventajas a la hora de desarrollar aplicaciones distribuidas. Sin embargo, el día de hoy me encontré con esta noticia la cual creo que es de sumo interés para los desarrolladores que nos dedicamos al tema de arquitectura y capa media – middleware.

Hoy se anuncio por parte de OASIS, ISO y IEC que el protocolo AMQP se ha convertido en un estándar internacional. Este anuncio es un gran paso para lograr estandarizar la forma en que comunicamos aplicaciones dispares usando métodos asíncronos o broadcasting de transacciones, ya que nos da la posibilidad de crear capas medias estandarizas en donde podemos cambiar  de componente intermedio (servidor de colas o tópicos) y nuestras aplicaciones solamente tendrían que cambiar la forma en que se comunican con el componente, dejando el consumo de mensajes intacto.

RabbitMQ, Azure Service Bus, Windows Service Bus y otras marcas de componentes del mercado ya soportan este estándar de manera natural por lo que los insto a utilizarlo para crear capas medias eficientes y estandarizadas, en donde el lenguaje de programación no incide en el comportamiento de la aplicación.

Igualmente, el grupo de Apache Qpid tiene en su roadmap soportar clientes en diversas tecnologías tales como php, Ruby y C, además de las ya soportadas.

Esperamos mucha evolución positiva en estos temas en los próximos meses.

4.05.2014

Que es AMQP?

“Advanced Message Queuing Protocol ” es un estándar abierto para enviar mensajes entre aplicaciones y/o organizaciones. Este estándar nos permite eliminar el “vendor lock” en lo que respecta a la creación de arquitecturas distribuidas ya que podemos utilizar cualquier intermediario y cambiarlo cuando así lo queramos sin tener necesidad de cambiar el código que escribimos para enviar o recibir los mensajes. Como es un estándar abierto, nos permite conectar aplicaciones que están en distintas plataformas sin necesidad de utilizar un intermediario que le ponga mucho overead a la transacción tal como un bus de servicios de integración en donde normalmente se tiene que enviar para ser procesado en XML y en el peor de los casos usando HTTP.

AMQP en la vida real

Aun sin existir el estándar para manejo de mensajes vías un servidor de colas, este tipo de servidores nos permiten crear aplicaciones distribuidas que nos ayudan a manejar altos volúmenes transaccionales donde no necesariamente alguna de las partes debe de estar disponible para que el envío del mensaje sea exitoso. Este tipo de modelos de operación se aplican de forma común sobre todo en sistemas que procesan transacciones tales como pagos, solicitudes de autorización, manejo de auditorias, etc.

Esta capa intermedia nos permite conectar aplicaciones entre si, dándonos la oportunidad de crear verdaderas aplicaciones distribuidas –> concepto que difiere mucho de tener librerías en un directorio virtual que aunque se podrían utilizar en otras aplicaciones no se hace, porque en realidad al estar en un directorio virtual, están siendo utilizadas de forma local.

Para conectarnos a un servidor AMQP utilizamos diversas librerías disponibles en el mercado, siendo una de las mas comunes Apache Qpid. Esta librería nos permite enviar y recibir mensajes utilizando el estándar AMQP desde cualquier lenguaje soportado y desde el cual se puedan utilizar las librerías; entre los lenguajes incluidos están Java –> JMS, javascript, C++, .NET –> WCF, phyton, Ruby, Perl y una seria de lenguajes que se van agregando a la misma. Igualmente existen otras librerías que nos permiten interactuar con servidores AMQP con otros lenguajes de programación. Es importante destacar que AMQP nos permite interactuar entre diversas plataformas mientras la plataforma se adapte al estándar.

Existen varios servidores que soportan el estándar AMQP, tales como Windows Service Bus, RabbitMQ, Oracle Open Queue, ZeroMQ, etc. Una ventaja con este estándar es que podemos cambiar el servidor sin necesidad de cambiar el código con el cual interactuamos con el servidor, esto nos permite tener una infraestructura distribuida sin estar “amarrado” a una marca en especifico.

Básicamente la forma en que AMQP funciona se puede visualizar en la siguiente figura. Un cliente A tiene una librería en su lenguaje de preferencia que le permite interactuar con un servidor utilizando AMQP; por lo tanto puede enviar mensajes al servidor AMQP. Desde el otro extremo hay otro cliente B que también soporta el estándar AMQP pero no necesariamente utilizan el mismo lenguaje de programación para consumir los mensajes y que puede interactuar con el cliente A sin importar desde que plataforma fue enviado el mensaje.

image

En próximos post vamos a ver como interactúan clientes en plataformas diferentes utilizando AMQP – .NET y Java.

Etiquetas de Technorati:

3.29.2014

Request–Response con el Windows Service Bus

El bus en su versión de Windows no tiene “relay service” disponible como si sucede en el bus de servicios de Azure, por lo tanto solo se soportan transacciones asíncronas. En este sentido solo tenemos como opción utilizar colas o tópicos ya que no podemos conectar servicios creados en WCF y hosteados en el IIS al Windows Service Bus para que sean atendidos en un patrón solicitud y respuesta.

Sin embargo, como bien lo definimos en el titulo de este post, si existe una forma de crear solitudes de dos vías en el Windows Service Bus y es utilizando correlación, sesiones y colas.

El Cliente

El primer paso es crear el cliente del servicio es decir, el que envía la solicitud. Para esto primero creamos variables para tener acceso a la cola de envío y a la cola de respuesta.

  1: var _requestQueue = QueueClient.CreateFromConnectionString(ServiceBusEndpoint, "RequestQueue");
  2: var _responseQueue = QueueClient.CreateFromConnectionString(ServiceBusEndpoint, "ResponseQueue", ReceiveMode.ReceiveAndDelete);

Luego creamos un while para presentar la consola hasta que el cliente digite una tecla que sea diferente a “n” o “N”, en cuyo caso el cliente nos estará diciendo que no quiere enviar mas mensajes.


Dentro de este While vamos a crear un Id de sesión único utilizando un Guid de sistema y procedemos a solicitar el numero de cliente que el usuario desea ingresar; por ultimo establecemos la sesión utilizando el id de sesión único que acabamos de generar.

  1: var _replyToSessionId = Guid.NewGuid().ToString();
  2: Console.WriteLine("Digite el numero de cliente: ");
  3: string _numeroDeCliente = Console.ReadLine();
  4: var _messageSession = _responseQueue.AcceptMessageSession(_replyToSessionId);
  5: 

El siguiente paso es crear el mensaje que vamos a enviar. Este contendrá el numero de cliente ingresado por el cliente, pero además tendrá el valor de la sesión y la propiedad ReplyToSessionId establecidos por el Id de sesión único creado anteriormente con el Guid del sistema. Después de esto enviamos el mensaje.

  1: var _mensaje = new BrokeredMessage(_numeroDeCliente)
  2: {
  3:     SessionId = _replyToSessionId,
  4:     ReplyToSessionId = _replyToSessionId,
  5:     MessageId = DateTime.Now.ToBinary().ToString()
  6: };
  7: _requestQueue.Send( _mensaje );
  8: Console.ForegroundColor = ConsoleColor.Cyan;
  9: Console.WriteLine("Mensaje enviado. Id Mensaje = " + _mensaje.MessageId);

Por ultimo esperamos la respuesta del mensaje y lo desplegamos en la consola.

  1: Console.ForegroundColor = ConsoleColor.Cyan;
  2: Console.WriteLine("Mensaje enviado. Id Mensaje = " + _mensaje.MessageId);
  3: 
  4: var _responseMessage = _messageSession.Receive(TimeSpan.FromSeconds(20));
  5: if (_responseMessage != null)
  6: {
  7:     Console.ForegroundColor = ConsoleColor.Green;
  8:     Console.WriteLine("Mensaje recibido: {0}. El nombre del cliente es {1}", _responseMessage.MessageId, _responseMessage.GetBody<string>());
  9: }

El Servidor


Seguidamente creamos el servidor que va a procesar la solicitud enviada por el cliente y va a responder a la instancia del cliente. El primer paso es crear dos colas, una hacia donde se envía la solicitud, y otra hacia donde se envía y se busca la respuesta a la solicitud.

  1:         private QueueClient _requestQueue;
  2:         private QueueClient _responseQueue;

Luego procedemos a crear el método que va a procesar la respuesta. Inicialmente se crea una sesión, luego de esto hacemos un ciclo “while” en donde nos quedamos esperando hasta que llegue un mensaje a la cola de recibo. Como se puede ver en el segundo while, nos quedamos esperando hasta que la variable _messageSession sea diferente de nulo; el estado de esta variable cambiara cuando la operación de solicitud de mensaje devuelva un mensaje recibido en la cola de solicitud _requestQueue.

  1: while (true)
  2: {
  3:   MessageSession _messageSession = null;
  4:   while (_messageSession == null)
  5:   {
  6:       try
  7:       {
  8:           Console.ForegroundColor = ConsoleColor.DarkMagenta;
  9:           Console.WriteLine("Aceptando la sesion del mensaje");
 10:           _messageSession = _requestQueue.AcceptMessageSession();
 11:           Console.WriteLine("Sesion aceptada");
 12:       }
 13:       catch (TimeoutException _e)
 14:       {
 15:           Trace.WriteLine(_e.ToString());
 16:           throw;
 17:       }
 18:   }


Una vez recibido el mensaje procedemos a procesarlo. El primer paso es extraerlo de la cola para que la instancia del mensaje desaparezca de los mensajes a procesar, esto se logra con la operación MessageSession.Receive. Seguidamente obtenemos el contenido del mensaje con la operacion GetBody y procedemos a imprimir lo recibido. Seguidamente procedemos a crear el mensaje de respuesta, para esto creamos un nuevo mensaje – BrokeredMessage –, le agregamos el nuevo contenido el cual es el mismo del anterior pero con el string “el nombre del cliente <mensaje anterior> es XYZ”. Este nuevo mensaje se responde con una particularidad, la variable SessionId es el valor de la variable ReplyToSessionId y el Id del mensaje sera el mismo que el Id del mensaje recibido, para lo cual usamos la propiedad MessageId de ambos mensajes.

  1:  Console.ForegroundColor = ConsoleColor.Yellow;
  2:     Console.WriteLine("Recibiendo mensajes de la session {0} ", _messageSession.SessionId);
  3:     Console.ForegroundColor = ConsoleColor.Green;
  4:     var _message = _messageSession.Receive(TimeSpan.FromSeconds(5));
  5:     if (_message != null)
  6:     {
  7:         var _numeroDeCliente = _message.GetBody<string>();
  8: 
  9:         Console.WriteLine("Cliente numero: {0}", _numeroDeCliente);
 10: 
 11:         var _nombreCliente = string.Format("El nombre del cliente : {0} es XYZ", _numeroDeCliente);
 12: 
 13:         var _responseMessage = new BrokeredMessage(_nombreCliente)
 14:         {
 15:             SessionId = _message.ReplyToSessionId,
 16:             MessageId = _message.MessageId
 17:         };
 18: 
 19:         _responseQueue.Send(_responseMessage);
 20:     } //fin del if
 21: } //fin de while

Para hacer la prueba primero ejecutamos el servidor que se queda esperando por mensajes.
image

Luego iniciamos el cliente que nos solicita la información del cliente a enviar.
image

Luego digitamos los datos del cliente y podemos ver que el servidor recibe la respuesta de forma inmediata. Al mismo tiempo nos despliega los datos digitados del cliente y procede a contestar.
image



En la siguiente pantalla vemos que el cliente envió ABC y que recibió la respuesta por parte del servidor con el mensaje de texto agregado de vuelta.


image


Etiquetas de Technorati:

1.02.2014

Configurando el portal de Azure localmente con el Windows Service Bus–parte 2

Continuando con el post anterior, vamos a configurar el servicio del bus de servicios a través del portal para que los usuarios puedan administrar sus objetos del bus directamente desde el portal.

Configurando el aprovisionamiento del service bus

Una vez configurado el service bus en el portal del Azure Pack, procedemos a crear los planes de forma tal que los usuarios del mismo puedan administrarlo directamente desde el portal. Para iniciar vamos al portal del Azure pack y seleccionamos planes, en esa opción seleccionamos crear plan.

image

Seguidamente procedemos a crear el plan y el primer paso es ponerle un nombre descriptivo al mismo.

image

Seguidamente seleccionamos los servicios que serán parte del plan, como se ve en la siguiente pantalla, seleccionamos service bus y el service bus recién agregado.

image

En la ultima pantalla procedemos con la finalización de la configuración del servicio.

image

Una vez creado el plan, este aparece en la consola del portal.

image

El siguiente paso es asegurarnos que el numero de conexiones en el sitio sea ilimitado.

image

Como podemos ver en la siguiente figura, el plan esta configurado y el sitio de estadísticas listo para recabar información de uso.

image

Una vez creado el plan, ahora se procede a asociar los inquilinos del servicio con el plan. Con esta asociación los inquilinos pueden asociarse al portal y solicitar nuevos planes, o interactuar con el service bus haciendo tareas como crear colas, suscripciones, namespaces, etc.

Para que los inquilinos puedan acceder al service bus configurado en la nube privada, debemos crear una cuenta para el usuario que va a proceder con su uso. Para eso vamos a la opción de cuentas de usuario y seleccionamos crear un nuevo usuario.

image

Agregamos los datos solicitados, asociamos el nuevo usuario al plan del service bus, y procedemos a crearlo.

image

El siguiente paso es verificar si el usuario se creo correctamente y si se asocio al plan que estábamos configurando, para esto procedemos dando clic al usuario en el portal y viendo los detalles del mismo verificamos si el usuario esta activo y si tiene asociado el plan.

image

Ahora procedemos a ingresar al sitio de inquilinos con el nuevo usuario creado. Para esto vamos a la dirección https://drojasmwin8:30081/ y procedemos a digitar las credenciales creadas.

image

Una vez ingresados al sitio web, podemos ver que el usuario inquilino tiene permisos para manipular el bus de servicios del plan (o la instancia que le corresponde). Inicialmente podemos crear un namespace y dentro del namespace podemos crear colas y tópicos.

image

Si ingresamos al namespace vemos que ya tenemos las opciones de creación antes mencionadas.

image

El resultado de dicha acción es la creación de una cola de mensajes en el service bus.

image

Para conectarnos al bus, podemos usar la cadena de conexión que nos brinda directamente el namespace del bus de servicios.

image

Incluso podemos acceder a la cola desde el Service bus Explorer (con la versión compatible con el Windows Service bus)

image

El resultado final de la conexión se ve en la siguiente figura.

image

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.

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: