Barrapunto

La Web 2.0 es una moda y Java durará siglos así que no me preocuparía demasiado por el artículo.

Java es un lenguaje que te permite hacer cualquier cosa, y J2EE una plataforma que incluye muchas APIs, a veces incluso demasiadas.
Lo que entra en conflicto es web1.0 con web2.0, pero usando java EE se pueden hacer perfectamente aplicaciones web2.0. Incluso con mayor robustez y productividad que con otros lenguajes.
En las soluciones que propone el artículo no se comenta la que más me gusta a mi: JBoss Seam [jboss.com]. Un framework que dará mucho que hablar. Me encanta el nuevo concepto de scope conversation, es sencillamente genial.

Pero los principios sobre los que Java EE fue diseñado no soportan la Web 2.0 eficientemente.

HTTP tampoco fue diseñado para soportar la Web 2.0 eficientemente, y ahí sigue...

... pero, el artículo, en resumen, ¿viene a decir que para montar un puto foro o un blog no hace falta liar la de dios con entity beans, enterprise beans, transacciones y toda la parafernalia esa que al final no vale ni para tomar por...?

Eso los más viejos del lugar lo llevamos pensando desde hace tiempo. Pero es que venimos del C, cuando un programa hacía lo estrictamente necesario y no se perdía en chorradas arquitecturalmente esotéricas.

La traducción adecuada es "impedancia de fase". Y es una metáfora. Puedes encontrar "metáfora" en el diccionario.

Pues ya sabes, la impedancia es la combinación de resistencia y condensador o bobina, y determina la relación entre voltaje y corriente... Alguien se ha confundiado de palabro, opino.

El tema no es el Web 2.0 sino el modelo de sincronismo entre los servicios que se producen en la Web 2.0.

En "Web 1.0" el esquema peticion - proceso - respuesta es claro, y es el mismo que sigue Seam, Shale, y cualquier otro modelo actual.

El Web 2.0 en cuanto a "java" se refiere es un modelo de trabajo Asíncrono con cualquier forma de leer / escribir información en cualquier buffer. No se trata de que el cliente mande peticiones cada X tiempo, sino de que los propios "servicios" (lease servlets) puedan devolver Future (objetos futuros) directamente al cliente, o que pueda "suspender" una request para continuarla cuando sucedan otros hitos...

No sólo afecta a Java sino a cualquier lenguaje de servidor que sirva "cosas" para web (en general). SOAP asincrono ("he terminado de procesar tu petición") no es posible en un marco generalizado, no forma parte del estandar general (existen otros estandares para ello).

El impulso que hay que dar al Web 2.0 está ahora en manos de los servidores. Cuando "existía" el Web 1.0 tardó tiempo en aparecer un API de servidor para agilizar el desarrollo de las aplicaciones, y lo mismo está sucediendo con el Web 2.0.

Simplemente, tiene que quedar un poco claro que Seam no procesa peticiones asíncronas, se sigue enviando una petición y se devuelve una respuesta.

De todos modos, llevo 4 meses sin trabajar/seguir SEAM (igual ha cambiado algo) y aún estoy esperando al JSR 196 que conseguirá que ocurra con SEAM lo mismo que con Hibernate y Spring, que sean "adoptados" -lease copiados- dentro del API estándar.