Aplicaciones web modulares
https://stackoverflow.com/questions/126073
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
he estado investigando OSGi Recientemente y creo que parece una muy buena idea para aplicaciones Java modulares.
Sin embargo, me preguntaba cómo funcionaría OSGi en una aplicación web, donde no solo tienes que preocuparte por el código, también HTML, imágenes, CSS, ese tipo de cosas.
En el trabajo, estamos creando una aplicación que tiene múltiples 'pestañas', siendo cada pestaña una parte de la aplicación.Creo que esto realmente podría beneficiarse al adoptar un enfoque OSGi; sin embargo, no estoy seguro de cuál sería la mejor manera de manejar todos los recursos habituales de las aplicaciones web.
No estoy seguro de si hace alguna diferencia, pero estamos usando JSF y caras de hielo (lo que añade otra capa de problemas porque tienes reglas de navegación y tienes que especificar todos los archivos de configuración de caras en tu web.xml...¡eh!)
Editar:de acuerdo a este hilo, los archivos faces-config.xml se pueden cargar desde archivos JAR, por lo que en realidad es posible incluir varios archivos faces-config.xml sin modificar web.xml, siempre que los divida en archivos JAR.
Cualquier sugerencia será muy apreciada :-)
Solución
Tiene mucha razón al pensar que hay sinergias aquí, tenemos una aplicación web modular donde la aplicación en sí se ensambla automáticamente a partir de componentes independientes (paquetes OSGi) donde cada paquete aporta sus propias páginas, recursos, CSS y, opcionalmente, JavaScript.
No usamos JSF (Spring MVC aquí), por lo que no puedo comentar sobre la complejidad adicional de ese marco en un contexto OSGi.
La mayoría de los marcos o enfoques que existen todavía se adhieren a la forma "antigua" de pensar:un archivo WAR que representa su aplicación web y luego muchos paquetes y servicios OSGi, pero casi ninguno se preocupa por la modularización de la GUI en sí.
Requisitos previos para un diseño
Con OSGi la primera cuestión a resolver es:¿Cuál es su escenario de implementación y quién es el contenedor principal?Lo que quiero decir es que puedes implementar tu aplicación en un tiempo de ejecución OSGi y usar su infraestructura para todo.Alternativamente, puede incrustar un tiempo de ejecución OSGi en un servidor de aplicaciones tradicional y luego necesitará reutilizar parte de la infraestructura, específicamente si desea utilizar el motor de servlet de AppServer.
Nuestro diseño actualmente se basa en OSGi como contenedor y utilizamos el servicio HTTP ofrecido por OSGi como nuestro contenedor de servlets.Estamos buscando proporcionar algún tipo de puente transparente entre un contenedor de servlet externo y el servicio HTTP OSGi, pero ese trabajo está en curso.
Boceto arquitectónico de una aplicación web modular Spring MVC + OSGi
Entonces, el objetivo no es solo servir una aplicación web a través de OSGi, sino también aplicar el modelo de componentes de OSGi a la propia interfaz de usuario web, para hacerla componible, reutilizable y dinámica.
Estos son los componentes del sistema:
- 1 paquete central que se encarga de unir Spring MVC con OSGi, específicamente utiliza código de Bernd Kolb para permitirle registrar Spring DispatcherServlet con OSGi como un servlet.
- 1 asignador de URL personalizado que se inyecta en DispatcherServlet y que proporciona la asignación de solicitudes HTTP entrantes al controlador correcto.
- 1 JSP decorador central basado en Sitemesh que define el diseño global del sitio, así como las bibliotecas centrales de CSS y Javascript que queremos ofrecer como predeterminadas.
Cada paquete que quiera contribuir con páginas a nuestra interfaz de usuario web debe publicar 1 o más controladores como servicios OSGi y asegurarse de registrar su propio servlet y sus propios recursos (CSS, JSP, imágenes, etc) con el servicio HTTP OSGi.El registro se realiza con HTTPService y los métodos clave son:
httpservice.registerResources () y httpservice.registerservlet ()
Cuando un paquete de contribución de interfaz de usuario web activa y publica sus controladores, nuestro paquete de interfaz de usuario web central los recoge automáticamente y el asignador de URL personalizado antes mencionado reúne estos servicios de controlador y mantiene un mapa actualizado de URL a instancias de controlador.
Luego, cuando llega una solicitud HTTP para una determinada URL, encuentra el controlador asociado y envía la solicitud allí.
El Responsable hace su trabajo y luego devuelve cualquier dato que deba ser entregado. y el nombre de la vista (un JSP en nuestro caso).Este JSP está ubicado en el paquete del Controlador y se puede acceder a él y procesarlo mediante el paquete de interfaz de usuario web central exactamente porque registramos la ubicación del recurso con el Servicio HTTP.Nuestro solucionador de vista central luego fusiona este JSP con nuestro decorador central Sitemesh y escupe el HTML resultante al cliente.
Sé que este es un nivel bastante alto, pero sin proporcionar la implementación completa es difícil de explicar completamente.
Nuestro punto clave de aprendizaje para esto fue observar lo que hizo Bernd Kolb con su ejemplo de conversión de JPetstore a OSGi y usar esa información para diseñar nuestra propia arquitectura.
En mi humilde opinión, actualmente hay demasiada publicidad y enfoque en integrar OSGi de alguna manera en aplicaciones tradicionales basadas en Java EE y se piensa muy poco en utilizar modismos OSGi y su excelente modelo de componentes para permitir realmente el diseño de aplicaciones web en componentes.
Otros consejos
Verificar Servidor SpringSource dm - un servidor de aplicaciones construido íntegramente en términos de OSGi y que admite aplicaciones web modulares.Está disponible en versiones comerciales, gratuitas y de código abierto.
Puede comenzar implementando un archivo WAR estándar y luego dividir gradualmente su aplicación en módulos OSGi o 'paquetes' en el lenguaje OSGi.Como es de esperar de SpringSource, el servidor tiene un excelente soporte para el marco Spring y los productos relacionados de la cartera de Spring.
Descargo de responsabilidad:Trabajo en este producto.
Tenga en cuenta el servidor Spring DM Licencia.
Hemos estado usando descansar con OSGi con buenos resultados con un servicio Http integrado (bajo las sábanas en realidad es Jetty, pero Tomcat también está disponible).
Restlet tiene necesidades de configuración XML mínimas o nulas, y cualquier configuración que hagamos se realiza en BundleActivator (registrando nuevos servicios).
Al crear la página, simplemente procesamos las implementaciones de servicios relevantes para generar el resultado, estilo decorador.Los nuevos paquetes que se conecten agregarán nuevas decoraciones/widgets de página la próxima vez que se procesen.
REST nos brinda URL agradables, limpias y significativas, múltiples representaciones de los mismos datos y parece una metáfora extensible (pocos verbos, muchos sustantivos).
Una característica adicional para nosotros fue el amplio soporte para el almacenamiento en caché, específicamente ETag.
SpringSource parece estar trabajando en un interesante marco web modular construido sobre OSGi llamado Rebanadas de SpringSource.Puede encontrar más información en las siguientes publicaciones del blog:
¡Echa un vistazo a RAP! http://www.eclipse.org/rap/
Echa un vistazo a http://www.ztemplates.org que es simple y fácil de aprender.Éste le permite colocar todas las plantillas relacionadas, javascript y css en un solo frasco y usarlo de forma transparente.Significa que ni siquiera tiene que preocuparse por declarar el javascript necesario en su página cuando utiliza un componente proporcionado, ya que el marco lo hace por usted.
Interesante conjunto de publicaciones.Tengo una aplicación web que se personaliza según el cliente.Cada cliente obtiene un conjunto básico de componentes y componentes adicionales según para qué se haya registrado.Para cada versión tenemos que "ensamblar" el conjunto correcto de servicios y aplicar la configuración de menú correcta (usamos el menú struts) según el cliente, lo cual es tedioso por decir lo menos.Básicamente es la misma base de código, pero simplemente personalizamos la navegación para exponer u ocultar ciertas páginas.Obviamente, esto no es ideal y nos gustaría aprovechar OSGi para componer los servicios.Si bien puedo ver cómo se hace esto para las API de servicio y entiendo cómo recursos como CSS y scripts y controladores java (usamos Spring MVC) también podrían agruparse, ¿cómo abordaría inquietudes "transversales" como la navegación de páginas? y flujo de trabajo general, especialmente en el escenario en el que desea implementar dinámicamente un nuevo servicio y necesita agregar navegación a ese servicio.También puede haber otras preocupaciones "transversales", como servicios que abarcan otros servicios.Gracias, Declan.
