问题描述
什么使模块/服务/位应用程序功能成为OSGi模块的特别好的候选者？
What makes a module/service/bit of application functionality a particularly good candidate for an OSGi module?
我有兴趣使用。我正在寻找一种将OSGi作为试用版纳入应用程序的好方法。有没有人在这里使用过这种或类似的OSGi技术？有任何陷阱吗？
I'm interested in using OSGi in my applications. We're a Java shop and we use Spring pretty extensively, so I'm leaning toward using Spring Dynamic Modules for OSGi(tm) Service Platforms. I'm looking for a good way to incorporate a little bit of OSGi into an application as a trial. Has anyone here used this or a similar OSGi technology? Are there any pitfalls?
@Nicolas - 谢谢，我见过那一个。这是一个很好的教程，但我正在寻找更多关于如何做我的第一个真正的OSGi包的想法，而不是Hello World示例。
@Nicolas - Thanks, I've seen that one. It's a good tutorial, but I'm looking more for ideas on how to do my first "real" OSGi bundle, as opposed to a Hello World example.
@david - 感谢您的链接！理想情况下，使用绿地应用程序，我会将整个事物设计为动态的。不过，我现在正在寻找的是将其引入现有应用程序的一小部分。假设我可以选择应用程序的任何一部分，有哪些因素可以使这件作为OSGi豚鼠更好或更差？
@david - Thanks for the link! Ideally, with a greenfield app, I'd design the whole thing to be dynamic. What I'm looking for right now, though, is to introduce it in a small piece of an existing application. Assuming I can pick any piece of the app, what are some factors to consider that would make that piece better or worse as an OSGi guinea pig?
推荐答案
好吧，既然你不能拥有一部分OSGi和一部分非OSGi，你需要制作整个应用程序OSGi。在最简单的形式中，您可以从整个应用程序中创建一个OSGi包。显然，这不是最佳实践，但是在OSGi容器（Equinox，Felix，Knoplerfish等）中部署捆绑包的感觉非常有用。
Well, since you can not have one part OSGi and one part non-OSGi you'll need to make your entire app OSGi. In its simplest form you make a single OSGi bundle out of your entire application. Clearly this is not a best practice but it can be useful to get a feel for deploying a bundle in an OSGi container (Equinox, Felix, Knoplerfish, etc).
To将它带到下一个级别，您将要开始将应用程序拆分为组件，组件通常应该具有一组职责，这些职责可以通过一组接口和类依赖性与应用程序的其余部分隔离。纯粹手工识别这些内容的范围可以从一个设计良好，高度内聚但松散耦合的应用程序，到您不熟悉的互锁源代码的噩梦。
To take it to the next level you'll want to start splitting your app into components, components should typically have a set of responsibilities that can be isolated from the rest of your application through a set of interfaces and class dependencies. Identifying these purely by hand can range from rather straightforward for a well designed highly cohesive but loosely coupled application to a nightmare for interlocked source code that you are not familiar with.
一些帮助可以来自等工具，它们可以向您展示Java包与其他包/类的耦合在你的系统中。具有低传出耦合的封装应该比具有高传出耦合的封装更容易提取到OSGi束中。使用等专业工具可以获得更多架构洞察力。
Some help can come from tools like JDepend which can show you the coupling of Java packages against other packages/classes in your system. A package with low efferent coupling should be easier to extract into an OSGi bundle than one with high efferent coupling. Even more architectural insight can be had with pro tools like Structure 101.
纯粹在技术层面上，每天使用包含160个OSGi包并使用Spring DM的应用程序工作我可以确认从正常Spring到Spring DM的过渡很大程度上是痛苦的自由。额外的命名空间以及您可以（并且应该）将您的OSGi特定Spring配置隔离在单独的文件中的事实使得使用和不使用OSGi部署方案更加容易。
Purely on a technical level, working daily with an application that consists of 160 OSGi bundles and using Spring DM I can confirm that the transition from "normal" Spring to Spring DM is largely pain free. The extra namespace and the fact that you can (and should) isolate your OSGi specific Spring configuration in separate files makes it even easier to have both with and without OSGi deployment scenarios.
OSGi是一个深度和广泛的组件模型，我推荐的文档：
OSGi is a deep and wide component model, documentation I recommend:
- ：获取Core和Compendium规范的PDF，它们具有规范性，权威性和可读性。在任何时候都有方便的快捷方式，你会咨询他们。
- 阅读OSGi最佳实践，你可以可以做很多事情但是应该做的事情要小一些，而且你应该从不（例如DynamicImport：*）。
- OSGi R4 Specification: Get the PDFs of the Core and Compendium specification, they are canonical, authoritative and very readable. Have a shortcut to them handy at all times, you will consult them.
- Read up on OSGi best practices, there is a large set of things you can do but a somewhat smaller set of things you should do and there are some things you should never do (DynamicImport: * for example).
一些链接：
- 一个关键的OSGi概念是服务，通过
-
并已移至Eclipse.org作为Gemini Blueprint项目，该项目有一个论坛。
- OSGi best practices and using Apache Felix
- Peter Kriens and BJ Hargrave in a Sun presentation on OSGi best practices
- one key OSGi concept are Services, learn why and how they supplant the Listener pattern with the Whiteboard pattern
The Spring DM Google Group is no longer active and has moved to Eclipse.org as the Gemini Blueprint project which has a forum here.
这篇关于开始使用OSGI的最佳方法是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！