Cómo Indigo cambiará la forma de comunicar aplicaciones

 Éste  es el primero de una serie de tres artículos centrados en nuevos modelos de programación .NET que acompañarán la próxima versión del sistema operativo de Microsoft: Windows Vista (antes conocida como Longhorn)

Vista implica un cambio mayúsculo en la forma en que tanto Microsoft como el resto de la industria concebían a los sistemas operativos. Me voy a centrar en tres pilares sobre los cuales esta próxima versión del sistema operativo que todos tenemos se va a apoyar. Pilares que van a hacer el desarrollo de aplicaciones en plataforma .NET más fácil y potente de lo que ya venía siendo

Estos pilares son

  • Comunicaciones, mediante Windows Communication Foundation o WCF (previamente conocido como Indigo, su code name)
  • Flujos, gracias al recientemente anunciado Windows Workflow Foundation o WWF
  • Presentación, a través de Windows Presentation Foundation o WPF (antes conocido como Avalon)

Decía entonces que el mismo sistema operativo va a estar apoyado en estos pilares, los cuales a su vez tendrán sus respectivas API’s disponibles para desarrolladores .NET. En este artículo me voy a enfocar en el primero

Actualmente no es ajeno a nadie que las organizaciones tienen una heterogeneidad de plataformas maduradas a lo largo de estos últimos años, con inversiones ya realizadas y en muchos casos aún no amortizadas

Las empresas que yo visito encuentran interesante a la plataforma .NET, no obstante me plantean siempre el pero de que "es impensable migrar toda la arquitectura empresarial a esta plataforma", por lo que me preguntan qué tan viable es desarrollar en .NET y reaprovechar funcionalidades a nivel de componentes en sus plataformas previas (COBOL, Java/JEE, Visual Basic viejo, etc)

La respuesta siempre es afirmativa, y formas de interoperabilidad hubo para elegir según la necesidad. Repasemos:

  • Mediante colas de mensajes, la API System.Messaging junto con MS MQ es la respuesta
  • Poniendo disponibles objetos de negocio que contemplen seguridad y contextos transaccionales vía Enterprise Services y su API, System.EnterpriseServices
  • A través del -por default propietario aunque ilimitadamente extensible- esquema de invocaciones remotas .NET Remoting, y la API System.Runtime.Remoting. Especial mención a las piezas basadas en .NET Remoting que hablan Java RMI por la otra punta y permiten enlazar en ambos sentidos .NET y JEE
  • Por intermedio del ampliamente disponible estándar de Servicios Web XML, tanto en el simplísimo aunque limitadamente básico ASMX -ASP.NET-, o aprovechando la variante extendida conocida como Web Services Enhancements (WSE), que en cada release incrementa la implementación de la arquitectura WS-*. Especialmente en cuanto a seguridad. No tan así con la inclusión de contextos transaccionales o mensajería confiable (este último soportado parcialmente)

Tal despliegue de variantes no hace más que confundir al desarrollador a la hora de decidir una tecnología para interoperabilidad, lo que motivó a publicar decenas de artículos aclaratorios y orientadores (Choosing Communication Options in .NET, Choosing a Distributed Technology, por mencionar sólo dos)

WCF procura dar vuelta la página, ofreciendo un modelo unificado de programación para desarrollar servicios web avanzados. Es sabido que Microsoft apostó por los servicios Web como un estándar emergente en interoperabilidad de aplicaciones. El Gartner Group durante los últimos años vino evaluando a esta compañía como la de mayor visión y habilidad de ejecución, por delante de IBM, Oracle, Sun y otros jugadores importantes. Con WCF, Microsoft redobla la apuesta, apuntando a que todos sus esquemas de conectividad consideren a esta tecnología de web services como la primera alternativa

Así, necesitamos postear un mensaje a una cola MS MQWCF se encarga. Tenemos que gatillar un proceso de negocio mediante Biztalk Server? WCF es el principal adaptador. Acaso se necesita ejecutar un procedimiento almacenado en SQL Server? Ya no más System.Data.SqlClient: ahora WCF es la forma de comunicarle el requerimiento al servidor. WCF para todo, porque WCF no es que sea una solución única, sino que es un modelo único de programación basado en atributos que se ejecutará con variantes alternativas según cuáles de esos atributos estén presentes

Voy a ir más a lo técnico con eso de "nuevo modelo unificado de programación basado en atributos". WCF no es una nueva API unificada. No es una API! Los servicios se implementan en objetos planos, decorados con aquellos atributos que declaran (no programan) los requerimientos de seguridad, mensajería confiable, contextos transaccionales, etc. Créanme: fácil de asimilar. Eso es lo fantástico del nuevo modelo de programación que viene con Windows Vista, y que me motiva a escribir esta serie. Necesitamos especificar seguridad por roles? PrincipalPermission y otros atributos están para llevar a cabo la tarea. Hace falta explicitar el contexto transaccional? TransactionFlowAllowed, AutoCompleteTransaction o AutoEnlistTransaction, entre otros atributos, están para describir la necesidad. 0 (cero) líneas de código, y es bastante probable que Visual Studio integre un mecanismo visual (por ejemplo la toolbox) para configurar esos aspectos de los servicios web de esta nueva generación

Dos mitos quiero echar abajo acerca de lo que WCF representa

  1. WCF suplanta a Biztalk Server. Nada más alejado de la realidad. Créanme que no son pocos los que opinan que WCF implica "Biztalk gratis". WCF es lo que decíamos: un modelo unificado de programación para comunicar procesos. Biztalk Server es una poderosa herramienta de integración que, a modo de intermediario (broker) puede filtrar mensajes (transformarlos, etc) y orquestar flujos de negocios, entre otras características (Monitoreo de Actividades de NegocioBusiness Activity Monitoring o BAM-, etc), todas ellas no presentes en WCF
    Podemos pensar en WCF con o sin Biztalk Server. Estaremos hablando pues de un esquema peer-to-peer o unbrokered (sin intermediarios) en el primer caso, y de un esquema brokered (con intermediario) si optamos por aprovechar los beneficios de Biztalk. En ambas situaciones, WCF implementa la tecnología de comunicación
  2. WCF es una implementación de Enterprise Service Bus (ESB). Tampoco es cierto. De nuevo: WCF es un modelo unificado de programación para comunicar procesos. Enterprise Service Bus es un patrón de arquitectura para integración de procesos basada en mensajes (amén de que hoy se considere a ESB como un rango de productos). Recordemos que WFC habilita comunicación con o sin intemediario. Esta última implica no tener ESB. En ese sentido, Biztalk Server es una supra implementación de ESB ya que cumple con las características básicas de este patrón y con otras más orientadas al monitoreo del negocio y la facilidad de administración. No me explayo más, dejando la posibilidad de continuar desmitificando WFC como ESB aquí

Para profundizar más sobre esta nueva tecnología recomiendo el artículo Introduction to Building Windows Communication Foundation Services. Este otro artículo, previo al anterior, aclara muy bien varios puntos como por ejemplo la convivencia con tecnologías actuales de interoperabilidad e integración: Introducing Indigo: An Early Look. Por su parte, David Pallmann nos cuenta más en detalle sobre el modelo de programación y los contratos de servicio (ambos capítulos tomados de su libro Programming Indigo, MS Press)

Si bien Windows Communication Foundation está para lanzarse con Windows Vista, esto es en la segunda mitad de 2006, se va a distribuir también como una extensión para el framework .NET 2.0 para entornos XP Profesional o Windows Server 2003. De hecho el último SDK se puede bajar de este sitio. Este kit de desarrollo se debe acompañar del runtime disponible aquí. Y, convenientemente, las extensiones para Visual Studio 2005. Segmentos de código interesantes para revisar y probar están disponibles aquí

En los artículos que siguen voy a abordar los pilares restantes: Comunicación y Flujos. Hasta entonces🙂

Esta entrada fue publicada en Software Architecture. Guarda el enlace permanente.

4 respuestas a Cómo Indigo cambiará la forma de comunicar aplicaciones

  1. Juan Pablo dijo:

    Hola,Un tío que realmente sabe de esto, en rigor lo hizo, me dijo que indigo es como el aceite de un motor que facilita el trabajo de dos piezas que se mueven coordinadamente, en el software indigo hace lo mismo, ayudando a las aplicaciones a trabajar juntas.Además dicen que es tan fácil como el ABC:A.- ADDRESSB.- BINDINGC.- CONTRACT:) JPG

  2. Alexander dijo:

    Gracias Diego por esta articulo – es facil, corto, y correcto – casi perfecto! Una cosa pequeno – se llama Workflow "WF", no "WWF" por causas de conflictos con otros TLA’s (Three Letter Acronyms). Saludos, Alex (Lead PM en Indigo)

  3. Sergio dijo:

    Holas Diego!
     
    Excelente post! Con esto suficiente para ver claramente todo lo que estaba en ingles😀.
     
    P.D.: Me gusto uno de tus comentarios en tu portada: "El que dice conocer Indigo y no visitó esta página de recursos, hablará del Indigo de los pendejos", os pido que me permitas copiarlos, esta muy bueno (Y).
     
    Saludos,

  4. Diego dijo:

    Estimado Sergio,
       encantado de que me cites pero siempre que no me llames Daniel (me llamo Diego). En tu post me llamás así en dos oportunidades: "Como dice Daniel, en su post" y al final, en "Y por último como dice, Daniel, en su portada"
     
       Me llamo "Diego", Sebastián, "Diego" con hache intermedia y acento en la equis 🙂

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s