模块化网络应用程序 [英] 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.

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

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文件中加载 - 所以实际上可以包含多个faces-config.xml文件而不修改web.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 :-)

推荐答案

你认为这里有协同效应是非常正确的，我们有一个模块化的网络应用程序wh应用程序本身是从独立组件（OSGi包）自动组装的，其中每个包都提供自己的页面，资源，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.

大多数框架或方法仍然坚持旧 思维方式：一个代表你的webapp的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个中央捆绑包它负责使用OSGi桥接Spring MVC，特别是它使用了 Bernd Kolb的代码允许您使用OSGi作为servlet注册Spring DispatcherServlet。


• 1个自定义URL映射器，它被注入DispatcherServlet并提供传入HTTP请求到正确控制器的映射。


• 1个基于Sitemesh的中心装饰器JSP t hat定义了网站的全局布局，以及我们想要提供的默认中央CSS和Javascript库。



• 每个想要向我们的网站贡献页面的包UI必须将一个或多个控制器发布为OSGi服务，并确保使用OSGi HTTPService注册自己的servlet及其自己的资源（CSS，JSP，图像等）。注册是通过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映射器收集这些Controller服务，并保存到Controller实例的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.

然后当HTTP请求进入某个URL时，它会找到相关的控制器并在那里发送请求。

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

Controller完成其业务，然后返回应该呈现和视图名称的任何数据（在我们的示例中为JSP）。这个JSP位于Controller的包中，可以由中央web ui bundle完全访问和呈现，因为我们使用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做了什么他的示例JPetstore转换为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屋！