java 模块化网络应用
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/126073/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Modular web apps
提问by Boris Terzic
I've been looking into OSGirecently and think it looks like a really good idea for modular Java apps.
我最近一直在研究OSGi，并认为它对于模块化 Java 应用程序来说是一个非常好的主意。
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 如何在 Web 应用程序中工作，您不仅需要担心代码——还有 HTML、图像、CSS 之类的东西。
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.
在工作中，我们正在构建一个具有多个“选项卡”的应用程序，每个选项卡都是应用程序的一部分。我认为这真的可以从采用 OSGi 方法中受益 - 但是我真的不确定处理所有常用 Web 应用程序资源的最佳方法是什么。
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!)
我不确定它是否有任何区别，但我们正在使用 JSF 和IceFaces（这增加了另一层问题，因为您有导航规则，并且您必须在 web.xml 中指定所有面配置文件...哦！ )
Edit: 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.
编辑：根据这个线程，faces-config.xml 文件可以从 JAR 文件加载 - 因此实际上可以包含多个 faces-config.xml 文件而无需修改 web.xml，前提是您拆分为 JAR 文件。
Any suggestions would be greatly appreciated :-)
任何建议将不胜感激 ：-）
回答by Boris Terzic
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.
您认为这里有协同作用是非常正确的，我们有一个模块化 Web 应用程序，其中应用程序本身由独立组件（OSGi 包）自动组装，其中每个包贡献自己的页面、资源、css 和可选的 javascript。
We don't use JSF (Spring MVC here) so I can't comment on the added complexity of that framework in an OSGi context.
我们不使用 JSF（此处为 Spring MVC），因此我无法评论该框架在 OSGi 上下文中增加的复杂性。
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.
大多数框架或方法仍然坚持“旧”的思维方式：一个代表您的 web 应用程序的 WAR 文件，然后是许多 OSGi 包和服务，但几乎没有一个关注 GUI 本身的模块化。
Prerequisites for a Design
设计的先决条件
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 运行时上部署您的应用程序，并将其基础设施用于一切。或者，您可以将 OSGi 运行时嵌入到传统的应用程序服务器中，然后您将需要重新使用一些基础设施，特别是您想要使用 AppServer 的 servlet 引擎。
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 作为容器，我们使用 OSGi 提供的 HTTPService 作为我们的 servlet 容器。我们正在考虑在外部 servlet 容器和 OSGi HTTPService 之间提供某种透明的桥梁，但这项工作正在进行中。
Architectural Sketch of a Spring MVC + OSGi modular webapp
Spring MVC + OSGi 模块化 webapp 的架构草图
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.
因此，目标不仅仅是通过 OSGi 为 Web 应用程序提供服务，还要将 OSGi 的组件模型应用于 Web UI 本身，使其可组合、可重用、动态。
These are the components in the system:
这些是系统中的组件：
- 1 central bundle that takes care of bridging Spring MVC with OSGi, specifically it uses code by Bernd Kolbto 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() and httpService.registerServlet()
- 1 个负责桥接 Spring MVC 与 OSGi 的中央包，特别是它使用Bernd Kolb 的代码来允许您将带有 OSGi 的 Spring DispatcherServlet 注册为 servlet。
- 1 个自定义 URL 映射器，注入 DispatcherServlet 并提供传入 HTTP 请求到正确控制器的映射。
- 1 个基于 Sitemesh 的中央装饰器 JSP，它定义了站点的全局布局，以及我们希望作为默认值提供的中央 CSS 和 Javascript 库。
每个想要向我们的 Web UI 贡献页面的包都必须发布 1 个或多个控制器作为 OSGi 服务，并确保向OSGi HTTPService注册自己的 servlet 和自己的资源（CSS、JSP、图像等）。注册是通过 HTTPService 完成的，关键方法是：
httpService.registerResources() 和 httpService.registerServlet()
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.
当 Web ui 贡献包激活并发布其控制器时，我们的中央 Web ui 包会自动获取它们，并且前面提到的自定义 URL 映射器会收集这些控制器服务并保持控制器实例的最新 URL 映射。
Then when an HTTP request comes in for a certain URL, it finds the associated controller and dispatches the request there.
然后，当针对某个 URL 的 HTTP 请求进入时，它会找到关联的控制器并在那里分派请求。
The Controller does its business and then returns any data that should be rendered andthe 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.
控制器完成它的工作，然后返回任何应该呈现的数据和视图的名称（在我们的例子中是一个 JSP）。这个 JSP 位于控制器的包中，可以被中央 web ui 包访问和呈现，因为我们使用 HTTPService 注册了资源位置。然后，我们的中央视图解析器将这个 JSP 与我们的中央 Sitemesh 装饰器合并，并将生成的 HTML 输出给客户端。
In know this is rather high level but without providing the complete implementation it's hard to fully explain.
知道这是相当高的水平，但如果不提供完整的实现，就很难完全解释。
Our key learning point for this was to look at what Bernd Kolb didwith his example JPetstore conversion to OSGi and to use that information to design our own architecture.
我们对此的主要学习点是查看Bernd Kolb用他的示例 JPetstore 转换为 OSGi做了什么，并使用该信息来设计我们自己的架构。
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.
恕我直言，目前有太多的炒作和关注让 OSGi 以某种方式嵌入到传统的基于 Java EE 的应用程序中，而很少考虑实际使用 OSGi 习语及其出色的组件模型来真正允许组件化 Web 应用程序的设计。
回答by Glyn Normington
Check out SpringSource dm Server- an application server built entirely in terms of OSGi and supporting modular web applications. It is available in free, open source, and commercial versions.
查看SpringSource dm Server- 完全根据 OSGi 构建并支持模块化 Web 应用程序的应用程序服务器。它有免费、开源和商业版本。
You can start by deploying a standard WAR file and then gradually break your application into OSGi modules, or 'bundles' in OSGi-speak. As you might expect of SpringSource, the server has excellent support for the Spring framework and related Spring portfolio products.
您可以从部署标准 WAR 文件开始，然后逐渐将您的应用程序分解为 OSGi 模块或 OSGi 中的“包”。正如您对 SpringSource 所期望的那样，该服务器对 Spring 框架和相关的 Spring 产品组合产品具有出色的支持。
Disclaimer: I work on this product.
免责声明：我正在研究这个产品。
回答by Pavol Juhos
SpringSource seems to be working on an interesting modular web framework built on top of OSGi called SpringSource Slices. More information can be found in the following blog posts:
SpringSource 似乎正在开发一个有趣的模块化 Web 框架，该框架构建在 OSGi 之上，称为SpringSource Slices。可以在以下博客文章中找到更多信息：
回答by jamesh
We've been using Restletwith OSGi to good effect with an embedded Http service (under the covers it's actually Jetty, but tomcat is available too).
我们一直在使用带有 OSGi 的Restlet，通过嵌入式 Http 服务取得了良好的效果（在幕后，它实际上是 Jetty，但也可以使用 tomcat）。
Restlet has zero to minimal XML configuration needs, and any configuration we do is in the BundleActivator (registering new services).
Restlet 的 XML 配置需求从零到最少，我们所做的任何配置都在 BundleActivator（注册新服务）中。
When building up the page, we just process the relevant service implementations to generate the output, decorator style. New bundles getting plugged in will add new page decorations/widgets the next time its rendered.
在构建页面时，我们只处理相关的服务实现以生成输出，装饰器样式。插入的新包将在下次呈现时添加新的页面装饰/小部件。
REST gives us nice clean and meaningful URLs, multiple representations of the same data, and seems an extensible metaphor (few verbs, many nouns).
REST 为我们提供了干净且有意义的 URL，相同数据的多种表示，并且似乎是一个可扩展的隐喻（很少动词，很多名词）。
A bonus feature for us was the extensive support for caching, specifically the ETag.
我们的一个额外功能是对缓存的广泛支持，特别是 ETag。
回答by jamesh
Have a look at RAP! http://www.eclipse.org/rap/
回答by jamesh
Take a look at http://www.ztemplates.orgwhich is simple and easy to learn. This one allows you to put all related templates, javascript and css into one jar and use it transparently. Means you even have not to care about declaring the needed javascript in your page when using a provided component, as the framework does it for you.
看看http://www.ztemplates.org，它简单易学。这个允许您将所有相关模板、javascript 和 css 放在一个 jar 中并透明地使用它。意味着在使用提供的组件时，您甚至不必关心在页面中声明所需的 javascript，因为框架会为您完成。
回答by jamesh
Interesting set of posts. I have a web application which is customized on a per customer basis. Each customer gets a core set of components and additional components depending on what they have signed up for. For each release we have to 'assemble' the correct set of services and apply the correct menu config (we use struts menu) based on the customer, which is tedious to say the least. Basically its the same code base but we simply customize navigation to expose or hide certain pages. This is obviously not ideal and we would like to leverage OSGi to componentize services. While I can see how this is done for service APIs and sort of understand how resources like CSS and java script and controllers (we use Spring MVC) could also be bundled, how would you go about dealing with 'cross cutting' concerns like page navigation and general work flow especially in the scenario where you want to dynamically deploy a new service and need to add navigation to that service. There may also be other 'cross cutting' concerns like services that span other of other services. Thanks, Declan.
有趣的一组帖子。我有一个基于每个客户定制的 Web 应用程序。每个客户都会获得一组核心组件和附加组件，具体取决于他们注册的内容。对于每个版本，我们必须根据客户“组装”正确的服务集并应用正确的菜单配置（我们使用 struts 菜单），这至少可以说是乏味的。基本上它是相同的代码库，但我们只是自定义导航以显示或隐藏某些页面。这显然不理想，我们希望利用 OSGi 来组件化服务。虽然我可以看到这是如何为服务 API 完成的，并了解如何将 CSS 和 java 脚本和控制器（我们使用 Spring MVC）等资源捆绑在一起，但您将如何处理“横切” 关注页面导航和一般工作流程，尤其是在您想要动态部署新服务并需要向该服务添加导航的场景中。也可能存在其他“交叉”问题，例如跨越其他其他服务的服务。谢谢，德克兰。
