没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
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,对象请求代理)总线通信。
1
与传统的 Client/Server 模式(我们称为 Two-tier client/server)不同,CORBA 是一种
multi-tier client/server architecture,更确切的说,是一种 three-tier client/server 模式。双重客
户/服务器模式存在的问题是两者耦合太紧,它们之间采用一种私有协议通信,服务器的改
变将影响到客户方。多重客户/服务器与此不同,两者之间的通信不能直接进行,而需要通
过中间的一种叫代理的方式进行。在 CORBA 中这种代理就是 ORB。通过它,客户和服务
器不再关心通信问题,它们只需关心功能上的实现。从这个意义上讲,CORBA 是一种中
间件(Middleware)技术。
下面列出 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.如果需要,将结果以同样的方式返回。
2
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 denition 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 denes 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 自动生成的,前者放在客户方,后者放
3
在服务器方。不同厂商的 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 设计的尽可能简单,开销最小,同时又具有最广泛的适应性和可扩展性,
以适应不同的网络。
4
GIOP 定义了以下几个方面:
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
};
5
剩余54页未读,继续阅读
资源评论
INTRUSTION
- 粉丝: 9
- 资源: 26
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功