Yo diría que, en este momento, la práctica totalidad de las aplicaciones de negocio actualmente utilizan un gestor de base de datos relacional para guardar sus vitales datos de negocio. Las bases de datos relacionales (RDBMS) nacieron en los años 70 y se impusieron desde entonces en los entornos empresariales de la mano sobre todo de Oracle (todavía hoy cuando se cita esta empresa se piensa en su base de datos) y de IBM con su DB2.


Por otra parte, como comentaba en un post anterior, con el movimiento NoSQL, establecido en la práctica por empresas como Facebook, Amazon, Google, Linkedin,  estamos asistiendo a una “crisis” del status quo que ha establecido por este tipo de bases de datos. En unos servicios con millones de usuarios, el movimiento de virtualización y de “cloud”, se ve que este forma de guardar los datos de negocio no escala como debiera.

Pero volviendo a las bases de datos relacionales, ¿que debemos tener en cuenta desde un punto de vista conceptual para su uso en una arquitectura SOA?

1.- el desacoplamiento de las bases de datos

En las grandes corporaciones hemos asistido a un proceso de “concentración” de las bases de datos en un modelo de datos centralizado. Se ha hecho un esfuerzo para unificar estos modelos de las decenas de aplicaciones departamentales o verticales que tenía la empresa por las ventajas que conllevaba la unificación en un sólo modelo, desde el punto de vista de su gestión y sobretodo de la coherencia de los datos (la calidad de los datos es una de las grandes preocupaciones que se tienen en T.I.)
Sin embargo, bajo un paradigma SOA, no parece lógico que si los servicios están desacoplados, sí que lo esté su modelo de datos. Para garantizar la integridad de los datos se ha utilizado la característica de de integridad referencial asegurando de este modo relaciones entre las entidades de negocio.
Por ejemplo: “para tener una cuenta corriente tipo Premium hay que tener una hipoteca contrada”. Simplificando mucho, para esto se establecía una clave ajena en la tabla cuenta corriente que hacía relación a la clave de la hipoteca.
En un mundo “pre-servicios”, los programas accedían a las tablas directamente. Esto ha planteado un problema de evolución del modelo de datos, ya que es muy problemático cambiar el modelo de una tabla si ni siquiera sabes a ciencia cierta quién accede a ella. Parece un modelo de diseño equivalente a la que se tenía con la  programación estructurada frente a la programación orientada a objetos.
Si un conjunto de servicios, de una misma agrupación funcional, por ejemplo, los servicios de negocio de Clientes o Prestamos, tienen su propio modelo de datos, sin ninguna relación entre sí, entonces la “aplicación” de Clientes puede ser cambiada por otra sin ningún problema (sus servicios de negocio estarán desacoplados del resto y la base de datos sobre la que se apoya también).

2.- bases de datos que hacen de servidores de aplicaciones

Las bases de datos proporcionan, además de las tabla y la gestión de los datos propiamente dichos, una forma de implementar programas que manipula estos datos: los procedimientos almacenados (el más famoso es quizás el PL/SQL de Oracle).
Por mucho que les pese a los vendedores de gestores de bases de datos, estos servidores no están a la altura de lo que pueda ser un servidor de aplicaciones tipo Websphere de IBM o Weblogic de la propia ORACLE. Y de muestra un botón, por ejemplo, hasta la versión reciente 11.2, ORACLE no proporcionaba un servicio 24/7 ya que cuando se realiza una actualización del código de la aplicación (con procedimientos almacenados) era necesario parar el servidor. En el caso del código de la aplicación en un servidor de aplicaciones, hace ya algunos años que se hacer un “upgrade” de una versión de la aplicación sin parar el servicio. Esto se logra, porque en un entorno de Producción hay varios servidores o nodos que ejecutan la misma aplicación. Es posible ir parando un nodo, uno a uno, cambiando la versión de la aplicación e ir levantándolo sucesivamente de tal manera que los usuarios no tienen pérdida de servicio en ningún momento.

3.- diseño centrado en las tablas

En la implementación de un servicio, pasamos de un servicio de alto nivel (con su interfaz de entrada/salida), a uno o varios componentes y estos a su vez son implementados con clases. La orientación a objetos es un paradigma que está muy maduro y lleva décadas entre nosotros. Lo que quiero decir con esto es que lo importante en una aplicación son los objetos, que tienen comportamiento de negocio en base a unos métodos que implementan su lógica. La base de datos es algo necesario, ya que los objetos “viven” en memoria y necesitamos algo que pueda persistir esta información en un soporte durable. Esto es así y es impepinable (al menos por ahora) pero lo que no podemos caer es en el error de diseñar nuestra aplicación basándonos en unas tablas. Son las tablas las que apoyan a los objetos y no al revés.

Conclusión:

  1. Pensemos en el modelo de datos como algo necesario para persistir los datos de negocio en el tiempo, pero aplicando los mismos principios de desacoplamiento que aplicamos al diseño de los servicios
  2. Dejemos las bases de datos y los servidores de aplicaciones para lo que saben hacer: servir datos las primeras y servir aplicaciones las segundas. Zapatero a tus zapatos…
  3. Pensemos en servicios. Y pensemos en implementar éstos como componentes orientados a objetos.

Comparte esta entrada…
Share

Anuncios