[WCF] Y finalmente, llegó el cliente!

Jejejee... pues sí! Finalmente veremos como crear un cliente para nuestros servicios WCF. En las sesiones anteriores, hemos visto como crear un servicio, configurarlo y hospedarlo. Pero de què serviria todo esto sin un cliente que consuma el servicio? Sinceramente para muy poco, así que vamos a ver como en un plis-plas creamos un cliente que se conecte a nuestro servicio...
Para este post voy a suponer que partimos de una solución que tiene ya tres proyectos:

• Una WCF Service Library, es decir una dll con el código del servicio
• Una console application con el servidor
• Una winforms application con el esqueleto inicial del cliente.

El código para esta solución inicial lo podeis encontrar en: http://cid-6521c259e9b1bec6.skydrive.live.com/self.aspx/BurbujasNet/Wcf1/ServiciosCalculo|_INICIAL.zip

Si cargais la solución en VS2008, vereis los tres proyectos. Si les echais una ojeada observareis que:

1. El proyecto ClienteCalculo solo tiene el formulario creado, sin código (lógico, es lo que vamos a hacer)
2. El proyecto ServiciosCalculo tiene el código servicio (la interfaz y la clase que la implementa). El fichero de configuración del servicio no está en este proyecto
3. El proyecto Servidor, tiene el código para hospedar el servicio, así como el fichero de configuración del servicio que indica los endpoints que tiene nuestro servicio. Si os fijais el proyecto de Servidor tiene una referencia al proyecto ServiciosCalculo.
   

Ahora estamos listos para empezar a codificar el cliente...
El primer paso será agregar una "Service Reference" desde el proyecto del cliente hacia el servidor. Para ello, haceis click con el botón derecho en el nodo "references" i le dais a "Add Service Reference". Esto nos despliega un cuadro de diálogo donde básicamente Visual Studio nos pregunta la URL en la que está corriendo el servicio.
Porqué necesita Visual Studio que el servicio esté corriendo? Muy fácil: para poder descargarse el archivo de metadatos que todo servicio WCF expone y que le permite a Visual Studio generar el proxy de forma automática. Bueno, dado que necesitamos que esté corriendo el servicio, vamos a poner en marcha el Servidor. Os vais a la carpeta bin\debug\ del proyecto Servidor y ejecutais Servidor.exe (jejeje.... si no habiais compilado la solución cerrad el cuadro de dialogo y compiladla ;-)). Ahora sí, con el servidor corriendo, os vais de nuevo al Visual Studio, y entrais la URL donde está el servicio (fijaos que el Servidor os dice la URL por la cual escucha el servicio). Si todo ha ido bien (que es de esperar que sí), Visual Studio os mostrará información sobre el servicio (básicamente que métodos tiene):

Entrad el namespace en el que quereis que se generen las clases proxy (p.ej. CalculadoraService) y cuando le deis a "Ok" visual studio generará las clases para poder acceder a nuestro servicio.
Que es lo que ha hecho visual studio en este punto?

1. Ha generado unas clases proxy (dentro del namespace que nosotros le hemos dicho) para poder acceder al servicio wcf
2. Ha añadido o modificado el fichero app.config de la aplicación cliente, para añadir la configuración WCF necesaria.

El segundo punto igual os sorprende: no estaba la configuración en el servidor? La respuesta es que está en los dos lados: en el servidor se definen todos los endpoints que soporta el servicio, mientras que en el cliente se define cual de los endpoints queremos usar.
Una vez generado todo esto, lo que queda es trivial: basta con usar las clases generadas dentro del namespace que le hemos indicado para llamar al servicio, como si de una llamada normal a .NET se tratara.
Por ejemplo, en el evento click del boton de sumar vinculais el método:

private void CmdSuma_Click(object sender, EventArgs e)

{

    double op1 = Double.Parse(txtOp1.Text);

    double op2 = Double.Parse(txtOp2.Text);

    // LLamamos al servicio

    ClienteCalculo.CalculadoraService.CalculadoraClient srv =

        new ClienteCalculo.CalculadoraService.CalculadoraClient();

    double resultado = srv.sumar(op1, op2);

    txtResultado.Text = resultado.ToString();

}

Fijaos como instanciamos la clase "CaluladoraClient" (la clase proxy generada por visual studio) y llamamos a sus métodos (en este caso sumar) que son los definidos en la interfaz del servicio.
Para probarlo, poneis en marcha el Servidor y ejecutais el cliente... y listos!

Evidentemente nos han quedado cosas por ver (como llamadas asíncronas)... ya iremos profundizando un poco más en WCF, pero de momento... ya tenemos lo básico!!! :)
Saludos!
PD: El código final lo teneis en http://cid-6521c259e9b1bec6.skydrive.live.com/self.aspx/BurbujasNet/Wcf1/ServiciosCalculo|_FINAL.zip (jejejeee... el cliente no está completado, eh? sólo suma, pero vamos el resto es trivial...).

[WCF] Hospedando servicios

Bueno... en esta serie de posts sobre esta excitante tecnología que es WCF, hemos visto como crear un servicio, y como configurar un servicio usando el fichero de configuración.
Pero un servicio por si sólo no es nada: estaría bien que tuviese al menos un cliente (porqué si no es posible que se sienta un poco inútil). Vale, vale... aceptamos pulpo como animal de compañía, un servicio puede vivir sin ningún cliente pero lo que no me podeis negar es que lo que sí que necesita forzosamente es un servidor que lo acoja en su seno proceso.
Sí: los servicios en esto son como los virus: si no hay alguien que los hospede, son totalmente inútiles :)


Vale, tenemos claro que necesitamos hospedar nuestro flamante servicio pero... donde? Necesitamos comprar un "servidor de servicios" ? Podemos usar IIS? No lleva VS ningún servidor de piltrafilla que nos sirva en desarrollo? Pues (como ya viene siendo habitual en el mundo Microsoft) hay muchas maneras de enfocar la historia...


En general, el proceso que hospeda un servicio WCF es, básicamente, el CLR. Esto viene a significar que cualquier proceso .NET puede hospedar un servicio. Sí, sí: he dicho cualquier proceso. Una aplicación winforms? Pues sí. Una aplicación de línea de comandos? Pues también. Y claro está IIS también es una opción disponible, al igual que un servicio windows. Entonces? Bueno, decidir como hospedamos nuestros servicios es una decisión que se toma basándose en los requerimientos y en la arquitectura global de la solución. Cada sistema tiene sus ventajas y sus inconvenientes.
Por ejemplo, si usamos un ejecutable (sea winforms o linea de comandos), evidentemente el dicho ejecutable debe estar en marcha para que nuestros servicios esten disponibles. Esto invalida entornos desasistidos donde no habrá nadie para "poner en marcha" nuestro host, en estos entornos será mucho mejor un servicio windows. Por otro lado los hosts que son ejecutables estándar, son muy fáciles de crear y de depurar. De hecho no es extraño que durante el desarrollo, se use un servidor que sea un ejecutable, para migrar a un servidor "real" en una fase final.


Y... IIS? Hombre, pues claro. IIS puede hospedar servicios. Además, seguramente, es el mejor hosting posible, ya que si IIS sabe hacer algo és hospedar cosas y servirlas a sus clientes. Y que ventajas nos aporta IIS? Pues varias y muy importantes, entre las que destacaríamos temas de monitorizacion, activación del servicio on-demand y reciclaje de procesos. Estos temas deben "codificarse" a mano si uno opta por un host propio, mientras que en IIS nos vienen de serie. Además IIS es eficiente y altamente escalable... que razón para no usarlo? Lamentablemente podría haber una... Que pasa si mi transporte NO es http ó https? Sabe gestionar otros protocolos de transporte nuestro querido IIS? La respuesta, como todo es... depende.


Tienes XP y tienes un servicio que no usa http(s) como transporte? Pues lo siento, pero NO puedes usar IIS como hosting: En XP y 2003 IIS sólo soporta servicios con transporte http(s). Por otro lado si tienes Vista o 2008 entonces... entonces estás de suerte: WAS viene en tu ayuda!


Estoooo... WAS? Que narices es WAS? No hablábamos de IIS? WAS es el acrónimo de "Windows Activation Services", que es un nuevo sistema de activación de procesos, disponible sólo de Vista para adelante. IIS7 usa internamente WAS, para cualquier tipo de servicio (sea http(s) o no). Pero IIS7 no es un requisito de WAS, es decir podemos tener WAS sin IIS7 y hospedar cualquier tipo de servicio y no usar IIS7 a menos que lo necesitemos para otras cosas (p.ej. ASP.NET). Y no os preocupeis por las ventajas que nos ofrecía IIS7 (reciclaje de procesos, activación on-demand, etc): WAS también las ofrece (recuerdo: IIS7 usa WAS internamente).


Así, tendriamos las siguientes opciones:

• Ejecutable (winforms o consola): Sencillo, fácil y útil en etapas de desarrollo. No apto en producción.
• Servicio Windows: Única opción para hospedar servicios que no usen http(s) en XP y 2003.
  
• IIS 5.1 ó 6 en XP y 2003: Ideal para todos los servicios que usen http(s). Ganamos todas las ventajas que nos ofrece IIS.
• WAS: Ideal para cualquier servicio, pero requiere Vista, 2008 o posterior. Ganamos todas "las ventajas de IIS"... sin necsidad de tener IIS.
  
• IIS7 en Vista o 2008: Ideal para cualquier tipo de servicio. Tenemos todas las ventajas de IIS y además permite interoperar nuestros servicios WCF con ASP.NET.
  

Una vez visto el abanico de opciones disponibles para hospedar nuestros servicios, vamos a ver un ejemplo de como hospedar un servicio WCF, usando la aplicación más simple posible: una aplicación de linea de comandos.


Para hospedar un servicio se usa la classe ServiceHost. El constructor de esta clase espera un parámetro que es un objeto Type con la información de la clase que implementa el servicio. Por ejemplo, si tengo la clase CalculadoraService que me implementa un servicio, para ponerlo en marcha, debo construir un ServiceHost y abrir el canal de comunicaciones:

ServiceHost shCalc = new ServiceHost(typeof(CalculadoraService));

shCalc.Open();

// ....

shCalc.Close();

 
Y listos! Esto es todo! Esta es la manera más simple de poner en marcha un servicio. El servicio utilizará los endpoints que haya definido en el fichero de configuración de la aplicación host.
Evidentemente con la clase ServiceHost podemos personalizar más el proceso de hosting, por ejemplo podemos configurar endpoints programáticamente (en lugar de usar el fichero deconfiguración).

Bueno.... ya sólo nos queda ver una cosilla para cerrar el círculo de esa introducción de WCF: Sí, sí... el cliente!


Saludos!

[WCF] Configurando mis servicios

Bueno.... justo empieza agosto, vacaciones y demás, y antes de que decaiga toda la actividad mundial, aprovecho para contaros algo más de WCF... :) La configuración de los servicios.

En el post anterior vimos como crear un servicio sencillito (ya lo iremos complicando). Lo que hicimos básicamente fueron dos cosas:

• Definir el contrato del servicio (una interfaz de .NET decorada con ServiceContract).
• Implementar el contrato (una clase de .NET que implementaba la interfaz)

Luego vimos que ejecutando el proyecto, Visual Studio nos hospedaba nuestro servicio en un servidor de pruebas y nos permitia probarlo con un cliente de pruebas.

Pero recordais los primeros posts de esta serie? Los endpoints??? Sí, sí...el ABC de WCF: Address, Binding, Contract... dónde está mi servicio, cómo accedo a él y qué hace el servicio.
Pues bien, una de las claves de WCF es que el endpoint se define mediante un fichero de configuración (puede hacerse programáticamente, pero esto ahora no nos interesa).

Es decir, tanto la URI de mi servicio, como el protocolo que usaremos para acceder a él, se define mediante el fichero de configuración... Hoy quieres acceder a tu servicio en http://servidor/servicio1 mediante SOAP en HTTP? Pues lo configuras en el fichero de configuración. Mañana cambias de idea y quieres acceder a tu servicio mediante MSMQ? Pues ningún problema: edita el fichero de configuración. Y listos. No toques ni una línea de código.
Es por esto que decimos que WCF unifica todas las APIs de comunicaciones existentes hasta el momento.

El fichero de configuración de WCF es el estándard de .NET (que VS llama app.config), y toda la configuración de WCF se lleva a cabo en la etiqueta <system.serviceModel>.
Veamos un ejemplo de como puede ser la configuración de UN servicio:


      <service name="ServiciosCalculo.CalculadoraService" behaviorConfiguration="ServiciosCalculo.Service1Behavior">
        <host>
          <baseAddresses>
            <add baseAddress = "http://localhost:8731/Design_Time_Addresses/ServiciosCalculo/Service1/" />
          </baseAddresses>
        </host>
        <endpoint address ="" binding="wsHttpBinding" contract="ServiciosCalculo.ICalculadora">
        </endpoint>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
      </service>


Por un lado dentro de la etieuta "service" tenemos dos etiquetas principales:

• host: Que nos permite establecer la dirección (URI) base de este servicio
• endpoint: Que nos define UN endpoint. Recordad que un servicio puede tener MAS de un endpoint

Dentro del endpoint se definen los tres aspectos principales:

1. La dirección. Atributo address que contiene una URI relativa a la dirección base establecida en la etiqueta "host".
2. El binding. Atributo binding que contiene el nombre identificativo del binding que vamos a usar.
   
3. El contrato. Atributo contract que contiene el nombre de la interfaz de .NET que representa este contrato.

En el código de ejemplo vemos que el servicio implementa dos endpoints:

1. Uno con dirección relativa vacía (o sea que la URI de este endpoint es la misma que la definida en la etiqueta host), con el contrato ServiciosCalculo.ICalculadora (la interfaz que hicimos en el post anterior)
2. Otro con dirección relativa "mex", con el contrato IMetadataExchange.

El contrato IMetadataExchange es un contrato que implementan todos los servicios de WCF, y que sirve para que el servicio pueda informar al cliente de sus metadatos (p. ej. los datos del binding o del contrato, para que el cliente sepa a que atenerse... vendría a ser como "la oficina de información" del servicio).

Si os fijais en el trozo de ejemplo que he puesto, en los dos endpoints los dos bindings que hay son:

• wsHttpBinding para el primer endpoint
• mexHttpBinding para el segundo endpoint

Si os preguntais donde definimos la codificación (binaria, SOAP,...) o el transporte (TCP, MSMQ, HTTP) de estos bindings, aquí no lo vais a encontrar ya que estos bindings son bindings predefinidos de WCF.
En este post de Maor David podeis encontrar una comparación de los bindings predefinidos de WCF.
Pero no estamos limitados a estos bindings: un binding es configurable (podemos añadirle o quitarle "elementos") o bien nos podemos crear nuestros propios bindings... pero bueno, esto ya es harina de otro costal. La verdad es que con los bindings predefinidos cubrimos un amplio espectro de necesidades.


Por último los más observadores habreis visto que la etiqueta "service" del ejemplo, definia un atributo llamado "behaviorConfiguration" (con valor "ServiciosCalculo.Service1Behavior"). Esto sirve para indicar el behavior del servicio... y claro que es un behavior?
Pues bien, básicamente son datos de configuración del servicio, que NO forman parte de su endpoint. Por ejemplo: si el servicio da una excepción, queremos enviar información detallada al cliente o no? Los behaviors que tengamos se definen con la etiqueta behavior (dentro de serviceBehaviors) y se asocian a los servicios con el atributo que hemos comentado.
Por, ejemplo un behavior puede se puede definir así:
       <serviceBehaviors>
        <behavior name="ServiciosCalculo.Service1Behavior">
          <serviceMetadata httpGetEnabled="True"/>
          <serviceDebug includeExceptionDetailInFaults="False" />
        </behavior>
      </serviceBehaviors>


En posts sucesivos veremos más información sobre los behaviors.
Bien!!!! En el próximo post de la serie veremos como... crear un cliente y conectarnos a nuestros servicios!!!!

Buenas vacaciones a todos los afortunados que las hagais!!
Nos leemos! ;-)

[WCF] El primer servicio

Bueno... como lo prometido es deuda vamos a ver como crear nuestro primer servicio usando WCF!!!! Jejeee... os embarga la emoción, eh??? ;-)

Cuando creamos un servicio en WCF, lo primero es pensar cual será su contrato, es decir, cuales serán las operaciones que este servicio expondrá a sus clientes. Por ejemplo, vamos a hacer un servicio calculadora, que servirá para realizar cálculos. Para ello, voy a definir que mi servicio tendrá los métodos Sumar, Restar, Multiplicar y Dividir. Este sería a grandes rasgos el contrato del servicio.

Como creamos un WCF en Visual Studio 2008? Pues nos vamos a "New Project" y dentro de la categoría WCF escogemos algo así como "WCF Service Library". Lo que vamos a crear será un assembly (concretamente una DLL) que contendrá uno o más servicios. Le pongo al proyecto el nombre de ServiciosCalculo.


 Lo primero que vemos es que VS ha creado el proyecto y le ha añadido tres archivos:

1. App.config
2. IService1.cs
3. Service1.cs

El fichero App.config, es el fichero clásico de configuración de aplicación de .NET. Porque nos añade uno VS??? Pues bien, porque WCF se puede configurar usando el fichero App.config.


El fichero IService1.cs contiene una interfaz. Y que es esta interfaz? Pues el contrato de mi servicio, ni más ni menos. Además es lógico no? Cual es la manera de declarar los métodos que implementa una clase en .NET? Las interfaces. Pues WCF usa este mecanismo, y todo servicio en WCF debe implementar una interfaz.

Vamos pues a declarar el código de nuestro servicio. Modificamos el archivo IService1.cs para que quede así:
namespace ServiciosCalculo
{
    [ServiceContract]
    public interface ICalculadora
    {
        [OperationContract]
        double sumar(double a1, double a2);
        [OperationContract]
        double restar(double a1, double a2);
        [OperationContract]
        double multiplicar(double a1, double a2);
        [OperationContract]
        double dividir(double a1, double a2);
    }
}



Si os fijais la interfaz está decorada con el atributo [ServiceContract]. Esto le indica a WCF que esta es una interfaz que algún servicio implementará. Cada operación de la interfaz debe ir decorada con [OperationContract]. Si no ponemos [OperationContract] en el método, este pertenecerá a la interfaz, pero NO al contrato del servicio (es decir será un método no accesible desde WCF).

Ok, ya tenemos un contrato... y el servicio? Pues muy fácil, editamos el fichero Service1.cs para que quede algo así:

    public class CalculadoraService : ICalculadora
    {
        public double sumar(double a1, double a2)
        {
            return a1 + a2;
        }
        public double restar(double a1, double a2)
        {
            return a1 - a2;
        }
        public double multiplicar(double a1, double a2)
        {
            return a1 * a2;
        }
        public double dividir(double a1, double a2)
        {
            return a1 / a2;
        }
    }


Fijaos en una cosa: la clase que implementa el servicio NO tiene ninguna decoración especial. No usamos ningún servicio ni nada para indicar que esta clase es un servicio. El hecho que implemente una interfaz decorada con [ServiceContract] le basta a WCF para saber que esta clase es un servicio.

Venga... como se que la emoción os emarga!! Dadle a F5! Os preguntais que pasará??? Generalmente las DLLs no se pueden ejecutar (necesitamos un .exe), pero en el caso de las WCF Service Library, Visual Studio pone en marcha un host de servicios propio que nos permite probar nuestros servicios sin necesidad de hacernos una aplicación que los hospede ni un cliente!

Pues bueno... si le dais a ejecutar, aparece... un mensaje de error (algo así como "The client was unable to retrieve service metadata. Make sure the service is running and exposing metadata"). Oooops... nuestro gozo en un pozo.
Vamos a ver que ha pasado...

... la clave, como no podia ser de otro modo, está en el único fichero que no hemos tocado... el app.config.  En este fichero estan las configuraciones de todos los servicios de nuestra libreria. Recordad que un servicio debe tener un Endpoint: es decir, una dirección, un binding y un contrato. Lo del contrato lo tenemos claro, pero... vosotros habeis especificado una dirección (URI) para el servicio? Y un binding? No, verdad? Es que todo esto se especifica en el archivo de configuración.
VS.NET cuando hemos creado el proyecto ha creado uno para nosotros. No entraremos en detalles ahora (tendremos tiempo), pero echando una ojeada, descubrireis el problema: el fichero app.config generado por el Visual Studio utiliza los nombres IService1 y Service1 para declarar el servicio. Y estas clases no existen (les hemos cambiado el nombre), así que reflejamos los cambios en el app.config.

Concretamente los cambios a realizar son:

• En el tag <service> el atributo name debe tener el nombre de la clase (en nuestro caso ServiciosCalculo.CalculadoraService).
• En el tag <endpoint> el atributo contract debe tener el nombre del contrato, es decir de la interfaz. En nuestro caso ServiciosCalculo.ICalculadora.

 En principio no es necesario cambiar nada más. Compilad y ejecutad el proyecto de nuevo y os aparecerá el WCF Test Client:

Podeis ver que VS ha arrancado el WCF Service Host (para hospedar nuestro servicio) y un cliente de prueba (el WCF Test Client) para que podais probar el servicio. Haciendo doble click en uno de los métodos de nuestro servicio, el WCF Test Client lo invocará y nos mostrará el resultado. Aquí teneis un ejemplo de una llamada a dividir:

Que os parece? Fácil, no? Pues en el proximo post veremos un poco más en detalle como funciona el fichero app.config.
Hasta entonces.... nos leemos ;-)

[WCF] El ABC de WCF

Bueno... segundo post de la serie de WCF, donde sigo con la introducción.
En el primer post vimos que WCF era la nueva api de comunicaciones del Framework 3, orientada a servicios y con vocación de convertirse en la API de comunicaciones definitiva.

Bueno, desarrollar en WCF, consiste básicamente en hacer servidores que exponen servicios y clientes que los consumen. La relación entre un cliente y un servicio es un fiel reflejo de la vida real... veamos, podemos ver un cliente como alguien muy enamorado de la chica de sus sueños. Al final nuestro enamorado se decide lanzar a la dificil tarea de conquistar a su dama.... aaahhh.... el romanticismo....


Ante tan árdua tarea, seguro que te van a asaltar las siguientes dudas:

1. Donde vive?
2. Cómo hablarle?? Prefiere a los románticos, a los que van de duros o tiene debilidad por los tímidos y calladitos?
3. Qué decirle?? Probablemente la clave entre el éxito y el fracaso está en este punto.... Quien no ha estropeado un largo trabajo de conquista con una frase que, digamos... no tocaba.

Pues como si un Don Juan cualquiera se tratase, esas tres dudas, el Donde, el Cómo y el Qué, son los tres datos que todo cliente necesita para poder consumir un servicio:

1. Donde está? Es decir, en que URI se localiza?
2. Cómo hablarle? Es decir, que protocolo usar? Qué codificación de datos?
3. Qué decirle? Es decir, qué métodos se pueden invocar del servicio? Cual es su interfaz?

A las respuestas a esas tres cuestiones (fundamentales), se las conoce como el ABC de WCF, no sólo porque sean realmente lo básico (que lo son) de WCF si no porque:

1. Donde está un servició es su dirección. En inglés Address.
2. Como hablarle es el enlace a usar. En inglés Binding.
3. Qué  le podemos decir es el contrato  del servicio. En inglés Contract (esa era fácil).

Address, BInding y Contract, ABC, esos tres puntos son los que tenemos que tener siempre en mente. De hecho la suma de los tres es lo que se llama un Endpoint.
En WCF los servicios pueden tener uno o varios endpoints, y los clientes cuando quieren consumir un servicio, pueden escojer a través de que endpoint quieren hacerlo.

Parad atención al tema de que un servicio puede tener más de un endpoint... por ejemplo, podría tener dos endpoints con el mismo contrato pero con direcciones y bindings distintos... Un binding podria ser acceder al servicio a través de http usando soap y el otro binding podria ser usando msmq con codificación binaria... El servicio es el mismo, solo cambia el protocolo y la codificación de datos a usar (y la URI de nuestro servicio). Cuando el cliente quiere consumir este servicio decide si quiere (generalmente si puede xD) hacerlo usando http y soap, o bien usa msmq y datos binarios. Pero de nuevo el cliente es el mismo.


Y cuando digo mismo, quiero decir eso: mismo. El mismo código. El mismo programa. La misma clase.


Esa es la clave de WCF. Por eso se dice que unifica a todas las APIs anteriores.


En la próxima entrega... empezaremos ya a ver código de como hacer un servicio en WCF!

[WCF] Introducción

Bueno... voy a empezar con este una serie de posts dedicados a WCF, uno de los grandes pilares del framework 3 y que a mi, personalmente, me encanta...
Que es WCF? Bueno... pues resumiendo podriamos decir que se trata de una nueva API para la comunicación de aplicaciones o procesos. Sï, sí... una nueva API más. Hombre, la primera pregunta que uno se hace es si es necesaria otra API más, ya que en la historia microsoft relativamente reciente (vamos .NET) tenemos ya un buen número de APIs que se encargan de comunicar procesos de alguna manera u otra:

1. System.Messaging: Para el uso de colas de mensajes, donde ni emisor ni receptor deben estar on-line.
2. Servicios web asmx: Para la realización de servicios web en ASP.NET, que permiten interoperar aplicaciones realizadas en distintas tecnologias.
3. WSE: Añade mejoras a los servicios web de ASP.NET para permitir el soporte de estándares más avanzados.
4. .NET Remoting: Para el uso de aplicaciones .net basadas en objetos distribuidos.
5. Enterprise Services: Para el uso de servicios COM+

En resumen... 5 APIs distintas para realizar lo mismo: comunicar procesos. Claro está que cada una tiene sus características y debe evaluarse cual debe usarse en cada caso... y ahí radica el primer problema: cuando arquitecturamos una aplicación tenemos que decidir cual de esas APIs vamos a usar para comunicar la aplicación con el exterior. Ojo, que son APIs completamente distintas, así que si nos equivocamos, cambiar de una a otra no es fácil.
Y ahora, aparece una nueva API... qué podemos decir de ella?
Pues básicamente que WCF es a las APIs de comunicaciones lo que el Anillo Único es en los Anillos de Poder: es una API para dominarlas a todas.

Para entendernos: WCF unifica todas las APIs de comunicaciones previamente existentes en una de sola. Da igual si vamos a usar web services, COM+, objetos distribuidos en .NET o colas de mensajes asíncronas: usaremos WCF para desarrollar la aplicación. Eliminamos pues la decisión de que API usar. A grosso modo podríamos decir que no hay necesidad en el framework 3, de usar ninguna de las otras APIs existentes (que evidentemente se mantienen): todo podemos hacerlo usando una sola API, usando WCF.

A los que tengais experiencia en la creación de aplicaciones distribuidas en .NET, esto igual os suena un poco a quimera: conceptualmente Servicios Web asmx y System.Messaging se parecen como un huevo a una castaña... ¿cómo se han podido unificar? Pues tranquilos: veremos que se ha podido y como se ha hecho ;-)

De momento vamos a quedarnos con dos conceptos clave:

1. WCF unifica todo el resto de APIs de comunicaciones que existían en el universo .NET
2. WCF es una API orientada a servicios: Los servidores exponen servicios que los clientes consumen.

En el próximo post vermos lo que los anglosajones llaman el ABC de WCF...

Saludos!