Comparando OpenEjb y Glassfish

Question

¿Podemos reemplazar el pez de vidrio con Tomcat / OpenEJB para aplicaciones más ligeras? ¿Cuál es el rendimiento de OpenEJB en comparación con el pez de vidrio como contenedor EJB?

¿Cuáles son las restricciones de OpenEJB en lugar de GlassFish?

Saludos

Answer 1

Supongo que la pregunta es sobre el entorno de tiempo de ejecución, pero aún así, no entiendo qué significa la aplicación . Huella de memoria? ¿Tiempo de inicio? Tiempo de implementación? ¿Qué problema tienes realmente? Y por favor define la luz.

Por lo que vale la pena, considero que Glassfish 3 como un tiempo de ejecución ligero y mi experiencia con ella es muy positiva. Desde el producto hoja de datos :

Oracle Glassfish Server 3 Implementa el tiempo de ejecución de OSGI, lo que permite que las funciones se agreguen dinámicamente al servidor Java según sea necesario, y para que se despliegue la pila de Java más pequeña posible para admitir aplicaciones. Esto ayuda a mantener la huella lo más pequeña posible al cargar solo los módulos necesarios para que el servicio implementó las aplicaciones, lo que mejora el tiempo de inicio y la reducción de la utilización de los recursos.

segundo, personalmente no me gusta el enfoque de Frankenstein, Creo que el pegamento entre todas las partes que obtiene con un servidor de aplicaciones real es parte del valor agregado , en realidad, es por eso que uso un servidor de aplicaciones.

Tercero, nunca me fijé a OpenJB, lo usé para probar solo y nunca planeé usarlo para la producción, principalmente debido a su mala reputación. Consulte este comentario sobre las actuaciones de Geronimo en TSS (de Hani Suleiman , no se sorprenda si es cáustico):

Me imagino que decir que el EJB El nivel es 'aceptable' es sobre el cosa más bonita que podrías decir.

de lo que sé, el código EJB de Geronimo se basa en OpenEJB, que tiene, Históricamente, frijol el peor contenedor. Posiblemente podrías encontrar. Tendrías que Mira bastante duro para encontrarlo también, solo estar lleno de diversos grados de arrepentimiento / rabia una vez que logres eso Objetivo dudoso.

No es sorprendente que G's El rendimiento siempre será sub-par. El enfoque de Frankenstein del software. El edificio es una gran receta para mal. actuación. Claro, tendrás un montón de bonitos diagramas, excelente mirada Gráficos de dependencia, y acoplamiento suelto. Todos los cuales son bastante irrelevantes para Usuarios que quieren un servidor de aplicaciones coherentes. que pueden tratar como una caja negra.

Las cosas pueden haber cambiado, OpenEJB probablemente ha mejorado, al menos un poco, pero aún así:

• OpenEJB no apoya completamente EJB 3.1.
• Tomcat + OpenEJB aún no es una implementación completa de Java EE, es posible que tenga que agregar algunas piezas a su criatura (ni siquiera mencionar Java EE 6).
• ¿Y qué pasa con la administración, agrupamiento, etc.?
• Si no necesita el perfil completo de Java EE 6, está el perfil web de Java EE 6
• Estoy feliz con Glassfish 3, no lo descubro "pesado" (y sugiero probarlo).
• Sé que puede funcionar bien.

Por todas estas razones, no consideraría Tomcat + OpenEJB en lugar de Glassfish, especialmente si no hay problema para resolverlo.

Preguntas relacionadas

• ¿Qué tecnologías admite Tomcat Support
• ¿Qué es realmente una frijol Java Empresa realmente?
• ¿Las comparaciones del mundo real de Glassfish y Jboss 5?

Ver también

• glassfish 2 vs. tomcat 6
• puttlefish V3 en producción: guía de sobreviviente esencial

Answer 2

Tenga en cuenta que el comentario de Hani fue en lo que respecta a Geronimo 1.0 / OpenEJB 2.0. Hani estaba equivocado en el comentario de Frankenstein, ya que la base de código OpenEJB 2.x fue construida completamente desde cero para Geronimo y, como resultado, solo se ejecutó en Geronimo; Los modos incrustados, tomcat y estadios estaban perdidos. Encontramos que el comentario de Hani tenía razón en que la actuación no era buena.

Para OpenEjb 3.x Abandonamos la base de código 2.x y recogimos las cosas desde donde lo dejamos en OpenEjb 1.x y lo llevamos a la certificación EJB 3.0. 2.x y 3.x Compartir ningún código. OpenJB 3.x resultó muy bien y el proyecto se ha ido creciendo bastante rápido desde la primera versión 3.0 en 2008. El contenedor incrustado EJB 3.1 y los funciones de EJES en .wars vinieron de OpenEJB. Tuvimos la primera implementación de @singleton y esperamos completar el resto de EJB 3.1 y certificar el perfil web por Q4 este año. La conmutación por error y el monitoreo de JMX han estado bajo un desarrollo pesado desde enero, ahora están completos, y se lanzarán en 3.1.3 en un par de semanas. La conmutación por error es en realidad la segunda generación, el primer soporte de conmutación por error se lanzó en 3.1.1. Hubo un trabajo de rendimiento remoto significativo realizado en la versión 3.1.1, así que, así que brinda llamadas RPC a una media de 7300 TPS en nuestra evaluación comparativa.

Menos importante para algunos, pero muy importante para los demás, Apache OpenEJB no es un proyecto de código abierto controlado en corporativamente. La mayoría de los comités son usuarios que se han ganado comprometidos y usan OpenEJB en el trabajo. Esto tiene sus ventajas y desventajas, pero la línea de fondo es OpenEJB está llena de personas que lo aman y lo usan y la comunidad es tan abierta como la fuente.

Actualización

En octubre de 2011, obtuvimos la certificación de perfil web de Java EE 6 con "Tomcat + OpenEjb", ahora llamado Apache Tomee.

Certificado y con un nombre más claro, esperamos que esto haga que la pila sea más fácil de entender y comparar.

En una nota personal, veo los comentarios en este hilo como uno de los principales motivadores para tomar el paso de certificación. Gracias a todos en Stackoverlfow para comentarios que encuentro a la altura y puesta a tierra. Conectarse con esta comunidad ha resultado en un cambio tan positivo en OpenEJB / TOMEE.

Answer 3

En mis breves pruebas, encontré a GlassFish no lo suficientemente ligero para mis necesidades (tiempo de inicio y uso de la memoria).He estado feliz con OpenEJB hasta ahora.

Answer 4

Post realmente interesante. ¡Esa fue exactamente nuestra opinión (compañía) antes de probar OpenEJB 3.0, hace tres o cuatro años!

Ahora tenemos una buena experiencia con OpenEJB y es ampliamente utilizado en producción / desarrollo. Es realmente ligero y fácil de usar.Gracias a OpenEJB, los desarrolladores ahorran mucho tiempo (los mensajes de Matthew B. Jones también son una buena respuesta).

La comunidad es activa, de mente abierta y todo el tiempo listo para ayudar y mejorar el producto con características útiles provenientes de realimentación real de usuarios.

y por último, pero no menos importante, las actuaciones son realmente geniales!

jean-louis

Answer 5

OpenEjb como una alternativa ligera e incrustada a los servidores de aplicaciones independientes.Portamos nuestra solicitud de JBOSS y WEBLOGIC (tuvo que apoyar ambos) a Tomcat / OpenEJB sin problemas importantes.Las pruebas de rendimiento mostraron ganancias o no peor resultados.

La mayor restricción de OpenEJB es la documentación incompleta.Su sitio web está bien (en realidad es bastante decente para el proyecto de código abierto), pero no se puede comparar con JBoss, Glassfish, etc.

Otra cosa que debe ser consciente es que usa ActiveMQ como un proveedor de JMS, que es otro proyecto de código abierto.La integración con ActiveMQ es agradable, pero presenta algunas restricciones.Por ejemplo, no puede simplemente actualizar a la última versión de ActiveMQ.

Una vez más, como siempre, en la fuente abierta, la falta de apoyo y la documentación se compensa con acceso gratuito a fuentes y desarrolladores que lo escriben.

Answer 6

Creo que estoy parado por David Blevins en el sentido de que Glassfish ahora significa Oracle, y todos conocemos el legado que dejaron atrás con OC4J.Temo que Glassfish puede requerir más y más hardware para el mismo servicio.

De todos modos, el mejor consejo es: configurar un punto de referencia y probar ambas soluciones usted mismo, es una cuestión de no más de 20 horas de trabajo de expertos.