到目前为止，我所知道的是CORBA规范本身不允许服务器程序使用的IDL和客户端程序使用的IDL之间有任何差异。
然而，在实践中，某些差异与的工作（相当）普遍，因为潜在的通信机制很可能是GIOP（至少是IIOP），并且某些差异肯定无法通过IIOP检测到。
我喜欢建立的是，只要使用GIOP/IIOP，服务器和客户端IDL之间的差异就可以在任意ORB之间普遍存在。
例如：到目前为止，我假设它适用于：
- 向服务器IDL添加任何类型/接口，只要客户端IDL知道的类型没有被触及，或者任何未知的新类型都发送回客户端
- 向服务器端的现有接口添加一个方法——客户端应该能够继续使用该接口调用对象，即使他的IDL没有列出所述方法。（这里的答案似乎是肯定的。）
- 在枚举的端添加一个成员，只要客户端从未看到此新值
- 向联合添加成员，只要客户端从未看到将鉴别器设置为新值的此联合类型即可
我的目标是获得一个类似于在现有IDL中可以做的事情的短列表，用新的东西来扩展"服务器"，而不必用修改后的IDL重新编译现有的客户端。
-
是的，服务器和客户端方法集不需要完全匹配，因为方法是按名称（GIOP消息中的操作字段）独立访问的。换句话说，GIOP调用将方法名称作为字符串包含，稍后参数将按照此参数的预期进行编码。请参阅CORBA连接和CORBA存根的示例。
-
是的，如果您创建并导出一个新接口，它只是一个新的接口。它可以独立于其他接口绑定到任何名称服务，而不知道此新接口的客户端将无法使用它。将能够使用绑定到同一名称服务的已知类型。
-
是的，GIOP将枚举写为无符号长，第一个值始终编码为零，连续的标识符采用升序数值，按声明从左到右的顺序。因此，附加新的枚举标识是完全安全的，但不删除也不重新排序。
阅读GIOP规范，帮助很大。研究IDL编译器生成的代码，以及当IDL中的某些内容发生变化时，代码是如何变化的，也是非常好的。
当然，仅仅因为缺乏谨慎而使用不匹配的IDL并不是一个好的做法，因为它也很容易引入不兼容的更改。这可能只有在您无法再访问和更新已发布给用户的客户端的情况下才有意义。