OSGi 中的声明式服务与蓝图服务
OSGi 中的声明式服务和蓝图服务有什么区别？因为两者的目标都是在 osgi 中实现依赖注入。 蓝图服务可以替代声明式服务吗？ 或 bluprint 服务填补了声明式服务的限制（如果有）？
What is the difference between Declarative and Bluprint Services in OSGi? as both are aim to achieve Dependency injection in osgi.
Is blueprint services is alternative to declarative services?
or bluprint services fills the limitations (if any) of declarative services?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
恐怕这个问题没有一个简单的答案。我建议阅读两者的规范以了解差异的程度。声明式服务是服务纲要的第 112 节，蓝图容器是同一文档的第 121 节。您可以在此处获取核心和纲要文档：
http://www.osgi.org/Download/Release4V42
对我来说，最显着的区别是（用 DS 术语来说）蓝图服务可以在其所依赖的服务不存在的情况下激活。容器创建代理服务，该服务会阻塞，直到实际实现可用为止。我相信这类似于 Spring 的方法，并且习惯使用 Spring 的 IOC/DI 方法的人将立即获得 Blueprint，尽管我无法根据从未使用过 Spring 或 Blueprint 的个人经验发表评论。
由于我们正在处理 OSGi 服务，因此可以根据您的需要混合搭配 DS 和蓝图。到目前为止，我还没有发现需要做任何比 DS 可以实现的更复杂的事情，所以我不确定 Blueprint Container 规范满足什么用例，尽管从规范来看 Blueprint 确实提供了相当多的功能为了使组件开发变得简单。
我相信添加它主要是因为 J2EE 开发人员会发现它很熟悉，但这只是我的观点。 :)
There isn't a trivial answer to that question, I'm afraid. I would recommend reading the specification of both to see the extent of the differences. Declarative Services is section 112 of the Service Compendium, Blueprint Container is section 121 of the same document. You can get the core and compendium documents here:
http://www.osgi.org/Download/Release4V42
For me though, the most significant difference is that (in DS terms) a Blueprint service can be made active without the services it depends on being present. The container creates proxy services which block until an actual implementation is made available. I believe this is akin to Spring's approach and that people who are used to using Spring's IOC/DI approach will get Blueprint instantly, though I could not comment from personal experience having never used Spring or Blueprint (yet).
Since we are dealing with OSGi services it is possible to mix and match DS and Blueprint as you see fit. So far I haven't found a need to do anything more complicated than can be achieved with DS, so am not sure what use case the Blueprint Container specification meets, though from the spec it does look as though Blueprint provides quite a lot of functionality in order to make component development simple.
I believe it has been added primarily because J2EE developers will find it familiar, but that is just my opinion. :)
我意识到这是一个旧线程，但我认为这个问题仍然很重要。
我同意其他人的观点，即 BS 比 DS 更好地隐藏了 OSGi 的动态特性。
此外，看起来 DS 旨在绑定捆绑包，而 BS 可用于构建“供内部使用”的对象图。
I realize this is an old thread, but I think the question is still important.
I agree with the others who said that BS better hides dynamic nature of OSGi than DS.
Also, it looks like DS was meant for binding among bundles, while BS can be used to build object graphs "for internal consumption".