18/05/2009
02/06/2009
18/06/2009
He publicado un artículo en CometDaily.com sobre cómo programar aplicaciones Comet con ItsNat.
En una primera parte se plantean los dos enfoques fundamentales a la hora de programar una aplicación AJAX/Comet:
1) Céntrico en el cliente (frameworks JavaScript)
2) Céntrico en el servidor (JSF/IceFaces como ejemplo)
El enfoque de ItsNat es de una tecnología centrada en el servidor pero con un estilo de programación similar a la forma de programar en el cliente.
La segunda parte expone las dos técnicas de programación Comet en ItsNat: polling (AJAX timers) y long polling, así como un par de ejemplos de código fuente.
Este artículo es la continuación del artículo Introducing ItsNat, a New Java-based Comet Tool publicado anteriormente.
Etiquetas: j2ee, comet, cometdaily, itsnat, ajax, web
Saludos,
Me disgusta que una noticia como esta tenga tan pocos comentarios, y mas cuando las ideas que se exponen son interesantes.
No se si nadie se ha planteado crearse su mini-framework para simplificar la programación posterior, o entender como un framework funciona por dentro.
Tenemos en España (y en general en el mundo hispano) gente como Jose Maria Arranz o Javier Paniza por citar dos ejemplos que han desarrollado su propio framework.
Desde luego, poder alcanzar el nivel de conocimientos adquirido por el autor de un framework es difícil, pero ahí queda su trabajo y esfuerzo para el beneficio de todos.
Tenemos que intentar que este conocimiento llegue de manera eficaz y que no nos deje indiferentes, o por contra nos deja impotentes y no sabemos que decir.
A ver si alguien se anima y se plantea un curso de ItsNat para principiantes, a modo de lecciones entregables en este foro (lo mismo le planteo a Javier Paniza aprovechando esta noticia que le es un poco ajena).
Bueno, con esto animo a Jose Maria que nos deleite con mas noticias de ItsNat.
Gracias.
Eduard Escrihuela
Se nota que eres un poco nuevo por aquí :)
No pasa nada porque no haya comentarios, a veces sencillamente no hay nada que decir. Por otra parte ItsNat es una tecnología "relativamente" nueva y por tanto con pocos interesados y que no tiene a un Goliat de la industria detrás. Javier Paniza y yo en cierto modo somos dos David frente a varios Goliat... pero no será la primera vez que un Goliat haya sido vencido :)
Respecto al curso para principiantes, casi todo lo que publico está en inglés. Aparte de la documentación oficial y los artículos de CometDaily, puedes echar un vistazo a esta entrevista en JavaLobby que incluye el ejemplo del tutorial oficial algo recortado.
Si hay demanda puedo traducir a español los artículos de CometDaily, pero sólo si hay demanda (y no hay problemas de copyright).
Por otro lado, el concepto de Comet, aunque atractivo (Es básicamente cliente/servidor de toda la vida), no me atrevo a utilizarlo. Trabajo para una gran empresa y hay entre lod navegadores y los servidores, firewalls, proxys,y mil cositas de ese tipo, y eso de dejar la conexión abierta, me da que me iba a dar muchos problemas.
La técnica polling es un timer AJAX, desde el cliente se envía una request via AJAX con una frecuencia dada (sin retenerla) para traerte posibles cambios respecto a la anterior petición, si no te funciona es que con toda probabilidad el uso normal de AJAX tampoco te funciona.
La técnica "long polling" también usa AJAX aunque ciertamente de forma diferente, reteniendo la conexión. Pero retener la conexión es simplemente hacer que la petición AJAX "dure mucho", es decir esencialmente no hay ninguna diferencia entre una petición AJAX que se queda retenida esperando alguna novedad en el servidor, que una petición AJAX que dura mucho porque la consulta a la base de datos o lo que sea es muy lenta. Es posible que tengas el problema de los timeout, y es cuando "alguien" (el navegador, el servidor, algún proxy etc) "se cansa" y corta la conexión por timeout. Los timeout se pueden evitar liberando la request desde el servidor con una frecuencia dada aunque no haya nada que hacer en el cliente. En ItsNat sería llamando a notifyClient de vez en cuando, se liberaría la conexión y se habriría otra de nuevo por lo que la cuenta de los timeout se reinicia, en cierto modo sería un long polling con algo de polling pero ordenado desde el servidor.
Lo que quiero dar a entender es que si los firewalls, proxies etc hacen fallar el Comet casi con toda probabilidad te va a fallar el AJAX normal y corriente. Hay otras técnicas de Comet (forever frame AJAX streaming etc) que no son request AJAX normales y ahí no me mojo porque en general son más problemáticas (aunque en teoría pueden ser más eficientes que el polling y el long polling), ItsNat concretamente no las usa.
Uy perdón por el "habriría" ... argg que vergüenza :(
Yo el Comet lo veo útil en aplicaciones, normalmente tendiendo a intranet, donde la relacion de usuarios/interactividad sea favorable. Por que si no, dejar las conexiones abiertas durante largo tiempo, de una forma u otra, puede dar problemas de quedarse sin recursos rápidamente.
Pero siempre es bueno tener esas opciones por si te encuentras en un caso en que lo necesites.
En cuanto a lo de la falta de comentarios... hay un poco de todo. Por un lado la comunidad hispana no destaca precisamente por su espíritu colaborativ, en relación a su tamaño, y por otro pues hay poca gente que se meta en temas tan específicos por una noticia y entonces como dice Jose María, hay poco que decir. Yo no llego ni a David por que no salgo ni mencionado en los ejemplos jejeje pero bueno, tampoco es tan raro por que ni siquiera intento promocionar el framework.
Hombre greeneyed cualquier sistema admite miles de conexiones, miles de hilos y tiene varios Gb de memoria, no todo servidor es un eBay (que más quisiera), para que una aplicación Comet sature el servidor no sólo tiene que haber montones de usuarios sino también una frecuencia de actualizaciones bastante grande.
cualquier sistema admite miles de conexiones, miles de hilos y tiene varios Gb de memoria
No lo he entendido bien, ¿eso es coña? No digo que no se pueda configurar un sistema para eso, pero de ahi a que todos lo puedan hacer así como así... o que sea necesario... El Apache que tenemos nosotros para todas nuestras aplicaciones y paginas web da servicio con un max. de 150 conexiones simultaneas. En hora punta de mes punta tenemos un par de miles de sesiones simultaneas en una sola de las aplicaciones, si eso lo tuvieramos a pasar a conexiones simultaneas... pues no digo que no se pueda, pero si no es nececesario...
Precisamente el problema de Comet es que mantiene la conexion mas allá del intercambio de información, y por eso satura más con menos usuarios. Igual que el keep-alive de HTTP1.1 etc. etc.
No digo que no se pueda usar o que consuma todo lo consumible, sólo digo que no lo veo como una solución general para Internet y que consume bastante más que no usarlo.
Yo ya le encontre un uso al Comet que de otra forma no se podria haber hecho o seria muy muy ineficiente.. Estoy desarrollando un ERP usando ICEfaces (comet centrico en el server) y hay usuarios que facturan articulos y hay otros usuarios en tesoreria (o caja) que autorizan esas facturas. Normalmente estos usuario de Tesoreria mantienen su ventana de autorizacion siempre abierta y lo ideal seria que cada vez que alguien facture algo ellos automaticamente puedan ver la(s) nueva(s) facturas por autorizar sin necesidad de hacer nada, osea que el sistemas les avise sin estar pendientes de dar click en algun boton refrescar o algo parecido.
Con el soporte de Comet de ICEfaces pude hacer eso en un dos por tres sin el mayor esfuerzo y lo mejor es que las cosas se muestran unicamente cuando se deben mostrar. Una alternativa sin comet podria haber sido colocal algun codigo javascript que se ejecute cada tanto tiempo para actualizar eso, como los clasicos timer de javascript. Pero en un lugar de ventas la llegada de clientes nunca es ni sera constante, y esto ocasionaria que en tiempo muertos (nadie factura nada) tuviera varios procesos ejecutantose quien sabe cuantas veces al dia, sobrecargando la BD con tantas peticiones. En mi caso el uso de Comet centrico es la mejor opcion para resolver ese problema. Y pensandolo bien se me acaban de ocurrir otros casos parecidos donde tambien seria una muy buena opcion.
Esto del comet tienen la gran ventaja de hacer aplicaciones colaborativas porque permite (al fin) tener una arquitectura cliente/servidor real de doble via donde el server puede avisar a sus clientes que algo paso por alguna razon y al mismo tiempo usar todas las buenas tecnologias que existen para hacer aplicaciones web.
Pensando en el caso de IsNat en general, he pensado mucho ultimamente en este framework, he llegado a la conclusion de que por si solo IsNat es un framework de "bajo nivel" precisamente por el hecho de poder manejar el DOM directamente y desde el server. Y por ser un framewokr de "bajo nivel" se podrian construir sobre el frameworks de alto nivel para usuarios que simplemente quieren usar cosas abstractas y simples para hacer su aplicacion. De hecho jmarranz ya lo esta haciendo al crear un set de componentes visuales para GUIs, habra que ver como evoluciona todo y creo jmarranz que deberias centrar un poco mas la publicidad o propaganda que hagas de IsNat en cosas de alto nivel, porque por ejemplo en mi caso, nunca me interesaria meterme a manejar ningun DOM ni nada de eso, yo hiria directamente por el set de componentes y que tan facil y simple seria utilizarlos. Bueno eso solo es mi opinion xD
Con el soporte de Comet de ICEfaces pude hacer eso en un dos por tres sin el mayor esfuerzo y lo mejor es que las cosas se muestran unicamente cuando se deben mostrar. Una alternativa sin comet podria haber sido colocal algun codigo javascript que se ejecute cada tanto tiempo para actualizar eso, como los clasicos timer de javascript. Pero en un lugar de ventas la llegada de clientes nunca es ni sera constante, y esto ocasionaria que en tiempo muertos (nadie factura nada) tuviera varios procesos ejecutantose quien sabe cuantas veces al dia, sobrecargando la BD con tantas peticiones.
¿Y en los tiempos muertos Comet no hace nada y no consume nada? Por otro lado, teniendo en cuenta que muchos sistemas Comet utilizan Long Polling... de eso al Polling, que es lo que tu describes, sólo hay una palabra ;).
permite (al fin) tener una arquitectura cliente/servidor real de doble via
Yo mas bien diría emular, como suelen decir las definiciones de Comet, ya que en realidad no es una arquitectura bi-direccional real.
Y lo de las desventajas no me lo estoy inventando yo. No es que sea la enciclopedia, pero...
http://en.wikipedia.org/wiki/Comet_(programming)#Problems
S!
greeneyed: No digo que no se pueda usar o que consuma todo lo consumible, sólo digo que no lo veo como una solución general para Internet y que consume bastante más que no usarlo.
Bastante de acuerdo, de hecho en general cualquier aplicación de gran público no necesita de Comet. Pero el ejemplo que ha puesto Marioko es muy bueno, el típico caso de un usuario que necesita saber en tiempo real que cambios hay en el sistema. Un ejemplo interesante de Comet es la "fisgona" de meneame.net imagino que usando "polling" (temporizadores AJAX):
Es ese tipo de aplicaciones las que abre el mundo Comet.
Yo también voy a recurrir a la Wikipedia:
http://en.wikipedia.org/wiki/Native_POSIX_Thread_Library
----------
The Native POSIX Thread Library (NPTL) is a software feature that enables the Linux kernel to run programs written to use POSIX Threads fairly efficiently.
In tests, NPTL succeeded in starting 100,000 threads on a IA-32 in two seconds. In comparison, this test under a kernel without NPTL would have taken around 15 minutes. [1][2]
---------
Cuando hablaba de los miles de hilos y conexiones que pueden abrirse en cualquier máquina "sin problema" quería dar a entender que el problema de la saturación de un servicio de ese tipo no viene por ahí sino más bien en cosas como la base de datos, la misma frase expuesta como "se pueden abrir miles de consultas simultáneas a la base de datos" no es cierta.
La saturación del servidor vendrá antes por ahí que por Comet, ahora bien te doy la razón de que una aplicación con Comet esencialmente mantiene un estado en el servidor lo cual es siempre más costoso en recursos que la típica aplicación con un par de variables en la sesión.
Respecto a los tiempos muertos en el caso de ItsNat los hilos están soñando el sueño de los justos tranquilitos esperando que alguien los despierte.
Marioko: creo jmarranz que deberias centrar un poco mas la publicidad o propaganda que hagas de IsNat en cosas de alto nivel, porque por ejemplo en mi caso, nunca me interesaria meterme a manejar ningun DOM ni nada de eso, yo hiria directamente por el set de componentes y que tan facil y simple seria utilizarlos.
Es una cuestión de prioridades, el mundo ya está lleno de componentes sobrecargados llenos de efectos especiales, una de las críticas que se suelen dar es que o bien no se puede o hay que hacer virguerías para poder adaptar un componente precocinado para una funcionalidad ligeramente diferente, tú mismo sabes que algo en teoría tan obvio como hacer componentes compuestos en JSF no es nada sencillo, en ItsNat es trivial gracias a que son componentes de *nivel medio* que ni siquieran son propietarios 100% del markup (y por tanto el programador puede poner el markup que quiera asociado a nuevos componentes).
Luego está el mundo de los móviles, en general todos esos componentes superguays no funcionan en navegadores móviles. El ejemplo más extremo es IE Mobile 6 cuyo motor DHTML es penoso (el renderizado no está nada mal), gracias a componentes de nivel medio se pueden conseguir tablas y trees AJAX en ¡¡IE Mobile!! ni los programadores del navegador se podían creer que su chapuza podía llegar tan lejos. Si buscas en Internet no encontrarás ningún framework de componentes AJAX con soporte de IE Mobile. Se trata de ser menos ambicioso en los componentes a cambio de ofrecer mayor control por parte del programador y mayor universalidad soportando una lista muy amplia de navegadores.
La "ventaja competitiva" de ItsNat precisamente la has mencionado tú, que cualquiera puede crear sus propios componentes "guays" a medida encima de ItsNat. Yo no aspiro a que ItsNat sirva para todo el mundo, para todo tipo de aplicaciones y para todo tipo de programadores, en cierto modo va destinado a programadores desconfiados de los frameworks que tienden a quitarles de en medio y que dedican más tiempo en entender qué co..o hace el framework que a hacer su trabajo.
Un ejemplo interesante de Comet es la "fisgona" de meneame.net imagino que usando "polling" (temporizadores AJAX):
No estoy muy puesto, sólo por curiosidad, pero si es "polling" puro entonces no se considera Comet, ¿no? O quizá te refieres a que sería un buen caso de uso para pasarse a Comet y no lo he entendido. De todas formas, estamos básicamente de acuerdo. Me pregunto en el caso de Meneame si usaran Comet y todo el mundo decidiera usarlo como iría, sería un caso interesante a analizar.
Y sí, se pueden configurar servidores para tener muchas conexiones simultaneas, pero como bien dices no es sólo cosa del S.O. sino que que hay mucha capa intermedia a la que habría que mirar, así que simplemente quería dejar constancia de que no es trivial.
La impresión que me da es que el problema de los frameworks como IsNat, y que comparte el WebLEAF, es precisamente destinarse a programadores que quieran "saber más" o "saber de forma bastante precisa lo que pasa" a cambio de trabajar algo más. Me da que esa opción no es muy popular :). Y conste que no lo digo como crítica si no que como me pasa lo mismo...
greeneyed: No estoy muy puesto, sólo por curiosidad, pero si es "polling" puro entonces no se considera Comet, ¿no?
Es una cuestión de semántica, cuando introducí estas técnicas en ItsNat no llamé Comet a "polling" (lo llamo AJAX timers) pero popularmente se considera una técnica Comet, porque hay dos formas de entender el término Comet:
1) Comet = "Server push" puro sin acción explícita por parte del cliente: en ese caso polling no se consideraría Comet
2) Comet = "Real time web": en donde la página cambia sin intervenir el usuario y en donde se admite implícitamente que los cambios son parciales, es decir una página que hace reload con una cierta frecuencia no se considera "real time web" porque incluso aunque no haya cambiado nada la página se recarga. De acuerdo con esta idea polling es Comet, parto de que ese polling supone un cambio parcial de la página (o incluso nada).
En la definición del término Comet en la Wikipedia hay una verdadera guerra, en una versión más antigua polling (usando AJAX, o script o similares) era considerado Comet.
En CometDaily.com donde escribe por ejemplo el inventor del término Comet que es Alex Russell (de hecho la gente de su empresa, sitepen.com, son los propietarios del portal) se tiende a considerar polling como Comet, de hecho Comet no es sólo polling y long polling AJAX, están las variantes que usan script, el forever frame, streaming etc. Yo personalmente ya tiendo a incluir polling como Comet entendido como "real time web".
El caso de meneame.net lo puse precisamente como ejemplo muy claro de Comet (si se asume polling como parte de la definición de Comet), da igual la técnica usada.
Respecto a cual es "mejor" si polling o long polling pues no está del todo claro y depende. Hacen falta experiencias reales y casos de uso. En mi opinión hay dos escenarios:
1) El servidor genera cambios con mucha frecuencia (y la frecuencia es mas o menos constante)
2) El servidor genera cambios con poca frecuencia/esporádicos sin una frecuencia clara.
En el caso 1) da casi igual polling que long polling, constantemente el servidor recibe y suelta peticiones AJAX, polling probablemente es algo más adecuado porque es más sencillo y consume menos recursos en el servidor y da casi igual que el evento del servidor se reciba en el instante (usando long polling) o dentro de un ratito pequeño (polling), además si el flujo de eventos es constante con long polling se puede saturar el servidor no tanto por exceso de recursos, no, sino por excesivo tráfico, por excesivas peticiones (requests). Por ejemplo para seguir la cotización en bolsa de muchos valores, como la actualización es constante un polling razonable es suficiente, ahora bien si necesitas saber el cambio instantáneamente, yo que se porque se hace una operación automática desde el cliente sin intervencion humana, entonces mejor long polling, pero sería un caso un poco extremo.
En el caso 2) considera un evento del servidor que se da cada 15 minutos pero a veces puede ser que cada 30 o a veces tras 5 minutos. Es complicado establecer una frecuencia de polling que daría lugar unas veces a consultas inútiles y en otros casos habría mucho tiempo entre el evento y cuando se entera el cliente.
Greg Wilkings (Jetty boy) por ejemplo defiende que long polling es siempre mejor que polling.
Respecto a que los componentes de ItsNat sean de bajo nivel no es así, yo los considero de "nivel medio". Los ejemplos del Feature Showcase están precisamente diseñados para que el programador reutilice los comportamientos ya prediseñados. De hecho la licencia del Feature Showcase es totalmente liberal.
Por ejemplo el tree de ItsNat es muy adaptable pero si se reutilizan los renderers y estructuras y ejemplos del HTML ya hechos de los ejemplos del Feature Showcase, el tree deja de ser de bajo nivel y su uso es prácticamente idéntico al tree de Swing pues puede controlarse únicamente con el data model y selection model de los trees de Swing sin tocar nada visual y nada de DOM (pues ya está hecho) y tiene poco que envidiar a los trees que hay por ahí fuera. La clave es que el tree del Feature Showcase es un ejemplo de los posibles tipos trees que se pueden hacer con el tree de ItsNat (de hecho en el propio Feat. Show. un tree normal se convierte en un tree table etc). Lo que no hay son drag and drop, movimientos suaves al desplegar y esas cosas tan chulas que sirven para impresionar pero que a la hora de la verdad no sirven gran cosa.
@Greeneyed: "Yo mas bien diría emular, como suelen decir las definiciones de Comet, ya que en realidad no es una arquitectura bi-direccional real."
Deacuerdo, se me olvido colocar lo que dije entre comillas!!! xD
@jmarranz: "Es una cuestión de prioridades, el mundo ya está lleno de componentes sobrecargados llenos de efectos especiales, una de las críticas que..."
Otra vez deacuerdo, aunque mi comentario se centro en los componentes (y si, son muy complicados de hacer en jsf) mi idea original es en el soporte de alto nivel que se pueden dar a otras cosas, por ejemplo, me imagino que hacer un databinding entre modelo y vista deber ser mucho mas sencillo utilizando ItsNat porque el codigo necesario se genera en el server que usando una libreria JavaScript pura del lado del cliente, donde toca utilizar algun mecanismo de comunicacion con JSON o XML...
@Greeneyed: "La impresión que me da es que el problema de los frameworks como IsNat, y que comparte el WebLEAF, es precisamente destinarse a programadores que quieran "saber más" o "saber de forma bastante precisa lo que pasa" a cambio de trabajar algo más."
Vuelvo y lo digo, ese tipo de funcionalidad fina que ofrecen esos frameworks es muy util para crear cosas sobre ellos que se puedan reutilizar muchas veces, porque la opcion de "trabajar mas" cada vez que tengas que usarlos, no creo que se muy llamativa para la gran mayoria, y no digo que sea malo saber mas o tener mas control de lo que pasa, (a mi siempre me ha gustado saber como le entra el agua a un coco) pero en este mundo donde todo es para "dentro de una hora", "al rato lo tengo listo", "si yase, ahora mismo lo cambio", "mañana tiene su producto listo" el tiempo es un lujo que muchos deseamos y no podemos tener...
saludos
Estoy de acuerdo con greeneyed en que en ItsNat hay que trabajar algo más pero cuando uno tiene diseñado el componente como a uno le gusta, el resultado es un conjunto de clases Java de toda la vida y un layout patrón con HTML normal y corriente con 0 código de lógica y 0 código de vínculación con datos.
Ambas partes, layout patrón y clases Java son susceptibles de reutilizarse una y otra vez aplicándose a cualquier modelo de datos que encaje con el componente (ejemplo datos tabulares-componente tabla). Lo que quiero decir es que ItsNat apuesta hasta el extremo por la reutilización puesto que hasta el HTML puede reutilizarse para múltiples modelos de datos, eso no es posible en frameworks en donde se usa la típica mezcla de acceso a datos mezclada con markup que generalmente suele ser custom tags propios del framework.
pero en este mundo donde todo es para "dentro de una hora", "al rato lo tengo listo", "si yase, ahora mismo lo cambio", "mañana tiene su producto listo" el tiempo es un lujo que muchos deseamos y no podemos tener...
Si y no, por que después la gente pierde un montón de tiempo en cosas que... ains. Por ejemplo, el ultimo desarrollo que hice fue un Portlet atacando a una BDD. Los desarrollos "estandares" utilizan una metodologia toda organizada etc. etc. que es más una carrera de obstaculos que un desarrollo. Yo hice la primera versión en un par de horas con Groovy, tampoco era algo tan gordo, y el JDBC a pelo caramelo, cambiando las cosas sin reiniciar el contexto ni una vez ni para cambiar de BDD a acceder. Cuando lo tuve listo y verificado con la interfaz aceptada, se muestran los datos que toca etc. pues me puse y repliqué la lógica en la "metodologia oficial" (un ~20% de la aplicación) y me pasé un poco más que lo que había tardado en hacer la otra versión completa, no solo la lógica.
Igual que oigo a mucha gente quejarse de que desarrollar es un palo por que cada vez que re-despliegan por un misero cambio, se tiran minutos esperando a que el servidor reinicie, redespliegue... pues yo reinicio el contexto "de pascuas a ramos" por que el 90% se actualiza dinámicamente y cuando lo hace sólo me tarda 10-15 segs... como mucho.
Es decir, que sí, que el tiempo es muy justo, pero a veces los arboles no nos dejan ver el bosque y un poco más de perder el tiempo en saber exactamente lo que hacemos y por qué, nos permitiría ahorrarnos tiempo a la larga. Y la culpa en gran medida es de las empresas por llevar tan ahogados a sus programadores que no puedan "perder tiempo en ganar tiempo". Pero bueno...
Respecto a lo de Comet/Polling... la definición que leí de Comet lo definía "en contraposición" al Polling, así que pense que no lo incluía, gracias por la aclaración.
Escribe tu comentario