您非常认为这里有协同作用，我们有一个模块化的Web应用程序，该应用程序本身是由独立组件（OSGi捆绑软件）自动组装而成的，每个捆绑软件都贡献自己的页面，资源，css和可选的javascript。
我们不使用JSF（此处为Spring MVC），因此我无法评论OSGi上下文中该框架增加的复杂性。
那里的大多数框架或方法仍然遵循“旧的”思维方式：一个代表您的Web应用程序的WAR文件，然后是许多OSGi捆绑软件和服务，但几乎没有人关心GUI本身的模块化。
设计先决条件
使用OSGi，要解决的第一个问题是：您的部署方案是什么，谁是主要容器？我的意思是，您可以在OSGi运行时上部署应用程序，并将其基础结构用于所有内容。另外，您可以将OSGi运行时嵌入到传统的应用服务器中，然后需要重新使用某些基础结构，特别是要使用AppServer的servlet引擎。
当前，我们的设计基于OSGi作为容器，并且我们使用OSGi提供的HTTPService作为我们的servlet容器。我们正在寻求在外部servlet容器和OSGi
HTTPService之间提供某种透明的桥梁，但是这项工作仍在进行中。
Spring MVC + OSGi模块化Webapp的架构图
因此，目标不仅是通过OSGi服务Web应用程序，而且还将OSGi的组件模型应用于Web UI本身，以使其可组合，可重用，动态。
这些是系统中的组件：
- 1个中央软件包，负责将Spring MVC与OSGi桥接，特别是它使用Bernd Kolb的代码来允许您将OSGi的Spring DispatcherServlet注册为Servlet。
- 1个自定义URL映射器，已注入DispatcherServlet中，并提供将传入的HTTP请求映射到正确的控制器。
- 1个基于Sitemesh的中央装饰器JSP，它定义了站点的全局布局，以及我们要提供的默认CSS和Javascript库。
- 每个要向我们的Web UI贡献页面的包都必须发布1个或多个Controller作为OSGi服务，并确保向OSGi HTTPService 注册其自己的servlet和其自己的资源（CSS，JSP，图像等） 。注册使用HTTPService完成，主要方法为：
httpService.registerResources（）和httpService.registerServlet（）
当一个Web ui贡献捆绑包激活并发布其控制器时，它们将由我们的中央Web
ui捆绑包自动拾取，并且上述自定义URL映射器将收集这些Controller服务并保持URL到Controller实例的最新映射。
然后，当针对某个URL的HTTP请求进入时，它将找到关联的控制器并将请求分派到该控制器。
Controller开展业务，然后返回所有应呈现的数据 和
视图名称（在本例中为JSP）。该JSP位于Controller的捆绑包中，并且可以由中央Web
ui捆绑包访问和呈现此JSP，这恰恰是因为我们通过HTTPService注册了资源位置。然后，我们的中央视图解析器将此JSP与我们的中央Sitemesh装饰器合并，并将生成的HTML吐出到客户端。
众所周知，这是一个很高的层次，但是如果不提供完整的实现，则很难完全解释。
我们对此的主要学习点是看Bernd
Kolb在他的示例JPetstore转换为OSGi方面所做的工作，并使用该信息来设计我们自己的体系结构。
恕我直言，目前有太多的炒作，并且专注于以某种方式将OSGi嵌入到基于Java
EE的传统应用程序中，几乎没有考虑过实际使用OSGi习惯用法及其出色的组件模型来真正允许设计组件化Web应用程序。
