Ideas sobre Tomcat y Jboss

Tomado de:
Comentarios sobre Tomcat y Jboss

Hola, Voy a desarrollar una aplicación web y estoy mirando que servidor de aplicaciones voy a utilizar. El servidor de aplicaciones lo voy a contratar con algún proveedor. Estoy informandome y estoy mirando servidores. He leido en varios sitios cual es la diferencia entre tomcat y los servidores de aplicaciones. Básicamente que tomcat no incluye contenedor de ejbs. Por ejemplo comparándolo con jboss: Servidor Web Container EJB Container Licencia TOMCAT SI NO OPEN-SOURCE JBOSS SI SI OPEN-SOURCE He seguido leyendo sobre ejbs, conceptualmente entiendo la diferencia (componentes que están contenidos en servidor en el ejb container), pero a efectos prácticos, por ejemplo, los ejbs de sesión (he leido sobre ellos) no me aportan nada funcion con respecto a beans de sesión que puedo usar en tomcat... ¿Alguien puede ponerme un ejemplo de algo que solo se pueda hacer por ejbs y que no se va a poder hacer con tomcat? ¿Cual es la diferencia entre un ejb y un servlet? ¿Cuando se debe utilizar cada uno?
RE: tomcat jboss ...		18/06/2010 08:13
izaera	Sin intención de ser exhaustivo: Primero distinguir entre EJBs y servlets. Los EJBs son servicios y los servlets son generadores de contenido (principalmente HTML). Es decir, un EJB es parecido a un objeto CORBA o COM (de M$) que exporta un servicio a traves de una interfaz conocida y que puede ser accedido de forma remota o local. Un servlet es una evolución de los CGI. Dicho esto, se puede conseguir algo similar a los EJBs con servlets. Por ejemplo: usando web services. Entonces, ¿cual es la ventaja de los EJBs? Que los gestiona el servidor de aplicaciones y por tanto los puedes configurar. Por ejemplo: puedes ejecutar cada EJB en una maquina distinta, puedes decir cuantas instancias quieres de cada EJB, puedes coordinar varios EJBs es una transacción distribuida, etc. Si usas POJOs (plain old java objects), es decir, implementas las funciones de tu aplicacion con Java pelado, el servidor de aplicaciones no puede controlar las instancias de tus objetos y si quieres una funcionalidad similar te lo tienes que hacer tu. Vista la diferencia, parece que mola usar EJBs, pero luego viene la realidad, como siempre, y ya la cosa no esta tan clara. Porque para obtener esa funcionalidad "extra" el nivel de complejidad de tus sistemas y de tu aplicacion se incrementa en varios ordenes de magnitud. Así que mi consejo es: usa Tomcat mientras puedas y pasa de JBoss. Y si en algun momento tenéis algun requisito que os obliga a usar funcionalidad de un servidor de aplicaciones, pues os pasais a JBoss y listos. Ten en cuenta que el "motor de servlets" de JBoss es Tomcat, asi que el paso no va a ser nada traumatico. Una cosa mas: esto que te he contado aplicaria a EJB2 y a EJB3, salvo a los "EJBs" de persistencia de EJB3 (los que representan filas de la BD), que se pueden ejecutar en Tomcat usando JPA (no necesitar servidor de aplicaciones, es una libreria, como por ejemplo Hibernate). Por supuesto, esta es mi opinion, otra gente puede tener otra y les animo a que la expongan pero cortesmente. Gracias majos :-P.
RE: tomcat jboss ...		18/06/2010 09:57
coutemeier	Coincido con Izaera, y aún más. Como veo que te estás introduciendo en el mundillo te sugiero dos cosas: Que no trates de entrar de golpe y porrazo con los EJB's, aprende antes las bases con tecnologías más ligeras. Quizás servlets sea un buen comienzo, mas yo intentaría aprender las bases de servlets para meterme con JavaServerFaces. Es una pasada para la inmensa mayoría de aplicaciones. En relación al servidor, antes que JBoss yo te propondría usar Glassfish por tres razones fundamentalmente: licencia CDDL y GPL, es comparable al JBoss y posee un ESB, ideal para webservices. A medida que vayas aprendiendo cosillas verás como compensa.
RE: tomcat jboss ...		18/06/2010 10:42
izaera	Respecto a JSF (antes de que se me adelante greeneyed :-)): Yo llevo usandolo casi desde que salio en conjuncion con Icefaces+facelets y la verdad, cada vez me decepciona mas. Se que es el estandar y que lo sera, y que se acabara imponiendo, y cada vez lo demandara mas gente. Y por ende, se acabara puliendo y acabara siendo medio util. Y que yo lo seguire usando durante bastante mas tiempo porque no me queda mas remedio. Sin embargo, desde que hicimos el famoso podcast de SPI jmarrranz y yo, y a raiz de mas conversaciones en los foros, pruebas con GWT, lecturas sobre otros frameworks, y cosas que he ido sufriendo en mis propias carnes, cada vez me gusta menos. Entre otras razones no me gusta: -El uso excesivo de memoria -El que tenga que ser centrico en el servidor por fuerza (con HTML5 yo soy de la opinion de que cada vez mas cosas van a ir al cliente, de ahi la importancia de GWT como framework cliente productivo) -La interaccion entre el arbol de componentes de JSF y los JSPS/Facelets esta especificada mal y es incoherente. Por mucho que se pula, siempre sera dificil saber donde se pueden usar determinados tags (c:if, c:choose) y donde no. -Las referencias "lazy" a las expresiones EL suponen una carga de CPU exagerada que en no todos los contextos esta justificada. -La curva de aprendizaje es alta porque el ciclo de vida de las peticiones es complejo y por la incoherencia en el uso de tags en facelets. Con esto no digo que se deje de usar y que sea una basura, porque funcionar funciona y lo tenemos en producción en varios clientes y hace su función. Solo digo que hay que pensarselo antes de escogerlo ciegamente, especialmente habiendo otros frameworks con filosofias muy diferentes y supuestamente mas sencillos. La elección de JSF en bastantes ambientes puede ser sub-optima. Por ultimo, no estoy seguro de que JSF vaya a ser un fiasco como EJB2, pero para mi gusto se esta acercando peligrosamente a serlo. Veremos si se endereza. Ojo: todo esto lo digo sin haber usado JSF2, pero por lo que se de JSF1 y por lo que he leido no creo que mejore drasticamente la situación. Y ahora si alguien es tan amable de argumentar a favor de JSF se lo agradeceré mucho puesto que me gustaría seguir creyendo, ya que lo voy a tener que seguir usando bastante tiempo, como he dicho.
RE: tomcat jboss ...		18/06/2010 12:15
anonymous	Estoy parcialmente de acuerdo contigo, pero hay algunos puntos que merece la pena revisar. Sí, consume mucha memoria, pero he visto algún artículo en el que se puede resolver por medio de compresión zip del estado. No puedo asegurarlo, pero creo que es la estrategia de JSF2 Estoy parcialmente de acuerdo con lo del centrismo en el servidor y con lo de HTML5. En realidad yo creo que se debe centrar en el servidor, pero que las especificaciones HTML deberían adaptar los controles que suministran (los input, select...) para tener de modo natural un comportamiento AJAX, más controles nuevos (date, combo editable, listas más potentes...) y reducir la dependencia del javascript o del código centrado en el servidor. Nunca se llegará a esto, poner de acuerdo a varios fabricantes es algo imposible, pero un acuerdo de mínimos podría reducir el coste del desarrollo de componentes visuales, que, al final, es lo que ve un usuario de una aplicación. JSF y Facelets se integran perfectamente, pero pretender que JSP y JSF y Faceletes se integren sin problemas es otro cantar. Cuando te refieres a las etiquetas c:if y c:choose te estás refiriendo a la jstl:core, que se debería evitar usar, puesto que es una adaptación de JSP, y el EL unificado, aunque resuelve, puede no resolver como esperamos en JSF, de ahí la diferencia entre el # y el $ (y aunque le pongamos # a la expresión, es el contexto del c:if el que determina cómo se resuelve). Yo no tuve excesivos problemas para entender el JSF, pero sí tuve más de uno para integrar el Facelets, desarrollar componentes en Facelets y usar el Richfaces. Una vez configurado un proyecto ya lo tuve para los demás. La ventaja de JSF2 es que Facelets es el motor de plantillas por defecto de JSF, aunque no lo he probado, yo entiendo que ya no es necesario configurarlo. Aparte d eque simplifica la creación de controles con respecto a JSF 1. Por otro lado no uso lazy en JSF, no da más que problemas, ya que las operaciones lazy presentan el problema de que cuando se accede a un sistema de persistencia es posible que cuando se intenta resolver el lazy la sesión se haya cerrado. A mi modo de ver el lazy es demasiado peligroso cuando de lo que se trata es de separar el acceso a datos de la vista. El ciclo de vida de las peticiones en JSF2 soporta atajos, para aquellos casos en los que no es necesario pasar por todo el ciclo de la petición (creo que se pensó para AJAX, sobre todo). Y que conste que no pretendo convencer, simplemente lo conozco mucho más que otros entornos, y doy mi opinión. De hecho, antes de JSF venía de usar Freemarker, que por su sintaxis me facilitó muchísimo el paso a JSF (Freemarker proporcionaba algo parecido al EL, con una sintaxis similar). Espero que esto pueda arrojar un puntito a favor de JSF, aunque es cierto que aún tiene que mejorar en velocidad, sobre todo. Pero no se puede tener todo.
RE: tomcat jboss ...		18/06/2010 12:20
coutemeier	La gracia de las sesiones... el último anónimo soy yo...
RE: tomcat jboss ...		18/06/2010 12:42
greeneyed	Simplemente añadir que ahora mismo la razón primordial para querer usar EJB de sesión sería el acceso remoto que proporciona el contenedor sin que tu tengas que montarte nada de RMI ni similares, o la integración con colas de mensajes de los EJB de mensajería. Eso o si se quiere entrar a tener un control de acceso muy refinado por componente en vez de funcionalidad. Para todo lo demás Master... digo... los servlets y sus amigos valen :). Lo EJB de entidad no hay que mencionarlos por que a los difuntos hay que dejarlos descansar no vaya a ser que se levanten, que están bien donde están ;). Y de JSF y similares no digo ná, que ya lo dicen los que lo usan más y no hace falta hurgar en la herida. El GlassFish personalmente no me mata mucho, está demasiado volcado al modelo empresarial y area de sistemas, y con el futuro incierto dentro de Oracle... en fin. No creo que sea mala elección, pero para empezar y usar "simplemente" servlets con el Resin o el Jetty vas que te matas. S!
RE: tomcat jboss ...		18/06/2010 12:46
izaera	Uff, compresion ZIP me suena a "no uso memoria pero uso CPU". Pero bueno esta claro que si hay que guardar el estado hay que guardar el estado, no se puede hacer magia. En cuanto a centrismo en el servidor a mi tambien me gusta mas y lo veo mas facil de desarrollar, pero tambien tiene mas problemas de escalabilidad y de alta disponibilidad si engordas mucho la sesion. Como siempre es una cuestion de contexto. Lo malo de JSF es que engorda la sesion y si no quieres, te ves obligado a mandar el estado de la UI en un campo hidden, lo cual permite alta disponibilidad pero es dudosamente eficiente. Otra opcion es serializar la sesion y replicarla entre servidores balanceados, pero tampoco es muy buena opcion, yo creo. Sobre las etiquetas JSTL al final se integran con JSF en facelets como en JSF. Un poco mejor, pero no mucho mejor. Mi queja es que hay dos momentos de evaluacion de etiquetas: al construir la vista y luego al renderizarla. Asi, por ejemplo, no siempre funciona meter c:ifs dentro de un dataTable por ejemplo o no puedes hacer un ui:include dentro de un control JSF. En general, analizando cada problema se puede encontrar una solucion, pero es complejo y requiere de mucha experiencia. Incluso en tomahawk estan haciendo falsos controles JSF para solucionar estos problemas que no son controles visuales en si, sino un poco, digamos, ñapas que simulan los c:if y los ui:include.  Y lo de lazy no me he explicado, no me referia a JPA, me referia a que las expresiones EL internamente crean un arbol de evalucion bastante complejo (uso de memoria y CPU) y que cada vez que se evaluan (y se evaluan muchisimas veces en cada renderizacion de pagina) tienen un coste muy alto de CPU. Ejemplo: si tu haces c:set var=pepito value=${x.y.z} y luego usas la variable ${pepito} en un control de JSF, cada vez que el control quiera acceder a pepito, el EL tiene que resolver que es x, luego llamar a getY dentro de x, luego a getX dentro de lo que devuelve, y finalmente pasarle el valor a JSF. Estaria bien que hubiese un modo de resolver la expresion al hacer el c:set y que no se evaluase mas. Aunque esto es cosa mas de EL que de JSF. En fin, lo de siempre, que no esta ni mal ni bien, tiene sus cosas buenas y sus malas. A mi personalmente me esta decepcionando un poco, pero quizas porque esperaba que fuese mas de lo que al final ha resultado ser para mi. No desaconsejo totalmente su uso, pero desde luego ya no lo aconsejo tanto como antes ;-).
RE: tomcat jboss ...		18/06/2010 17:59
coutemeier	Sí, siempre que se habla de compresión es a costa de CPU. Ahí es donde entra en juego el viejo equilibrio entre cpu-memoria-coste. De cualquier forma, tampoco es que tengas que comprimir 1Gb de información, así que, a priori, tampoco es un coste tan grande.  JSF engorda la sesión, sí, y volvemos al tema del punto anterior: cpu-memoria-coste. Pero este engordamiento no es gratuito en el sentido de que se hace de una forma para proporcionar un control sobre una serie de aspectos que sea más o menos sencillo de acceder. Personalmente no me gusta que el estado viaje al cliente en un campo oculto. En cuanto a la evaluación EL a eso me refería yo con lo de # y $, y las adaptaciones que se han hecho para usar los tags propios de JSP en JSF. Pero no es realmente una integración, sino una adaptación, ya que los jstl:core se resuelven en el contenedor del JSP, y JSP tiene conceptos como el Page scope que no existen en JSF. Por ejemplo, el c:forEach, este problema está documentado en la especificación de JSF. Resumiendo, puedes usar las etiquetas, pero tienes que entender cuál es el contexto en el que se van a resolver. No niego que las uso, pero en muy contadas ocasiones. En cuanto al sistema de resolución de EL básicamente han optado por una estructura de tipo Map. Y curiosamente, los List, o los propios Map, no funcionan muy bien, porque un #{lista.size} o #{lista.size()} no resuelven correctamente, ya que por la especificación se espera que exista un método lista.getSize(). Pero eso se resuelve fácilmente con una implementación de un Resolver para que resuelva las propiedades de un List o de un Map. A mí ni me impresiona ni me decepciona, simplemente hace lo que necesito; cuando necesito más lo extiendo (si soy capaz), y si no a otra cosa mariposa. Yo sí lo aconsejo, porque no estoy limitado por CPU ni por memoria (al menos no de momento). Más adelante ya veremos. Y sobre el Glassfish, yo creo que sí tiene futuro, aunque distinto al que inicialmente se había previsto. Probablemente, acabaremos viendo una versión OpenGlassFish (como le pasó al OpenJDK), que será la base y contendrá lo mejor (y quizá también lo peor) de GlassFish y del servidor de Oracle. Tiempo al tiempo. Y espero que además, la licencia del GlassFish permita hacer un fork para continuar con el desarrollo del GlassFish llamémoslo tradicional, el que conocemos hoy en día, para no tener que cambiar al de Oracle, que sinceramente, como emrpesa y orientación de sus productos, cada día me decepciona más. Un saludo, da gusto tener intercambio de opiniones sobre el tema.
RE: tomcat jboss ...		18/06/2010 18:14
izaera	Leyendo tu post, quiza sea eso lo que mas me decepciona de JSF: que estaba llamado a ser el estandar de desarrollo de aplicaciones web y al final hay que ser ingeniero espacial para usarlo. Ya se que estoy exagerando, pero ponte tu a contarle las sutilezas del uso de tags ui:include y c:if a un novato. O que las expresiones EL se componen en una pasada pero se evaluan en un momento u otro segun donde las estes poniendo en la pagina y quien las evalua. Lo fliparia y no creo que lo llegase a entender hasta darse varias veces de cabezazos con ello. No puedo dejar de imaginarme el tipico equipo de desarrollo de la megaconsultora chupiguay lleno de primerizos programando en JSF sin haberse leido ni un folleto sobre el tema, y me recorre un escalofrío la espalda del que me cuesta recuperarme :-D. Seria interesante saber, si marioko anda por ahi, porque se paso a ZK despues de Icefaces. Seguro que tambien tenia un punto de vista interesante sobre el asunto. Marioko, ¿andas por ahi? ¡Manifiestate! Ah, y a mi tambien me mola hablar de estos temas "filosoficos". Ya lo habréis notado ;-).
RE: tomcat jboss ...		18/06/2010 20:45
greeneyed	Al igual que la compresión o no es un tema CPU/memoria, hay otro tema que hay que equilibrar y es el de la funcionalidad-abstracción vs comprensión-facilidad de uso. Sun suele(solía) pecar en algunos casos (especialmente en Java EE) de hacer especificaciones pensando en mega-corporaciones para casos de uso complejísimos, olvidándose de los casos sencillos y la gente "común", y luego salen estas cosas hiper-flexibles, extensibles, mega-especificadas que para hacer una cosa sencilla son un dolor de cabeza. Pero bueno, sus cosas buenas tienen... supongo ;). Nosotros en el equilibrio optamos por separar limpiamente las capas y tendemos a la simplicidad para que cada una sea más sencilla de entender, con el consiguiente coste en esfuerzo extra. Tiene sus pros y sus contras, como todo, pero a nosotros nos sirve y eso es lo importante: encontrar algo que te sirva para tu equipo y tus tipos de proyecto.
RE: RE: tomcat jboss ...		21/06/2010 11:50
coutemeier	Como greeneyed yo también creo que Sun ha hecho un gran esfuerzo pensando siempre en una arquitectura para proyectos excesivamente complejos. Eso no quiere decir que siempre se deba aplicar siempre esa arquitectura, sino que si la conoces y sabes aplicar en su momento lo que más conviene a tu problema, tendrás menos problemas que si lo haces a tu manera. También opino como greeneyed que al final como se trata de construir algo en lo que puede colaborar mucha gente y que se puede desmadrar fácilmente, cuanto más separadas estén las distintas capas entre sí mejor. Por ejemplo, yo soy un anti Spring, y reconozco que está muy bien, y que posee sus virtudes, pero cuando me hablan de usar Spring, y me dan cincuenta mil razones por las cuales debería usarlo, por poner un ejemplo, siempre pregunto lo mismo, ¿en qué lo quieres utilizar? JSF fue una reacción de Sun a una necesidad. No creo que sea tan mala, pero creo que es importante conocer sus limitaciones antes de decidirse a usarla. Y creo que el EL es bastante útil (es mejor hablar de EL unificado más que de EL) y muy potente, pero que se diseñó en el contexto JSF, y ahí es donde realmente tiene sentido, por lo que intentar aplicarle conceptos de JSP sólo puede llevar a confusión. JSF no es JSP. Creo que el gran error de Sun fue crear esa adaptación de las librerías JSTL con una mezcla de JSP y JSF. Desde mi punto de vista, deberían haberlas diseñado de nuevo bajo el modelo JSF, pero con el cuento de la reusabilidad (reusar los componentes de JSP) le han hecho mucho daño a JSF sin que las causas se le puedan atribuir a JSF. Pero el problema de esta confusión es que Sun no se distingue por ser muy claro con JSF. En su momento en otro post, había comentado que para diseñar mi primer control JSF había encontrado como tres o cuatro modelos de ejemplos, de los cuales sólo uno me funciono. Había mucha información, pero la información de calidad en este tema brillaba por su ausencia. Por otro lado, seguro que podría prescindir de JSF en muchos de mis proyectos (ya os comenté que empecé con el Freemarker, gran motor de plantillas), seguro que añadiéndole un frontend decente ya contaría con la mayoría de opciones que necesito hoy en día. Pero por comodidad (el plugin de JBoss es impresionante), uso JSF. Por eso y porque realmente es más que suficiente para lo que necesito. De hecho, mientras que otros apuestan por Spring para hacer cualquier proyecto yo procuro buscar un compromiso entre la complejidad de un proyecto y las tecnologías a aportar. Un apunte, la parte visual la diseño con Richfaces (por la ventaja que tiene la integración AJAX, sobre todo), así que tengo una interface muy completa. Decía un anuncio de la tele que la potencia sin control no sirve de nada, y el dicho popular que no puedes matar moscas a cañonazos. En esto pasa lo mismo. Lo mejor es conocer y decidir, y lo que a veces vale para uno, no es tan adecuado para otro con el mismo problema.
RE: tomcat jboss ...		29/06/2010 04:46
anonymous	Gracias de responder tan ampliamente y ahondar en el tema de JSF, tambien lo que trabajado aunque no tan avanzado, como todo cosas buenas o malas.