No es web todo lo que reluce. Mi apuesta de futuro por el paradigma p2p
Sé que no debería contar esto, ya que al fin y al cabo me gano la vida desarrollando aplicaciones en su mayor parte web, pero a lo mejor precisamente por eso, por la cercanía con el tema, cada vez veo mas claro que este boom de las aplicaciones web que hemos vivido recientemente y que seguirá gracias (o por culpa, según se mire) a la web 2.0 se nos está yendo de las manos. Y lo peor de todo es que dejará víctimas en el camino. ;-)
Es evidente que el 2006 ha sido el año del web: el año de YouTube, de Digg, de menéame, de AJAX, de google, de las mashups, en definitiva, de la Web 2.0 y quizás en esta euforia, con cada vez más proyectos web luchando por su minuto de gloria en TechCrunch o en Loogic suene muy extraño lo que voy a decir, pero ...
Son ya varios los proyectos que he visto de cerca que se podrían calificar como grandes fracasos (y otros que vienen en camino)y en la mayoría he podido apreciar entre otras causas del fracaso una muy llamativa: no una mala elección de la tecnología, sino una mala utilización de la misma. A lo que vamos, ¿es Java EE una mala tecnología para desarrollar una aplicación de ámbito empresarial? por supuestísimo que no (si eres lector habitual de este blog ya sabrás por qué) ¿es malo distribuir esa aplicación con una interfaz web? claro que no, además en organizaciones con un amplio despliegue territorial (como la mia) esto tiene muchas ventajas, pero ... ¿pero? si, pero, puede haber casos que desaconsejen esto y en la mayoría de las ocasiones no se contempla esta opción. Por ejemplo en el caso de los grabadores de datos, o sea, gente que se pasa toda su jornada laboral picando datos como posesos, y que posiblemente estarán las 8 horas de trabajo delante de su flamante nuevo interfaz web acordándose de la ascendencia directa del responsable de haberles quitado su anterior programita cliente/servidor, que iba tan rápido y que no tenía que recargarse en cada petición ...
¿Tiene esto solución? claro que si, Java EE tiene solución para casi todo: como tu aplicación reside en el servidor, puedes hacer varios interfaces de usuario: a lo mejor uno general via web para la mayoría de usuarios y un cliente ligero para usuarios específicos. ¿Entonces cuál es el problema? el problema es que se ha prostituido tanto la arquitectura J2EE (perdón, Java EE) que en algunas organizaciones (incluída la mía) se ha llegado asimilar que Java==Web (bueno, lo de asimilar es un decir, porque creo que todavía no se han asimilado los principios de una arquitectura empresarial).¿Existen otros problemas? si claro, algunos de los que he visto: a poco que la aplicación no esté bien hecha (y hay que recordar que vivimos en el país de las ñapas) el consumo de recursos se dispara: cpu, memoria, ancho de banda ... Evidentemente estos problemas se pueden generalizar para cualquier entorno no Java. Además parece que ahora las aplicaciones deben ser web por decreto y me da la impresión que se han convertido en el nuevo martillo de oro
¿Qué alternativas hay? bueno, toda esta chapa que he soltado era para acabar hablando de una de mis últimas apuestas: el paradigma p2p como herramienta para desarrollar aplicaciones empresariales. Después de haber sufrido alguno de los problemas comentados en el anterior párrafo y buscando una solución creo que una alternativa a tener en cuenta es la utilización de redes p2p y aquí están mis motivos. El primero es que me parece incongruente el que los equipos del usuario son cada vez más potentes: mayor cpu, más memoria, un disco duro casi inagotable, etc, y sin embargo nos estamos empeñando en usarlos como terminales tontos con el consiguiente desaprovechamiento de recursos. En este caso el modelo p2p ofrece una solución para que todos los dispositivos se conviertan en proveedores de servicios para el resto de dispositivos de la red. El segundo motivo tiene que ver con la disponibilidad y el rendimiento, el hecho de no depender de un único servidor central sino tener esa responsabilidad dispersa por la red de nodos puede evitar en determinadas ocasiones tener un único punto de fallo. Además el aumento de rendimiento en el ancho de banda puede incrementarse notablemente al evitar los cuellos de botella, ya que el modelo p2p explota el ancho de banda disponible en los nodos "externos" de la red.
Es cierto que el modelo p2p ya ha tenido grandes éxitos de implantación, por ejemplo en el ámbito del intercambio de ficheros (la mayoría de la gente identifica el paradigma p2p con redes como emule, BitTorrent, Gnutella y demás), en el de la mensajería instantánea (msn messenger, yahoo messenger o jabber), en el de la VoIP (Skype es un buen ejemplo) o en el de la computación distribuída (¿quién no ha oído hablar del proyecto SETI@home?). Sin embargo creo firmemente que estamos ante el principio del auge del modelo p2p como arquitectura de desarrollo de numerosas aplicaciones. Por ejemplo creo que en el 2007 o 2008 será el año definitivo de la televisión P2P (P2PTV) y que también pronto veremos un uso creciente de las redes p2p en campos como las aplicaciones colaborativas (hoy dominadas por herramientas web como los wikis), la robótica, o las comunicaciones. Yo de momento ya estoy trabajando en ello ...
(2007-01-24 11:30:09.0) Permalink Comentarios [6]
Coincido contigo en el análisis que has hecho a la plataforma J2EE. También he visto los problemas de los operadores de pasar de un entorno clietne /servidor a web. A la pregunta de por qué se hacen las aplicaciones en web, "pues por que sí, por que ahora hay que hacer web".
Sobre lo del P2P, mmm, lo tengo que reflexionar, suena interesante, pero no sé si la mayoría de palicaciones hoy en web se podrían llevar a un entorno P2P. Las aplicaciones P2P se centran en dividir procesos repetitivos o basandose en datos que ya sabes cuales son. Pero creo que es dificil simular un repositorio único para una app. P2P.
le echaré una pensada! :)
Enviado por Joserra en enero 24, 2007 a las 12:14 PM CET #
La verdad es que vayas donde vayas, hoy por hoy todo se centra en Java == aplicación Web y, aunque sea algo muy útil, no es la panacea para todos los problemas... He llegado a ver con horror como procesos críticos se ponen en versión Web y... pufff... horrores múltiples.
La idea del p2p es muy curiosa en este contexto, realmente sí que merece la pena pensar sobre ello... Prometo hacerlo
Enviado por Black Hole en enero 24, 2007 a las 01:12 PM CET #
Una idea bastante interesante. Yo he visto aplicaciones corriendo en grid para acelerar procesos muy demandantes en recursos, pero nunca había pensado llevar el p2p al ámbito empresarial.
Siguiendo tu ejemplo de los grabadores de datos; ¿cómo funcionaría una aplicación así en p2p? Supongo que la carga de trabajo del procesamiento de la información se repartiría entre los terminales y la persistencia y seguridad se seguiría manejando en servidores centralizados. ¿No este un concepto muy parecido al de Orquestación de servicios solo que en vez de usar servidores que ejecuten uno más servicios estos se ejecutan en las terminales?
Enviado por Erick Camacho en enero 25, 2007 a las 01:30 PM CET #
Yo ya he estado pensando en estos temas, una aplicación empresarial p2p debe repartir, no sólo interfaces de usuario (tipo web), o computación, tipo grid, sino también datos, debería basarse en "mini" BD repartidas las cuales pueden actualizarse - replicarse con uno o varios servidores centrales, en base a ciertos criterios.
En el ejemplo de los grabadores maestros, cada grabador debería tener una aplicación (si es Java), swing, con su mini DB DBO, o mysql, por ejemplo (u Oracle XE gratis, etc..), que se replicaría con Oracles "centrales" para actualizar datos maestros y para "enviar", los datos que vaya grabando.... así cada "megapentium" de cada grabador repartiría interfaz, computación y gestión de datos...
Es una idea, pero creo que es un punto de partida...
Saludos
Enviado por asertus en enero 25, 2007 a las 05:45 PM CET #
Las cosas van mas por lo que comenta asertus. En principio en una red p2p cada nodo o peer es un "igual" que puede actuar como cliente y como servidor de cualquier tipo de recurso que pueda manejar: capacidad de proceso, memoria, almacenamiento, el tiempo que el usuario se pasa en el equipo, etc. Por eso no sería descabellado pensar en una aplicación que tenga todo su poder de procesamiento y su capacidad de almacenamiento de manera totalmente distribuída. Evidentemente, lo primero de todo, y de ahí mis criticas a la elección de arquitecturas por decreto o por costumbre, habría que hacer un estudio detallado de los requisitos y restricciones. Pero por ejemplo se me ocurre que en un sistema que de soporte a una organización amplicamente descentralizada ¿por qué tener en la misma máquina los datos de las delegaciones de Madrid, Barcelona, Oviedo, Santander, ... quizás las delegaciones para su trabajo diario únicamente tienen que trabajar con los datos de los equipos de su delegación (quizás a nivel provincial), si la delegación central tuviese que recabar información general haría peticiones a todos los nodos. La ventaja es que si se cae el nodo de Barcelona, en el resto del país seguirían trabajando con normalidad. Evidentemente este esquema es ampliable y modificable según las necesidades: los "servidores" tal y como los conocemos podrían ser nodos (peers o iguales) pero con una conexión permanente, también se podría adoptar una estructura jerárquica (es decir, no una arquitectura completamente distribuída), etc,etc, no sé, se me ocurren muchas ideas, será cuestión de ir probando
Enviado por mondelo en enero 25, 2007 a las 07:02 PM CET #
La idea es muy interesante.
Ahora si le buscamos las desventajas, tal vez sería que añade complejidad al diseño
Enviado por Ricardo en enero 27, 2007 a las 03:16 PM CET #