¿Cómo modularizar una aplicación empresarial con OSGi y EE6?

Question

Sé que ya hay algunas preguntas relacionadas con este tema, pero todavía no he podido encontrar una solución real.

Actualmente estoy desarrollando aplicaciones con EE6, usando JPA, CDI, JSF. Me gustaría adoptar un enfoque más modular que empaquetar todo en un WAR o EAR y desplegar todo en un Application Server.

estoy tratando de diseñar mis aplicaciones tan modular como sea posible mediante la separación de un módulo en 3 proyectos de Maven:

• API - contiene las interfaces de servicios (sin estado)
• Modelo - contiene las entidades JPA para el módulo específico
• Impl - contiene la implementación de la API, frijoles mayoría CDI

la vista lógica de cada módulo se bundeled actualmente dentro de un gran proyecto web, que es feo Ya había pensado en fragmentos de web, pero si extendía mis clases de bean y los archivos xhtml en archivos jar, tendría que implementar un enlace para que una aplicación web principal pudiera buscar los recursos. Este tipo de solución al menos me permitiría tener un cuarto proyecto por módulo que contendría toda la lógica de visualización relacionada con el módulo, lo cual es un buen comienzo.

Lo que quiero es no solo que pueda tener esos 4 tipos de proyectos, sino también que cada proyecto sea intercambiable en caliente. Esto me llevó a OSGi, que al principio fue genial hasta que me di cuenta de que las tecnologías EE6 no son muy compatibles con un Contenedor OSGi.

APP

Veamos primero APP. Hay algunos tutoriales [1] que explican cómo hacer un paquete OSGi habilitado para JPA, pero ninguno de estos tutoriales muestra cómo distribuir entidades en diferentes paquetes (el proyecto modelo de un módulo). Me gustaría tener, por ejemplo, tres módulos diferentes

• Core
• usuario
• Blog

El proyecto de modelo del módulo blog tiene una dependencia (en tiempo de compilación) en el proyecto modelo de usuario. El proyecto modelo del módulo de usuario tiene una dependencia (en tiempo de compilación) del proyecto modelo de core.

¿Cómo puedo hacer que JPA funcione en tal escenario sin tener que crear una Unidad de persistencia para cada proyecto de modelo de un módulo? Quiero una unidad de persistencia que conozca todas las entidades disponibles en tiempo de ejecución. Los proyectos modelo en los que se encuentran las entidades deberían ser, por supuesto, intercambiables en caliente. Tal vez necesite hacer un proyecto separado para cada cliente que importe todas las entidades necesarias de los proyectos y contenga un persistence.xml que incluya todos los elementos de configuración necesarios. ¿Hay algún complemento maven disponible para construir tales proyectos o incluso otros enfoques para resolver ese problema?

CDI

CDI es muy agradable. ¡Realmente lo amo y no quiero perderlo más! ¡Utilizo extensiones CDI como MyFaces CODI y DeltaSpike que son increíbles! Inyerto mis servicios (sin estado) en otros servicios o en la capa de visualización, lo cual es genial. Como mis servicios son apátridas, no debería ser un problema usarlos como OSGi Services, pero ¿qué hay de la integración de CDI en OSGi? Encontré una Glassfish CDI Extension [2] que sería la inyección de OSGi Services en CDI beans, pero también quiero que OSGi Services sean beans CDI. No estoy totalmente seguro de cómo lograr eso, probablemente tendría que usar BeanManager para crear instancias y luego registrar cada implementación para su interfaz en el registro de servicio dentro de un BundleActivator. ¿Hay alguna manera estándar para hacer eso? Me gustaría evitar cualquier dependencia (en tiempo de compilación) del marco OSGi.

También me gustaría usar mis servicios tal como los uso ahora mismo, sin cambiar nada (implementaciones no anotadas y puntos de inyección no calificados). Existe una extensión/subproyecto de JBoss Weld [3] que parece enfocarse en ese problema pero que parece estar inactiva, no puedo encontrar ninguna práctica recomendada o instrucciones prácticas. ¿Cómo puedo dejar mi implementación tal como está pero aún puedo usar OSGi? Quiero decir que no sería un gran problema agregar una anotación a las implementaciones, ya que cada implementación ya está anotada con una anotación de estereotipo, de todos modos me gustaría evitarlo.

JSF

Como se ha mencionado antes me gustaría poder difundir mi opinión módulo lógico sabia. Hasta donde yo sé, esto no es realmente posible de la caja. Pax Web [4] debería resolver eso de alguna manera, pero no estoy familiarizado con eso.

Me gustaría tener un proyecto "CoreWeb" en el módulo "core" que contiene una plantilla de Facelet, llamémoslo "template.xhtml". Una página JSF en un proyecto llamado "BlogWeb" en el módulo "blog" debería poder hacer referencia a esa plantilla y aplicar una composición.

Para poder ampliar la vista, introduciría una interfaz java "Extensión" que puede ser implementada por una clase específica de un módulo. Un controlador para una vista luego inyectaría todas las implementaciones de la extensión. Una extensión, por ejemplo, proporcionaría una lista de subvistas que se incluirán en una vista principal.

El mecanismo de extensión descrito puede implementarse fácilmente, pero los siguientes requisitos deben cumplirse:

• al añadir nuevos OSGi Bundles al servidor de aplicaciones, el conjunto de extensiones disponibles pueden cambiar, las extensiones debe estar disponible para el controlador de la vista.
• Las subvistas (de un paquete separado) que deberían incluirse en una vista principal deberían ser accesibles.

El concepto de un solo servidor pero las aplicaciones de división múltiple de Spring Slices [5] es muy interesante, pero parece limitarse a Spring DM Server y el proyecto también parece estar inactivo.

Resumen

Después de todos los ejemplos y comportamientos que he descrito espero que sabes lo que me gustaría achive. Es simplemente una aplicación EE6 que es muy dinámica y modular.

Lo que busco al final es al menos documentación sobre cómo hacer que todo funcione como yo lo esperaba o incluso mejor una solución que ya funcionaba.

[1] http://jaxenter.com/tutorial-using-jpa-in-an-osgi-environment-36661.html

[2] https://blogs.oracle.com/sivakumart/entry/typesafe_injection_of_dynamic_osgi

[3] http://www.slideshare.net/TrevorReznik/weldosgi-injecting-easiness-in-osgi

[4] http://team.ops4j.org/wiki//display/paxweb/Pax+Web

[5] https://jira.springsource.org/browse/SLICE

Answer 1

Para responder a algunas de sus preguntas , usando una sola unidad de persistencia pero extendiendo sus entidades a través de múltiples paquetes pletos is not recommended, but may occasionally work. Sin embargo, si sus entidades están tan estrechamente relacionadas que necesitan compartir una unidad de persistencia, dividirlas entre los módulos puede no tener sentido. Además, no olvide que puede manejar las dependencias en tiempo de compilación separando la implementación y la interfaz para cada entidad; la interfaz y la implementación no necesitan estar en el mismo paquete.

Para inyección de dependencia, es posible que le guste Blueprint. Varias implementaciones están disponibles y la mayoría de los servidores de aplicaciones con soporte empresarial OSGi admiten Blueprint de fábrica. Utiliza XML para agregar metadatos, por lo que las clases no necesitarán ninguna modificación.