uso tipos programacion modulos modularidad ejercicios ejemplos como aplica java web-applications jsf modularity

java - tipos - Aplicaciones web modulares



tipos de modularidad (8)

He estado investigando OSGi recientemente y creo que parece una muy buena idea para las aplicaciones modulares de Java.

Sin embargo, me preguntaba cómo funcionaría OSGi en una aplicación web, donde no solo tienes que preocuparte por el código, sino también HTML, imágenes, CSS, ese tipo de cosas.

En el trabajo, estamos creando una aplicación que tiene múltiples ''pestañas'', cada pestaña es una parte de la aplicación. Creo que esto podría beneficiarse si tomas un enfoque OSGi; sin embargo, no estoy seguro de cuál sería la mejor manera de manejar todos los recursos habituales de la aplicación web.

No estoy seguro de si hace alguna diferencia, pero estamos usando JSF e IceFaces (lo cual agrega otra capa de problemas porque tienes reglas de navegación y tienes que especificar todos los archivos de configuración de rostros en tu web.xml ... doh! )

Editar: según este hilo , los archivos faces-config.xml se pueden cargar desde archivos JAR, por lo que es posible tener múltiples archivos faces-config.xml incluidos sin modificar web.xml, siempre que se dividan en archivos JAR.

Cualquier sugerencia sería muy apreciada :-)

Eche 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 contenedor y usarlo de forma transparente. Significa que incluso no tiene que preocuparse por declarar el javascript necesario en su página cuando utiliza un componente provisto, ya que el marco lo hace por usted.

Eche un vistazo al servidor de SpringSource dm : un servidor de aplicaciones construido completamente en términos de OSGi y compatible con aplicaciones web modulares. Está disponible en versiones gratuitas, de código abierto y comerciales.

Puede comenzar desplegando un archivo WAR estándar y luego dividir gradualmente su aplicación en módulos OSGi, o ''paquetes'' en OSGi-speak. Como cabría esperar de SpringSource, el servidor tiene un excelente soporte para el marco Spring y los productos relacionados de la cartera Spring.

Descargo de responsabilidad: yo trabajo en este producto.

Hemos estado utilizando Restlet con OSGi con buenos resultados con un servicio Http incorporado (bajo las cubiertas, en realidad es Jetty, pero tomcat también está disponible).

Restlet tiene necesidades de configuración XML de cero a mínimas, y cualquier configuración que hagamos es en el BundleActivator (registrando nuevos servicios).

Cuando construimos la página, solo procesamos las implementaciones de servicios relevantes para generar el estilo de decorador de salida. Los nuevos paquetes que se enchufan agregarán nuevas decoraciones / widgets de página la próxima vez que se procesen.

REST nos da direcciones URL bonitas, limpias y significativas, representaciones múltiples 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 el ETag.

Interesante conjunto de mensajes. Tengo una aplicación web personalizada por cliente. Cada cliente obtiene un conjunto básico de componentes y componentes adicionales en función de para qué se han suscrito. Para cada versión, tenemos que ''ensamblar'' el conjunto correcto de servicios y aplicar la configuración de menú correcta (usamos el menú struts) en función del cliente, lo que 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 lo ideal y nos gustaría aprovechar OSGi para componentes de servicios. Mientras puedo ver cómo se hace esto para las API de servicio y entiendo cómo los recursos como CSS y el script de java y los controladores (utilizamos Spring MVC) también se pueden agrupar, ¿cómo abordar las preocupaciones ''cruzadas'' como la navegación de página? 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 los servicios que abarcan otros servicios. Gracias, Declan.

Tenga en cuenta las licensing servidor de Spring DM.

Tiene mucha razón en pensar que hay sinergias aquí, tenemos una aplicación web modular donde la aplicación 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 añadida de ese marco en un contexto OSGi.

La mayoría de los marcos o enfoques que existen todavía se adhieren a la "vieja" forma de pensar: un archivo WAR que representa su aplicación web y luego muchos paquetes OSGi y servicios, pero casi ninguno se preocupa por la modularización de la GUI misma.

Requisitos previos para un diseño

Con OSGi, la primera pregunta para resolver es: ¿cuál es su escenario de implementación y quién es el contenedor principal? Lo que quiero decir es que puede implementar su aplicación en un tiempo de ejecución OSGi y usar su infraestructura para todo. Alternativamente, puede incorporar un tiempo de ejecución OSGi en un servidor de aplicaciones tradicional y luego tendrá que volver a utilizar cierta infraestructura, específicamente, desea usar el motor servlet de la AppServer.

Nuestro diseño se basa actualmente en OSGi como contenedor y usamos el servicio HTTPS ofrecido por OSGi como nuestro contenedor de servlets. Estamos buscando proporcionar algún tipo de puente transparente entre un contenedor externo de servlets y el servicio OSGi HTTPS pero ese trabajo está en curso.

Bosquejo arquitectónico de una aplicación web modular Spring MVC + OSGi

Entonces, el objetivo no es solo servir una aplicación web sobre OSGi sino también aplicar el modelo de componentes de OSGi a la interfaz de usuario web misma, para que sea composable, reutilizable y dinámico.

Estos son los componentes en el sistema:

  • 1 paquete central que se encarga de conectar Spring MVC con OSGi, específicamente utiliza el código de Bernd Kolb para permitirle registrar Spring DispatcherServlet con OSGi como servlet.
  • 1 URL Custom Mapper que se inyecta en el DispatcherServlet y que proporciona la asignación de las solicitudes HTTP entrantes al controlador correcto.
  • 1 decorador central basado en Sitemesh JSP que define el diseño global del sitio, así como las bibliotecas centrales de CSS y Javascript que queremos ofrecer como valores predeterminados.

  • Cada paquete que desea 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 OSGi HTTPService. El registro se realiza con el servicio HTTPS y los métodos clave son:

    httpService.registerResources () y httpService.registerServlet ()

Cuando un paquete de contribución web se activa y publica sus controladores, nuestro paquete de web ui central los selecciona automáticamente y el URLMapper personalizado recopila estos servicios del Controlador y mantiene un mapa actualizado de URL a las instancias del Controlador.

Luego, cuando aparece una solicitud HTTP para una determinada URL, encuentra el controlador asociado y envía allí la solicitud.

El Controlador hace lo suyo y luego devuelve todos los datos que se deben representar y el nombre de la vista (un JSP en nuestro caso). Este JSP se encuentra en el paquete del Controlador y el paquete web ui central puede acceder y representarlo exactamente porque fuimos y registramos la ubicación del recurso con el servicio HTTPS. Nuestro sistema de resolución de vista central luego combina este JSP con nuestro decorador central de Sitemesh y escupe el HTML resultante para el cliente.

Sabemos que este es un nivel bastante alto, pero sin proporcionar la implementación completa es difícil de explicar por completo.

Nuestro punto de aprendizaje clave para esto fue ver lo que Bernd Kolb hizo 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 exageración y me enfoco en conseguir OSGi de alguna manera incrustado en las aplicaciones tradicionales basadas en Java EE y muy poco pensando en usar modismos OSGi y su excelente modelo de componentes para realmente permitir el diseño de aplicaciones web componentes.