h1

5 Herramientas Opensource y 10 Frameworks de desarrollo que todo delivery engineer debería conocer (Parte II)

08/02/2007

Wizdoc [Icon By Buuf]  Tips & Tricks.
Continuando con el tema iniciado la semana pasada, donde describí 5 herramientas opensource indispensables para cualquier developer, hoy concluyo con los 10 frameworks que, aventurándose a un proyecto sin ellos, tenemos la mejor receta para el desastre: recuerdo un proyecto en una anterior vida donde se requería la generación y/o parseo de archivos XML de varios Megabytes de longitud. El arquitecto decidió que …los frameworks no tienen utilidad y es mejor hacerlo a mano… y así fue, hasta que todo reventó espectacularmente.

Dejando los rodeos, éstos son los frameworks que no sólo pueden salvar un proyecto, sino también un trabajo (o dos o más, si el equipo esta muy comprometido con el proyecto):

Framework: Echo2
Tipo: AJAX (Asynchronous JavaScript and XML)
Desarrollado originalmente por NextApp y liberado posteriormente como opensource bajo las licencias Mozilla Public License o GNU LGPL, es EL framework por excelencia en cuanto a AJAX se refiere: cuando se necesite una aplicación web con cliente rico (parecido al meebo), este framework es como implementar una aplicación AWT/Swing pero sin la necesidad de conocer HTML o Javascript.


Demo de Echo2

Ya en una ocasión anterior resumí una comparación originalmente realizada en The Server Side entre este framework y el Google Web Toolkit proporcionando los pros y contras de ambas tecnologías; por supuesto ambos destronan al infame JackBe.

Framework: Hibernate
Tipo: ORM (Object Relational Mapping)
Desde el principio: ORM se refiere a aquellas tecnologías dedicadas a la integración y comunicación de sistemas de datos relacionales (es decir, cualquier base de datos existente como Oracle) con lenguajes orientados a objetos (por ejemplo, Java).

La principal característica de Hibernate es que permite realizar el mapeo casi transparente entre clases de Java y tablas en la base de datos; los queries son generados por el framework liberando al programador de las tareas de generación de conexión, conversiones a partir del ResultSet y demás labor de bajo nivel. Por esta simple funcionalidad, Hibernate en conjunto con Spring, provocará la desaparición de los EJBs – especialmente los Entity Beans. Al grado que prácticamente la especificación EJB 3.0 fue diseñada tomando a Hibernate y Spring como modelos a seguir por Sun para evitar la desaparición de su propia tecnología.

Framework: Jasper Reports (+ Herramienta iReport)
Tipo: Reporteo
Concebido desde el principio como un proyecto opensource, Jasper Reports es el framework de su tipo más utilizado en la industria, permitiendo la generación de reportes con los formatos "más buscados" (desde PDF o HTML hasta XML). Adicionalmente tiene algunos "extras" que facilitan la labor del programador o mejoran los resultados del producto terminado: añadir gráficas (en conjunto con el framework JFreeChart, descrito más abajo), funciones tales como cálculo de consolidados, números de página, promedios, mínimo, máximo, etcétera.


El "primer reporte" en Jasper

Por otro lado, la herramienta de diseño iReport tiene una curva de aprendizaje muy baja, y en conjunto estas dos tecnologías ayudan a generar reportes en un dos por tres.

Framework: JCSP (Java Communicating Sequential Processes)
Tipo: Multithreading
Desarrollado inicialmente como un proyecto académico por parte de Peter Welch, de la Universidad de Kent (Canterbury, Reino Unido), este framework está basado en la investigación relacionada a los Procesos de Comunicación Secuencial, que básicamente son una rama de la teoría de la computación relacionada a la descripción de patrones de interacción en sistemas concurrentes. En pocas palabras, tanto la teoría como la implementación realizada por el framework abstraen la capa de multithreading (Threads/Runnable) y evitan que el programador "meta las cuatro" al construir un sistema con este tipo de requerimientos.
Framework: JFreeChart
Tipo: Graficación (Histogramas, gráficas de pie, líneas, dispersión)
De acuerdo a la información desplegada en el home del proyecto:

El proyecto JFreeChart fue fundado hace siete años, en febrero del 2000, por David Gilbert. En la actualidad, JFreeChart es usado por aproximadamente 40-50 mil desarrolladores (ver aquí una lista de los proyectos que utilizan JFreeChart). El proyecto continúa siendo administrado por Gilbert, con las contribuciones de una diversa comunidad de desarrolladores.

El financiamiento del proyecto es proporcionado por Object Refinery Limited, la compañía de David Gilbert basada en el Reino Unido. Object Refinery vende la documentación y servicios de consultoría relacionados a JFreeChart.


Uno de los muchos tipos de gráficas obtenidos mediante JFreeChart

Así entonces, JFreeChart utiliza el mismo modelo comercial de JBoss o Sun Microsystems: como desarrollador puedes descargar el software y utilizarlo de forma libre, pero si requieres documentación o soporte, ahí te la dejamos ir.

Framework: Log4J
Tipo: Bitácoras/depuración
Parece difícil que a estas alturas todavía existan proyectos donde se siga utilizando System.out.println() para depurar programas; especialmente aquellos donde el desempeño de la aplicación está en juego. Sin embargo, he visto aplicaciones donde el nivel de transaccionalidad es altísimo (300 o más transacciones compuestas por segundo) y aún así para cada paso de la transacción lo utilizan. La respuesta es Log4J, que adicionalmente a ser un proceso ligero (es decir, el memory footprint y el overhead resultantes de integrarlo a nuestra aplicación son muy bajos), permite varios niveles de depuración (o lo que es lo mismo: sólo "imprime" los mensajes del tipo asignado, desde el aburrido DEBUG hasta el temido FATAL) es muy sencillo de instalar e integrar a cualquier componente, desde stand-alones hasta JSPs, servlets o EJBs. De hecho, cualquier framework que se respete contiene por ahí su archivo de configuración del log4j para que podamos depurarlo.
Framework: OSCache
Tipo: Sistema de Cacheo (Caching System)
Cuando se requiere algo más que sólo un Hashtable para implementar nuestro cache (por ejemplo, caches que automáticamente se actualicen cada cierto tiempo, o que requieran ser persistidos en disco) podemos utilizar la implementación ofrecida por OpenSymphony: adicionalmente a las características antes mencionadas, incluye otros features que agregan robustez y escalabilidad al framework, como tags de JSP para el manejo dinámico del cache o plugins de persistencia con JDBC y OLAP. Finalmente, lo que me pareció realmente interesante del proyecto es que puede integrarse a Hibernate, proporcionando funcionalidad de cache sobre la base de datos (de primera instancia, cargar en el cache los catálogos de la aplicación me parece un buen inicio).
Framework: Quartz
Tipo: Calendarización de eventos
Implementado también por OpenSymphony, Quartz es un framework que nos permite calendarizar eventos, extendiendo la funcionalidad básica de las clases de Java java.util.Timer y java.util.TimerTask para incluir novedades tales como manejo del estado resultante del evento (éxito/fracaso), JobListeners y TriggerListeners que escuchan cuándo sucede la ejecución de un evento, implementación de transaccionalidad (JTA), entre otras. Adicionalmente, al igual que OSCache, este framework ha sido diseñado tomando en cuenta su integración a Hibernate y Spring.

Nota: El único detalle que le he encontrado es que para ciertos servidores de aplicaciones (específicamente el Sybase EAServer) puede generar errores fatales que tiran el servidor debido a la manera en que maneja los hilos de ejecución.

Framework: Spring
Tipo: Middleware / Reemplazo de la especificación EJB
Altamente basado en las técnicas de Inversión de Control (Inversion of Control – IoC) y Programación Orientada a Aspectos (Aspect-Oriented Programming – AOP), Spring es un framework que ha revolucionado la manera en que se desarrollan sistemas de alta escalabilidad y robustez. Genuinamente llevando a cabo las promesas incumplidas por los EJBs, Spring permite desarrollos más orientados al negocio (en vez de ser orientados a la tecnología implementada). Adicionalmente, es un framework muy completo que puede funcionar como middleware por las siguientes características y/o módulos que lo componen:

  • Es un lightweight container (En términos simples, mantiene y gestiona pools de Java Beans).
  • Mediante la AOP que lo integra, logra implementar una capa de abstracción para la gestión de la transaccionalidad.
  • También posee una capa de abstracción para las implementaciones de JDBC.
  • Es integrable con un sinnúmero de frameworks (Quartz, Hibernate, Tapestry, entre otros).
  • Posee su propio submódulo MVC que opera bastante bien al integrarlo con web frameworks como Struts o Tapestry.

Aunque la curva de aprendizaje de Spring es algo elevada, es bastante menor que la de los EJBs y como mencioné anteriormente, ha incluso afectado el cómo se definió la propia especificación EJB 3.0 y probablemente, tarde o temprano la reemplace o elimine por completo.

Framework: Tapestry
Tipo: Presentación (Web)
Mi favorito en cuanto a MVCs, aunque poco utilizado en la industria (espero que con la llegada de los JSF esto cambie), Tapestry es un framework que por su excelente documentación, facilidad de aprendizaje, mantenibilidad y relativa escalabilidad, cada que implemento un proyecto web y puedo seleccionar las tecnologías de implementación, me voy por éste.


El Tapestry Component Workbench

Nota: Por ahí llegué a escuchar que no funciona del todo montado sobre el Websphere, pero ya lo he visto correr sin problemas sobre Sun Application Server, Weblogic y hasta Sybase EAServer.

Conclusiones

Ahhh listo; por supuesto que hay muchos otros frameworks que son igualmente útiles para nuestros proyectos de JEE delivery (como Apache Axis), pero estos son los más significativos en cuanto a capacidad y uso. Tomando prestada la leyenda en la entrada del Infierno de La Divina Comedia (con un poco de mi cosecha, claro está): "¡Oh vosotros los que entráis a este proyecto sin sus frameworks al hombro abandonad toda esperanza!"

One comment

  1. Estimado, estas muy equivocado en el tema del Hibernate, EJB 3 no fue diseñado a partir de Spring y Hibernate para evitar su desaparicion, desde EJB 2 fue el mismo equipo de Hibernate quien tomo la batuta en la especificacion de EJB (JPA es base fundamental en ambos frameworks) siendo el modelo de EJB 3 la especificacion oficial y Hibernate la especificacion paralela. Yo he utilizado EJB y Spring y te digo q no se parecen en casi nada. Mas bien, ahora he probado el Framework de JBoss Seam y veo que es mucho mejor que estos dos, pues soporta EJB 3 y ademas no solo soportar inversion de control sino tambien biyeccion de dependencias (no solo in, sino tambien out) y ademas soporta nuevos contextos como el Conversation.



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

A %d blogueros les gusta esto: