SOA y Orientación a Objetos: el poder de la abstracción.

por

La Orientación a Objetos (OO) supuso una aportación muy importante a la historia del desarrollo de software. Introdujo un profundo cambio de enfoque respecto a la forma tradicional de diseñar el software, incluso de analizar la realidad para modelarla en diseños software. La capacidad de abstracción, que siempre había sido una característica deseable para que el software fuera limpio, legible, ordenado y por tanto mantenible, dio un paso al frente para convertirse en una habilidad imprescindible para un diseño de clases correcto. La Orientación a Servicios (SOA) hereda ese protagonismo de la abstracción como herramienta clave para una correcta ejecución de la estrategia, pero no es lo único que tienen en común SOA y OO. Vamos a darle una vuelta.

La Orientacion a Servicios y la Orientacion a Objetos tienen muchas semejanzas y representan dos niveles de abstraccion importantisimos

Una primera similitud entre SOA y OO la tenemos en el concepto de instancia. Como sabéis, una vez que has definido una clase, la instancias para crear objetos. Cada objeto, que es una instancia de esa clase, es diferente del resto de objetos que instancian esa misma clase, porque cada uno tiene sus propios valores de atributos y por tanto presentan características que los diferencian aunque se comportan de la misma manera. Exactamente igual que dos personas distintas, aunque similares en su “modelado” y comportamiento, presentan características (atributos o propiedades) que los hacen diferentes. Aunque responden a un mismo patrón, son objetos diferentes.

Con los servicios ocurre algo parecido. La definición de un servicio de negocio en SOA es único. Pero luego ese servicio de negocio se despliega en distintos contextos, en los cuales varían generalmente los valores de configuración, o los datos que resuelven las reglas de enrutamiento, o algún dato configurable que incida en las reglas de negocio que orquestan el proceso. Desde este punto de vista, cada despliegue de ese mismo servicio en cada entorno supone una instancia de dicho servicio.

Otro parecido razonable entre SOA y OO lo encontramos en el ocultamiento de su lógica interna, lo que conocemos como encapsulamiento. Al igual que un objeto se comporta como una caja negra para el exterior, y simplemente ofrece una serie de métodos para ser invocados, un servicio de negocio SOA también responde al mismo enfoque: lo que hace internamente es totalmente transparente para sus consumidores. Aquí hay un pequeño matiz: en un servicio SOA el encapsulamiento se da en dos niveles: por un lado, el consumidor del servicio simplemente recibe el mensaje del evento de negocio al que se subscribió, y no sabe nada de cómo ni desde dónde se generó (lo que se conoce como desubicación, otro concepto importante que trataremos más adelante). Al mismo tiempo el ESB recibe el mensaje del evento de negocio provisto por el sistema proveedor, y no sabe ni le interesa cómo generó ese sistema de información dicho mensaje. Lo mismo es válido cuando hablamos de servicios de consulta-respuesta, síncronos (los menos recomendables como veremos más adelante cuando hablemos de EDA).

Otro de los aspectos en los que la OO y SOA van de la mano, es la reutilización. Uno de los grandes logros que trajo la OO fue la capacidad real de diseñar software de forma óptima, modelando la realidad encapsulando el comportamiento de los objetos y sus estados (métodos y atributos) en una única definición que pudiera reutilizarse cuantas veces quisiéramos, ya que el modelado se enfocaba no al problema funcional concreto del requerimiento particular de un sistema de información particular, sino al objeto en sí. Y ese objeto sería el mismo en todos los contextos en que apareciera. Así, una vez tienes definida la clase “Cliente”, con sus atributos y sus métodos, no tienes que volver a definirlo para otros sistemas de información que deban lidiar con el objeto “cliente”. Simplemente reutilizamos la clase que ya tenemos. Como mucho, podemos heredar otra clase para crear una clase de cliente específica, pero poco más.

Con los servicios SOA ocurre algo parecido, aunque en este caso la reutilización es más pura. Un servicio se reutiliza tal cual todas las veces que sea necesario. Y no solo en distintos ESB, o distintos ámbitos, donde los procesos de negocio a resolver son los mismos, sino que también podemos reutilizarlos como piezas para resolver servicios de mayor nivel de complejidad, a base de participar en orquestaciones más amplias de eventos. Todo depende de los patrones de procesos de negocio que estemos implementando en los servicios y los eventos que participen en ellos.

Pero la característica que más enlaza SOA y OO desde mi punto de vista es la abstracción.

De la misma manera en que una clase representa un patrón abstracto de atributos y métodos encapsulados, autocontenidos, que ocultan al exterior su comportamiento, un servicio es también una abstracción de un patrón de eventos, reglas y datos encapsulados, autocontenidos, que ocultan al exterior su comportamiento interno.

Encontrar el equilibrio entre abstraccion y granuralidad es clave en los Servicios SOA

La abstracción en SOA tiene un peso específico al menos tan importante como en la OO. Tanto si estamos en una aproximación de arriba abajo (top-down), es decir, descubriendo servicios desde el análisis de los procesos de negocio, como si estamos en una aproximación de abajo arriba (bottom-up), es decir, identificando servicios desde el estudio de los sistemas de información existentes y la manera en que tienen implementadas sus soluciones de integración, siempre es necesario mantener un ejercicio constante de revisión parecido al zoom in y zoom out en un mapa. Debemos mover nuestro nivel de abstracción de más arriba a más abajo para asegurarnos de que encontramos el punto de granuralidad adecuado en la definición de nuestros servicios.

Un servicio demasiado abstracto provoca una reutilización exagerada, una indefinición por ambigüedad de su semántica, dificultades para gestionar su ciclo de vida, o la seguridad, y al final una degradación de la capacidad de monitorizar el negocio de manera eficiente.

Un servicio con falta de abstracción provoca una reutilización muy baja, la proliferación excesiva de servicios muy parecidos, y una mejora muy pobre del acoplamiento entre los sistemas de información.

En SOA por tanto es fundamental manejar una capacidad de abstracción muy potente y ágil. Puede facilitar mucho las cosas tener bien entrenada la capacidad de abstracción para hacer un análisis y diseño de servicios de negocio acertados. Y como hemos visto, existen muchas otras similitudes entre la Orientación a Servicios y la Orientación a Objetos.

Por todo esto siempre recomiendo, tal como hicieron conmigo en su día, asegurar un completo y profundo entendimiento de la OO antes de sumergirse de lleno en SOA.

Te puede interesar

0 comentarios

Trackbacks/Pingbacks

  1. Principio SOA 3: la Abstracción en los Servicios, un paso más allá. - […] este concepto aparece a menudo cuando tratamos la orientación a servicios. De hecho le dedicamos esta entrada […]

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Sigueme en las redes

Share This