Enterprise OSGi frameworks: Comparación de madurez Apache Aries vs. Eclipse Gemini

Question

Pregunta: A partir de hoy, ¿cuál de los dos marcos Enterprise OSGi es más maduro: Apache Aries o Eclipse Gemini?

He hecho una investigación básica de las capacidades de Aries y Gemini Enterprise OSGi. También he pasado por una pregunta similar: el contenedor de planos de Géminis y Apache Aries .

Mis requisitos y conclusiones a continuación. Apreciaré mucho sus entradas adicionales.

1. Contenedor de Blueprint: tanto Aries como Gemini parecen igualmente maduros en términos de implementación en comparación con la especificación de Blueprint.

2. Desarrollo web (se desarrollará contra JSR 286 utilizando Spring Portlet MVC):
   Aunque Gemini Web tiene sus raíces en Spring DM (de ahí mi preferencia inicial hacia el marco de Gemini), creo que Aries debería ser igualmente capaz de trabajar con las aplicaciones web basadas en Spring Portlet MVC.

3. JPA: Esta es mi mayor área de preocupación. Aunque inicialmente estaba más inclinado hacia Gemini (debido a sus raíces en Spring DM y al apoyo de la comunidad activa de SpringSource), creo que la madurez de la JPA de Gemini es bastante BAJA en comparación con la JPA de Aries. Razones:

   • Gemini JPA solo admite la integración con EclipseLink como proveedor de JPA. Me gustaría utilizar Hibernate. Aries JPA soporta Hibernate.
   • Refiriéndose a las limitaciones de Gemini JPA: especialmente la limitación # 5: Falta de soporte para transacciones JTA. Parece que Aries JPA es compatible con JTA ... Pero no he podido entrar en los detalles del nivel de soporte.

4. JNDI: Mis nuevas aplicaciones web tendrían que llamar a los EJB de sesión existentes desde un nivel de servicio alojado dentro del servidor de aplicaciones JBoss. Por lo tanto, el soporte de JNDI es crucial para mis aplicaciones web habilitadas para OSGi en el nivel de cliente.
   Parece que Gemini Naming aún no se ha lanzado, mientras que Aries ya tiene alguna capacidad en esta área.

Answer 1

La misma pregunta vino a mi mente y obtuve los siguientes resultados:

1: Gemini se basa en Spring, que tiene un pasado mucho más largo y ha demostrado ser mucho. Mientras miraba el código, Gemini parecía un poco más limpio con más posibilidades de extensión, sin embargo tuve problemas con los manejadores de espacio de nombres. Incluso con la versión 1.0.0 no esperó a los manejadores de espacio de nombres. Aries espera a los manejadores de NS de la misma manera que espera las referencias requeridas. Les pregunté a los chicos de OSGi y dijeron que la próxima especificación de Blueprint podría contener una API de manejador NS estándar que, en mi opinión, ayudaría mucho. Mi conclusión fue que uso Apache Aries, pero no es una decisión final. Reviso este tema en cada trimestre del año. También hice algunas sugerencias sobre cómo mejorar Blueprint y lo subí a la bugzilla de OSGi . Me gustaría implementar estas mejoras en el verano y, al mirar el código, sería mucho más fácil basarme en Gemini.

2: Géminis contiene un Tomcat incrustado. Si simplemente sueltas los paquetes en un equinoccio, funciona bastante bien. Sin embargo, contiene varias dependencias a Spring que quería evitar. Me gusta la primavera, pero quería menos dependencias que necesitaba. No creo que Aries tenga ningún apoyo importante en este tema. Finalmente comencé a usar Jetty que funciona con Myfaces y Jersey hasta ahora. No he probado nada más hasta ahora. También me gustaron más las posibilidades de configuración de Jetty. Un paquete de configuración se puede definir como una variable de entorno que puede ayudar mucho si desea ejecutar pruebas de integración como parte de su ciclo de vida de compilación. Si Gemini admite más opciones de configuración (como provenir de un paquete) pensaré en cambiarme a esa.

3: Como me gusta usar JTA, no era una opción para mí usar Gemini. Usé Aries JPA por un momento y me conformé con eso. Como trabajo con muchos colegas, soy responsable de su efectividad. Con Aries JPA tuve el problema de que no esperaba los servicios DataSourceFactory (si la conexión db está definida en persistence.xml) o los servicios DataSource (si jta-data-source o non-jta-data-source) están definidos. Significó que el orden de inicio del paquete es importante cuando utiliza Aries JPA.

No fue un problema hasta que usamos Glassfish y JNDI, ya que Glassfish comenzó los recursos de JNDI antes de nuestros paquetes OSGI. Cuando nos mudamos a limpiar el contenedor OSGI, comenzamos a tener problemas y mis colegas comenzaron a pasar una gran cantidad de tiempo tratando de obtener el paquete correcto para comenzar a ordenar.

Al final, simplemente agrupé Aries JPA en un paquete y reescribí las partes que no me gustaban. Esto significa que mantuve solo la parte del analizador persistence.xml y creé un proyecto propio en http://everit.org/osgi/jpa/org.everit.osgi.jpa.container/index.html donde me concentré sin tener estos problemas . Actualmente funciona con Hibernate y supongo que (no lo he intentado) con Eclipselink y OpenJPA con tiempo de compilación mejorado. El contenedor escrito por mí funciona bien con org.apache.aries.jpa.container.context y los manejadores de espacio de nombres de aries jpa blueprint.

4: Si utiliza un servidor de aplicaciones y está seguro de que su entorno JNDI se inicia antes que sus paquetes antes de usarlo. Sin embargo, no puede detectar la modificación o eliminar un recurso JNDI, por lo tanto, no sugiero utilizarlo dentro de OSGi. Si lo necesitaba debido a JPA, puedo sugerir mi implementación de contenedor :) que use los rastreadores de servicio OSGi estándar incluso si usa * -data-source en su persistence.xml con la expresión osgi: service / .... Si necesita un lugar de configuración central, le recomiendo que consulte la pestaña Configuración de felix-webconsole, Metatype y Configuration Admin de la especificación OSGi. Si define un ajuste de configuración con la ayuda de Metatypes, estarán disponibles en feilix-webconsole y, a través de la API de administración de configuración, podrá detectar los eventos de cambio de configuración. Probé y felix-webconsole también me funcionó en el par Equinox-Jetty.

Espero que mi entrada haya sido útil!