Archivo de la categoría: Arquitectura

Usando Windows Azure Content Delivery Network (CDN)

El Azure Content Delivery Network (CDN) esta diseñado para enviar audio, vídeo, imágenes y otros contenidos rápidamente a los usuarios en función de la proximidad del usuario a un nodo de su red global. Esto aumenta la velocidad y la disponibilidad haciendo su uso indispensable para ofrecer una gran experiencia de usuario dentro de nuestra aplicación web.

cdn

El CDN o Red de entrega de contenidos nos ofrece una red de servidores distribuidos que es fundamental para escalar cualquier aplicación HTTP en Azure. En la actualidad cuándo diseñamos una aplicación web que recibirá mucho trafico generado por miles de usuarios mediante llamadas concurrentes proporcionando diferente tipo de contenidos desde archivos CSS a imágenes, entre otros, sería un error plantear que un único nodo sea el responsable de ofrecer el contenido.

En este tipo  de escenarios y mediante el CDN conseguimos distribuir todos nuestros contenidos en servidores distribuidos de forma geográfica para que cuando un usuario de USA este conectado a nuestra aplicación web, el CDN le proporcione el contenido de nuestras páginas desde el nodo geográficamente más cercano.

Razones para usar un CDN

Una de las razones obvias es la distribución global y la caché de contenidos de cada uno de los nodos de la red global ofreciendo una menor latencia en la carga de la página a los usuarios de nuestra aplicación.

Con el uso de esta red ofreceremos un mejor rendimiento a nuestras aplicaciones y servicios, tendremos una aplicación escalable, reduciremos la posibilidad de failover de nuestra aplicación y además, ofreceremos contenido seguro en todo momento a través de la distribución del contenido mediante HTTPS.

Configurar Windows Azure CDN

Para configurar nuestro CDN en Azure debemos ir al portal y de ahí a Nuevo > Medios + CDN > CDN y configurar el nombre de nuestro CDN, la ubicación principal y el grupo de recursos dónde almacenaremos todo nuestro contenido. Es importante establecer el nodo principal cercano a nuestro mercado principal pues es del que se replicará a los otros nodos del CDN global de Azure.

cdn_azure

Una vez tenemos el CDN creado debemos crear un Endpoint o punto de conexión desde el mismo portal,

cdn_azure_endpoint

Para crear el endpoint necesitaremos especificar un nombre, el tipo de origen, y el host de origen. Si en el tipo de origen seleccionamos un origen personalizado deberemos escribir nosotros el host de origen, cómo por ejemplo, www.francescjaumot.net que será el dominio autorizado a consumir de nuestro CDN.

Una vez configurado nuestro endpoint este tendrá un nombre *.azureedge.net siendo * el nombre de nuestro dominio CDN y empezaremos a cargar contenido en él indicándole la ubicación del contenido mediante una ruta relativa. En mi caso el origen es un sitio web pero este puede ser el almacenamiento, un servicio en la nube, una WebApp o cómo en mi caso un dominio personalizado.

Lo más lógico para un entorno de producción es que tengamos un BLOB de Azure dónde subamos todo el contenido que queremos distribuir a través de un CDN y desde ahí administremos el contenido que cargaremos a nuestro endpoint.

cdn_azure_endpoint_load

Una vez tenemos nuestro contenido cargada podemos acceder a él y hacer referencia de el desde nuestra aplicación web mediante la URL que nos da el CDN, en nuestro caso, http://cdn4demo.azureedge.net/sliderAZURE_1.jpg.

Si nuestra aplicación ya esta desplegada en un entorno de producción y tenemos configurada la misma en un servidor IIS, podemos agregar una norma rewrite en el servidor web para que sobrescriba la URL de un grupo de contenidos directamente a nuestro CDN sin aplicar ningún cambio en nuestro código y con tan solo modificar nuestro web.config,

<rewrite>
  <rules>
    <rule name="Rewrite hacia el CDN">
      <match url="^wp-content/(.+)$" />
      <action type="Rewrite" url="http://cdn4demo.azureedge.net/{R:0}" />
    </rule>
   </rules>
</rewrite>

Tener en cuenta que el endpoint y su contenido no están disponibles de forma inmediata. De hecho puede tardar hasta 90 minutos para que sea registrado y distribuido en la red global de azure. Mientras no esté distribuido recibiremos un fantástico error 404 :) .

Single-Page Application: Web Apps modernas

Single-Page Applications (SPAs) son aplicaciones web que cargan una única página de HTML y la actualizan de forma dinámica en función de las interacciones del usuario con esa página.

SPAs utiliza HTML5, CSS y AJAX para crear aplicaciones fluida sin recargar la página de forma constante. Básicamente, toda la carga de la página y toda su interacción se encuentra en el lado del cliente mediante JavaScript.

En una página tradicional, cada vez que se hace una navegación del cliente al servidor este renderiza una nueva página de HTML. Esto, ejecuta un refresco de la página en el navegador del cliente.

En una página SPA, después de que la página sea cargada por primera vez, todas las interacciones con el servidor suceden a través de llamadas AJAX. Este devuelve datos, no tags en HTML, normalmente en un formato JSON. La aplicación web usa los datos devueltos en JSON para actualizar la página de forma dinámica, sin tener que recargar la página completa.

Cómo podéis observar, el ciclo de vida de las páginas SPA ofrecerán un rendimiento más fluido sin tener que volver a hacer que la página se recargue al completo.

Uno de los aspectos más cambiantes es la arquitectura de nuestra aplicación web. El envío de peticiones mediante AJAX y recepción de resultados mediante JSON crea una separación entre la capa de presentación y la lógica de la aplicación.

Esta separación hace que sea más fácil diseñar y mejorar cada una de las capas por separado. Si implementamos nuestra arquitectura correctamente, podremos cambiar el código HTML sin tocar el código que implementa la lógica de la aplicaciones, haciendo nuestra solución la ideal.

En esta arquitectura, toda la interacción del usuario con la UI sucede en el cliente (browser) a través de JavaScript y CSS dejando al servidor cómo una capa de servicio, es decir, que el servidor encapsulará una Web Api para dar respuesta a las peticiones HTTP de la SPA.

Con esta arquitectura, el cliente y el servicio son independientes pudiendo reemplazar al completo todo nuestro back end siempre y cuándo las cabeceras de la API se conserven para que el cliente pueda ejecutar las llamadas HTTP sin modificación. Por supuesto, lo contrario, también sería completamente posible. Podríamos escribir una aplicación móvil nativa o cualquier otra aplicación que consumiera la API al completo.

Para hacer SPAs existen diferentes Frameworks de JavaScript que podemos usar. En próximos articulos veremos frameworks cómo KnockoutJs, AngularJs y Ember.Js para el lado del cliente sobre ASP.NET, y ASP.NET Web Api para nuestro back-end.

Un saludo!!

El uso de Data Transfer Objects (DTO’s)

En muchas de nuestras aplicaciones, estamos usando ORM cómo Entity Framework. Los objetos (clases) de nuestra modelo E/R (DB) son mapeados mediante un modelo orientado objeto que representa sus relaciones físicas en formato lógico.

Estos objetos, que se pueden abstraer cómo entidades POCO de este ORM, pueden llegar a contener muchas relaciones entre los diferentes objetos dependiendo de la complejidad de nuestro modelo E/R.

En las tecnologías visibles para nuestros usuarios, es decir, las interfaces de usuario (UI) cómo puede ser ASP.NET MVC, Aplicaciones móviles… entre otros, necesitamos dar una experiencia rica, ágil y rápida teniendo en cuenta que en muchas ocasiones nuestro modelo de datos es complejo y la interfaz del usuario es sencilla.

Justo en este momento es dónde entran en contexto los Objeto de transferencia de datos (DTO con sus siglas en inglés) dónde nace (no es nuevo, este concepto lleva años con nosotros pero gana peso en las aplicaciones actuales :)) con el objetivo de minimizar el coste de la comunicación entre procesos y por lo tanto, la transferencia de datos entre estos en cada una de sus llamadas cliente – servidor minimizando así su tiempo de respuesta y transportando únicamente los datos necesarios para la operación destino.

La diferencia entre los objetos DTO y los objetos de negocio es que los primeros únicamente tienen el comportamiento de transformar los datos desde el origen y entregar los datos a su destino. Estos objetos son simples y sin lógica de negocio, es decir, son objetos que no están contenidos en nuestro dominio si no que se nutren de su resultado.

A la conclusión que podemos llegar es que si usamos las entidades POCO cómo DTO nos saltamos justo la S (SPR) de los principios SOLID que os explicava en un anterior post y le damos 2 responsabilidades diferentes a nuestro objeto: sirve de entidad del ORM y por otro de transferencia de datos.

Además darle dos responsabilidades a un objeto, obligas a que los procesos envíen gran parte la información que almacenas en la base de datos, y quizá solo hace falta una parte de esa información. Y con eso estarás enviando demasiada o poca información creando procesos muy poco eficientes.

¿Cuándo se debe usar DTO?
– Cuándo debamos reducir el nombre de llamadas al servidor.
– Cuándo debamos considerar el rendimiento y la latencia de las comunicaciones de la red.
– Cuándo debamos minimizar la transferéncia de datos.

¿Cómo se usan los DTO?
Los DTO no son mas que clases sencillas con propiedades get y set. Estas clases son llenadas en desde la capa de aplicación que estas obtienen los datos desde el repositorio a través de una llamada a nuestra DB.

Los DTO deben ser definidos en una librería a parte dentro de nuestro dominio pero sin formar parte de él pues carecen de comportamiento y en una capa superior, dónde recibimos la respuesta de la aplicación, debemos realizar la conversión de nuestra respuesta de entidad POCO a nuestro DTO.

Para ello podemos usar diferentes métodos pero en .NET y con las últimas versiones podemos usar dos formas de hacer esta conversión,
– La primera de ellas es mediante Automapper que es una librería que es capaz de convertir un objeto a otro mediante un mapeo (Lo podéis instalar mediante Nugget). Si en ambos objetos, las propiedades get y set tienen el mismo nombre, el mapeo es muy sencillo pero si no, nos permite manejar esa conversión de forma muy sencilla.

public static ContactDto Binding(Contact contact)
{
  ContactDto contactDto = new ContactDto();
  Mapper.CreateMap<Contact, ContactDto>()
        .ForMember(c => c.Name, dto => dto.MapFrom(co => co.Person.Name))
        .ForMember(c => c.FirstName, dto => dto.MapFrom(co => co.Person.FirstName))
        .ForMember(c => c.LastName, dto => dto.MapFrom(co => co.Person.LastName))
        .ForMember(c => c.Gender, dto => dto.MapFrom(co => co.Person.Gender))
        .ForMember(c => c.IdPerson, dto => dto.MapFrom(co => co.Person.IdPerson))
        .IgnoreAllNonExisting();
  Mapper.AssertConfigurationIsValid();
  contactDto = Mapper.Map<Contact, ContactDto>(contact);
  return contactDto;
}

A grandes rasgos, lo que nos permite hacer el objeto Mapper es crear un mapeo entre dos clases (Contact y ContactDto), le indicamos mediante .ForMember cómo debe ser la conversión (solo es necesario si es diferente) y le indicamos que IgnoreAllNonExisting, es decir, que no mapea lo que no exista. Finalmente hacemos un AssertConfigurationIsValid  que nos devuelve una excepción si no puede hacer la conversión.

Para terminar, hacemos el Map y obtenemos nuestro DTO con los datos que vamos a usar o representar y descartamos el resto.
En otro post, explicaré cómo usar Automapper a fondo pues da para escribir más de un post.

– La segunda de ellas, es mediante una consulta Linq to Objects y escojer que queremos devolver y que no.

var report = await _ourLayerApplication
.Contact
.Where(cnt => cnt.SequenceNumber == contactCode)
.Select(cnt => new ContactDTO
{
  Name = cnt.Person.Name,
  FirstName = cnt.Person.FirstName,
  LastName = cnt.Person.LastName,
  Gender = cnt.Person.Gender,
  IdPerson = cnt.Person.IdPerson
}).SingleOrDefaultAsync();

¿Cuál usar?
Personalmente, ambas formas nos proporcionan la misma potencia aunque al estar contextualizado en el entorno de EF y .NET la segunda forma no necesita del uso de librerías de terceros y la primera, debemos usar una librería externa y que a nivel de rendimiento, no nos oferecerá el mismo rendimiento que una consulta Linq to objects nativa de .NET.

En todo caso y resumiendo, lo que no debemos hacer es devolver los objetos obtenidos mediante consultas a la DB si usamos ORM cómo EF pues contienen sus relaciones y estas, pueden ser complejas, pesadas y transmitir datos que no son necesarios para nuestra aplicación, sobretodo, si su destino son entornos que deben ser fluidos cómo la web, el cloud y las app.

A desarrollar :)
Saludos!

Principios ‘SOLID’

En mi anterior entrada dónde hablaba de la importancia de tener una buena arquitectura de nuestra solución hacía hincapié en que escojamos lo que escojamos debe ser solida y robusta capaz de responder a evoluciones y a una facilidad en el momento de su mantenimiento.
Todo ello se resume con un desacoplamiento (separación, disgregación) entre nuestras capas de la solución.

Este desacoplamiento entre nuestras capas debe tener presente una serie de principios de diseño fundamentales que nos ayudaran a crear una arquitectura que se ajuste a prácticas demostradas que minimizan el mantenimiento y maximizan su evolución. Estos son los principios de diseño ‘SOLID’.

Single Responsability Principale (Principio de responsabilidad única)
Open Close Principale (Principio de abierto – cerrado)
Liskov Substitution Principale (Principio de subsitución de Liskov)
Interface Segregation Principale (Principio de segregación de Interface)
Dependency Inversión Principale (Principio de Inversión de dependencia)

Todo ello, nos proporcionará un bajo acoplamiento, alta cohesión y una alta encapsulación de nuestras capas.
Vamos a sintetizar, conceptualmente, cada uno de ellos y en otro post veremos un ejemplo de cada uno de los principios,

Principio de responsabilidad única (SRP) se basa en que una clase sólo debe tener una única responsabilidad o caraterística para cambiar.

Principio de Abierto – Cerrado (OCP) nos dice que las clases deben ser extensibles sin requerir modificación en la implementación de sus métodos internos. Esto se consigue mediante la abstracción.

Principio de sustitución de Liskov (LSP) nos indica que una clase que implemente una interfaz o herede de una clase base debe poder ser reemplazable por su clase base.

Principio de segregación de la interface (ISP) nos dice que los consumidores de nuestras clases no deben estar forzados a implementar interfaces que no utilizan. Las interfaces demasiado grandes deben dividirse en varias para que cada una de ellas sea implementada por distintos tipos de clientes.

Principio de Inversión de dependencias (DIP) se enfoca en darnos a entender que las dependencias directas entre módulos deben ser reemplazadas por interfaces (abstracciones) y estas no deben depender de los detalles.

En resumen, estos cinco principios conceptuales resumidos con este acrónimo introducido por Robert C. Martin, representa unos principios básicos de la programación orientada a objetos.
Si los aplicamos, es más probable que nuestro sistema sea fácil de mantener y ampliar a lo largo del tiempo con un código limpio evitando la refactorización de nuestro código fuente.

En los siguientes post voy a dedicar ejemplos concretos con cada uno de ellos.
Happy architect! :)

La importancia de una buena arquitectura

¿Qué es una arquitectura de software y que nos puede ofrecer?
En el área de software, una arquitectura nos identifica los elementos más importantes del mismo, es decir, nos da visibilidad global a todos los pasos a seguir para desarrollar.

¿Por qué es importante? Porque necesitamos una arquitectura para entender el sistema, organizar su desarrollo, plantear la realización del software y hacerlo evolucionar.

En un desarrollo de software se nos plantearán muchas dudas y casuísticas que deberemos saber cómo abordar desde un primer momento. En este planteamiento es muy importante responder a preguntas sencillas… ¿Quién? ¿Cuándo? ¿Cómo? ¿Dónde?… relacionadas con la solución para los requisitos técnicos y operacionales de nuestro sistema. Las respuestas a estas preguntas nos definirán qué componentes forman el sistema, cómo se relacionan y cómo llevan a cabo la funcionalidad.

Es muy importante tener en cuenta que las arquitecturas de software no responden únicamente a requisitos estructurales, sino que están relacionadas con aspectos de rendimiento, usabilidad, reutilización, restricciones tecnológicas e incluso cuestiones estéticas.

Arquitecturas y metodologías
Existen muchas metodologías de desarrollo de software; desde métodos muy pesados a muy ligeros que aparecen cómo respuesta al excesivo formalismo de otros métodos.

En un sistema con casos de uso que definen una secuencia de acciones entre el usuario y el sistema, visto desde un punto de vista arquitectónico, no todos los casos de uso tienen la misma importancia dónde es aconsejable destacar aquellos que nos ayudan a evitar los riesgos más importantes y sobre todo los que representan la funcionalidad básica del sistema que se debe realizar.

Cómo primera fase se debe diseñar una arquitectura base que defina nuestro sistema, lo haga robusto y sobretodo, cumpla la funcionalidad especificada.

!Una arquitectura se debe adaptar siempre a nuestra necesidad, y en ocasiones, una arquitectura puede suponer una penalización a nuestro sistema.

Tipos de arquitecturas
Hoy en día existen muchos tipos de arquitectura y todos ellos aportan su granito de arena. Lo más común en una arquitectura es que se base en un conjunto de tipos para obtener las principales ventajas de cada uno de ellos.

Debemos tener en cuenta que los diferentes tipos de arquitecturas son definiciones abstractas de cómo dividir en partes más pequeñas el sistema y de cómo estas partes deben interactuar entre si.

Cómo citación y mención a las más importantes tenemos: Cliente – Servidor, N-Layer, N-Tier, Orientado a Objetos, Presentación desacoplada, DDD (Domain Driven Design), Orientación a servicios… entre otras.

Hasta aquí todo muy bonito y perfecto… pero… ¿Cómo diseñamos una arquitectura para nuestro sistema de software?

Layers vs. Tiers
Antes de nada se debe distinguir los conceptos de Layers (Capas) y Tiers (Niveles).

El primero de ellos se refiere a desacoplar elementos de forma jerárquica de roles y responsabilidades, proporcionado una separación de las preocupaciones que tenemos en el software sin tener en cuenta la localización física de estos componentes en servidores o diferentes lugares.

El segundo desacopla de forma física los segmentos de estos elementos que se encuentran en diferentes servidores dando cómo resultado un despliegue distribuido proveyendo mejoras de escalabilidad, disponibilidad y utilización de recursos.

Ambos son importantes y se deben tener presentes, pero separar la lógica de nuestro software en N-Layers es importante para nosotros, para el cliente y para nuestro equipo. Nuestras necesidades de IT, nos indicarán si debemos usar N-Tier o no.

Ambas hacen referencia a la que es para mí una gran frase: ¡Divide y vencerás!

Próximos pasos…
En este conjunto de artículos me voy a basar, principalmente, en una arquitectura de N-Layer con orientación al dominio con C#. Esta arquitectura lleva conmigo un par de años y sin duda, me ha proporcionado enormes ventajas en proyectos pequeños, medianos y grandes en su justa medida.

En los próximos artículos iremos definiendo estos pequeños subsistemas de nuestro sistema de software.