Utilizando ficheros de configuración

Durante el diseño de WCF, se tuvo en mente el desacoplamiento de la configuración. Esto con el objetivo de brindar la posibilidad de realizar cambios en el servicio sin necesidad de volver a compilar el código, este es uno de los puntos fuertes de WCF. Esto aporta dos grandes ventajas: la flexibilidad de adaptar el sistema a las condiciones del entorno sin la necesidad de modificar el código fuente, y permitir que un administrador de sistemas tome ciertas decisiones en la implantación del sistema, tales como puertos de escucha, aspectos de seguridad, etc.

.Net hace uso extenso de ficheros de configuración XML y normalmente llevan como extensión .config. WCF también usa ficheros XML para la configuración de servicio, tanto a nivel de servidor como cliente.

Volviendo al ejemplo del servidor de consola visto anteriormente, podemos eliminar todo el código relativo a la configuración del servicio y definir la misma en un fichero de configuración que llamaremos app.config.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <services>
      <service name="Webservices.Implementacion.ReservaVuelos">
        <endpoint name="ReservaVuelos"
                  address="ReservaVuelos"
                  binding="basicHttpBinding"
                  contract="WebServices.Interfaces.IRerservaVuelos" />
        <host>
          <baseAddresses>
            <add baseAddress="http://localhost:8080/" />
          </baseAddresses>
        </host>
      </service>
    </services>
  </system.serviceModel>
</configuration>

Todo fichero de esta clase, debe llevar una sección <system.serviceModel> la etiqueta <services> lleva un nombre que debe coincidir con el nombre del tipo de dato que se pasa al constructor de ServiceHost, que en esencia es el nombre de la clase que implementa el servicio. Como cada servicio debe exponer al menos un Endpoint, dentro del service se declara esta sección que debe contar con los tres atributos explicados anteriormente address, binding y contract. También es necesario definir una dirección base que servirá para indicar la IP y el puerto del servicio si esto fuera necesario.
El endopoint cuenta con un atributo address que nos sirve para definir la URI del servicio. Para este caso, la dirección del servicio sería http://localhost:8080/ ReservaVuelos. Tanto la dirección base como alguna relativa siempre deberían definirse externamente en el fichero de configuración para así evitar que un servicio dependa de una dirección lógica. Además, le brinda la posibilidad al administrador hacer cambios en la configuración sin necesidad de recompilar el código.
En el cliente se debe realizar la misma configuración 

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="BasicHttpBinding_IReservaVuelos" closeTimeout="00:01:00"
                    openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                    allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
                    maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                    messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
                    useDefaultWebProxy="true">
                    <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
                        maxBytesPerRead="4096" maxNameTableCharCount="16384" />
                    <security mode="None">
                        <transport clientCredentialType="None" proxyCredentialType="None"
                            realm="" />
                        <message clientCredentialType="UserName" algorithmSuite="Default" />
                    </security>
                </binding>
            </basicHttpBinding>
        </bindings>
        <client>
            <endpoint address="http://localhost:8080/ReservaVuelos"
                binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IReservaVuelos"
                contract="WebServices.Proxy.IReservaVuelos" name="BasicHttpBinding_IReservaVuelos" />
        </client>
    </system.serviceModel>
</configuration>

Hay varias versiones sobrecargadas del constructor de ReservaVuelos. Si se utiliza el constructor sin parámetros, se buscará un endpoint en el fichero de configuración que tenga el mismo tipo de contrato que el especificado por ReservaVuelos. Opcionalmente se puede pasar el nombre del endpoint. Al igual que en el servidor, la dirección se puede definir de modo imperativo en el código o en el fichero de configuración, que por razones obvias, es más flexible.

Estos contenidos se publican bajo una licencia de Creative Commons

WCF - 5.2 Primer ejemplo (Hospedando en un servicio de windows)

Hospedar un WebService en una aplicación de consola puede no ser lo mas práctico. Este tipo de aplicaciones esta muy expuesta a ser cerradas por accidente, no se recuperan automáticamente y siempre deben estar vigiladas por usuarios finales. Quizá una de las mejores opciones para hospedar un servicio WCF, sea la de un servicio windows, ya que ofrece una serie de ventajas no presentes en alguna de las otras posibilidades. Entre estas, se encuentra la posibilidad de automáticamente recuperarse de una parada no esperada, así como el arranque del servicio antes de cualquier proceso de login, entre otras. Veamos como podemos hospedar un servicio WCF dentro de un servicio windows.

using System;
using System.ServiceModel;
using System.ServiceModel.Description;
using System.ServiceProcess;
 
using WebServices.Interfaces;
 
namespace WebServices.Host.WindowService
{
    partial class ReservaVuelos : ServiceBase
    {
        private ServiceHost objHost = null;
 
        public ReservaVuelos()
        {
            InitializeComponent();
 
            if (!System.Diagnostics.EventLog.SourceExists("ResourceReservaVuelos"))
            {
                System.Diagnostics.EventLog.CreateEventSource("ResourceReservaVuelos", "logReservaVuelos");
            }
 
            this.objEventViewer.Source = "ResourceReservaVuelos";
            this.objEventViewer.Log = "logReservaVuelos";
            this.objEventViewer.WriteEntry("Se inicia log de eventos del servicio ReservaVuelos");
        }
 
        protected override void OnStart(string[] args)
        {
            this.objEventViewer.WriteEntry("Se inicia el servicio de reserva de vuelos");
 
            Uri objUri = new Uri("http://localhost:8080/ServicioReservaVuelos");
            BasicHttpBinding objBinding = new BasicHttpBinding();
 
            this.objHost = new ServiceHost(typeof(WebServices.Implementacion.ReservaVuelos), objUri);
            this.objHost.AddServiceEndpoint(typeof(IReservaVuelos), objBinding, "");
 
            try
            {
                /// Esto se utiliza para mostrar la metadata del servicio.
                ServiceMetadataBehavior objMetadata = new ServiceMetadataBehavior();
                objMetadata.HttpGetEnabled = true;
                this.objHost.Description.Behaviors.Add(objMetadata);
 
                this.objHost.Open();
            }
            catch (Exception ex)
            {
                this.objEventViewer.WriteEntry("Error: \n" + ex.Message);
            }
        }
 
        protected override void OnStop()
        {
            this.objEventViewer.WriteEntry("Se detiene el servicio de reserva de vuelos");
            
            if(this.objHost != null)
                this.objHost.Close();
        }
    }
}

Estos contenidos se publican bajo una licencia de Creative Commons

WCF - 5.1 Primer ejemplo (Consumiendo el servicio)

Tener un servicio disponible sirve de poco si no se puede utilizar. Para poder consumirlo, debemos implementar en nuestro cliente los pasos necesarios para poder hablar con el servidor. Vamos a encapsular toda la comunicación que tiene lugar, mediante un objeto proxy que se encargará de interactuar con las operaciones expuestas por el servidor. Así el proxy tendría un método por cada operación que expone el servicio. Al adaptar esto a nuestro ejemplo, el proxy tendría un objeto ReservaVuelos con un método  llamado ObtenerCodigoAeropueto que tomaría dos parámetros de entrada ciudad y pais, y devolvería una cadena como resultado. Encapsulado dentro de este objeto proxy, estaría toda la funcionalidad de intercambio de mensajes entre el cliente y el servidor.

Para construir nuestro proxy, vamos a utilizar una herramienta que viene con el sdk denominada svcutil que nos permite generar automáticamente el objeto proxy conociendo únicamente el objeto de descripción del servicio, es decir, el WSDL. Hay que tener en cuenta que el servicio debe estar activo y contar con permisos de escritura sobre el directorio donde se encuentra ubicado el ejecutable svcutil (c:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\) . Vamos a crear un nuevo proyecto de librería de clases donde ubicaremos todos nuestros proxy y ejecutamos la siguiente linea de comandos en el cmd.

svcutil.exe /language:cs /out:ReservaVuelos.cs /config:app.config /namespace:*,WebServices.Proxy /ct:System.Collections.Generic.List`1 http://localhost:8080/ServicioReservaVuelos?wsdl

Después de ejecutar esta linea, se crearán 2 archivos. Uno de ellos es el fichero que contiene el objeto proxy y por defecto, se nombra igual que la implementación del contrato. En este caso, le cambiamos el nombre por ReservaVuelos.cs y el otro es un fichero de configuración que por defecto se le nombra output.config. En este caso, le cambiamos el nombre por app.config.

Buscamos estos dos archivos en la ruta donde se encuentra el svcutil.exe y los añadimos a nuestro proyecto de proxys. Recuerden que este proyecto debe tener una referencia a la libreria System.ServiceModel. 

Nuestro objeto proxy es el siguiente.

public partial class ReservaVuelosClient : System.ServiceModel.ClientBase<WebServices.Proxy.IReservaVuelos>, WebServices.Proxy.IReservaVuelos
    {
        
        public ReservaVuelosClient()
        {
        }
        
        public ReservaVuelosClient(string endpointConfigurationName) : 
                base(endpointConfigurationName)
        {
        }
        
        public ReservaVuelosClient(string endpointConfigurationName, string remoteAddress) : 
                base(endpointConfigurationName, remoteAddress)
        {
        }
        
        public ReservaVuelosClient(string endpointConfigurationName, System.ServiceModel.EndpointAddress remoteAddress) : 
                base(endpointConfigurationName, remoteAddress)
        {
        }
        
        public ReservaVuelosClient(System.ServiceModel.Channels.Binding binding, System.ServiceModel.EndpointAddress remoteAddress) : 
                base(binding, remoteAddress)
        {
        }
        
        public string ObtenerCodigoAeropuerto(string ciudad, string pais)
        {
            return base.Channel.ObtenerCodigoAeropuerto(ciudad, pais);
        }
    }

Ahora en un proyecto de presentación aparte, que para este caso vamos a utilizar uno de consola, vamos a hacer uso de este objeto proxy el cual nos ayudará a consumir las operaciones expuestas por nuestro servicio.

using System;
using System.ServiceModel;
 
using WebServices.Proxy;
 
namespace Presentacion.WebService.Console
{
    class Program
    {
        static void Main(string[] args)
        {
            EndpointAddress objAddress = new EndpointAddress("http://localhost:8080/ServicioReservaVuelos");
            BasicHttpBinding objBindig = new BasicHttpBinding();
            ReservaVuelosClient objProxy = new ReservaVuelosClient(objBindig,objAddress);
            bool blnContinuar = true;
            string ciudad = string.Empty;
            string pais = string.Empty;
            string continuar = string.Empty;
 
            do
            {
                try
                {
                    ciudad = string.Empty;
                    pais = string.Empty;
                    continuar = string.Empty;
 
                    System.Console.WriteLine("Ciudad: \n");
                    ciudad = System.Console.ReadLine();
                    System.Console.WriteLine("\nPaís: \n");
                    pais = System.Console.ReadLine();
 
                    System.Console.WriteLine(objProxy.ObtenerCodigoAeropuerto(ciudad,pais));
                    System.Console.WriteLine("\nContinuar: \n 1. Sí\n 2. No");
                    continuar = System.Console.ReadLine();
                    if(continuar.Equals("2"))
                    {
                        blnContinuar = false;
                    }
                }
                catch (Exception ex)
                {
                    System.Console.WriteLine("Ha ocurrido un error al intentar conectarse con el servicio: \n" + ex.Message);
                    blnContinuar = false;
                    System.Console.ReadLine();
                }
            } while (blnContinuar);
        }
    }
}

Creamos un EndPointAddress para indicar la dirección y puerto de conexión, así como un BasicHttpBinding para fijar el protocolo de comunicación. Estos dos objetos se pasan por parámetro al proxy ReservaVuelosClient que nos lo creó svcutil anteriormente. Seguidamente solicitamos los parámetros de consulta ciudad y pais para solicitar el código de aeropuerto relacionado. Llamamos al método ObtenerCodigoAeropuerto con los parametros necesarios y mostramos el resultado. El bloque try...catch es para controlar cualquier error que pueda ocurrir durante la comunicación.

Estos contenidos se publican bajo una licencia de Creative Commons

WCF - 5. Primer Ejemplo (Reserva de vuelos)

Este primer ejemplo consiste en crear parte de un sistema de reserva típico donde el cliente hace una búsqueda de vuelo y procede a efectuar la reserva, registrándose previamente. Este ejemplo se compone de varios componentes que iremos desarrollando a medida que haga falta. Sin embargo, para empezar, lo primero que necesitamos ofrecer al cliente, es un sistema de búsqueda de vuelo.

Nuestro primer objetivo es obtener los aeropuertos que intervienen en el vuelo. Es necesario crear un procedimiento que dado el nombre de una ciudad, devuelva el aeropuerto de dicha ciudad. Teniendo estos aeropuertos, podremos proceder a la búsqueda de vuelos disponibles mas adelante.

Como se explicó anteriormente, un servicio web se compone de 3 valores, donde, como y que. Estos valores se identifican con Address, Binding y Contract y la unión de estos componen el Endpoint.

Definición del contrato (Contract)

Lo primero que debemos definir claramente es lo que se va a ofrecer y las condiciones bajos las cuales se va a llevar a cabo. La mejor manera de definir esto es mediante interfaces, ya que una interfaz es una serie de condiciones que una clase que la implementa debe cumplir, es decir, un contrato.

En un proyecto de librería de clases, vamos a manejar todas las interfaces que necesitemos.

using System.ServiceModel;
 
namespace WebServices.Interfaces
{
    [ServiceContract]
    public interface IReservaVuelos
    {
        [OperationContract]
        string ObtenerCodigoAeropuerto(string ciudad, string pais);
    }
}

El proyecto debe contar con la referencia a System.ServiceModel. Esto es el espacio de nombre para aplicaciones que hacen uso de WCF. Se pueden observar 2 atributos, ServiceContract y OperationContract. El primero indica que la interfaz que se define es el contrato de servicio que se va a implementar. El segundo indica que el procedimiento que decora es una operación que el servicio ofrece.

Implementación del servicio

Teniendo el contrato definido, el siguiente paso es implementarlo. Para esto creamos otro proyecto de librería de clases y le adicionamos la referencia a System.ServiceModel y a nuestro proyecto de interfaces. La clase que va a implementar la interface es la siguiente:

using WebServices.Interfaces;
 
namespace WebServices.Implementacion
{
    public class ReservaVuelos : IReservaVuelos
    {
        public string ObtenerCodigoAeropuerto(string ciudad, string pais)
        {
            string strRespuesta = string.Empty;
 
            if (pais.Equals("Colombia"))
            {
                switch (ciudad)
                {
                    case "Medellin":
                        strRespuesta = "EOH";
                        break;
                    case "Bogota":
                        strRespuesta = "BOG";
                        break;
                    case "Cali":
                        strRespuesta = "CLO";
                        break;
                    default:
                        strRespuesta = "Desconocido";
                        break;
                }
            }
            else
            {
                strRespuesta = "País desconocido";
            }
 
            return strRespuesta;
        }
    }
}

Hospedando el servicio (Address).

Para poder exponer un servicio, hay que hospedarlo dentro de un proceso, que puede ser cualquier aplicación de Windows, ya sea consola, una aplicación de escritorio, un servicio windows o incluso dentro de IIS. Para ello, es necesario crear lo que se denomina un ServiceHost, que es la clase que se encarga de hospedar el servicio. Vamos a optar por una aplicación de consola.

El constructor de ServiceHost toma dos parámetros, el tipo de servicio implementado y una dirección base. La dirección base indica en que dirección IP y puerto estará escuchando el servicio. Además se puede incluir de manera opcional, una ruta permitiendo de eta forma tener mas de un servicio hospedado en la misma combinación de puerto y dirección IP.

Después de realizar los dos pasos anteriores, tenemos dos proyectos: la definición del contrato y una implementación. Sin embargo esto no es suficiente para poder exponer el servicio para su consumo por los clientes. En este punto sólo tenemos el que y el donde, es necesario definir el como para poder exponer dicho servicio. 

Bindign

A parte de definir lo que vamos a ofrecer (contract) y donde esta definido(address), falta una pieza para completar el Endpoint: el binding, que indica las condiciones bajo las cuales el servidor y el cliente se van a comunicar. Entre muchos de los aspectos que define, una de ellas es el protocolo de transporte. Para nuestro caso el servicio se va a exponer utilizando el protocolo Http. WCF define varios bindings que utilizan este protocolo, siendo el más simple BasicHttpBinding.

Teniendo los parámetros anteriores, procedemos a crear el ServiceHost, asociarle una dirección, un protocolo y archivarlo.

using System;
using System.ServiceModel;
using System.ServiceModel.Description;
 
using WebServices.Interfaces;
using WebServices.Implementacion;
 
namespace WebServices.Host.Console
{
    class Program
    {
        static void Main(string[] args)
        {
            Uri objUri = new Uri("http://localhost:8080/ServicioReservaVuelos");
            ServiceHost objHost = new ServiceHost(typeof(ReservaVuelos), objUri);
            BasicHttpBinding objBinding = new BasicHttpBinding();
 
            objHost.AddServiceEndpoint(typeof(IReservaVuelos), objBinding, "");
 
            try
            {
                /// Esto se utiliza para mostrar la metadata del servicio.
                ServiceMetadataBehavior objMetadata = new ServiceMetadataBehavior();
                objMetadata.HttpGetEnabled = true;
                objHost.Description.Behaviors.Add(objMetadata);
 
                objHost.Open();
 
                System.Console.WriteLine("El servicio de reservas esta activo en: \n" + objUri.AbsoluteUri);
                System.Console.WriteLine("\n\nPulse [ENTER] para detener el servicio.");
                System.Console.ReadLine();
            }
            catch (Exception ex)
            {
 
            }
            finally
            {
                objHost.Close();
            }
        }
    }
}

Una vez que se ha definido el ServiceHost, se procede a activarlo llamando al método Open(). Este método lanzará una hebra secundaria para procesar las peticiones y devolverá el flujo del programa a la siguiente instrucción, donde se escribe información sobre el servicio.

Al estar utilizando Http como protocolo de comunicación, se puede utilizar el navegador para comprobar que el servicio esta activo. Introduciendo la dirección correspondiente en el navegador, saldrá el siguiente mensaje.

Podemos ver la descripción del servicio dando clic sobre la url. Veamos parte de lo que se obtiene.

Estos contenidos se publican bajo una licencia de Creative Commons

WCF - 4. Estructura de los servicios WCF

En todo servicio WCF intervienen dos partes, el cliente y el servidor. El servidor es la parte que atiende las peticiones de una serie de servicios que ofrece, y el cliente es la que consume estos servicios, y todo ello tiene lugar mediante el intercambio de mensajes. Para que el cliente pueda comunicarse con el servidor, debe conocer donde se encuentra ubicado éste, por ejemplo, la dirección IP y el puerto, debe conocer el protocolo, para saber como se va a comunicar y por ultimo, de tener conocimiento de los servicios que ofrece el servidor, es decir, que es lo que va a consumir.

ENDPOINT

En WCF los tres valores donde, como y que, se identifican con Address, Binding y Contract, y la unión de todos ellos constituye lo que se denomina Endpoint, y dependiendo de la configuración de cada uno, puede ofrecerse servicios distintos o los mismos bajos condiciones distintas.

Cuando el cliente se comunica con el servidor, debe hacerlo cumpliendo las condiciones expuestas por éste. Por ello, el concepto de endpoint, es aplicable también al cliente. De esta manera, el cliente que quiera comunicarse con el servidor, debe tener un endpoint con las mismas características.

WCF - 3. Objetivos de un Servicio Web

Los objetivos de SOA se pueden resumir en:

• Las fronteras son explícitas: Cuando creamos un servicio y lo ponemos a disposición para su consumo, no sabemos ni quien ni cómo se va a consumir éste. Puede ser un sistema en nuestra red local, o puede ser una aplicación remota al otro lado del mundo; el consumidor igual tiene que consumir el servicio atravesando un cortafuegos o a través de un proxy. Cuando se define un servicio hay que tener en cuenta que consumirlo puede ser muy costoso ya sea en ancho de banda, tiempo o gestiones de seguridad. Por eso hay que definir el interfaz público de manera concisa y mantenerlo al mínimo ya que cuanto mas amplio sea, mayor coste de mantenimiento requiere. A su vez, ningún detalle de las operaciones internas deben filtrarse al lado público. Al igual que un país, un servicio debe tener bien definidas sus fronteras y las normas con las que opera.
• Los servicios son autónomos: Un servicio debe depender de sí mismo. Cuando se diseña un servicio, hay que considerar que no se despliega en un entorno infalible. Hay muchos factores alrededor que pueden causar una falla. Un cambio de localización, un acceso erróneo, tanto si es intencionado como fortuito no deben causar una caída del servicio. Por ello, se deben minimizar las dependencias externas, y esto se consigue mediante un correcto desacoplamiento.
• Se deben compartir contratos: Teniendo en cuenta que un servicio puede ser una operación costosa, es muy importante limitar al máximo cualquier cambio en las condiciones bajo las que se ofrece un servicio. Para dejar constancia de estas condiciones y garantizar una estabilidad, se debe acordar un contrato entre las partes. Para no imponer restricciones en la implementación de las operaciones, se conviene establecer los contratos para ello por medio de interfaces.
• Adaptable a las políticas externas: Un servicio se puede desplegar en distintos entornos, con distintas políticas de seguridad, fiabilidad y rendimiento. Los servicios deben poder adaptarse a estos entornos dispares sin mucho esfuerzo, y sin la necesidad de rediseñar el sistema.

La idea detrás de SOA es permitir la integración de sistemas de manera flexible, fácil, fiable y escalable. 

Estos contenidos se publican bajo una licencia de Creative Commons

WCF - 2. Servicio Web

Como vimos anteriormente, uno de los mayores problemas con las tecnologías existentes para el desarrollo de aplicaciones distribuidas, además de ser propietario, es que están enfocados hacia una comunicación orientada a la conexión, es decir, el cliente tiene que estar conectado durante todo el transcurso de la comunicación con el servidor.

La necesidad de comunicar distintos fabricantes y aplicaciones, dieron lugar a la creación de un estándar abierto basado en un protocolo que por su naturaleza es sin estado, el HTTP. El consorcio W3C define los servicios web como un software que permite la iteroperabilidad entre sistemas heterogéneos utilizando estandares como SOAP Y XML. La idea detrás de los servicios web es la de exponer operaciones que puedan ser llamadas por clientes.

Los servicios web nos permiten hablar de un conjunto de sistemas que se comunican entre sí mediante mensajes, donde cada uno de ellos define una serie de servicios y unas condiciones bajos las cuales se ofrecen. 

Estos contenidos se publican bajo una licencia de Creative Commons

{ WCF [ Windows Comunication Fundation ] } - Contextualización

Hasta la aparición de WCF, cuando uno se proponía realizar una aplicación distribuida, se le presentaban numerosas opciones: DCOM, .NET Remoting, Servicios Web o incluso sockets nativos; .Net Remoting por ejemplo, permitía realizar aplicaciones distribuidas donde se podía llamar remotamente a objetos, y en cambio los servicios web estaban más enfocados a arquitectura orientada a servicios.

El problema de disponer de tantas tecnologías es que cada sistema se implementaba de una forma más acomodada a los requerimientos. Esto significa un gran problema de comunicación a la hora de intentar poner a interactuar un sistema con otro debido a que hablan en idiomas distintos. Para poner un ejemplo, supongamos una agencia de viajes que se alimenta de múltiples proveedores de servicios aéreos, hoteleros y alquiler de autos, para de esta forma ofrecerle a sus clientes la mejor opción; siempre y cuando todos los servicios que consume la agencia de viajes trabajen con el mismo sistema que en este caso es .Net Remoting, podrá comunicarse con cada uno de ellos sin ninguna trascendencia. Sin embargo, el problema surge cuando aparece en el escenario un nuevo proveedor de servicio de viajes aéreos que ofrece unas condiciones muy favorables. La agencia de viajes tiene un gran interés de comunicarse con este proveedor. Pero para ello, debe adaptar su sistema para poder comunicarse con su nuevo proveedor, que ofrece su API mediante servicios web. El sistema de comunicación original esta enfocado hacia una interacción mediante .Net Remoting. Cambiarlo para utilizar servicios web no es tarea fácil. De hecho es un cambio muy sustancial que requiere rediseñar aspectos de la arquitectura del sistema y si el día de mañana aparece otra entidad que requiere utilizar mensajería para las comunicaciones, de nuevo hay que adaptar el diseño. Todo esto requiere de un coste enorme de desarrollo y mantenimiento para la empresa.

Cuando diseñamos un sistema distribuido o cualquier aplicación que requiera una comunicación, necesariamente adaptamos esa comunicación con el diseño del sistema, limitando la extensibilidad y versatilidad del sistema. Lo que pretende WCF (Windows Comunication Fundation) es justamente separar esto, permitiendo desvincular nuestro diseño de la cumunicación que pueda tener lugar. Así, un mismo sistema puede comunicarse mediante mensajería como podría con servicio web sin necesidad de cambiar el diseño. Por lo tanto nuestro esquema de capas quedaría como el siguiente.

Estos contenidos se publican bajo una licencia de Creative Commons