sirve - ¿Utilizaría usted, en la actualidad, JBoss o Glassfish(u otro) como servidor Java EE para un nuevo proyecto?
servidor de aplicaciones vs contenedor de servlets (9)
¡Checkout GlassFish 3.1! Construido sobre el kernel GlassFish v3 modular basado en Java EE 6, la versión 3.1 ofrece clustering, administración centralizada y alta disponibilidad.
Consulte http://blogs.oracle.com/nazrul/entry/glassfish_3_1 para obtener más detalles.
Si hoy comenzó un nuevo proyecto de Java EE que debe estar terminado en aproximadamente un año, ¿qué servidor de aplicaciones elegiría y por qué?
Parte de su respuesta debe incluir sus argumentos para su decisión. Y también cuánta experiencia tiene con el servidor Java EE que elija y con los otros servidores disponibles en el mercado. Estos son interesantes ya que todos tenemos un sentido de la investigación y el pensamiento que se puso en su respuesta.
El término "servidor de aplicaciones" es ambiguo. Con GlassFish v3, puede comenzar poco a poco con, digamos, un contenedor web tradicional y evolucionar (utilizando OSGi y la funcionalidad simple de "agregar contenedor") para agregar todo lo que desee: JPA, JAX-RS, EJB, JTA, JMS, ESB , etc. ... Sin embargo, es el mismo producto, la misma interfaz de administración, etc. ¿Esto califica como un servidor de aplicaciones para usted? -Alexis (Sol)
He estado usando jBoss por 3-4 años.
Argumentos para jBoss:
- Fuente abierta.
- Soporte comercial disponible.
- Comunidad de usuarios grande y activa.
Argumentos contra jBoss:
- Ninguna versión de contenedor compatible con Java EE 5 de acceso general.
- Mucha documentación pero prolija; puede ser difícil encontrar las respuestas a "¿Cómo hago x?"
- Herramientas administrativas para 4.x pobres en comparación con otras ofertas comerciales.
He usado WebLogic, WebSphere, JBoss, GlassFish, Resin, Jetty, Tomcat y algunos otros en los últimos 10 años. Entonces, si estuviera considerando un nuevo proyecto, primero me haría algunas preguntas. Una cosa que no volvería a cuestionar es que me negaría a usar JSP a menos que me torturaran hasta que lloré por mi mami.
¿Tengo que ser compatible / implementar en un producto específico debido al mandato de alguien? ¿No hay forma de ignorarlos o convencerlos de lo contrario? Si es así, ahí está tu respuesta.
¿Debo usar EJB? De Verdad? Evítelos si es posible; en realidad, solo son necesarios para sistemas muy grandes de clase empresarial. Recuerde que no son más que herramientas, y grandes (¿alguien puede decir "Golden Sledgehammer"?). Están muy usados en exceso, así que realmente, realmente me pregunto si los necesitas. Si los necesitas, eso elimina varias de tus opciones, incluido mi favorito, Jetty.
¿Tiene que usar alguna de las otras tecnologías importantes de J2EE como JMS, ESB, etc.? Si es así, y realmente no puede prescindir, entonces está nuevamente obligado a un contenedor J2EE completo. Considere e investigue cuidadosamente antes de comprometerse con BPM, por ejemplo, y evite los BPM de AquaLogic a (casi) todos los costos: es extremadamente feo.
Si realmente debe usar un contenedor J2EE completo, considere primero el código abierto porque es más robusto, mejor compatible y más rentable. Tienen bases de clientes más grandes y una interacción de soporte más abierta, por lo que tienden a obtener mejores soluciones más rápido. Sin embargo, Resin es inmaduro y lo evitaría en relación con GlassFish o JBoss. Encontré problemático su despliegue y soporte. Preferiría JBoss debido a su base de clientes más amplia, madurez, etc. GlassFish es más difícil de incorporar a un proceso automatizado de compilación / implementación, pero podría ser mejor para algunas de sus funciones específicas (si las necesita).
¿Tengo una razón especial para necesitar Apache? Luego inclínate hacia Tomcat, quizás más algo.
¿Puedo arreglarme con solo servlets? Luego usaría Jetty: es la solución más ligera, rápida, fácil y flexible. Si me inclino por no poder usar Jetty, cuestionaría todas mis suposiciones de por qué. YAGNI aplica.
Lo mejor es usar StringTemplate / WebStringTemplate en Jetty: una solución limpia, robusta, rápida y fácil de mantener sin tarifas de licencia, sólida reputación y soporte, etc. Ahí es donde comienzo hoy en día.
La mayoría de las aplicaciones / sistemas eligen muchas características extravagantes de J2EE cuando todo lo que realmente necesitan es servlets y JDBC con una arquitectura / diseño decente. Pregunta por qué crees que necesitas más.
De los contenedores completos, evitaría WebLogic y WebSphere, a menos que esté dando soporte a un sitio web público MAYOR (el sitio web de mi empleador actual se implementa en WebLogic y recibe más de 11 millones de visitas por mes, otros han sido comparables). La verdadera fama de la fama de WebLogic es su agrupamiento relativamente fácil, pero evite las características propias de bloqueo de proveedores a un costo (casi) total. WebSphere es simplemente una pesadilla que evitaría literalmente a toda costa: me niego a hacer proyectos que involucren a WebSphere después de haber hecho un par en el pasado. Ninguno de los productos vale las tarifas de licencias masivas, a menos que realmente tenga una necesidad especial que impulse el uso de una característica patentada. En una década como arquitecto / ingeniero senior para muchas compañías de Fortune 500, aún no he visto tal necesidad. Por otro lado, he visto MUCHO dolor debido a la selección de tales productos patentados.
Incluso para los sitios web públicos realmente grandes y de alto tráfico, los productos patentados todavía son cuestionables. Prefiero gastar ese millón de dólares por año de tarifas de licencia en un buen hardware y algún tiempo de calidad de un puñado de consultores realmente buenos para abordar una solución de escalabilidad simple. Los millones adicionales por año podrían usarse para producir algo digno de vender en ese sitio web agradable ...
EDITAR: otra pieza para considerar ...
Recientemente me encontré con Terracotta . Estoy reconsiderando todo y estoy buscando implementarlo pronto en un sistema significativo. En particular, Terracotta agrupa mejor que cualquier otra cosa, por lo que ya no recomendaría WebLogic para su agrupamiento.
La primera pregunta que suelo hacerme es "¿Puedo hacer esto con Tomcat?". Si la respuesta es no porque necesito JMS o JTA, entonces recurro a un servidor de aplicaciones.
Utilicé WebLogic 8 hace unos 3 años, contento con la facilidad de uso de WebLogic y el modelo de licencias / costos. Lo usamos para dos proyectos, uno era un servicio web y el otro era un portal. No encontramos ningún problema con WebLogic o Portal WebLogic en ninguno de esos proyectos.
Durante los últimos dos años estuve trabajando con WebSphere. Cada vez que negocié con IBM, siempre terminaba costando el doble que un equivalente de WebLogic, pero la política corporativa dictaba que WebSphere tenía que ser utilizado. Encontré que la curva de aprendizaje en WebSphere era considerablemente más empinada que WebLogic y nuestro ciclo de vida de compilación / implementación / prueba consumía tanto tiempo que utilizamos Tomcat en el entorno de desarrollo. Pero el mayor problema que tuve con WebSphere fue cuando nos encontramos con un error que nos forzó a actualizar a la próxima versión de parche solo para ejecutar el nuevo problema al analizar web.xml. Tomó un turno de 48 horas trabajar todo eso.
Por el momento, estoy usando JBoss. Hace aproximadamente 3 meses estaba a punto de embarcarme en mi nuevo proyecto con Tomcat y Jetspeed 2, pero noté que Jetspeed 2 parece estar un poco estancado en este momento y JBoss Portal 2.7.0 acaba de lanzarse con soporte para JSR 286 / Portlet 2.0. Le di un giro a JBoss y me pareció muy fácil de configurar y administrar. El ciclo de compilación / implementación / prueba es muy rápido y rara vez tengo que reiniciar el servidor a menos que haya cambiado un archivo Spring XML en alguna parte.
Otro punto que no se discutió aquí es el rendimiento. Si esto es una preocupación debido al tipo de servicio o por la cantidad de usuarios, entonces se aplicará lo siguiente:
- Tomcat parece ser más lento que Glassfish
- Glassfish parece ser más lento que Resin
- La resina es mucho más lenta que G-WAN + Java
Tenga en cuenta que G-WAN depende solo de la JVM: no utiliza ningún contenedor adicional (a menos que se especifique explícitamente) por lo que puede reservarlo para porciones de rendimiento crítico de sus aplicaciones web.
Como G-WAN admite otros lenguajes (C, C ++, C #, D, Objective-C), incluso puede procesar algunas partes de las aplicaciones en C sin procesar, manteniendo Java para otras tareas.
Podría incluir su sistema operativo preferido como criterio de decisión. Debería ser más fácil de admitir si está utilizando el mismo proveedor para el sistema operativo y el servidor de aplicaciones. Si ya tiene una relación con uno o ambos proveedores, considere si es bueno tratar con ellos.
Desde una perspectiva técnica, elegiría GlassFish porque tiene soporte para innovaciones más recientes. No creo que JBoss sea malo de todos modos, simplemente no está tan actualizado.
La mayor parte de mi experiencia es en WebLogic, pero he usado JBoss y GlassFish. Acabo de lanzar un nuevo sitio en una pila completa de código abierto de Sun (OpenSolaris, GlassFish, MySQL) y fue una gran experiencia con solo frustraciones menores.
Sigo pensando que WebLogic es el mejor servidor de aplicaciones Java EE del mercado. Creo que vale la pena si puede pagar esos derechos de licencia.
Me sorprendió ver lo lejos que puedes llegar combinando Tomcat, OpenEJB y ActiveMQ. Eso me parece una alternativa de bajo costo.
También buscaría en el servidor de Spring dm. Está basado en Tomcat, pero creo que la pieza de OSGi que agregaron podría estar en todas partes en poco tiempo. Si está hecho con la misma calidad que el marco Spring, será muy bueno.