模块化网络应用 [英] Modular web apps

问题描述

我最近一直在研究 OSGi 并认为它对于模块化 Java 应用.

I've been looking into OSGi recently and think it looks like a really good idea for modular Java apps.

然而，我想知道 OSGi 如何在 Web 应用程序中工作，在那里您不仅需要担心代码 - 还有 HTML、图像、CSS 之类的东西.

However, I was wondering how OSGi would work in a web application, where you don't just have code to worry about - also HTML, images, CSS, that sort of thing.

在工作中，我们正在构建一个具有多个选项卡"的应用程序，每个选项卡都是应用程序的一部分.我认为这真的可以从采用 OSGi 方法中受益 - 但是我真的不确定处理所有常用网络应用程序资源的最佳方式是什么.

At work we're building an application which has multiple 'tabs', each tab being one part of the app. I think this could really benefit from taking an OSGi approach - however I'm really not sure what would be the best way to handle all the usual web app resources.

我不确定它是否有任何区别，但我们使用的是 JSF 和 IceFaces(这增加了另一层问题，因为你有导航规则，你必须在你的 web.xml 中指定所有面配置文件......天！)

I'm not sure whether it makes any difference, but we're using JSF and IceFaces (which adds another layer of problems because you have navigation rules and you have to specify all faces config files in your web.xml... doh!)

根据这个线程，faces-config.xml 文件可以从 JAR 文件加载 - 因此实际上可以在不修改 web.xml 的情况下包含多个 faces-config.xml 文件，前提是您拆分为 JAR 文件.

according to this thread, faces-config.xml files can be loaded up from JAR files - so it is actually possible to have multiple faces-config.xml files included without modifying web.xml, provided you split up into JAR files.

任何建议将不胜感激:-)

Any suggestions would be greatly appreciated :-)

推荐答案

您认为这里有协同作用是非常正确的，我们有一个模块化 Web 应用程序，其中应用程序本身由独立组件(OSGi 包)自动组装，其中每个bundle 贡献自己的页面、资源、css 和可选的 javascript.

You are very right in thinking there are synergies here, we have a modular web app where the app itself is assembled automatically from independent components (OSGi bundles) where each bundle contributes its own pages, resources, css and optionally javascript.

我们不使用 JSF(此处为 Spring MVC)，因此我无法评论该框架在 OSGi 上下文中增加的复杂性.

We don't use JSF (Spring MVC here) so I can't comment on the added complexity of that framework in an OSGi context.

大多数框架或方法仍然坚持旧"的思维方式:一个代表您的 web 应用程序的 WAR 文件，然后是许多 OSGi 包和服务，但几乎没有一个关注 GUI 本身的模块化.

Most frameworks or approaches out there still adhere to the "old" way of thinking: one WAR file representing your webapp and then many OSGi bundles and services but almost none concern themselves with the modularisation of the GUI itself.

对于 OSGi，首先要解决的问题是:你的部署场景是什么，谁是主容器?我的意思是，您可以在 OSGi 运行时上部署您的应用程序，并将其基础设施用于一切.或者，您可以在传统应用服务器中嵌入 OSGi 运行时，然后您将需要重用一些基础设施，特别是您想要使用 AppServer 的 servlet 引擎.

With OSGi the first question to solve is: what is your deployment scenario and who is the primary container? What I mean is that you can deploy your application on an OSGi runtime and use its infrastructure for everything. Alternatively, you can embed an OSGi runtime in a traditional app server and then you will need to re-use some infrastructure, specifically you want to use the AppServer's servlet engine.

我们的设计目前基于 OSGi 作为容器，我们使用 OSGi 提供的 HTTPService 作为我们的 servlet 容器.我们正在考虑在外部 servlet 容器和 OSGi HTTPService 之间提供某种透明的桥梁，但这项工作正在进行中.

Our design is currently based on OSGi as the container and we use the HTTPService offered by OSGi as our servlet container. We are looking into providing some sort of transparent bridge between an external servlet container and the OSGi HTTPService but that work is ongoing.

因此，我们的目标不仅是通过 OSGi 为 Web 应用程序提供服务，还要将 OSGi 的组件模型应用于 Web UI 本身，使其可组合、可重用、动态.

So the goal is not to just serve a web application over OSGi but to also apply OSGi's component model to the web UI itself, to make it composable, re-usable, dynamic.

这些是系统中的组件:

• 1 个负责桥接 Spring MVC 与 OSGi 的中央包，特别是它使用 代码由 Bernd Kolb 提供 允许您将 Spring DispatcherServlet 注册为 OSGi 作为 servlet.
• 1 个自定义 URL 映射器，它被注入到 DispatcherServlet 中，并提供传入 HTTP 请求到正确控制器的映射.
• 1 个基于 Sitemesh 的中央装饰器 JSP，用于定义站点的全局布局，以及我们希望作为默认值提供的中央 CSS 和 Javascript 库.

• 想要为我们的 Web UI 贡献页面的每个包都必须发布 1 个或多个控制器作为 OSGi 服务，并确保注册自己的 servlet 和自己的资源(CSS、JSP、图像等)) 与 OSGi HTTPService.注册是通过 HTTPService 完成的，关键方法是:

• 1 central bundle that takes care of bridging Spring MVC with OSGi, specifically it uses code by Bernd Kolb to allow you to register the Spring DispatcherServlet with OSGi as a servlet.
• 1 custom URL Mapper that is injected into the DispatcherServlet and that provides the mapping of incoming HTTP requests to the correct controller.
• 1 central Sitemesh based decorator JSP that defines the global layout of the site, as well as the central CSS and Javascript libraries that we want to offer as defaults.

• Each bundle that wants to contribute pages to our web UI has to publish 1 or more Controllers as OSGi Services and make sure to register its own servlet and its own resources (CSS, JSP, images, etc) with the OSGi HTTPService. The registering is done with the HTTPService and the key methods are:

httpService.registerResources()和httpService.registerServlet()

httpService.registerResources() and httpService.registerServlet()

当 Web ui 贡献包激活并发布其控制器时，我们的中央 Web ui 包会自动获取它们，并且上述自定义 URL 映射器会收集这些控制器服务并保持控制器实例的最新 URL 映射.

When a web ui contributing bundle activates and publishes its controllers, they are automatically picked up by our central web ui bundle and the aforementioned custom URL Mapper gathers these Controller services and keeps an up to date map of URLs to Controller instances.

然后，当针对某个 URL 的 HTTP 请求传入时，它会找到关联的控制器并将请求分派到那里.

Then when an HTTP request comes in for a certain URL, it finds the associated controller and dispatches the request there.

控制器完成它的工作，然后返回任何应该呈现的数据和视图的名称(在我们的例子中是一个 JSP).这个 JSP 位于控制器的包中，可以被中央 web ui 包访问和呈现，因为我们使用 HTTPService 注册了资源位置.然后，我们的中央视图解析器将此 JSP 与我们的中央 Sitemesh 装饰器合并，并将生成的 HTML 输出给客户端.

The Controller does its business and then returns any data that should be rendered and the name of the view (a JSP in our case). This JSP is located in the Controller's bundle and can be accessed and rendered by the central web ui bundle exactly because we went and registered the resource location with the HTTPService. Our central view resolver then merges this JSP with our central Sitemesh decorator and spits out the resulting HTML to the client.

知道这是相当高的水平，但如果不提供完整的实现，就很难完全解释.

In know this is rather high level but without providing the complete implementation it's hard to fully explain.

我们对此的主要学习点是查看Bernd Kolb 做了什么 以他的示例将 JPestore 转换为 OSGi 并使用该信息来设计我们自己的架构.

Our key learning point for this was to look at what Bernd Kolb did with his example JPetstore conversion to OSGi and to use that information to design our own architecture.

恕我直言，目前有太多的炒作和专注于将 OSGi 以某种方式嵌入到基于 Java EE 的传统应用程序中，而很少考虑实际使用 OSGi 习语及其出色的组件模型来真正实现组件化 Web 的设计应用程序.

IMHO there is currently way too much hype and focus on getting OSGi somehow embedded in traditional Java EE based apps and very little thought being put into actually making use of OSGi idioms and its excellent component model to really allow the design of componentized web applications.

这篇关于模块化网络应用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！