[Serie] TechEd 2007- 4ta Jornada

 El  Jueves mi día comenzó al frente de la estación de demos, donde ya las preguntas se empezaban a repetir (obvio, preguntando gente diferente, claro). La más destacable es la de un caballero que se me acercó algo preocupado ya que me decía que los modelos de arquitectura que varias sesiones muestran parecen chocar entre si, lo que le daba la idea de que no hay una única forma de parar una arquitectura, sino que contextos diferentes parecían tener enfoques particulares

Eso obviamente le generaba cierta inseguridad de tomar el camino equivocado, por lo que me preguntó "vos qué harías?" (juah! Número equivocado…)

No, fuera de broma. Lo que le respondí es lo que realmente yo empecé a hacer hace ya varios años, cuando entendí que el paradigma orientado a objetos es mejor en aplicaciones monóliticas y ya no tan bueno en aplicaciones multicapa, principalmente cuando las capas están en procesos diferentes (posiblemente de servidores físicos también diferentes)

La razón? Que al separar las capas lo que se busca es ganar cierta independencia, pudiendo mantenerlas por equipos diferentes y con ciclos de vida ocasionalmente coordinados, aunque no necesariamente (lo que permite ganar agilidad y responder más rápidamente a ciertos cambios de negocio)

En cambio, al compartir clases entre las capas (con conducta, propiedades que los caracterizan a lo largo de toda la aplicación) la cosa se empieza a salir un tanto de cauce ya que cualquier clase que se es alterada implica puede impactar en todo el resto (no necesariamente cierto aunque con gran probabilidad)

El asunto entonces pasaría por exponer servicios entre las distintas capas (suena a guitarreada pero la realidad terminó por imponer eso porque, se acepte o no, funcionó). Y mensajes deberían viajar entre las mismas, llevando objetos de transferencia de datos (data transfer objects, o DTOs), disponibles a lo largo de todo el caso de uso (quizás reusables entre unos pocos casos de uso, pero no ilusionarse con compartirlos a lo largo de toda la aplicación)

Los servicios expuestos hacia afuera, internamente son llevados a cabo por clases que modelan procesos de negocio (casos de uso, basicamente hablando)

Los mismos no deberían guardar estado, sino que trabajan sobre el estado del/los DTOs que hayan recibido en cada método (o servicio, si es que los llamaron de afuera)

El hecho de que no guarden estado habilita a escalar la granja de servidores para cada capa sin mayor impacto en el código

Es claro que el único caso en que se va a sentir impacto a ambas márgenes (capas, tiers, etc) es cuando el DTO a traficar deba llevar más datos. Pero siendo que el DTO debería estar limitado al caso de uso, eso ocurriría cuando la necesidad la tenga el caso de uso, con lo cual es más que súper razonable cambiar el mensaje de intercambio

Ese por qué no se veía tan obvio, o al menos a mí no me gustaba, cuando el cambio se produjo en un caso de uso diferente pero termina impactando en todos los casos de uso perejiles que andaban compartiendo lo innecesario

Poooorrrrrrrrrrrrrrrrrr lo menos, así, lo veo… yo. Más info al respecto he publicado alguna vez y hace tiempo acá

 

Después estuve charlando un poco con un MVP muy particular, Jeffrey Palermo, acerca de lo complejo que es organizar eventos y que encima estos salgan a la altura de las expectativas de quienes pagaron por asistir… y de quienes cobramos también. Jeffrey, puedo dar fe, conoce del tema. El suele organizar unas fiestas muy tradicionales hoy, conocidas como Party with Palermo. El muchacho tira la casa por la ventana sin oblar un sólo níquel ni -del mismo modo- ganar metálico alguno a cambio. Cómo hace? Llama a editorial Wrox, a Apress!, a O’Reilly, a los productores AMD, MaxStore, Microsoft, y otros. A todos les hace aportar para la causa. A cambio, claro, de espacios de publicidad y el derecho a poner algún que otro stand con promotoras, etc. Qué tul, el amigo? Yo lamentablemente me perdí la que organizó para este TechEd (ver fotos) porque fue el Domingo 3 cuando los amigos de United me tenían en el Maelström

 

En paralelo a todo esto, el amigo David Platt estuvo dando una presentación magistral -la que fue muy bien recibida en las encuestas- sobre la Arquitectura del Composite UI Application Block (CAB UI) y el posterior Smart Client Software Factory (SCSF) que lo incorporó como parte constituyente. La charla más que nada se enfocó a mostrar ejemplos concretos de bajo acoplamiento presentes en estas dos tecnologías sea para manejo de eventos, para la exposición de una interfaz de usuario (UI) compartida entre varias partes (conocidas como smartparts), para la disponibilidad de servicios que desde cualquier parte de la aplicación se pueden consumir y, por supuesto, para la configuración de todo lo anterior (sea vía XML, una base de datos remota, un servicio web inclusive). Cool

Entonces llegó el turno de Scott Jamison, un arquitecto de Microsoft responsable de las aplicaciones basadas en Office, que resultó la revelación del track. Las claves del éxito de Jamison estuvieron dadas en el hecho de que abordó el problema por donde se lo debe abordar: las necesidades del negocio primero. En esta ocasión, Scott mencionó la necesidad de consolidar información de distintas fuentes (de manera que SOA pague por lo que fue) de manera de poner esas conclusiones no ya a la mano de gerentes sino de empleados en general. Información fácil de atajar para reaccionar con agilidad a los ritmos del negocio
Y entonces encaró el problema como un arquitecto lo debe hacer, enunciando diversos posibles caminos y marcando de cada uno sus pros y contras. Entonces llega a uno de los puntos tabú de las aplicaciones empresariales: comprar versus construir. O "alivianar la carga y eficientizar la fuerza tecnológica para favorecer el negocio" versus "darle la chance a los empleados del área de tecnología de que hagan lo que más les gusta: contruir absolutamente todo (incluyendo las herramientas que sirven para contruir)". Jamison se volvó consistentemente por la primera opción, y destacó que la posibilidad de exponer funcionalidades desperdigadas en la forma de servicios web, habilita al consumo de los mismos desde componentes construidos para ensamblar Aplicaciones Compuestas, trazando entonces un paralelo entre las mismas y los servicios que ellas consumen
Luego mostró cómo las distintas aplicaciones que integran 2007 Office System sirven como contenedores de componentes que consuman servicios web (o XML plano) para agregar otros tipos de valores, y lo sencillo que es construir componentes para estos contenedores de la plataforma. Y así calló en la cuenta de que Sharepoint Server encaja prolijamente en una nueva capa entre la de presentación y la de negocio: la capa de Productividad. La necesidad de la misma se funda en el hecho de que una capa de negocio tal como la conocemos aborda sólo aspectos funcionales de la aplicación que la contiene. Pero si a nivel empresarial tenemos varias de estas aplicaciones, las capas de negocio de las mismas están -en el mejor de los casos- débilmente conectadas, lo que hace que los usuarios deban usar más de una aplicación para satisfacer necesidades cruzadas (a veces, aunque no frecuente, en un mismo caso de uso)
Así llegó una caracterización del Sharepoint, como plataforma escalable que permite exponer documentos como componentes que vinculan varias aplicaciones y que extender el alcance toma cortos tiempos de desarrollo ya que sólo se trata de construir puentes: no funcionalidades completas. Sharepoint provée per se no sólo administración de contenido (content management o CM) y colaboración sino también Inteligencia de negocios (business intelligence o BI) y principalmente capacidades de búsqueda (searching capabilities), entre otras características out-of-box
Jamison destacó cómo eso es aplicable en forma de patrones. De diseño, sí, pero de negocio esta vez, de manera de componer aplicaciones con piezas (funcionalidades en la forma de servicios, datos en la forma de XML, etc) que encajen en estos patrones y ofreció ejemplos claros y concretos de ello. En cada uno de ellos, al final, mostraba el clásico diagrama de arquitectura en capas (presentación, negocio, datos y ahora también productividad), mostrando cómo 2007 Office System encajaba, para en dicho patrón. Por supuesto, no eran ejemplos de Powerpoint sino que Scott tenía demos ya construidas que analizó en vivo
Al final de su sesión se dedicó a firmar ejemplares del libro "Essential Sharepoint 2007 – Delivering High-Impact Collaboration", que escribió con Mauro Cardarelli y Susan Hanley (Addison-Wesley, 2007). Aunque su sesión, por el tema que abordaba, no convocó masivamente, el público que asistió marcó en las encuestas un alto grado de satisfacción (8.29 de 9). Necesito más scottjamisons para este tipo de eventos

Entonces tocó el turno de David Clark, un arquitecto de infraestructura que, al igual que Jamison, trabaja para Microsoft (y al igual que los restantes presentadores de Microsoft, siendo Jamison la excepción que confirma la regla, no le va tan bien como a los oradores no Microsoft -algo que ya habíamos previsto al armar la agenda, privilegiando a los no Microsoft; la expectativa que se genera es diferente cuando el speaker pertenece a Microsoft, ya que deja de importar cómo se llama sino que para quién trabaja pasa a ser lo más relevante y por ende se espera algo que realmente provoque un sacudón; cuando el orador es independiente, es decir, no trabaja ni para Microsoft ni para ningun otro de los grandes jugadores, lo que menos importa es para quién trabaja-
Clark habló de Zero-Touch Provisioning (ZTP), un mecanismo para configurar desde cuentas, hasta workstations, servidores, servicios, software en general e incluso hardware (no sólo notebooks o PCs, también PDAs, impresoras, etc), con una mínima intervención humana (posiblemente nula), delegando las acciones en políticas (policies), scripting y otras facilidades otorgadas por Windows Server
El resultado neto implica una ganancia en seguridad y eficiencia (casos típicos, cuando un empleado deja la organización y hay que revocar todos los derechos de acceso a aplicaciones en múltiples sistemas, etc). Una arquitectura completa dentro de la plataforma Windows le da cabida a Biztalk Server (que va a ejecutar el workflow de actividades),  a Active Directory (donde los permisos van a quedar almacenados) a MIIS (Microsoft Identity Integration Server, cuya versión compatible con Windows Server 2008 pasará a llamarse Identity Lifecycle Manager), quien se va a encargar de interfacear con sistemas externos, a Sharepoint Services (útil para la capa de presentación integrada) y, por supuesto, a .NET (el vehículo que transforma estímulos en comandos); también habló del roadmap de ZTP, el rol que va a jugar PowerShell (el mecanismo de scripting que sustituye a Visual Basic Script), el rol de .NET 3.0, de Windows Server 2008…
En fin, me encantó a mí -personalmente hablando- la sesión, sus contenidos, sus demos, la forma en que se estructuró, sus porqués…
… pero el público le dio la espalda. La ley de Murphy para los oradores que pertenecen a Microsoft se volvió a cumplir acá
Clark explicó definiciones para novatos, mostró workflows de cierta complejidad, contó cómo todo el arco de la infraestructura Windows se tensa para lanzar la flecha del aprovisionamiento lo más lejos posible (la metáfora es mía)… Qué querés que te diga: cuando esta sesión esté disponible, vela por favor. Te va a sorprender, te va -por supuesto- a gustar, y te va a instruir de cómo tu organización puede ganar en seguridad, eficiencia y productividad en lo que a infrastructure deployment (despliegue de infraestructura: hardware y software de base) se refiere

Durante la tarde, Beat Schwegler (un arquitecto de Microsoft Suiza que manejó la agenda del track de Arquitectura para el TechEd Europe 2006 en Barcelona y logró el primer puesto! smile_omg) nos dedicó una sesión sobre cómo lograr googlear, dentro de nuestra organización, datos contenidos en nuestras aplicaciones. Una forma más de ver Inteligencia de Negocios (Business Intelligence o BI). Beat, en realidad, estableció las diferencias entre googlear en la web y googlear en la empresa. En la web cada server es un nodo (node) y un link en una página web es una conexión entre nodos, por lo que el problema de clasificar la información de la web pasa a ser un problema de matemática discreta. En la empresa, en cambio, la info está no sólo en nuestras propias aplicaciones (on shore) sino que puede estar en sistemas externos (off shore). Además, según cada quién, los usuarios buscadores no somos todos iguales: según que el que busque sea un empleado del front desk o uno del back office, la info debería agruparse y rankearse en forma diferente (y seguramente las experiencias de usuario pueden llegar a diferir de acuerdo al contexto de trabajo -usuarios en la calle con dispositivos móviles, usuarios en la oficina en un puesto fijo, etc-). Hay que lidiar no necesariamente con páginas web sino con datos que a veces están estructurados (bases de datos), semi estructurados (archivos XML) o no estructurados (documentos, mails, planillas de cálculo, etc)
Entonces, ya en el plano de las propuestas, Beat mencionó "la" plataforma para aplicaciones empresariales que habilita búsquedas libres para información no sólo en bases de datos sino también detrás de servicios web o archivos propietarios, incluyendo la posibilidad de definir señaladores (bookmarks). Mostró asimismo la arquitectura de tal plataforma (con servidores de consultas directamente accesibles por los servidores de aplicación, pero a la vez dependientes de los servidores de indexado sobre las fuentes de los datos)
Y lógico, cuando dijo el nombre de la misma, 2007 Office System, en seguida salió a atajarse del rechazo que les genera a algunos la sola mención de Sharepoint como contenedor de aplicaciones web, ya que consideran que Sharepoint provée una interfaz de usuario muy fría (y -presumen- poco configurable). Al respecto Beat mostró, y yo te invito (desafío en realidad) a que la veas vos también, la aplicación que Hed Kandi -sello discográfico inglés especializado en música house– creó sobre Sharepoint más ASP.NET webparts: http://beta.hedkandi.com/ (posta, eh? Esta versión actual maneja la multimedia en el browser todavía con Adobe Flash, pero ya se proyectan hacer uso de Silverlight en un futuro cercano). Esta aplicación, mientras tanto, hace uso de los workflows de contenido que Sharepoint habilita crear, así como también de sus mecanismos de búsqueda, sus Business Data Catalogs (BDCs, un mecanismo que permite pluguear información de fuentes externas -las que comentaba antes- de modo que Sharepoint pueda operar sobre ella), la interfaz de usuario extensible vía webparts ASP.NET, el formato de datos OpenXML y la seguridad que provée la plataforma
Beat mostró los mecanismos de indexado sobre BDCs para facilitar las posteriores búsquedas de información, y las consiguientes estrategias de llamada al búscador (sea por una URL con parámetros HTTP GET, sea por suscripción a un RSS de búsqueda -o sea, un RSS que va agregando los posibles resultados que la búsqueda arrojaría a lo largo de la vida de la suscripción-, sea mediante la invocación de un servicio web -mecanismo adecuado cuando "quien" va a buscar es un proceso y no una persona)
Mi opinión personal? Aquellos que vean la oportunidad en construir aplicaciones que habiliten búsquedas sobre su información, van a comenzar a hacer que la montaña empiece a ir sola hacia Mahoma

La jornada se cerró con Mark Pollack y Rod Johnson (project manager de la versión .NET del framework Spring y padre de dicho framework, respectivamente). En su sesión -de la cual debo admitir, yo tenía gran expectativa- comentaron acerca de lo complejo que resulta desarrollar aplicaciones sobre las plataformas básicas como Java EE o .NET, la necesidad de contar con frameworks que levanten el nivel de abstracción y habiliten montar aplicaciones sobre ellos, mediante extensiones basadas en objetos planos (esto es, no casados con ninguna API o plataforma), de modo de acelerar los tiempos de desarrollo, mejorar las condiciones para un testing unitario de cada uno de sus componentes, etc
Así destacaron las cualidades aportadas por Spring.NET, para configuración de aplicaciones (con características propias de un contenedor liviano -o lightweight container– ya que permite tomar sólo lo mínimo indispensable y nada más, no es una solución todo-o-nada ni obliga a extender APIs propias que inutilizarán la inversión si el framework un buen día es reemplazado
También, mostraron cómo Spring.NET habilita AOP (Programación Orientada a AspectosAspect-Oriented Programming-), un modelo liviano de programación para acceso a datos, a servicios middleware como ser colas de mensajería, a ASP.NET e incluso a frameworks open source como NHibernate, etc
Si bien es absolutamente cierto que Spring.NET no es una mera portación del Spring de Java (un estándar de facto en dicha plataforma), quedó la sensación de que "programar en Spring .NET" si se parecía mucho al entorno de programación de Spring Java: escasa o nula integración con Visual Studio u otro IDE, con lo cual Spring.NET no se vio tan atractivo frente a otros frameworks como los que provée Patterns and Practices, integrados a Visual Studio en la forma de Sofware Factories, etc. El público reclamó por eso en el momento de las preguntas, y ante la respuesta vacilante y dubitativa de los oradores, hicieron valer cierto descontento en las evaluaciones

De ahí me fui a la festichola del evento, y a la cucha

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

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