Dotnetero Reloaded

Where Workflow Foundation really shines

Rocky tiene unas ideas bastante interesantes de cómo encaja Workflow Foundation en la arquitectura de un sistema. Vale la pena echarle el ojo.

De su artículo:

Today we all write these non-interactive processes in code. Maybe with a set of objects working in concert, but more often as a linear or procedural set of code. If a change is needed to the process, we have to alter the code itself, possibly introducing unintended side-effects, because there's little isolation between steps.

Personally I think this is where WF fits in. It is really good at helping you create and manage non-interactive processes.

Yes, you have to think about those non-interactive processes in a different way to use WF. But it is probably worth it, because in the end you'll have divided each process into a set of discrete, autonomous steps. WF itself will invoke each step in order, and you have the pleasure (seriously!) of creating each step as an independent unit of code.

From an OO design perspective it is almost perfect, because each step is a use case, that can be designed and implemented in isolation - which is a rare and exciting thing!

SOA te hará más sexy

Ayer vi este post de Grady Booch en su blog y me pareció chistosísimo (y cierto).

"My take on the whole SOA scene is a bit edgier than most that I've seen. Too much of the press about SOA makes it look like it's the best thing since punched cards. SOA will apparently not only transform your organization and make you more agile and innovative, but your teenagers will start talking to you and you'll become a better lover. Or a better shot if your name happens to be *** [Cheney]. Furthermore, if you follow many of these pitches, it appears that you can do so with hardly any pain: just scrape your existing assets, plant services here, there, and younder, wire them together and suddenly you'll be virtualized, automatized, and servicized.

What rubbish.

SOA is, first and foremost, about the A part of the acronym (architecture). Organizations who already have a solid approach to architecture will likely do reasonably well with SOA; organizations who already have a broken architecture and/or a broken architectural governance practice will likely fail with SOA and then blame SOA on all their problems."

Échenle un ojo al post completo aquí.

¿Confundido con la Orientación a Servicios?

Si alguna vez han intentado definir o explicarle a alguien qué es Orientación a Servicios (SO, Service Orientation), y se dan cuenta que trataron un montón de temas, sin llegar a algo concreto, no se preocupen, no son los únicos. Agarren a 5 expertos, métanlos en un cuarto y pregúntenles qué es y seguramente recibirán 5 respuestas distintas.

¿Por qué es tan difícil de definir?

• Se ha hablado, escrito y hasta podcasteado demasiado sobre el tema—espero que este artículo no sea otro del montón.
  
• Es un tema aún nuevo en la conciencia colectiva de los desarrolladores así que, en realidad, aún no hay una definición universalmente aceptada.
• Hubo demasiado marketing de productos para un concepto que es abstracto. Esto llevó a muchas personas a la conclusión de que SO==SOA==Web Services, al grado que hasta los gurúes de pronto hablan indistintamente de esas 3 “cosas” y no sabe uno dónde quedó la bolita.

¿Qué problemas resuelve?

• SO(A) promete aliviar muchos problemas de re-uso, integración y comunicación para los sistemas disgregados y sistemas distribuidos.
• Permite la <buzzword>interoperabilidad</buzzword>: la capacidad de que sistemas en distintas plataformas, que funcionan con distintas tecnologías interactúen felizmente.

¿Qué NO es SO?
Quizá Rich Turner tenga razón, y la manera más sencilla de aclarar la confusión y de explicar qué es SO, es desmentir algunas ideas sobre lo que NO es SO. En otra entrada les detallaré más sobre las características que debe cumplir “algo” orientado a servicios. Por ahora veamos lo que no es.

SO != tecnología
SO en realidad no tiene nada que ver con tal o cual tecnología (.NET, J2EE, Web Services, etc.).

SO es una metáfora, una manera de representar—abstraer—las cosas, para ayudar a atacar un problema: la interacción en sistemas distribuidos. Es análogo a la Orientación a Objetos (OO), que es una manera de abstraer “cosas” de la vida real para modelarlas y poder formar un sistema.

“Service orientation refers to a mindset that centers on the four SO tenets.” (Selly, Troelsen y Barnaby, p. 303)

“It is philosophy.” (Lhotka)

SO != una arquitectura per se, por lo tanto SO != SOA

“First, services are just a mechanism, a specific mechanism for allowing communication across standard Web protocols. As such, the best service-oriented architectures seem to come from good component-oriented architectures, meaning that the mere imposition of services does not an architecture make. Second, services are a useful but insufficient mechanism for interconnection among systems of systems.” (Booch) [Énfasis mía].

La SO por sí sola no lleva a producir un sistema completo. Aún no hay una metodología establecida, aunque afortunadamente ya se está trabajando en eso.

SO(A) ha sido promovida como la cura de todos los males: broncas en procesos de negocios, arquitectura a nivel enterprise y a nivel soluciones, y hasta arquitectura de aplicaciones. Y es ahí el meollo de la confusión. Vean la figura 1 y figura 2 en el artículo de Zimmermann, Krogdahl, y Gee.

“Service Oriented Architecture [vs. SO] is more specific in that it refers to the activity of developing an architecture or can be used to describe an existing architecture. When the service notion first appeared within the developer world, it was commonly referred to as SOA. The problem with the SOA term, however, is that it implies that service orientation is simply an architectural approach.” (Selly, Troelsen y Barnaby, p. 303)

SO != OO
Esto pudiera parecer obvio, pero algunas personas piensan que SO es un “paradigma-moda-arquitectura” que pretende sustituir a la OO. Esto es incorrecto. Son “cosas” que se complementan, ya que, aunque hay traslape, atacan problemas distintos.

Específicamente, el principio en SO de que “las fronteras son explícitas” es importantísimo, ya que rompe de una manera fundamental con OO, que asume que todo es local y stateful (que retiene su estado). Esto puede parecer trivial, pero fue donde la puerca torció el rabo.

¿Recuerdan COM+/DCOM, o RMI? Estos fueron intentos de aplicar OO a sistemas distribuidos, pero al intentar esto el primer tope fue con el costo de la comunicación de las partes, lo cual llevó a los “objetos” stateless (sin estado). El clásico querer cuadrar un círculo. ¿Ven por qué SO se ve chida?

“OO analysis is a very powerful and proven approach, and as such, SOAD should make use of OO analysis techniques as much as possible. To successfully apply OO analysis to SOA projects, you must examine more than one system at a time. Use case models will continue to play an important role. However, SOAD must be predominantly process, rather than use-case driven.” (Zimmermann, Krogdahl, y Gee.)

SO != Web Services / WSE
Web Services es una implementación de orientación a servicios, un ejemplo concreto. Web Services no es SO.

Las Web Service Extensions son extensiones que Microsoft agregó al .NET Framework para cumplir con las especificaciones WS-I y permitir que su implementación de Web Services interoperara.

SO != RPC / .NET Remoting
Parte del punto anterior es que cuando se comenzaron a popularizar los Web Services, muchas personas—incluyéndome—interpretaron Web Services == XML RPC sobre HTTP, y comenzaron a implementarlos bajo ese modelo.

Eso llevó al embarradero erróneo de que SO tenía que ver con COM+/DCOM/Enterprise Services o hasta con Remoting. Aparte de que en dado caso estas serían implementaciones de SO, no cumplen pero para nada con la interoperabilidad, ya están casadotas con las tecnologías de Microsoft.

SO != Algo nuevo
Rocky Lhotka, y Gary Booch, han sido de los que se han quejado de esto. Cierto, SO definitivamente no es algo nuevo, solo pareció así por la popularidad de los Web Services. Sin embargo,

“One of the many complaints we often hear regarding SO/A is that it offers nothing that sophisticated and successful distributed implementations aren’t already doing. To which we say: ‘That’s the point’. We've all learned many hard lessons over the past few years by watching distributed applications deliver disappointing results or completely fail. The primary goal of SO/A is to take those lessons to heart and document the characteristics of the most successful distributed systems. The hope is that this information will help future developers avoid the same mistakes that crippled many early attempts at building distributed applications.” (Selly, Troelsen y Barnaby, pp. 300-301)

¿Aún confundidos?
No se agüiten, como dijo Edward R. Murrow: “Cualquiera que no esté confundido no entiende realmente la situación”.

ASP.NET para hombres

Disclaimer #1: Aunque vaya a parecer comercial, no tengo nada que ver con los autores del libro o con la editorial. Simplemente me cayó tan bien el libro que tuve que escribir sobre él.

Disclaimer #2: No estoy siendo sexista. Al decir “para hombres” es en el sentido “vs. niños, amateurs, principiantes”, no “vs. mujeres”. Las mujeres son la neta.

Disclaimer #3: Este post está intencionalmente “pocho”. Hay cosas en jerga computacional y citas textuales que francamente me da flojera traducir.

Yo soy extremadamente codo para comprar libros técnicos. La verdad es que si voy a pagar 60 dólares por un pedazo de árbol muerto con letritas, más vale que las letritas sean muy buenas, ya que la herramientas cambian tan rápido que la vida útil de un libro técnico es de solo un par de años, a lo mucho.

Aún recuerdo cuando me llegó mi copia de Professional VB 5 Business Objects (Wrox Press, ¿1997?), por un tal Rockford Lhotka, que abogaba el uso de la arquitectura en capas y el uso de UML. Cuando años más tarde, en el trabajo comencé a hacer cosas dotneteras™ más en serio, sugerí la versión de .NET de su libro—recién sacadita de la imprenta si mal no recuerdo—para el proyecto y la adoptamos como el armazón de nuestra aplicación con bastante éxito. Esa es la clase de libros que te “dan de comer” por varios años y vale la pena comprar.

En esa misma categoría pues, he puesto a Expert ASP.NET 2.0 Advanced Application Design: ASP.NET as a distributed application hosting environment (Apress, 2005). Que si hubiera sido yo el autor, probablemente le habría puesto como título “ASP.NET para hombres”. En mi humilde opinión, este libro debería ser lectura requerida para cualquier desarrollador .NET profesional.

¿Por qué? Porque más que un libro más sobre ASP.NET es un libro sobre arquitectura de software aplicando herramientas que se llevan bien con el .NET. Y no solo es para aplicaciones Web o Web Services, el contenido aplica para casi cualquier tipo de aplicación que se necesite desarrollar con las herramientas que se tienen en este momento, y cómo se relaciona con las que están en puerta (como Windows Communication Foundation).

“And so in designing this book we decided that we did not want to do the standard ‘new feature march.’ This book is not a general introduction to version 2.0 of the ASP.NET Framework. Instead, this book focuses on designing distributed applications using the .NET Framework as your platform. With this as our focus, we treat ASP.NET not as an environment for the generation of HTML, but rather as an application hosting environment, one capable of servicing requests not just for Web Forms, but also for Web Services, for distributed objects via Remoting, even for your own custom application hosting needs. By treating ASP.NET as an application server instead of as a web application development environment, our field of view is dramatically increased.” (p. xix)

Y no es exageración. Después de leerlo sentí que mi arsenal de herramientas se había incrementado dramáticamente.

El libro comienza con algo de “teoría” básica sobre arquitectura donde me topé con algunas citas con las cuales estoy totalmente de acuerdo:

“You'll need to consider more than the business-based, functional requirements. When you're designing the architecture, functional requirements may be relevant, but they're usually secondary to other application requirements, which aren't captured in the ‘Use Cases.’” (p. 3)

[Traducción: la arquitectura de un sistema se saca de todas las “-abilidades” (mantenibilidad, ecalabilidad, etc.), no tanto de los requerimientos]

“The answer to any question when it comes to architecture is ‘it depends’. This is why you make the big bucks.” (p. 4)

[Refiriéndose a la importancia de la mantenibilidad y flexibilidad en los sistemas:]

“Checking a code file out of source control and having a developer make changes to it is the most expensive kind of change that can be made to a system. It requires a developer (not cheap). It requires the recompilation of binaries. It requires regression testing of all areas of the application that are affected by a change to that binary (testers, automation, and time: aka more money). And then it takes a deployment and all of the requisite worry, heartache, and long hours that can accompany that.” (p. 12)

Después de algunas arquitecturas de ejemplo, el libro pasa rápidamente a explicar el ASP.NET Execution Pipeline, en otras palabras, qué pasa desde que un request le llega a IIS hasta que la página es rendereada y todos los puntos de extensibilidad en el proceso.

Al principio me era un poco amenazante, pero gracias a la muy amena redacción que tiene, de-mistificó rápidamente cosas que para mi hasta ahora habían sido “magia” de ASP.NET. Conforme avanzas en la lectura comprendes perfectamente cómo Microsoft implementó muchos de los features de ASP.NET (Forms Authentication, el handler de Web Services, etcétera). Y una vez que se entiende eso, el modelo (en capítulos posteriores) para entender Web Services Extensions (WSE) y hasta WCF es esencialmente el mismo. Whoa.

Podría hacerles un resumen casi por capítulo de cosas que me gustaron en cada uno de ellos, pero para no hacer el cuento muy largo les voy a poner las cosas principales que aprendí o me gustaron de este libro:

• Qué tecnologías están disponibles hoy, qué features proveen y cómo decidir cuándo usar cuál (a veces los features son ofrecidas por varias de las tecnologías) y cómo emplearlas de forma que provean una migración fácil a las tecnologías que están en puerta (como WCF).


• Trae un destilado de las muchas definiciones que se han dado de Web Services y de Service Orientation y qué elementos tienen en común. La importancia de entender la diferencia entre SO y OOAD y cual es el papel de cada una de estas filosofías en un sistema distribuido (hint: tiene mucho que ver con la diferencia entre cosas stateful y stateless).


• La tendencia de Microsoft hacia la programación “declarativa”, como alternativa a la “imperativa”—si alguna vez han utilizado atributos en sus clases o visto código XAML, de esto se trata la programación declarativa.


• Ejemplos claros, completos, prácticos y concisos de cómo hacer (y no hacer) muchas cosas con el .NET Framework 1.x Aquí me topé con muchas situaciones por las que yo ya había pasado y aprendido a guamazos. (p.ej. qué se tiene que hacer para implementar Forms Authentication), y qué cambios hubo en 2.0 para facilitar esas cosas (p.ej. cómo usar el nuevo MembershipProvider, controles nuevos, etc.).


• Capítulos detallados en algunas áreas que no se cubren muy bien en la documentación o en otros libros que he visto o leído:


• Hay un capítulo enterito dedicado la clase Page: qué es lo que sucede a la hora de ejecución, cómo arma los controles, y qué prácticas seguir. Incluye una muy buena explicación en la página 95 de porqué NO es tan buena idea DataBindear un DataSet a un DataGrid—esencialmente acabas gastando 4X el tamaño original de los datos—y qué alternativas hay.


• Otro capítulo dedicado exclusivamente a ViewState y JavaScript, incluyendo cosas AJAX-escas (Out-Of-Band Callbacks)


• Una muy buena cobertura sobre Enterprise Services (COM+) en .NET. Aquí aprendí varias cosas que ni sabía que existían, incluyendo Queued Components—componentes que se ponen en una cola de ejecución y automáticamente tienen un proceso “escucha” y los procesa asíncronamente; cómo poder generar Web Services a partir de componentes configurados automáticamente y sin siquiera requerir de .NET

En fin, el libro cubre los temas con un detalle suficiente como para meterse en broncas, y entender el concepto de una manera concreta, pero te deja “picado” para buscar más detalles cuando se ofrezca en la vida real.

Les recomiendo que le den una hojeada al libro o lo compren en su tienda favorita, o si tienen acceso a algo como books24x7.com, ahí también lo tienen.