¿En la actualidad, usaría JBoss o Glassfish (u otro) como servidor Java EE para un nuevo proyecto? [cerrado]


136

Si comenzara hoy un nuevo proyecto Java EE que se terminará 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 una idea de la investigación y pensamos que se incluyó en su respuesta.

Respuestas:


181

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 ya no cuestionaría es que me negaría rotundamente a usar JSP a menos que fuera torturado hasta que llore 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.

¿Tengo que usar EJBs? De Verdad? Si es posible, evítelos; en realidad, solo son necesarios para sistemas muy grandes de clase empresarial. Recuerde que son simplemente herramientas, y grandes en eso (¿alguien puede decir "Golden Sledgehammer"?). Están muy sobreutilizados, por lo que realmente se preguntan si los necesita. Si los necesita, eso elimina varias de sus opciones, incluido mi favorito, Jetty.

¿Tiene que usar alguna de las otras tecnologías J2EE importantes como JMS, ESB, etc.? Si es así, y realmente no puede prescindir, entonces nuevamente está limitado a un contenedor J2EE completo. Piense e investigue cuidadosamente antes de comprometerse con BPM, por ejemplo, y evite AquaLogic BPM 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 soportado 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 inmadura y la evitaría en relación con GlassFish o JBoss: me pareció problemático implementarla y brindar soporte. Preferiría JBoss debido a su base de clientes más amplia, madurez, etc. GlassFish es más difícil de incorporar en un proceso automatizado de construcción / implementación, pero podría ser mejor para algunas de sus características específicas (si las necesita).

¿Tengo una razón especial para necesitar Apache? Luego inclínate hacia Tomcat, quizás más algo.

¿Puedo conformarme solo con servlets? Entonces usaría Jetty: es la solución más ligera, rápida, fácil y flexible. Si me inclino a 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. Aquí es donde empiezo hoy en día.

La mayoría de las aplicaciones / sistemas eligen muchas características sofisticadas de J2EE cuando todo lo que realmente necesitan son 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é apoyando un sitio web público MAYOR (el sitio web de mi empleador actual está implementado en WebLogic y recibe más de once millones de visitas por mes, otros han sido comparables). El verdadero reclamo a la fama de WebLogic es su agrupación relativamente fácil, pero evite sus características exclusivas de bloqueo de proveedores a (casi) todo el costo. 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 enormes tarifas de licencia, a menos que realmente tenga una necesidad especial que impulse el uso de una función patentada. En una década como arquitecto / ingeniero senior para muchas compañías de Fortune 500, todavía no he visto tal necesidad. Por otra parte,

Incluso para los sitios web públicos realmente grandes y de alto tráfico, los productos patentados siguen siendo cuestionables. Preferiría gastar esos millones de dólares anuales en tarifas de licencia en un buen hardware y un 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 venta en ese lindo sitio web ...

EDITAR: otra pieza a considerar ...

Recientemente me he encontrado con terracota . Estoy repensando todo y estoy buscando implementarlo en un sistema significativo pronto. En particular, la terracota agrupa mejor que cualquier otra cosa, por lo que ya NO recomendaría WebLogic para su agrupación.


77
Para referencia futura, generalmente puede encontrar las definiciones de acrónimos a través de una búsqueda en Google o Wikipedia. YAGNI = No lo vas a necesitar = no exageres tu diseño JMS = Java Message Service ESB = Enterprise Service Bus BPM = Business Process Management
Rob Williams

21
Sus comentarios sobre Java EE y EJB están un poco desactualizados. ¿J2EE? Eso fue como hace 5 años. ¡Eche un vistazo a Java EE 6 y modernice su perspectiva!
Brian Leathem el

66
@Brian: Estoy de acuerdo con Brian, especialmente con EJBLite, se ha vuelto mucho más liviano.
Thang Pham

77
@Brian, mira la publicación: fue escrita tres años antes de tu comentario. Y aún diría que Spring es más liviano que incluso un Java EE reducido.
duffymo

2
¿Cuál es el veredicto ahora en 2012? ¿JBoss 7 AS es el rey de Glassfish en el ámbito de Java 6 EE? ¿O al revés?
Rolando

10

El término "servidor de aplicaciones" es ambiguo. Con GlassFish v3, puede comenzar con, digamos, un contenedor web tradicional y evolucionar (usando OSGi y la funcionalidad simple "agregar contenedor") para agregar lo que desee: JPA, JAX-RS, EJB's, 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)


1
Desafortunadamente Glassfish ya no es un producto oficial, sino "solo" la implementación de referencia.
Thorbjørn Ravn Andersen

9

La primera pregunta que generalmente me hago es "¿Puedo hacer esto con Tomcat?". Si la respuesta es no porque necesito JMS o JTA, 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 licencia / costo. Lo usamos para dos proyectos, uno era un servicio web y el otro era un portal. No encontramos ningún problema con WebLogic o WebLogic Portal en ninguno de esos proyectos.

Durante los últimos dos años estuve trabajando con WebSphere. Cada vez que negociaba con IBM siempre terminaba costando el doble que un equivalente de WebLogic, pero la política corporativa dictaba que tenía que usarse WebSphere. Descubrí que la curva de aprendizaje en WebSphere es considerablemente más pronunciada que WebLogic y nuestro ciclo de vida de construcción / implementación / prueba fue tan lento que usamos Tomcat en el entorno de desarrollo. Pero el mayor problema que tuve con WebSphere fue cuando encontramos un error que nos obligó a actualizar a la próxima versión del parche solo para encontrar un nuevo problema al analizar web.xml. Tomó un turno de 48 horas para resolver todo eso.

Por el momento, aunque 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 un poco estancado en este momento y JBoss Portal 2.7.0 acaba de lanzarse con soporte JSR 286 / Portlet 2.0. Le di una vuelta 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.


¡Buena respuesta! ¿Has probado Jetty? ¿Y cuál es su opinión al respecto en caso de que lo haya hecho?

7

He estado usando jBoss durante 3-4 años.

Argumentos para jBoss:

  1. Fuente abierta.
  2. Soporte comercial disponible.
  3. Comunidad de usuarios grande y activa.

Argumentos contra jBoss:

  1. Sin acceso general, compatible con Java EE 5 versión de contenedor.
  2. Mucha documentación pero detallada; puede ser difícil encontrar las respuestas a "¿Cómo hago x?"
  3. Herramientas administrativas para 4.x pobres en comparación con otras ofertas comerciales.

"Sin acceso general, compatible con la versión de contenedor JEE 5". Supongo que ya no es el caso, ¿correcto?
Raedwald

@Raedwald: sí, ahora que JEE 6 ha existido por algún tiempo ;-)
ymajoros


3

Otro punto que no se discutió aquí es el rendimiento. Si esto es preocupante por el tipo de servicio o por la cantidad de usuarios, se aplicará lo siguiente:

  • Tomcat parece ser más lento que Glassfish
  • Glassfish parece ser más lento que la resina
  • La resina es mucho más lenta que G-WAN + Java

Tenga en cuenta que G-WAN se basa solo en la JVM: no utiliza ningún otro contenedor (a menos que se especifique explícitamente), por lo que puede reservarlo para porciones críticas de rendimiento 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 mientras mantiene Java para otras tareas.


2

Podría incluir su sistema operativo preferido como criterio de decisión. Debería facilitar el soporte 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 tratarlos.

Desde una perspectiva técnica, elegiría GlassFish porque tiene soporte para innovaciones más recientes. No creo que JBoss sea malo de ninguna manera, 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 pequeñas frustraciones.


El sistema operativo no es realmente un problema, a menos que tenga dependencias binarias muy específicas (que no debería ser el caso para la mayoría de los proyectos de Java). Desarrollamos en Windows, 32 y 64 bits, y lo implementamos en Glassfish en Solaris. La mayoría de los desarrolladores realmente no lo saben y no tienen que preocuparse. Los usuarios no lo ven (la mayoría de nuestros desarrollos son aplicaciones web).
ymajoros

2

Sigo pensando que WebLogic es el mejor servidor de aplicaciones Java EE del mercado. Creo que vale la pena si puede pagar esas tarifas de licencia.

Me sorprendió ver hasta dónde puede llegar combinando Tomcat, OpenEJB y ActiveMQ. Me parece una alternativa de bajo costo.

También buscaría en el servidor Spring dm. Está basado en Tomcat, pero creo que la pieza OSGi que agregaron podría estar en todas partes en poco tiempo. Si se hace con la misma calidad que el marco de Spring, será realmente muy bueno.


2
El problema que tengo con WebLogic es el bloqueo del proveedor, ¡es una píldora desagradable para tragar cuando realmente no es necesario!
Manius

1
Eso es cierto para todos los proveedores de Java EE que conozco, no solo para WebLogic. Si usa alguna característica específica del proveedor, está bloqueado. Tengo que escribir código alguna vez.
duffymo

3
WebLogic es solo comercial, es a eso a lo que me refiero, una vez que escribe un cheque grande, está "bloqueado" en mayor medida que con una alternativa de código abierto. Obviamente, si le importa la independencia de la plataforma, no usaría las características específicas del proveedor, así que no es a eso a lo que me refiero. En realidad, una encuesta que leí una vez dijo que los desarrolladores creen que el bloqueo de proveedores para evitar es la ventaja # 1 del código abierto (no el costo).
Manius

¿Tonterías completas? ¿Crees que firmar un contrato multimillonario con un vendedor no te encierra? Ahí está tu prueba.
duffymo

@ymajoros ¿Quiso decir "no debería" tener un proveedor cerrado? Francamente, no puedo entender tu comentario.
Patrick M

1

Una alternativa: no utilizar ningún servidor de aplicaciones.

Revisa http://www.atomikos.com/Publications/J2eeWithoutApplicationServer .

Para proyectos web, mantenga un contenedor web ligero si es necesario, combinado con algo como Wicket para evitar la complejidad de JSP / JSF o puntales.

HTH Guy


Si no quieres aprender usando herramientas, no uses ninguna. O intente convertirse en un profesional calificado e invertir en su entorno, será recompensado. Debo admitir que hice eso para algunos proyectos. Los mismos proyectos no evolucionaron a ningún servidor de aplicaciones, a un cliente-servidor personalizado en Spring, a Java EE puro y Glassfish. Nunca quisiera volver, la primera solución era en realidad demasiado compleja, es tan simple como puede ser hoy (y estándar, se implementaría en cualquier servidor de aplicaciones Java EE sin muchos cambios).
ymajoros

buena respuesta, mala manera de obtener el documento
msangel
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.