{ MVC } - ¿Cómo lo usamos en Visual Studio?

Hola a tod@s, ya sabemos un poco sobre el patrón de diseño MVC gracias al articulo anterior ¿Qué es MVC? donde pudimos ver cual es su concepto y filosofía. Ahora veamos como aplicamos este concepto en una solución web con tecnología .Net creando una aplicación basada en este patrón.

Cuando le indicamos a Visual Studio que deseamos crear un nuevo proyecto o aplicación web basándonos en el patrón de desarrollo MVC, este nos ofrece la posibilidad de crear proyectos web usando templates o plantillas prediseñadas que nos ahorran mucho trabajo. Veamos las más importantes:

Tipos de plantillas:

Empty

Esta plantilla agrega las referencias, recursos y estructura de directorios mínimos requeridos para que una aplicación de ASP.NET MVC funcione.

Empty

Esta opción es ideal si deseas crear todo desde cero.

Basic

Esta plantilla agrega las referencias y recursos o estructura de directorios mínimos requeridos para que una aplicación de ASP.NET MVC funcione. Además de esto, adiciona los directorios content, Script y Shared.

• El directorio content se usa para guardar los archivos CSS e imágenes que requiera la aplicación, en este la plantilla Basic adiciona archivos CSS básicos.

• El directorio Script se usa para agregar los archivos de extensión js o javascript, en este la plantilla Basic adiciona archivos js básicos como el framework de JQuery.

• El directorio Shared se usa para agregar vistas parciales compartidas por toda la aplicación, en este la plantilla Basic adiciona: el layout o página maestra, una vista para manejo de errores no controlados y una vista llamada _ViewStart donde se especifica cual es el layout por defecto que usarán las otras vistas en caso que no se especifique alguno.

Además de lo anterior, la plantilla adiciona al directorio App_Start un archivo llamado BundleConfig.cs que permite optimizar los tiempos de carga de archivos JS y CSS.

Basic

Esta opción es ideal si deseas crear todo desde cero pero, con algunos archivos necesarios que deseas se agreguen desde el inicio a diferencia de la plantilla Empty.

Internet Aplication

Esta plantilla, tiene lo de la plantilla anterior y además es totalmente funcional, es decir, si la ejecutamos veremos una aplicación web funcionando en el explorador. Eso gracias a que cuenta con 2 controladores (AccountController y HomeController) con toda la lógica y funcionalidad implementada en acciones y vistas. La funcionalidad implementada le brinda la posibilidad al usuario de registrarse, identificarse o autenticarse, cambiar la contraseña, ver la página de About y Contacto. Este proyecto se puede usar de base para implementar su aplicación web.

Internet Aplication

Esta opción es ideal si el proyecto que deseas iniciar, ya esta tan claro que sólo requiere agregar las vistas y controller necesario y modificar las plantillas de presentación.

Intranet Aplication

Esta aplicación cuenta con lo mismo de la anterior, pero su autenticación es en base al directorio activo de Windows.

Intranet Aplication

Esta opción es ideal para aplicaciones que se deseen implementar al interior de una empresa.

Mobile Aplication

Esta aplicación es otra variación de la plantilla Internet Aplication, en este caso la plantilla esta optimizada para trabajar con dispositivos móviles.

Mobile Aplication

Esta opción es ideal para aplicaciones que van a usarse en dispositivos móviles.

Web API

Esta aplicación es otra variación de la plantilla Internet Aplication, en este caso la plantilla cuenta con un controlador Web API preconfigurado. Una Web API es un servicio que se consume por HTTP. ASP.NET WebAPI es el nuevo framework de la familia .NET que tiene como objetivo el facilitarnos en gran medida la construcción de aplicaciones RESTFul orientadas a ofrecer servicios, como podría ser Twiter, World of Warcraft, Amazone o Windows Azure(Aquí tienes documentación: DosIdeas).

Web API

Esta opción es una gran opción si se desean construir servicios de datos que las aplicaciones puedan consumir fácilmente a través de AJAX.

View Engines

Es el lenguaje que utilizamos para escribir en la vista código del lado del servidor, ese código se ejecuta en el servidor antes de dibujar la vista y este devuelve código HTML que es dibujado en la página. Maneja el rendering de las vistas a la pantalla en forma de HTML o XML. Estos usan diferentes sintaxis, ASP.NET maneja 2 Razor y AXPX (Web Form).

Razor (Aquí tienes documentación: MSDN) es el view engine recomendado para MVC.

Muy bien, espero que esta información les haya servido para identificar los distintos tipos de proyectos que Visual Studio nos permite crear. En la próxima entrega vamos a crear nuestra primera aplicación web basada en el patrón de diseño MVC.

Quedo atento a cualquier inquietud.

¡¡Hasta pronto!!

Estos contenidos se publican bajo una licencia de Creative Commons

{ MVC } - ¿Que es MVC?

Hola a tod@s, ya me estaba sintiendo en deuda con todos ustedes porque hace tiempo no publicaba nada. Realmente creo que es obligación de todos compartir el conocimiento adquirido durante el recorrido en este mundo apasionante que es el software, y recibir retroalimentación de la comunidad para seguir creciendo.

En esta ocasión quiero compartir con ustedes una serie de conocimientos que he estado adquiriendo sobre el patrón de diseño MVC. Iniciemos: Primero miremos de que se trata este concepto.

¿Qué es MVC?

Much@s alguna vez nos preguntamos y ¿qué es esa cosa del MV C que tanto se está mencionando actualmente? Aquí te tenemos una definición de eso que tanta curiosidad está generando. MVC es un patrón arquitectónico cuyo principal propósito es establecer una separación clara entre la interfaz de usuario que presenta la aplicación y la lógica de negocio que maneja la misma. Es decir, queremos tener el control de todo en nuestra aplicación y la mejor manera de hacerlo es separando las cosas. Recuerden la filosofía que usamos en software “divide y vencerás” (Aquí tienes documentación: Wikipedia).

Los elementos que componen el patrón son los siguientes:

• Modelo: Es la representación de los datos o entidades de negocio que modelan la aplicación. Es decir, una aplicación por lo general requiere manejar una cantidad de datos que servirán para realizar una cantidad de operaciones más adelante. El modelo es el lugar donde se encuentra la lógica que nos permite guardar en la base de datos e interactuar con esos datos tan importantes. Estos datos nos permitirán desplegar vistas al usuario con los datos procesados.
• Controlador: Es el elemento encargado de recibir y procesar las peticiones HTTP para después retornar una vista concreta. Es aquí donde se reciben todas las solicitudes del cliente, se procesa la petición y se envía al mismo la respuesta relacionada.
• Vista: Es el contenido o resultado que va a ser devuelto como consecuencia de la petición HTTP. También se puede decir que es la representación visual del modelo. Por eso la vista puede recibir el modelo para poder realizar la presentación de los datos.

Visualmente el patrón se ve asi:

Figura sacada de Fuente

Como podemos ver, el controlador es el encargado de interactuar con el modelo y las vistas. Aunque estas pueden acceder al modelo también, la interacción debe estar centralizada en el controlador para tener un solo punto de procesamiento y no regar lógica de negocio en toda la aplicación. La vista puede acceder al modelo porque en muchas ocasiones necesita las propiedades de las entidades de negocio para presentar los datos al cliente.

El flujo que debe seguir una aplicación que esté basada en este patrón es el siguiente: el cliente realiza una petición HTTP al servidor, este revisa la ruta de la misma y dirige la petición hacia una acción del controlador de la aplicación. El controlador procesa la información y solicita, si es necesario, datos al modelo. Recibida la información del modelo, el controlador la procesa y se la pasa a la vista para que esta se la despliegue al cliente. La vista tiene como objetivo mostrar información. Los procesamientos deben realizarse en el controlador.

Muy bien, espero esto les haya servido para aclarar el concepto implementado por el patrón MVC. En la próxima entrega vamos a iniciar con la implementación de una aplicación web que nos ayudará a ver el funcionamiento del patrón en .Net

Quedo atento a cualquier inquietud.

¡¡Hasta pronto!!

Estos contenidos se publican bajo una licencia de Creative Commons

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.