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

Question

I think I know so far 是 CORBA specification 本身不允许服务器程序使用的 IDL 和客户端程序使用的 IDL 之间存在任何差异。

但是，在实践中，某些差异必然普遍适用（相当），因为底层通信机制很可能是 GIOP（至少 IIOP）和一些差异一定不能通过 IIOP 检测到。

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

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

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

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

Answer 1

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

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

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

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

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