3.02.2009

Utilizando el API de IIS 7 para crear Web Sites Aplicaciones, Directorios Virtuales y para explorar mi servidor Web desde .NET

En días pasados tuve la necesidad de crear una aplicación que me permitiera llevar a cabo acciones sobre el IIS para poder realizar acciones tales como crear un Sitio Web desde una aplicación desarrollada en C#. Es por eso, que en este post decidí escribir un poco acerca de como llevar a cabo estas tareas utilizando VS 2008, C#, IIS 7.0 y el API manejado para acceder las funcionalidades del IIS – al menos algunas.

El API de IIS 7.0 es una librería localizada en el directorio C:\Windows\System32\inetsrv\ – Asumiendo que la instalación de Windows esta en el disco C – y es un assemblie que se llama Microsoft.Web.Administration.dll. Esta vez, vamos a hacer una aplicación de consola que nos permita realizar un par de tareas contra el IIS.

Una vez creada la aplicación de consola procedemos a agregar una referencia al componente que nos va a exponer la funcionalidad disponible del IIS, es decir, el Microsoft.Web.Administration.dll. La siguiente figura nos muestra la referencia agregada al proyecto de ejemplo.

image

Una vez agregada esta referencia, procedemos agregar la referencia a la libreria para poder utilizarla en nuestra aplicación tal y como se muestra en el siguiente código:

using System;
using Microsoft.Web.Administration;



Luego a agregar funcionalidad a nuestra aplicacion para acceder al IIS 7.0. Lo primero que vamos a hacer es desplegar la lista de sitios web que han sido creados en el IIS con el que vamos a interactuar, en este caso, el servidor Web local. El código para llevar a cabo este procedimiento es el siguiente.



static void Main( string[] args )
{
ListarSitiosWeb( );
}

private static void ListarSitiosWeb( )
{
using (ServerManager server = new ServerManager( ))
{
foreach (Site site in server.Sites)
{
Console.WriteLine("Sitio Web:{0}", site.Name);
}
}
}



Como se ve en el código anterior, lo primero que debemos hacer es crear una instancia de la clase ServerManager, la cual representa el servidor Web instalado en mi máquina. Seguidamente, para imprimir el nombre de los sitios web creados en el servidor Web simplemente recorro la colección de Sites presente en mi servidor web. La salida de este código es:



image





Para crear un Sitio web desde mi aplicación en .NET utilizo el siguiente código.



/// <summary>
///
Permite crear un web site utilizando el API de IIS 7
/// </summary>
/// <param name="siteName">
El nombre del sitio web</param>
public static void CreateSite( string siteName )
{
try
{
using (ServerManager mgr = new ServerManager( ))
{
Site newSite = mgr.Sites.CreateElement( );
newSite.Id = DateTime.Now.Second;
newSite.SetAttributeValue("name", siteName);
mgr.Sites.Add(newSite);
mgr.CommitChanges( );
}
}
catch (Exception ex)
{
Console.WriteLine("Error: {0}", ex.ToString( ));
}
}


Este código permite crear un sitio web con el nombre que viene por parámetro – siteName – y con un Id obtenido del segundo en que fue creado el sitio web. Seguidamente agregamos el sitio a la colección de sitios del IIS, y le damos CommitChanges para refrescar el sitio web.



Otra funcionalidad con la que tenemos que trabajar cuando creamos es crear una Aplicación. Una aplicación en IIS es un agrupamiento de contenido en un sitio Web. Estas aplicaciones tienen una ruta física para el contenido y propiedades que son específicas al contenido indicado. Para crear una aplicación en el sitio web antes creado agregamos el siguiente código.



private static void AgregarAplicacion( string sitioWeb )
{
try
{
using (ServerManager server = new ServerManager( ))
{
server.Sites[sitioWeb].Applications.Add("/", @"C:\Proyectos\MiSitio");
server.CommitChanges( );
}
}
catch (Exception ex)
{
Console.WriteLine("Error creando aplicación {0}: {1}", sitioWeb, ex.ToString( ));
}
}



En este código, el método Add de la colección de aplicaciones del sitio web recibe dos parámetros, el primero es la ruta dentro del servidor web donde se va a administrar el contenido – en este caso en el directorio raíz del sitio web - , y el segundo parámetro que indica la ubicación física del contenido.



Por último, le vamos a agregar un directorio virtual a la aplicación que acabamos de crear.



public static void AgregarDirectorioVirtual( string nombreSitioWeb, string aplicacion )
{
using (ServerManager server = new ServerManager( ))
{
Site sitioWeb = server.Sites[nombreSitioWeb];
Application app = sitioWeb.Applications[aplicacion];
app.VirtualDirectories.Add("/ASPX", @"C:\Proyectos\MiSitio");
server.CommitChanges( );
}
}


Este código agregar un directorio virtual llamado ASPX, en la ruta física C:\Proyectos\MiSitio, por lo tanto va a estar mapeado a esta dirección física.

2.27.2009

¿Qué es WCF? – Parte 4. Arquitectura de WCF

Como vimos en los posts anteriores, WCF nos facilita la manera de crear servicios para poder consumirlos de forma sencilla a partir de la generación de un proxy que actúa como interceptor de la llamada y nos abstrae de toda la plomería necesaria para conectarnos con el provedor del servicio y obtener el resultado deseado. En este post vamos a hablar acerca de la arquitectura de WCF.

Todas las características de WCF, entre ellas confiabilidad, administración de la concurrencia, seguridad, y activación de instancias, dependen de la arquitectura de WCF, conocida como arquitectura basada en intercepción. El hecho de que un cliente interactúe con un proxy, significa que WCF siempre esta presente entre el servicio y el cliente, interceptando la llamada y llevando a cabo pre procesamiento y post procesamiento.

Esta “intercepción” inicia cuando el proxy serializa la llamada a un stack frame para un mensaje y envía el mensaje hacia abajo en la cadena de canales. El canal es simplemente un interceptor que tiene como propósito llevar a cabo tareas específicas. Este concepto de canal es algo muy similar al manejo de “pipes” utilizado por Biztalk Server para procesar mensajes.

Cada canal del lado del cliente hace un pre procesamiento del mensaje. La estructura exacta y la composición de la cadena depende en su mayoría del tipo de binding que se este utilizando. Por ejemplo, un canal puede estar encargado de la codificación del mensaje (MTOM, texto, etc.), otro de pasar el contexto de seguridad, otro de propagar las transacciones, otro por manejar la confiabilidad de la sesión, otro para encriptar el mensaje y así sucesivamente. El último canal del lado del cliente es el canal de transporte el cual envia el mensaje a través del transporte configurado en el host.

Del lado del servidor, el mensaje “sube” otra vez por la cadena de canales pero en sentido inverso al channel stack del cliente. Es decir, el primer canal en participar en el server es el canal de transporte, el cual recibe el mensaje.  Los canales subsecuentes llevan a cabo las tareas inversas realizadas en el cliente; por ejemplo, si en el cliente se encripto el mensaje, en el server se desencripta el mensaje. Igualmente, en esta ruta del mensaje se activa la instancia del servicio requerida para consumir el servicio. El último canal en el servidor pasa el mensaje a un elemento conocido como el dispatcher. El dispatcher es el elemento que administra la ejecución de servicio. El dispatcher convierte el mensaje en un stack frame ( lo deserializa. y llama la instancia del servicio creada para completar el llamado). En la siguiente figura se puede ver este proceso.

image Como se puede ver, el servicio no sabe que fue llamado por un cliente externo, y el cliente no sabe que se esta comunicando con un cliente externo. Ambos, ven los componentes localmente para comunicarse – el cliente en el proxy y el servicio en el dispatcher. Este concepto de intercepción en ambos lados, cliente y servidor, garantiza que ambos obtiene el ambiente de ejecución que se requiere para operar correctamente.

Por último, en el proceso de respuesta, la instancia del servicio ejecuta la llamada y retorna el control al dispatcher, el cual a su vez convierte los valores retornados y la información del error – si existe – en el mensaje de regreso. El proceso se invierte siendo el dispatcher el que inicia la cadena del llamado, y el proxy el último en contestarle al cliente.

Para concluir podemos destacar que esta arquitectura nos permite extensibilidad en el modelo, ya que podríamos crear canales personalizados para interacciones propietarias o propias de un negocio o plataforma en específico.

2.25.2009

Nuevo Look de Visual Studio 2010

Como muchos de ustedes saben, en el 2010 saldrá la nueva versión de VS, la versión 4.0. Mucho se ha especulado acerca de esta herramienta, ya que el UI de la herramienta ha sido reescrito utilizando WPF. Leyendo blogs en msdn, me encontré las primeras fotos del look de VS 2010 escrito en WPF. Aquí les dejo el link para que lo puedan ver.

http://blogs.msdn.com/jasonz/archive/2009/02/20/a-new-look-for-visual-studio-2010.aspx

2.22.2009

¿Qué es WCF? – Parte 3

En el post anterior finalizamos hablando de proxies y metadata de manera general. En este post vamos a hablar acerca de como es que funciona Windows Comunication Foundation en conjunto con mi aplicación.

En primera instancia vamos a conversar acerca de como se relacionan WCF y mi aplicación. Vamos también a incluir otros componentes como el Framework y el sistema operativo. La siguiente figura nos muestra como funcionan mi aplicacion en relación a todas las partes que intervienen cuando se envía una solicitud de mensaje y cuando la otra parte recibe esta solicitud.

imageComo podemos ver, todo inicia con la aplicación que nosotros construimos y que se va a encargar de enviar una solicitud de mensaje – cliente - al host del servicio. Este envío utiliza los assemblies de WCF, los cuáles tienen como objetivo facilitar el desarrollo de mis aplicaciones orientadas a servicios. Físicamente, WCF es un grupo de assemblies que exponen tipos y funcionalidades. Estos tipos y estas funcionalidades me permiten desarrollar aplicaciones sin preocuparme por la plomería necesaria para hacer que el mensaje que yo voy a enviar al host llegue sin problemas. Cuando hablo de plomería me refiero a las actividades relacionadas con abrir y cerrar la conexión, rutear el mensaje, seguridad del mensaje, etc. Por supuesto, WCF esta desarrollado sobre el framework de .NET, el cual a su vez utiliza las API’s del sistema operativo para poder llevar a cabo todas sus tareas.

Del otro lado, en el host de un servicio desarrollado en WCF sucede lo mismo. Un mensaje llega, y WCF, a través del sistema operativo y utilizando el framework de .NET, procesa el mensaje y de ser necesario, construye y envía una respuesta.

Así es como se relaciona WCF con el resto de los componentes necesarios para poder construir aplicaciones que utilizan servicios. En el próximo post vamos a conversar acerca de la arquitectura de WCF.

2.12.2009

¿Qué es WCF ? – Parte 2

En el post anterior publicamos el primer post acerca de lo que es WCF. En este post vamos a continuar con la parte 2 de esta serie de articulos.

En el contrato especificado en el post de la parte 1, usamos un tipo de retorno del tipo List<Usuario>. Usuario es una clase que escribí que representa una entidad de negocios la cual me permite almacenar los datos en detalle que acepto o envio desde el servicio generado. La estructura de este objeto como veremos en un post posterior va a viajar en formato XML con el wsdl, para que el consumidor del servicio tenga acceso al tipo de datos predefinido como tipo de retorno en mi servicio. Esta información del servicio en conjunto con el detalle del endpoint – definido en el post anterior – van a conformar la metadata del servicio.

Hay que tomar en cuenta que para que el “Usuario” vaya por la red, este debe de ser serializable. Ser serializable significa que el estado del objeto en un momento determinado puede ser persistido en algún medio, ya sea un archivo o un stream de bytes o en una instancia de una clase ya activa (Si nosotros como humanos fueramos serializables, entonces podríamos teletransportarnos :) ).

Con esta metadata del servicio, un consumidor del servicio puede ahora generar un Proxy. Ahora, ¿qué es un proxy en este contexto? Un proxy en WCF es un cliente generado a partir de la metadata expuesta por el servicio que hereda de la clase ClientBase<T>, por ejemplo:

[System.Diagnostics.DebuggerStepThroughAttribute( )]
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "3.0.0.0")]
public partial class ServiciosSeguridadClient : System.ServiceModel.ClientBase<WPF_ClienteSeguridad.ReferenciaServiciosDeSeguridad.IServiciosSeguridad>, WPF_ClienteSeguridad.ReferenciaServiciosDeSeguridad.IServiciosSeguridad




Este proxy nos abstrae toda la lógica necesaria para conectarse con el servicio que se desea consumir, desde el manejo de la dirección del servcio a consumir hasta el endpoint necesario para poder conversar con el servicio. Igualmente, cuando tenemos tipos compuestos en el retorno o en los parámetros del servicio, estos tipos son generados automáticamente por el proxy para así poder utilizarlos del lado del cliente, es decir, para que la aplicación que consume el servicio “compile” cuando utilizamos el servicio. Podemos decir entonces, que el proxy es un puente que nos expone todas las operaciones en un servicio, y abstrae la serialización y el envío a traves de la red. Finalmente debemos decir que un proxy utiliza un único endpoint.



Por último, el cliente y el host hablan entre sí a través de varios canales. Además, alrededor de estos canales, se pueden tener comportamientos – behaviors – asociados con el servicio. Un canal es el medio por el cual el mensaje viaja entre el cliente y el ente que hostea el servicio. La comunicación se lleva a través de de un modelo conocido como el channel stack el cual estaremos revisando en detalle en post posteriores. Un comportamiento sirve para modificar un mensaje cuando el mensaje viaja por el channel stack.



En resumen podemos decir que vamos a tener un cliente y un host los cuales se ponen de acuerdo en un contrato. El host expone endpoints los cuales tienen una combinación de dirección, binding y contrato – ABC. El cliente utiliza un proxy que esta ligado a un endpoint, por lo tanto esta ligado a un contrato en particular. Por último, todos los detalles relacionados con la comunicación se abstraen a través de los canales y los comportamientos.



En el siguiente post vamos a profundizar en el tema del channel stack para comprender como es que funciona la parte de comunicación en WCF.

2.08.2009

¿Qué es WCF? – Parte 1

Una de las preguntas más comúnes cuando hablamos de servicios y arquitecturas orientadas a servicios en tecnologías Microsoft es: ¿Qué es WCF? Pues vamos a tratar de dar una breve introducción referente a que es WCF.

WCF significa Windows Comunication Foundation. Esta disponible desde la versión 3.0 del framework de .NET. Muchos gurús de SOA incluso dicen que WCF es un framework aparte al framework de .NET – algo con lo que coincido – escencialmente por que el framework de .NET conoce de componentes y no de servicios.

Se preguntarán entonces, para que otra forma de comunicación entre componentes si ya hemos tenido DCOM, Remoting, Servicios Web, WSE, etc. La respuesta corta a esta pregunta es SOA. WCF es diferente de las versiones anteriores antes mencionadas para comunicar componentes. Aunque ya definimos que es SOA en este post, vamos a simplificarlo para explicar que es WCF y por que es tan diferente como estamos intentando explicarlo. Pensemos en SOA como diferentes piezas de código ( servicios ) que estan corriendo alrededor del mundo y los clientes pueden hacer uso de estos servicios ( consumirlos ). El ente que hostea el servicio lleva a cabo las complejidades internas, y la infraestructura de comunicación  permite cosas tales como versionamiento, seguridad, ruteo, etc. Así, uno de los principales doctrinas de SOA es el aislamiento. ¿Por qué? Vamos a decir que estamos consumiendo un servicio web que acepta un parámetro cédula de identidad para buscar una persona en una base de datos de cliente y que este servicio retorna la persona encontrada. Todo lo que tiene que tiene que hacer el cliente es preocuparse por el parámetro de ingreso y por el dato que se le va a regresar. Más allá de este modelo solicitud/respuesta, el hosteador del servicio nunca habla con el cliente. Es por esto que decimos que existe una asilamiento entre el cliente y el servidor, y ellos interoperan solamente con lo acordado para interoperar es decir, el contrato.

En WCF se utiliza el término contrato para referirse a lo que el servicio hace. Usualmente en WCF un contrato es implementado como una interface decorado por el atributo [ServiceContract]. Un contrato por ejemplo luce como el siguiente código.

[ServiceContract]
public interface IServiciosSeguridad
{
[OperationContract]
List<Usuario> ObtenerUsuarios( );

}



En realidad se requieren al menos 3 piezas de información antes de poder utilizar un servicio:





  • La dirección: donde puedo encontrar el servicio.




  • El binding: cuál protocolo utilizar para poder consumir este servicio.




  • El contrato: cuando ya se donde esta el servcicio, y como voy a conversar con él, el contrato me dice que puedo hacer con el servicio.




Esto en WCF es conocido como el ABC ( Address, Binding, Contract) del servicio. Estos 3 componentes juntos conforman lo que se conoce como un EndPoint. Un EndPoint es como el que expone el servicio ( host del servicio ) expone un servicio para que muchos clientes puedan invocar las operaciones definidas en el contrato.



En el siguiente post vamos a seguir conversando acerca de WCF, principalmente de Proxies, canales y comportamientos.



 



2.02.2009

Controles para Silverlight – Mac Style

Normalmente no escribo acerca de controles o utilidades de terceros que yo utilizo para desarrollar aplicaciones en .NET, pero esta vez voy a hacer una excepción. Esta excepión se debe a que estoy utilizando un par de controles para silverlight que me parecen impresionantes. Esto son los controles de WebAqua. Estos controles me permiten tener un desktop web con el “look and feel” del sistema operativo de Mac Leopard.

En realidad son dos controles que me permiten tener formas de navegación idénticas al MacOS. El primero es el WebFishEye, que es algo así como el toolbar de aplicaciones que aparece en las Mac. La siguiente figura es un ejemplo de una aplicación WEB que utiliza este control. Si quieres ver el demo funcional, aquí lo puedes probar.

image

El segundo control es el WebCoverFlow, el cual permite tener una interface similar al del IPhone para desplegar imágenes. En la siguiente figura se puede ver una combinación del WebVoverFlow y el WebFishEye funcionando. Si quieres ver el demo funcional lo puedes ver aquí.

image

Espero les sirva para futuros desarrollos web.

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.