¿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.

Como 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.

¿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.

¿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.

 

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.

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í.

Espero les sirva para futuros desarrollos web.

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.

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:

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.

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.

 

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.

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.

¿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.

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.

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.

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.

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.