Una Mojca Más

Una de las novedades que más me ha gustado de las nuevas versiones de nuestros lenguajes son los métodos extensores.

Es una particularidad que yo he usado algunas veces en javascript y que consistía en añadir un nuevo método al prototype de una clase, para que todas las instancias de una clase lo tuvieran. Esto es bastante normal en la programación orientada a objetos al crear nuestras propias clases, pero lo bueno es que podemos hacerlo también con las clases del Framework: por ejemplo con la clase String.

Para hacerlo la forma difiere un poco al hacerlo en C# que en Visual Basic pero ambos lenguajes ya soportan esta funcionalidad.

C#

Para crear un método extensor en C# usamos la palabra reservada this al primer parámetro del método. Además solo se pueden declarar dentro de clases estáticas.

Si nos creamos nuestra librería, definiríamos nuestro método extensor así:

using System;

namespace MetodosExtensores

{

    public static class Extensiones

    {

        public static int ElevarA(this int num, int potencia)

        {

            return (int)Math.Pow(num, potencia);

        }

    }

}

Ahora en nuestro programa, podemos usar estos métodos solo importando la librería:

using System;

using MetodosExtensores;

namespace Miprograma

{

    class Program

    {

        static void Main(string[] args)

        {

            int num = 2,potencia = 5;

            int resultado = num.ElevarA(potencia);

            //Equivalente a hacer esto:

            //int resultado = Extensiones.ElevarA(num, potencia);

            Console.WriteLine("{0} elevado a {1} es {2}", num, potencia, resultado);

            Console.ReadLine();

        }

    }

}

Visual Basic .NET

En este caso lo que debemos usar es un atributo antes del método para indicar que va a ser un método extensor. Además solo pueden estar definidos dentro de módulos:

Namespace MetodosExtensoresVB

    Public Module Extensiones

        <System.Runtime.CompilerServices.Extension()> _

        Public Function ElevarA(ByVal num As Integer, ByVal potencia As Integer)

            Return CType(Math.Pow(num, potencia), Integer)

        End Function

    End Module

End Namespace

Como vemos puede sernos de gran utilidad en algunas ocasiones.

Además también han añadido una nueva funcionalidad en Visual Basic 9: el Operador Ternario.

Lo que todos los programadores en C# y en C conocíamos como:

string msn = a > b ? "a>b" : "a<=b";

Ahora también lo podemos hacer en Visual Basic así:

Dim msg as String = If( a>b ? "a>b", "a<=b")

Poco a poco nuestro lenguajes van mejorando y haciéndonos la vida más fácil.

Artículos anteriores:
Tutorial WCF (1 de 5)
Tutorial WCF (2 de 5)
Tutorial WCF (3 de 5)
Tutorial WCF (4 de 5)

5 – CREANDO UN CLIENTE

La forma más fácil i rápida de crear un cliente/consumidor de un servicio de WCF es con la ayuda de Visual Studio. La forma de hacerlo es muy parecida a cómo lo hacíamos cuando se trataba de un Servicio Web del Framework 2.0: en nuestro proyecto donde queremos consumir un servicio tenemos la opción de Add Service Reference, pero en este caso la dirección que indicaremos no solo tiene porque ser http://…; también podemos introducir los diferentes protocolos net.tcp://…, net.pipe://… o net.msmq://… Al introducir una dirección correcta Visual Studio utiliza una herramienta que lee la metadata que le brinda el servicio (el contrato WSDL) y genera clase proxy que nos comunicará con el servicio. Podemos ver el código generado expandiendo la carpeta Service References en el explorador de soluciones. La herramienta utilizada por el Visual Studio para generar la clase proxy es el svcutil. Podemos generar nosotros mismos la clase proxy desde línea de comandos del SDK (Start->All programs->Microsoft Windows SDK->CMD Shell) (debemos tener el SDK de Windows instalado) utilizando la siguiente instrucción: (debemos ir primero al directorio donde queremos que se nos genere la clase)

svcutil http://localhost:8000/BlogWCF /out:Cliente.cs /config:App.config

Con esta línea le estaríamos diciendo que buscara un servicio que se encuentra en la dirección http://localhost:8000/BlogWCF, que leyera la metadata y generara la clase proxy en el fichero Cliente.cs y que la configuración de los bindings y enpoints necesaria para comunicarse con el cliente la guardara en un fichero llamado App.config.

Ahora ya sabemos como conseguir generar el código necesario para comunicarme con nuestro servicio. Vamos a generar un cliente que lo consuma y muestre algo por pantalla:

Creamos una proyecto de aplicación de consola y lo llamamos ClienteWCF. Yo lo he hecho en Visual Basic para cambiar un poco, pero eso va a gustos. Vamos a crear el proxy para el servicio de la forma rápida: con Visual Studio. Primero hacemos correr el servicio; si queremos usar el del servicio web ya estará corriendo en el IIS, si usamos el que se servía desde una aplicación Host debemos ejecutarla y dejarla funcionando. Hacemos click con el botón derecho encima del nombre de nuestro proyecto «cliente» y seleccionamos Add Service Reference. Ahora debemos colocar la dirección donde se encuentra escuchando nuestro servicio net.tcp://…, o http://…., le damos un nombre al espacio de nombres donde se va a crear nuestra clase proxy y le damos a Go. Nos mostrará una pantalla parecida a esta:

Le damos a OK y ya tenemos creada la clase proxy. Ahora ya podemos crear nuestro cliente, importar el espacio de nombres que le hemos dicho y empezar a utilizar nuestro cliente. El nombre de la clase proxy que invoca los métodos de nuestro servicio es el nombre de nuestro servicio acabado en Client: en nuestro caso MiServicioClient. Ahora podemos hacer que nuestro cliente invoque los métodos de nuestro servicio a través de la clase generada:

Imports ClienteWCF.BlogWCFReference

Module Module1

    Sub Main()

        Console.WriteLine(«Una vez este iniciado « + _

            «el servicio presione una tecla para continuar.»)

        Console.ReadKey(True)

        Dim cliente As New MiServicioClient()

        Dim cumples As Cumple() = cliente.DameCumples()

        For Each cu As Cumple In cumples

            Console.WriteLine(«El cumpleaños de {0} es el {1}», _

                    cu.Nombre, cu.FechaCumple.ToShortDateString())

        Next

        Console.WriteLine()

        Console.WriteLine(«{0} tiene ahora {1} años», _

                          cumples(0), _

                          cliente.DimeEdad(cumples(0)))

        Console.WriteLine()

        Console.WriteLine(«Presiona una tecla para terminar.»)

        Console.ReadKey(True)

    End Sub

End Module

Para poder ejecutarlo el servicio debe de estar activado. Si no usamos el IIS como host sino una aplicación y además está en la misma solución, podemos decirle al Visual Studio que ejecute ambos proyectos a la vez: botón derecho en el nombre de nuestro solución y seleccionamos la opción Set StartUp Projects…. Escogemos la opción de Multiple stratup projects: , ponemos Start en Action tanto en el cliente como en la aplicación Host y aceptamos. Si ahora le damos a ejecutar se abrirán dos consolas: una para el cliente y otra para el host. Primero hacemos que empiece a ejecutarse el servicio y luego la aplicación cliente; el resultado debe ser parecido al siguiente:

Ahora ya sabemos como consumir un servicio de WCF.

Si ahora queremos que lo consuma usando el protocolo TCP no tenemos que hacer nada más que modificar el app.config del cliente. Si lo abrimos veremos que nos ha generado un archivo de configuración parecido a los de antes pero con algunas cositas más. Vemos que, por ejemplo, no solamente le dice que tipo de binding tiene el endpoint si no que también tiene una configuración especial para este binding. Como nosotros no indicamos nada especial en el App.config del servicio (cogimos la configuración por defecto de cada uno de los dos tipos de binding) y el cliente tiene el app.config que ha generado leyendo la metadata de nuestro servicio, los parámetros que hay son los mismos que los nuestros, los que hay por defecto. Podemos modificar el app.config para que acceda mediante TCP modificando solo la línea del endpoint:

<endpoint address=»http://localhost:8000/BlogWCF/Servicio»

                      binding=»basicHttpBinding»

                      bindingConfiguration=»BasicHttpBinding_IMiServicio»

                      contract=»BlogWCFReference.IMiServicio»

                      name=»BasicHttpBinding_IMiServicio» />

La cambiamos por esta otra:

<endpoint address=»net.tcp://localhost:8080/BlogWCF/Servicio»

                    binding=»netTcpBinding»

                    contract=»BlogWCFReference.IMiServicio»

                    name=»NetTcpBinding_IMiServicio» />

Si volvemos a ejecutar ahora el servicio y el cliente podemos ver que vuelve a funcionar; pero esta vez esta accediendo mediante el protocolo TCP. Como vemos tenemos completamente separadas la parte de comunicaciones de la de implementación.

Con esto acaba esta serie de posts/tutorial sobre como utilizar Windows Communication Foundation para crear, servir y consumir servicios. Espero que os haya ayudado.

Más adelante iré posteando cosas más avanzadas sobre WCF: servicios, bindings personalizados, seguridad, etc. Hasta pronto.

Artículos anteriores:
Tutorial WCF (1 de 5)
Tutorial WCF (2 de 5)
Tutorial WCF (3 de 5)

4- APLICACIÓN HOST

Otra forma de servir un servicio de WCF es hacer que una aplicación haga de host del servicio y sea ésta la que tenga el control sobre éste. En este tutorial haremos que sea una aplicación de consola pero podría, tranquilamente, ser cualquier otro tipo de aplicación como, por ejemplo, un servicio de Windows.

Partiremos del servicio creado en el segundo post de este tutorial, el que no tiene ningún archivo de configuración ni el .svc; ya que éstos son para servirlo mediante IIS. En este caso el archivo de configuración lo tendrá la aplicación que hará de host.

Empezamos creando un nuevo proyecto de consola que llamaremos Host y al que importaremos dos dlls .La primer será la necesaria para trabajar con WCF; System.ServiceModel, y la segunda será la que genera nuestro proyecto del servicio de WCF; BlogWCF.dll. En el archivo Program.cs añadiremos los using/import de ambas dlls y escribiremos el código necesario para que arranque el servicio:

using System;

using System.Collections.Generic;

using System.ServiceModel;

using BlogWCF;

namespace Tests

{

    class Program

    {

        static void Main(string[] args)

        {

            ServiceHost hos = new ServiceHost(typeof(MiServicio));

            Console.WriteLine(«Presiona cualquier tecla para empezar»);

            Console.ReadKey(true);

            try

            {

                hos.Open();

                Console.WriteLine(«El servicio se esta sirviendo correctamente… «);

                Console.WriteLine(«presiona cualquier tecla para cerrarlo.»);

                Console.ReadKey(true);

                hos.Close();

            }

            catch (Exception ex)

            {

                Console.WriteLine(«ERROR: «, ex.Message);

                Console.WriteLine(ex.Message);

            }

            Console.ReadKey(true);

        }

    }

}

Vemos que lo primero que hace es crear una instancia de la clase ServiceHost indicándole a ésta que tipo de servicio va a usar. Luego, entre un bloque try/catch por si surge algún problema, hacemos que empiece a servir-se el servicio (válgase la redundancia), y lo cerramos una vez usado.

Pero con esto no estamos aun, falta definir como va a ser el canal de comunicación y como se va a acceder al servicio. Para ello añadiremos un fichero de configuración a nuestra aplicación Host. Como en este caso sí que se trata de una aplicación normal y no de una aplicación web añadiremos un archivo App.config con la siguiente información:

<?xml version=»1.0″ encoding=»utf-8″ ?>

<configuration>

  <system.serviceModel>

    <services>

      <service name=»BlogWCF.MiServicio»  behaviorConfiguration=»lala»>

        <host>

          <baseAddresses>

            <add baseAddress=»http://localhost:8000/BlogWCF»/>

          </baseAddresses>

        </host>

        <endpoint address=»Servicio»

                  binding=»basicHttpBinding»

                  contract=»BlogWCF.IMiServicio»/>

      </service>

    </services>

    <behaviors>

      <serviceBehaviors>

        <behavior name=»lala»>

          <serviceMetadata httpGetEnabled=»true»/>

        </behavior>

      </serviceBehaviors>

    </behaviors>

  </system.serviceModel>

</configuration>

Como vemos es casi igual al que teníamos antes para el Web.config pero cambiando el puerto de destino y la forma de definir las direcciones. El puerto que usaba antes era el 80, el puerto por defecto para comunicaciones mediante http. Si no ponemos un puerto diferente (y libre) nos dará un error, ya que estaremos intentando servir por un puerto que lo esta usando otra aplicación, en nuestro caso el IIS. Las direcciones se generaran en este caso concatenando la baseAddress específica a un protocolo con la address del endpoint. En este caso solo tenemos una y uno, y no hay donde perderse, pero puede haber más de una baseAddress más de un endpoint. La forma de concatenarse dependerá del binding al protocolo utilizado: en este caso en basicHttpBinding busca la baseAddress que empiece por http.

Ahora ya tenemos todo preparado para hospedar nuestro servicio. Si todo esta bien y ejecutamos nuestra aplicación tiene que salir esta pantalla:

Si mantenemos el servicio sin cerrarlo y abrimos una nueva ventana de comandos (Inicio->Ejecutar->’cmd’) y escribimos el comando netstat -a -n veremos que nos aparece que hay un servicio ejecutandose en el puerto 8000: el nuestro. Si quitamos la opción -n veremos que protocolo usa (http).

Si queremos además servir nuestro servicio también con el protocolo tcp por el puerto 8080 solo debemos editar el App.config de la manera siguiente:

<?xml version=»1.0″ encoding=»utf-8″ ?>

<configuration>

  <system.serviceModel>

    <services>

      <service name=»BlogWCF.MiServicio»  behaviorConfiguration=»lala»>

        <host>

          <baseAddresses>

            <add baseAddress=»http://localhost:8000/BlogWCF»/>

            <add baseAddress=»net.tcp://localhost:8080/BlogWCF»/>

          </baseAddresses>

        </host>

        <endpoint address=»Servicio»

                  binding=»basicHttpBinding»

                  contract=»BlogWCF.IMiServicio»/>

        <endpoint address=»Servicio»

                  binding=»netTcpBinding»

                  contract=»BlogWCF.IMiServicio»/>

      </service>

    </services>

    <behaviors>

      <serviceBehaviors>

        <behavior name=»lala»>

          <serviceMetadata httpGetEnabled=»true»/>

        </behavior>

      </serviceBehaviors>

    </behaviors>

  </system.serviceModel>

</configuration>

En este caso tenemos dos baseAddress y dos enpoints: se concatenarán las direcciones por el protocolo. Si os fijáis la baseAddress que se refiere al protocolo tcp empieza por net.tcp. Si ejecutamos y volvemos a mirar el netstat veremos que tenemos el servicio sirviéndose por dos puertos diferentes y con protocolos diferentes:

Con esto ya hemos visto como podemos servir nuestros servicios y añadir enpoints con diferentes mecanismos de comunicación a cada uno.

Ahora falta ver como consumirlos, pero esto será en el siguiente post: Consumiendo un Servicio de WCF.

Artículos anteriores:
Tutorial WCF (1 de 5)
Tutorial WCF (2 de 5) 

3 – BINDINGS

Nuestro servicio dará una funcionalidad pero el cliente tiene que acceder a él de alguna manera. Lo que tenemos que hacer es configurar de qué manera se va a comunicar el el servicio y dónde estará éste. Los servicios podemos tenerlos accesibles en diferentes lugares (puertos) y usando diferentes mecanismos de comunicación. A cada combinación de lugar/mecanismo le llamaremos endpoint.

Los Bindings especifican los mecanismos de comunicación que usaremos para «hablar» con un endpoint.
La plataforma .NET nos ofrece una serie de bindings «de serie» que podemos configurar y usar. Con estos definiremos como queremos que se codifiquen los datos, la seguridad de las comunicaciones, la compresión, el protocolo a usar, etc.

Nosotros podemos crear nuestros propios bindings si nuestro proyecto usa algún protocolo propio o algún tipo de mecanismo de comunicación diferente a los que nos da el Framework.

Podéis encontrar la lista de bindigns que nos da la Plataforma .NET en el siguiente enlace: http://msdn2.microsoft.com/en-us/library/ms731092.aspx

4 – CONFIGURANDO NUESTRO SERVICIO

Lo primero que vamos a hacer es servir nuestro servicio de WCF creado en el post anterior como un servicio Web a través de SOAP y XML. Para esto necesitamos tener el Internet Information Services instalado.

Primero debemos cambiar la carpeta donde se generan las dlls de nuestro servicio. Por defecto se generan el la carpeta bin/Debug, pero si ponemos el servicio en el IIS, éste va a leer directamente de bin así que debemos cambiar el lugar. Para hacerlo hacemos click con el botón derecho en nuestro proyecto y vamos a propiedades. En el apartado Build, en Output cambiaos el Output path a bin, guardamos y listos.

Ahora debemos crear un fichero de configuración para configurar el servicio y sus endpoints. Como la aplicación va a estar servida por el IIS, o sea, va a ser una aplicación web, la configuración va dentro del archivo Web.config. Lo creamos (si lo creamos con la plantilla borramos todo su interior) y escribimos lo que necesitamos:

<?xml version=»1.0″?>

<configuration>

  <system.serviceModel>

    <services>

      <service name=»BlogWCF.MiServicio»>

        <endpoint address=»»

                  binding=»basicHttpBinding»

                  contract=»BlogWCF.IMiServicio» />

      </service>

    </services>

  </system.serviceModel>

</configuration>

Aquí hemos definido un solo servicio con un solo enpoint, pero podríamos tener varios y dependiendo de a que endpoint se dirigiera el cliente usaría un binding o un servicio diferente. En el atributo name del servicio hemos colocado el espacio de nombres de nuestro servicio seguido del servicio. En el endpoint no hemos colocado ninguna dirección ya que será en el lugar donde lo sirva el IIS. El binding utilizado es el basicHttpBinding (ojo, es case sensitive!); éste nos provee el sistema básico de comunicaciones mediante Web Services. Después le hemos dicho qué contrato implementa este servicio.

Ahora lo único que falta es un ficherito con extensión .svc para que el usuario tenga un punto a donde navegar y el IIS sepa que ésto que está sirviendo es un servicio de WCF y sepa como compilar y generar la información WSDL del contrato cuando el cliente se lo pida. Añadimos un nuevo fichero de texto y lo nombramos Service.svc.

<%@ServiceHost Service=»BlogWCF.MiServicio» %>

Como vemos sigue el patrón de los fichero de ASP.NET, una directiva con <%@, en este caso ServiceHost, que indica que servico tiene que compilar y ejecutar.
Con esto ya podemos poner nuestro servicio en nuestro IIS y navegar por Internet para verlo. Sin muchos detalles: en el IIS creamos un directorio virtual que apunte al directorio raíz donde está en .svc y listos. Accedemos al servicio con nuestro navegador: http://localhost/BlogWCF/Service.svc (mi directorio virtual se llama BlogWCF) y tenemos que ver algo parecido a esto:

Si nos fijamos hay una línea que pone: Metadata publishing for this service is currently disabled. Por seguridad el IIS deshabilita la posibilidad de publicar la metadata. Si queremos verla y que clientes desde fuera puedan acceder a ella para poder ver el WSDL debemos modificar un poco nuestro Web.config. Crearemos un behavior que extenderá la funcionalidad de nuestro servicio:

<?xml version=»1.0″?>

<configuration>

  <system.serviceModel>

    <services>

      <service name=»BlogWCF.MiServicio»

               behaviorConfiguration=»MiBehavior»>

        <endpoint address=»»

                  binding=»basicHttpBinding»

                  contract=»BlogWCF.IMiServicio» />

      </service>

    </services>

    <behaviors>

      <serviceBehaviors>

        <behavior name=»MiBehavior»>

          <serviceMetadata httpGetEnabled=»true»/>

        </behavior>

      </serviceBehaviors>

    </behaviors>

  </system.serviceModel>

</configuration>

Si volvemos a cargar la pagina veremos que ahora sí podemos acceder a la metadata que genera a partir del contrato (WSDL), donde se define qué funcionalidades da nuestro servicio, qué tipos de datos usa, y cómo se accede.

Con esto ya tenemos listo nuestro servicio web.

También podemos hacer que nuestro servicio sea servido por otro programa y con otro protocolo.

Ésto lo veremos en el próximo post: Sirviendo un Servicio de WCF (2ª parte).

Articulos anteriores:
Tutorial WCF (1 de 5)

2 – MONTANDO UN SERVICIO

La idea principal es que nuestro servicio será independiente de la forma en que nos comunicaremos con él.

El proceso de creación de un servicio se divide en dos partes:

1. Definición y creación de un contrato: en éste definiremos la funcionalidad (métodos accesibles) que tendrá nuestro servicio y que datos (clases, estructuras, …) utilizará para comunicarse.
   
2. Creación de un servicio que «implemente» el contrato definido.

Así que esto es lo que haremos en este primer tutorial.

DEFINIENDO EL CONTRATO

Un contrato no es más que una interfaz tal y como la conocemos en el concepto de la POO. Vamos a definirlo.

Sin usar la plantilla que nos ofrecen las extensiones o «Orcas» por defecto para crear una WCF service Library, creamos un proyecto que sea de tipo librería en el lenguaje que más os guste; yo lo haré en C#. Para empezar crearemos una nueva interfaz en nuestro proyecto y la llamaremos IMiServicio. Es importante saber que para trabajar con WCF necesitamos añadir una referencia a nuestro proyecto (si no está ya) y hacer el «import/using» pertinente: System.ServiceModel.

   1: using System;

   2: using System.Runtime.Serialization;

   3: using System.ServiceModel;

   4: using System.Collections.Generic;

   5:  

   6: namespace BlogWCF

   7: {

   8:     [ServiceContract]

   9:     public interface IMiServicio

  10:     {

  11:  

  12:         [OperationContract]

  13:         List<Cumple> DameCumples();

  14:  

  15:         [OperationContract]

  16:         int DimeEdad(Cumple cu);

  17:     }

  18:  

  19:     [DataContract]

  20:     public class Cumple

  21:     {

  22:         string nombre = «»;

  23:         DateTime fechaCumple = new DateTime();

  24:  

  25:         [DataMember]

  26:         public string Nombre

  27:         {

  28:             get { return nombre; }

  29:             set { nombre = value; }

  30:         }

  31:  

  32:         [DataMember]

  33:         public DateTime FechaCumple

  34:         {

  35:             get { return fechaCumple; }

  36:             set { fechaCumple = value; }

  37:         }

  38:     }

  39: }

Para indicar que se trata de un contrato usamos el atributo ServiceContract al declarar la Interface. Para definir qué métodos tendrá el contrato usamos el atributo OperationContract.
Este contrato es el que usarán los clientes para saber que operaciones tiene un servicio y que datos intervienen en la comunicación.
En este caso usamos una clase nuestra llamada Cumple que interviene en la comunicación y deberá ser serializada. Para indicar que la clase también debe estar en el contrato usamos los atributos DataContract y DataMember para la deficinión de la clase y sus propiedades respectivamente. Esta clase debe cumplir los requisitos para que sea serializable ya que debe poder ser enviada mediante SOAP y XML si lo deseamos.

CREANDO EL SERVICIO

Ahora lo que debemos hacer es implementar esta Interfaz (contrato), y crear la clase que dará este servicio:

   1: using System;

   2: using System.Collections.Generic;

   3:  

   4: namespace BlogWCF

   5: {

   6:     public class MiServicio : IMiServicio

   7:     {

   8:         public List<Cumple> DameCumples()

   9:         {

  10:             List<Cumple> cumples = new List<Cumple>();

  11:             cumples.Add(new Cumple{

  12:                             Nombre=«Jordi»,

  13:                             FechaCumple=new DateTime(1982,10,8)});

  14:             cumples.Add(new Cumple {

  15:                             Nombre = «Alex»,

  16:                             FechaCumple = new DateTime(1982, 6, 13) });

  17:             cumples.Add(new Cumple {

  18:                             Nombre = «Clara»,

  19:                             FechaCumple = new DateTime(1982, 3, 20) });

  20:  

  21:             return cumples;

  22:         }

  23:  

  24:         public int DimeEdad(Cumple cu)

  25:         {

  26:             int years = DateTime.Now.Year – cu.FechaCumple.Year –

  27:                 (cu.FechaCumple.Month > DateTime.Now.Month ? 1 :

  28:                 (cu.FechaCumple.Month != DateTime.Now.Month) ? 0 :

  29:                 (cu.FechaCumple.Day > DateTime.Now.Day) ? 1 : 0);

  30:             return years;

  31:         }

  32:     }

  33: }

Vemos que hemos creado una clase que implementa la interfaz que define el contrato. Podríamos añadir más métodos, propiedades y demás, pero no serían visibles desde un cliente ya que no están definidos en el contrato.

Ahora ya tenemos definido el servicio y lo que tenemos de decidir es cómo se va a acceder a él; SOAP y XML (Web Services), mediante HTTP/HTTPS, TCP,… y quien lo va a servir; el IIS, un servicio del sistema operativo, lo serivá otro programa, etc.
Pero esto se hace a parte de la definición del servicio, así separamos lo que es la funcionalidad de las comunicaciones.
Además, la definición de las comunicaciones la haremos mediante ficheros de configuración basados en XML, o sea, legibles y fácilmente editables. Así que, si decidimos un día cambiar un servicio que se está sirviendo como un servicio web a un servicio que se sirva por TCP por el puerto 8080, solo habrá que cambiar dos lineas del fichero de configuración y listos; no habrá que modificar el código de nuestro servicio.

Esto lo veremos en el próximo post: Sirviendo un Servicio de WCF.

<comentario>
Voy a poner una serie de posts que tenía en mi antiguo blog y que me gustaría que estuvieran aquí. Así puedo separar contenidos en los blogs. Los primeros cinco forman un pequeño tutorial sobre cómo trabajar con WCF; dirigido a aquellos que aun no se han atrevido a enfrentarse. Este tutorial me lo pidió uno de los alumnos que tuve en el último curso que di sobre ASP.NET este julio. Luego vienen dos más que me gustaría que también estuvieran aquí.
</comentario>

Voy a hacer una pequeña introducción/tutorial para empezar a trabajar con WCF: cómo crear un servicio, cómo servirlo y como consumirlo.

Voy a intentar que sea todo bastante sencillo sin entrar en conceptos complicados. Así que, en teoría, este post va a ser apto para todos los públicos.

1 – INTRODUCCIÓN

WCF (Windows Communication Foundation) es una de las 4 mejoras circunstanciales del Framework 3.0, junto con WPF, WWF y CardSpace.

Con los Servicios Web podemos crear aplicaciones distribuidas usando XML y SOAP y podemos añadirle seguridad y privacidad a las comunicaciones usando WSE (Web Services Enhancements). Pero esto solo es una de las tecnologías que nos permiten hacer aplicaciones distribuidas: también podemos usar Enterprise Services, .NET Remoting o MSMQ. WCF nos da un modelo estándar de programación que engloba todas estas tecnologías. Así podemos crear servicios de una forma fácil, rápida y, sobretodo, adaptable.

Requisitos: Para poder realizar este tutorial deberéis tener instalado el Framework 3.0 o superior. Y podéis hacerlo tanto con la Beta 2 de Visual Studio 2008 «Orcas» o con el Visual Studio 2005 y las extensiones para el .NET Framework 3.0.

Aquí tenéis los enlaces:
Microsoft .NET Framework 3.0 Redistributable Package
Visual Studio 2005
Extensions for .NET Framework 3.0 (WCF & WPF)
Visual Studio 2008 «Orcas» Beta 2

En el próximo post empezaremos con la primera parte: Creando un Servicio de WCF.

Muy buenas a tod@s!

Me llamo jordi Núñez y soy estudiante de telecomunicaciones en la UPC (Barcelona), intentando tirar adelante con la carrera sin dejar de lado mis inquietudes y mis aficiones. También soy, aunque desde hace muy poco, currante dentro del mundo de la programación.
Desde pequeño he tenido mucha facilidad con las artes gráficas y hasta he estudiado estas en algún momento. Desde hace unos años he trabajado como diseñador y programador web con tecnologías como DHTML, PHP, JAVA y, actualmente, ASP.NET. Mis ganas de aprender cosas nuevas me han llevado a conocer diversos lenguajes de programación como C/C++, Java, PHP, C#, etc. Pero también me han interesado temas como la robótica y he hecho alguna cosilla en ese campo. Todo ello a base de internet, perseverancia y mucha ilusión.
Hace tres años decidimos, unos amigos de la universidad y yo, formar el Club .NET de la UPC y, gracias a Ricardo Varela, tiramos adelante con esa iniciativa. Así, desde nuestra universidad, telecos e informáticos nos juntamos para jugar con la tecnología .NET compartir y aprender juntos.
Gracias al club hemos podido formar parte de una gran sociedad a nivel nacional conociendo a un montón de estudiantes y profesionales que, como nosotros, les encanta jugar con esta tecnología: los DotNetClubs. Gracias también a Microsoft Ibérica por apoyarnos a todos y llevarnos a eventos como el CodeCamp, ImagineCup, University Tour y hasta al TechEd; proporcionarnos libros, material y de todo para poder facilitar nuestra tarea de aprender y enseñar. Y gracias también a amigos como Alberto, Gerardo, David Carmona, Chema Alonso, David Salgado, José Luis Latorre, etc. Éstos consiguen que siga adelante cada día con más ganas.

Recientemente mi esfuerzo y dedicación en la comunidad han sido recompensados y me han nombrado MSP, Microsoft Student Partner. Me ha hecho mucha ilusión y me ha recargado las pilas y las ganas de seguir adelante pero, como últimamente he estado de exámenes y se me ha acumulado mucho trabajo, no he podido «justificar» este título en la comunidad.

También colaboro con los chicos de BcnDev. Por ahora ayudándoles con las salas de presentación y demás pero seguramente este año también me anime a dar alguna charla.

El contenido de este blog va a ser solamente sobre cosas relacionadas sobre la tecnología, .NET y cosas por el estilo. Pero también tengo otro blog más genérico en donde podréis encontrar alguna que otra ida de olla: http://unamojcamas.blogspot.com/.

Muchas gracias a Rodrigo Corral por dejarme participar en esta comunidad. Sobretodo después de darles la lata a él y a El Guille durante toda una tarde en el aeropuerto de Madrid después del TTT y el CodeCamp en el camping del Escorial hace algo más de un año.

Espero poner contenido interesante y útil. Aunque no tengo el nivel ni la experiencia de la mayoría de los bloguers de Geeks, mi intención es aprender un montón y poder disfrutar con esta experiencia.

Muchas gracias a tod@s.