interop - CORBA 服务器和客户端的 IDL 之间允许有什么区别？

Question

什么 I think I know so far是CORBA specification因此不允许服务器程序使用的 IDL 和客户端程序使用的 IDL 之间有任何差异。

但是，在实践中，某些差异必然普遍(非常)有效，因为底层通信机制很可能是 GIOP(至少是 IIOP)并且一些差异必然无法通过 IIOP 检测到。

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

例如:到目前为止，我假设它适用于:

• 将任何类型/接口(interface)添加到服务器 IDL，只要不触及客户端 IDL 知道的类型或将任何未知的新类型发送回客户端即可。
• 向服务器端的现有接口(interface)添加一个方法——客户端应该能够继续使用该接口(interface)调用对象，即使他的 IDL 没有列出所述方法。 (这似乎是 answered with yes here. )
• 将一个成员添加到枚举的末尾，只要客户端永远看不到这个新值。
• Add a member to a union ，只要客户端永远不会看到鉴别器设置为新值的联合类型。

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

Answer 1

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

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

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

阅读GIOP specification , 帮助很大。查看由 IDL 编译器生成的代码，以及当 IDL 中的某些内容发生更改时代码如何更改，这也是非常好的。

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