Muchos vendedores y proyectos de código abierto en Java ofrecen herramientas complejas, construidas para resolver problemas complejos, frecuentemente bajo el paraguas de desarrollo “empresarial” en Java. Por ello, en la actualidad asistimos a una explosión de complejidad en J2EE, EJB y XML. Aunque es cierto que la sencillez y la potencia de una herramienta suelen ser opuestas, algunos arquitectos importantes de la comunidad Java trabajan para cambiar la tendencia desde los frameworks monolíticos hacia otros más sencillos y limpios. Así, varios proyectos se oponen a la tendencia a una mayor complejidad, optando por construir frameworks específicos más ligeros que ayuden a simplificar las aplicaciones.

En este artículo, examinaremos unos pocos de estos frameworks y nos ocuparemos de los principios básicos con los que consiguen ser más sencillos. Concretamente, estudiaremos un contenedor ligero y un framework de persistencia. Luego veremos cómo los vendedores J2EE más importantes enfrentan este cambio de paradigma.

2. VOLVER A EMPEZAR

Hay unos pocos proyectos notables que se basan muy poco en J2EE. Básicamente intentan crear una noción simplificada de lo que significa ser un objeto persistente o un contenedor. Los contenedores ligeros como Pico o Spring proporcionan menos servicios que EJB, pero tienen una arquitectura mucho menos invasora. Por otra parte, Hibernate, un framework de persistencia, ofrece una alternativa a la persistencia gestionada por el contenedor (Container Managed Persistence o CMP) de EJB, como veremos a continuación.

2.1. Persistencia transparente

La solicitud 12 de especificación de Java (Java Specification Request 12) fue una de las primeras solicitudes que se realizaron dentro del Proceso Comunitario Java (Java Community Process o JCP). Solicitaba persistencia transparente en forma de JDO ya que argumentaba que ésta no podía conseguirse con los beans de entidad EJB. JDO falló por un tiempo pero ha experimentado un resurgimiento en el último par de meses gracias al respaldo de los equipos de desarrollo de los servidores de aplicaciones SunOne y JBoss. Con dos fuertes productos JDO como Kodo y Lido, se puede decir que la persistencia transparente se ha hecho realidad.

Siguiendo la misma línea, Hibernate es un proyecto de código abierto, iniciado por Gavin King, que proporciona persistencia transparente para aplicaciones Java. Debo confesar que, aunque imparto una sesión introductoria sobre Hibernate en varias conferencias, no creo que Hibernate experimente un éxito rápido, sino que pienso que será, en el mejor de los casos, un actor secundario en el mercado. Al fin y al cabo, es propietario, goza de recursos de desarrollo modestos comparados con muchos de los motores de persistencia comerciales y es un proyecto de código abierto, lo que puede perjudicarlo en los departamentos informáticos más grandes. Aún así, Hibernate ha irrumpido en la escena con un impulso tremendo, proporcionando un framework sorprendentemente rico y rápido.

Al contrario que JDO o EJB, Hibernate no esta basado en la “mejora” de bytecodes o en la generación de código, sino que utiliza reflexión. Deja una huella pequeña y, a parte de la base de datos, necesita muy pocos recursos para ejecutarse. Creo que el éxito de Hibernate se debe a tres razones principales: es específico, sencillo y rápido. Veamos a continuación algunos de los principios que han hecho exitoso al proyecto Hibernate.

• Haga sólo una cosa y hágala bien. Hibernate es un motor de persistencia que funciona exclusivamente con aplicaciones Java que usan bases de datos relacionales mediante JDBC. Esto constituye la mayor proporción de los casos de persistencia en Java. Además, es un problema específico. Así, limitando el dominio del problema a bases de datos relacionales, Hibernate puede tomar algunas decisiones pragmáticas que tienen un impacto dramático sobre la eficiencia. Por ejemplo, como los diseñadores sabían que usarían SQL a través de JDBC, pudieron aprovechar algoritmos específicos para estos casos y extensiones de alto rendimiento para “outer joins”. Esto no es posible en muchos otros frameworks de persistencia, ya que no se limitan a bases de datos relacionales. Así, Hibernate consigue una mayor eficiencia al precio de un mayor acoplamiento a un problema específico.

• Procure alcanzar la sencillez. El equipo de Hibernate ha trabajado duro para conseguir documentación efectiva y buenos ejemplos de uso. Además, ha diseñado una API sencilla. Así, conseguí que mi primera aplicación con Hibernate se ejecutara en menos de quince minutos. Observo la sencillez de Hibernate en muchos puntos. Sus métodos tienen nombres adecuados y las capas de abstracción están claras. Puedo trabajar simplemente con Javabeans, en vez de tener que construir componentes complejos. Hibernate incluye integración con Ant y soporte a Xdoclet. En general, un framework debería proporcionar a sus usuarios el soporte más sencillo posible.

• Elija sus batallas. Si usted decide construir aplicaciones o frameworks más sencillos, deberá decidir donde centrar su atención. No puede adoptar cada patrón de diseño existente o hacer todas las mejoras de eficiencia posibles. Admito que algunas de mis primeras reservas sobre Hibernate se debían a su uso de la reflexión. Sin embargo, Gavin King y su equipo supusieron de forma correcta que la sobrecarga debida a la reflexión sería mínima comparada con la debida a las consultas SQL que Hibernate generaría. En vez de optimizar la reflexión, el equipo se concentró en el número y eficiencia de las consultas retrasando actualizaciones, combinando muchas sentencias SQL en una, detectando “no operaciones” (como una inserción seguida inmediatamente de una actualización y un borrado) y haciendo optimizaciones similares. El resultado es un framework sorprendentemente rápido, que además goza de la transparencia que permite la reflexión.

Debido a la sencillez y a su concentración en los puntos importantes, el equipo de Hibernate ha conseguido lanzar versiones bien acabadas a un ritmo rápido. Su comunidad de usuarios crece a pesar de que se ha completado sólo la segunda versión principal. Pero la persistencia no es el único dominio en el que la tendencia a la sencillez está echando raíces.

2.2. Contenedores ligeros

Los contenedores ligeros intentan proveer servicios para componentes que sean lo más sencillos posibles. Spring y Pico son los contenedores ligeros más populares. Si todavía no los conoce, quizás esté tentado de saltarse este apartado, pensando que lo último que necesita es otro contenedor más. No lo haga. Los contenedores ligeros como Spring se están difundiendo rápidamente, porque pueden resolver problemas que otros contenedores no pueden. Aunque estos frameworks no son tan conocidos como Hibernate, al menos uno de ellos puede serlo pronto. El equipo de Spring comienza a generar el ruido familiar de las primeras etapas de un proyecto exitoso de código abierto. Desde mi punto de vista, los aspectos más interesantes de Spring son la transparencia de los objetos, la existencia de servicios limpios y desconectables y su huella pequeña. Todos estos aspectos producen un framework sencillo y efectivo, con las siguientes características:

• Transparencia. Cuando se construye una solución para programadores, lo más sencillo suele ser lo mejor. Spring no es invasor. De hecho, los objetos que se colocan en el contenedor son simples POJOs (“Plain Old Java Objects”), objetos tradicionales de Java (o JavaBeans, para ser más precisos). Los objetos no dependen del contenedor. Pueden ejecutarse fuera del mismo para facilitar las pruebas o llamar a otros objetos como POJOs.

• Posibilidades de extensión. Spring soporta algunos servicios sencillos de forma integrada, incluyendo, por ejemplo, capas JTA y JDBC para proporcionar soporte a bases de datos y a transacciones. Además, Spring ofrece una API bien distribuida en capas y que puede ser extendida fácilmente por terceras partes. Por ejemplo, ya se pueden usar objetos Hibernate y JDO dentro de un contenedor Spring.

• Una huella más pequeña. La sencillez de Sprint le permite una huella más pequeña. Así, puede usarse de maneras que no podría usarse un contenedor J2EE tradicional. Puede utilizarse fácilmente en la etapa de pruebas, incluso si planifica ejecutar muchas de ellas en una sola construcción. Se puede usar Spring en un cliente Web o en un dispositivo móvil.

Como los contenedores ligeros trabajan con objetos tradicionales de Java (POJOs), separan claramente las funciones de los diversos servicios. Por ello, son adecuados para la próxima generación de paradigmas de programación, como la programación orientada a aspectos.

Hemos visto que Hibernate y Spring reducen la complejidad del desarrollo de software, para lo cual se basan en abstracciones simplificadas. Ahora bien, hemos visto también que la sencillez y la potencia de una herramienta suelen oponerse. ¿Cómo sabemos que estas abstracciones son suficientemente potentes para un desarrollo empresarial?

2.3. Abstracciones con fugas

Está claro que hay una tendencia a retornar a abstracciones más sencillas y limpias, pero la sencillez no es suficiente. Todas las abstracciones tienen fugas, es decir, hay situaciones en que no pueden o no deberían abstraer la infraestructura subyacente. Por ejemplo, nunca será posible capturar toda la complejidad de la API nativa de una base de datos en un framework simplificado y un contenedor ligero nunca será capaz de hacer todo lo que hace un contenedor pesado. Por esta razón, es importante exponer la capa inmediatamente inferior a la nueva abstracción. Por ejemplo, en Hibernate no existe el concepto de procedimientos almacenados. En vez de esto, se permite el acceso completo a la conexión JDBC subyacente, para que se pueda llamar a los procedimientos almacenados desde fuera de Hibernate.

Además, una arquitectura adaptable y conectable, con bajo acoplamiento en las áreas apropiadas, permite desconectar los servicios que son inadecuados y conectar otros más robustos. Por ejemplo, Spring permite conectar y desconectar la persistencia y las transacciones.

Hasta ahora, hemos mencionado un par de proyectos de código abierto que simplifican el desarrollo de aplicaciones Java. A continuación, veremos lo que los principales vendedores J2EE están haciendo para soportar un paradigma Java más sencillo.

3. ENFOQUES ALTERNATIVOS

Por supuesto, construir frameworks más sencillos desde cero es sólo una forma de ganar sencillez. La comunidad Java está explorando también otros enfoques alternativos. Algunos equipos de desarrollo están evaluando paradigmas de programación completamente nuevos, como arquitectura dirigida por el modelo (Model Driven Architecture o MDA) o programación orientada a aspectos (Aspect-Oriented Programming o AOP). Otros están probando un enfoque más incremental, como usar herramientas para protegerse de la complejidad.

3.1. Herramientas que simplifican

Algunos vendedores, especialmente los que tienen una inversión significativa en J2EE, pueden pensar que los contenedores ligeros, Hibernate y frameworks similares son una desviación demasiado radical del status quo. Estos vendedores pueden no prescindir completamente de J2EE para volver a empezar, sino que pueden preferir usar herramientas más inteligentes que consigan aislar a los usuarios de la complejidad. Rave de Sun o Workshop de BEA adoptan este enfoque.

Inspirándose en Visual Studio, BEA y Sun han construido herramientas para proteger a los programadores sin experiencia de las complejidades de J2EE. Se espera así que herramientas más inteligentes con alto nivel de generación de código puedan aislar a los programadores en J2EE más comunes de un excesivo nivel de detalle.

La habilidad de construir aplicaciones con bajo acoplamiento, especialmente usando servicios Web, es una característica fundamental de Workshop de BEA, que intenta proveer un conjunto de abstracciones simplificadas que permitan a sus usuarios ser mucho más productivos. Para tener éxito con Workshop, BEA tiene un reto doble. Debe abstraer a sus usuarios la mayor parte de la complejidad de J2EE, y aún así permitir el acceso a algunas de las capas subyacentes para que los clientes puedan usar Workshop en formas que vayan más allá de las intenciones del equipo original de diseño.

4. ¿QUÉ ENFOQUE ES EL MEJOR?

¿Se adelantará alguno de estos enfoques y matará al dragón de la complejidad? La verdad es que, hasta donde puede preverse, es probable que veamos muchos más intentos de reducir la complejidad, ya que, en lo que respecta a la misma, se está llegando al límite superior de lo que la mayoría de equipos modernos de desarrollo de aplicaciones puede manejar. Pero la industria no se limitará a un único enfoque. Los vendedores con grandes inversiones en frameworks existentes para J2EE tenderán a preferir mejores herramientas que liberen a sus clientes de los detalles tediosos. Otros esfuerzos, como Hibernate y Spring, intentarán adoptar un enfoque más radical y fundamental. Incluso otros intentarán argumentar que Java nos ha traído tan lejos como es posible y que debemos pasar al siguiente lenguaje o paradigma como C# o AOP. El terreno está preparado. Que comience el juego.

SOBRE EL AUTOR

Bruce Tate es un consultor en Austin, Texas. Es el autor de libros muy vendidos como Bitter Java y Bitter EJB. Es un conferenciante común en conferencias de la industria, como TheServerSideSymposium y No Fluff, Just Stuff Java Symposium. Tiene 15 años de experiencia en desarrollo y es el fundador y presidente de J2Life, que ofrece consultoría y servicios en el área de persistencia en Java, mercadotecnia en programación y en el proceso de desarrollo de aplicaciones.

Compruebe la calidad de nuestro desarrollo offshore.
Aurum Solutions tiene experiencia en desarrollo offshore en J2EE y .NET de alta calidad y reducidos costos para empresas europeas y norteamericanas. Conozca nuestro desarrollo offshore haciendo clic aquí o en la página Web ../../offshore.html.

Cursos de Aurum Solutions relacionados con el tema de este artículo:
“Frameworks y bibliotecas para el desarrollo en Java”
“Persistencia para Java”
“Buenas prácticas en programación en Java”
“Buenas prácticas en arquitecturas J2EE”