JavaServer Faces, ¿el substituto de Struts?

Una de las alternativas con respecto a los frameworks de presentación que han aparecido en los últimos años con más fuerza en el mundo open source es JavaServer Faces (JSF).

He podido trabajar con esta tecnología en los últimos proyectos en los que he participado y en la siguiente lista resumo lo que, en mi opinión, son los puntos fuertes de esta tecnología, desde mi experiencia práctica.

1. Orientado a componentes (estilo Swing) a diferencia de Struts, que está orientado a comandos. Para mí, esta filosofia en el desarrollo de presentaciones web es mucho más intuitiva para un programador.


2. Es un estandard REAL y no "de-facto" como Struts. De hecho JSF está incluido dentro de las especificaciones JEE 5. ¿Y qué aporta esto? Todas las grandes compañías tecnológicas y comunidades open source están apostando por JSF y han aportado o integrado librerías de componentes (Sun, BEA, IBM, Oracle, Apache, JBoss,...).


3. Relacionado con el punto anterior, existen múltiples librerías de componentes complejos (AJAX, Drag'n'Drop,...) que facilitan la vida al programador una barbaridad a la hora de hacer paginas visualmente complejas (que por otro lado es lo que mercado empieza a demandar hoy en día). Además puedes utilizarlas simultáneamente (he llegado a integrar en un proyecto RichFaces, Ajax4JSF, Facelets, Tomahawk y MyFaces, y os aseguro que funciona).


4. Existen herramientas WYSIWYG (editores visuales), aunque no proporcionan esa funcionalidad para todos los componentes. El RAD de IBM proporciona un pintador para componentes IBM, el JDeveloper para Oracle, MyEclipse y Eclipse Europa (3.3 + WTP 2.0) tienen pintador sólo para componentes básicos (MyFaces o RI de Sun). Que los pintadores sean para librerías concretas NO SIGNIFICA que no se puedan incluir otras librerías. A pesar de no existir pintadores genéricos, el tema "snippets" puede ser tan válido e incluso mejor que el pintador.


5. Podría parecer que JSF está poco maduro pero opino todo lo contrario. A parte de que la diversidad en cuanto a librerías va aumentado continuamente, hace más de un año que apareció la especificación JSF 1.2. En ella, se mejora aspectos concretos de especificaciones anteriores y aporta soluciones específicas (gestión de frames, pop-ups, etc.).
   

Por todo esto y por la demanda en temas JEE que empieza a haber en las empresas, tengo la impresión que Struts va perdiendo importancia y se quedará como una tecnología "migrable" en el futuro (más trabajo para nosotros... ;) ). La cuestión es cual será la próxima tecnología en presentación: ¿ JSF, FLEX, GWT , JavaFX, Silverlight,...? El tiempo dirá!

Siglas...

... montones de siglas. Seguramente esta es una de las primeras cosas que nos viene a la cabeza cuando pensamos en Java y J2EE/JEE. Algunas siglas identifican framewoks específicos, otras son especificaciones, patrones de diseño, “filosofías tecnológicas”, etc.

Dentro de las nuevas tecnologías relacionadas con el mundo web o arquitecturas orientadas a servicio, el mundo de las siglas es increíblemente extenso y cada día no dejan de aparecer nuevas: BPM, SOA, SCA, BPEL, JBI, SOAP, WSDL, UDDI, XHTML, JSPX, AJAX, JSON, JSF, RIA, JavaFX, EJB, DAO, POJO, JPA, ORM, etc, etc...

Todo esto refleja la situación actual dentro de este caos conceptual que son las nuevas tecnologías. En más de una ocasión, debido a las diferentes alternativas, tenemos que considerar cual es la más adecuada para las necesidades concretas de una empresa. Se suele correr el riesgo de utilizar siempre las mismas tecnologías en proyectos con requisitos y necesidades totalmente diferentes, bien por costumbre o simplemente por desconocimiento.

Con la aparición de los nuevos frameworks open source en estos últimos años, las arquitecturas J2EE/JEE se han complicado en el sentido de que suelen integrar múltiples librerías o frameworks, cada uno de ellos específico para tareas y funcionalidades concretas.

Aquí aparece la figura de arquitecto como integrador, que debe conocer exactamente los requerimientos no funcionales de las aplicaciones que soportará la arquitectura para aplicar y configurar cada tecnología de forma adecuada.

Hay cientos de siglas y por ende cientos de tecnologías. Las tecnologías siempre deben estar al servicio del negocio específico de una empresa y no a la inversa.