El tratamiento de los datos como “ciudadanos de primera clase”
Nadie discute que la orientación a objetos es hoy día el denominador común en el desarrollo y evolución de nuestros sistemas de información.
Así lleva siendo realmente desde hace varios años. Y desde hace varios años los desarrolladores JAVA han sufrido lo que se ha dado en conocer como ‘impedance mismatch’ que supone un sobrecoste estimado de un 40% sobre el esfuerzo requerido para el desarrollo y manteniendo de dichos sistemas. Y es que, paradójicamente, el mundo relacional aún domina el ámbito de la persistencia de datos en estos sistemas de información.
Parece un hecho que los grandes fabricantes se han concentrado en la mejora de las herramientas destinadas al desarrollo de aplicaciones orientadas a objetos y, de algún modo, se han olvidado del otro pilar fundamental en todo sistema de información y que no es otro que el motor de datos que almacena la información de dicho sistema. En la mayoría de los casos todavía hablamos del tradicional motor relacional que basa su persistencia en estructuras bidimensionales (tablas). Si pensamos en la enorme limitación que a un lenguaje como JAVA le supone no poder trabajar con una representación consistente, en objetos, desde la capa de aplicación a la de datos, no son de extrañar los ímprobos esfuerzos que la industria ha venido realizando a lo largo de los últimos 10 ó 15 años para “facilitar” el mapeo entre el mundo de objetos y el relacional, creando la tecnología de Java Beans, Enterprise Jaba Beans (EJB) 2 y más recientemente EJB 3 e Hibernate. Todas estas tecnologías o herramientas en el fondo siguen apoyándose y, de algún modo, promoviendo la existencia de un motor relacional en el que implementar la persistencia de los objetos que se manejan a nivel de aplicación.
La pregunta que debemos hacernos es simple: ¿por qué nos empeñamos en mantener una tecnología de persistencia que supone un lastre tan patente para nuestras aplicaciones, tanto en esfuerzo de desarrollo como en el rendimiento en producción?; y sobre todo, ¿por qué los grandes fabricantes no abren nuevas vías de evolución en el mundo de los motores de datos? La base instalada puede ser una respuesta. Puede que haya más razones, lo que está claro es que los fabricantes conocen el problema y saben perfectamente que no se está ofreciendo a la comunidad de desarrolladores la solución más óptima que a día de hoy sería posible.
Como siempre las generalizaciones tienden a simplificar aquello de lo que se habla. Realmente podríamos decir que no es cierto que no se esté andando el camino. De hecho sí hay fabricantes que desde hace años, cuando el problema se hizo patente, lo abordaron desde una perspectiva innovadora y así nació, por ejemplo, InterSystems Caché®, permitiendo que las aplicaciones basadas en tecnología orientada a objetos fuesen capaces de “ver” los datos almacenados en el motor como objetos propios y, sobre todo, fuesen capaces de almacenar sus objetos, de forma nativa, en el motor, sin necesidad de mapeos que indefectiblemente complican el modelo global. En concreto, en su versión Caché 2007, además de permitir trabajar en sistemas apoyados en EJB o Hibernate, incorpora la tecnología Jalapeño (Java Language Persistente with No mapping).
Puedo así trabajar con EJB o Hibernate, o dar un paso más allá e ir a un modelo OO puro con tecnologías como Jalapeño. En todos los casos conseguiríamos independencia del motor de datos final. Con las primeras, requerimos que los datos estén en una estructura relacional, así tendré objetos en la parte JAVA y tendrán que pasar a través de algún tipo de proceso de mapeo para pasar a la parte relacional. Pero nos crean retos en el momento en que queremos cambiar la representación en uno de los extremos. Así, cuando mi modelo de objetos cambie en Java, cuando exista un mapeo objeto-relacional, cambiar el lado relacional puede resultar bastante complicado. Jalapeño, por otro lado, se apoya en la posibilidad real de almacenamiento de objetos para facilitar el desarrollo, conectando directamente la definición de clases y objetos en JAVA con la base de datos. Para ello permite al desarrollador el uso de cualquier entorno de desarrollo (Eclipse, NetBeans, IntelliJ,..) y deja que cree sus clases (Plain Old Java Objects) sin importar su tipo y, cuando lo requiera, decide cuales han de hacerse persistentes. El motor se encargará de tomar esas clases e ir componiendo el modelo de clases que finalmente definirá la persistencia de la aplicación que estemos diseñando.
Por otro lado, ningún desarrollador JAVA escogería una herramienta de desarrollo que no le facilitase de algún modo el refactoring, la evolución y cambio de sus aplicaciones. Cuando estamos sujetos a un mapeo objeto-relacional, un cambio en el modelo de clases JAVA puede llevarnos a tener que realizar un volcado de la información de la base de datos relacional, para así poder modificar el modelo E/R y después proceder de nuevo a importar los datos. Se trata de un nuevo efecto colateral de nuestro ya conocido impedance mismatch que sería más que deseable evitar y es lo que también se consigue con tecnologías como Jalapeño que traslada automáticamente a la BD los cambios en el modelo JAVA, sin necesidad de un proceso de descarga y carga de información.
De todo esto, debemos sacar como conclusión que sería más que deseable que la industria innovase realmente en el mundo del desarrollo de aplicaciones y que finalmente viese este mundo de modo global, con los datos en él. Al final no hablamos de otra cosa que de aumentar rendimiento y fiabilidad, tanto de las aplicaciones como de los procesos de desarrollo, lo que necesariamente ha de redundar en la disminución de costes para los usuarios. Algunos fabricantes ya están andando ese camino. Los que no lo hagan probablemente dejen de serlo.
URL: http://www.datati.es/?p=43
Escrito por 
