CORBA程序设计指南(入门) Author:龙湘明 Company:北京邮电大学国家重点实验室 Update:2021-08-30 这里假设你对 CORBA毫无所知。对JAVA略有所知,因为这里使用JAVA作为程序 设计语言。学习了本书,你将对 CORBA有个初步了解,并能编写一个简单完整的 CORBA 应用程序。 1. CORBA简介 CORBA( Common Object Request Broker Architecture)是为了实现分布式计算而引入的。 为了说明 CORBA在分布计算上有何特点,我们从它与其它几种分布计算技术的比较中进行 说明。 与过去的面向过程的RPC( Remote Procedure Cal)不同, CORBA是基于面向对象技术 的,它能解决远程对象之间的互操作问题。 MicroSoft的DCOM( Distributed Component Object Model)也是解决这一问题的,但它基于 Windows操作系统,尽管到本书编写时, DCOM已有在其他操作系统如 Sun Solaris, Digital Unix, IBM MⅤS上的实现,但毫无疑问, 只有在微软的操作系统上才会实现得更好。而只有 CORBA是真正跨平台的,平台独立性正 是 CORBA的初衷之一。另一种做到平台无关性的技术是 Java rm( Remote Method Invocation),但它只能用JAVA实现。 CORBA与此不同,它通过一种叫IDL( Interface Definition Language)的接口定义语言,能做到语言无关,也就是说,任何语言都能制 CORBA组件,而 CORBA组件能在任何语言下使用。 因此,可以这样理解 CORBA: CORBA一种异构平台下的语言无关的对象互操作模型。 1.1 CORBA体系结构 CORBA的体系结构如下: Client Implement ation Skeletor Object Request Broker Figure l: A request passing from client to dh D 2000 ch n Momrcmms chaup 图1.1 CORBA体系结构
1 CORBA 程序设计指南(入门) Author: 龙湘明 Company: 北京邮电大学国家重点实验室 Date : 2001-2-28 Update : 2021-08-30 这里假设你对 CORBA 毫无所知。对 JAVA 略有所知,因为这里使用 JAVA 作为程序 设计语言。学习了本书,你将对 CORBA 有个初步了解,并能编写一个简单完整的 CORBA 应用程序。 1.CORBA 简介 CORBA(Common Object Request Broker Architecture)是为了实现分布式计算而引入的。 为了说明 CORBA 在分布计算上有何特点,我们从它与其它几种分布计算技术的比较中进行 说明。 与过去的面向过程的 RPC(Remote Procedure Call)不同,CORBA 是基于面向对象技术 的,它能解决远程对象之间的互操作问题。MicroSoft 的 DCOM (Distributed Component Object Model)也是解决这一问题的, 但它基于 Windows 操作系统,尽管到本书编写时, DCOM 已有在其他操作系统如 Sun Solaris, Digital Unix, IBM MVS 上的实现,但毫无疑问, 只有在微软的操作系统上才会实现得更好。而只有 CORBA 是真正跨平台的,平台独立性正 是 CORBA 的初衷之一。另一种做到平台无关性的技术是 Java RMI(Remote Method Invocation),但它只能用 JAVA 实现。CORBA 与此不同,它通过一种叫 IDL(Interface Definition Language)的接口定义语言,能做到语言无关,也就是说,任何语言都能制作 CORBA 组件,而 CORBA 组件能在任何语言下使用。 因此,可以这样理解 CORBA:CORBA 一种异构平台下的语言无关的对象互操作模型。 1.1 CORBA 体系结构 CORBA 的体系结构如下: 图 1.1 CORBA 体系结构
CORBA上的服务用IDL描述,IDL将被映射为某种程序设计语言如C++或Java,并且 分成两分,在客户方叫 IDL Stub(桩),在服务器方叫 IDL Skeleton(骨架)。两者可以采 用不同的语言。服务器方在 Skeleton的基础上编写对象实现( Object Implementation,而客户 方要访问服务器对象上的方法,则要通过客户桩。而双方又要通过而ORB( Object Request Broker,对象请求代理)总线通信。 与传统的 Client/Server模式(我们称为Two- tier client/server)不同, CORBA是一种 multi- tier client/ server architecture,更确切的说,是一种 three- tier client/ server模式。双重客 户/服务器模式存在的问题是两者耦合太紧,它们之间采用一种私有协议通信,服务器的改 变将影响到客户方。多重客户/服务器与此不同,两者之间的通信不能直接进行,而需要通 过中间的一种叫代理的方式进行。在 CORBA中这种代理就是ORB。通过它,客户和服务 器不再关心通信问题,它们只需关心功能上的实现。从这个意义上讲, CORBA是一种中间 件( Middleware)技术 下面列出 CORBA中的一些重要概念,或者说 CORBA中的几个重要名词,有助于读者 了解 CORBA的一些重要的方面 12 CORBA中的几个概念 1. 2. 1 ORB(Object Request Broker) CORBA体系结构的核心就是ORB。可以这样简单理解:ORB就是使得客户应用程序 能调用远端对象方法的一种机制。 Client machine Client Applicatio Operation Call Code Object IDL Interface 图12ORB模型 具体来说就是:当客户程序要调用远程对象上的方法时,首先要得到这个远程对象的引 用,之后就可以像调用本地方法一样调用远程对象的方法。当发出一个调用时,实际上ORB 会截取这个调用(通过客户Stub完成,“提高”篇中会详细解释),因为客户和服务器可 能在不同的网络、不同的操作系统上甚至用不同的语言实现,ORB还要负责将调用的名字 参数等编码成标准的方式(称 Marshaling)通过网络传输到服务器方(实际上在同一台机器上 也如此),并通过将参数 Unmarshaling的过程,传到正确的对象上(这整个过程叫重定向, Redirecting),服务器对象完成处理后,ORB通过同样的 Marshaling/ Unmarshaling方式将结 果返回给客户。 因此,ORB是一种功能,它具备以下能力: 1.对象定位(根据对象引用定位对象的实现) 2.对象定位后,确信 Server能接受请求 3.将客户方请求通过 Marshaling/ Unmarshing方式重定向到服务器对象上
2 CORBA 上的服务用 IDL 描述,IDL 将被映射为某种程序设计语言如 C++或 Java,并且 分成两分,在客户方叫 IDL Stub(桩), 在服务器方叫 IDL Skeleton(骨架)。两者可以采 用不同的语言。服务器方在 Skeleton 的基础上编写对象实现(Object Implementation),而客户 方要访问服务器对象上的方法,则要通过客户桩。而双方又要通过而 ORB(Object Request Broker,对象请求代理)总线通信。 与传统的 Client/Server 模式(我们称为 Two-tier client/server)不同,CORBA 是一种 multi-tier client/server architecture,更确切的说,是一种 three-tier client/server 模式。双重客 户/服务器模式存在的问题是两者耦合太紧,它们之间采用一种私有协议通信,服务器的改 变将影响到客户方。多重客户/服务器与此不同,两者之间的通信不能直接进行,而需要通 过中间的一种叫代理的方式进行。在 CORBA 中这种代理就是 ORB。通过它,客户和服务 器不再关心通信问题,它们只需关心功能上的实现。从这个意义上讲,CORBA 是一种中间 件(Middleware)技术。 下面列出 CORBA 中的一些重要概念,或者说 CORBA 中的几个重要名词,有助于读者 了解 CORBA 的一些重要的方面。 1.2 CORBA 中的几个概念 1.2.1 ORB(Object Request Broker) CORBA 体系结构的核心就是 ORB。可以这样简单理解:ORB 就是使得客户应用程序 能调用远端对象方法的一种机制。 图 1.2 ORB 模型 具体来说就是:当客户程序要调用远程对象上的方法时,首先要得到这个远程对象的引 用,之后就可以像调用本地方法一样调用远程对象的方法。当发出一个调用时,实际上 ORB 会截取这个调用(通过客户 Stub 完成,“提高”篇中会详细解释),因为客户和服务器可 能在不同的网络、不同的操作系统上甚至用不同的语言实现,ORB 还要负责将调用的名字、 参数等编码成标准的方式(称 Marshaling)通过网络传输到服务器方(实际上在同一台机器上 也如此),并通过将参数 Unmarshaling 的过程,传到正确的对象上(这整个过程叫重定向, Redirecting),服务器对象完成处理后,ORB 通过同样的 Marshaling/Unmarshaling 方式将结 果返回给客户。 因此,ORB 是一种功能,它具备以下能力: 1.对象定位(根据对象引用定位对象的实现) 2.对象定位后,确信 Server 能接受请求 3.将客户方请求通过 Marshaling/Unmarshing 方式重定向到服务器对象上
4.如果需要,将结果以同样的方式返回。 1.2.2 DL(nterface Definition Language) IDL,接口定义语言,是 CORBA体系中的另一个重要概念。如果说ORB使 CORBA 做到平台无关,那么IDL,则使 CORBA做到语言无关。 正像其名字中显示的那样,IDL仅仅定义接口,而不定义实现,类似于C中的头文件 实际上它不是真正的编程语言。要用它编写应用,需要将它映射它相应的程序设计语言上去 如映射到C++或JAVA上去。映射后的代码叫 Client stub code和 Server skeleton code c IDL的好处是使高层设计人员不必考虑实现细节而只需关心功能描述。IDL可以说是描 述性语言。设计IDL的过程也是设计对象模型的过程。它是编写 CORBA应用的第一步 在整个软件设计过程中至关重要 IDL的语法很像C++,当然也像Java。很难想像一个程序设计人员是不懂C或Java的, 所以,几乎所有的程序设计人员都能迅速理解IDL。而这正是IDL设计者所希望的 下面是一个IDL定义的简单例子 // grid. ic // idl definition of a 2-d grid module simpleDemof interface grid I readon ly attr ibute short he ight; / he i ght of the grid readonly attr ibute short width: / width of the gr id // IDL operat ions // set the element [row, col] of the grid, to value void set (in short row, in short col, in long value) // return element [row, col] of the grid long get (in short row, in short col) This iDL def ines an interf ace for a gr id CoRBa object that maintains a grid or 2-D array of data values, which a client can access or modify remotely Module类似于Java中包( Package)的概念,实际上 module simpleDemo映射到JAVA 正是 package simpleDemo而 Interface类似于C++中的类(clas声明,或是Java中的 Interface 定义 附录中列出了IDL的全部语法。 1.2.3 Stub Code # FH Skeleton Code Stub code和 Skeleton Code是由 IDL Complier自动生成的,前者放在客户方,后者放
3 4.如果需要,将结果以同样的方式返回。 1.2.2 IDL(Interface Definition Language) IDL,接口定义语言,是 CORBA 体系中的另一个重要概念。如果说 ORB 使 CORBA 做到平台无关,那么 IDL, 则使 CORBA 做到语言无关。 正像其名字中显示的那样,IDL 仅仅定义接口,而不定义实现,类似于 C 中的头文件。 实际上它不是真正的编程语言。要用它编写应用,需要将它映射它相应的程序设计语言上去, 如映射到 C++或 JAVA 上去。映射后的代码叫 Client Stub Code 和 Server Skeleton Code。 IDL 的好处是使高层设计人员不必考虑实现细节而只需关心功能描述。IDL 可以说是描 述性语言。设计 IDL 的过程也是设计对象模型的过程。它是编写 CORBA 应用的第一步, 在整个软件设计过程中至关重要。 IDL 的语法很像 C++,当然也像 Java。很难想像一个程序设计人员是不懂 C 或 Java 的, 所以,几乎所有的程序设计人员都能迅速理解 IDL。而这正是 IDL 设计者所希望的。 下面是一个 IDL 定义的简单例子: // grid.idl // IDL definition of a 2-D grid: module simpleDemo{ interface grid { readonly attribute short height; // height of the grid readonly attribute short width; // width of the grid // IDL operations // set the element [row,col] of the grid, to value: void set(in short row, in short col, in long value); // return element [row,col] of the grid: long get(in short row, in short col); }; }; This IDL defines an interface for a grid CORBA object that maintains a grid or 2-D array of data values, which a client can access or modify remotely. Module 类似于 Java 中包(Package)的概念,实际上 module simpleDemo 映射到 JAVA 正是package simpleDemo。而Interface类似于C++中的类(classs)声明,或是Java中的Interface 定义。 附录中列出了 IDL 的全部语法。 1.2.3 Stub Code 和 Skeleton Code Stub code 和 Skeleton Code 是由 IDL Complier 自动生成的,前者放在客户方,后者放
在服务器方。不同厂商的 IDL complier生成的Stub和 Skeleton会略有区别,但影响不大。 如上面的grid.idl,编译后, Stub Code包含以下文件 grid. java gridStub. java gridHelper. java grid Holder. java gridOperations. java Skeleton Code则包含以下文件 gridOperations. java gridPOA. java gridPOATie java (在 Stud Code也包含 gridOperations. java.,是因为在使用 Call back机制时会用到。) 这些文件的用途后面会讲到。 124GIOP和IOP 我们知道,客户和服务器是通过ORB交互的,那么,客户方的ORB和服务器方的ORB 又是通过什么方式通信呢?通过GOP( General Inter-ORB Protocol)。也就是说,GlOP是一 种通信协议,它规定了两个实体:客户和服务器ORBs间的通信机制。 C1 Object Client Stub Skel IOP ORB 1 ORB 2 Protocol Figure 2: Interop erability uses ORB-to-ORB communication opynght e 2000 Object Managemert Group 图1.3ORBs通信机制 GIOP在设计时遵循以下目标: Widest possible availability Simplicity Scalability Low cost Generality Architectural neutrality 也是说,GOP设计的尽可能简单,开销最小,同时又具有最广泛的适应性和可扩展性, 以适应不同的网络 GIOP定义了以下几个方面:
4 在服务器方。不同厂商的 IDL complier 生成的 Stub 和 Skeleton 会略有区别,但影响不大。 如上面的 grid.idl, 编译后,Stub Code 包含以下文件: grid.java _gridStub.java gridHelper.java gridHolder.java gridOperations.java Skeleton Code 则包含以下文件: gridOperations.java gridPOA.java gridPOATie.java (在 Stud Code 也包含 gridOperations.java, 是因为在使用 Call back 机制时会用到。) 这些文件的用途后面会讲到。 1.2.4 GIOP 和 IIOP 我们知道,客户和服务器是通过 ORB 交互的,那么,客户方的 ORB 和服务器方的 ORB 又是通过什么方式通信呢?通过 GIOP(General Inter-ORB Protocol)。也就是说,GIOP 是一 种通信协议,它规定了两个实体:客户和服务器 ORBs 间的通信机制。 图 1.3 ORBs 通信机制 GIOP 在设计时遵循以下目标: ➢ Widest possible availability ➢ Simplicity ➢ Scalability ➢ Low cost ➢ Generality ➢ Architectural neutrality 也是说,GIOP 设计的尽可能简单,开销最小,同时又具有最广泛的适应性和可扩展性, 以适应不同的网络。 GIOP 定义了以下几个方面:
1. The Common Data Representation( CDr) definition 通用数据表示定义。它实际上是IDL数据类型在网上传输时的编码方案。它对所有IDL 数据类型的映射都作了规定 2. GIOP Message Formats. 它规定了 Client和 Server两个角色之间要传输的消息格式。主要包括 Request和 Reply 两种消息 个 Request消息有以下几部分组成 A GlOP message header A Request Header The Request body 相应的,一个 Reply消息则包括 A Reply He The Reply body GIOP1.1规定 GIOP message header格式如下: lI GIOP 1.1 struct MessageHeader-_1_1 I char magic [4] Version gloP version: octet flags; l/ GIOP 1.1 change unsigned long message size } Request Header格式如下 / GIOP 1.1 struct RequestHeader_11 i IOP. ServiceContextList service context: unsigned long request i boolean response expected octet reserved[3]; //Added in GIOP 1.1 sequence <octet object key; string operation Principal requesting_principal; Request Body则按CDR规定的方式编码,它主要对方法调用的参数进行编码,如方 double example (in short m, inout Principal p); 可表示成 struct example body short m; l/ leftmost in or inout parameter Principal p; lI. to the rightmost 3. GIOP Transport Assumptions
5 1.The Common Data Representation (CDR) definition. 通用数据表示定义。它实际上是 IDL 数据类型在网上传输时的编码方案。它对所有 IDL 数据类型的映射都作了规定。 2.GIOP Message Formats. 它规定了 Client 和 Server 两个角色之间要传输的消息格式。主要包括 Request 和 Reply 两种消息。 一个 Request 消息有以下几部分组成: A GIOP message header A Request Header The Request Body 相应的,一个Reply消息则包括 A GIOP message header A Reply Header The Reply Body GIOP1.1规定 GIOP message header格式如下: // GIOP 1.1 struct MessageHeader_1_1 { char magic [4]; Version GIOP_version; octet flags; // GIOP 1.1 change octet message_type; unsigned long message_size; }; Request Header 格式如下: // GIOP 1.1 struct RequestHeader_1_1 { IOP::ServiceContextList service_context; unsigned long request_id; boolean response_expected; octet reserved[3]; // Added in GIOP 1.1 sequence <octet> object_key; string operation; Principal requesting_principal; }; Request Body 则按 CDR 规定的方式编码,它主要对方法调用的参数进行编码, 如方 法: double example (in short m, inout Principal p); 可表示成: struct example_body { short m; // leftmost in or inout parameter Principal p; // ... to the rightmost }; 3.GIOP Transport Assumptions: