Interoperable Object References: IOR
IOR用于表示一个对象引用，我们知道，当我们在客户端一个CORBA对象的时候，接触的并不是真正的对象，而是这个对象的代理（Proxy），Proxy使用这个对象的位置信息与服务器通信。那么这里有一个问题，这些信息到底些什么信息，另外，ORB使用什么样子的形式去传输这些对象的信息。答案是IOR。这里给它加上Interoperable是因为IOR是ORB Interoperability Architecture的一部分。
首先我们来看一下IOR的IDL定义：
module IOP { // IDL
// Standard Protocol Profile tag values
typedef unsigned long ProfileId
const ProfileId TAG_INTERNET_IOP = 0;
const ProfileId TAG_MULTIPLE_COMPONENTS = 1;
struct TaggedProfile {
ProfileId tag;
sequence<octet> profile_data;
};
// an Interoperable Object Reference is a sequence of
// object-specific protocol profiles, plus a type ID.
struct IOR {
string type_id;
sequence<TaggedProfile> profiles;
};
// Standard way of representing multicomponent profiles.
// This would be encapsulated in a TaggedProfile.
typedef unsigned long ComponentId;
struct TaggedComponent {
ComponentId tag;
sequence<octet> component_data;
};
typedef sequence <TaggedComponent> MultipleComponentProfile;
};
IOR
type_id的内容是Repository ID（这个比较难翻译，这里姑且理解成“类型”应该也不为过），用于实现类型安全，它应该是对象的most derived（指最继承层次结构中最底部的子类）类型。在type_id为null时，它表明这是一个Null Object Reference。
profiles，Object Reference（这里当然指IOR）至少有一TaggedProfile，每个TaggedProfile可以支持一个或者多个协议（比如IIOP），它封装了这些协议所需的用于定位对象的基本信息。一个TaggedProfile应该包含足够的信息，以使得它所支持的协议可以完成一个调用的全过程 。从这里我们可以知道，TaggedProfile对应的是协议级别的信息。
TaggedProfile
tag，OMG给每种TaggedProfile定义了一个唯一的数字，其实这是TaggedProfile的类型信息，从而决定了profile_data中的内容。对于IIOP Profile这个值是TAG_INTERNET_IOP，profile_data这个Encapsulation的内容是IIOP Profile。如果tag==TAG_MULTIPLE_COMPONENTS，那么profile_data的内容是MultipleComponentProfile。
profile_data是一个Encapsulation，如上面所说的，它的内容由tag决定，如果tag==TAG_INTERNET_IOP，profile_data这个Encapsulation的内容是IIOP Profile。如果tag==TAG_MULTIPLE_COMPONENTS，那么profile_data的内容是 MultipleComponentProfile。注意，在GIOP 1.1和1.2中，IIOPProfile也包括了一个sequence<TaggedComponent>类型的字段。这里profile_data中的TaggedComponent是多个TaggedProfile之间共享的，而IIOPProfile中的sequence<TaggedComponent>是IIOPProfile自己的。
IIOPProfile
IIOPProfile是TaggedProfile的TaggedProfile实现，下面是IIOPProfile的IDL定义：
module IIOP { // IDL extended for version 1.1 and 1.2
struct Version {
octet major;
octet minor;
};
struct ProfileBody_1_0 {// renamed from ProfileBody
Version iiop_version;
string host;
unsigned short port;
sequence <octet> object_key;
};
struct ProfileBody_1_1 {// also used for 1.2
Version iiop_version;
string host;
unsigned short port;
sequence <octet> object_key;
// Added in 1.1 unchanged for 1.2
sequence <IOP::TaggedComponent> components;
};
};
iiop_version，iiop协议的版本信息，没有什么好说的，主版本号相同的话，那么高次版本的协议是兼容低次版的协议，同时低版本的可以尝试对高次版本的IOR进行调用。请查阅CORBA规范以获取详细信息。
host用来表示对象调用信息发往的主机名。
port用于表示对象调用信息发往的端口号。
object_key是对象的标识信息，object_key在对象中应该是唯一的。服务端通过Request Message中object_key信息来将请求委托到目标对象。
components用于表示对这个对象进行调用可能使用到的额外信息。区别于profile_data的中MultipleComponentProfile，这些信息不会在TaggedProfile之间共享。CORBA规范中定义的TaggedComponent有ORB Type，CodeSet等等。
CORBA命名服务和JNDI的之间的关系
CORBA 命名服务也被称做为（COSNaming，Common Object Service Naming），它提供了名字到CORBA对象之间的映射。COS Name Server（公共对象命名服务器）用于储存和查询Object Reference（对象引用）。
而JNDI（Java Naming and Directory Interface）是个更高级别的抽象，而COSNaming只是JNDI的一个具体的Service Provider（服务提供者），它提供了名字到CORBA对象的绑定；从JNDI的结构图可以看出，JNDI的服务提供者还有LDAP（根据名字定位到数据库中相对应的内容），RMI（提供RMI对象注册服务，提供了名字到RMI对象的绑定）等等。如此一来，我们便可以使用JNDI来根据名字来定位CORBA对象，绑定/解绑定对象等操作。
JNDI结构