Orientación a Servicios: Dónde Quedaron los Objetos

 Días  atrás estaba hablando sobre integración de aplicaciones. Hoy es muy difícil hablar de integración ignorando el concepto de Orientación a Servicios (Service Orientacion o SO) y especialmente el estilo arquitectónico conocido como SOA

Uno de los que me escuchaba cumple hoy un rol jerárquico, está alejado de la tecnología y sus últimos acercamientos estuvieron en el mainframe. Por ende se había salteado también la experiencia de programación dentro de un lenguaje del paradigma de programación orientada a objetos (object-oriented programming u OOP). A este paradigma sólo lo conoció por artículos, lo que lo llevó a preguntarme

-Cuando se habla de "orientación a servicios" y "orientación a objetos", ambos conceptos son intercambiables?

Existen dos mitos (bueno, seguramente varios más) respecto de la orientación a servicios

  • Mito 1: Orientación a Servicios y Orientación a Objetos son la misma cosa
  • Mito 2: Orientación a Servicios viene a suceder a la Orientación a Objetos

Vamos a refutar a cada uno por separado

Mito 1: SO.equals(OO)
Quienes acuñan esta creencia, en más de un caso, ven mala fé de los grandes vendors en el sentido de "cada tantos años salir a la calle con un verso nuevo para captar atención, pero es todo lo mismo de siempre". Voy a ser enfático: la Orientación a Servicios poco tiene que ver con la Orientación a Objetos

El paradigma Orientado a Objetos es un paradigma de programación que enfatiza el concepto de encapsulamiento de funcionalidades cohesivas en clases. Esto permite al resto de la aplicación abstraerse de la complejidad encapsulada, mejorando la mantenibilidad del sistema global. Por otra parte, es posible maximizar el reuso de toda o parte de la lógica mediante un esquema jerárquico donde las clases (o tipos) heredan propiedades y métodos de otros, pudiendo estos últimos ser reimplementados en las clases descendientes. Ese esquema jerárquico es el que permite que la aplicación tenga un comportamiento polimórfico, según cual sea el miembro de la jerarquía al que se le invoca un método dado. Suficiente lo dicho sobre OOP, no? Creo que aún aprobaría el examen teórico. Pasemos a revisar el otro paradigma

La Orientación a Servicios es un paradigma arquitectónico que planea a un sistema con la premisa de integrar funcionalidades autónomas, en contraposición a la tendencia de diseñar primero sistemas aislados y pretender integrarlos a posteriori. A estas funcionalidades autónomas es que se las llama Servicios, y se pretenden que duren a largo plazo, a la par que se espera de los mismos alta disponibilidad y estabilidad. De este modo los sistemas se ensamblan adaptivamente de estos servicios distribuidos. En ese sentido, los sistemas sí están pensados para cambiar

Hay cuatro premisas que Microsoft distingue como fundamentales en la Orientación a Servicios

  • Las fronteras son explícitas. El punto de interacción del consumidor y el proveedor está perfectamente demarcado, aceptado, de modo que ambas partes se comuniquen vía intercambio de mensajes. Del punto de vista del desarrollo, este intercambio simplifica la integración. No obstante se debe considerar que en ejecución cada cruce de frontera paga peaje
  • Los servicios son autónomos. Esto implica compromisos mutuos: el consumidor no debe asumir cómo el proveedor implementa el servicio (plataforma, lenguaje de programación, diseño interno, etc); el proveedor no debe suponer que el consumidor siempre actúe adecuadamente (que pase los parámetros dentro de los rangos de valores, que recupere estados inconsistentes, etc). Este principio de autonomía tiene como objetivo que el proveedor pueda versionar su servicio, desplegarlo, etc, en forma absolutamente transparente y sin impacto para los consumidores
  • El intercambio de mensajes se basa en contratos. Ambas partes intercambian mensajes de estructuras dadas. Estas estructuras se definen con esquemas neutrales. El contrato de un servicio aglutina todos los posibles esquemas de mensaje, tanto de entrada como de salida, que el servicio tiene considerados. En la medida en que los contratos se conserven se apuntala el principio de autonomía. Una recomendación surgida de la experiencia es que los mensajes se compongan de la mínima información posible, de datos básicos. Preferentemente datos primitivos que clases serializadas, ya que estas últimas aumentan el acoplamiento entre ambas partes: a la primera modificación en alguna de las márgenes habría que rehacer el contrato, se entiende? Aún cuando sea inevitable modificar el contrato, es recomendable versionar el servicio
  • La compatibilidad semántica se declara con políticas. La premisa anterior hace referencia a la compatibilidad estructural: el qué de la integración. También hay que contemplar el cómo o el quién de los requerimientos operacionales. Me refiero a acuerdos de nivel de servicio, encriptación de partes del mensaje, canales de transporte habilitados, obligatoriedad de autentificación, integridad transaccional, y varios etc. Este principio establece que tales requerimientos no deben estar embebidos en la lógica ni del proveedor ni del consumidor del servicio, sino que se deben fijar como políticas de compatibilidad implementadas en la infraestructura de integración. WS-Policy es una especificación de WS-I que pone en práctica este concepto mediante un esquema basado en aserciones

Mito 2: SO reemplazará a OO
Falso: la segunda premisa de la orientación a servicios establece un principio de autonomía. Dentro de las fronteras de un servicio, a los ojos de un consumidor del mismo, es indiferente si se ha optado por COBOL CICS, COBOL VMS, por SmallTalk, J2EE o TI-BASIC. La refutación del mito anterior procuraba dejar en claro que SO no es lo mismo que OO. Ahora reafirmemos que ni siquiera son cosas comparables. Perfectamente se puede tener un sistema empresarial cuya arquitectura esté orientada a servicios, en tanto que algunos o todos estos servicios estén implementados autónomamente dentro de un lenguaje o plataforma orientado a objetos
Para responderle al título de este artículo, entonces, los objetos quedan dentro de las fronteras de los servicios. La Orientación a Servicios, en ese sentido, no es más que una evolución de técnicas de integración ya que hasta el momento se venía usando el mismo paradigma Orientado a Objetos:

  • El Object Management Group (OMG) en su momento creó CORBA, un modelo de integración basado en objetos distribuidos
  • Microsoft tenía DCOM
  • J2EE especificaba EJB basado en comunicación RMI

Es materia opinable concluir que estos tres esquemas resultaron exitosos o no (si es por adopción, fueron exitosos, si es por eficacia en la resolución del problema, estimo que habrá opiniones a favor y en contra). Lo innegable es el alto grado de acoplamiento del enfoque resultante de compartir clases. La premisa de la orientación a servicios busca no repetir ese error al establecer que se comparten contratos y no clases. Esto explica el masivo vuelco de la industria a la tecnología de Servicios Web, actualmente el estándar orientado a servicios de mayor aceptación

Conclusión
En base a lo comentado, espero haber aclarado que la Orientación a Servicios está en una dimensión distinta a la Orientación a Objetos, son técnicas para resolver problemas de dominios diferentes. Si bien es de esperar que más y más las aplicaciones viejas sean reemplazadas por versiones orientadas a objetos más mantenibles, la orientación a servicios viene a garantizar que, mientras la migración no se produzca, la vieja infraestructura garantice el retorno de inversión (return of investment o ROI) tanto como sea posible

Para terminar, es importante destacar que Windows Communication Foundation (WCF) es una API que permite exponer funcionalidades de objetos .NET en la forma de servicios que cumplan con las cuatro premisas descriptas más arriba

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