标签:
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结构
标签:
原文地址:http://www.cnblogs.com/mosmith/p/5185379.html