3

到目前为止，我认为我所知道的是，CORBA 规范本身不允许服务器程序使用的 IDL 和客户端程序使用的 IDL 之间存在任何差异。

然而，在实践中，某些差异必然会（相当）普遍起作用，因为底层的通信机制很可能是 GIOP（至少是 IIOP），并且某些差异必然无法通过 IIOP 检测到。

我想确定的是，只要使用 GIOP/IIOP，在任意 ORB 之间普遍允许服务器和客户端 IDL 之间存在哪些差异。

例如：到目前为止，我认为它适用于：

  • 只要不触及客户端 IDL 知道的类型或将任何未知的新类型发送回客户端，就可以将任何类型/接口添加到服务器 IDL。
  • 将方法添加到服务器端的现有接口——客户端应该能够继续使用此接口调用对象，即使他的 IDL 没有列出所述方法。（这似乎在这里得到了肯定的回答。）
  • 只要客户端永远不会看到这个新值，就在枚举的末尾添加一个成员。
  • 将成员添加到 union，只要客户端永远不会看到此 Union 类型并将鉴别器设置为新值。

我的目标是得到一个可以在现有 IDL 中做的事情的简短列表，用新的东西扩展“服务器”，而不必用修改后的 IDL 重新编译现有的客户端。

4

1 回答 1

1

  • 是的，服务器和客户端方法集不需要完全匹配，因为方法是按名称（GIOP 消息中的操作字段）访问的，并且是独立的。换句话说，GIOP 调用将方法名称包含为字符串，然后参数按照此参数的预期进行编码。请参阅CORBA tie和CORBA stub的示例。

  • 是的，如果您创建并导出一个新界面，它只是一个新界面。它可以独立于其他名称服务绑定到任何名称服务，不知道这个新接口的客户端将无法使用它。将能够使用绑定到同名服务的已知类型。

  • 是的，GIOP 将枚举写入无符号长整数，第一个值始终编码为零，连续的标识符采用升序数值，按照从左到右的声明顺序。因此，添加新的枚举标识但不删除也不重新排序是完全安全的。

阅读GIOP 规范，有很大帮助。查看由 IDL 编译器生成的代码以及在 IDL 中更改某些内容时它如何更改也非常好。

当然，仅仅因为缺乏注意而使用不匹配的 IDL 并不是一个好习惯，因为它也很容易引入不兼容的更改。这可能只有在您无法再访问和更新已发布给用户的客户端时才有意义。

于 2013-01-13T13:13:10.267 回答