{ WillyXoft .NET }

Cambiar el monto de la pila

Si bien lo mejor es conformarnos con el tamaño de pila (stack) predeterminado para una ejecución confiable, hay algunos casos en los que puede resultar necesario que se cambie el tamaño de la pila, ya que si se intenta utilizar más memoria de la que está disponible en la pila se lanzaría una StackOverflowException que no se puede manejar. Tales casos incluyen, aunque no son lo únicos: la implementación de algún algoritmo recursivo de gran profundidad, una mejor utilización de la asignación de pila (stackalloc), así como la optimización en el uso de hilos múltiples. Mas tenga en cuenta que debe mantener dicho valor lo más pequeño que se pueda.

EDITBIN

Para modificar el tamaño de la pila en C++ se utiliza la opción "/stack" del vinculador (linker). Pero para los binarios creados con compiladores de lenguajes .NET, como C#, se tiene que recurrir a la herramienta EDITBIN.EXE.

EDITBIN es una herramienta de línea de comandos que viene con Visual Studio, la cual se utiliza para modificar binarios en formato COFF (Common Object File Format). Para el caso que nos interesa utilizaremos la opción /STACK, de forma similar al vinculador de C++:

EDITBIN.EXE /STACK:reserve[,commit]

La opción /STACK sólo se aplica a un archivo ejecutable (EXE). El tamaño de la pila se establece en bytes.

El argumento reserve especifica la asignación total de memoria virtual de la pila. El valor especificado se redondeará a los 4 bytes más próximos.

El argumento opcional commit está sujeto a interpretación por el sistema operativo. En Windows NT, Windows 95 y Windows 98, commit especifica la cantidad de memoria física que se debe asignar de una sola vez. La memoria virtual comprometida hace que se reserve espacio en el archivo de paginación. Si se asigna un valor más alto a commit, se ahorrará tiempo cuando la aplicación necesite más espacio de la pila, pero aumentarán los requisitos de memoria y, posiblemente, el tiempo de inicio.

Así por ejemplo, para reservar un tamaño máximo de pila de 2MB ejecutaríamos:

EDITBIN.EXE /STACK:2097152 ejecutable.exe

Este método nos obliga a alterar el ejecutable después de cada compilación, cosa que se pude automatizar utilizando el evento post-build.

Tome en cuenta que se trata de una asignación estática que afecta al ejecutable en sí, cuando talvez sería más conveniente una solución dinámica, en tiempo de ejecución y que afecte a un solo hilo a la vez.

CreateThread

Se puede especificar programáticamente el tamaño de un hilo utilizando la API de Windows. Para ello empleamos PInvoke con kernel32.dll y ejecutando su método CreateThread para crear dicho hilo con el tamaño especificado en su segundo parámetro.

myThread = CreateThread(
    IntPtr.Zero, // atributo de seguridad
    maxStackSize, // tamaño máximo de pila
    myThreadDelegate, // delegado del hilo
    pDataArg, // argumento para el delegado
    0, // bandera predeterminada
    out dwThreadId); // identificador del hilo

Dado que se trata del uso del API Win32, este método puede utilizarse con cualquier versión del .NET Framework y funciona con cualquier sistema Windows compatible. Por otro lado, tenga en cuenta que se trata de "código inseguro" (unsafe-code).

Más información en Creating Threads.

Constructor Thread

Un par de sobrecargas del constructor de la clase Thread, disponibles a partir de la versión 2.0 del .NET Framework, nos permiten especificar el tamaño máximo de pila para el mismo.

Thread myThread = new Thread(myThreadDelegate, maxStackSize);

Donde:

MyThreadDelegate: es un delegado ThreadStart o ParameterizedThreadStart que representa los métodos a ser invocados cuando el hilo empieza a ejecutarse.
maxStackSize: es el tamaño de pila máximo a ser utilizado por el hilo, si es 0 utiliza el tamaño predeterminado especificado en el encabezado del ejecutable. Si no es ningún múltiplo del tamaño de página establecido por el sistema operativo, se redondea al múltiplo mayor siguiente del tamaño de página.

Este método sólo funciona con sistemas operativos Windows XP, Windows 2003 y posteriores, en sistemas anteriores no tendrá ningún efecto por lo que se utiliza el tamaño de la pila especificado en la cabecera del ejecutable.

NOTA:

Si maxStackSize es menor que el tamaño de pila mínimo, se utiliza el tamaño de pila mínimo. Si especifica un tamaño de pila muy pequeño y la pila está muy limitada, podría necesitar deshabilitar el sondeo de desbordamiento de pila, ya que el propio sondeo puede provocar un desbordamiento de pila. Para deshabilitar el sondeo del desbordamiento de pila, agregue lo siguiente al archivo de configuración de la aplicación.

<configuration>
  <runtime>
    <disableStackOverflowProbing enabled="true"/>
  </runtime>
</configuration>

Service Pack 1 para VS 2008 y NetFx 3.5

"Basados en las mejores características de VS2008 y .NET 3.5, estoy satisfecho de anunciar hoy el lanzamiento del Service Pack 1 de .NET Framework 3.5 y Visual Studio 2008 (inglés).

En Visual Studio 2008 SP1 nos hemos concentrado en mejorar el rendimiento y la fiabilidad. Hemos trabajado en nuestros diseñadores para la creación de aplicaciones de WPF mejorando su rendimiento, se han mejorado las herramientas para desarrollar aplicaciones AJAX, diseñadores mejorados para trabajar con el ADO.NET Entity Framework y hemos incluido un entorno de desarrollo JavaScript más completo a la vez que hemos simplificado la experiencia de implementación de sitios Web.

En .NET Framework hemos ido un poco más allá. Aparte de corregir los problemas notificados por clientes también hemos añadido algunas características muy solicitadas para facilitar el desarrollo de aplicaciones para las plataformas más recientes. Algunas de estas nuevas características incluyen .NET Framework Client Profile, compatibilidad mejorada para desarrollo de aplicaciones de base de datos a través del ADO.NET Entity Framework, ADO.NET Data Services y su integración con el recientemente lanzado SQL Server 2008, además de varias mejoras en ASP.NET."

Historia completa en: Service Pack 1 for VS 2008 and .NET FX 3.5 released! o bien la traducción: Publicado el Service Pack 1 de Visual Studio 2008 y .NET FX 3.5.

Por su parte Sam Gentile nos cuenta lo que el SP1 trae consigo para WCF en: New and Notable 264 - Visual Studio 2008 SP1 and .NET Framework 3.5 SP1 RTM!, a la vez que nos deja una interesante lista de vínculos:

SQL Server 2008 RTM

Microsoft ha anunciado la liberación del RTM de SQL Server 2008, la nueva versión del gestor de datos y plataforma de inteligencia de negocios de Microsoft.

Esta versión de SQL Server proporciona nuevas capacidades tales como el soporte para la gestión basada en políticas, auditoria, warehousing de datos a gran escala, datos geo-espaciales, y servicios de reporte y análisis avanzados.

SQL Server 2008 proporciona la plataforma confiable, productiva e inteligente necesaria para las aplicaciones de negocio críticas.

Confiable

Productivo

Eleva la productividad del administrador
Simplifica el desarrollo con ayuda de ADO.NET Object Services y LINQ
Almacena cualquier tipo de información, incluyendo datos espaciales

Inteligente

Integra datos con Integration Services para Data Warehousing
Brinda información relevante con Analysis Services
Entrega ideas con Reporting Services para Data Mining

SQL Server 2008 está disponible para subscriptores MSDN y Technet, y muy pronto estará disponible la versión de evaluación. Las ediciones Express y Compact de SQL Server 2008 estarán disponibles en la página de SQL Server.

Más información en:

ACTUALIZACIÓN

Ya están disponibles las descargas de:

Microsoft SQL Server 2008 Express

Microsoft SQL Server 2008 Enterprise Evaluation: para desarrolladores

Microsoft SQL Server 2008 Enterprise Evaluation: para profesionales de TI

Libros en pantalla de Microsoft SQL Server 2008

Feature Pack de Microsoft SQL Server 2008 (agosto de 2008)

Asesor de actualizaciones de Microsoft SQL Server 2008

Seguridad para Servicios Web WCF

El equipo de patterns & practices ha publicado la versión 1.0 (final) de su guía de seguridad para Servicios Web, titulada:

Improving Web Services Security:
Scenarios and Implementation Guidance for WCF

En la cual se muestra cómo mejorar la seguridad de WCF mediante escenarios, guías directivas, Preguntas & Respuestas, listados Como-Se-Hace, etc...

La guía está relacionada con el proyecto de seguridad WCF Security Guidance Project.

Mayor información y descarga de la guía en:

Improving Web Services Security.

Midori: SO Administrado

Midori es el nombre clave de un posible sistema operativo comercial sucesor del actual proyecto Singularity, el cual es un proyecto de investigación iniciado en 2003 sobre un sistema operativo en código administrado .NET, y cuyo RDK (Research Development Kit) Microsoft Research hizo público el pasado mes de marzo.

Midori sería entonces un Sistema Operativo en Modo Administrado, en el cual el núcleo (kernel), controladores de dispositivos (drivers), y aplicaciones están todos escritos en código administrado .NET, por ende sería un SO construido desde cero y no una simple evolución de la tecnología Windows actual. Para resolver el problema de la compatibilidad hacia atrás Midori emplearía tecnología de virtualización.

Cuando Windows fue diseñado no había Internet como hoy lo conocemos, por lo que las funcionalidades al respecto se le añadieron más tarde con parches. El diseño inicial de Midori sin embargo estará centrado en Internet y la reducción del acoplamiento existente entre los datos, las aplicaciones y los dispositivos, llevando a cumplimiento el sueño de Bill Gates iniciado con .NET.

No obstante aún no existen plazos para el desarrollo de Midori, el cual es considerado como un "proyecto de investigación". Un portavoz de Microsoft incluso afirmó que Midori es apenas uno de muchos proyectos en incubación en Microsoft Research.

Por lo que de momento lo único "concreto" que existe es el proyecto Singularity.

Mas información en:

Web Service Software Factory Contrib

Un nuevo proyecto de "contribuciones" para extender el Web Service Software Factory ha sido abierto, e inicia con un par de las contribuciones más buscadas:

VB.NET Release, donde Edward Bakker extiende el release oficial de Febrero de 2008 para incluir plantillas de generación de código VB.NET y tipos de proyecto
Import WSDL Add-on, facilitado por Digit Factory para la generación de modelos desde documentos WSDL existentes (Hurra!)

Mayor información en el sitio del proyecto: Web Service Software Factory Contrib

Aplicaciones Compuestas con WPF

El equipo de patterns & practices de Microsoft ha publicado el conjunto de guías titulado: Composite Application Guidance for WPF. El cual contiene una implementación de referencia que emplea patrones de diseño, conceptos y técnicas para la construcción de aplicaciones compuestas con WCF. Incluye además ejemplos de inicio rápido, laboratorios, temas "como se hace", etc.

La implementación de referencia ilustra cómo se pueden enfrentar muchos de los retos presentes en la construcción de aplicaciones basada en módulos independientes pero colaborativos.

Mas información en:

WCF bajo Contrato (4/4)

Contrato de Fallo

Cualquier operación petición/respuesta devuelve dos posibles mensajes: su mensaje de respuesta normal, o bien un mensaje de error. Para enviar un mensaje de error (un "SOAP Fault" en términos de servicios web) se lanza una FaultException en la implementación del servicio, tal y como se ha ejemplificado hasta ahora.

Pero además se pueden especificar formalmente los mensajes de error utilizando tipos personalizados con un contrato de datos adecuado, dado que se serializarán mediante el DataContractSerializer. El tipo a utilizar en el mensaje de error se especifica contractualmente en la firma de la operación utilizando el atributo FaultContract, mientras que en la implementación de la operación se genera mediante una FaultException del tipo especificado en el FaultContract.

Como ejemplo suponga que deseamos especificar un mensaje de error, que nos informe sobre un error en el parámetro de la petición, utilizando el siguiente tipo con su contrato de datos:

Listado de HelloData.cs (fragmento)

[DataContract(Namespace="http://hello/data/")]
public class InvalidRequest
{
  private int id;
  private string message;
  private string notes;

  [DataMember()]
  public int ID
  {
    get { return id; }
    set { id = value; }
  }

  [DataMember()]
  public string Message
  {
    get { return message; }
    set { message = value; }
  }				

  [DataMember()]
  public string Notes
  {
    get { return notes; }
    set { notes = value; }
  }				
}

El fragmento de código se agrega al archivo HelloData.cs, tras lo cual lo compilamos.

Para especificar el uso del tipo InvalidRequest como tipo de fallo sobre la operación, aplicamos el atributo FaultContract a la firma de la operación:

Listado de Hello.cs (fragmento)

[ServiceContract(Namespace="http://hello/", Name="Hello")]
interface IHello
{
  [OperationContract()]
  [FaultContract(typeof(InvalidRequest))]
  SayHelloResponse SayHello(SayHelloRequest request);
}

Después en la clase de implementación del servicio se lanzan las excepciones correspondientes:

Listado de Hello.cs (fragmento)

  [ServiceBehavior(Namespace="http://hello/", Name="HelloService")]
  public class Hello : IHello
  {
    private StringBuilder message = new StringBuilder("¡Hola ");

    private void ValidateRequest(SayHelloRequest request)
    {
      if (request.PersonParameter == null)
      {
        InvalidRequest fault = new InvalidRequest();
        fault.ID = 1;
        fault.Message = "Parámetro Person inválido";
        fault.Notes = "El objeto Person no puede ser nulo...";
        throw new FaultException<InvalidRequest>(fault, "Parámetro inválido.");
      }
      else if (request.PersonParameter.FirstName == null ||
        request.PersonParameter.FirstName.Length == 0)
      {
        InvalidRequest fault = new InvalidRequest();
        fault.ID = 2;
        fault.Message = "Miembro FirstName inválido";
        fault.Notes = "El miembro FirstName del objeto Person no puede ser nulo o vacío...";
        throw new FaultException<InvalidRequest>(fault, "Parámetro inválido.");
      }
    }

    public SayHelloResponse SayHello(SayHelloRequest request)
    {
      ValidateRequest(request);

      message.Append(request.PersonParameter.FirstName + "!");
      string msg = message.ToString();
      SayHelloResponse response = new SayHelloResponse();
      HelloCard card = new HelloCard();
      card.Greeting = msg;
      response.HelloCardResult = card;
      System.Console.WriteLine(msg);
      return response;
    }
  }

Nótese que hemos extraído el código de validación del request en un método privado, en el cual se crea una instancia de InvalidRequest, se establece la información pertinente, y se lanza un FaultException con dicha instancia. Note además que se hace el uso de la versión "genérica" de FaultException para ello.

Compilamos Hello.cs, y para terminar del lado del servicio sólo ejecutamos la aplicación host.

Para el cliente una vez más se regeneran los artefactos cliente con svcutil.exe.

Después, aunque el código de la aplicación cliente podría funcionar sin cambios, para poder consumir los mensajes adicionales de error (de tipo InvalidRequest) ahora agregaremos un catch para "atrapar" el FaultException de tipo InvalidRequest. El listado de Client.cs queda de la siguiente manera:

Listado de Client.cs

using System;
using System.ServiceModel;

public class Client
{
  static void Main(string[] args)
  {
    String arg = null;
    String result = null;
    if (args.Length > 0) {
      arg = args[0];
    }
    else {
      arg = "Anónimo";
    }
    try {
      hello.Hello service = new hello.HelloClient();
      hello.data.Person person = new hello.data.Person();
      person.FirstName = arg;
      hello.SayHelloRequest request = new hello.SayHelloRequest();
      request.Person = person;
      hello.SayHelloResponse response = service.SayHello(request);
      result = response.HelloCard.Greeting;
    }
    catch (FaultException<hello.data.InvalidRequest> helloFault)
    {
      result = String.Format("{0}\nID: {1}\nMensaje: {2}\nNotas: {3}",
                helloFault.Message,
                helloFault.Detail.ID,
                helloFault.Detail.Message,
                helloFault.Detail.Notes);
    }
    catch (FaultException fault) {
      result = "Fault: " + fault.Message;
    }
    catch (Exception ex) {
      result = "Error: " + ex.ToString();
    }
    finally{
      System.Console.WriteLine(result);
    }
  }
}

Observe que para acceder a los miembros de la instancia de InvalidRequest enviada utilizamos la propiedad Detail de la instancia de FaultException helloFault.

Compilamos el proxy y el cliente, y ejecutamos Client.exe. Pruebe las excepciones modificando el código de la aplicación cliente, ya sea estableciendo a nulo el valor del miembro FirstName o el parámetro Person, y volviendo a compilar y ejecutar...

Epílogo

Con los ejemplos vistos en la presente serie se han explorado brevemente los diferentes tipos de contratos de WCF: contrato de servicio, contrato de datos, contrato de mensajes y contrato de fallo. Los mismos se definen aplicando ciertos atributos a clases y sus miembros. Los atributos permiten parámetros por nombre, tales como el Namespace y Name, para una mejor definición del elemento al cual se aplica. Queda como tarea para el lector que indague sobre dichos parámetros, ya que existen muchos otros en cada uno de los distintos atributos.

Quedan pendientes entonces varias cosas, además del nuevo cliente Java, mismas que espero abordar en futuras ocasiones. ¡Hasta entonces!

WCF bajo Contrato (3/4)

Contrato de Mensajes

Hasta ahora se ha redefinido el contrato de servicio utilizando una interfaz, así como empleado tipos personalizados con contrato de datos definidos, lo cual es suficiente en la mayoría de los casos.

Pero cuando se desea tener mayor control sobre la estructura de los mensajes SOAP debemos crear un contrato de mensajes el cual permite utilizar un tipo para el parámetro y el valor devuelto que se serialicen en los mensajes SOAP de solicitud y respuesta que se necesiten.

A éste estilo de modelado de las operaciones se le conoce como estilo de mensajería, en contraposición al estilo de llamada de procedimiento remoto (RPC). Las firmas de las operaciones de estilo de mensajería tienen hasta un parámetro y un valor de retorno y ambos deben ser tipos de mensaje que se serializan directamente en una estructura del mensaje SOAP especificado.

Para definir el contrato de mensajes debemos aplicar el atributo MessageContract a las clases que vayan ser los tipos de mensaje. Así también debemos aplicar el atributo MessageBodyMember a sus miembros (que pueden ser campos, propiedades o eventos) que serán los elementos del cuerpo del mensaje SOAP, o bien el atributo MessageHeader para especificar el encabezado del mensaje.

Podriamos haber empleado el contrato de mensajes desde la versión del servicio que empleaba tipos simples, en cuyo caso podría ser algo como:

[MessageContract()]
public class SayHelloRequest
{
  [MessageBodyMember()]
  public string name
}

[MessageContract()]
public class SayHelloResponse
{
  [MessageBodyMember()]
  public string greeting
}

Pero continuando con nuestro ejemplo, los contratos de mensaje para la operación SayHello quedan de la siguiente forma:

Listado de Hello.cs (fragmento)

using hello.data;

  [MessageContract()]
  public class SayHelloRequest
  {
    private Person person;

    [MessageBodyMember(Name="Person")]
    public Person PersonParameter
    {
      get { return person; }
      set { person = value; }
    }
  }

  [MessageContract()]
  public class SayHelloResponse
  {
    private HelloCard helloCard;

    [MessageBodyMember(Name="HelloCard")]
    public HelloCard HelloCardResult
    {
      get { return helloCard; }
      set { helloCard = value; }
    }
  }

Nótese que se trata de clases "planas" con atributos, y que los elementos del cuerpo de los mensajes son los tipos personalizados con contratos de datos definidos anteriormente en HelloData.cs.

Para utilizar los tipos de mensaje ahora la firma del contrato de servicio debe redefinirse como sigue:

Listado de Hello.cs (fragmento)

[ServiceContract(Namespace="http://hello/", Name="Hello")]
interface IHello
{
  [OperationContract()]
  SayHelloResponse SayHello(SayHelloRequest request);
}

Por lo que también debemos reescribir su implementación. El listado completo de Hello.cs queda entonces de la siguiente forma:

Listado de Hello.cs

using System;
using System.Text;
using System.ServiceModel;
using hello.data;

namespace hello
{

  [MessageContract()]
  public class SayHelloRequest
  {
    private Person person;

    [MessageBodyMember(Name="Person")]
    public Person PersonParameter
    {
      get { return person; }
      set { person = value; }
    }
  }

  [MessageContract()]
  public class SayHelloResponse
  {
    private HelloCard helloCard;

    [MessageBodyMember(Name="HelloCard")]
    public HelloCard HelloCardResult
    {
      get { return helloCard; }
      set { helloCard = value; }
    }
  }
  
  [ServiceContract(Namespace="http://hello/", Name="Hello")]
  interface IHello
  {
    [OperationContract()]
    SayHelloResponse SayHello(SayHelloRequest request);
  }

  [ServiceBehavior(Namespace="http://hello/", Name="HelloService")]
  public class Hello : IHello
  {
    private StringBuilder message = new StringBuilder("¡Hola ");

    public SayHelloResponse SayHello(SayHelloRequest request)
    {
      if (request.PersonParameter == null ||
          request.PersonParameter.FirstName == null ||
          request.PersonParameter.FirstName.Length == 0)
        throw new FaultException(
            "Parámetro Person inválido.");

      message.Append(request.PersonParameter.FirstName + "!");
      string msg = message.ToString();
      SayHelloResponse response = new SayHelloResponse();
      HelloCard card = new HelloCard();
      card.Greeting = msg;
      response.HelloCardResult = card;
      System.Console.WriteLine(msg);      
      return response;
    }
  }
}

Las clases de los archivos HelloData.cs y HelloHost.cs permanecen sin cambios. Por lo que del lado del servicio únicamente compilamos el archivo Hello.cs:

>csc /t:library Hello.cs /r:System.ServiceModel.dll,HelloData.dll

...y ejecutamos la aplicación host.

Continuemos con el cliente. Primero debemos (una vez más) regenerar los artefactos cliente con svcutil.exe, y después modificar el código de Client.cs como se muestra a continuación:

Listado de Client.cs

using System;

public class Client
{
  static void Main(string[] args)
  {
    String arg = null;
    String result = null;
    if (args.Length > 0) {
      arg = args[0];
    }
    else {
      arg = "Anónimo";
    }
    try {
      hello.Hello service = new hello.HelloClient();         
      hello.data.Person person = new hello.data.Person();
      person.FirstName = arg;
      hello.SayHelloRequest request = new hello.SayHelloRequest();
      request.Person = person;
      hello.SayHelloResponse response = service.SayHello(request);
      result = response.HelloCard.Greeting;
    }
    catch (System.ServiceModel.FaultException fault)
    {
      result = "Fault: " + fault.Message;
    }
    catch (Exception ex) {
      result = ex.ToString();
    }
    finally{
      System.Console.WriteLine(result);
    }
  }
}

Nótese que antes del llamado al método SayHello se deben crear una instancia del tipo de mensaje SayHelloRequest, así como el tipo Person para su miembro correspondiente. La invocación retorna una instancia del tipo de mensaje SayHelloResponse mediante la cual se recupera el mensaje a desplegar. Note también que los elementos de los mensajes tienen los nombres especificados en el argumento por nombre "Name" del atributo MessageBodyMember correspondiente.

Para finalizar compilamos el proxy y la aplicación cliente, y ejecutamos Client.exe como hasta ahora.

Dado que en el presente ejemplo no hemos empleado el contrato de mensajes para nada extraordinario, el uso del mismo pareciera una sobrecarga innecesaria. Pero tenga presente que es útil para aquellos casos en los cuales se requiere tener control sobre los elementos o cabecera del mensaje, tales como la resolución de problemas de seguridad del mensaje o problemas de interoperabilidad.

WCF bajo contrato (2/4)

Contrato de Datos

WCF emplea, de forma predeterminada, a la clase DataContractSerializer como mecanismo de serialización de datos .NET desde y hacia XML, el cual requiere que los tipos tengan un contrato de datos definido.

Hasta ahora el servicio utiliza tipos simples (string) para el intercambio de datos (en el parámetro de entrada y el valor devuelto) sin ninguna preparación. Esto se debe a que ciertos tipos del .NET Framework, entre ellos los "primitivos", tienen contratos de datos predeterminados. Si lo desea puede consultar la lista de los tipos admitidos por el DataContractSerializer.

En caso que deseáramos utilizar nuestros propios tipos de datos, necesitamos definir tipos complejos. Para ello debemos crear tipos que tengan un contrato de datos definido, lo cual conseguimos aplicando el atributo DataContract a las clases, estructuras y/o enumeraciones a ser serializables por el DataContractSerializer. Además de lo anterior debemos aplicar el atributo DataMember a los miembros que deseemos sean serializables, sin que importe su modificador de acceso.

Continuando con nuestro ejemplo, supongamos que ahora deseamos utilizar los siguientes tipos para el intercambio de datos:

Listado de HelloData.cs

using System;
using System.Runtime.Serialization;

namespace hello.data
{
    [DataContract(Namespace="http://hello/data/")]
    public class Person
    {
        private string firstName;
        private string lastName;

        [DataMember()]
        public string FirstName
        {
            get { return firstName; }
            set { firstName = value; }
        }

        [DataMember()]
        public string LastName
        {
            get { return lastName; }
            set { lastName = value; }
        }
    }

    [DataContract(Namespace="http://hello/data/")]
    public class HelloCard
    {
        private string greeting;
        private int serial;

        [DataMember()]
        public string Greeting
        {
            get { return greeting; }
            set { greeting = value; }
        }

        public int Serial
        {
            get { return serial; }
            set { serial = value; }
        }
    }
}

Nótese que son clases "planas" con los atributos que definen el contrato de datos. Observe también la declaración del espacio de nombre del .NET Framework: System.Runtime.Serialization, a cuyo ensamblado debemos referenciar para compilar HelloData.cs:

>csc /t:library HelloData.cs /r:System.Runtime.Serialization.dll

Una vez definidos los tipos personalizados, ahora definimos el nuevo contrato de servicio, y reescribimos su implementación, como se lista a continuación:

Listado de Hello.cs

using System;
using System.Text;
using System.ServiceModel;
using hello.data;

namespace hello
{
  [ServiceContract(Namespace="http://hello/")]
  interface IHello
  {
    [OperationContract()]
    public HelloCard SayHello(Person person);
  }

  [ServiceBehavior(Namespace="http://hello/", Name="HelloService")] 
  public class Hello : IHello
  {
    private StringBuilder message = new StringBuilder("Hola ");
  
    [OperationContract(Namespace="http://hello/")]
    public HelloCard SayHello(Person person)
    {      
      if (person == null ||
      person.FirstName == null || 
      person.FirstName.Length == 0)
        throw new FaultException("Objeto Person inválido.");
      message.Append(person.FirstName + "!");
     string msg = message.ToString();
     HelloCard card = new HelloCard();
     card.Greeting = msg;
     System.Console.WriteLine(msg);
     return card;
    }
  }
}

Nota: En el código se altera la interfaz del contrato del servicio, cuando en la práctica se debe definir una nueva interfaz e implementarla. Se hizo así para simplicidad del ejemplo.

Ahora compilamos el servicio agregando la referencia al ensamblado generado previamente:

>csc /t:library Hello.cs /r:System.ServiceModel.dll,HelloData.dll

El host y su archivo de configuración permanecen sin cambios, por lo que solo resta ejecutar HelloHost.exe.

Ahora pasamos al cliente. Primero regeneramos los artefactos cliente con svcutil.exe como hasta ahora, y después modificamos el código de la aplicación cliente, tal como se aprecia a continuación:

Listado de Client.cs

using System;

public class Client
{
  static void Main(string[] args)
  {
    String arg = null;
    String result = null;
    if (args.Length > 0) {
      arg = args[0];
    }
    else {
      arg = "Anónimo";
    }
    try {
      hello.IHello service = new hello.HelloClient();
      hello.data.Person person = new hello.data.Person();
      person.FirstName = arg;
      hello.data.HelloCard card = service.SayHello(person);
      result = card.Greeting;
    }
    catch (System.ServiceModel.FaultException fault) 
    { 
      result = fault.Message; 
    }
    catch (Exception ex) {
      result = ex.ToString();
    }
    finally{
      System.Console.WriteLine(result);
    }
  }
}

Compilamos los archivos del proxy y el cliente, y ejecutamos Client.exe como hasta ahora.

Nota: Además de DataContractSerializer, WCF también admite (de forma excluyente) la clase XmlSerializer, que es el mismo mecanismo de serialización utilizado en Servicios Web ASP.NET (aka ASMX). Aunque XmlSerializer solo admite un conjunto reducido de tipos, permite un mayor control sobre el XML resultante y admite mejor la norma de XSD. Para más información consulte Utilización de XMLSerializer.

WCF bajo contrato (1/4)

Como continuación al artículo Servicios Web con WCF: Una sencilla introducción a Servicios Web con WCF, la presente serie abordará de manera sencilla los principales tipos de contratos que se emplean para definir los Servicios de WCF. La finalidad es dar una introducción práctica a los mismos, sin pretender ser exhaustivo. Así que partiendo del servicio Hello del artículo anterior, comencemos por el Contrato de Servicio.

Contrato de Servicio

Un contrato de servicio permite la comunicación con el mismo, al proporcionar la siguiente información:

Listado de las operaciones que ofrece y la ubicación de las mismas
Firma de las operaciones, en términos de intercambio de mensajes
Tipos de datos empleados en los mensajes.
Protocolos concretos y formatos de serialización.

Para esto se utilizan los documentos WSDL y XSD, que son lenguajes estándar para describir servicios web. No obstante WSDL y XSD son difíciles de utilizar, por ello las aplicaciones WCF utilizan atributos, interfaces y clases para definir la estructura de un servicio e implementar un servicio.

En el artículo anterior se define el contrato del servicio utilizando la clase de implementación del mismo. Sin embargo es recomendable utilizar una interfaz para ello, ya que, al igual que un contrato de servicios, las interfaces solo definen la agrupación de métodos (operaciones) con ciertas firmas sin especificar ningún detalle sobre su implementación. Además, todas las ventajas de las interfaces administradas se aplican a las interfaces de contrato de servicio:

Las interfaces pueden extender cualquier número de interfaces.
Una única clase puede implementar cualquier número de interfaces.
Puede modificar la implementación de una interfaz, mientras la interfaz siga siendo la misma.

Por lo que adicionalmente se puede controlar la versión del servicio implementando la interfaz antigua y la nueva. Los clientes antiguos se conectan a la versión original, mientras los clientes más nuevos pueden conectarse a la versión más nueva.

Así que, tras realizar refactoring al Servicio WCF Hello, el contrato y su implementación ahora quedan de la siguiente forma:

Listado de Hello.cs

using System;
using System.Text;
using System.ServiceModel;

namespace hello
{  

  [ServiceContract(Namespace="http://hello/")]
  interface IHello
  {
    [OperationContract()]
    string SayHello(string name);
  }
    
  [ServiceBehavior(Namespace="http://hello/", Name="HelloService")]    
  public class Hello : IHello
  {
    private StringBuilder message = new StringBuilder("Hola ");

    public string SayHello(string name)
    {
      if (name == null || name.Length == 0)
        throw new FaultException("Parámetro 'name' nulo o vacío.");
      string msg = message.Append(name + "!").ToString();
      System.Console.WriteLine(msg);
      return msg;
    }
  }
}

Observe que ahora los atributos ServiceContract y OperationContract se aplican a la interfaz, y que a la clase de implementación sólo se la aplica el atributo ServiceBehavior. Recuerde que los dos primeros atributos definen el contrato del servicio y sus operaciones, mientras que el tercero define comportamientos concretos de la implementación. En el ejemplo los utilizamos para marcar las responsabilidades de cada una, así como el namespace a utilizar en la exportación hacia el WSDL.

Tras compilar el servicio:

>csc /t:library Hello.cs /r:System.ServiceModel.dll

Continuamos con el host. El código de HelloHost.cs permanece sin cambios, pero tenemos que hacer un ligero cambio al archivo de configuración HelloHost.exe.config, de modo ahora el atributo contract del endpoint señale a la interfaz:

Listado de HelloHost.exe.config

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <services>
      <service name="hello.Hello" behaviorConfiguration="enableMetadata">
        <endpoint contract="hello.IHello" binding="basicHttpBinding" address="" 
            bindingNamespace="http://hello/" name="HelloPort" />
        <endpoint contract="IMetadataExchange" binding="mexHttpBinding" address="mex" />
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="enableMetadata" >
          <serviceMetadata httpGetEnabled="true" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

Tras ejecutar el host:

>HelloHost.exe

El Servicio Web Hello se esta ejecutando...
WSDL: http://localhost:8080/Hello?wsdl
Presione una tecla para cerrarlo.

Ahora vamos con el cliente. Primero debemos regenerar los artefactos cliente con svcutil:

>svcutil http://localhost:8080/hello?wsdl /out:Hello.cs /config:Client.exe.config /n:http://hello/,hello

Después modificamos una línea del código de la aplicación cliente:

Listado de Client.cs

using System;

public class Client
{
  static void Main(string[] args)
  {
    String arg = null;
    String result = null;
    if (args.Length > 0) {
      arg = args[0];
    }
    else {
      arg = "Anónimo";
    }
    try {      
      hello.IHello service = new hello.HelloClient();
      result = service.SayHello(arg);
    }
    catch (System.ServiceModel.FaultException fault) 
    { 
      result = fault.Message; 
    }
    catch (Exception ex) {
      result = ex.ToString();
    }
    finally{
      System.Console.WriteLine(result);
    }
  }
}

Compilamos tanto el proxy como la aplicación:

>csc /t:library Hello.cs /r:System.ServiceModel.dll

>csc /t:exe Client.cs /r:System.ServiceModel.dll,Hello.dll

Y la ejecución será la misma que la última vez:

>Client Willy

Hola Willy.

SQL Server 2008 RC

A comenzado la saga RC de SQL Server 2008, el RTM se acerca...

SQL Server 2008 Express RC0: edición funcional ideal para aprender y ejecutar aplicaciones de base de datos de escritorio y de servidor a pequeña escala. SQL Server 2008 Express admite 1 CPU, 1 GB de RAM y bases de datos de hasta 4 GB.

Ejecute el archivo de descarga para copiar los archivos de instalación en el directorio Temp. La instalación comenzará una vez se haya completado la extracción. No es necesario buscar e iniciar setup.exe manualmente.

SQL Server 2008 Express Advanced RC0: edición Express que además incluye una plataforma básica de informes y administración de datos con funcionalidad completa.

Tanto el formato de archivo de descarga como el inicio del proceso de instalación son idénticos para SQL Express.

SQL Server 2008 RC0: versión de prueba para crear y probar cualquier tipo de aplicación. Incluye toda la funcionalidad de SQL Server 2008 Enterprise, pero sólo está autorizado para el uso de desarrollo, prueba y demostración.

Ejecute el archivo de descarga. En el símbolo del sistema, seleccione un directorio y pulse Siguiente. Una vez finalizado el paso de extracción automática, busque y haga doble clic en Setup.exe en el directorio seleccionado para comenzar la instalación.

Además de SQL Server Evaluation, puede probar las ediciones Standard y Enterprise, para ello especifique la clave del producto correspondiente para desbloquear la edición que desea.

Más información en: SQL Server 2008 Release Candidate 0.

Silverlight 2 Beta 2

Microsoft ha liberado la segunda beta pública de Silverlight 2.

¿Que es Silverlight?

Silverlight (antes WPF/E) es una nueva tecnología de presentación Web propuesta por Microsoft, creada para su ejecución en distintos browser HTTP y en múltiples dispositivos y sistemas operativos de escritorio. Al igual que WPF (Windows Presentation Foundation), la tecnología de presentación en Microsoft .NET Framework 3.0: XAML (eXtensible Application Markup Language), constituye la base de la capacidad de presentación de Silverlight.
Parafraseado de Introducción a Silverlight.

Algunas características de Siverlight 2 Beta 2:

Soporte de lenguajes .NET: VB.NET, C#, Iron Python e IronRuby
Nuevo conjunto de controles (Button, ListBox, Slider, CheckBox, DataGrid, Calendar, TabPanel, etc.)
Edición de plantilla de controles
VSM (Visual State Manager)
Caching cliente
Soporte para WCF
Programación XML
LINQ to XML y LINQ to Objects
ADO.NET Data Services
Tecnología Deep Zoom

Descargas:

Mayor información:

Velocidad de datos

El equipo de Datos de Microsoft se encuentra trabajando en un proyecto de caching llamado "Velocity" del cual ya ha publicado el primer CTP. Pretenden que el producto resultante del proyecto sea una plataforma de caché en memoria que proporcione a las aplicaciones .NET el acceso a datos a alta velocidad, de forma escalable y con alta disponibilidad.

Principales características:

Almacenamiento de cualquier objeto CLR serializable y acceso mediante APIs simples
Caché de alto desempeño para todas la aplicaciones de datos
Ejecución tanto como servicio de red como embebido en aplicaciones
Soporte para las configuraciones más comunes de caché
Escalamiento dinámico
Balanceo de carga automático
Compatibilidad con ASP.NET e IIS.
Alta disponibilidad al mantener copias de datos en múltiples nodos
Soporte de múltiples lenguajes del lado cliente (PHP, C#, C++, etc.)

Para mayor información visitar:

Guia de Seguridad WCF (Beta)

El equipo de patterns & practices ha publicado la versión beta de su guía de seguridad en Servicios Web titulada:

Improving Web Services Security: Scenarios and Implementation Guidance for WCF

En la cual se muestra cómo mejorar la seguridad de WCF mediante escenarios, guías directivas, Preguntas & Respuestas, listados Como-Se-Hace, etc... La guía está relacionada con el proyecto de seguridad: WCF Security Guidance Project.

Mayor información y descarga de la guía en:

WCF Web Services Security Guide.