所以，我有一堆 OSGi 包 (.jars)，它们执行一堆“业务逻辑”。一切都很好，到目前为止，我一直在使用 gogo 命令行 shell 与捆绑包进行交互。
我想添加一个网络界面。
我最初的想法是将接口捆绑到同一个 OSGi 容器/实例中。我想我会制作一个轻量级嵌入式 Jetty 包，然后加载 .war。理论上，servlet 可以直接与其他 OSGi 服务对话。
在现实世界中，会有多个应用程序实例相互通信。我不确定对于每个业务应用程序来说，最好有 1 个 Web 界面连接到本地的每个 Web 界面还是 1 个 Web 界面。
对技术没有任何限制或偏好，只是它是开源的。
我的问题是；
- 这很糟糕吗？
- 有更好的方法吗？
- 我应该将 .war 和业务逻辑分成两个单独的进程吗？
So, I have a bunch of OSGi bundles (.jars) which perform a bunch of "business logic". All is good and up until now I've been interfacing with the bundles using the gogo command line shell.
I would like to add a web interface.
My initial thoughts are to bundle the interface into the same OSGi container/instance. I thought I would make a lightweight embedded Jetty bundle which in turn loads a .war. The servlets can then in theory talk directly with other OSGi services.
In the real world there will be several instances of the application that talk to each other. I'm not sure if it's best to have 1 web interface that connects to each one or 1 web interface locally for each business application.
There are no limitations or preferences for technology, only that it be open source.
My question is;
- Does this suck?
- Is there a better way to do this?
- Should I separate the .war and the business logic into two separate processes?
发布评论
评论（3）
看一下 Virgo Web Server，以前称为 Spring DM Server。它内置了一个成熟的 servlet 容器，是一个完整的 OSGi 容器，如果您想走这条路，它还内置了 Spring DM。我认为没有任何理由将网络和业务内容分成单独的流程。是否拥有单个 Web 应用程序或每个业务捆绑包似乎更像是一个设计问题：“它是一个结合了许多潜在问题的单一 UI，还是这些都是单独的问题？”
Take a look at Virgo Web Server, formerly Spring DM Server. It's got a full-blown servlet container baked right in, is a full OSGi container, and also has Spring DM built in if you want to go that route. I don't think there's any reason to split the web and business stuff into separate processes. Whether to have a single webapp or one per business bundle seems like more of a design question: "Is it a single UI that combines many underlying concerns, or are these all separate concerns?"
最简单的方法是使用 OSGi HttpService 注册您的 servlet，例如由 Apache Felix HTTP 服务 捆绑包。我认为 Felix 的变体嵌入了 Jetty，但你不必关心，在 OSGi 级别你只看到标准的 HttpService。
加上生成 JSON 的服务器端库（我使用 Apache Sling commons.json 捆绑），以及像 jQuery 这样的客户端库，您就拥有了一个强大而简单的工具包，您的 servlet 可以充当 OSGi 服务的前端。
The simplest way is to register your servlets with the OSGi HttpService, provided for example by the Apache Felix HTTP Service bundle. I think the Felix variant of that embeds Jetty, but you don't have to care, at the OSGi level you just see the standard HttpService.
Coupled with a server-side library that generates JSON (I am using the Apache Sling commons.json bundle), and a client-side library like jQuery, you have a powerful yet simple toolkit where your servlets can act as front-ends for your OSGi services.
听起来您的 Web 界面是管理界面而不是最终用户界面？
如果是这种情况，请查看 Felix Webconsole，您可以通过编写 轻松扩展它一个href="http://felix.apache.org/site/providing-web-console-plugins.html" rel="nofollow">插件
另外，控制台本身是可换肤的，所以如果它只是一个内部应用程序那么这可能是最容易实现的。有许多用于管理/查看的插件
，我不会嵌入 Jetty，因为 Betrand 指出有 HTTP 服务实现，但也有 PAX Web 允许直接部署战争。
RE：“我应该将 .war 和业务逻辑分成两个单独的进程吗？”我不会为了它而分发应用程序，除非（需要高可用性或负载平衡），但您绝对应该将应用程序拆分为一个瘦小的战争（仅 UI 内容）和单独的服务包。
Web 应用程序是否应管理所有实例或每个实例一个实例取决于许多其他因素；
不确定您打算如何让应用程序进行通信，但 Apache CXF 可以通过 Web 服务实现远程服务规范，并且 Eclipse 通信框架提供了更多传输协议。
It sounds like your web interface is a management interface not an end user interface?
If that's the case then have a look at the Felix webconsole, you can easily extend it by writing a plugin
Also the console itself is skinnable, so if it's just an internal application then this will probably be the simplest to implement. There's a number of plugins for managing/viewing
I wouldn't embed Jetty, as Betrand states there's the HTTP Service implementation, but also PAX Web which will allow to deploy wars directly.
RE:"Should I separate the .war and the business logic into two separate processes?" I wouldn't distribute the app for the sake of it unless (High availability or load balancing necessitate), but you should definitely split the app into a skinny war (UI stuff only) and separate service bundles.
Whether the web app should manage all instances or one per instance depends on a lot of other things;
Not sure how you're planning to get the apps to communicate, but Apache CXF can implement the Remote Services spec over webservices and Eclipse Communication Framework provides many more transport protocols.