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