Java 为什么要在OSGi中创建和使用服务

过去一周我一直在学习OSGi，但唯一的原因似乎不太合适，那就是为什么我需要注册并使用任何捆绑包，而我只需要导入它的JAR文件就可以了。 我这样做有什么好处？是的，我确实得到了依赖关系管理，但是：

我可以通过导入未注册为服务本身的JAR文件来使用其他JAR文件吗？

---

如果是，为什么我要承担使用OSGi的开销？

OSGi的整个理念是模块化：将关注点和功能明确分离，并在需要时使用不同的版本或实现替换或更新功能

通过导入一个jar，您可以实例化在另一个jar中声明的类，但不能在运行时替换它！通过另一个实现或版本。OSGi服务的思想是定义Java接口，并通过在OSGi服务注册表中查找其实现从客户机使用该接口，而客户机实际上不知道该接口的实现。这使得在运行时用另一个版本甚至完全不同的解决方案替换实现成为可能，而不必担心客户机。从另一个jar实例化一个类是不可能的

---

当然，如果您不需要它，您可能会认为OSGi只是一个很大的开销。根据你的情况，你可能是对的。我发现遵循OSGi的结构可以让您更好地了解组件与应用程序整体架构之间的关系。从维护的角度来看，这是一个很大的好处。

服务解决的问题是当您开始使用基于契约的编程时出现的绑定问题。在代码中，您使用的是接口，但在运行时，您实际上需要该接口的实现对象。如何得到这个

服务是解决这个绑定问题的一个非常优雅的解决方案，我所知道的所有其他解决方案都有泄漏的抽象，并且在分析时不是模块化的。一些人指出了基于XML的解决方案，但他们似乎只是消除了这种耦合，从表面上看，这种耦合及其不良副作用仍然存在

硬解耦是服务的主要优势，单凭这一点是值得的

然而，一旦您开始使用服务，并看到在声明性服务中使用它们是多么容易，它们就会成为主要的体系结构和设计原语。您开始用服务而不是代码来组成系统，它们成为使系统灵活和可维护的枢纽。向我展示您的系统的服务图，我不仅可以告诉您您的系统做了什么，不同于大多数高级体系结构图片，它们在不同的系统之间惊人地相似，而且我还可以告诉您如何扩展它。此外，配置管理和服务模型的紧密集成为部署系统的人员提供了无与伦比的灵活性

服务解决许多问题，许多开发商认为做生意的成本，即复杂的问题，是生活的一部分。解决这些问题需要努力去理解，因为人们常常觉得没有问题。在中世纪，城市没有污水处理系统，但他们也没有错过。你只会错过它，一旦你拥有了它

也就是说，并不是所有的东西都是服务。如果API+实现是相同的，那么一定要使用库。例如，ASM库显然是一个应该直接使用的库，但是像Quartz这样的东西应该在服务后面