过去一周我一直在研究OSGi，但唯一的原因似乎不适合我为什么需要注册并使用任何bundle我只需输入它就能做到JAR个文件。
这样做我有什么好处？是的，我确实得到依赖管理但是：
我可以使用任何其他JAR文件导入未注册为services的文件吗？
如果是，我为什么要承担使用OSGi的开销？
答案 0 :(得分：7)
OSGi的整个想法是，您可以获得模块化：明确分离关注点和功能，以及在需要时使用不同版本或实现替换或更新功能的选项。
通过导入jar，您可以实例化在另一个jar中声明的类，但不能用其他实现或版本替换它（运行时！）。 OSGi服务的想法是您定义Java接口并通过在OSGi服务注册表中查找其实现来从客户端使用此接口，而客户端实际上不知道接口的实现。这使得可以用另一个版本或甚至完全不同的解决方案在运行时替换实现而几乎不关心客户端。通过从另一个jar实例化一个类，这是不可能的。
当然，如果你不需要它，你可能会认为OSGi只是很多开销。你可能是对的，这取决于你的情况。我发现遵循OSGi的结构可以让您更好地了解组件与应用程序整体架构之间的关系。从维护角度来看，这是一个很大的好处。
答案 1 :(得分：4)
问题服务解决的是当您从基于合同的编程开始时出现的绑定问题。在您的代码中，您使用的是接口，但在运行时，您实际上需要该接口的实现对象。怎么弄这个？
服务是解决此绑定问题的非常优雅的解决方案，我所知道的所有其他解决方案都有漏洞抽象，并且在分析时不是模块化的。有些人指出基于XML的解决方案，但他们只是似乎才能使这种耦合消失，在表面下耦合及其不良副作用仍然存在。
硬脱钩是服务的主要优势，值得单独使用。
但是，一旦开始使用服务并看到使用它们是多么容易（在Declarative Services中），它们就会成为主要的架构和设计原语。您开始使用服务而不是代码来构建系统，它们成为使您的系统灵活和可维护的关键。向我展示你的系统的服务图，我不仅告诉你你的系统做了什么（不同于大多数高级架构图片，在不同的系统之间非常相似），但我也可以告诉你如何扩展它。此外，配置管理和服务模型的紧密集成为部署系统的人员提供了无与伦比的灵活性。
服务解决了许多开发人员考虑开展业务成本的许多问题，即生活中错综复杂的问题。解决这些问题需要努力去理解，因为人们常常觉得没有问题。在中世纪时期，城市没有污水系统，但他们也没有错过它。一旦你拥有它，你只会错过它。
那就是说，并非一切都是服务。如果API +实现完全相同，那么请使用库。例如，ASM库显然是一个应该直接使用的库，但Quartz应该在服务后面。