12

我试图了解 OSGi 服务。我一直问自己的主要问题是：使用服务而不是使用捆绑包及其导出的包有什么好处？

据我所知，后期绑定的概念似乎与它有关。捆绑包依赖项在捆绑包开始时连接在一起，所以我猜它们是相当固定的。但是对于服务，它似乎几乎是一样的。捆绑包启动并注册服务或绑定到服务。当然，服务可以随时来来去去，您必须跟踪这些机会。但核心思想对我来说似乎并没有什么不同。

另一个方面似乎是服务更加灵活。一个特定接口可能有许多实现。另一方面，对于特定的导出包也可以有很多不同的实现。

在另一篇文章中，我读到使用导出包的缺点是它们使应用程序比服务更脆弱。作者写道，如果您从依赖图中删除一个捆绑包，将不再满足其他依赖关系，因此可能会对整个图造成多米诺骨牌效应。但是，如果服务离线，难道不会发生同样的情况吗？在我看来，服务依赖并不比捆绑依赖好。

到目前为止，我找不到一篇博文、书籍或演示文稿可以清楚地描述为什么服务比仅仅通过导出和导入包来公开功能更好。

总结一下我的问题：

使用 OSGi 服务使其优于导出和导入包的主要优势是什么？

添加

我试图收集有关此问题的更多信息，并在包和服务的普通导出/导入之间进行某种比较。也许这会帮助我们找到一个满意的答案。

  1. 开始/停止/更新

    捆绑包（因此是包）和服务都可以启动和停止。除此之外，它们还可以进行更新。服务也与捆绑生命周期本身相关联。但在这种情况下，我只是说您是否可以启动和停止服务或捆绑包（以便导出的包“消失”）。

  2. 跟踪变化

    ServiceTracker 和 BundleTracker 使跟踪和响应捆绑和服务可用性的变化成为可能。

  3. 对其他捆绑包或服务的特定依赖关系。

    如果要使用导出的包，则必须导入它。

    Import-Package: net.jens.helloworld

    net.jens.helloworld是否会提供服务，我还需要导入包才能获得接口。

    因此，在这两种情况下，它们都会与或多或少特定的包进行某种“紧密耦合”。

  4. 拥有多个实现的能力

    特定包可以通过多个捆绑包导出。可能有一个包net.jens.twitterclient由包 A 和包 B 导出。这同样适用于服务。接口net.jens.twitterclient.TwitterService可以由包 A 和 B 发布。

在这里总结一下简短的比较（导出的包/服务）：

  1. 是的是的
  2. 是的是的
  3. 是的是的
  4. 是的是的

所以没有区别。

此外，服务似乎增加了更多复杂性并引入了另一层依赖关系（见下图）。

替代文字 http://img688.imageshack.us/img688/4421/bundleservicecomparison.png

那么，如果导出的包和服务之间没有真正的区别，那么使用服务有什么好处呢？

我的解释：

服务的使用似乎更复杂。但服务本身似乎更轻量级。如果您启动/停止整个捆绑包或者您只是启动和停止特定服务，这应该是不同的（在性能和资源方面）。

从架构的角度来看，我也猜想捆绑包可以被视为应用程序的基础。在启动和停止捆绑包方面，基础不应该经常改变。该功能由该包的服务在“捆绑层”之上的某种动态层中提供。这个“服务层”可能会经常发生变化。例如，如果数据库离线，查询数据库的服务将被取消注册。

你怎么看？我是否开始了解服务的全部意义，还是我仍在思考错误的方式？有没有我遗漏的东西会使服务比出口的包更具吸引力？

4

6 回答 6

7

它非常简单：Bundles 只是提供你可以使用的类。使用 Imports/Exports，您可以屏蔽可见性并避免（例如）版本控制冲突。服务是满足特定契约（接口）的类的实例。

因此，在使用服务时，您不必关心实现的来源或实现细节。当您使用某种服务时，它们甚至可能会发生变化。

当您只想依赖 OSGi 的 Bundle 层时，您可以轻松地将横切依赖项引入您通常不想要的具体实现。（阅读下面关于 DI 的内容）

这不仅仅是 OSGi 的事情 - 只是好的做法。

在非 OSGi 世界中，您可以使用 Guice、Spring 或类似的依赖注入 (DI) 框架。OSGi 在框架中内置了服务层，并允许更高级别的框架（Spring、Guice）使用该层。- 所以最后你通常不直接使用 OSGi 服务 API，而是使用用户友好框架（Spring-->Spring DM、Guice-->Peaberry 等）的 DI 适配器。

HTH，托尼

于 2010-05-30T11:28:20.953 回答
4

我建议购买这本书。它在解释服务和构建使用 OSGi 服务的非平凡应用程序方面做得非常出色。

http://equinoxosgi.org/

我的公司经常使用服务构建 100 多个捆绑应用程序。我们从使用服务中获得的主要好处是：

1）生产者/消费者实现的松散耦合

2) 热插拔服务提供商

3）更清洁的应用架构

于 2010-05-08T20:00:32.040 回答
2

当您从 OSGi 开始时，从导出包方法开始总是更容易，它肯定感觉更像 java。但是当您的应用程序开始增长并且您需要一些动态性时，服务就是您要走的路。

Export-package 仅在启动时进行解析，而 services 是一个持续的解析（您可能想要或不想要）。从支持的角度来看，拥有服务可能非常可怕（它是确定性的吗？我怎样才能复制问题？），但它也非常强大。

Peter Kriens解释了为什么他认为服务是一种范式转变，就像当时的 OO 一样。参见µServices和管道胶带。

在我所有的 OSGi 经验中，我还没有机会实现复杂的服务（即超过一层），当然注释似乎是要走的路。您还可以使用Spring 动态模块来减轻处理服务跟踪器的痛苦。（以及许多其他选项，如iPOJO和Blueprint）

于 2010-05-07T02:13:10.157 回答
1

让我们考虑以下两种情况：

  1. Bundle A 提供了一种算术加法服务add(x,y) return x+y。为此，它使用“IAddition 接口”导出“mathOpe 包”，并在服务注册表中注册服务。捆绑包 B、C、D、... 使用此服务。

  2. Bundle A 导出“mathOpe 包”，我们在其中发现了一个类 Addition 公开了一个 operation (x+y)<--add(x,y)。捆绑 B、C、D、... 导入包 mathOpe。

方案 1 与方案 2 的比较：

  • 只有一个实现实例与许多实例（随意将其设为静态！）
  • 动态服务管理启动、停止、更新与无管理，消费者拥有实现（“服务”）
  • 灵活（我们可以想象网络上的远程服务）与不灵活

……等等。

PS：我不是OSGI专家也不是Java专家，这个答案仅表明我对现象的理解:)

于 2014-10-20T17:19:38.087 回答
0

我认为这篇优秀的文章可以回答你的很多问题：OSGi，以及它是如何做到的。

于 2010-05-05T20:26:45.337 回答
0

使用服务而不是实现类的主要优点是提供服务的包将执行类本身的初始化。

使用服务的包不需要知道服务是如何初始化的。

如果您不使用服务，您将始终需要调用一种工厂来创建服务实例。该工厂将泄露本应保密的服务细节。

于 2015-09-23T15:45:07.123 回答