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íaSO 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 != OOEsto 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 RemotingParte 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”.