1.18.2009

El Rol del Entity Framework en una Arquitectura n-layer

El entity framework es una nueva forma de acceder datos utilizando .NET. En este post vamos a conversar acerca del rol del EF ( Entity Framework ) dentro de una arquitectura n-layer.

¿Qué es el Entity Framework?

Lo primero que tenemos que hacer para entender el rol que juega en EF en una arquitectura n-layer, es entender que es el EF. De acuerdo a la definición del msdn,  el EF es  un conjunto de tecnologías que brindan soporte para desarrollar aplicaciones orientadas a datos. Esta definición agrega además que los arquitectos y desarrolladores tiene que enfocarse en dos objetivos diferentes: modelar entidades y relaciones, y además deben de trabajar con motores de datos para guardar y obtener datos, por lo que hace más complejo el proceso de diseño de aplicaicones. En otras palabras, sin el EF se deben de crear dos modelos, uno para los objetos y otro para las base de datos y entender ambos. Esto se da por que la forma de acceder y administrar los datos desde un modelo de objetos es diferente respecto a la forma en que se hace desde una base de datos. Este y otros muchos problemas vienen a ser solucionados por el EF.

El EF es un ORM que permite manejar la traducción de datos entre dos modelos que son muy diferentes, el modelo de objetos de una aplicación y el modelo de la base de datos. Para ver estas diferencias vamos a ver un ejemplo muy simple y muy utilizado en el día a día de nosotros los desarrolladores de software: un maestro detalle de una factura. Al modelar un maestro detalle en un diagrama de base de datos, vamos a tener inicialmente la tabla maestro con toda la información relacionada con el encabezado de la factura, por ejemplo el nombre del cliente, la fecha de la venta, etc. Seguidamente en el detalle debe de ir todo lo relacionado con el detalle de una factura, por ejemplo el id del producto vendido, el precio, la cantidad, y el más importante respecto al punto que tratamos: el ID del encabezado de la factura al que pertenece el detalle. Por el contrario, en un diagrama de clases el objeto que representa el detalle no conoce quién es su padre, ya que el objeto hijo es contenido dentro del padre, ya sea a través de una colección de objetos, un arreglo, o cualquier otra estructura disponible en el lenguaje.

Un ORM lo que hace es llevar a cabo esta transformación de datos que normalmente nosotros hacemos a mano cuando interactuamos con la base de datos; es decir, todo lo que normalmente hacíamos desde los métodos de la capa de acceso a datos, ya sea para obtener datos o para llevar a cabo operaciones de actualización, inserción y borrado. Los ORM además abstraen la funcionalidad requerida para interactuar con un repositorio de datos, por ejemplo el abrir y cerrar la conexión, el “lazy loading” de datos, el manejo de las relaciones, etc. Algunas de estas tareas igualmente las llevamos a cabo en la capa de acceso a datos y la forma tradicional de abstraer el manejo de las conexiones y la interacción con el repositorio de datos es utilizando el “data access application block”.

Rol del EF en una Arquitectura n-layer

Como podemos ver, el EF viene a jugar el rol que tradicionalmente ocupaba nuestra capa de acceso a datos en la arquitectura tradicional n-layer. Es decir, la librería que normalmente creabamos para acceder y abstraer el acceso al o a los repositorios de datos, ya no es necesaria dado que el EF nos da toda la funcionalidad requerida para poder interactuar con el o los repositorios de datos. Claramente dicho, el EF reemplaza la capa de acceso a datos en una arquitectura n-layer.

En post siguientes vamos a explorar más detalladamente la funcionalidad del entity framework.

1.13.2009

Capas del Modelo Conceptual de SOA

En el post anterior, expliqué el modelo conceptual de lo que sería una arquitectura n-layer de una arquitectura orientada a servicios. En este post vamos a describir detalladamente que papel juega cada una de esas capas en una arqutiectura SOA. Pero antes de iniciar, vamos a actualizar la figura que utilizamos en el post anterior para mostrar una arquitectura n-layer de SOA y le vamos a agregar dos capas más la cuales vamos a describir en conjunto con las restantes. La figura actualizada es la siguiente:

image

En esta figura agregamos la capa de integración y la capa de Administración, Monitoreo, Calidad de Servicio y Administración. Ambas capas serán descritas en este post.

Capa 1: Sistemas Operacionales. Esta capa consiste en las aplicaciones existentes dentro de la empresa, conocidas como legacy systems.Entre estas capas podemos tener CRM´s, ERP´s, aplicaciones de BI, Orientadas a objetos, etc. Todas estas aplicaciones se integran a través de SOA.

Capa 2: Capa de Componentes: Esta capa es la que contiene los componentes que se encargan de brindar la funcionalidad que exponen los servicios. Esta capa tipicamente usa tecnologías para contener los componentes que existen dentro de esta, tales como servidores de aplicaciones, los cuales a su vez ayudan a llevar a cabo tareas como implementar componentes, a manejar el balanceo de los componente, la disponibilidad, etc.

Capa 3: Capa de Servicios: En esta capa residen los servicios que la organización decide exponer. Pueden ser descubierto, referenciados directamente, o ser parte de una orquestación o de un servicio compuesto. Normalmente estos servicios exponen la funcionalidad de negocio a través de contratos que permiten invocar los componentes de negocio que se encuentran en la capa de componentes de la empresa. Estos contratos permiten cambiar la forma en que se llevan a cabo las tareas sin necesidad de hacer redeploy de los servicios expuestos.

Capa 4: Procesos de Negocio – Orquestación: En esta capa se exponen las orquestaciones de los servicios. Los servicios estan ligados a estos workflows, y por lo tanto actúan como una sola aplicación. Aqui se utilizan herramientas visuales para construir los flujos de trabajo tales como el diseñador de orquestación de Biztalk Server, o alguna herramienta de terceros que me permita crear workflows en notación BPEL.

Capa 5: Capa de Presentación. Normalmente esta capa no forma parte de SOA, pero cada día se vuelve más relevante. Los usuarios acceden los servicios y las orquestaciones invocando desde diversas interfaces de usuario la funcionalidad que desean consumir.

Capa 6: Integración ( ESB – Enterprise Service Bus ). Esta capa facilita la integración de servicios a través de la introducción de un conjunto de capacidad tales como ruteo, mediación de protocolos, mecanismos de transformación, etc. Con el WSDL ( Web Service Description Language ) se especifica el binding, el cual implica la localización del servicio que se provee. Al mismo tiepmo, el ESB nos da la facilidad de tener independencia de la ubicación del servicio para su integración, ya que es el ESB el que al final controla el ruteo de los mensajes que le llegan para ser procesados.

Capa 7: Administración, Monitoreo y Calidad del Servicio. Esta capa nos da las características requeridas para monitorear, administrar y mantener la calidad del servicio en áreas tales como seguridad, desempeño, y disponibilidad. Se le conoce como el SOA governance.

En el siguiente post vamos a tocar el tema de los enterprise service bus, vamos a definir que es un ESB y para que nos sirve un ESB en una arquitectura orientada a servicios.

1.02.2009

SOA: Arquitectura y Modelo Conceptual

En el post anterior vimos la definición de SOA. En este post, vamos a analizar conceptualmente que es SOA, y le vamos a dar un vistazo general a una arquitectura orientada a servicios en conjunto con todas sus capas.

SOA esta basado en un estilo de arquitectura que define un modelo de interacción entre 3 partes principales:

  • El proveedor del servicio: publica la descripción del servicio y brinda la implementación del mismo.
  • El consumidor del servicio: invoca el servicio utilizando el URI de la descripción del servicio directamente o puede encontrar la descripción del servicio  a través de un registro de servicio.
  • El service broker: brinda y mantiene el registro del servicio – aunque no muy de moda ultimamente.

En la siguiente figura podemos ver la relación entre las partes.

 image

Arquitectura Básica en SOA

La definición de la arquitectura SOA describe una serie de patrones o guías para crear servicios que sean independientes, relacionados, y alineados con el negocio. Dada la separación entre la descripción, la implementación y el “binding” del servicio, es posible tener gran flexibilidad en lo que se refiere a nuevas oportunidades de negocio – B2B.

Para poder obtener estas características, se deben de cumplir con una serie de lineamientos que nos van a permitir llegar a tener una arquitectura orientada a servicios dentro de la organización.

Una arquitectura SOA se puede ver de manera parcial y abstracta a través de un arquitectura n-layer de servicios que se alinean con los procesos del negocio. La siguiente figura nos muestra esta arquitectura n-layer.

image

En la figura anterior, podemos ver que existen una capa de aplicaciones que acceden los procesos de negocio a través de workflows que orquestan – organizan - el funcionamiento de dichos proceso. Estos procesos organizan el consumo de los servicios los cuales a su vez acceden los componentes de negocio de la organización que brinda el procesamiento requerido para la función deseada. Los componentes de negocio por lo general tienen un capa de acceso a datos que les permite acceder distintos repositorios de datos de aplicaciones que funcionan actualmente en la empresa – de aplicaciones legacy.

En el siguiente post vamos a analizar cada una de estas capas en detalle.