4

我熟悉 OSGI Semantic Versioning - 技术白皮书。但是，我没有看到针对 OSGI 服务提出的任何版本控制概念。

简单情况：我提供注册为 com.services.payments.PaymentService 的服务，它执行方法 void makePayment(Integer amount, String accountNo)，我将其打包为 1.0 版。然后，我用修改后的界面更新服务。我删除此方法并添加新方法：makePaymentInDifferentWay (Integer amount, String accountNo) 并将新服务打包为捆绑版本 2.0。第一个捆绑包停止后，客户端将连接第二个服务，并且崩溃在服务调用时，因为方法签名不是二进制兼容的。当您处理 java 包时，这种情况得到了完美的解决，但是我没有看到 OSGI 服务有任何开箱即用的版本控制功能。我错过了什么吗？（我知道我可以通过设置像'service.version'这样的服务属性来预先设计版本控制方案，并在客户端通过这个属性过滤提供的服务，或者只是重命名一个API包或类名，但是为什么没有提供版本控制框？也许还有其他更标准的方式解决方案？也许有一些与服务相关的概念我根本没有掌握？）

4

2 回答 2

3

服务是类型，类型在包中。所以服务的版本是包含服务类型的包的版本。OSGi 框架确保仅当客户端使用与服务提供者相同的服务类型包时才向客户端公开服务。

于 2012-05-17T16:18:38.600 回答
3

客户端应该在其 Import-Package 语句（或 Require-Bundle）语句上有版本，例如：

Import-Package: com.services.payments;version="[1.0,2.0)"

该服务会将包导出为：

Export-Package:  com.services.payments;version="1.0.0"

停止第一个捆绑包并安装第二个捆绑包后，客户端将无法解析 resolve（由于所需的约束，com.services.payments;version="[1.0,2.0)"将不会满足。

此外，如果您有两个 API 包，一个包版本为“1.0.0”，第二个包版本为“2.0.0”，并且客户端导入“1.0.0”API，客户端将不会“看到”服务实现 API版本“2.0.0”。

于 2012-05-17T16:10:14.617 回答