Lo que la intención que tenga suena factible, con algunas salvedades:
La Vista: primer lugar, su capa de vista suena un poco mullido. Existen otras formas de modularizar los componentes JSF mediante el uso de componentes personalizados que evitarán los dolores de cabeza implicados al tratar de crear algo tan espectacular como los beans administrados de enlace tardío.
Los módulos en sí: En segundo lugar, sus módulos no parecen particularmente modulares. Su primera lista de viñetas lo hace parecer como si estuviera tratando de crear aplicaciones web interoperables, en lugar de módulos en sí. Mi idea de un módulo es que cada componente tenga un propósito bien definido y más o menos discreto. Al igual que ex es la base de vi. Si va por la ruta OSGi, entonces deberíamos definir modular como este: Modular, por el bien de esta discusión, significa que los componentes son intercambiables en caliente, es decir, pueden agregarse y eliminarse sin romperse la aplicación.
Dependencias: Me preocupa un poco su descripción de los módulos como "posiblemente dependiendo el uno del otro". Probablemente (espero) ya lo sepan, pero sus dependencias deben formar un gráfico acíclico dirigido. Una vez que introduce una dependencia circular, está pidiendo un mundo de dolor en términos de la posibilidad de mantenimiento de la aplicación. Una de las mayores debilidades de OSGi es que no impide las dependencias circulares, por lo que depende de usted hacer cumplir esto. De lo contrario, sus dependencias crecerán como kudzu y ahogarán gradualmente el resto del ecosistema de su sistema.
Servlets: Fuhgeddaboudit. No se pueden vincular tarde los servlets en una aplicación web, no hasta que la especificación de Servlet 3.0 esté en producción (como señaló Pascal). Para iniciar un servlet de utilidad por separado, deberá colocarlo en su propia aplicación.
Bueno, mucho para las advertencias. Pensemos en cómo esto podría funcionar:
Has definido tu propio módulo JSF para hacer ... ¿qué, exactamente? Vamos a darle un propósito definido, bastante trivial: una pantalla de inicio de sesión. Entonces creas tu pantalla de inicio de sesión, únete a ella con OSGi en tu aplicación y ... ¿luego qué? ¿Cómo sabe la aplicación que la funcionalidad de inicio de sesión está allí, si no la ha definido en su página .jspx? ¿Cómo sabe la aplicación navegar a algo que no puede saber que hay allí?
Hay formas de evitar esto usando inclusiones condicionales y similares (por ejemplo, <c:if #{loginBean.notEmpty}>), pero, como dijiste, las cosas se ponen un poco feas cuando tu loginBean administrado existe en otro módulo que puede que ni siquiera se haya introducido en la aplicación todavía De hecho, obtendrá una excepción de servlet a menos que exista loginBean. Entonces, ¿Qué haces?
Define una API en uno de sus módulos. Todos los beans administrados que pretende compartir entre módulos deben especificarse como interfaces en esta capa API. Y todos sus módulos deben tener implementaciones predeterminadas de cualquiera de estas interfaces que pretendan usar. Y esta API debe ser compartida entre todos los módulos interoperables. Luego puede usar OSGi y Spring para conectar juntos los beans especificados con su implementación.
Necesito tomar un momento para señalar que no es así como abordaría este problema. De ningún modo.Dado algo tan simple como una página de inicio de sesión, o incluso tan complicado como un gráfico de inventario, personalmente preferiría crear un componente JSF personalizado. Pero si el requisito es "Quiero que mis beans administrados sean modulares (es decir, hot-swappable, etc.)", esta es la única forma que conozco para que funcione. Y ni siquiera estoy completamente seguro de que funcionará. This email exchange sugiere que es un problema que los desarrolladores de JSF acaban de comenzar a trabajar. habas
me consideraría normalmente logrado ser parte de la capa de vista, y como tal, los utilizo sólo para la vista lógica y delegar todo lo demás a la capa de servicio. En mi opinión, hacer que los beans administrados sean de enlace tardío los promueve fuera de la capa de vista y dentro de la lógica comercial. Hay una razón por la cual todos esos tutoriales están tan enfocados en los servicios: porque la mayoría de las veces quiere considerar lo que le tomaría a su aplicación funcionar "sin cabeza", y lo fácil que sería "desollar" su vista si, por Por ejemplo, quería que se ejecutara, con toda su funcionalidad, en un teléfono Android.
Pero parece que mucho de lo que está trabajando es la lógica de visualización, por ejemplo, la necesidad de cambiar una plantilla de vista diferente. OSGi/Spring debería ser capaz de ayudar, pero necesitará algo en su aplicación para elegir entre las implementaciones disponibles: más o menos para lo que fue creado el Registro de Servicios de OSGi.
Eso deja recursos estáticos. Puede modularizar estos, pero recuerde que deberá definir una interfaz para recuperar estos recursos, y deberá proporcionar una implementación predeterminada para que su aplicación no se ahogue si faltan. Si i18n es una consideración, esta podría ser una buena manera de hacerlo. Si quisiera ser realmente intrépido, podría insertar sus recursos estáticos en JNDI. Eso los haría completamente intercambiables en caliente, y le ahorrará el esfuerzo de tratar de resolver qué implementación utilizar mediante programación, pero hay algunas desventajas: cualquier búsqueda fallida hará que su aplicación genere una NamingException. Y es excesivo. JNDI normalmente se usa en aplicaciones web para la configuración de la aplicación.
En cuanto a sus preguntas restantes:
Am I inventar una bicicleta aquí? ¿Hay soluciones estándar para eso?
Usted es, un poco. He visto aplicaciones que hacen esto tipo, pero pareces haber tropezado con un conjunto bastante único de requisitos.
¿Crees que OSGi es la tecnología adecuada para la tarea descrita?
Si necesita que los módulos se intercambien en caliente, sus opciones son OSGi y la interfaz ServiceLocator más liviana.
¿Es mi bosquejo de la aplicación OSGI más o menos correcto?
Realmente no puedo decir sin saber más sobre dónde están los límites de tus componentes. Por el momento, parece que está presionando a OSGi para que haga más de lo que es capaz de hacer.
Pero no confíe en mi palabra. Ifoundother leyendo material en estos lugares.
Y como preguntas sobre Spring Slices, this should be enough to get you started.Necesitarás un cliente de Git, y parece que te entrenarás en la aplicación mirando el código fuente. Y es un código de prototipo muy temprano.
http://blog.springsource.com/2008/04/29/web-applications-and-osgi/ – Bozho
http://sites.google.com/site/springosgi/ – Bozho