francesc jaumot

Microsoft Build (Anaheim, California)

Todas las previsiones se han cumplido con creces. Microsoft, que apostó fuerte con el nuevo Windows Phone, repite la estrategia con Windows 8. La ruptura absoluta con lo que hoy es conocido, con un excelente inicio para la nueva etapa post-PC.

La experiencia Windows 8 es una asimilación de que todo está cambiando en los ordenadores personales y en el mundo de los negocios. Avisos, notificaciones, eventos, conexión… todo lo que estamos acostumbrados a acceder al instante en tablets y teléfonos lo tendremos ahora en la pantalla principal del nuevo Windows 8.

La nueva interfaz Metro, protagonista del futuro de Microsoft y una apuesta valiente que hay que reconocerles. No se han dejado influir por lo que iOs o Android estaban imponiendo y desde Microsoft han decidio encaminarse en solitario con un resultado excelente para todos. Se ha mejorado el control táctil y las aplicaciones, que en Windows 8 son homogéneas dejando menos libertad al desarrollador, funcionando a pantalla completa y haciendo que nos olvidemos de barras de menús y tareas. La multitarea es completa pudiendo usar varias aplicaciones a la vez en la misma pantalla y al mismo momento.

No podía faltar la conexión con la nube dónde la única necesidad es tener un identificador Live y de todas las cuentas de servicios en la nube, ya sean propias o de terceros. Windows 8 será el encargado de que la información, documentos y contenido relevante, así como los contactos, se sincronicen en todos los equipos conectados.

Por último, aunque todo se ha mostrado en dispositivos táctiles, da igual que se use el dedo, el teclado o el ratón pues ha sido creado para que sea independiente del dispositivo en el cúal se instale. Su espectacular rendimiento se ha mostrado aún más eficiente que sus antecesores; usa menos memoria que Windows 7 encendido siendo más y más fluido.

Windows 8 hereda la idea de suspensión del mundo de la telefonía, con desploqueo immediato y actualización aunque esté en pausa. La BIOS ha pasado a la historia y llega EFI, con más posibilidades y más enfocado al consumidor que al experto, incluyendo un solucionador de problemas, limpieza del sistema operativo o arranque des de USB, y no 2.0 si no 3.0. También tenemos novedades en la gestión de redes, pues puede conectarse vía WiFi, Ethernet o 3G.

En la próxima entrada hablaré sobre Win RT y veremos las novedades de Visual Studio 2011.
Enjoy!

MTOM cómo codificación de ficheros en WCF

MTOM (Mecanismo de optimización de transmisión del mensaje), como su nombre indica, es un mecanismo para transmitir datos binarios grandes con basicHttpBinding. De forma predeterminada, basicHttpBinding envía y recibe los mensajes en XML y este tipo de encoding del mensaje debe ser habilitado en la configuración de nuestro proyecto cómo veremos más adelante.

El objetivo de usar MTOM en vez de otro encoding de mensajes, no es otro que optimizar la transmisión de grandes cargas binarias. Al contrario, esta codificación cuándo se usa para pequeñas cargas añade una sobrecarga innecesaria en nuestro mensaje por lo que debemos saber cuándo debemos usarlo, aunque teniendo en cuenta los documentos que se usan hoy en día y la calidad de las fotografías seguramente lo uséis la gran mayoría de las veces.

Antes de empezar os recomiendo que os bajéis el código de ejemplo y lo vais siguiendo con lo que explicaré. Como veréis dentro de la solución que he creado, hay dos carpetas: Cliente y Servidor. La primera de ellas tendrá un proyecto WinForms que nos servirá para subir/bajar archivos y la segunda el servicio WCF. Lo primero que vamos a ver es un sencillo servicio en WCF que nos permitirá subir y bajar archivos de cualquier tipo. Es facil, la interface IService.cs tendrá dos métodos; uno para subir ficheros con el atributo IsOneWay = true para indicar que este método no va a devolver mensaje de respuesta y otro para obtener el fichero. Además dos clases, PeticionDescarga y Fichero. Esta última implementara la interfaz IDisposable para asegurarnos que al terminar la transmisión podremos vaciar el flujo de datos.

Cómo MTOM transmite el mensaje por SOAP debemos formatear las clases cómo tal, así que la clase Fichero contendrá las propiedades NombreFichero y Peso con el atributo [MessageHeader(MustUnderstand = true)] que nos indica que ambas propiedades pertenecerán a la cabecera SOAP (Header) del mensaje y nos permite especificar si el Header deberá ser analizado y comprendido por el destinatario o no. Sí esta a true, al enviar los datos se espera que el receptor comprenda la cabecera y los tenga en el DataContract. La propiedad FicheroBytes tiene el atributo [MessageBodyMember()] que nos indica que será el cuerpo del mensaje.

Ahora viene lo complicado, ¿Cómo hacemos que nuestro servicio transfiera sus datos a través de la codificación MTOM? Configurando el binding de nuestro servicio. Para ello nos situamos en el archivo Web.config y nos deberá quedar, además de las otras etiquetas, la configuración del servicio así:

<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name=“MTOMBinding“ maxReceivedMessageSize=“1048576“ messageEncoding=“Mtom” transferMode=“Streamed“>
</binding>
</basicHttpBinding>
</bindings>
<services>
<service name=“Service“ behaviorConfiguration=“ServiceBehavior“>
<endpoint address=“” binding=“basicHttpBinding“ bindingConfiguration=“MTOMBinding“ contract=“IService“/>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name=“ServiceBehavior“>
<serviceMetadata httpGetEnabled=“true“/>
<serviceDebug includeExceptionDetailInFaults=“true“/>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>

Como veís, le indicamos que la codificación del mensaje será con MTOM y a través del transporte http. Las propiedades a destacar y de importacia són maxReceivedMessageSize que nos indica el tamaño máximo del mensaje total expresado en bytes y transferMode que lo estableceremos a Streamed indicando así que no será un transporte almacenado en un búfer si no que será transmitido, es decir, solo deberán ser almacenadas las cabeceras SOAP y el cuerpo del mensaje será transmitido cúando se haga la petición. Cómo le hemos indicado que será transmitido ahora maxBufferSize deberá ser menor o igual que maxReceivedMessageSize ya que a diferencia de este, maxBufferSize unicamente limita el tamaño máximo de la cabecera SOAP. Para que lo podaís entender mejor, maxBufferSize configura el búfer de WCF que almacena la cabecera del mensaje mientras se procesa el mensaje en el extremo del cliente y no la totalidad del mismo mensaje. Así pues, nuestra cabecera SOAP contendrá el nombre del fichero y el peso tal y cómo hemos configurado la interficie IService.

El servicio no tiene más, lo que haremos ahora es la implementación de la interface y el código de los métodos que no explicaré ya que son muy básicos, aunque podéis preguntar si tenéis cualquier duda por supuesto y además lo más complejo lo he comentado. Algo simple, dentro de Service.cs tendremos implementados los métodos SubirFichero y DescargarFichero.

El método SubirFichero, recibirá una instancia de la clase Fichero con la información del archivo a subir: su nombre, tamaño y el contenido en un stream de bytes. Este método tendrá un FileStream que va a escribir a disco en una ruta concreta el stream de bytes recibido, o sea, el archivo. Y el método DescargarFichero hará todo lo contrario, recibirá una instancia de la clase PeticionDescarga con el nombre del archivo a obtener y va a crear una instancia de la clase Fichero,es decir, el nombre, su longitud y el contenido en un stream devolviendo esta instancia cómo resultado de la llamada al método.

Hasta aquí todo lo que se refiere al servicio, ya lo tenemos terminado y ahora nos toca hacer la parte de cliente. WCF siempre debe de tener almenos un EndPoint así que a esta aplicación cliente le añadiremos una referencia a un servicio, el que hemos hecho, del que deberemos obtener la URL para saber dónde está hospedado. La podremos ver en la barra de direcciones ejecutando el servicio independientemente. Aunque el servicio este configurado, el cliente tiene total libertad para decidir cómo actuar con el servicio cómo por ejemplo en nuestro caso le estamos indicando que únicamente (como servicio) podremos recibir 1Mb y mediante Streamed. El cliente debe responder con acuerdo a nuestras configuraciones pero por ejemplo puede hacer que el tamaño máximo que se envié al servicio sea de 0,5Mb.

Bien, los parametros a configurar del lado cliente van a ser el maxBufferSize, maxReceivedMessageSize y transferMode. Se debe indicar que el tamaño maximo sea igual o menor que el tamaño que permite el servico (>= 1mb), en caso contrario el servicio lanzará una excepción indicando que no soporta un tamaño superior. Con el último parámetro debemos tener cuidado, debe ser transferMode=“StreamedResponse” porqué nuestro servicio espera recibir las cabeceras SOAP en un buffer y recibir la transmisión del mensaje al momento del envío. De esta forma evitamos tener un buffer con miles de bytes debido al gran peso del fichero.

Comentar que las carpetas de subida y descarga se crearan dentro de los proyectos correspondientes. La de subida dentro del App_Code del servicio y la de descarga dentro del bin del cliente.Para obtener el código, que esta adjunto, debéis abrir el archivo MTOM.zip y copiar cada una de las subcarpetas que contiene Projects y WebSites dentro de las carpetas de proyecto de Visual Studio 2008 y abrir la solución Ficheros.sln. Está hecho con el Framework 3.5 y c#, como no

Espero que no dudéis en preguntar y que os guste el post! Happy code!

MTOM

Microsoft LightSwitch 2011

Desde Redmond (Seattle,WA) nos llegan buenas noticias con  productos frescos y es que hace unos días, 27 de Julio, ha salido a la luz (y nunca mejor dicho ) la herramienta de desarrollo simplificado Visual Studio LightSwitch.

Esta vez, y aunque no menos importante, el código pasa a un segundo plano mientras nos dedicamos a crear una aplicación útil e intuitiva con un entorno manejable a cualquier nivel de habilidad permitiéndonos crear nuestra aplicación profesional orientada a cualquier entorno; web , escritorio y en la nube.

La mayor contribución de esta nueva aplicación empresarial es su contribución a la aceleración en la fase de desarrollo al mismo tiempo que reduce la complejidad de crear una UI sencilla y las dificultades de un despliegue en entornos complejos, cómo por ejemplo, la nube. Va a resultar definitivamente practico crear soluciones de software personalizables, escalables y más accesibles económicamente vinculadas a los sistemas que tenemos actualmente para complementar el trabajo con la información.

Entrando en las entrañas de nuestra ímpetu tecnológica y destripadores de código fuente esta herramienta es capaz de realizar la anatomía de la aplicación con todas las tecnologías existentes de MS con la posibilidad de que sea N-Layer o bien, N-Tier. Estos conceptos hay que tenerlos muy claros, pues son diferentes en todos sus aspectos. Cuándo estamos hablando de N-Layer, nos referimos a la delegación lógica de las funcionalidades; un ejemplo sería presentación, lógica de negocio y acceso a datos. Por lo contrario cuándo se habla de N-Tier, nos referimos a la separación física de los diferentes componentes de nuestra aplicación; un ejemplo sería una aplicación para dispositivos móviles que se comunica mediante WCF con el servidor de lógica de negocio y esta se comunica con el servidor de base de datos que está hospedado en un servidor diferente. Bien, ambas arquitecturas son soportadas por LightSwitch.

Cómo visión genérica, gracias a este producto desaparece la complejidad para hacer una aplicación N-Layer y N-Tier centrándose únicamente en el funcionamiento esencial de la aplicación que vamos a realizar. Para la capa de presentación, podremos usar Silverlight 4.0 ejecutándose en el browser o bien out of browser (Windows desktop application). Su lógica de negocio puede ser expuesta a través de WCF RIA  Services debajo de ASP.NET y hospedada en un servidor IIS o bien en un WebRole de Windows Azure. Una aplicación realizada con LightSwitch puede almacenar y leer datos de SQL Server, SQL Azure e incluso de listas de SharePoint 2010 mediante Entity Framework o proveedores personalizados de WCF RIA.

LightSwitch tiene unas arquitecturas muy bien definidas y extensibles para la capa de presentación, lógica y acceso a datos. Aunque estas las trataremos en próximas entradas, pues son extensas y hay que explicarlas con detalle.

¡Un saludo!

Microsoft Surface SDK 2.0

“Write once – touch anywhere” (Escribe una vez – toca en cualquier lugar) será, seguramente, la próxima generación de desarrollo de software en Microsoft Surface que admitirá el desarrollo de proyectos independientemente del hardware e incluso, con PC que admitan tecnologías “Touch”. En el Mix de este año, MSFT ya nos informó del nuevo Kit de desarrollo para verano y así ha sido. El pasado 12 de Julio salió para la descarga pública el nuevo SDK 2.0 que incluye tecnologías cómo WPF (Windows Presentation Foundation) 4.0, XNA 4.0 y Windows 7 para 32 y 64 bits. Hay que tener en cuenta que las aplicaciones realizadas en Silverlight, aunque puedas usar los eventos de Windows Touch, no son aplicaciones para Surface ni usan la enriquecida experiencia de usuario que puedes obtener con el SDK aunque, si sabéis Silverlight, con WPF 4.0 no vais a tener problemas ya que todo es XAML. Para los que ya habéis usado SDK 1.0 no os preocupéis, vuestra aplicación funcionará perfectamente en el nuevo SDK aunque debéis convertir vuestra aplicación al SDK 2.0 con la herramienta PowerToy

A partir de este momento, tan solo queda instalar las herramientas para aprender el modelo de programación de esta nueva experiencia de usuario. ¡Comencemos!