Hace  unos diez meses atrás había posteado sobre el Desajuste por Impedancia entre Objetos y Tablas Relacionales, mencionando como una de las estrategias para corregir ese desajuste a los Mapeadores entre (Propiedades de) Objetos y (Columnas de) Tablas Relacionales. Los conocidos O/R-M u Object/Relational Mappers

Esta es una alternativa de la cual yo conozco (de veras, no bromeo) innumerables casos de proyectos donde sus responsables entran con la guardia baja pensando que están adoptando una solución políticamente correcta que les va a allanar el camino, acortar tiempos de desarrollo y lograr un producto más robusto y mantenible

Pues bien, voy a ser concreto: Ted Neward, una distinguida voz para los mundos modernos tanto de Java Enterprise Edition (Java EE) como de Microsoft .NET, se refiere a esta solución como "El Vietnam de las Ciencias de la Computación". Para ello, escribió un post muy polémico donde comienza relatando su visión sobre las expectativas que Estados Unidos tenía en el momento de embarcarse en la guerra de Vietnam, y lo que la guerra en sí misma terminó significandole (desafortunadamente, el hombre es el único animal que tropieza dos veces con la misma piedra)

De ese relato hace luego una analogía con lo que los arquitectos de software comienzan creyendo que van a lograr al emplear mapeadores O/R en sus aplicaciones, y lo que viene luego aparejado. Como tocó un tema sensible para sus propios compatriotas (Ted es estadounidense), y para colmo de males hizo esa comparación en un momento igualmente sensible, recibió un sinnumero de críticas que lo obligaron, 24 horas más tarde, a publicar una aclaración en las razones que lo motivaron a usar esa guerra como ejemplo de lo que suele pasar en los proyectos donde se usa esta técnica

También un tal Diego Dagum, Diegum para los íntimos, charlatán de aquellos si los hay, publicó allá por Agosto del año pasado un post en el que se refería al antipatrón, a la mala costumbre, de sobrecargar las arquitecturas con chirimbolos pensados ante eventualidades de dudosa probabilidad de ocurrencia (probabilidad, al menos, discutible). Esa sobrecarga hace luego que al montar la aplicación sobre dicha arquitectura, todo el sistema colapse (o peor, que colapse el arquitecto -me he enterado de algún que otro casillo de arquitectos que terminaron cableados posando para el electrocardiograma -respire hondo... retenga... ... largue el aire-). En este post mencionaba varios ejemplos típicos de ese comportamiento cuestionable de algunos arquitectos, ilustrando uno de ellos con un caso aparecido en los Foros de Arquitectura de Microsoft. En realidad uno de los tantos que han aparecido relacionados con O/R-M en dicho Foro de Arquitectura

En este case, mi contraparte en la discusión terminaba admitiendo que había llegado al pantano en que estaba porque la idea detrás de todo ello sonaba bien. A eso lo llamamos "pisar el palito" o "quedarse a escuchar cantos de sirena", en mis pagos

A continuación te quiero enlistar una serie de recomendaciones de mi propio folklore, después de haber fracasado con el enfoque O/R-M y atenuado un poco la magnitud de los daños. La lista es tan completa como la puedo escribir hoy en base a mis memorias (a la mie...). Creo que te va a servir mucho conocer mis conclusiones al respecto

1. Primer Mandamiento: si todavía no te metiste con O/R-M, no te metas entonces. A cambio tratá de modelar primero procesos, a nivel de negocio, y allá donde necesites entidades de negocio, usa lo que la plataforma en la que estás desarrollando te deja más a mano. Lo crucial acá es no forzar abstracciones innecesarias: conozco casos en que alguien, no voy a dar nombres, me decía "hay que usar colecciones (tales como el "Collection Framework" de Java o las APIs de colecciones de .NET) ya que así no te condicionás a que por detrás pueda haber una base de datos, un conjunto de servicios web o archivos XML para el entorno de desarrollo"
   Suena políticamente correcto, no? Bueno. Si sos de los que piensan así te sugiero releas el post de "Demasiada Arquitectura". Normalmente cuando el proyecto comienza, hay varios datos que ya existen -a no ser que me cuentes que la compañía recién se está abriendo-, en tanto que otros datos sí van a comenzar a persistirse una vez que la aplicación esté en producción. En cualquiera de estos casos, la decisión de sí bases de datos, servicios web, integrador Tuxedo, etc, se toma de antemano y esa decisión incluso no la toma el arquitecto de la aplicación. Esa decisión normalmente será parte de una estrategia corporativa y la puede llegar a tomar el arquitecto empresarial (o Gerente de Arquitectura, es decir, un arquitecto que no está en ninguna aplicación específica de la organización sino en el portfolio completo de estas), como el Jefe de Tecnología, el director de Sistemas, etc
   Ejemplos: si la organización compró un motor de bases de datos relacional (RDBMS), no sólo vas a tener que leer y escribir los datos de la aplicación en una base de datos: lo vas a tener que hacer en esa base de datos. Si la organización firmó un convenio con algún tercero para que le provea ciertos servicios que involucran datos (por ejemplo, una empresa externa que administra la contabilidad de tu organización), es probable que un conjunto de servicios (no necesariamente web) sustituya a la base de datos corporativa. Pero en este caso el enfoque sería híbrido, de modo que ciertos datos se almacenen en una base de datos de tu organización en tanto que otros "viajen" al proveedor del servicio
   La probabilidad de que se decida cambiar en el corto plazo normalmente es baja (sí, lo es, no me des vueltas, pls que tengo que seguir con el post), con lo cual siendo que la organización está esperando ansiosa que termines la aplicación, agarrate del hecho que la decisión de dónde van a ir los datos ya fue tomada, y encolumnate detrás de esa decisión y sacale el jugo a full a esa decisión
   Tratar de construir abstracciones por si algún día decidieran cambiar no sólo te van a comer un tiempo precioso de desarrollo y time-to-market: en ejecución te van a comer un tiempo precioso... de ejecución justamente, cuando malgastes ciclos de CPU convirtiendo a listas u otras representaciones agnósticas de la implementación los datos que te llegan del mecanismo de persistencia (o los que envías al mismo). Considerá acá que el tiempo que perdés en desarrollo es tiempo acotado al período de desarrollo del proyecto, a lo sumo demora el lanzamiento, pero es tiempo que se pierde una vez. En cambio el tiempo que se disipa en ejecución es tiempo que vas a perder durante todo el período que ese código malogrado esté en producción
   Yo sé que lo que planteo a más de un romántico anti vendor lock-in no le va a caer simpático y probablemente crea que lo que pretendo en el fondo es hacer lobby por el software comercial, para que te metas con patas y todo en una plataforma específica y luego sea tanto lo que lleves hecho en la misma que nunca más se justifique cambiarla (o de lo contrario, todo el tiempo invertido se perdería)
   Pero eso no es verdad. Mi motivación es otra: si la decisión de ir por un IBM DB/2, por un Oracle o por lo que sea está ya tomada, en mérito al rendimiento y a la escalabilidad, sacale el máximo provecho que la infraestructura ponga a tu disposición -dado que seguramente eso es lo que la Dirección esperaba cuando pagó la licencia de dicha infraestructura-. Irse por el mínimo común múltiplo de todas las posibles bases de datos es desaprovechar justamente lo que tu base de datos ofrece y que hace la diferencia. Como comprarse una 4x4 y no querer meterte nunca en caminos de tierra, poceados y embarrados, por la eventualidad de que mañana te toque bajarte a un Corsa
   Estoy esperando a que me preguntes "y si finalmente unos años después se decide cambiar, qué?". Si se decide cambiar, se presupuesta el costo de reescribir la lógica de persistencia (acá no des por asumido que vas a tener que escribir toda esa lógica de vuelta, sólo las equivalencias), y pasa a ser costo de la migración. Está claro que cuando desarrollamos software quisieramos que dure tanto como sea posible. Pero todo el software tiene una vida útil y a la larga hay que alinearlo a las nuevas plataformas tecnológicas. Pensar que es tirar una inversión ya hecha es falaz: cuánto creés que te saldría hoy mantener sistemas de décadas atrás en COBOL o incluso en Assembler? Es como los autos muy viejos: empieza a salir caro mantenerlos porque los repuestos ya no se consiguen. Claro, el secreto está en que no tengas que tirarlo tan rápido, pero la expiración de la vida útil le llega a todos
   Existe un caso que no estoy mencionando, que es el de los desarrolladores que no tienen una BD disponible y quieren usar a cambio archivos XML para simular datos que se crean y se graban. Si tal es el caso, te propongo a cambio que metas tus datos mock en una planilla Excel, una pestaña por tabla, y al string de conexión lo hagas apuntar a una fuente de datos ODBC (detalles acá mismo). La aplicación siempre lo va a ver como una conexión JDBC o ADO.NET de acuerdo a la plataforma en la que estés corriendo. Es decir, elegí alternativas que te ahorren escribir demasiado código si lo que pretendías era ahorrar costos
2. Sea que te hayas embarcado en O/R-M o no, privilegiá el modelado de tus objetos de negocio en forma local al módulo o caso de uso por sobre global el global a la aplicación. Lo que me sirve a mí es dividir las aguas de la siguiente manera: los datos los modelo según como los quiero guardar (o quizás ni tengo que molestarme en pensar cómo los voy a guardar si los datos son legacy de aplicaciones existentes con lo cual sólo debo pedir por ellos). En la lógica de aplicación, más bien me focalizo en modelar el proceso (cuya unidad visible a nivel de negocio es el caso de uso, aunque éste a su vez se puede descomponer en subcasos de funcionalidad ad hoc)
   Sería muy dificil que un caso de uso no deba acceder a datos mas, cuando deba hacerlo, mi propuesta es que el caso de uso tenga asociadas entidades de negocio que le vengan a la medida, que esté garantizado que esas entidades contengan los datos que le son necesarios sin que ello implique que deban contener todos los restantes datos asociados a la entidad
   Caso práctico: si el caso de uso de aprobación de crédito necesita conocer que la edad de quien pide el crédito sea mayor o igual que 21 años, la fecha de nacimiento la necesitás sí o sí. En cambio, la dirección del cliente, al menos para esta funcionalidad, que esté o no es accesorio (seguramente sí va a hacer falta cuando el crédito sea aprobado y se proceda a ingresar entonces el préstamo asociado
   Normalmente no es malo que casos de uso de un mismo módulo tengan un modelo de entidades compartido y quizás también reusen varios mecanismos de persistencia (Objetos de Acceso a Datos -llamados DAO por su sigla en inglés-, procedimientos almacenados, etc). Es lo deseable, y se justifica cuando obtener esa información es sencilla (digamos, uno o dos round-trips a la base de datos por entidad de negocio). Deja de serlo cuando tenemos que realizar varios accesos por una misma entidad, para traer datos que en realidad en el caso de uso no van a ser utilizados
   Caso práctico otra vez: necesito recuperar las cuotas impagas de un cliente para calcular sus días de mora, aplicar multas y mostrarle así al cliente la deuda actualizada. Es realmente necesario traer además el detalle de los bienes y servicios incluídos en cada una de las cuotas? Estoy hablando puntualmente de este caso de uso, eh? Si en uno o pocos round-trips a la base de datos me traigo todo, quizás no es tan malo (ojo, acá juega también cuántas cuotas son: si -supongamos que el caso pudiera darse-, el cliente debe 40 cuotas, así en un round-trip me trajese la cabecera y en otro el detalle... es deseable evitar este último si realmente no se va a hacer nada con el detalle
   Atención a esto que te estoy contando acá, porque los O/R-M suelen decepcionar a quienes optaron por ellos en esta parte: o hidratan (así se llama a la acción de recuperar uno o más registros en un objeto) demasiados objetos innecesarios -con los consecuentes posibles problemas de escalabilidad en lo que esto puede derivar-, o por evitar sobrehidratación terminan viajando reiteradamente a la base de datos para buscar información relacionada con una misma entidad de negocio (por ejemplo la Cabecera de un movimiento, después sus items, despues los productos asociados con estos items, y así sucesivamente), derivando esto en problemas de rendimiento
   Mi consejo, estés o no con O/R-M, es que no te mates en pensar objetos reusables a lo largo de toda la aplicación sino quizás acotados a los módulos en que son protagonistas (aquellos donde se crean, se modifican, se listan, etc; no donde se consultan por propiedades específicas que contengan). En los puntos que siguen te voy a sugerir ciertas reglas del pulgar para lidiar con el peligro de la sobrehidratación
3. Usá carga perezoza (lazy loading) en asociaciones de agregación y carga proactiva (eager loading) en asociaciones de composición. Vamos por el principio: en los diagramas de clases de UML se conciben dos tipos de asociaciones entre objetos. Las asociaciones de composición, que establecen que si un objeto de la clase A se compone de objetos de la clase B, el ciclo de vida del objeto A determina la vida de los objetos asociados de clase B. En otras palabras, cuando el objeto A muere, sus objetos B lo acompañan a ese "Más Allá" hasta que el Garbage Collector barra sus cenizas. Y del mismo modo, el objeto A nace antes que sus objetos B. Un típico caso es cuando A representa Factura y B DetalleFactura. A este tipo de asociación se la grafica con un diamante negro, como se ve en la figura 1 a la izquierda
   
   
   Figura 1 - Asociaciones en UML:
   Composición (diamante negro)
   y Agregación (diamante blanco)
   
   En cambio en la misma figura, pero a la derecha, podemos ver una asociación con el diamante de color blanco. Estas son las llamadas asociaciones de agregación. En estas asociaciones, el ciclo de vida de A no condiciona a los de sus B asociados. Un típico caso es A representando un Curso (una materia de la facu, un seminario, etc) y B representado por los Alumnos inscriptos al mismo. Si por alguna razón el Curso se cancela, la asociación con los Alumnos se pierde pero estos no desaparecen
   Entonces, la regla del pulgar que te estoy contando acá no es infalible pero, ante la duda, aplicarla te va a sacar de un apuro hasta que la termines de afinar. Los mapeadores O/R te permiten, al definir cómo se mapean objetos en tablas, sus propiedades en columnas y sus asociaciones en tablas relacionadas, si vas a querer cargar las asociaciones al recuperar objetos de la clase A en la figura 1 o no. Si vas a querer recuperar los B asociados, al toque que recuperás un objeto A, se dice que es carga proactiva o eager loading. Si, en cambio, te vas a aguantar de cargar los B hasta el momento de necesitarlos realmente, se dice que es carga perezoza o lazy loading
   Como te decía en el punto anterior, acá está el dolor de cabeza de O/R-M: si elegís carga proactiva siempre, podés terminar hidratando objetos innecesariamente porque no los vas a necesitar. Esto, como te decía, podría conducir a problemas de escalabilidad: qué pasaría sí por pedir un Cliente para saber su edad, terminás cargando todas sus Cuentas, que a su vez cargan todos los Bienes y Servicios que llevan contratados, y estos últimos hacen que se recuperen todos los Productos que llevan asociados, Mecanismos de Facturación, etc? Cuánta memoria consumirías nada más en ese requerimiento? Cuánto tiempo aguantaría el servidor si la carga de usuarios que está ejecutando ese caso de uso es elevada?
   Lógico, tal vez con esto que te digo te agarra cuiqui y no vas a querer ni plantearte la carga proactiva. Entonces juguémonosla por la carga perezoza siempre. En el ejemplo de la edad del Cliente va a andar bien. Pero ahora te paso al caso de uso de la baja del Cliente. Dar de baja al Cliente implica dar de baja a cada una de sus cuentas, para que no sigan facturando servicios o bienes, o eventualmente devengando intereses. Si dar de baja cada Cuenta a su vez implicase cambiar algún estado en objetos de los que la Cuenta se compone, cuántos round-trips a la base de datos tendrías? Al menos sin O/R-M acá podemos hacer un mega JOIN de SQL (INNER JOIN, OUTER JOIN, el que convenga) y en un solo pique a la base de datos nos podemos traer un resultado tabular que quizás en estructura sea más fulero que Betty la Fea, pero al menos le va a sacar provecho a la polenta de la base de datos, en lo que la base de datos ya tiene afinado para rendir y escalar. En quizás uno o dos roundtrips tenemos toda la data que el caso de uso necesita (uno o dos es un decir: siempre va a depender del caso de uso pero la cosa es evitar, cuando se pueda, acceder a nivel de tabla si las relaciones también son necesarias). De lo contrario, desde el punto de vista del usuario, el rendimiento de la aplicación para ese caso de uso se va a ver pobre
   La pregunta entonces es, cuándo conviene carga proactiva y cuando perezoza, de modo de no caer ni en problemas de escalabilidad ni en problemas de rendimiento?
   Entonces acá entra en juego lo que te aconsejaba en este punto: al configurar los mapeos de asociaciones de objetos en relaciones de tablas, siempre que dudes pedí carga proactiva para asociaciones de composición, carga perezoza para agregaciones. El problema de la mayoría de los mapeadores O/R es que el mapeo, se define a nivel de clase y queda fijo para todos los casos de uso. Un embole realmente porque el nivel de datos requerido para una misma clase varía una enormidad a lo largo de todos los casos de uso. Por ejemplo, si pido un Cliente, me viene ya con las Cuentas de las que el Cliente se Compone ahora, y si quiero listar todos los clientes que contrataron un determinado servicio en un dado período... para qué quiero traer sus Cuentas? Lo único que necesito listar es cierta información de cada Cliente. Pero nada asociado a sus Cuentas! Para peor, si cada Cliente en promedio tiene 3 Cuentas, y tengo que listar 500 (quinientos) clientes... hidraté de yapa 1500 (mil quinientos) objetos al cuete como oreja de sordo!! La realidad es que la reglita del pulgar de este punto es aplicable cuando lo que necesitamos traer es un número reducido de entidades de negocio: un Cliente con sus Cuentas... dos Clientes con las Cuentas de ambos si el caso de uso es de una transferencia o cosas así, pero no cuando la cantidad de Clientes no se conoce de antemano, o bien al menos se conoce de que van a ser varios. Para esos casos (tipicamente reportes) descartá esta regla por la regla que sigue
4. En escenarios de recupero de grandes volúmenes de información (como reportes, por ejemplo), hacé uso de los lenguajes de consultas que los O/R-M traen. Por ejemplo, NHibernate viene con su Hibernate Query Language (HQL), que con una sintaxis algo similar a SQL, te permite consultar cosas de objetos en lugar de tablas. Eventualmente, y pensalo bien, estos mapeadores te permiten introducir comandos SQL nativos de la base de datos real a la que estés accediendo. Cuando te convenga, no seas gil: usalos. No te dejes ganar por la testarudez de que entonces tu aplicación va a perder portabilidad
   Es que en realidad, con los reportes, pasa algo que yo ya comentaba en el post de Desajuste por Impedancia: los reportes tienen una estructura que es de por sí tabular, cuadrada. Las tablas, como su nombre sugiere, son tabulares, cuadradas. El arquitecto que no entiende que no tiene mucho sentido hidratar tablas de la BD en grafos de objetos multidimensionales para, a su vez, transformar a estos en un reporte tabular, cuadrado... yo no digo que sea tabular él (el arquitecto) pero sí que es moooooooooooy cuadrado
5. Y finalmente, para cerrar, vuelvo al comienzo: si podés evitar caer en los O/R-M, hacelo. Por ejemplo, te voy a contar lo que hacemos nosotros hoy. Tenemos un conjunto de casos de uso que están relacionados con un determinado tipo de objeto que a su vez tiene todo un grafo de otros objetos asociados. Normalmente en estos casos de uso en que te comento que tenemos que acceder a nuestro objeto y su grafo, aunque vos no me creas, recuperamos todo en un solo acceso a la BD y persistimos todo (leélo: todo) en un solo acceso a la BD, de nuevo. Cómo hacemos? Sencillo:
   Tanto Java como .NET tienen mecanismos de serialización, que son extensibles. La serialización por defecto en Java es binaria, aunque se puede extender para que sea XML (y si no lo querés extender vos, existe un proyecto open source llamado XStream, entre tantos otros). La serialización en .NET, en cambio, es por defecto XML excepto que le indiques al serializador que utilice el protocolo binario (claro, .NET surgió después que Java: el que ríe último ríe mejor, je-je)
   La clave de nuestro secreto está en la serialización XML puesto que las bases de datos ya hoy van comenzando a admitir XML como formato de intercambio
   Lo cierto es que en nuestro proyecto se usa una base de datos que es fija. Quiero decir, la probabilidad de que cambien es escasa (nunca voy a decir que es nula pero tiende a 0 en los próximos años). Como la base es fija y es corporativa (o sea, otro ya se tomó la molestia de eligir por nosotros), decidimos sacarle el máximo provecho. Para ello nos valemos de la facultad que esta base de datos tiene, que es capaz de generar XML como resultado de un SELECT (incluso un XML con nodos anidados si el SELECT tiene sub SELECTs anidados) y también de recibir como argumento un flujo XML y parsearlo, descomponerlo
   Cuestión que definimos un par de procedimientos almacenados (stored procedures): uno para el alta y/o modificación del grafo de objetos, otro para el recupero del mismo -oigo por ahí algún arquitecto murmurar que no se debe hacer uso de procedimientos almacenados porque no son portables... prefiriendo en cambio mandar, desde la capa de acceso a datos, una serie de comandos SQL, no? Te propongo releer Repudio de la Infraestructura si sos de los que piensan eso-
   Como te contaba, entonces, el primer procedimiento almacenado recibe el chorizo XML que .NET produjo al serializar nuestro grafo, lo parsea con el soporte XPath que la base de datos trae, cortándolo en rebanadas. Así, INSERTa, o actualiza (UPDATE) las tablas necesarias. Normalmente el alta o modificación de esta entidad de negocio suele ser en promedio un total de unos cinco (5) INSERT/UPDATE registros en unas cuatro (4) tablas distintas. Un O/R-M que no tiene soporte para procedimientos almacenados se va a pegar los cinco piques hasta la base de datos. Creéme, te lo aseguro, que eso va a demorar más que el overhead que admitidamente agrega nuestra serialización / deserialización + parseo para un solo roundtrip
   El otro procedimiento almacenado es simétrico: nos valemos de la posibilidad que la base de datos ofrece de generar SQL anidados, formateando la salidad en XML para generar una imagen serializada de mi grafo de objetos. Eso es justamente lo que la aplicación recibe y se lo pasa sin demoras al deserializador de .NET que a cambio hidrata el grafo con el que teníamos que trabajar
   Lo interesante del caso es que estos procedimientos almacenados se usan sólo en aquellos casos de uso donde recuperar / guardar ese particular grafo de objetos es necesario. Y en ningún lado más: en efecto, esas mismas tablas, con esas mismas columnas, eventualmente nutren otros grafos de objetos similares pero no equivalentes, para otros casos de uso donde no quisimos forzar situaciones por tener una única representación de objetos para toda la aplicación
   Finalmente, para reportes, el DataReader de ADO.NET es una masa (es similar al ResultSet de JDBC). Ma qué objetos ni que rabanitos. Mandamos la query que necesitamos, que nos devuelve un DataReader. Y de ahí generamos sin más demoras el reporte que necesite (y a liberar la conexión que el prójimo no puede esperar, ché)

Un abrazo y ojalá que esto sirva

 Allá  por Octubre del 2005 comentaba que el Programa "Desarrollador 5 Estrellas" se había recreado para la versión 2.0 de .NET, en aquel entonces próxima a lanzarse. Había nada más que dos estrellas disponibles, pero la propuesta era que el que obtuviera esas dos estrellas antes del 7 de Noviembre de aquel año, fecha del anunciado lanzamiento mundial de Visual Studio 2005, SQL Server 2005 y el lanzamiento honorario de Biztalk Server 2006 (para no tener que hacer la fiesta de nuevo cuando efectivamente se lanzara: Mayo del 2006) se ganaba un Visual Studio 2005 Standard Edition
 
Para aprobar los estrellas había que descargarse y ver unos videos de un MVP brasilero, Renato Haddad, que hablaba español con evidente dificultad (aunque lo que decía se veía interesante, más bien parecía que estaba leyendo algo escrito por otro). Para colmo, los exámenes después preguntaban cualquier cosa, nada que ver con lo que el MVP había explicado. Pero al menos las pregus no eran difíciles y, siendo que finalmente se aprobaba y uno en realidad lo que quería era el Visual Studio, a caballo regalado nadie le veía los dientes (bueno, sí: hubo uno que sí se quejó pero hoy trabaja en Microsoft y aunque se sigue quejando ahora es por otras cosas)
 
Lo cierto es que el programa fue sometido a revisión en la medida que se siguieron incorporando estrellas (actualmente la única estrella que no está disponible es la quinta, aunque se proyecta lanzarla este mismo año). Paralelo a la evolución del programa, las dos primeras estrellas fueron rehechas
 
He estado revisando los cambios y debo decir que han quedado de veras bien. Ahora hay una tabla de contenidos coherente y estos son reveladores incluso para aquel que creía que no necesitaba aprender más nada de .NET. Además, claro, ahora los contenidos se asocian a las preguntas (yo aproveché y volví a dar el examen de la primera estrella porque la tenía aprobada en C#, así que ahora me tiré a Visual Basic .NET para ver qué onda)
 
Una masa!! Me gustó rever todo esto porque, no exagero, los contenidos son súper profundos pero sin perder simplicidad. Todo muy entendible. Cómo se organiza la memoria, cómo funciona el sistema común de tipos, características de los dominios de aplicación (application domains), configuración de aplicaciones, acceso a datos independiente del proveedor en ADO.NET 2.0, y muchos muchos otros tópicos
 
Vale la pena descargarse los contenidos, reservarse un tiempillo y estudiarlos. El programa completo va alineado con el roadmap de .NET (por ejemplo, la cuarta estrella se basa en la evolución a .NET 3.0, lo que es decir, Windows Communication Foundation, Windows Workflow Foundation, Windows CardSpace y Windows Presentation Foundation)

 Es  increiblemente curioso cómo surgió este post: días atrás había lanzado el primer número del Boletín Extraoficial de Arquitectura, razón por la que recibí no sólo varias muestras de apoyo al proyecto sino también... pedidos de suscripción!!
 
Suscripción!? No será mucho, ché!? Cómo hago para mandarlo estilo newsletter? Le pido a cada uno la cuenta de correo y después me trato de "acordar de no olvidarme"?
 
Sensación extraña ya que por un lado no quería defraudar a los que manifestaron interés pero, por el otro, no me quería comprar un compromiso que después quizás no llegue a poder afrontar
 
Entonces les propuse a algunos que directamente suscriban el RSS feed -ahora te voy a contar qué es eso, este post trata de eso- que está en mi blog, de modo tal que en cuanto haya un boletín nuevo, ellos lo reciban
 
Para sorpresa mía, la mayoría no sabía lo que es RSS, y de los pocos que sí sabían, cada uno usa clientes distintos para acceder a las entradas del RSS feed
 
Razón por la cual decidí "esto es tema de post" y me encontraba justamente seleccionando el material a presentar, cuando llegué a la conclusión de que contarlo pasteando pantallazos era como... intrascendente. En cambio, poder hacer las demos en una forma más real, secuencial, encadenada, iba a tener un efecto no sólo más relevante sino también innovador
 
Por esta razón y por primera vez, grabé un screencast pura y exclusivamente para el blog. Para Uds que me léen y que les agradezco por ello. Si la experiencia da como para, y esperemos que dé, va a pasar a ser algo frecuente en este blog
 
A los hechos: RSS comenzó siendo un formato para envío de índices de novedades. La idea era simple: se define un formato XML para comunicar una lista de links disponibles a través de un canal (generalmente un sitio web) y a cada uno se le agrega un título, una descripción, la lista de sus autores, las categorías (hoy se las llama marcas o, en inglés, tags) y la fecha de publicación
 
De esa manera el canal publicaba su XML en dialecto RSS, y los suscriptores (las aplicaciones capaces de acceder a este XML e interpretarlo) se encargarían de presentar al usuario los nuevos ítems incluídos en la lista recibida, aunque también los viejos ítems ya recibidos, incluso si ya no estaban presentes en la lista actual, de modo de ir generando un archivo de las novedades a lo largo del tiempo
 
El formato RSS ha ido evolucionando a lo largo del tiempo, coagulándose hoy sus diferentes e incompatibles versiones en lo que parece ser la definitiva versión 2.0, cuya especificación está disponible aquí
 
El significado de la sigla RSS también fue cambiando según las distintas versiones. No viene al caso explicar todas las denominaciones sino que me voy a detener en dos de las más llamativas: Rich Site Summary (Sumario Enriquecido de Sitios) y la más actual Really Simply Syndication (Afiliación Realmente Simple)
 
Pero no solamente el formato RSS y el significado de la sigla han ido evolucionando sino también la forma de accederlo y consumirlo. Inicialmente para recibir las entradas de un canal era menester contar con una aplicación ad hoc. Una aplicación que permitiese suscribir los así llamados "alimentadores" (en inglés, feeds). Estas aplicaciones recibían así el nombre de RSS feed readers o simplemente feed readers, que no es otra cosa que "lectores de alimentación RSS". Esas aplicaciones consumían o comían RSS
 
Si bien hoy continúa siendo no poca la gente que descarga e instala estos feed readers para suscribir sitios y consumir sus resúmenes, me atrevo a vaticinar que van directo a la extinción dada la inmensa cantidad de aplicaciones de propósitos de los más variados que hoy, además, añaden la posibilidad de suscribir sitios y potenciar sus resultados con los contenidos que estos sitios ofrecen
 
En la demo que te voy a mostrar a continuación, vas a ver cómo Internet Explorer 7, Outlook 2007 y además un par de gadgets (miniaplicaciones), una para Windows Vista, otra para espacios web colaborativos spaces.live.com, hacen un uso eficiente de la información recibida en este formato, organizandola de manera eficiente, en beneficio del usuario que va a consumirla
 
La idea de esto no es promover esos productos de Microsoft, sino invitarte a vos mismo a que con creatividad pienses qué provecho podrías sacar en beneficio de tu organización y/o tuyo propio
 
El video tiene una calidad de regular tirando a mala, ya que los servidores de streaming como Youtube o Soapbox habilitan un ancho máximo de 320 pixels. Por tal razón tuve que hacer malabares para regular un tamaño de letra que al reducirse durante la conversión a 320 pixels, igual conserve lo más que pueda
 
Lo digo y me comprometo: no va a ser la última vez que haga un screencast para el blog sino apenas la primera
 
Y ahora sí, Sr Director, si las cámaras me acompañan, adelante móvil 1, volvemos a estudios

• Alegría (2006). Premiado en el Festival Iberoamericano de Cine de Atacama
• La Canción de Ana (2005)
• The Archibishop's Confession (El Cura Confeso, 2005). Premiado en el Festival de Jóvenes Realizadores Latinoamericanos (Mejor Corto de Ficción, Mejor Guión, Mejor Director, Mejor Sonido), en el Festival Crepusculum; y también finalista y seleccionado en una decena de festivales
• Encuentro en el Gran Majestic (con actuación de un entonces ignoto Walter Quiroz)
• El Artista Peripatético (la produjo)

Quique logra el reconocimiento de una manera muy sencilla por su flexibilidad y adaptación a distintos contextos. Quique se crió en un hogar de clase media, estudió en uno de los mejores colegios secundarios, luego realizó dos carreras simultáneas -Ciencias de la Comunicación y la carrera de Dirección de Cine en el INCAA, el Instituto de Cine Argentino-. En 1992, a los 22 años, tuvo un breve pero no intrascendente paso por la radio con su programa de arte "Proyecto Stavron" (la autoreferencia en el nombre puede sonar egocéntrica -Quique me corregiría preguntandome "por qué 'puede'!? acaso no lo logra!?- pero en realidad con ello Quique rendía tributo a su máximo referente musical: Alan Parsons, creador de Alan Parsons Project y con el correr de los años amigo personal de Quique -hay fotos de ambos almorzando en Madero-). Esa versatilidad de adaptarse a cualquier contexto lo encontró a Quique manejando un maxiquiosco y luego una heladería en Montserrat. Por esos años Quique creó, gracias al trato permantente con gente de la zona, una serie de personajes basados en gente de la vida real. Con ello fue desarrollando una actividad literaria sumergida pero persistente, de la mano de maestros como Alberto Laiseca y Ana María Shúa, que culminó con la publicación de un par de cuentos de ficción en el "Homenaje a Julio Cortázar" del año 2004 (a veinte años de su muerte)
 
Entonces empieza la etapa de recolectar frutos de tantos años de preparación y pruebas, al fin y al cabo menores. Para ello le dio el toque final a "El Cura Confeso", inicialmente su trabajo de graduación en la carrera del INCAA, comenzado una década antes. La pausa no fue en vano dado que "El Cura..." es hasta hoy su obra más premiada. Pero aclaro que dije "hasta hoy"
 
En un festival de cine en Mendoza, "El Cura..." fue premiado en tantas categorías que a Quique lo hacían subir al escenario reiteradamente. Entonces los organizadores en un momento le dijeron "pibe, quedate! Para que vas a bajar si en seguida vas a tener que subir de vuelta!"
 
No voy a contar el argumento de esta película: es muy breve y no voy a dejar motivos para verla entonces. Sólo voy a anticipar que está basada en un sueño que Quique tuvo y que me contó al otro día, cuando salimos de correrías nocturnas
 
"La Canción de Ana" es una película bastante particular, no sólo por el reconocimiento que le trajo a Quique sino que gracias a ella conoció a dos actores, Susana Beltrán y Miguel Fontés que marcarían luego, aunque por separado, los siguientes pasos
 
Empiezo por Fontés ya que es el protagonista de la película que sigue, "Alegría". Por aquel entonces Fontés no era más que el ocaso de un enano de circo con actuaciones fugaces de extra en televisión. "Alegría" trata justamente de Miguel Fontés. Mezclando situaciones ficticias con situaciones reales involucrando a Fontés, a su familia y al circo donde trabajaba (vivía). El espectador no se va a dar cuenta sino hasta el final qué partes y personajes eran ciertos y cuáles no. Y eso mismo corrió para los actores: Fontés y miembros de su familia terminaron de ver esta película completa (incluyendo las partes en que ellos no actuaban y tampoco habían visto) hasta después de editada
 
"Alegría" es una mirada trascendente a un antihéroe en quién nadie se hubiera fijado. "Alegría" fue también un reconocimiento a Fontés. Quique me comentó que en una muestra de cine en Olavarría (provincia de Buenos Aires), fueron a promocionar el film Quique y Miguel en persona, repartiendo a la gente unos volantes circenses con la leyenda "Vuelve el Circo - Pasen y Vean". Es en esta época que Quique inauguró su web, "El Mágico Mundo de Enrique Stavron", y que tal vez por esa razón tiene un look and feel y sonido igualmente circense
 
En un programa radial, durante el éxito de "Alegría", Quique anticipó que en breve el barco iba a volver a zarpar pero esta vez el turno sería para Susana Beltrán, una actriz argentina que durante la última dictadura militar se exilió en Francia, aunque volvió tiempo después. Similarmente al guión de "Alegría", la historia de "Ma Fille" es y no es la vida de Beltrán. Este film está hablado en francés ya que trata de la hija que la protagonista había tenido en Francia durante su exilio, a quién había abandonado de chiquita para volver. La pelicula refleja el momento en que madre e hija se vuelven a encontrar, 20 años después, cuando la hija (interpretada por la actriz francesa Isabelle Moreau, entrá a verla me lo vas a agradecer) se decide a venir a Buenos Aires y preguntarle a su madre "por qué"
 
Mejor Película "Ma Fille". Mejor Director "Enrique Stavron". Mejor Actriz "Susana Beltrán"
 
Quique no va a pasar desapercibido. No quiere, tampoco. Y siempre se las va a ingeniar para destacarse. Caminando por Avda. Corrientes cierta vez (esa avenida es la "Broadway" de Buenos Aires, con sus teatros a lo largo de varias cuadras por ambas manos), vio a una ex modelo y actriz muy exuberante, Beatriz Salomón; y unos metros más allá al empresario teatral (ya fallecido) Pepe Parada. Sin demorar ni un segundo se le acerca a Parada y fingiendo no haberlo reconocido le señala a la actriz diciendo "aquella no es Beatriz Salomón?". Parada no lo sacó corriendo ni llamó a seguridad. La audacia de Enrique le hizo brotar una carcajada, y palmeandolo le dijo "Jjajajja!! Pero vos para detective no habrías servido!"
 
Una última acerca de Quique y su pasión por el cine. Cuando éramos adolescentes y arreglábamos para ir al cine, mientras que todos queríamos -cosas de la edad- ver si zafábamos para ver alguna prohibida o al menos una de Stallone o de Charles Bronson, Quiquito a fuerza de tosudez nos terminaba convenciento de entrar a ver "Y la nave va" de Fellini, o alguna de Bergman
 
Para qué te voy a seguir contando. Ya te vas enterar como sigue la película de Quique Stavron, que tengo el privilegio de venir viendo desde 1983 

• Conocer los avances que la nueva tecnología aporta al desarrollo de aplicaciones y/o a su proceso (por ejemplo, las master pages de ASP.NET 2.0 aportaban al desarrollo de aplicaciones web, en tanto que Visual Studio 2005 Team System aportaba al proceso de desarrollo, se entiende?), entendiendo asimismo cómo la organización monetizaría este avance ("monetizar": ahorraría plata en cada ciclo de desarrollo? ganaría tiempo? lograría mejores resultados? Esas son las preguntas que responden "qué significa monetizar")
   
• Con la lista en la mano de estos avances, el arquitecto pasa a estar en una posición inicial de hacer un dictamen go/no go de la plataforma. Si dice "no go" al TDM, es directamente no (claro, justificando los por qués). Ahora sí dice "go", es en realidad un "tal vez". Porque todavía queda evaluar la factibilidad de la adopción -aunque se la vaya a adoptar para proyectos acotados-
   
• Evaluar la factibilidad es en otras palabras estimar los costos de adoptar, más allá de los beneficios que se cuantificaron en el paso anterior. Preguntas tales como "las APIs son sencillas de aprender?", "son sencillas de dominar?", "las van a entender nuestros desarrolladores o vamos a tener que salir a buscar nuevos al mercado?", "si hay que salir a buscar... el mercado tendrá ya desarrolladores duchos en esta plataforma?", "convendrá eventualmente encapsular la API dentro de un componente más sencillo de aprender y asimilar por parte de la mayoría de nuestros desarrolladores, de manera de que la terminen aprovechando sin tener que pagar el costo de su aprendizaje?" (atención con ésto último porque de todas formas no sale gratis: la API simplificadora va a haber que desarrollarla y después mantenerla, y los desarrolladores mediopelo van a tener que aprendarla también, aunque sea más simple)
   
• Es en esta etapa que el arquitecto se puede asociar con el o los desarrolladores más senior, en lugar de estar haciéndoles la vida imposible para que no progresen, para responder a esas y a otras preguntas en forma práctica. Entonces la cosa pasa por seleccionar un elenco acotado de casos testigo, un 20% de situaciones que se presentan el 80% de los casos (Paretto suena tan lindo, siempre me hace quedar bien :-D) de manera de realizar Pruebas de Concepto (Proof of Concepts, o PoC's)
   
• El arquitecto idea los tests que considera necesarios realizar para confirmar la viabilidad de adopción de la plataforma, en términos de aquellos beneficios de su lista que realmente atañen a la organización. El o los desarrolladores senior los ponen en práctica
   
• Elementos medibles pueden ser: reducción de las líneas de código, ganancia en un ciclo de desarrollo, rendimiento de la nueva plataforma (mediante una prueba de stress), y otros. Me quiero detener acá un segundo en comentar acerca de la curva de aprendizaje, porque hay al menos dos cosas que se deben considerar de ella:
   
  
  • Hay plataformas que son muy difíciles de aprender, en tanto que una vez que se aprenden, los beneficios pagan el costo inicial. Afortunadamente el duro aprendizaje inicial es un costo de única vez. Después la curva se ameseta, por lo que los plazos para incorporar expertise son más breves (ver figura 1)
    
    

Figura 1 - Se avanza lento al principio, pero una vez
que se llega a cierto nivel, los plazos son más breves
 

• En cambio, puede ocurrir que aún habiendo aprendido lo básico para comenzar, estas plataformas siguen siendo luego difíciles de dominar. Quiero decir, escribir código básico sale como chorizo. Pero luego el tuning para que funciones en términos aceptables de rendimiento, escalabilidad -en términos del usuario- o incluso fácil de cambiar en el futuro -en términos de el propio equipo de desarrollo- puede ser otra la historia. La figura 2 ilustra este caso
  
  

Figura 2 - Valor de la entrada algo más barato que
el caso anterior (igual caro en este ejemplo), pero
una vez alcanzado cierto nivel igual sigue siendo
costoso avanzar
 

• Haciendo un balance, incepción inicial y perfeccionamiento posterior son las dos pendientes que hacen a una curva de aprendizaje, y que deberían estimarse antes de adoptar una tecnología o API

De esta manera, y éste era entonces el objetivo de este post, quiero destacar lo que trae de nuevo .NET 3.0 y ofrecer, tanto al arquitecto como al desarrollador de software, elementos como para que puedan evaluarlos en un período relativamente razonable, y decidir así la conveniencia o no de su adopción
 
En términos generales, .NET 3.0 agrega cuatro APIs nuevas a la versión previa de la plataforma, por lo que hay que ser concientes, si no se venía aplicando .NET 2.0, que adoptar .NET 3.0 implica revisar todo el stack, no sólo las cuatro novedades

Figura 3 - .NET 3.0: cómo se compone la nueva versión

Esto querría decir que habría que entender qué lenguajes de programación ofrece la plataforma, si estos son fáciles de asimilar por los desarrolladores de la organización, si el mercado laboral ofrece recursos humanos, si las APIs básicas de la plataforma (ASP.NET 2.0, ADO.NET 2.0, System.Xml 2.0, etc) son potentes y fáciles de usar, si los servicios de código administrado que la plataforma ofrece (chequeo de tipos, recolección de memoria liberada, etc) no impactan seriamente en el rendimiendo, etc. Y finalmente, Visual Studio 2005. Siendo que es la principal herramienta disponible (no la única pero sí kilómetros de distancia por adelante de las otras en lo que respecta a proyectos en equipos), también se deberían revisar sus capacidades y asistencia al desarrollador y/u otros miembros del equipo antes de seguir hablando
 
En lo que sigue, me voy a focalizar en los avances aportados por .NET 3.0 y cómo y dónde probarlos. Los cuatro componentes nuevos son:
 

• Windows Presentation Foundation (WPF): habilita la creación de interfaces de usuario más potentes en plazos más breves, permitiendo combinar adecuadamente formularios, gráficos vectoriales, documentos e incluso multimedia (el modelo de programación es indistinto). Aunque disponible para Windows XP y Windows Server 2003, esta API se pensó para trabajar directamente con Aero, la nueva interfaz gráfica de Windows Vista, que a su vez aprovecha las capacidades adicionales de video disponibles por hardware. Otra de las características de WPF es que puede hostearse indistintamente en una aplicación de escritorio o en un navegador web, aunque para esto último hay que instalar el framework .NET 3.0 en el puesto cliente -y no considerar que la aplicación es web sólo porque el host es un browser-. WPF presenta varios otros beneficios como por ejemplo un sistema de navegación configurable entre pantallas de ingreso de datos y muestra de resultados
  Para cualquier arquitecto interesado en conocerlo más a fondo, hay una clínica de dos horas -a la fecha de escribir esto no tenía costo- disponible acá: https://www.microsoftelearning.com/eLearning/offerDetail.aspx?offerPriceId=109342
  A su vez, si luego de seguir esa clínica, el arquitecto se encuentra motivado como para tener alguna experiencia personal con el uso de WPF, hay un par de laboratorios virtuales -tanto en C# como en VB.NET- de unos 90 minutos cada uno, disponibles acá: http://msdn.microsoft.com/virtuallabs/netframe/default.aspx. Mi recomendación con los labos, yo estoy haciendo algunos y creo que esto que te voy a decir te puede servir, es que te bajes el manual primero, lo leas bien para entender qué es lo que vas a hacer, y después entres a hacer el labo con la cosa masticada: al principio a mí me preocupaba que se cumplan los 90 minutos y se me cierre la máquina virtual -los labos se hacen con Virtual Server con lo cual en el browser se te abre una sesión remota en un servidor por 90 minutos-. Por esta razón le metía pata a seguir las instrucciones del manual y no estaba dando demasiada bola a lo que iba haciendo (o sea, 90 minutos perdidos, no ganados)
  Para mayores referencias conviene visitar la página de WPF en MSDN: http://msdn2.microsoft.com/en-us/netframework/aa663326.aspx
  También hay algunos webcasts tanto introductorios como más avanzados acá: http://www.microsoft.com/events/series/msdnvista.mspx#WindowsPresentationFoundation
   
• Windows CardSpace: en la figura 3 aparece como InfoCard dado que ese fue el código interno hasta que se anunció oficialmente que también iba a formar parte de .NET 3.0. CardSpace bien pudo haberse llamado Windows Identity Foundation, para continuar la saga de fundaciones. Esta API, me atrevo a decir, va a dar mucho que hablar, porque va a permitir desacoplar definitivamente el mecanismo de identificación de los usuarios de la aplicación misma (sea ésta web o de escritorio). A ver, hasta donde yo conozco siempre venía ocurriendo que lo deseable era manejar las identidades a través de mecanismo robustos basados en servidores de directorio como IBM Tivoli, Active Directory, u otros. Pero la complejidad de las APIs, cuando disponibles, era tal que finalmente se debía apelar al clásico mecanismo de la "tablita" con usuario y contraseña -y quizás otros datos- para manejar las identificaciones. Esto no solamente duplica esfuerzos sino que, hablando seriamente, estos mecanismos no suelen ser codificados por expertos reconocidos en seguridad, sino por alguien idóneo del equipo de desarrollo. Por esta razón, los riesgos de metidas de pata -cuando no fraudes cometidos ex profeso, atención- son posibles y reales
  Pero encima ahora vamos a un mundo digitalmente integrado donde las aplicaciones consumen servicios de terceros, y nos encontramos con que el usuario no puede estar logueandose de cinco maneras distintas en un mismo caso de uso. Por esta razón han surgido estándares de identidad federada a lo largo de diversas aplicaciones. Qué credencial hay que usar en cada momento? Sirve la contraseña de Windows para identificarme en la web de Blockbuster y alquilar una peli? Y el carnet de Boca para hacer un trámite en la web del consulado de Estados Unidos? (que lleguen a decir que no y les mandamos a Di Zeo) Sirve la tarjeta de crédito para demostrar que uno tiene más de 21 años? Como se puede ver, hay diferentes credenciales para mostrar en diferentes contextos, pero todo para un mundo donde los diferentes contextos se van cruzando y amalgamando
  Windows CardSpace nos va a permitir delegar en el sistema operativo el manejo de esas credenciales en una forma agnóstica del tipo de credencial que estemos usando -incluso si finalmente deseamos darle para adelante con nuestra "tablita"-
  Un labo virtual para conocer Windows CardSpace en acción esta disponible acá: http://msdn.microsoft.com/virtuallabs/netframe/default.aspx
  Artículos acá: http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx
  Un webcast interesante acá: http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032303077&EventCategory=4&culture=en-US&CountryCode=US
   
• Windows Communication Foundation (WCF): a veces mal llamada "la nueva generación de web services de Microsoft", WCF es muchísimo más que servicios web. En realidad más adecuado sería hablar de "la nueva generación de comunicaciones" porque todo lo que tenga que ver con comunicación en aplicaciones distribuidas, sea mediante servicios web o no, pasa por WCF. La API nos permite fielmente separar la lógica de lo que nuestros componentes distribuidos ofrecen, de los mecanismos para consumirlos. De esta forma sin necesidad de recompilar nada, podemos hacer que un servicio sincrónico pasa a comportarse en forma asíncrona, o bien para algunos consumidores síncrono y para otros asíncrono; podemos también elegir si queremos manejar una instancia única del componente (que por ende no debería manejar estado por sesión), o bien uno por cada sesión, uno por cada requerimiento, e incluso controlar la cantidad de instancias simultáneas acotándola a cierto tope; también manejar las dinámicas conversacionales (one way, full duplex, etc); mecanismos de transporte de los mensajes hacia el servicio (si HTTP, si colas MSMQ, si TCP pelado, si otros... inclusive no necesariamente atado a un único mecanismo); políticas de encriptación (si a nivel de canal con SSL, si a nivel de mensaje con -por ejemplo- WS-*); políticas de distribución de los mensajes (transaccional, una única vez, respetando el orden de emisión de los mismos, etc); estilos de serialización de los mensajes (serialización binaria, POX -plain old XML-, SOAP, etc, incluso más de una según el consumidor). Y, como te contaba, aunque no todas, casi todas estas diferentes conformaciones de tus componentes distribuidos se manejan a nivel de configuración, no a nivel de código -algunas pocas implican tocar los atributos del componente, aunque no su lógica-
  Estos mecanismos son extensibles de modo que puedas agregar los tuyos propios, a la vez que te permiten generar eventos monitoreables o mensajes de excepción (para que se entienda bien: no dije "arrojan alguna clase derivada de System.Exception", dije que entre los mensajes que te podés esperar de un componente, podés recibir un MessageFault, es decir, un modelo similar al de excepciones que lleva el Common Language Runtime, pero llevado al nivel de los servicios y los mensajes
  Finalmente, así como las interfaces de usuario en WPF se podían hostear tanto en una aplicación de escritorio como en un browser, un servicio WCF se puede hostear donde quieras: en un servidor IIS, en un puesto de trabajo, en una aplicación de escritorio, ..., donde quieras: WCF viene preparado para dejar los servicios up and running donde vos le pidas (el tema es que pidas donde haya que pedir, claro: no que pidas porque pedir es gratis)
  Hay, nuevamente igual que en el caso de WPF, una clínica para conocer en mejor detalle WCF con demos, preguntas multiple choice de evaluación, etc, acá: https://www.microsoftelearning.com/eLearning/offerDetail.aspx?offerPriceId=109346
  Labos de WCF acá: http://msdn.microsoft.com/virtuallabs/netframe/default.aspx
  Artículos acá: http://msdn2.microsoft.com/en-us/netframework/aa663324.aspx
  Y finalmente webcasts acá: http://www.microsoft.com/events/series/msdnvista.mspx#WindowsCommunicationFoundation
   
• Windows Workflow Foundation (WF): los procesos, tanto de negocio como también tecnológicos, siempre han sido modelados de diversas formas. Diagramas de flujo, diagramas de estado, árboles de decisión, y muchos otros. Sin embargo, a la hora de llevar esas ideas a código, amen de alguna que otra herramienta CASE, había que terminar codificando completamente el modelo representado mediante uno o más grafos. WF nos habilita a modelar estos grafos con Visual Studio 2005, generando así una representación XML del mismo donde cada nodo pasa a ser una actividad ejecutada por un proceso (externo o local) y los ejes representan acciones dentro del motor de orquestación
  Esto nos permite pensar nuestras aplicaciones ya desde otro nivel: llevar a la práctica flujos humanos (por ejemplo un esquema de autorizaciones según monto y jerarquía del autorizador, o bien un sistema de administración de contenido, de órdenes de compra, etc); procesos sistémicos (como una transacción que involucre una entidad financiera autorizadora de crédito, un proveedor al que se le está comprando cierta mercadería, un transportista que se va a encargar de llevarla a destino y a la vez sistemas internos de contabilidad que deberan generar los respectivos asientos correspondientes a la transacción); eventualmente máquinas de estado relacionadas con cambios en alguna entidad del modelo de dominio, etc
  La ejecución del workflow para una instancia dada se puede persistir y retomar luego. Por ejemplo, supongamos que el workflow modela la aprobación de una operación por un usuario autorizado, y este usuario no está en línea. Es necesario en ese caso quedarse aguantando el workflow hasta que en algún momento finalmente se conecte? WF se encarga de persistir el estado y recuperarlo más tarde para poder continuar con esa instancia en particular
  Estos workflows también pueden ser encapsulados como unidades transaccionales, habilitando la posibilidad de disparar automaticamente compensaciones en aquellas actividades no preparadas para participar de transacciones, que se habían completado exitosamente
  Los workflows, asimismo, se pueden exponer hacia afuera como servicios web mediante la integración entre WF y WCF. También, al igual que las otras dos fundaciones, los workflows se pueden hostear donde se necesite sin tener que escribir código adicional para habilitar eso
  Una clínica interesante de 2 horas está disponible en https://www.microsoftelearning.com/elearning/offerdetail.aspx?offerpriceid=109340
  Labos acá: http://msdn.microsoft.com/virtuallabs/netframe/default.aspx
  Artículos y otros recursos en esta página: http://msdn2.microsoft.com/en-us/netframework/aa663328.aspx
  Y para terminar, webcasts acá: http://www.microsoft.com/events/series/msdnvista.mspx#WindowsWorkflowFoundation

Como podrás observar, con los recursos que te he dado no necesitás instalar nada en tu equipo para conocer hasta cierto nivel qué es lo que te ofrece .NET 3.0 y cómo se podría monetizar ahí adentro. Un unos posts más adelante te voy a estar contando cómo tenés que hacer para armarte un entorno con Visual Studio 2005 extendido para .NET 3.0 de manera que puedas hacer algunas pruebas de concepto