嵌入式 OSGi 或应用程序包
我刚刚花了两天时间阅读了我能得到的所有 OSGi 内容，我终于认为我已经了解了它。
我现在正尝试将其与现有应用程序集成，原因有很多，例如第 3 方插件、自动更新，更不用说 SOA 让我很高兴。
我现在有一个我正在努力做出的决定，那就是天气。
- 我的整个应用程序应该成为容器中默认安装的 OSGi 包； 或者
- 我的应用程序应该启动嵌入式 OSGi 容器并与它交互以获取所有插入的服务。
我更喜欢 1，因为这可以让我轻松更新应用程序并且架构保持一致。 当然，我希望必须将应用程序重构为许多更小的包。 然而2在短期内让事情变得更容易，但在未来会变得尴尬。
I've just spent the last two days reading up all the OSGi stuff I can get my hands on and I finally think I've got my head around it.
I'm now trying to integrate it with an existing application for many reasons such as 3rd party plugins, automatic updates, not to mention that SOA just makes me happy.
I now have a decision I'm struggling to make, which is weather
- My entire application should become an OSGi bundle installed by default in the container; or
- My application should launch an embedded OSGi container and interact with it for all the plugged services.
I'd prefer 1, as this lets me update the application easily and the architecture would be consistent. Of course I expect to have to refactor the application into many smaller bundles. However 2 makes things much easier in the short term, but will become awkward in the future.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
对于选项 1），您确实不希望将整个应用程序放在一个捆绑包中 - 您将失去 OSGi 的所有好处 - 但这实际上取决于您的应用程序的大小。
这实际上取决于您想要运行应用程序的位置以及您希望它执行的任务。 此外，您可能希望有某种远程处理来访问公开的服务。
在选项 1 中）您需要启用某种 http/servlet 捆绑包（存在一个桥）
在选项 2）中，您的应用程序可以在应用程序服务器内运行，因此您不必担心这一点。
您要问自己的第一个问题是关于操作环境的。 谁将运行该应用程序？ 他们需要/想要接受 OSGi 培训吗？ 他们对 J2EE 堆栈更满意吗？
我认为对你来说最好的选择是保持你的选择开放，1) 和 2) 之间没有真正的区别，但是 OSGi 框架关注的是你的代码或框架代码。 您的应用程序本身，即构成您的应用程序的捆绑包将完全相同。
我的建议是不要过多担心 OSGi 运行时 - 但从 OSGi 开发开始 - 没有什么可以阻止你开发“OSGi 风格”并在标准 JRE 环境中运行。
for option 1) you really don't want your whole application in one bundle - you would loose all the benefit from OSGi - but really that depend on the size of your application.
It really depends where you want to run application and which task you want it to perform. Also you probably want to have some kind of remoting to access the exposed services.
in option 1) you need to enable some kind of http/servlet bundle (there is a bridge that exists)
in option 2) you application can run inside an application server so you don't have to worry about that.
The first question you want to ask yourself is about the operational environment. Who is going to run the application? Do they need/want to be trained on OSGi? Are they more comfortable with the J2EE stack?
I think the best option for you is to keep your options open, there is no real differences between 1) and 2) but what is staring the OSGi framework, either your code or the framework code. Your application itself, ie the bundles constituting your application will be exactly the same.
My advice would be not to worry too much about OSGi runtime to start with - but start on OSGi development - nothing stop you from developing "OSGi-style" and running in a standard JRE environment.
我认为您想要采用选项 1，并让您的应用程序由一组位于（大多数是开箱即用的）OSGi 容器内的捆绑包组成。
所以我想说，即使在短期内，选项 1 也可能更容易。
另外，我同意 Patrick 的断言，即您的大部分代码不需要关心它是在 OSGi 还是在普通 JVM 中运行。 特别是当使用声明性服务时，代码中使用 OSGi 接口和机制的需要大大减少：您只需将一些描述符文件添加到 jar 的 META-INF 中即可。
I think you want to go with option 1, and have your application consist of a set of bundles inside of an (mostly out-of-the-box) OSGi container.
So I'd say that even in the short run, option 1 is probably easier.
Also, I agree with Patrick's assertion that the bulk of your code does not need to care if it runs in OSGi or in a plain JVM. Especially when using Declarative Services and such the need to use OSGi interfaces and mechanisms from your code is greatly reduced: You just add a few descriptor files to the jar's META-INF.
我宁愿选择选项2，
从本质上讲，您的应用程序不是一个捆绑包，而是一个应用程序。
如果您想要增加 OSGi 的价值，请从您的应用程序中生成 OSGi 容器。
这样，将来如果您决定放弃 OSGi，您可以通过简单的方式完成。
I would rather go with option 2,
Inherently your application is not a bundle, but an application.
If you want the OSGi value addition, spawn the OSGi container from within your application.
That way, at a future date if you decide to move away from OSGi, you can do in a simple way.
你看过 Spring 应用服务器吗？ 这难道不允许你管理这些东西吗？
Have you looked at the Spring Application server? Doesn't this allow you to manage this stuff?
我肯定会推荐 1 - 应用程序应该成为 OSGi 捆绑包，不仅仅是因为易于更新。 如果你的代码一半在OSGi框架中，一半在外部，你就必须为这两部分之间的通信构建一座桥梁； 您还可能会遇到类可见性问题。
1的好处也很多，而且实现起来也不是那么困难。 我的建议如下：
您不必拥有许多模块 - OSGi 可以轻松处理两个每个 10 MB 的包以及 100 个较小的包。 分离应该是功能本身的结果 - 一个好的起点是您在开始实现这些东西之前可能已经绘制的 UML 架构图。 不同功能部分相互通信的地方正是您应该考虑定义接口而不是类的地方 - 然后这些接口将成为您的 OSGi 服务，实现将成为捆绑包 - 下次您将拥有要更新某些部分，您会发现预测对应用程序其他部分的影响要容易得多，因为您将其清楚地分开并在捆绑包的清单中声明了它。
将您在单独的捆绑包中使用的任何外部/开源库分开。 它们很可能是需要比您自己的代码更频繁地更新并且在不同的时间线上更新的部分。 这里还更重要的是定义明确的包依赖关系、包版本，并避免依赖于实现部分而不是仅依赖于接口！
将
考虑一下您想要向插件公开应用程序的哪些部分。 然后用这些部分制作 OSGi 服务 - 即在 OSGi 注册表中发布接口。 您不需要实现任何特定的事情 - 您可以发布任何 Java 对象。 然后插件将使用注册表进行查找。
插件也是如此 - 考虑您想从插件获得什么，并定义插件可以实现和发布以及您的应用程序可以在注册表中查找的相应接口。
最后一个提示 - 查看您选择的 OSGi 框架中已有哪些可用的捆绑包。 OSGi 规范定义了许多标准 OSGi 接口 - 用于配置、日志记录、持久存储、远程连接、用户管理、事件处理等等。 由于它们是标准的，因此您可以使用它们而无需依赖任何特定的 OSGi 实现。 并卸载您不需要的内容。
I would definitely recommend 1 - the app should become an OSGi bundle(s), and not only because of easy updating. If half of your code is in the OSGi framework and half is outside, you will have to construct a bridge for the communication between the two halves; you could also have issues with classes visibility.
There are also many benefits from 1, and it is not so difficult to achieve. What I would recommend is the following:
You are not forced to have many modules - OSGi can as easily handle two bundles 10 MB each as well as 100 smaller bundles. The separation should be a result of the functionality itself - a good starting point is the UML architecture diagram you probably did before you even started implementing the stuff. The places where the different functional parts communicate with each other are exactly the places where you should think about defining interfaces instead of classes - and these interfaces will then become your OSGi services and the implementations will become the bundles - and the next time you will have to update some part you will find out it is much easier to predict the effect on the other parts of the app because you separated it clearly and declared it in the manifest of the bundles.
Separate any external/open source libraries you use in separate bundles. They will most probably be the parts that will have to be updated more often and on a different timeline than your own code. It is also more important here to define clear package dependencies, package versions, and to avoid depending on the implementation parts instead of only on interfaces!
Think about which parts of the app you want to expose to plugins. Then make OSGi services out of these parts - i.e. publish the interfaces in the OSGi registry. You don't need to implement any specific thing - you can publish any Java object. The plugins will then use the regitry for the lookup.
The same goes for the plugins - think about what you want to get from plugins and define the respective interfaces that the plugins can implement and publish and your app can lookup in the registry.
And as a final tip - see what bundles are already available in the OSGi framework you have chosen. There are many standard OSGi interfaces defined by the OSGi spec - for configuration, logging, persistent storage, remote connections, user admin, eventing, and many more. Since they are standard, you can use them without becoming dependent on any specific OSGi implementation. And uninstall what you don't need.