12.21.2008

¿Qué es SOA – Service Oriented Architecture?

La palabra de moda en los últimos años en el área de desarrollo de software ha sido SOA – Arquitectura Orientada a Servicios. ¿Pero qué significa SOA en realidad?

Básicamente SOA es un cambio significativo en la manera en que nosotros diseñamos y construimos aplicaciones. Esta arquitectura toma la naturaleza abierta de la Web y la convierte en una nueva manera de pensar acerca de las arquitecturas de aplicaciones.

SOA significa integración a través de sistemas diversos. SOA utiliza protocolos estándar e interfaces convencionales – usualmente Web Services – para facilitar el acceso a la lógica de negocios y la información entre diversos servicios. SOA nos brinda los principios y la guía para transformar el conjunto de recursos de TI de la compañía – los cuales son por lo general heterogéneos, distribuidos, inflexibles y complejos -  en recursos flexibles, integrados y simplificados, que pueden ser cambiados y compuestos para alinearse más fácilmente con los objetivos del negocio. Podemos decir entonces, que SOA no es una herramienta, no más bien es un conjunto de patrones de construcción de las nuevas aplicaciones de la empresa – más dinámicas y menos dependientes.

SOA es la evolución del modelo de programación orientado a componentes, ya que SOA agrega herramientas de computación distribuida a estas tecnologías que hemos venido utilizando por años. Podríamos decir que el cambio más grande es filosófico: en lugar de pensar en el diseño de aplicaciones individuales para resolver problemas especificos, SOA ve el software como un patrón que soporta todo el proceso del negocio. Cada elemento de un servicio es un componente que puede ser utilizado muchas veces a través de muchas funciones y procesos dentro y fuera de la empresa. Los servicios se pueden actualizar y escalar conforme sea requerido, o se pueden cambiar a una librería de terceros, sin afectar la operación del negocio – esto se da por que el componente clave de SOA no es la aplicación o el componente en uso si no más bien el contrato de uso, la interface.

La idea detrás de todo esto es que es más efectivo trabajar con servicios que con aplicaciones. Todos los componentes de una infraestructura de TI tradicional permanecen en una implementación de SOA, pero esta vez en lugar de que una aplicación soporte una funcionalidad, esta se pone disponible para todo el negocio.

Esta idea de aplicaciones como servicios alineadas a los procesos del negocio no es nueva, solamente que en esfuerzos anteriores se requería mucho esfuerzo para integrar las aplicaciones heterogéneas, además de que cada uno de estos esfuerzos tenían su propio API y su forma propietaria de comunicarse; por ejemplo CORBA y COM+.

Sin embargo, esta solución moderna que llamamos SOA, toma mucho de estos esfuerzos y de los estándares abiertos de Internet para posibilitarnos llevar a cabo esta tarea. Al día de hoy XML se ha convertido en la lengua de facto entre máquinas, lo que permite a los arquitectos ligar nuevas herramientas con aplicaciones “legacy”, y desarrollar el B2B – Business to Business - alrededor del mundo.  Esta intercomunicación no es solo entre componentes, ya que incluso se pueden describir procesos de negocio con documentos XML, utilizando lenguajes de orquestación como BPEL.

A nivel del servicio, la información se maneja como mensajes XML, definidos por un esquema XML, mientras que las interfaces de la aplicación pueden ser servicios web. XML y Servicios Web son soportardos por Java y .NET,  y estan empezando a ser soportadas por muchas más tecnologías.

En la siguiente imagen podemos ver la composición de una arquitectura orientada a servicios y la interacción de sus diversos componentes. En esta imagen faltan los elementos de infraestructura tales como el ESB, BPEL, etc.

ArquitecturaSOA
En esta imagen se puede ver que una arquitectura orientada a servicios agrega una interface de servicios ( capa lógica de servicios ) sobre los objetos de negocio y sobre las aplicaciones legacy que están alineados con los procesos del negocio. Estos objetos de negocio a su vez tienen una capa de acceso a datos la cual es la que se encarga de abstraer el acceso a las diversas fuentes de datos que utiliza la empresa.

En el siguiente post vamos a escribir acerca de lo necesario para tener SOA en la organización.

12.19.2008

Linq2XML – Filtrando en una consulta

Para continuar con el tema de linq to xml, en este post vamos a crear un ejemplo en donde se realiza una consulta a un documento XML y vamos a filtrar el contenido del XML para obtener solo los registros que cumplan con la condición que deseamos.

Para iniciar, el documento XML que vamos a utilizar es el siguiente.

<?xml version="1.0" encoding="utf-8" ?>
<
clientes>
<
cliente>
<
nombre>Juan Perez</nombre>
<
cuidad>Buenos Aires</cuidad>
<
pais>Argentina</pais>
</
cliente>
<
cliente>
<
nombre>Ernesto Jimenez</nombre>
<
cuidad>La Paz</cuidad>
<
pais>Bolivia</pais>
</
cliente>
<
cliente>
<
nombre>Ana Mora</nombre>
<
cuidad>Heredia</cuidad>
<
pais>Costa Rica</pais>
</
cliente>
<
cliente>
<
nombre>Ismael Lopez</nombre>
<
cuidad>Cuidad de Guatemala</cuidad>
<
pais>Guatemala</pais>
</
cliente>
<
cliente>
<
nombre>Diego Simon</nombre>
<
cuidad>Buenos Aires</cuidad>
<
pais>Argentina</pais>
</
cliente>
<
cliente>
<
nombre>Ismael Lopez</nombre>
<
cuidad>Cuidad de Guatemala</cuidad>
<
pais>Guatemala</pais>
</
cliente>
<
cliente>
<
nombre>Isis Benavides</nombre>
<
cuidad>Alajuela</cuidad>
<
pais>Costa Rica</pais>
</
cliente>
</
clientes>



Seguidamente vamos a crear una consulta utilizando Linq2XML en la cual vamos a seleccionar todos los clientes que tengan como país Argentina o Costa Rica. Nótese que la condición de búsqueda es compuesta, ya que debemos crear un where y un or en la condición del where. El código para llevar a cabo esta consulta es el siguiente:



static void Main( string[] args )
{
XDocument xmlDoc = XDocument.Load("Clientes.xml");
var resultado = from cliente in xmlDoc.Descendants("cliente")
where cliente.Element("pais").Value == "Argentina"
|| cliente.Element("pais").Value ==
"Costa Rica"
select new
{
Nombre = (string)cliente.Element("nombre"),
pais = (string)cliente.Element("pais")
};
foreach (var cliente in resultado)
{
Console.WriteLine(cliente.Nombre);
Console.WriteLine(cliente.pais);
Console.WriteLine("-----------------");
}
}



En general, este código es casi el mismo que utilizamos en el post anterior acerca de linq2XML, lo que lo diferencia es la condición utilizada para llevar a cabo la búsqueda. En este caso, dentro del elemento cliente utilizamos el elemento país para acceder al valor de este nodo, y lo comparamos con el nombre de los países que deseamos filtrar. Como queremos filtrar por dos países, entonces ligamos la misma condición con el símbolo (||) or en C# y procedemos a ejecutar la consulta. El resultado de la ejecución de este código se puede ver en la siguiente pantalla.



image

12.13.2008

Arquitectura de Linq

En varios post anteriores hemos venido utilizando Linq; sin embargo, no hemos visto en detalle la arquitectura de Linq para entender como es su funcionamiento. En este post, voy a  explicar como funciona Linq.

En realidad Linq funciona como una capa intermedia entre la fuente de datos y el lenguaje que se esta utilizando. Desde una perspectiva de desarrollador, es simplemente una nueva manera de consultar datos desde diversas estructuras de datos directamente en el IDE. En resumen, Linq es un lenguaje de consulta que sirve de puente entre el lenguaje que se esta utilizando y la fuente de datos de donde se quiere obtener los datos. En la siguiente figura podemos ver el flujo de Linq para llevar a cabo su funcionamiento.

image

La operación de Linq inicia en el lenguaje que utiliza el desarrollador, en nuestro caso en C#. Para escribir las consultas utilizamos los operadores de Linq y las extensiones del lenguaje. Los operadores del lenguaje se exponen a través del API de operadores de consulta estándar. Entre los operadores más comúnes tenemos:

  1. Select / SelectMany
  2. Where
  3. Sum / Min / Max / Average / Aggregate
  4. Join / GroupJoin
  5. GroupBy
  6. OrderBy / ThenBy

La extensiones del lenguaje son implementadas de manera opcional por los lenguajes que implementan Linq, esto con el fin de tratar las consultas como ciudadanos de primera clase dentro del lenguaje con que se van a escribir dichas consultas. Estas extensiones incluyen:

  1. Expresiones Lambda
  2. Inicializadores de Objetos
  3. Tipos Anónimos
  4. Sintaxis de Consulta
  5. Variables tipificadas implícitamente

Seguidamente el motor de Linq se encarga de transformar estas consultas en un conjunto de llamadas a diversos métodos para obtener los datos vía los providers de linq.

El provedor de Linq es el que permite llevar a cabo la consulta desde el lenguaje hacia la fuente de datos seleccionada. Este proveedor de datos debe de implementar las interfaces IQueryProvider e IQueryable contenidas en el espacio de nombres System.Linq. Con estas interfaces podríamos extender la funcionalidad de Linq para realizar consultas a fuentes de datos que nosotros mismos seleccionamos, por ejemplo servicios web, bases de datos no soportadas aún, etc.

La siguiente figura nos muestra la arquitectura de Linq en detalle.

image

12.12.2008

Consultas con Linq2XML

En post anteriores hemos descrito como llevar a cabo consultas de diversos tipos utilizando Linq2Objects y una lista genérica de productos como fuente de datos. En esta ocasión vamos a utilizar Linq – específicamente Linq2XML – para hacer consultas a un documento XML.

Inicialmente vamos a crear el documento XML al cual le vamos a consultar utilizando Linq2XML. El documento a utilizar es el siguiente:

<?xml version="1.0" encoding="utf-8" ?>
<
clientes>
<
cliente>
<
nombre>Juan Perez</nombre>
<
cuidad>Buenos Aires</cuidad>
<
pais>Argentina</pais>
</
cliente>
<
cliente>
<
nombre>Ernesto Jimenez</nombre>
<
cuidad>La Paz</cuidad>
<
pais>Bolivia</pais>
</
cliente>
<
cliente>
<
nombre>Ana Mora</nombre>
<
cuidad>Heredia</cuidad>
<
pais>Costa Rica</pais>
</
cliente>
<
cliente>
<
nombre>Ismael Lopez</nombre>
<
cuidad>Cuidad de Guatemala</cuidad>
<
pais>Guatemala</pais>
</
cliente>
</
clientes>



Seguidamente vamos a crear el código necesario para consultar elementos sobre este documento. Inicialmente vamos a obtener todos los clientes del documento antes presentando. El código requerido para llevar a cabo esta consulta es el siguiente.



static void Main( string[] args )
{
XDocument xmlDoc = XDocument.Load("Clientes.xml");
var resultado = from cliente in xmlDoc.Descendants("cliente")
select new
{
Nombre = (string)cliente.Element("nombre"),
pais = (string)cliente.Element("pais")
};
foreach (var cliente in resultado)
{
Console.WriteLine(cliente.Nombre);
Console.WriteLine(cliente.pais);
Console.WriteLine("-----------------");
}
}



En este código simplemente cargamos el documento xml en una variable de tipo XDocument, seguidamente seleccionamos todos los descendientes del nodo raíz que en este caso es cliente, y luego creamos objetos anónimos con el nombre y el país del cliente que estamos consultando.



El resultado al ejecutar esta consulta se ve en la siguiente pantalla:



image



En los post próximos vamos a ver como ampliar el uso de Linq2XML en lo que se refiere a consultas de diversos tipos.

12.02.2008

Arquitecturas N-Layer – Ventajas y desventajas

En el post pasado, escribí acerca de las ventajas y las desventajas de utilizar una arquitectura n-tier, en este post voy a abarcar las ventajas y desventajas de utilizar una arquitectura n-layer desde mi punto de vista.

Dado que una arquitectura n-layer es una forma lógica de distribuir la aplicación, este tiene sus mayores ventajas en lo que respecta al desarrollo de la aplicación, su mantenimiento y su escalabilidad. Las principales ventajas de desarrollar una aplicación n-layer son:

  • Flexibilidad: Permite que los componentes sean modificados para llevar a cabo sus tareas sin necesidad de recompilar toda la aplicación – resguardando siempre el contrato definido para la operación. Además permite utilizar estos componentes en diversos tipos de aplicaciones y no exclusivamente para la aplicación que fueron diseñados.
  • Mantenibilidad: Facilita la tarea de modificar un componente para corregir errores, mejorar el desempeño, agregar atributos, o adaptarlos a un ambiente cambiante.
  • Reutilización: todos los componentes pueden ser utilizados desde otros componentes o desde otros sistemas. Incluso si los componentes de negocio son consumidos a través de servicios, esos servicios pueden ser reutilizados por otros sistemas internos o externos.
  • Escalabilidad: Facilita que un componente se pueda adaptar al cambio. Cuando el sistema crece en funcionalidad pero esta está definida por diferentes clientes, se pueden crear nuevos componentes sobre los componentes base para poder especializar más las capacidades de un componente específico para un cliente en específico.

La principal desventaja que yo encuentro con las aplicaciones n-layer, es que al inicio del desarrollo se consume mucho tiempo creando los componentes “core” de los sistemas; y las empresas o departamentos de TI por lo generar quieren mostrar a sus clientes – internos o externos - aspectos tangibles del sistema que se está desarrollando. Por supuesto, esta desventaja se desvanece con el paso del tiempo y con el avance en el desarrollo, porque una vez creado el “core” del sistema, el avance es impresionantemente rápido.