grizzly corba学习

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结构