Resolviendo confusiones con los ESB

wikipedia no viene mucho al rescate para explicar lo que es un ESB: "There is some disagreement on whether an enterprise service bus is an architectural style, a software product, or a group of software products.". Claro como agua del Mapocho.

Gracias a una evaluación de varios productos que declaran ser de tipo ESB pude empezar a resolver varias inquietudes. Estos productos son Sun , Apache ServiceMix , Oracle ESB/SOA Suite y Spring Integration .

Confusión #1: ¿que provee un ESB?

ServiceMix y Sun OpenESB implementan JBI y son relativamente cercanos. JBI define:

• un bus donde fluyen mensajes "normalizados" (llamado "canonical" en otros productos),

• adaptadores (bindings components en JBI) que suben o sacan mensajes del bus,

• una forma de conectar al bus paquetes de software llamados Service Engine o SE que proveen la funcionalidad realmente interesante.

JBI no define ninguna lista de Service Engine pero ServiceMix y OpenESB ofrecen soluciones parecidas:

• enrutamiento, filtro, transformación de mensajes, lo que antiguamente se llamaba brokering de mensaje,

• gestión de proceso de negocio (workflow o BPM)

• motor de reglas,

• procesamiento grupal de mensajes (CEP),

Los ESB tipo JBI pueden ejecutar lógica de negocio, como workllow, CEP y lógica de integración más tradicional como transformación de mensaje. Eso los distingue de los productos EAI donde se recomendaba no tener lógica de negocio en el bus: el workflow y el EAI eran 2 motores apartes.

Spring Integration, obviamente no implementa JBI, y parece solamente definir servicios de integración (adaptadores + brokering) como los EAI antiguos.

Oracle tiene otra división: su ESB es parte de su SOA Suite, la cual incluye BPM (Oracle BPEL) para lógica de negocio, pero no incluye Oracle CEP.

Entonces, lo que esta en común entre estos cuatros fabricantes (Apache, Sun, Spring, Oracle) son los adaptadores, el bus donde fluyen mensajes normalizados (o "canonical") y servicios de brokering. Algunas soluciones ESB pueden considerar conectar al bus servicios que implementan lógica de negocio como BPM o CEP. Otras soluciones ofrecen estas funcionalidades aparte.

La confusión era valida y sigue vigente.

Confusión #2: ¿ESB es indispensable para implementar una solución SOA ?

Creo que esta confusión viene del mundo SOA, donde después de tantos años, nadie esta de acuerdo en definir SOA. Todavía no tengo claro la respuesta a esta segunda confusión pero ya no me preocupa tanto desde que hay reportes de vez en más alarmistas sobre el futuro de SOA. SOA puede desaparecer, igual tendremos que comunicar sistemas entre si y construir flujos de negocio. Lo que ofrece estos productos ESB seguirá relevante por muchos años.

Confusión #3: ¿En que se distingue la arquitectura de un ESB de un EAI?

Hace poco tiempo atrás habria respondido que:

• proveen basicamente los mismos servicios,

• los ESB se basan en tecnologías estandares como XML, XSL, BPEL, JMS, JCA.

• Los ESB usan una topología más distribuida, que los EAI. Los EAI usan la topologia estrella donde todo converge a su bus y toda la integración se realiza en un par de servidores.

Por lo visto, el primer punto depende del proveedor del ESB, porque algunos ofrecen funciones de workflow/BPM que estaban separadas en la epoca EAI.

El segundo punto es correcto con la incarnación actual de los ESB. Apuesto si, que XML va a ser un poco menos usado.

El tercer punto, también depende del proveedor. La tendencia actual es modularizar el ESB de tal forma de poder configurarlo de distintas formas: desde una API dentro de una aplicación Java o como un motor sobre el cual desplegar aplicaciones. OSGI es el método usado para modularizar en ServiceMix, OpenESB versión Fuji y Spring Integration. En el caso de Oracle, la configuración natural seria estrella, principalmente por el costo en licencia y en recursos (CPU, memoria) de instalarlo en forma distribuida.

Confusión #4: ¿JBI es un estándar relevante?

Me gustan los estándares, pero si ningún proveedor importante los implementa no sirven de mucho. IBM nunca soporto JBI y tampoco Weblogic. Oracle lo soporto al principio pero no paso nada concreto. Sun  parecía muy solo con el tema JBI y lo habría dado por muerto.

No obstante, hay ahora 2 implementaciones Open Source de JBI, la de Sun, OpenESB y la del grupo Apache/IONA, ServiceMix. El estándar tiene un efecto bastante positivo: la compatibilidad. Un ejemplo, es que se puede correr Apache Camel, el cual es el broker de ServiceMix, como un Service Engine de OpenESB. Si logran intercambiar más adaptadores (Bindings Components en JBI) y otros Service Engine, se puede crear un mercado interesante.

Finalmente, el estándar en si es bueno porque es claro y acotado. Se puede criticar que es más orientado a fabricantes de soluciones de integración y BPM que para el programador. Creo que es una ventaja, porque todavía no esta definido cuales son las mejores soluciones, lenguajes, patrones, técnicas de programación, interfaz de diseño, para cada Service Engine. Por ejemplo, habrían podido obligar el uso de BPEL para un Service Engine de BPM: me alegro que no lo hayan hecho.

Confusión #5: ¿BPEL sirve de algo?

Siempre me resulto estredamente curioso que un lenguaje hecho para BPM no tenga capacidad de incluir tareas humanas: no conozco a ningún proceso de negocio donde un humano no tenga que intervenir. Casi seguro que el más automatizado de los procesos tiene condiciones de borde como errores, excepciones donde un humano tiene que hacer algo. No haber incluido este tema desde la versión 1.0, me parece muy poco serio. De hecho, la adopción fue muy lenta en los motores de workflow y muchas veces es solamente para cumplir con decir “cumplimos con el estándar pero recomendamos usar otra solucion” como por ejemplo jBOSS jBPM.

Al mismo tiempo, veía más adopción por proveedores de brokering de mensajes (EAI tradicional), a pesar que la literatura no recomienda usar BPEL para eso. De hecho, la versión actual de OpenESB usa BPEL para rutear mensajes/tareas. Al parecer pasa lo mismo con Oracle ESB donde para hacer ruteo algo complejo hay que usar BPEL.

Mi impresión es que BPEL quedo entre medio de 2 mundos y no hace ninguna cosa bien. Además viene con todo la herencia XML donde no se puede hacer nada simple.

Veo que Sun opina lo mismo, porque en su versión Fuji, han creado un DSL llamado Integration Flow Lenguage que reemplaza BPEL como ruteador de mensajes.

Confusión #6: ¿Los ESB se justifican fácilmente?

Las herramientas EAI eran muy costosas en licencia, tiempo de aprendizaje y puesta en marcha. Se necesitaba un volumen importante de sistemas a integrar para justificar la inversión.

Los ESB usan estándares y algunos son OpenSource gratuitos. Eso reduce significativamente la barrera de adopción. No obstante no la elimina por completo.

He usado productos que requieren una curva de aprendizaje similar. Tanto Magnolia como Web CMS y Alfresco como CMS de gestión documental, me demandaron 3 semanas para ser relativamente eficaz. Al hacer la primera página Web con Magnolia, recupere esta inversión. Al hacer el primer flujo de aprobación documental con Alfresco  también. Eso era debido que implementar desde cero estas funcionalidades me habría requerido bastante más esfuerzo.

No pasa lo mismo con un ESB: yo puedo fácilmente usar Java EE para leer archivos, transformar formatos, conectarme a bases de datos y colas de mensajes. Para que sea rentable el aprendizaje debe haber más de una necesidad de integración. La barrera esta bajando pero sigue vigente.

¿Como convencer que es tiempo usar Scala en lugar de Java?

Argumente en una entrada previa que se vienen nuevos tipos de aplicaciones que van a requerir cambios de arquitectura de software, o sea, cambios en los lenguajes y los middleware como servidores de aplicación y bases de datos.  Tengo la suerte ahora de participar en un proyecto asi: es de tipo CEP (Complex Event Processing) y podre usar Scala DSL de Apache Camel.

Esta bien, pero no es suficiente.  Quiero también usar Scala en proyectos web más tradicionales, porque no es todos los días que tengo la suerte de participar en proyectos realmente innovadores.  Por ejemplo, ahora mismo, estoy terminando un proyecto con J2EE 1.,4, Struts y EJB 2.0 para un cliente bastante conservador.  Pensando en este proyecto y el tipo de profesionales con los cuales tuve que interractuar, tengo que aprender a convencer que es el momento de mirar soluciones no 100% basadas en Java y JEE.  

Buscando lo que dicen los pundits en internet me encontré con este articulo de Bruce Eckel.cuyas conclusiones me hacen sentido: 

• Java llego en una etapa donde agregar nueva sintaxis como "closure", va a costar de vez en más . "...the adoption of new Java versions and features is going to continue to slow"
  
• La JVM y sus toneladas de bibliotecas van a ser heredadas por otros lenguajes. "The JVM will be the most important legacy that Java contributes to the computing world. "
• Scala y Groovy estan al acecho para re-utilizar la JVM y sus bibliotecas. "...Scala and Groovy (which play well with Java right out of the box)..."
  
• Hay Java para rato.   "Java itself will continue to be a core workhorse, just as C++ has been..."

No obstante, no estoy completamente de acuerdo en como Bruce fundamenta estas conclusiones. El hace una serie de criticas sobre Java y el rol que cumple Sun de las cuales algunas no son 100% justificadas o otras no son tan graves.

• el mensaje principal es que no se puede confiar en una organización con fines de lucro.  Es probable que si no había existido la necesidad de contrarrestar el dominio que tenia Microsoft sobre los desarrolladores, Sun no habría regalado su lenguaje e IBM no lo habría adoptado con tanta facilidad.   Entonces, compro este argumento pero solamente en parte, porque:
• existe muchos contra-ejemplo de lenguajes que no fueron apoyados por grandes empresas y que tampoco llegaron a un buen destino.  Perl es el primero que me viene en la mente.
  
• esta en las manos de los desarrolladores hacerse desear por las grandes empresas de TI.  Mientras no exista una sola tecnología dominante y que exista competencia por conquistar nuestro interés, estamos bien.

• no haber incluido closure y programación genérica desde el principio.  A mi, me parece una buena decisión de Sun haber aprovechado el boom de la internet.  Un año más tarde habría pasado la vieja, nadie habría sabido de Java y capaz que estaríamos criticando Visual Basic.

• haber mantenido compatibilidad hacia atrás cuando implementaron la programación genérica.  Me parece super razonable la decisión de Sun. Además, la programación genérica es muy practica para usos simples y la eche de menos en mi proyecto J2EE 1.4.

• No se cumplió a 100% el WORA (la portabilidad del binario Java).  Mi experiencia es que un proyecto razonablemente bien hecho es super portable.  En eso, Java esta muy encima de cualquier otra tecnología, incluyendo estándares como SQL, HTML, CSS y Javascript. 

• Implementación en Java de algunas funciones en punto flotante en lugar de usar el coprocesador.  OK, quizás para algunas rutinas matemáticas afecta un poco pero, la semana pasada vi una demo de un software de predicción estadístico con visualización en 3D. Estoy seguro que este software usa muchos cálculos en punto flotante y estaba hecho en Java/Eclipse RCP.  Al agua el argumento excepto para aplicaciones realmente fuera de lo común.

• Finalmente, Bruce termina argumentando que Python es la raja.  Quizás tenga razón, pero Python es más antiguo que Java y solamente orientado al objeto.  Yo creo que se necesita ideas realmente nuevas como la fusión de la programación funcional y la orientación al objeto para realmente dar un salto interesante.

Entonces, no me queda más que buscar otros argumentos.  Parece que va a ser difícil.

Evolución de los servidores de aplicación

Un tipo de SpringSource tiene un articulo muy interesante sobre la evolución de los servidores de aplicación.  SpringSource tiene un talento para hacerme reaccionar en forma negativa y no tengo una admiración incondicional por Rod Johnson .  Entonces, si estoy recomendando leer este articulo es porque lo encuentro realmente bueno.

Antes de propagandar su propia solución, el autor llega a la siguiente conclusión:

A new breed of application server is emerging. This new application server has a small, in-memory footprint. It starts fast and runs fast. It has a highly modular architecture and it can host a variety of services and domain-specific containers. It can respond to directives from a "grid controller" and it can provision, deploy, start, stop and tear down services on the fly. It runs efficiently in an elastic topology that may span heterogeneous physical hardware and virtualized hardware.  

En español:

• los servidores de aplicación se usan ahora para algo más que aplicaciones web dinámicas.  Por ejemplo, algunos productos ESB se montan sobre un servidor JEE para usar el manejo de transacción, la gestión de conexiones SQL/colas JMS, la administración vía JMX/consola Web, etc.  Estos ESB se programan con lenguajes no Java como BPEL, XPath, XSL o algún lenguaje de enrutamiento y enriquecimiento de mensajes propio.
• Un cluster con un número constante de servidores ya no es suficiente.  Se necesita soluciones "elásticas" donde una aplicación puede desplegarse automáticamente sobre nuevos nodos cuando crece su uso y decrece su SLA.  Al contrario, cuando baja el acceso a la aplicación, el sistema controlador de la grilla desactiva la aplicación para dejar más recursos a las demás.

Todo bien, pero no puedo dejar de criticar un poco el articulo, para no perder mi costumbre cuando se trata de SpringSource.

• habría sido bueno que el escritor diga desde el principio que trabaja para SpringSource.  Al principio, creí que era otro apostole de Rod, porque usaba el argumento liviano versus pesado de una forma super marketera.
• a pesar que estoy 1000% de acuerdo que la suite IBM Webpshere es la campeón de la pesadez. hay que señalar que lo que esta logrando SpringSource ahora, IBM lo tiene desde hace 3 años con productos como Webpshere ESB y Websphere XD.  Algunas veces, el pesado le gana al liviano y me parece suicidio dejar 3 años de ventaja a la fuerza de venta de IBM.

El futuro de las bases de datos SQL

Martin Fowler opina que vamos a ver cambios en el mercado de bases de datos.  Ver también el reporte en Infoq.

Su argumento central es que no necesitamos más a las bases de datos para integrar la información de una empresa.  Eso se debe que existen otras tecnologías (XML, Web Service, REST, JMS) que facilitan la integración entre aplicaciones y reemplazan a SQL.  

Es cierto que era una practica en la época cliente-servidor tratar de consolidar todas las tablas en un solo motor de base de datos, porque facilitaba hacer joins entre las tablas de las distintas aplicaciones.  La otra opción era conectar varios motores entre si, con facilidades de store-procedure remotos y SELECT remotos.  El hecho de tener un lenguaje estándar como SQL hacia fácil estos tipos de solución.  Entonces, para variar Martin tiene un buen punto,

La lógica de negocio se fue de los motores SQL hacia los servidores de aplicaciones y como lo menciona Martin la capa de integración también.  Hay una oportunidad de mirar por el lado para ver si hay algo mejor que SQL en algunos casos: SQL ya no manda el mundo TI como solía hacerlo.

No puedo ser indiferente con SpringSource

SpringSource compro G2One, lo cual es un evento suficientemente significativo para mover la blogsphere JEE y llenar foros de conversación.

Las distintas opiniones que aparecieron en esta entrada en TheServerSide  me permiten hacer como un checklist de los temas que ya toque en mi blog y poder compararlo con lo que opinan los miembros de TSS.  

Primero tengo que mencionar que TSS sigue un lugar para peleas entre representantes/fanáticos de jBoss y SpringSource.  En esta oportunidad, Rod Johnson se quedo callado y es Bill Burke de jBoss que fue al ataque.  Pero Spring tiene suficientes fanáticos para evitar que el guro tenga que intervenir.

Ahora, voy tema por tema.

Lightweight vs Heavyweight  

Bill Burke ataco a Spring por ser heavyweight, pero tuvo la mala idea de justificarlo solamente por el tamaño (80 MB) de los binarios de Spring.  Una de las respuestas razonables fue que la pesadez debe medirse con el impacto sobre el diseño de la aplicación.  

"lightweight has nothing to do with the dependency size, rather at how it impacts your application's design and its constraints."

Yo sigo opinando que la pesadez es un termino ambiguo que puede/debe medirse de varias formas:

• estoy de acuerdo con Bill, el tamaña si importa 
• si el contenedor tiene que cargar 80 MB de clases además de la webapp, la partida se va a ver afectada,
• IBM Rational Developper pesa 3.5 GB.  Netbeans con Glassfish pesa 200 MB, es tremenda diferencia para mi ADSL banda estrecha.

• estoy también de acuerdo con Bill, que Spring ahora es heavyweight porque trata de solucionar todo y es funcionalmente tan amplio como los contenedores JEE que lo precedieron.  Eso impacta por ejemplo, el aprendizaje necesario para conocer cada uno de los "Spring-*" y compararlo con otra solución: yo ya he abandonado esta tarea y me quedo con Google Guice por ser liviano y limitado en su alcance (DI y nada más que DI).

Los frameworks de DI son un accidente transitorio 

Nuevos lenguajes como Scala y Groovy los hacen menos relevantes:

"I've been waiting for people to realize that a good, concise dynamic language that provides clean integration with Java largely obviates the need for DI containers and/or allows for much more powerful approaches to DI containers. "

El uso de anotaciones en JEE 5 alivia el desarrollo y reduce la importancia de framework DI.

"Now what is Spring's contrbution to the platform..um... lets see... 

1. A wrapper which is possibly useless with JEE6"

"I love SpringSource's products, but I find them much less needed today than five years ago. RIP, my love! "

Ataques constantes a SUN 

La noticia no tiene nada que ver con SUN pero igual salio al baile:

"Have you been sleeping? Sun is lost in the weeds looking for an OSS strategy...Who better to run with the torch than Spring?"

De nuevo, aparece el tema OpenSource y encuentro increíble que ataquen a Sun por eso.  Antes de cambiarse a OpenSource, la suite Java de SUN estaba completamente inutilizable y moribunda.  Ahora, quizás SUN no gana directamente con su suite de software pero, por lo menos tiene una completa y competidora con IBM, Microsoft, Oracle, Red-Hat, Google.  Es algo estrategico para enfrentar el mercado de "cloud-computing" que viene.  Por otra parte, Solaris esta bien posicionado para aprovechar la explosión del multi-core, lo que dudo que Linux haga con tanta facilidad.

Existe también la preocupación constante por el estado financiero de SUN, la cual comparto a 100%.  De hecho, si los productos no fuesen OSS, no los recomendaría: hay un riesgo no menor que SUN sea comprado por otra empresa y que cambie radicalmente el futuro de sus software.  El hecho que sean OSS los protege de este punto de vista.

Rol de Rod Johnson y SpringSource en la estandarización de Java

Algunos prefieren que SpringSource sea el líder de la estandarización de Java.  Menos mal que hubieron respuestas bastante claras como por ejemplo:

"The idea of Spring taking stewardship of Java is crazy talk. Looking after Java requires theoreticians (e.g. Gilad), compiler experts, Swing and graphics experts, lots of maintainers and bureaucracy and much, much more. i.e. you need deep pockets and an iron stomach for these things"

"Say what you want about JBoss, but at least we've shared our IP with the Java community by bringing both Hibernate and Seam to a standards body. Then, if our business practices offend you for some reason, you can always move to another implementation. You can't say the same thing about Spring."

"That's a good point. SpringSource doesn't seem to be sharing Spring in JCP in a direct fashion that JBoss has with Hibernate(JPA) and Seam(Web Beans). "

En resumen:

• SpringSource es una mosca en comparación de SUN y se necesita espalda para cumplir este rol.
• El aporte de SpringSource a la estandarización ha sido casi nula hasta ahora.
• jBoss ha aportado mucho más que SpringSource al proceso de estandarización: JPA (Hibernate), WebBeans (Seam).

Finalmente, Bill Burke acusa a Rod Johnson, el cual es miembro reciente del JCP, de bloquear avances significativos de la plataforma.

"...this is exactly how Rod positions himself in the EE JSR and pretty much fights against any forward movement of the platform. "

Si se confirma este tipo de acusación, pasare Rod Johnson de anti-héroe a super villano.

Evolución de los framework MVC

La compra de G2One confirma la tendencia de usar lenguajes más concisos para la capa web en lugar de un framework Java.

Opino lo mismo, pero creo que no debe limitarse a la capa de presentación y Groovy tiene, a mi gusto, sus limites en otras capas.  También, opino que la cercanía a Java como la que tiene Groovy y Scala son factores importantes para la adopción.

En resumen, fui una buena entrada en TSS.  Polémica quizás, pero entretenida.

SOA es el futuro

Esta gráfica lo resume todo.

No obstante, si quieren leer un poco más, pueden ver estos comentarios sobre un reporte de Gartner.

Framework web en el mundo Java

Para los framework ORM, la guerra ya terminó y JPA ganó. Hay que recordar que no hace tanto, habían muchas soluciones para la capa de persistencia entre los cuales estaban los EJB Entity Beans, Hibernate, JDO y JDBC directo. Ahora todos están de acuerdo que JPA cumple 90% de las necesidades.

En el caso de los framework web, la guerra sigue vigente y es entretenido seguir el avance de las batallas y tratar de pronosticar el vencedor. Además, me permitirá explicar porque, a pesar de mi entusiasmo por soluciones estándares, estoy involucrado con Liftweb y Scala.

Voy a hacer primero un recorrido por las soluciones que conozco. Nota: no pretendo conocerlas todas.


Servlet y JSP

Eso es el equivalente de usar JDBC Directo en un ORM. Su gran gracia es su simplicidad, la cual es equivalente a la de usar PHP. Por esta razón, lo elijo si tengo que hacer una aplicación para un contenedor Java antiguo y si el cliente no obliga usar un framework X.

Su principal problema es que no obliga que la aplicación sea de tipo MVC y hay que ser disciplinado para no caer en código inmantenible. Para proyectos grandes, con muchos programadores de distinto nivel de conocimiento, no es una buena solución.


Struts

Struts corrige el problema anterior forzando ordenar el código. Yo encuentro que el costo es demasiado alto, muchos conceptos, muchos XML y archivos de propiedades: un "hello world" no puede ser tan complicado. Por eso considero Struts como uno de los responsables de la sensación de pesadez del mundo Java: en particular cuando la critica viene de un programador PHP.

Struts sigue bastante popular y Struts2 esta en la pelea: espero que no gane.


JSF

Los que critican el proceso de estandarización de Java tienen en JSF una víctima clara a la cual lanzar sus dardos. Las principales criticas que me hacen sentido son:

• sobre ingeniería: JSF tiene muchos puntos de extensión, que agregan mucha complejidad como por ejemplo los renderer.
• orientarse a los fabricantes de IDE y de componentes: "no importa si hay que tocar muchos XML porque el IDE se encargará". Desgraciadamente, eso se cumple a media.
  
• mantener compatibilidad con JSP. Eso creo un caos inicial donde había un EL para JSF muy similar pero distinto al de JSP y pasaba cosas raras cuando se mezclaban tags JSTL con los de JSF.

La gran gracia de JSF es su modelo de componente. Si se busca la eficiencia de desarrollo al estilo de Visual Basic/PowerBuilder de la epoca cliente-servidor hay buenas opciones de bibliotecas soportadas en IDE. Por ejemplo, Woodstock de Sun permite un desarrollo Wysiwig con Netbeans.

Ojo, que una vez que se elije una de estas soluciones, esta trabajando con un JSF "con apellido":

• el runtime de estas bibliotecas no soportan siempre las implementaciones de JSF (principalmente la de Sun y la de Apache). Eso implica que puede haber también problemas con el contenedor, si este viene con una de estas dos implementaciones.
  
• dependen de un solo IDE o de un plug-in para un IDE,
• suelen ser incompatibles con otras bibliotecas para JSF. Este ultimo problema se da mucho con las que soportan AJAX.
• la mayoría usan tags y dejan fuera la posibilidad de usar facelets en lugar de JSP.
  

Entonces, antes de casarse con una biblioteca y su IDE respectivo, hay que hacer una buena evaluación. Como no hay estandarización de esta capa, la gracia de tener un estándar para JSF se diluye: eso implica que puedo mirar por el lado a pesar de mi aprecio a soluciones estandarizadas.

Como hay varios proveedores interesados en mejorar JSF, no creo que este muerto. SI logran más simplificación y compatibilizar sus bibliotecas, seria un salto importante para crear el mercado tipo Visual Basic tan anunciado y esperado.


Wicket

Wicket.es distinto. Al abandonar JSP y sus taglibs, lograron separar por completo los artefactos HTML, CSS del código Java. Por otra parte, dice adiós a archivos de configuración en XML Son razones más que suficientes para atraer la atención.

Además, tiene una biblioteca de componentes importantes con soporte AJAX out-of-the-box y es relativamente fácil crear componentes propios (lo cual es ahora difícil en JSF 1.x). De hecho, JSF 2.0 reconoció estas ventajas y anuncia soporte oficial para facelets (¡al fin!) y métodos para crear componentes propios.

Yo recomiendo usar Wicket para proyectos web en Java.


Seam

No se puede comparar Seam, con los frameworks anteriores. De hecho incorpora JSF y ahora soporta a Wicket como opción.

Lo menciono aquí porque:

• logran la integración de las distintas capas de la aplicación.
  
• están aportando a los estándares de Java con la especificación WebBeans (nota aparte: ¡SpringSource aprenda de jBoss si quieres ser un vendedor ético!)
• marca una tendencia en los frameworks: una solución más integral con AJAX, REST, generación de PDF, page workflow, etc.
  

Si tuviera que usar JSF, porque un cliente me lo pide, trataría de usar o por lo menos ser compatible con Seam. Además, gracias al nuevo soporte de Wicket, vamos a poder incorporarlo en nuestros desarrollos Java.


Soluciones RIA en lugar de framework web

Se puede usar un cliente RIA y conectarse al servidor via REST o Web Service. En este caso, desaparece el framework web casi por completo.

Es una posibilidad pero la encuentro improbable: un framework web con una buena biblioteca de componentes AJAX es más simple.


Soluciones no Java

Con el soporte de muchos lenguajes sobre la JVM y los servidores de aplicación, es perfectamente posible usar otro lenguaje con su respectivo framework, para la capa de presentación llamando la lógica de negocio en Java. Por ejemplo, Netbeans permite desarrollar con Groovy/Grails, Ruby/Ruby On Rails y PHP haciendo el deploy sobre servidores de aplicación JEE. Para no mencionar solamente productos de Sun, se puede hablar de:

• el Project Zero de IBM (a pesar que no me queda claro si puede invocar código Java)
• el soporte PHP de Resin con Quercus. Drupal es 4 veces más rapido sobre Resin que sobre Apache. Sun Glassfish y Oracle Weblogic usan Quercus en modo interpretado para soportar PHP

Creo que esta tendencia va a seguir y es el camino que yo escogí al probar Scala y Liftweb. Y veo el futuro cada vez mejor:

• los programadores top de Liftweb están trabajando para mejorar el soporte JPA,
• los plug-in para Netbeans y Eclipse esta mejorando.
• me da la oportunidad de crear componentes y hacer un tipo de desarrollo que no hacia desde mi época en lenguaje C sobre MS-DOS: me hace sentir bastante más joven.

Conclusión

No creo que la guerra este cerca de terminar. El impacto de AJAX y RIA son factores importantes. Por el momento, voy por el camino Wicket (incorporando pronto Seam) cuando estaré ligado a Java y Scala/Liftweb cuando tendré más libertad.


Update 10 de Noviembre 2008: cambios menores de redacción

Update 12 de Noviembre 2008: otro cambio de redacción y mencionar que SpringSource apuesta fuertemente a Groovy/Grails.

Update 22 de Noviembre 2008: solamente mencionar esta conversación extensa en TSS sobre el mismo tema.