Jboss o Glassfish

Este es un tema casi religioso, asi que tambien sin entrar en polémica, mi experiencia con varias cosas de Jboss es que solo funcionan en jboss. En general el servidor de aplicaciones jboss es bueno, aunque no tengo noticia de implementaciones grandes; pero para mi su principal desventaja es que si usas cosas que son particulares de jboss (por nombrar unas, seam, drools) probablemente vas a tener broncas de portabilidad en el futuro.

Glassfish es una historia diferente, tiene una buena comunidad, está patrocinado por oracle, y es la implementación de referencia de j2ee, así que en general, y desde las épocas de Sun, es un servidor de aplicaciones en el que el codigo que corras ahí, lo podrás correr en cualquier otro servidor j2ee-compliant. Las últimas versiones ya hacen mas facil la vida del desarrollador y escala bastante bien cuando necesitas un cluster, usa grizzly así que vas a ver que es muy ligero y rapido, asi que en general te recomedaría mas gf que jboss. Pero como siempre, es cuestion de gustos.

Pues, son varios los factores que entran a discusión.
Uno de ellos , por supuesto , son los requerimientos de tu propio proyecto.

Aun imaginando que, tuvieras la total libertad de elegir cualquiera de los dos (¿eso existe?)
tendrías que proyectar a futuro como quieres que crezca la aplicación que desplegarás.

Toma en cuenta que glassfish ya esta bajo el manto de Oracle y que, muy probablemente a pesar de que menciona que lo mantendrá vigente, su buque insignia en temas de servidores de aplicaciones es Weblogic. Ya mencionaron que, al ser de Oracle, Glassfish es la implementacion de referencia para JEE.

Por el lado de JBoss, revisa su stacks de productos, quizá algunos encajan perfectamente con lo que tienes proyectado a futuro para tu aplicación.

Incluso temas como el sistema operativo pueden entrar en juego.... (Red Hat está detrás de JBoss y por lo tanto, seguramente tendrá cosas que optimicen o faciliten el uso de JBosss en esta SO).

Vamos que, intervienen tantos factores como previsión a futuro quieras incluir.

Siempre queda la opción de que, desarrolles apegado estrictamente a estandarés y evites usar peculiaridades de tu appserver, pero, ese es OTRO tema XD

Saludos.
RuGI

Puedes tener soporte pagado de JBoss; Red Hat lo ofrece. Hasta te lo optimizan si quieres, y si es sobre Red Hat obviamente hasta le mueven parámetros al sistema operativo para que funcione mejor de acuerdo a tus necesidades.

Oracle ofrece soporte así para Glassfish? Porque como ya mencionaron, es una implementación de referencia y probablemente no haya soporte comercial (y como dice rugi, Oracle seguramente prefiere venderte Weblogic o aunque sea soporte para el OAS).

Esto del soporte es muy común que lo pasen por alto y creo que es importante considerarlo; tal vez no lo necesites, pero es importante que SEPAS que no lo necesitas, no que nunca se te haya ocurrido analizar si lo necesitas o no.

hjuarezv: En cuanto a "implementaciones grandes", si te refieres a sitios grandes o aplicaciones importantes/populares/críticas en internet que corran sobre JBoss, pues tal vez no sean muy conocidas, y empresas como bancos por ejemplo no son muy dadas a anunciar las tecnologías que utilizan internamente, así que es difícil saberlo. Pero luego tampoco mencionas qué implementaciones grandes hay sobre Glassfish...

En cuanto a portabilidad, eso aplica para CUALQUIER contenedor. Si usas weblogic, te ofrece un montón de monerías (por eso cuesta tanto), pero si las utilizas por supuesto que te amarras a ese contenedor y pierdes portabilidad (esa es la meta y sueño de Oracle).

Si usas websphere, también ofrece cosas distintas, implementadas de forma distinta. Si las usas, te amarras a websphere (meta y sueño de IBM).

Si usas JBoss, ofrece varias monerías también; adivina qué pasa si las usas: te amarras a JBoss y haces feliz a Red Hat.

Si usas X contenedor y trae algunas monerías que no son precisamente estándar pero te sirven, pues si las usas, te amarras X contenedor y harás feliz a la empresa que lo vende y/o le da soporte.

Si usas X contenedor y solamente te apegas a los estándares, tendrás un mínimo de problemas de portabilidad.

Por eso es importante que también desde el inicio decidas qué tan importante es esto. Si tu aplicación es susceptible de ser puesta en producción en distintos contenedores, la portabilidad es muy importante y tendrán que apegarse a estándares lo más posible, y no usar nada que te amarre a uno u otro contenedor (o aislar eso muy bien para poder tener distintas implementaciones, para los distintos contenedores, sin que haya un reguero de dependencias a contenedores por toda la aplicación).

Si tu aplicación es algo que vas a poner a andar en el contenedor de tu elección y no hay planes para estarlo migrando de contenedor, entonces es importante decidir el contenedor de acuerdo a sus capacidades, características, planes a futuro, soporte, costos, etc.

Sobre la portabilidad ... pues sí, es todo un tema.

En la esquina técnica tenemos:
-Apegado a estandares puedes moverte entre appServers sin dolor.

En la esquina ruda:
-Si ya pagaste una buena cantidad de dolares por tu appServers al menos deberías aprovechar los monerías que éste te ofrece.

Entre esos dos puntos, hay toda una gama de tonalidades que puedes implementar.

Por eso dicen los libros que es mucho más dificil administrar la abundancia
(en este caso el hipotético escenario de que tienes la carta abierta para elegir)
que la escasez
(representada en este eufemismo por las restricciones normales en una empresa que ya ha decidio:
sistema operativo, arquitectura y marca con la cual convivir por una buena cantidad de años)

Ojala nos puedas ahora tu -radamantis- dar retroalimentación sobre, que es lo que estás tomando como parámetros para tu decisión final.

Saludos!!!

RuGI

Tal vez las entidades financieras si tienen el $$$ como para pagar las versiones con soporte de las distintas marcas, digase WL, Websphere, etc. y son las empresas de mediano tamaño o con tendencias al open source quienes han implementado sobre appservers como jboss y glassfish. Personalmente he visto puntos de venta y empresas de venta de boletos sobre JBoss, no he visto nada aun sobre GlassFish precisamente por la complejidad de la administracion, con las nuevas versiones eso parece mas sencillo. Habra que probar.

Por cierto, GlassFish si tiene una version con soporte empresarial de Oracle!

Estamos todavia decidiendo que servidor se ha de comprar pero falta mucho para tomar esa decision, ya que las aplicaciones las probaremos en los dos glassfish y jboss claro en las versiones gratuitas que brindan estos dos, por ahora le toca a glassfish la aplicacion ya tiene un tiempo de estar en pruebas reales, y por el momento ha respondido muy bien claro la aplicacion no es tan grande y las personas que lo usan son pocas,pero ha rendido bastante bien ya que el grueso de la aplicacion son puros reportes y hasta el momento no ha sucedido nada serio, solamente problemas con los printer y cuestiones de la red.

Gracias por sus opiniones estaremos analizando cual sera la que mas nos conviene y luego contestare porque Gracias.

Mi opinion es que para saber cual seleccionar debes haber probado o utilizado, en este caso uno de los compañeros comenta que JBoss nunca lo ha visto en proyectos grandes, solo para que se imaginen quien utiliza JBoss en un proyecto de su core, la Bolsa mas grande de Mexico lo utiliza, se realizo un comparativo no solo de documentacion sino de probarlo en produccion entre WebLogic, GF y JBoss, en aplicaciones estandares a JEE, por que si empiezan que si te casas con el framework, eso pasa en todo preguntele a Spring pero bueno eso no es el tema, al final gano JBoss, pero este tema no es de quien pierde o gane es quien se adecua a tus necesidades, por que para todos sale el sol si te gusta investigar estar cambiando xml tunnear el aplication server etc, el mejor es jboss, pero si te gusta tener con el chicote a un tercero que te resuelva y tu solo veas ventanitas existen 3 que te lo puedan dar a un precio elevado (webphere, weblogic y OAS), YO utilizo mas JBoss y creanme estable y con balanceador de cargas, etc.

En mi experiencia lo he visto y aplicado funcionando en:
En 3 Laboratorios de Analisis Clinicos en su Core, (ahi no dijo nombres siguen siendo clientes mios)
En una gran empresa enorme gigante en una linea de negocio en su core.
En un banco rojo queretano en un portal.
En la bolsa mas grande de mexico en una parte de su core

Y lo he visto funcionando en:
3 secretaria del gobierno.
En un portal nacional que ni se lo imaginan pero todos hemos entrado tu clave

Pero para gustos existen de todo, YO PROPONGO QUE SI ALGUIEN QUIERE HACER UN COMPARATIVO DE A VERDAD QUE SEA CON UNA APLICACION Y REALICEMOS UNA MATRIZ DE PUNTOS A EVALUAR, TIEMPO DE CONFIGURACION, DEPLOY, ADMINISTRACION, ETC.

A RESULTADOS Y LA PRESENTEMOS, CLARO UTILIZANDO UNA MISMA APLICACION PARA TODOS LOS APLICATION SERVER, YO PUEDO APOYAR EN EL JBOSS creo que puedo hacer funcionar el JBoss bien padre y con soluciones baratas, a las pruebas me remito

Tambien si gustan que realicemos una prueba con seam adelante a mi me encantan los ejb y drools, eso si el SOA para JBoss esta chafita mejor busquen otra opcion, lo unico bueno del SOA es el ESB le gana en tiempos de mensajeria al mismo WEbLogic, a las pruebas me remito

Ya comenzaron los flames, y eso no le ayuda en nada a la persona que pidió opiniones al foro. Solo para contestar algunos puntos que mencionas ezamudio, Glassfish tambien tiene subscripciones de soporte con Oracle, y tanto con ellos como son empresas mas chicas que le trabajan puedes conseguir apoyo por si los necesitas para optimizarlo.

En cuanto a "implementaciones grandes" me refiero a que reciba muchos usuarios concurrentes en aplicaciones oltp. Y que cuando necesites flexibilidad para escalar, sea relativamente sencillo y escale de forma lineal. Francamente he pasado por varias empresas (en gral en el sistema financiero) y no he visto en produccion a ninguno de los dos, mas que para aplicaciones "departamentales", ya sea de baja demanda o de bajo riesgo ante fallas.

La carencia de una interfaz de configuración me parece desafortunada en el caso de jboss, ya que la edicion de archivos de forma manual es mas sujeto a errores que la web GUI, y es una característica que el resto de los servidores de aplicaciones si tiene.

En cuanto al soporte, pues depende. En el caso del amigo que solicitó opiniones del foro, no parece que sea una aplicación de alta demanda ni que procese transacciones que le signifiquen perdidas/ganancias de dinero a su empresa, por lo que en su caso quiza el soporte 24/7 con niveles de servicio preestablecidos etc etc no le hagan sentido. En su caso yo me iria por las versiones opensource. Pero si el tuviera que procesar operaciones que en el caso de una falla le representen perdidas a su empresa, ya sea por el procesamiento en sí, o hasta por la mala prensa (piensa que el portal de ebanking de tu banco no es accesible un dia entero), entonces el soporte tiene mucho sentido. Si tu empresa esta perdiendo millones por hora, y tu "guru" local no le encuentra por donde, probablemente el apoyo del fabricante sea de ayuda no creen?

Como dije desde un inicio, es cuestion de gustos. Afortunadamente el mundo java no es como el .net en el que solo hay una forma de hacer todo. Tenemos estándares, tenemos posibilidad de elegir, y es tarea del ingeniero que lanzó la pregunta hacer su evaluación y se irá con el que más le convenza. En el mundo .net esta posibilidad de decisión se ve como fragmentación, no permitamos que tengan la razón.

Por cierto radamanthys360, si no estas usando ejbs / jms / jmx , puedes usar el muy olvidado tomcat. Si te interesa el soporte, creo que de todos es el mas barato, con tcserver de vmware (despues de que compro springsource). Asi que le puedes dar un vistazo tambien a ese.
Saludos.

Tomando en cuenta lo que comenta -hjuarezv360-, a veces tendemos a irnos a cosas grandes (mas si estamos empezando) cuando se pueden solucionar de manera mas simple. No digo que tomcat sea algo insignificante, sin embargo, desde mi punto de vista te quitas de todas esas 'monerias' que comentaba de otros servidores -ezamudio- .

Es lo que les puedo comentar en base a mi opinion personal, como bien lo dice el tema. Espero no haber repetido muchas ideas :)

En su caso yo me iria por las versiones opensource

Pues de qué estamos hablando entonces? Glassfish y JBoss son open source. Ninguno de los dos tiene versiones propietarias. Lo de pagar soporte, es pagar un servicio, no pagar por el software. Puedes usar cualquiera de los dos contenedores sin pagar un centavo.

Estimado Oliver.

Tengo una aplicación grande, pero tengo problemas con el jboss, la gente que lo trabaja aunque han hecho algunos sistemas, no tienen experiencia en sistemas grandes.

Estuvimos trabajando en tomcat y el sistema funcionaba correctamente, pero al pasarnos a jboss por requerimientos del cliente, empezamos a tener fallas, y creo que debe ser la inexperiencia de la gente en el jboss.

Donde me puedo contactar contigo para ver si me puedes cotizar el trabajo de configuración del jboss para que funcione correctamente.

El trabajo sería en el D.F., después de contactarme te pasaría mas detalles.

mis datos son:
danielperezvargas@hotmail.com
7221429380

Saludos.
Daniel Perez.

Dependiendo de los requerimientos de tu ambiente de desarrollo, Apache TomEE puede ser una buena opción.

~~~