Diario de un Dotnetero

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 Dick [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í.

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”.