您现在的位置:首页 > >

Ice中间件关键技术的研究与实现

发布时间:

摘要
中间件作为计算革命第三次浪潮的核心技术,以网格计算和普适计算为主要      演进方向,前者被称为 “ 中间件的中间 ,旨 件” 在增强中间件的应用集成能力;后
者的目标是将中间件扩展到更广泛的应用环境。

论文在系统分析 Zr      e C公司的网络通信引擎 ( e o I )源代码的基础上,建立了 c

系统的、 清晰的I 逻辑功能分析结构, c e 分析了各功能模块实现原理, 破译了中0 1 件实现中的关键技术。在此基础上,提出 “ 传输层协议可替换构架” 方案,并用 串口通信协议替换原有传输层协议的实例验证了方案的合理性:还提出和实现了 "c C R A互操作” I /O B e 的双向网关, 探讨了I 集成多域应用和多种中间件的可能 c e
性。

“      传输层协议可替换构架” 解决了 I c e应用于普适计算环境的核心问题, 而   C R A互操作” "eOB I/ c 则探讨了I 应用于网格计算环境的关键技术。 c e 论文的研究 成果在十五国防预研项目 “ 海军综合网络管理系统” 得到应用,该项目己 于今年
通过鉴定。

关键词:Ie 传输层协议 C R A 互操作 c O B

Ab t c sr t a

A t c e  nl y  h h w e  h o pt g  l i ,       r t ho g o t t d  v o t cm ui r o tn t s  o e h e  c o f  u a f  e  e  n e uo h v e mdl a t ho g eo e i to m r d etn:  g d  pt g  t i e r e nl y  l s  w pi a icost r cm un ad  d w e  c o v v n  r y  i h i o i n h r e  e

pr s e  ptg T e  r  ae a ” i l a o Mi l a " w i e av cm un.  fme icld  M d e r f  d w r , h h vi o i h o r s l s d w e  d e e c seg e t ai y  mdl a t iere  laosw i t lt i t tnt n  b t o i e r o  g t apctn,  l h ae s  r h h l f  d w e  n a p i i e i t he  tr  o e  epn t mdl a tm c wdr lao ev n et xad  i e r o  h  eapctn i m n h d w e  u i p i i n r e  o . Te t e C m n aos  i (e s  b coi t md e r     nt m ui tn E g ec i a oj trn d i l a h Ie nr o ci n n I )  n  e - e e dw e

p tr dvl e b Zr , . e o t sd ot s r cd o I ,  lfm  e pd  e C I . a d  h t y h o c oe  c ts ao e o y o n Bs n  u f  u e  f  h c e  e  e i ppr le t  a heu o I l il  tn  s t iad  r  .  aeaa s h r ic r f  o c f co ia  e c  c aw yI n y s  c t te c g a u i n  sm n l a t e  e  n y e ao l et ip m n tn  c loec f co m dl ad cs ky l aa s h m l eti pi ie  ah  tn  u r  c k t e s n y s  e  e ao r p f  u i o a n r h n n a e  ip m n tn  nl i o I .  r s r rooRp calAcic r i m l eti t ho g s c A  a p t  cl l eb r t te s e ao e o e f  " n o po c e T t e a e  he u "  p s t ,  i ri at ivri b t epr e o r l i t og a re e ad  ao l s i d  h xem n f  an h ri l e n d n t tn i s  y  ef y  e e  i t  e c g  in p e 
po cl t t nprl e wt C M  t o A  i coa gt a bs o r oo o h r sot  r h  p o l b r tnl  w y  e n t n  a e  a y i O r c . i e i o d a e a d 

"e O B ieoe tn i p ps ad p m n d T e  s i y  I I / R A t- ri "  r oe n i l et .  f il o c cC n r p ao s  o d  m e e h e bi f  a t e ieoe t wtm l ldm i ad  r d w ra d cs d n rpre i uie  a s  o emdl a r ius . t- a d  h  t o n n t i e e  s e p h e  "r so p o l  l eb r t te el i h o r l s         t o Rp cal Acic r da wt t cr p b m o Ta pr r c e a e  he u "  s h  n t o e  e  e f o ap i t I t t prav ev om n ky  nl i o t g d  ptg pln h c o  e s e in et e t ho g s h r cm un y g  e h v i n r e  e  ,  e o e f  i o i c e  b e o " e O B ie pri " l s d dTe  l o ts ewr a d  I / R A  r e tn iao  i .  r us h ppr e s n  c C n o ao s  t e h e t f  a e t s u s i

a pd  a ld  ani a d e e -s r p j t  e a "a d t a p i i   o l  n p rec re n d  Nv o e n pe n  a n e s r e ah  c a d  t f e o m s  y
Iere N to Maae et t " c hs s ts r n ga d w r ngm nSs m w i aps d  ya t t e k  y e h h  a e h e . i K y od Ie  rnprl ep t o C R A ne oea o ew r:    Tasot  r  o l O B It -prt n     c a r c y o r i

}  84 8 99 5
创新性声明
本人声明所呈交的论文是我个人在导师指导下进行的研究工作及取得的研究      成果。尽我所知,除了文中特别加以标注和致谢中所罗列的内容以外,论文中不

包 含其他人己 经发表或撰写过的 研究成果;也不包含为获得西安电子科技大学或 其它教育机构的学位或证书而使用过的 材料。与我一同工作的同志对本研究所做 的 任何贡献均己 在论文中做了明确的说明并表示了 谢意。 申 位论文与资料      请学 若有不实之处, 本人承担一切相关责任。
本人签名

三1 4

日 期: Z 6 I - 不刀

关于论文使用授权的说明
本人完全了解西安电      子科技大学有关保留和使用学位论文的规定,即:研究

生在校攻读学位期间论文工作的知识产权单位属西安电 子科技大学。本人保证毕 业离校后,发表论文或使用论文工作成果时署名单位仍然为西安电子科技大学。 学 校有权保留 送交论文的复印件,允许查阅 和借阅论文:学校可以 公布论文的 全 部或部分内 可以允许采用影印、 容, 缩印或其它复制手段保存论文。 保密的论文 ( 在 解密后遵守 此规定) 本学      属于 在 ̄ 年 后适用本授权书。 位论文 保密 — 解密

本人签名 导师签名

:王I f





20率i    n o6


: { 沃鼻 二

2“年I      口 / 4

第一章 绪论

第一章 绪论
11新计算技术革命的内涵 . 
随着计算机技术的发展,P      C机和 Ie e所带来的这场信息技术革命在继续 nr t t n

为人类文明带来巨大影响的同时, 经变成了 也已 越来越多新兴技术的底蕴和基础。 尤其在最*十多年,普适计算和网格计算等新技术的提出和不断发展,使它们已

经看 计革 浪 的 向[ 被 作 算 命 潮 风 标i 1
111普适计算 ..
普适计算的思想由Ma Wee在 19 年提出,并从 2 世纪 9 年代后期开      r i r 91 k  s 0 0 始受到广泛关注,目 前在国际上已发展成为一个研究热点,其重要标志是分别从

19 9 年和20年开始的Uim 国 会议和P vi Cmun 国 会议, 0 9 00 bop 际 c eav o ptg 际 rse  i 22 0

年I E  avCmu g 刊 创 更 标 着 一 究 域 扩 E P vi opi 期 的 刊 是 志 这 研 领 的 大。 E e se  t r n
普适计算在学术界称为 P v i Cmun,       e av optg I业界称为 Ui iu r se  i   buo qts Cmun。 o ptg 普适计算迄 止还没有 个准确的定 但它的 含义是 i 今为 一 义, 大致 指用户
可以在任何时间和地点,通过有线一无线网络的合作获得 “ 量体裁衣”的服务。

普适计算的终极目 的是将网络计算空间以一种不被察觉的方式融入到人们生活的
物理空间去。

Stn a a 经定义了 普适计 术成为      n 曾 aa r a n y ay 使 算技 现实的四 个要点, 分别是智 能

空 的 效 用 不 视 、 部 可 量 以 屏 不 环 条 i1这 点 间 有 使 、 可 性 局 化 测 性 及 蔽 同 境 件2。 四 1 1 3
中最重要的就是智能空间的有效利用, 空间”指的是一个物理区域的概念,它包 “

含了很多的协同工作的嵌入式系统, 智能” “ 则表明了 这些协同工作的嵌入式设备 是融合起来为了捕获人的行动, 并且能够根据这些活动判断人的意图, 有效利用” “ 则说明了所有的智能空间都是迎合人的需要,提供以 人为中心的服务。不可视能 力意味着最低限度的用户间交互。局部化可测量性则指通常意义上的软件可测量 性,普适计算依赖于通过存在于用户环境中的智能实体,来使用户个人空间与周 围环境之间进行更多交互, 局部化意味着可测量性依赖于每一个具体的智能空间。 屏蔽不同 环境则指在不同 架构下开发智能空间, 这些架构也包括一些非技术因素, 例如,组织体系、经济考量、商业模式等等。 普适计算以      人的需求为中心,从根本上改变了 人去适应机器计算的被动式服
务思想,而是用户在不被打扰的前提下主动、动态地接受网络服务。普适计算改 变了计算只局限于桌面进行的传统,用户可以以各种灵活的方式享受计算能力和 系统资源。只有普适计算模式才能在真正意义上实现以人为本的生活方式。它在

1 “中间件关键技术的研究与实现

服务方式和灵活性上的突破使得普适计算模式取代了继主机计算模式后出现的桌

面 算 式 成 信 时 计 模 的 一 里 碑3 计 模 , 为 息 代中 算 式 又 个 程 [ 1
112网格计算 .  .

网格 ( r t bl  是一个把局域网、     aGoaGi) Ge l r d 城域网甚至整个 Ie e整合成一 nm t t 台巨大的超级计算机,实现知识资源、 存储资源、数据资源、计算资源、信息资 源、专家资源的全面共享。虽然,网格可以分为各种地区性的网格,如公司内部 网格、局域网网格甚至家庭网格和个人网格;但事实上,网格的根本特征是资源 共享而不是它的规模。网格按功能划分有很多种,一般来说,计算网格是一种, 其它都可以看作访问网格。通过计算网格,用户可以使用到无限制的计算和数据 资源,访问型网格提供一组协同环境,向用户提供资源和服务,用户可以通过浏
览器等访问网格。

19 年F t I     sr 和 CrKs la 首次对网 98 o e a n a ee n l sm 格进行定义: 计算网格是一种由 硬件和软件构成的信息技术基础设施,它能提供可靠的、可协调的、可扩展的和

廉 的端算 力 访 [ 价 高 计 能 的 问1 4
与普适计算类似,推动网格计算发展的也有四个驱动力:联邦化团体的有效     

使 、 拟 、 准 以 屏 不 环 条 的 求] 里 的 体 者 虚 用 虚 化 标 化 及 蔽 同 境 件 需 [这 说 团 或 说 拟 3 。
组织,指的是一系列的在相同规则或相同管理域下被管理的分布式网络资源。联 邦化意味着这些团体在资源共享和问题解决方面有着一致的需求,有效使用则表 明团体资源的使用提供了非同一般的高质量服务。虚拟化指的是在团体中的资源 被隐藏去了自身的归属者和归属地。标准化意味着这些联盟是建立在标准的、开 放的、通用目 的的协议和接口 基础上的。最后, 在网格计算里屏蔽不同环境,则
意味着联邦化团体的中间件系统将被不得不考虑各个虚拟组织的中间件进行混合 交互。

如果将网格计算比喻成电力网格,当你给电      器或其它用电设备接入电源时,
你可以使用正确电压的电力,但并不知道该电力的实际来源。当地的公用事业公 司提供了接入由发电机和电源组成的复杂网络的接口,并且为满足你的能源需求 提供了满意的服务质量。不需要每家每户或邻*地区使用或维护他们 自己的发电 机,电力网格基础设施提供了虚拟的发电机。该发电机高度可靠,并根据客户的 要求来适应客户的电力需求。同样,在不同地方的存储、数据、空闲 C U等通过 P 网格技术集成为一个整体,人们利用这些资源就像利用电源一样,无需考虑其来

源负情[ 和 荷 况6 ]
113网络计算技术的演进 ..

第一章 绪论

基 网 的 算 术 展 进 路 如 图1 所 3 于 络 计 技 发 演 的 线 下 - 示[ 1 1
F rt C mmu ie ' ae o Me d  nts i

V  ai t n iu l ai r z o t
Sa d r比ain tn ad t o
Un v n o d t n e e C n io s i

R moe  n n e tC o . a F ut  ea c al o r e Tl n

tg A aaiy - h  ibi l vl l i t
R moe  c s e t Aces

Mo i ntok bl e r e w
Mo i if acs bl no  es e  c

Aate l tn d i 叩pc i pv a o a Ee y a ssm nr A r yt g w e  e
Lct n  si t oao s iv y i c ti o

图1 基于网                        - 1 络的 计算机技术发展演进图

如图所示,可以看出,分步式计算是所有网络计算技术的基础,而全球智能      空间是所有计算技术发展的所要达到的最终目的。此外,普适计算实际上主要是

移动计算和智能计算的结合, 这种结合需要移动设备能 够动态集成到它们已 经移 入智能空间 ( 或者称为本地网络计算环境) ,并且设备可以 请求普遍的一些服务。 最后,尽管分布式计算技术和移动计算技术不再被看作新的技术,但是在不断面 临新问 题的同时,仍有一些技术问题没有得到解决,比 如说安全问 题。
11 .  .  4新计算技术革命的本质要求 从普适计算和网格计算的介绍可以看出,未来的计算技术发展,      越来越呈现 两个显著的趋势:一是访问这些网络资源的终端设备朝多样化,小型化、智能化 以及可移动的方向发展,二是计算资源、设备资源以及各种信息资源都向网络化

发 1正 这 种 势 引 普 计 技 、 格 算 术 发 , 下 我 展1 是 两 趋 牵 了 适 算 术 网 计 技 的 展 接 来 们 7 。
将对这些技术产生的内在需求进行分析。 首先,在过去的 3 年内,计算机的通信能力和计算能力更加强大、价格更加      0

便宜、体积也变得越来越小。随着传感器技术和网络技术的不断进步, 特别是人
们对无线网络技术的重视,普适计算技术产生发展的一些重要的外部因素都已具

k 中间件关键技术的研究与实现 e

备。普适计算作为第三代计算模式,在其之前,计算模式的发展经历了主机计算
和桌面计算两个时代。第一代计算模式可以称为主机计算,在主机计算时代,人

与计算机是多对一的关系,主机在中心机房里,信息空间和人们生活的物理空间
是脱节的,计算机的应用主要集中在科学计算领域。第二代计算模式可以成为桌

面计算,在桌面计算时代,人与计算机是一对一的关系,此时信息空间和人们的 生活己经有了一定的联系,计算机开始应用于工作生活相关领域,但是,解决一

个问题也需要我们花费很多精力在如何协调多个计算机工作,工作资源如何共享 和搜集、分类资料上面。普适计算作为第三代计算模式, 其更强调人与日 常工作
生活中的信息设备的融合问题,信息设备将以嵌入式处理器、存储器、通信模块

和传感器集成在一起的形式出现,信息设备可以极其廉价地通过无线网络与 Ie e连接,由通信和计算机构成的信息空间将与人们生活和工作的物理空间融 nrt t n 为一体。由上面可以看出,普适计算与传统分布式系统最大的不同就在于前者需
要实现计算节点和物理世界的某种集成,并进行 自发的互操作。

网格计算和普适计算有着几乎相同的背景和相似的发展外部条件,但网格计     

算的 着重点放在资源的整合上。网格计算需要实现多个虚拟环境下不同位置用户 的交互;可连接大量的、分步的、远程的智能设备,进行实时处理和远程操作等; 可使多个异构计算机协同解决单机难以完成的任务,使不同性质的任务调度到最 合适的计算机结构中去运行。 网格和联网的可提供服务的服务器最大的区别就是: 网格包含多种异构分步的资源,且这些资源间的互操作必须是动态可适应的,并
具有一定的可扩展性。

所以说,无论普适计算还是网格计算,实际上都是对信息对象间的互操作提      出了更高层次的要求。它们的区别也只在于互操作性作用域的不同,普适计算更

强调于不同传输媒质载体间信息服务上的无缝交互,而网格计算更关注于分布式
异构系统的为实现特定目标,相关资源的便捷共享和协同工作。

12对象级的分布式互操作 .
121分布式互操作 .  . 

从全局角度的观点来看,资源和应用从属于一个个独立的节点。如何将这些      地理上分布的节点组织起来实现互连、互通和互操作,从而为信息共享和应用交

互理务就 分式 统要 决 根 问1 处 服 , 是 布 系 所 解 的 本 题8 1
1 .1互连互通的定义 .1 2.

互连互通可以说是撬动整个信息技术乃至未来文明发展的需要支点。由于其

第一章 绪论

概念范围极广,本文所讨论的互连互通,具体以网络的互连互通为切入点。而在 探讨网络的互连互通时,主要从以下向几个层面考虑: . 网络体系结构的互通:或者说是基于T P P      C / 协议族的 I I P网络与其它协议 参考模型之间的非 I P网络之间的互连互通。 . 网络互通:网络互通是一种多层次、多方位的互通,如,两种技术如何在      物理层互通,如何在链路层互通,又如何在网络层互通。 . 业务互通:由于通信的目的是提供服务,因此在考虑电信网互通时,还应     
该考虑在用户或业务面的互通,控制面的互通和管理面的互通,即全方位的业务
互通 。

当然,无论是在宏观网络世界还是微观网络世界,人们最终的希望还是网络      技术最终能够收敛 / 统一,从而简化网络的互连互通工作。
1 .2互操作的定义 .1 2.

节点间的互连互通实际上由现有的计算机网络和通信网络来实现,而互操作      性的研究则建立于互连互通的基础上,由于互操作性的重要性,从 2 0世纪 9 年 0 代开始,人们对其做了较系统的理论性研究,得出了如下的科学定义: 在一个由异质实体构成的网络环境中,当应用在网络的结点运行时,它可以      透明地动用网中其它结点上的资源,并借助这些资源与本节点上得资源共同来完 成某个或某组任务,这种能力被称为互操作性。 互操作性内涵丰富,具有几个不同的层次,如下表 1 所示,      - 1
表1                                - 1互操作的不同层次

互操作层次 A pc o-oao tn plao pla n lbri - pc i it C l ao A itn i

功能

提供应用语义的兼容。 这一合作的程度是最难 实现的, 不仅仅是在物理上将分离的实体连在

一起, 更重要的是这些分离的实体之间能相互
合作

复制透明性等更多的 Tasa ny n r praiy r s r c 能提供诸如迁移透明性、 r pr c-t- e t l - a pe y n e Ie o a bi T n a n t

透明性和诸如安全、服务质量的保证
R C Itr o P - e- mmu iainRP n c nct - C o

提供对话结构, 提供一种能在信息上相互沟通 的方式。例如, P R C就提供了访问透明性。 实现基本数据传输

C n n - tr o n cinCo ts o u sI e- n e t - me n C o

根据互操作性定义中所提到的透明动用的资源的不同,可将互操作性分为面      向计算资源的互操作性和面向信息资源的互操作性 ( 如数据库互通性) 。第 类操

作 是 术 关 的 点 实 操 性 需 借 于 操 中 件8 性 技 界注 重 ,现 作则 要助互 作 间 [ l

k 中间件关键技术的研究与实现 。

122对象级的互操作性 ..
互操作性非常重要,但是如何进行高效、安全、便利于开发的互操作,则需     

要从软件设计技术上找到答案。

在计算机发展的6 多年里,      0 软件技术也在不断发展,随着软件复杂性的不断 增加, “ 基于模块” “ 和 面向过程”的大型软件设计已 经不能满足需求。 面向 “ 对 象” 概念的提出,降低了 大型软件的设计和维护的复杂度及成本。 在网络环境下, “ 分布对象”技术又由 “ 面向对象”技术进一步发展而来,适合于网络环境下的
大型分布式软件的系统建模和设计。

13中间件技术 .
从分布式应用体系结构的发展可以看出,中间件是为解决分布式计算和处理
而产生的。

131中间件的引入 .. 
目前,分布式计算技术得到了非常广泛的应用,但是,开发一个分布式应用     

软件,并使其各部件能可靠有效地协调工作还是比 较困难的。其原因有三:一是 用于开发分布式应用软件的常规工具和技术其自 身的局限性使分布式应用的开发 复杂化:二是分布式应用的开发大量采用了功能分解技术,而用常规的面向功能 编程技术开发应用软件时,往往会导致所生成的系统其结构缺乏可扩展性,从而 进一步增加了应用软件的复杂性:三是由于工程上的考虑和对原系统的继承问题 使分布式应用大多基于异种*台,而如何将这些分别开发的异种环境集成在一起 则牵涉到许多复杂的技术手段,显得困难重重。 为解决上述问题,      提出了中间件 ( i l a ) md e r 的概念, dw e 在学术界和企业中得

到 广 支 , 生 一 列 规 和 际 品 包 M 的CRA 范9 了 泛 持 产 了 系 的 范 实 产 , 括O G OB 规 1 1 Mro的DO 1以 U 公 的E [ 。 间 有 多 类 支 这 ist CM0 及SN 司 J1 中 件 很 分 , 持 种 c f o 1 1 B1 ] 等
面向 对象分布式计算技术的我们称之为面向 对象中间件,本文所讨论的中间件, 都是针对面向对象中间件来研究的。 面向      对象的中间件提供了一个标准的构件框架,能使不同厂家的软件通过不 同的地址空间、网络和操作系统交互访问。该构件的具体实现、位置及所依附的 操作系统对客户来说都是透明的。面向对象的中间件技术的目标就是为软件用户
及开发者提供一种应用上的即插即用的对象级互操作性。

132中间件的概念与特点 ..

第一章 绪论

中间件是一种介于操作系统与应用程序之间的独立的系统软件或服务程序,     

分布式应用软件借助这种软件在不同的技术之间共享资源。中间件不仅仅实现分 布式计算环境中各个相对独立的系统之间的互连, 还要实 现应用之间的互操作。
中间件是基于分布式处理的软件,其最重要的功能是网络通讯功能。

中间件能使处于应用层的各应用成分之间实现跨网络的协同工作,也就是第      一节中所说的应用语义上的互操作性,这时允许各应用成分之下所涉及的系统结 构、操作系统、通信协议、数据库和其他应用服务各不相同,如图1 所示。 - 2

图1                                - 2中间件的定义

从客户机一服务器模型的系统来看,中间件是在前端客户机和后端服务器之      间为 两者提供服务的一个中间 层软件。它能够帮助用户灵 活、高效地开发和集成 复杂的应用软件。中间 件具有标准的程序接口 和协议, 针对不同的 操作系统和硬 件*台,可以有符合接口 和协议规范的多种实现。 通常意义下,中间件应具备以下的一些特点:满足大量应用的需要:运行于     
多种硬件和 0 5*台;支持分布式计算,提供跨网络、硬件和 O *台的透明性的 S

应用或服务的交互功能;支持标准的协议;支持标准的接口。 程序员通过调用中间件提供的大量 A I 实现异构环境的通讯,      P, 从而屏蔽异构
系统中复杂的操作系统和网络协议。

中间      件提供客户 机与服务器之间的连接服务, 这些服务具有标准的程序接口 和协议。 针对不同的操作系统和硬件*台, 它们可以 有符合接口 和协议规范的多 种实现。由于标准接口 对于可移植性和标准协议对于互操作性的重要性,中间件
已成为许多标准化工作的主要部分。对于应用软件开发,中间件远比操作系统和

网络服务更为重要,中间件提供的 程序接口 定义了一个相对稳定的高层应用环境,

I 中间件关键技术的研究与实现 c e

不管底层的计算机硬件和系统软件怎样更新换代,只要将中间件升级更新,并保
持中间件对外的接口定义不变,应用软件几乎不需任何修改,从而保护了企业在 应用软件开发和维护中的重大投资。

133中间件技术规范 ..
目      前己逐步形成以 Mioo 的 C M/C M 技术、S N公司的 Jv/J c sf r t O DO U aa B技 E

术和 O G( M 对象管理组织)的 C R A ( O B 公共对象请求代理体系结构) 技术为代
表的三种中间件主流技术。 () O B        1 C R A中间件技术规范

O G提出的 O B      C R A为分布式对象之间的通信规定了完整的体系结构, M 它注

重 异 环境中 解决 构 分布对象的 操作性问 Mc s .  互 题。 io f S N也己 O B ro U t 与C R A中
间件厂商合作。实际上,C R A技术规范已 OB 成为大家认可的中间件技术规范。 C R A中间件技术规范主要分为三个层次:      OB 对象请求代理、公共对象服务和 公共设施。最底层是对象请求代理 O B R ,规定了分布对象的定义 ( 接口)和语言 映射,实现对象间的通信和互操作,是分布对象系统中的 “ 软总线” ;在 O B之 R 上定义了 很多公共对象服务,可以提供诸如并发服务、名字服务、事件 ( 交易) 服务、安全服务等各种各样的服务;最上层的 C R A 共用设施是接口 OB 语言定义 的组件框架,向 应用对象提供直接应用服务的框架集合,规定应用对象有效协作
所需的协定规则。

() C      M 中间件技术规范 2  D O

Mcs 的      分布式 C M D O ) 展了 对象 技术 (O , io f ro t O (C M 扩 组件 模型 C M) 使其能
够支持在局域网、广域网甚至 Ie e上不同计算机的对象之间的通信。 O 定 nm t t CM 义了部件和它们的客户之间互相作用的方式,使得部件和客户端无需任何中介部 件就能相互联系,客户进程直接调用部件中的方法。当一个客户进程需要和另一 个进程中的部件进行通信时, 不能直接进行调用, 但利用C M技术就能够以一种 O
完全透明的方式进行。当客户进程和部件位于不同的机器时,D O 仅仅只是用 CM

网络协议来代替本地进程之间的通信,使得客户和对象总是在进程内调用或被调 用,而由D O C M技术提供透明的R C 〔 P 远程过程调用)机制。

() v     中间件技术规范 3 Ja a Ja      a 中间件技术的核心是J ae s v a Ba 技术,aae s v n J Ba 是可以复用的软件部件, v n 它可以在一个开发工具中可视化地进行操作,是用 J a a 编写的一种可移植的、与 v

*台 关的 无 部件模型。 企业J a n EB体系结 义可 用的、 a Ba ( ) v e sJ 构定 重 可移植的J a a v
分布式事务服务器组件的设计和发布,它允许用 EB开发的应用程序在多个应用 J 程序服务器上发布,不必为每个应用程序开发专门的 服务器。当然这种服务器必

第一章 绪论

须遵循 EB标准。EB使开发者把精力主要放在开发多用户、高可靠性、高性能 J J 的 应用程序上。 通过使用和扩展JB .  I R I C R A等技术, J D C J D.  和 O B N M EB标准 提供了建立应用程序的统一方式,使这些程序具有永久性、事务处理、集群和负
载均衡等能力,但又不需要开发者直接实现这些能力。

134中间件技术的应用 ..

中间件技术现己      成为构建分布式应用系统的重要支撑技术。它能够解决网络 分布计算环境中多种异构数据资源的互联共享问题,实现多种应用软件的协同工 作, 是网络分布式应用软件的网络 “ 操作系统” 利用中间件可大幅提高应用软件 。 系统的开发效率,增强系统稳定性,使系统便于维护管理,同时具有良 好的伸缩 性与可扩展性,充分保护用户投资、降低系统投资风险。因此中间件已成为分布 式应用的关键性基础设施,广泛适用于各行业关键性的网络分布应用之中。 中间件是处于*台与应用之间具有标准的协议与接口的通用服务子集,      应用
该技术,软件开发人员无须对不同的设备和系统*台设计不同的代码,只要采用

标准化的中间件作为基础构件,就可迅速地开发出具有良 好的可扩展性、高可用 性和可移植性的企业管理软件,是建立大型软件系统和集成电 子商务计算环境的 最佳途径之一。中间件技术的应用使 E P产品的更新速度大大加快,同时也降低 R
了产品的开发成本。 对于应用开发者而言,中间件封装了事务处理的许多技术细节,因而能大大     

减少应用开发的难度。中间件通常也封装了许多通用的事务处理过程,因而使应

用开发商能够专注于应用层的开发, 避免重复性的开发。对于应用系统的用户而 言,中间件的应用能为减少应用系统的开发成本和维护成本建立起良 好的机制。 电子商务的发展对网络系统的可靠性和安全性提出了 越来越高的要求,中间 件对
于提高这些性能具有重要作用。

14中间件技术应用中存在的一些问题 .
尽管目      前来说,中间件是一种比 较成熟的技术,但是也在各个方面仍存在大
量的问题 。

141不同中间件*台的局限 .. 性
自      从上世纪九十年代以来, 计算工业一直在使用像 D O 和 C R A这样的 CM OB

面向对象中间件*台。然而,由 于一些原因,无论是D O 还是 C R A CM O B ,包括

后 的 OP pOeAePt i1 Wb e 未 成 占 大 来 S ( lb t  rc)  eei都 能 功 领 A S e  cs o o1 i j c o 2 sc m c s  1 和 r v
部分计算市场:

I 中间件关键技术的研究与实现 c e

首先, D M      O 与N T是微软的独家解决方案, C E 最严重的 缺点是不支持非 Mc s t io f*台。 ro 而且 D O C M和 .E N T都过于复杂。 要熟悉D O C M或.E ,并进 .T N
行相应的设计和编程,是一项需要许多个月来掌握的艰难任务。

C R A最严重的缺点是老化的*台、      OB 高度的复杂性,以 及仍在发生的供应商 磨擦。尽管有多家供应商提供 C R A产品,几乎不可能找到一家供应商,能够 OB 为异种网络中的 所有环境提供实现。 尽管进行了 大量标准化工作, 不同的C R A OB 实现之间仍缺乏互操作性,从而不断地造成各种问题:而且,由于供应商常常会 自 行定义扩展,而 C R A又缺乏针对多线程环境的规范,对于像 C或 C +这 OB + 样的语言, 源码兼容性从未完全实现过。 而且, O B C R A非常复杂,它的开发也和 DO C M一样,都需要很长的时间来学* 上手。 S A 和 We s i s      b v e最严重的缺点是低效, OP e c r 需要使用私有开发*台, 并且还 存在安全问 题。 S A 而一 无论是在网络带宽方面, 对 O P 言, 还是在 C U 开销方面, P SA O P都会给应用造成严重的性能恶化,以至于该技术无法适用于许多有苛刻性 能要求的系统。并且缺乏更高级的抽象促使供应商提供各种应用开发*台,使遵
从SA O P的应用开发自 动化。而 We s v e b  i s是一项还处在幼年的技术。到目前 e c r 为止,己进行的标准化很少,而且看起来还需要好几年,其标准化水*才能达到

源码兼容性和跨供应商互操作性所要求的完备程度。关于 S A O P和 W b v e e s is ec r
的架构安全性,有一些严重的担忧。

综上所述,原有的中间件技术方面的确缺乏能够在跨*台能力、性能、互操      作性、开发便利性等等方面都能有竞争力的产品,所以,如何选择一个合适地中 间件产品成为所有项 目开发人员所要面对的首要问 题。尽管说针对于具体应用, 具体的公司或组织总可以从以上几种中选择一个最适合所要开发项目 需要的中间 件产品,这个问题的最终解决只能依赖于技术的不断发展。本文所要重点论述的

I中 件 是 个 好 解 了 上 种 间 各 缺 的 型 间 产 [ C 间 就 一 很 的 决 以 几 中 件 自 憾 新 中 件 品1 。 3 ]
关于 I 中间件将在后续章节详细介绍。 c e

142中间件两种互操作性的缺位 ..

面对规模和复杂度都越来越高的分布式系统,      现有的中间 件技术也显示出其 两方面的固 有局限性:一方面,中间 件技术对传输层协议有很强的依赖性,几乎 所有的中间件技术都是在传输层以上做的, 所以, 一般来说说只能支持T P C 协议, 对其它的 传输层协议和其它的底层传输机制都不支持,所以 用它们开发出来的产 品的业务扩展严重受限;另一方面,不同 厂商间的中间件产品互通性越来越成为 企业级产品关注的重点,尽管各大厂商都为中间 件领域的标准化过程表达了足够 的 热情, 如O G组织推出的C R A标准, 经成为事实上的中间件领域的规 比 M OB 己

第一章 绪论

范,但由 于各个厂商对 C R A标准下各自的产品实现各异,而且围绕着 O B核 OB R 心开发出了各自不同的各种服务集合,导致不同厂商间的中间件产品互通的可能 性几乎为零。这样,在可能采用不同中间件产品的大型企业或组织内部,都形成

了“ 烟囱效应” 系统各个模块的技术含量很高,能够很好地独立完成各自 ( 模块所 需的功能, 但是模块间互通性互操作性很差,从而制约了整个系统的能力) 。

15论文选题来源和所做工作 .
本文选题主要来自十五国防预研项目 “      海军综合网管系统” ,该预研项 目目 前已总体完成并通过相关部门的验收。本论文的研究工作重点在于通过对中间件

传输层协议扩展和I 与C R A互通信两项关键技术的 c 。 OB 研究, 来进一步提高网管
系统各组件的网络通信模块的可互操作性。由于其研究重点主要集中于中间件领

域, 研究结果具有通用性,对其它中间 件相关项目 也有着直接的参考借鉴价值。 军事通信和民用通信有着很大的不同,集中体现在带宽受限、抗毁性要求很      高和严格的通信保密性等方面。在此基础上,不同设备、不同系统、不同指挥体

制 的 互 有 错 复 的 为 定1 间交都着 综杂人 规[ 4 1
将普适计算和网格计算的要求对应到军事领域,就是要求指挥、控制、计算、     

通信、情报、监视和侦察的无缝结合,即就是 CI 。目 4 R 前,各国军队军兵种之 S 间的CI 4 R系统大多表现为各自 S 相对独立开发的“ 式结构”技术体制不统一, 烟囱 , 互联互通能力差。 特别是 C 1 4 R系统只能链接和处理通过计算机通信联网的信息, S 而对其它设备的数字化信息,比如战场前端的传感器、作战要素的火器、射击系

统等仍不具备兼容共享的能力。 这些问题反映在战场上,主要表现为低级战术部 队、各种武器*台和单兵在战场上的横向、实时、无缝隙连通存在问 题。这些问
题是所有的军事通信系统都要面对的,本文所做的工作分别在这个问题的两个不 同角度入手,对这个难题进行了积极地尝试。 本文所有的工作都是围绕新型中间件产品I 来进行的。      c e 首先,用半年多的时间来着力于分析该中间件产品的源代码,详细地解析各      功能模块的实现特点,深入体会 I c e中间件较之原有中间件产品的设计上独到之
处。

然后,      提出并实现一个现实的传输层替换方案, I 的传输层支持不但可以 使c e

使用U P SL C I 体系下的传输层协议, D >  等T PP S I 也可以 用串口, 使 短波等等复杂
多样的底层传输机制。这样的话,分布式面向对象的技术思想对现有的一些特有 传输机制组网下的互操作协议开发产生革命性的影响, 从而最大程度地减小成本, 增加效率。
最后,在 c      I 与 C R A间设计并实现了交互框架,可应用于 I 与 C R A e OB c e OB

k 中间件关键技术的研究与实现 e

之间的互操作。这样的实践使不同种中间件产品之间的互通性*蟠蠹跎伲 于不同中间件产品互通性差所造成的系统整体性能受限的问题会随之消失,系统 模块间的互操作潜力将得到进一步释放。

总而言之,提高中间件的互操作性将最大限度地扩展中间件的应用环境,提      高中间件产品在大型分布式系统应用中所能起到的作用,从而为构筑于其上的各
种复杂业务逻辑服务。

16论文内容安排 .
本文首先从互操作性入手,重点分析当前中间件产品新的互操作性需求,然     

后通过对现阶段的I 中间件产品进行介绍, c e 分析其代码实现框架, 最后介绍了传

输层协议替换以 I 及 C C R A 中间 。与 O B 件互通信的两项关键技术的设计与实现方
案。

本文各章节内容安排如下:     

第一章首先从普适计算和网格计算上归纳出新计算技术对互操作性的更高要      求, { 并弓入互操作性及分布式对象计算的相关背景知识, 接着介绍了中间件技术, 并在此基础上,介绍了中间件技术在互操作性上的一些不足之处。最后介绍了论
文的选题来源和所做的工作。 第二章介绍了I 中间件的概念、      c e 结构及服务组成, 为其后的代码分析跟关键 技术的实现做铺垫。 第三章重点介绍 I 中间件的各核心组成模块原理,并且对I 实现中所使用      C 。 e c 的一些设计原则进行详细阐述。

第四章详细论述了I 传输层替换的设计思路,并描述了      c e 支持串口 通信的 I c e 串口扩展插件的实现方案。 第五章详细论述了I 与C R A互通信的设计思路,      e c OB 并描述了具体与C R A OB 中间件J O B互通信的实现方案。 aR c
第六章是全文的总结和结束语。     

第二章 网络通信引擎

第二章 网络通信引擎
2 1网络通信引擎 (c ) .  工e
网络通信引擎 Ie e o m n aos i .  是由Zr      ( tn Cm uitnEg e I ) n r t  ci n n c e e C的分布式系 o
统开发专家实现的一种新的高性能的对象中间件*台。

I 不同      O B I, 它与C R A 存 c e 于C R A" 但是 ] O B 确实 在着千 丝万缕的 联系。 先, 首
其主要的设计和实现人员都曾经是 C R A专家, O B OB 在C R A技术的实现和推广过 程中起到举足轻重的作用。也正是由于他们亲历了 C R A 由创建伊始到成为主 OB

流 全 过 , 以 了 OB 体 中 在 不 如 意 弊 11 k中 的 部 程 所 更 解CRA 制 存 的 尽 人 的 端 ]。 。 0刀 l
也借鉴了许多 C R A的优秀理念。从应用者的角度看来,I 更像是在 C R A OB c e OB 上进行升级或者革新。相似的理念使得两者从外部看确实有许多相似之处,例如: 都提供完善的分布式系统解决方案,都有一种接口定义语言,提供许多功能相似 的服务等等。然而,实际上,它们对于相似理念的具体实现是有很大不同的。 C R A 的不足之处阻碍了它在某些领域的推广和发展,并且在现有的体制      OB
下,想仅仅通过上层的修补来完善这些缺陷几乎是不可能的。I 通过重新设计和 c e

实现底层的基础结构,使对象中间件的性能得到了很大的提高。I 的优势在于简 c e 单紧凑的结构和高效的通信性能。 I 对中间件技术的许多方面进行了革新。      c e 它提供完善的分布式系统解决方案, 适合所有的异构网络环境:客户端和服务器端可以用不同的程序语言实现,运行 在不同的操作系统和不同体系结构的机器上,使用不同的网络通信技术。像 C R A一样,I 也提供了客户端与服务对象的完全分离,客户端不需要了 OB c e 解服 务对象的实现过程以及具体位置。I 采用软总线机制,使得在任何情况下、采用 c e 任何语言开发的软件只要符合接口规范的定义,均能够集成到分布环境中去。I c e 采用对象模型, 将所有应用看成是对象及相关操作的集合, 可以 构建在 I 之上的 c e
分布式系统中的应用对象的获取只取决于网络的畅通性和获取服务对象特征的准

确程度,而与对象的位置以及对象所处的设备环境无关。

I 具有简单的对象模型和类型系统,精练而功能强大的运行时A I      c 。 P,简单的 语言映射,紧凑高效的协议,丰富的调用和派遣模式,完善的安全解决方案,大 量高效实用的服务和工具。与包括 C R A在内的各种中间件*台相比,I 更适 OB c e 合那些对技术和性能要求很高的分布式应用程序开发,例如电信,国防,在线娱 乐等领域。目 I 经被惠普、Mu b Ra s 前 c e已 t l el 等众多大型公司所采用,为其提 a e  m 供安全、伸缩性强的底层通信*台。
在我国,     关于 I 技术的研究,无论是在民用还军用领域,都没有得到足够的 c e

I 中间 c e 件关键技术的 研究与实 现

关注。在本文的相关章节中,对 I 技术的原理及应用进行了较为详细的介绍。 c e

22 e . c 结构 I
I c e是一种面向对象的中间件*台。 从根本上说, 这意味着 I c e为构建面向对

象的客户/ 服务器模式的应用提供了工具、 应用程序接口和库支持。 c 的体系结构 I e

如 2所 [ 图 . 示1 1 8 ]
客户端应用程序 服务器端应用程序



; 聋

:    { ‘ 1

. S E译 成 码 L 编 生代 I C

曰 IA cP e  I

图2 IE . C 体系结构 1 

22 1客户端与服务器 ..

客户端与服务器这两个角色不是对应用的特定组成部分的严格指称,而是表      示在某个请求从发生到结束期间,应用的某些部分所承担的角色。客户是主动的 实体,它们向服务器发出服务请求。服务器是被动的实体,它们提供服务,响应 客户请求。从服务器不发出请求、而只是响应请求的角度看,许多服务器通常不 是纯粹的服务器:它们常常充当某些客户的 服务器,但为了完成它们的客户的请 求,它们又会充当另外的服务器的客户。与此类似,从只请求服务的意义上,客 户端常常也不是纯粹的客户:它们常常是客户/ 服务器的混合体。 例如,客户可以 在服务器上启动一个长时间运行的操作,在启动该操作时,客户可以向服务器提 供回调对象,供服务器用于在操作完成时向客户发出通知。在这种情况下,客户 在启动操作时充当客户,而在接收操作完成通知时充当服务器。这样的角色反转 在许多系统中都很常见,所以, 许多客户 反 朋 务器系统常常可以被更准确地描述为

对等 ( etp r 系统。 户端与 器 色只 行某 p r -e e- e ) o 客 服务 角 在执 个特定操作的 特定时间
具有绝对的意义。

第二章 网络通信引擎

222 e .  I 核心 . c

I 核心包含大量的链接库,是处于核心地位的对象总线,为客户端和服务器      c e 的远程通信提供运行支持。它主要关心的是线程,字节序和其它一些网络细节及 相关事务,并将应用程序与这些底层事务隔离开。I 核心定义了异构环境下对象 c e

透明地发送请求和接收响应的基本机制, 是建立对象之间的客户端/ 服务器关系的 核心组件。它使对象可以透明地向其它对象发出请求或者接收其它对象的响应, 这些对象可以 位于本地也可以 位于远程机器。 。 k 核心拦截客户端的请求调用, 找 到可以实现请求的服务器对象,并负责传送参数、调用相应的方法、返回结果等。 客户端对象并不需要了解同服务器对象通信、激活或存储服务器对象的机制,也 不必知道服务器对象位于何处、用何种语言实现、使用什么操作系统或其它不属 于对象接口的系统成分。对于服务器对象,也是如此。I 核心提供的客户端和服 c e 务器的松散祸合的通信模式,使得开发人员可以把更多的精力放在应用逻辑的实
现上 。
2 2 3 c A I . . I e P

I 应用      c e 程序接口(plaoP g m i iea  A I 提供 c核心 A pci r r mn nrc P) 对I itn  a g  fe  o t e
的通用部分 ( Lc 中定义的特定类型无关的 与S I e 部分) 的访问, 程序开发人员可以

使 I AI 用 c P做一些I 的 e  c 管理事务, e 例如初始化和结 I 的运行。 束c e 客户端和服
务器所使用的 I A I c P 是一样的,在服务器端使用的可能会多一些。 e 

224对象适配器 .. 对象适配器是专用于服务器端的I A I的一部分:      c P e  只有服务器才使用对象适 配器。 对象适配器有若干功能:

. 对象适配器把来自      客户端的请求映射到服务器端特定对象的特定方法上。 . 对象适配器会跟踪在内存中的伺服对象,记录其对象标识,从而实现适配     
请求的功能。

. 对象适配器可以      与一个或多个传输端点关联在一起。 如果与某个适配器关 联的传输端点不止一个,就可以通过多种传输机制到达在该适配器中的伺服对象。 为了提供不同的服务质量和性能,一个适配器可以同时关联一个 T P P C / 端点和一 I
个U P D 端点。

. 对象适配器负责创建传给客户端的 I 代理。对象适配器知道每个对象的      c e

类型、标识以 及传输机制的详细信息。当服务器端应用程序要求创建代理时,对 象适配器会在其中嵌入正确的信息。

k 中间件关键技术的研究与实现 e

225 e .  I 代理 . c

代 代      用 义的SI (p i a n g g f I ) 理 码是由 户定 L e  ef t Lnu e  c 文件经过 c S c ci a a o e i o r  编
译后生成的。一个客户端要想与一个 I 对象建立联系,必须持有该 I 对象的代 c e c e 理。 代理是存在于客户端地址空间中的远地 I 对象的代表。 c e 代理主要有两个功能: 为客户提供了一个向下调用的 (o n a)接口。如果客户端调用代理中的      dw - l cl 某个操作, 就会有一个 R C 消息被发送到服务器, P 从而调用目 标对象上的某个对

应的操作。以代理为中介,客户端发起的调用最终会调用到服务器目 标对象上相
应的操作。

提供了      ( ahi ) 编码 mr an 和解码 ( mra g。 s lg u ahi ) 编码是 n sl n 将复杂的 据结 数 构
串行化, 使其便于网络传输的过程。编码把数据转换成适于传送的标准形式,这 种形式不依赖于本地机器的字节序和填充规则。 解码是编码的逆过程,将通过网 络得到的串行化数据重新构造成具有类型的结构化数据。 解码之后得到的是与所 使用的编程语言相适应的类型表示的数据。
226 e .  I 骨架 . c

骨架 (k e n     lo )代码也是由用户定义的 S I 文件经过编译后生成的,其中 se t Lc e 的内容与 S I 中定义的对象和数据的类型是对应的。骨架代码是客户端的代理 Lc , e

代 服务 端的 码在 器 等价物。 供了向 用 ( -l 的 , 它提 上调 u cl 接口 允许I 把控制 p a) c e
线程转交给服务器端的应用程序代码。骨架也负责编码和解码,所以服务器可以 接收客户端发送的参数,并把返回值和异常传回客户。

23 Ie . S c 语言 L
在典型的客户/      服务器模式的应用中1 1 ,开发者使用自 的描述语言或一种公 己 认的标准来定义设备之间需要使用的协议。 协议的定义依赖于其实现所用的语言、 网络传输的 情况以 及许多其它的因素。 I 使这个过程变得很简单。在 I 中, 而c e c e 协议是通过使用 S I 语言描述的相关应用程序接口 Lc e 来定义的。 这是一种十分简单
的,且与编程语言无关的描述语言。
231 Ie .  S c 合约功能 . L

S I 是一种用于定义客户和服务器之间的合约的基础性机制。      Lc e 每个 I c e对象 都有一个接口,该接口具有一些操作。 接口、操作,还有在客户及服务器间交换 的 数据的类型, 都是用 S I 语言定义的。 Lc Le c SI e允许开发人员以 一种独立于特定
编程语言的方式定义客户端和服务器端的合约。Lc SI e定义由一个编译器编译成特

第三章 网络通信引擎

定编程语言的A I 通过用 S I 定义数据类型和接口, P。 Lc e 可以创建出与语言无关的
A I定义。 P

因为 S I     。描述的是接口 L c 和类型,不是具体实现,所以它实际上是一种纯粹 的描述性语言, 不能编写可执行语句。 L 。定义关注的焦点是对象接口、 SI c 这些接 口所支持的操作,以及操作可能引发的异常。同时也非常关注数据类型的定义。
只有在其类型用 S I Lc e进行了定义之后,数据才能在客户与服务器之间交换,这 是I c e提供语言无关性的根本保障。 Lc SI e具有完整的语法和语义, 所以开发人员 总能创建一种 S I 类型定义, L二 与想要发送的与特定语言相关的数据类型相对应。 SI      Lc e编译器生成的源文件与应用程序代码相结合后, 就能产生客户和服务器

端的可执行程序。 无论目 标环境使用的操作系统是否相同,无论它们是否使用相 同的语言实现,这两种可执行程序都可以部署到网络的任何地方。唯一的约束是 宿主机器必须提供必要的运行时环境,如必需的动态库,同时双方的宿主机器要
能够建立网络连接。

232 Ie .  S c 的翻译机制 .  L S I 是一种用于使对象接口      LC 。 与其实现相分离的基础性抽象机制。SI 所描 Lc e 述的各种数据类型和对象接口与具体的实现语言无关,所以客户端应用程序和服
务器端应用程序可以使用不同的编程语言。Lc SI e定义由S I 编译器编译到特定 Lc e 的实现语言。编译器把与语言无关的数据类型和接口的定义翻译成针对特定语言 的类型定义和 A I P 定义。服务器端按照这些定义提供应用服务,客户端按照这些

定义获取服务。I 前己经实现了SI c e目 L 二到C 十、 aa .E , ul i + J ,  T Vs Bs , v N i a ac

Pt n H 的 射。 y o 和P P 映 其中I 到C+ 映 是 h c e +的 射 线程安全的, 并且能 效地防 有 止
内 存泄漏。如此丰富和强大的映射类型是其它任何中间件产品所不具备的。 S I 提供了常用的简单的内建类型,      Lc e 并允许用户创建自 定义的、 具有任意复

杂度的 类型,比 如序列、枚举、结构、词典,以 及类。多态是通过接口、 类,以 及异常的继承来实现的。而异常又提供了 一些措施,可以进行高级的错误报告和 处理。模块允许用户把一个合约的相关部分汇总在一起,防止名字空间的污染; 通过使用针对特定编译器后端的指令, 元数据可用于对SI 定义进行补充说明。 Lc e SI      Lc e的语言映射是一些规则,决定怎样把每个 S I Lc e成分翻译到特定的语 言。例如, + 射而言, L e 列 ( q n ) 就C +映 SI 序 s u c 会作为SL向 ( cr c eee T 量 v t) eo 出现,而就 J a映射而言, Lc a v SI e序列会作为 J a数组出现。要想了 a v 解如何使 用A I , P 接口 只需要知 L e 义, 且了 道SI 定 并 解语言 射的简 c 映 单规则既 不 可, 用
阅读 S I 编译器生成的代码。 LC 。

I 中间件关键技术的 c e 研究与实现

24 e . c 协议 I
S I 是I 对象的描述方式,I 核心是 I 对象互通信的中介,而 I 协议      。 Lc c e c e c e c e 则是通信的具体实现。k 协议可以建立在多种流行的通信协议之上,定义了客户 。 端和服务器端的 I 核心之间的通信机制。 c 协议的设计简单、开销很小、同时 c e I e
又具有最广泛的适应性和可扩展性,以适应不同网络。 24 1工e .. c 协议的组成

I 提供了一个 R C  e o P c u Cl      c e P ( m t r e r a)协议,该协议能够运行在各种 R e  d e  l o 流传输和数据报传输协议上。目 前,该协议支持T P U P S L C ,  和 S 作为底层传输 D 机制。使用 SL协议时,客户端和服务器端之间的所有通信都可以进行加密,以 S

确保传输的安全性。c 协议的引擎是可以扩展的, I e 开发人员可以 通过增加A I P插 件来增加新的底层传输协议, 而不用修改源代码。c 的S L I e S 传输就采用了这种插
件结构。I c e协议定义由三个主要部分组成:

. 数据编码规则:确定各种数据类型的串行化方式。      . 协议状态机制:规定客户端和服务器如何交互不同类型的信息。     

. 版本控制:      确定客户与服务器怎样就特定的 协议和编码版本达成一致。 编 码规则和状态机制使用各自 独立的版本号,从而保证了良 好的向后兼容性。
242工e .. c 协议的优越性

C R A的H P      O 协议存在许多缺陷。 OB 例如:H P O 缺少对请求的封装,不利于 类型化信息的传送;H P编码规则中的填充规则浪费了一些带宽,降低了编码速 O

率; O 信 在bt H P 息 y 序不同 机 上 送时 每次 要 行bt 转 效 较 。 的 器 传 , 都 进 y 序 换, 率 。
低; 地址信息在 H P中的位置不固定, O 在穿越防火墙时带来了一些问题。c 的协 I e

议的构建是在充分认识到这些问题的 基础上进行的,所以在诸多方面都进行了重 新设计,性能和效率都有很大程度的提高。

I编      简洁紧凑。 有的 c 码规则 e 所 数据都 定的 序, 用bt 用固 字节 采 y 对齐, e 不作
任何边界填充, 保证了 编码体积最小化 带宽利用率很高。I 的协议状态机制十 C 。 分简单,只有 5 个消息类型。 I      c e还支持在线路上进行压缩: 通过设置协议头中的一个标志位, 可以压缩通 信的所有数据。在带宽资源匾乏的环境中,以及客户端与服务器之间需要交换大 量数据时,这种功能可以有效的节省带宽。 I      c e协议还适用于构建高效的事件转发机制。通过 I 协议传输的所有数据都 c e
是经过封装的,这种设计机制保证了转发数据时,中间节点不需要 了解数据 内部

第三章 网络通信引擎

的详细信息。这意味着,中间节点不需要做比特序转换和任何编码解码的工作,

它们只是简单地把消息当作不透明的字节缓冲区加以转发。 I      c e协议还适用于构建双向操作: 如果服务器想要把一条消息发送给客户端提

供的某个回调对象, 这个回调对象可以通过客户端发起调用时创建的连接传送消 息给服务器。该特性在穿越防火墙时十分重要。 如果客户端位于防火墙后面,通 常只允许建立向外的连接而不允许建立向内的连接,这样以来,服务器回调客户
端的操作时就会产生问题,该问题一直困扰着 C R A*台上的开发人员。 OB

243数据编码规则 .. I      c e数据编码的关键设计目 标是简单和高效。遵循这一原则,I c e编码没有在

字边界上对齐原始类型, 因而避免了带宽浪费, 也消除了 对齐所带来的复杂性。c I e 数据编码产生的就是一个连续的数据流,数据不含填充字节,也无需在字边界上 对齐。在 I c e编码时,数据总是使用”t - d n lle i ”字节序 ( ie n a 大多数机器都使用

"t- dn 字节序, lle i “ ien a t 所以I c e数据编码 “ 确”的时 正 候要比 不正确的时候多) 。 I      H P所使用的 “ C 。没有使用 O 由接收者负责使其正确”的 方案,因为这种方
案会引入额外的复杂性。例如,在常见于事件分发服务的接收者链中,每一个接

收者都沿着链转发数据, 直到数据到达最终的接收者。c I e协议允许所有在中间的 接收者直接转发数据,无需进行解码。中间接收者只需复制二进制数据块,就可 以 把请求转发出去。而如果使用的是 “ 由接收者负责使其正确”的方案,只要链 中的下一个接收者的字节序与发送者的字节序不同,中间接收者就必须解码和重 编码数据,这使传输的效率降低。采用 k e的传输方案的代价是要求运行在

"gni” b-dn 机器上的客 ie a 户端和服务器, 接收 链的 和目 端, 即 者 源端 的 对数据的 字
节序进行交换, 变成"t - d n 布局。与发送或接收请求的总代价相比,这样 i en a lle i ” t
的代价实际上无关紧要。

244协议状态机制 ..

I      c e只有五种协议消息, 相对与其它通信协议来讲是相当简单的。 它们分别是: 从客户端发到服务器的请求和批请求消息;从服务器发到客户端的答复和验证连 接消息;以 及双向发送的关闭连接消息。在这些消息里,验证和关闭连接消息只
用于面向连接的传输机制。 和数据编码一样,协议消息也没有对齐限      制。除了 验证和关闭连接消息,每 个消息都由一个消息头和一个紧跟其后的消息体组成。

I 中间件关键技术的 c e 研究与实现

2 5 e . c 服务 I
I      c e核心为分布式应用程序开发提供了一个完善的*台。 现实中, 应用程序需 要的常常不止是远程通信能力,有时还需要随需启动服务器、把代理分发给客户 端、异步分发事件、配置应用、分发应用补丁等诸如此类的服务。除了核心功能 之外,I 提供了大量这样的服务。这些服务被实现成 I c e c e服务器,应用程序充当

这些服务器的客户端。使用这些服务可以大大的简化分布式应用程序的开发。这 些服务作为I *台的一部分, c e 使开发人员可以专注于应用程序的开发, 而不必事 先构建许多基础设施。 下面重点介绍经常使用到的两个 I 服务, c e 其它服务仅做简
要介绍。
2 5 1 c P c . .     a k Ie

I Pc 是一个完善而复杂的服务器配置和激活工具。它的主要功能是提供定      ca e k
位服务。

客户端通过代理发起调用请求。代理分为直接代理和间接代理。直接代理中      保存有服务器的地址的详细信息。 使用该信息, 直接代理可以直接连接到服务器。 而间接代理中只包含对象适配器的信息,没有任何服务器端的地址信息。但是, 间接代理是一种更为常见的代理方式。间接代理支持服务器的透明迁移,即使服 务器地址改变,客户端所持有的己有代理也不会失效。如果使用的是直接代理, 虽然不用为了定位服务器而进行额外的查找,但是如果服务器被转移到其他机器 上,代理就不能继续工作了。可见定位服务在分布式系统中是相当重要的,可以 大大的提高系统的灵活性。 在IPc 维护了     中 ca e k 记录着对象适配器名和服务器地址的 对应关系的映射表。 通过检索这张表,客户端就能获取服务器端当前的地址信息。这个过程类似于通 过D S N 将网络域名映射成 I地址。通过这种间接代理和I Pc 相结合的方式, P ca e k 服务器的迁*换嵊跋斓娇突Ф说恼9ぷ鳌 I Pc      ca e k提供了一种简单的 对象查找服务, 客户端可用来获取它们感兴趣的对 象的代理。除此之外, c a 还提供服务器激活服务:当客户端发起请求时,服 I Pc e k 务器可能处于未运行状态, ea I Pc c k会在第一个客户请求到达时, 随需启动服务器。 通过 I Pc,开发人员可以 ca e k 轻松地配置包含若千服务器的复杂应用。
2 5 2 c S o m . . Ietr

应用常常需要把消息分发给多个接收者。由      信息发布者直接向消息使用者发 布消息的构架有一个很大的缺点— 发布者和使用者紧密地祸合在一起:为了传

第二章 网 络通信引 擎

送消息,要求发布者了解所有使用者的通信细节;如果传送出错,发布者还要进
行相应处理。这种过程相 当复杂,但是这种需求却相当常见。如果能有一种通用

的服务,那么应用程序的工作将得到极大的简化。 ISr     就是这样一种消息的发布/ c tm eo 订阅服务,能够消除消息的发布者和订阅 者之间的祸合关系。cS r I t m充当发布者与订阅者的中介。 eo 当发布者准备好分发一 个新消息时,它只需要简单的向I S r 服务器发出一个请求,而不用对订阅者 c tm eo

有任何了 解。由I S r 服务器全权负责把消息递送给订阅者,I S r c tm eo c tm还负责 eo 处理由于订阅者的行为有问 题或订阅者不存在所造成的异常。发布者不再需要关 注它的订阅,甚至不需要知道此时是否有订阅者。与此类似,订阅者仅需要与 I S r 服务器进行简单的交互,完成像订阅和取消订阅这样的任务,就可以获 c tm eo 得感兴趣的消息。发布者可以专注于其应用程序特有的职责,而不是管理订阅者 这样的琐事。订阅者也可以集中精力解决对消息的处理,而不用关心其它琐事。 要把 I S r c tm整合到应用程序中, eo 消息的发布者和使用者仅需要做出很少的改动。 发布的消息是按照主题进行分类的,订阅者会指定它们感兴趣的主题。只有      那些与该订阅者感兴趣的主题相吻合的主题才会发布给这个订阅者。订阅和取消 订阅主题消息都很简单。 cS r I tm支持任意多个主题,主题还可以根据其 cs属 eo ot 性联盟 ( dre) I S r 作为联盟服务运行时,服务的多个实例可以在不同 f e t .  t m e ad c o e 的机器上运行, 使处理负载分摊到许多C U 上。 cS r P I t m服务还允许指定服务标 eo 准质量,从而在可靠性和性能之间进行适当 折衷。 IS r      c t m实际充当的是事件分发的中介。 eo 发布者把事件发布给 I S r c tm服务, eo 由它发布给订阅者。这样,发布者发布的单个事件就可以发送给多个订阅者。如 果需要把消息分发给大量的应用程序组件,I S r 是十分合适的选择。 c tm eo
2 5 3 e F e z .. Ier ee

F e。 c     I 的持久化服务。r z 服务包括两部分 Fe e r z是 e e Fe e e r z 映射和 Fez 驱逐 e r e e

器。 所有的 化数 持久 据都保存在内 嵌的Brl 数据库中。 rz 映 一 eey ke F e 射是 个相 ee
关性容器,应用程序开发人员就可以在程序中 Fe e映射提供的容器存储和读 用 rz e
取持久化数据。 r z 驱逐器的主要功能是维护伺服对象的持久性。 Fe e e 在大型应用程

序中, 如果所有 I 对象的伺服对象都保存在内存中,开销十分巨大。 r z 驳逐 c e Fe e e 器维护一个活动伺服对象的队列,如果队列满了,最*最少使用的伺服对象将被 驱逐 ( 保存在数据库中) ,为新激活的伺服对象在内 存中让出位置。
2 54 c G a ir . . Ie lc e

Gai le I c r是 c e防火墙服务。它能让客户与服务器在不牺牲安全性的前提下,

I 中间件关键技术的 c e 研究与实现

通过防火墙安全地进行通信,并极大地简化了安全应用程序的配置。用 Gai 作 le cr 为服务器端的防火墙,由Gai 来验证和过滤客户端的请求,并以一种安全的方 le c:

式回调客户端。与I SL c S 相结合, li 提供了 e Ga e cr 一种非侵入式的、易于配置的、
强大的安全解决方案。
2 5 5 c B x .. Ieo

I Bx c      I 服务的应用程序服务器, c o是 e e 使用它可以容易地运行和管理动态装载

的 各种 I 服务。 c e 这些服务可能是 动态链接库, 共享库文件或者 J a I Bx a 类。 c o v e
将己开发的各种服务作为动态加载的组件配置到一个结合了各种需求的 “ 超级服 务器”中口通用的I B x c o 服务代替了单个的I 服务。I B x e c e c o 方便了开发人员对 e
各种服务进行集中管理。
2 5 6 c P t h .. Ieac

I Pt      种软件修补服务。 c ah是一 e c 用它把软件更新分发给客户是十分方便的。 客户可以简单地连接到I Pt , c a h 请求获得特定应用的更新。 e c 这个服务会自 动检查 客户软件的 版本,并以一种压缩形式下载任何更新过的应用组件,从而节省带宽。 可以 Gae 服务来保护软件补丁,只让得到授权的客户下载软件补丁。 用 li cr
2 5了 Ier d . . cG i

I Gi是I 3 版本新推出的一个功能,I Gi是 I 定位服务的一个实现 c r e d c. e0 c r e d c e

它从间接绑定的协议一地址对中将一个间接代理中的符号信息解析出来, 除了能够提供简单的服务对象定位功能( 3 及3 以后版本中,cPc 在 . . 0 0 I a e k 被所完全 I Gi替代) c r e d ,还提供了一下网 格计算的一些特性。

26本章小结 .
本章介绍了一种新的对象中间件技术— 网      络通信引擎 ( e。 I 的介绍 I) 对 c c e 主要集中 在其结构、Sc 语言、 le i 通信协议以 及所提供的通用服务等几方面。在对 I 的介绍过程中重点突出了该技术资源利用率高,性能优越的特点。 c e

第三章 I 中间件核心代码分析 c e

第三章 I 中间件核心代码分析 c e
本文对 I      中间件源代码分析主要集中在 1 .版本的C 十 c e .1 5 + 代码分析,c 是一 I e 个基于G L P 协议的开放软件, 商用则需要支付le e i n 授权费用。 普通的研究 cs 所以 者才可以得到所有的 I c e源代码,通过研究其代码来对设计思想其进行深入的理
解。

31整体概述                        . 
311工e .. c 核心功能架构分析

I 作为一个中间件产品,其使用过程中,      c e 有运行时 ( r t e 环境和 也称 u i ) n  m
开发环境两部分。rn  e u t 环境顾名思义,就是指使用 I 开发的应用程序,在使 i m c e

用中所需要依赖的I 相关的程序或服务。 c e 而开发环境则包括一些编译生成使用I c e 的应用程序而要使用的相关程序和类定义。 u t e r i 环境是开发环境的基础,如图 n  m
31 -所示的 I 核心功能模块图,主要指的 I r t e c e c u i 环境的相关模块。 e  m n 

应用程序

I 通用服务 c e
1 1

- 门 |
1 1 1 1 1 1 1 1 1 1

r l

iO mA f 3 5 } W

** 插 * I、 /C  g  x 7 f "
| | | 1 | |
l l l l l
S L S

.|



传输层协议                 

T U C D P P 丫         
图31 核心功能的模块组成图                            -I c 。

可见,I      核心功能实际上由六大子系统模块共同分担,分别是通信模块、对 c e 象适配模块、线程模块、调用/ 分派模块、桩和框架模块和插件模块。

I 中间件关键技术的研究与实现 c e

通信模块处于核心地位,它包括端点,引用和连接的管理。对象适配模块负      责在服务器端根据客户请求提供合适的 Sr n。线程模块提供 I e at v c e运行时的线程 池,并且提供便捷高效的方式管理线程池。调用和分派模块负责客户端请求的发 送和接收,服务器端对响应的处理和对客户端的答复等等。桩和框架模块主要用 来根据用户定义的接口语言,分别生成客户端和服务器端的相关类和文件,起一

个用户接口 语言到I 协议语言的解释翻译作用。 c e
上述模块将在本章后续各节内详细介绍。     

312  代码框架 .  Ie .  c
I      c e的核心程序在两个工程内,一个工程是 I ,另一个是 I Ui c e c t,前者主要 e l

为I r t 。 c u i 所用,后者为I 运行环境下所关联的一些辅助工具类。一般情况 e  m n  c e 下, 两个工程的输出都以动态链接库形式存在。 我们所说的k 核心的分析主 所以 。
要指这两个工程中相关类与对象关系的分析。

图3  I 核心代码的                      - c 2 e 框架总览

图3 从宏观上描述 I 核心类之间关系的草图, o m n a rC - 2 c e C m ui t l  c o 通信器) 是

第三章 I 中间件核心代码分析 c e

I rn  e c u t 的核心, s ne o m n a r的核心。 s ne e  i m I t c是C m ui t I na co I t c 组合进了I r t e na c u i e  m n 

所 需 的几乎所有重 要资源 ,I t c n a e负责对这些 资源 进 行创 建 、销 毁 。对 sn

Cm uitI o m n ar的方法调用大多都转发给 I tc, I t c 再转发给相应的资 co na e 而 n a e sn sn
源。 各个资源之间通常需要通过 I t 二来进行相互协作完成任务, na sn 所以它们之中

很多都含有对 It c 的引用, na na 。 sn It二是这些分散的资源之间的 sn 桥梁。同一进程
中可实例化多个 C m ui t I  o m nar co o

32通信模型 .
I 的通信子系统主要负责对网络连接的管理,涉及范围包括端点、引用、连 c e
接及它们的相互关系。 32 1端点 . . 

利用端点      信息可 一台 机, 信息 括协 类型、 寻址 主 端点 包 议 寻址信息 Edo t 等。npi n 类是端点 信息的 抽象, 有端点 是所 类的父 Ed i 类跟其它端点 关 类。np n ot 类的 系如图
3 所示。 - 3

图3                              - 3端点模型

I 核心上实 两      现了 个端点 T Edot dE即o t由 C 是面向 c e 类:c n i 和Upn i。 于T P p pn n 连接的,因此进一步将连接发起者抽象为 T Cneo, c o cr 将连接接收者抽象为 p nt Tpc p r 而一旦 c c t, A eo 连接建立后的 送 接收 发 / 信息的 则专门由 Tpr s ir 工作 c a cv T n ee
负责,它是比特数据收发员的抽象, 这样一来,职责分明, 接口细化粒度适中,

对 层 全 藏 S K 编 接 的 用 提 了 象 次9l 由 没 上 完 隐 了O E 程 口 使 , 高 抽 层 [ o  于 CT r U ] d ( p p
有连 建 接的 立过程,由Upnpi 可 接 d d n 直 创建Upr s i r E ot d a cv a T n ee

I 中间件关键 技术 的研究与实现 c e

Ed i      Edo tcr 创建,Edotcr a g np n o t由 npiF t n ao y npiF ty n e n ao M a r聚合了各种
Edo t cr.  据协议 npiF ty '可根 nao i ; 类型选择相应的Edo t c r创建Edo t npiF t y nao npi . n

322 引用 ..

如果要定位远程主      机上的一 Srn 仅有 Edot 个 ea, vt npi 是不够的,还要有此 n
Sr n的 e a 标识: d t 十a t 一 Rfe e vt I nt f e 个 e r c代表了 个 S vn的引 ei y c。 en 对一 e at 用, r 它 就包含这些信息。一个 Rfe e e r c 包含一个 I nt 如果有的话还要包含一个 en dt ei y(

fe, at 但可包含多个Edot这意味着, 选择任意一个满足要求的Edot c) npi, n 可以 npi n
定位服 务器 。 323连接 ..

Cne i      与 Edo t 对应, on tn npi 一一 co n 它使用 和这 Edo t 个 npi 对应的Ta cvr n rsi n ee
发送请 求、 回复等信息,C netn onco 实现了 E etad r 口, 以它可 以向线程 i vn nl 接 H e 所 池注 册从而响应被动事件 。

Cnei      一旦被成功构造, on tn co 对于T P C 意味着 连接已 经建立, 对于 U P D 意味
着会 话套接字创建完成 。此 后便可发送请求回复。 32 4相关对象 间的关系 .. 对于端点,引用 和连 接的具 体关系 ,如下图所示 。

第不章 I c e中间件核心代码 分析

如图3 所示,一个 Rfec聚合了      - 4 er e en 多个Edo t Rfe e npi,  e n 有一个 M d n er c oe 属性,它是一个枚举类型,用以表示通信方式是单向的、 双向的、数据报的、 批 单向还是批 数据报的( 指一次发若干请求)其中 , 单项双向 批单向 均是基 T P 于 C 的。 调用 Rfe 。的 g Cnei erc en e on tn方法若无异常就返回一个建好的 Cnei . t co o co n tn

gCnei 方法中( e o co t n tn 暂时不考虑回调的 情况) 先要对Rfec的多个Edot er e en npi n
进行过滤, 就是将 Edo t拷贝进副本, npis n 根据 M d 的 oe 值在副本中 滤除与 M d oe 不匹配的 Ed i ( 若 Mo 为 toa, np n 比如 ot d w wy 则删除 e 所有的U pnpis  滤 d do t , E n) 过 后 将余下的Edo t随机的 npis n 排列一 ( 下 令每个Edo t 位置都具有随机性, npi 的 n 这 样 各个 E即o t n i 才具有 n 相等的 机会被挑选出 立 Cnei 将其作为传入参 来建 on tn, co 数调用 Ot i Cne i Fc r u o gonco ao gn tn ty的 c a rt e。方法, ca rt ee方法将根据传来的

Edot 回与 其 中一 个 Ed i npis返 n npn o t对应 的激活 的 Cnetn  on i o co Oti Cnei F t 的 ca uo gon tnao gn co cr y rt ee方法并非每次被调用都新创建一个
Cnei ,因为新建一个 Cne i 是一项较耗时的任务,同时客户端的 on tn co onco tn
C net n 了不仅耗废客户端的资源, onco 多 i 更是对服务器带来很大负担 ( 意客户可 恶

借此发动拒绝服务攻击) 所以 , 要最大程度的重 用客户端的Cnetn o co 资源, n i 确保

一 npi只对应一个Cnei 。 是先根据Ed is 第一个Edot 个Edot n onco 方法 tn npn 中的 ot npi n
从一。 ei s( n co 一个 M p 存所有已 n tn a,保 存在的 Cnei )中寻找有无可用的 on tn co Cne i , o co 若找到就返回它, n tn 若找不到再根 npi 在 pni 一个 M p 据E d n 一ed g( ot n a, 保 存所有正在创建 Cne i 的 Edot 中找, o co n tn中 np n i) 若找到了则说明正 有其 它线
程也在建相 同的 C n e i , onco 此时要等待直到别的线程建完 C net n tn onco,等待完 毕 i

后 再在- n cos 一遍, c ntn中找 o ei 还找不到的话 就准备新建一 新建前先在 ni 个, 』edg n 中 加入相应的Edot 然后开始 npn i, 新建Cnei,建 ontn 完后 nt Al一下并把 c o of l i o y Cnei 加入- neis 把Cnei 激活, o co n tn c nco 中, on tn o tn co 最后返回 方法结束; 它, 若
新 Cnei 失败, 建 onco tn 则取下一个 Ed i 重复 n o t 尝试直至取完。 pn 由此      可以 看出,I 中 c 通过 Rfec获得 Cnei 的方式为负*胶夂腿 e er 。 en onco tn

错供 基 [ 多 服 器 提 相 的 务 客随 的接 中 台求 提 了 础1 台 务 可 供 同 服 , 户 机 连 其 一 请 2 。
服务,假如有的服务器 出了故障无法 接受连接 ,亦可尝试 同其它 的服务器 建立连 接。

33线程模型 .
C R A长期 以来一直受到线程模型太弱的困扰。      OB 在规范 中没有提供开发者可

以 依靠的 线程模型。 开发者必须在单线 程操作和供应商 专有的模型之间进行选择。
后者在 rn  e u t 可能不提供线程 。如果 O B使用 了线程,C R A没有对线程模 i m R OB

型加以 规定。 O B 缺乏可 C R A还 移植的 线程 A I所以开 P , 发者难以 编写可移植的代

I 中间件关键技术的 c e 研究与实现
码。

I 天生就是多线程的。在服务器端,一个线程池使用领导者一跟随者模式来      c e 分派到来的操作调用。 线程池的尺寸是可以 配置的; 把线程池尺寸设成 1 就可以 ,

进行单线程服务器操作。服务器还可以 创建额外的线程池,尺寸不限,这使得服 务器能够把到来的操作调用分给多个线程池, 从而防止线程饥饿的问题。 I 2 . 在 c .0 e1 版本以 后,与线程池模型对应,开始支持每连接一线程模型,每连接线程为对客 户请求进行优先级排队服务提供了很好的支持。举例说,更高优先级客户可以与 具有更高优先级的线程绑定, 这样,来自 较高优先级的客户请求将优先获得服务。 对 I 而言, c e 线程池模型是默认的, 如果要采用每连接一线程模型, 需要在r t e ui n  m 环境的相应配置文件里做修改即可。
331 raPo 与事件处理 .. T edol h

Tr dol      类是 IE事件处理的 ha o eP C 核心, h aPo关系到服务器对大量客户 Tr dol e 并发访问的反应能力和抗负荷能力。 I      c 。核心代码所使用 的 Tr dol类公有继承 自 I UiSad 和 h aPo e c t: r e l he :
I Ui: no I Ui: t > c t: ir c t: e ,它包含一个私有嵌套类 E etad rhed e l Mo t < e l Mu x vn nlT r , H e a Eetad rh a 继承自I Ui: r d vn nlT r d H e e c t:h a,是线程类,它是 T r dol e l e T h aPo 的友员, e 并且含有对 Tr dol b aPo 的引用。 e

Eeta e     l 是事件处理者, 监听线程收到请求、 vn n r H d 当 读取全部字节后不用管具
体做什么工作,通知E etad ; vn nl 处理即可。 H e Eetad :      l 类是抽象类,定义了一些供线程池回调的抽象方法,Cnetn vn n e H onco i

和I o i CneiFc r继承并 现了 n mn on tnao c g c o ty 实 它们。
可以认为 vn nl 相当于观察者模式中的 O s vr     E etad r H e be e接口,Tr dol r h aPo 相 e 当于 O s vb be al ,这 种方式降低 了 T r dol对上 层 的 〔 netn  r e类 h aPo e ` nco . o i

IoiCnei F ty 依 所 n mn on tnao 的 赖( 谓上层下 c g co cr 层是按 层次 抽象 和对操作系统的 依
赖程度划分) 如果以 Cne i . o i Cnei Fc r , 后 onco I mn on tnao tn n c g co ty发生一些改动将
不至于对下层的 T r d o l he P o 产生很大影响。 a

332领导者一跟随者模型 ..
领导者一      跟随者模型是典型的线程池模型所使用的模式。每次允许一个线程 l d 等待在事件源集合上。同时其他线程fl e 排队 ee ar oo r 等候成为领导者的机会。 lw Lae检测到事件后,马上转入 fl e并提升一个 fl e为l dr e r d oo r lw oo : e e,然后直接 lw a

处 事 这 处 pcs角 , 理 成 成 fo r  下 3所 , 理 件 时 于 ree 色 处 完 后 为ow[ 如 图 - 示 os r l e2 l 2 1 。 5

第二章 l 中间件核心代码分析 e e

IWi1 . . . . 一 9 a (i 1 g  } ( iY_ I  }  t ,  n
条宁 S 介的 OCK 'S 入 GP  , l

图3 ( 一条线程被提出 -a 5) 监听, 系统的S C E 输入缓存队列中尚无内 O KT 容

*

JWi'i . . .一 . r到 h ag   f iI a l r 仁 t1 n- } -   .
系线的 S C E 介 入踌存队y O K T俞 l j

厂 ! 一

下 上 一

Pme ro ot :

Ep  v0  -  e 斌 ; n ! t i , o f - i f l i + M 1
」 一 一
已汀册 的 S K OC ET

一 一 -

_    气  一 f  de s

Mp u
-Lctalrt va l l ' Pm e i f



图3 间 系统的S C E 输入缓存队列中出 - 5 O KT 现一条信息

3 0

I 中间件关键技术的 c e 研究与实现


1有Wai 的线程 7 1 in tg

. …
1mc 'n }l n
处理 {9 } 以 1 . 的夕 - 干 f
F- A

污统的 S C E 输 入级 介队 N O K" I I

一 且 工工 「 _ _ 」 日上
下 | 走

一 几 _

汽子 , t
E E g p的线利 V Wt o

Fa de ln lr

f st d  e

已 注册的S C E O KT

图 3 ( 监听线程取出 -c 5) 第一条信息转为 事件处理, 另一条线程被提出 监听

必…


考 一 川;

厂 | l l j l l ‘, | !

f 一 S (  I 统的 O K 输入缓子 从列 F 川

口咔

图3 ( 系统的S C E 输入缓存队列中出 -d 5) O KT 现另一条信息
所子 Wai 的线* I in tg , ,

I  '  1  f d I 7 - S s e O t C K I
..一 )了 ’
、广

藻l' S"t Cnr kp Kl 1a 3n ld }L      F  } n t - I c d

处即    七H


、回tW AI 、 J L
、 、 ,

P o- 和t rn o
. 刃 .



}I J 卜f hP F i线不 + N‘ 勺
F ai   n v
Ha dl r n e



e k n k t S 输y ' . !
//           
r st d  e
已注朋的 S C E O KT

别a p 5 C E 寿F 1 山 1打 O K T - 如n 1 户

第三章 I 中间件核心代码分析 c e

图 3 ( 监听 -e 5 ) 线程取出 第二条信息 事 理, 条线 提出 转为 件处 另一 程被 监听, 第一条线 件 程事

处理完毕继续w i                               a t

在缺省情况下,k 客户端使用的是一个含有两个线程的线程池。一个线程发      。 送外出的调用,另一个侦听到来的请求,这样就可以进行嵌套的回调,而不会发 生 死锁。 回调的嵌套深度限 于线程池的尺寸, 开发者可以 u t e 在r i 对该尺寸进行 n  m
配置。

333线程安全性 ..

I r t      自 c u i e  二 身是线程安全的,所以开发者无需针对并发访问 n  对任何与 I c e 有关的结构进行保护。 开发者必须明确实现的临界区涉及的是与应用有关的数据。 I 提供了一个可移植的线程和信号处理 A I c e P,开发者可以 藉此编写出可跨*台移
植的代码。

34对象适配器模型 .
当服务器端收到请求信息时,要将请求分派给合适的 Sr n,对象适配器就      e at v

负责由 请求信息至请求的对象之间的 适配工作。 对象适配子系统主要是应用于 I c e 的 服务器端。

与I 客     端的OtiCn c nao 创建 户 去 连 对 c 户 e uogo eiF ty 客 端 往的 接相 应, gn n t cr o
I o i Cnei Fc r创建服务 n mn onco ao c g tn ty 器端到来的 连接。

一 n mn o co ao     i Cnei Fcr和一 n o t 应, 个Io g n tn ty 个Ed i 对 这个Edot 务 c pn npi 是服 n 器端绑定到的 Edo t 在 I o i Cn co ao npi。 n mn on tn cr n c g ei F ty构造时, 如果它对应的 E即 i 是面向 n ot n 连接的, 就创建Ac t 并置 c pr 其为监 状态; eo 听 如果不是 连接 面向
的,就创建 Tas i r C netn r c v 和 onco,将 C ne i 加入 C netn n ee i onco tn onco 链表中。 i

Io i C n tnao      neiFcr同Cnei 一 现了EeHn e接口 所以 n mn o c c g o ty on tn 样实 co v ta l n dr ,
它可以向 线程池注册从而响应被动事件 ( 比如有连接请求到达) 注册后, 。 每当有

新的 请求到 Io i Cnei F ty 连接 达,n mn o co ao 就创建一 应的Cnei , c g n tn cr 个相 on tn 加 co
入 C netn onco 链表中,然后验证连接、激活连接。 i

I 中间件关键技术的研究与实现 c e

Oj t atl  b c dp rQ eA e

S r n aae e at n g r v M

UF D' 的时候才有Ac咖 r e

当 应 E pn 基 对 的 n ot 子 di 是

A cp r cet o I o i C netn at n mn oncoF c r c g i o y

1 Edot 1 npi n
E e t n lr v nHa de

Co n cin  net o t_ __ _

图3                            - 6对象适配子系统U ML图

Ojtd e 由Oj t ae ao     tI bc d tFcr创建, 个Ojt ae 都有一 bc a r eA p eA pr ty 每 bc d tI eA pr 个名 字, bc d tFcr维护着一个由 Ojt ae ao eA pr t y 名字到Ojtd tI a. bc ae 的mp eA pr 。 eA ae 组     tI 合进了 个Io i Cnei Fcr Oj t ae 在构 坷c d r t p 多 n mn on tnao b c d tI c g co ty  eA pr
造时,从属性对象中获取和它对应的多个端点信息,一一为之建立对应的

Ioi CneiFcr Ojtd tI 根据 信息 n mn on tnao ; eAae 还会 配N 创建线 c g c o ty bc pr 程池 ( 也可
能在此处不会创建,取决于配置信息) 。

所以,当服务器端创建了 。 eA a e      坷c d tI时就开始了监听工作 ( t pr 一个 O eAa e 可能 坷c d tI 会对应多 t pr 个监听端口 取决 , 于配置 信息) 但 并不响 , 此时 应请
求。

Ojtd tI cve 法中     e 在ait方 令它所 bc a r eA p ta 有的I oiCnei F ty n mn on tnao 在线 c g c cr o 程池中 注册 ( 非面向 对于 连接的Io i Cnei F t 而言, n mn on tnao c g c cr o y 什么也不 , 做) 每个Ioi CneiFcr再令 n mn on tnao c g co ty 其所有的Cnei 在线 o c n 程池中 nt o 注册 ( 对于 面向 接的I o i Cnei F t 而言, 它 有Cnei ) ai t 连 n mn on tnao c g co cr y 此时 还没 on t . v e cn ca o t
方法完成后,服务器端就可以处理所有到来的请求了。

为了 将请求 e a 联      和Sr n关 起来,bc d tI 合 个S v ta g 能 vt Oj t ae 组 进一 e a M n e eA pr rn a r

负 维 d t 到S v t a 这 a之中 实 嵌 着另 个mp 责 护Int ea 的mp 个mp 其 又 套 外一 a用 ei y rn ,
以实现服务对象的多接 口制,如下图 3 所示。 -7

第三章 I 中间件核心代码分析 c e

I ntl d ty ei

涤偿 { 黔
F c t  ae 1 F c t  ae n S r a t  e n 1 v
一               

S ra t  e nn v

Iety  dni n t

涤摆豁
F c t  a l e F c t  a n e S r a t  ev n 1 S r a t  ev n n


图3 svn对象被查找的映射示意图                        - e at 7  r

通过 f e 对象可以      , at cs 提供多个不相关的接口,同时又跨越这些接口、 保持单 一的对象标识。这提供了极大的灵活性,特别是在这样的情况下:应用在发生演
化,但又需要与更老的、己经部署的客户保持兼容。

所有由Oj td tI     eA ae 派生的Cnei 都含 b c pr o co n tn 有对Ojtd tI 用, bc a e 的引 所 eA pr
以,对于一个 C ne i 而言,它清楚的知道如何查找客户端请求的 Srat onco tn evno 这样设计对象适配器,使得服务器端框架简单、轻巧,对象适配器之间不存      在层次的关系,对象适配器生命周期的管理也就随即变得简单;请求到来后不用 查找定位对象适配器,因为 Cne i onco tn直接和派生它的对象适配器关联,创建对
象代理时也不用提供对象适配器的记,对于一般应用这也许已经足够了。

35调用模型和分派模型 。
C R A支持同步、 OB 异步,以 及单向调用模式。 c 也提供了 I 。 这些调用模式, 并且还增加了数据报和成批调用的能力。
35 I调用类型 ..

I 支持同步调用、异步调用、单向调用、数据报调用和批调用,但特定的传 c e 输机制只支持特定的调用类型。
3 .1同步调用 .1 5.

对于同步调用, O B      C R A提供了“ 最多一次” 语义, 需要进行非常保守的错误 恢复。特别地,如果在调用失败时,对请求的答复还没有返回 ( 例如连接故障) , 客户端rn e u t 没有选择,只能把故障传播给应用代码 ( n e i m r t 不能再次发送请 ui m 求,因为哪可能会违反 “ 最多一次”语义) 。

I 中间件关键技术的研究与实现 c e

I      c e也提供了 “ 最多一次”语义,但对 C R A 的做法进行了改进,增加了 OB

nnutg d ptt om ti 和im o n操作限 符。 种操 会改 状态, 种操作只 a n e e 定 前一 作不 变 后一
会把状态设成确定的值 ( 与先前的状态无关) u t e ,rn  可以在发生网络故障的情 i m

况下重新发送该值。这样,I r t e c u i 就可以从有些网络故障中透明地恢复,而 e  m n  在 C R A中,同样的故障都会造成严重的错误。 OB
3 .2异步调用 .1 5.

I 异步调用模型与 C R A异步方法调用 ( MI      c e OB A )回调模型类似:客户提供 回调对象,由服务器用于递送调用的结果。 c 取消了轮询模型,因为大部分A I e MI 应用使用的都是回调模型。轮询模型相对于回调模型增加的功能很少,再增加一

个单独的轮询A I P 只会增加生成的 代码的尺寸和复杂度。
3 .3单向调用 .1 5.

和 C R A一样,对于任何没有返回值、 u 参数或异常的操作,I      OB ot c e能让客 户发出单向调用。 u t e r i 像分派异步操作一样分派单向调用; n  m 一旦客户端把相应

的请求写到本地传输层,控制线程就会返回。只有灾难性的事件,比如连接丢失, 才造成单向调用丢失,在这个意义上,单向调用是可靠的。 特别地,单向调用会 像双向调用一样被流控制, 所以 客户发送的请求不可能超出 服务器的处理能力。
3 .4数据报调用 .1 5. 关于数据报及其语义, O B      C R A没有加以说明 ( O B提供了U P 有些 R D 传输机

制作为私有特性, 但其语义和A I是私有的, P s 显然不能提供跨供应商的互操作性) 。 I 包含了内      建的 U P支持, c e D 允许客户使用数据报调用. 这种调用只适用于 没有返回值的操作,在这个意义上,它和单向调用是类似的。在传输层, u t e r i n  m 会把这种调用当作普通的 U P数据发送,而 U P数据报不可靠,也有尺寸上的 D D 限制 ( e I 不允诺提供数据报调用的 “ c 最多一次” 语义) ,因为U P D 包可能会重复, 使得提供这样的保证是不现实的) 。
数据报调用可用在需要通过局域网分发大量事件的情况下。      在这样的情况下,

U P可以带来相当的性能提高,并 D 使应用消耗的操作系统资源更少, 可伸缩性也
比面向连接的传输机制好得多。

第二章 I 中间件核心代码分析 c e

3 .5批调用 .1 5.

在客户调用和请求之间, O B      C R A具有内建的一一对应性。 每个客户调用都会 在线路上导致一次单独的请求一一答复交互。对于细粒度的接口,这种一对一的
对应性可能会显著地降低性能。例如,设置某个对象的 2 个属性需要在网络上进 0

行2 次不同的、且又是同步的往返。 0 I 允许你成批发出单向和数据报调用。c r t e      c e I u i 会把批调用放在客户端的 e  m n  缓冲区中, 而不是立刻发送它们。 缓冲区会累积调用, 直到客户应用明确调用 fs lh u
操作,把已经累积的各个调用放在一条消息里,在网络上进行发送。这样做不仅

效率更高, 而且还能更好地使接口 设计免于收到同 P 局限的 步R C的 影响。
如果批调用中的某个调用引发了异常,I 不会把该错误通知给客户,所以批      c e 调用中的某个调用的失败不会影响批调用中的其它调用。

352分派类型 .. 和 C R A一样,I 为服务器端提供了同步调用分派模式。      OB c e 客户调用会致使 服务器端的应用代码中的函数被调用;一旦服务器端函数返回,I r t e c u i 整编 e  m n 
好返回值,发给客户,客户的调用才完成。

同步分派在有些情况下不适用。例如,设想一个阻塞的 ; d      e 操作,它会把数 a

据返回 给客户 ( 这样的 操作在 C R A中 O B 很常见, 例如, v t Ee 服务和N tci n ofao i tn i
服务都提供了这样的操作, 用于把事件递送给客户) 对于每一个阻塞在 ; d 。 e 调用 a

中、等待用户数据返回的客户,服务器都会使用一个执行线程,因为不完成客户 端操作,服务器端操作也无法完成。这样的阻塞操作的可伸缩性很差,因为每个 线程都会消耗很多资源。 为了处理这个问      题,I 提供了 c e 异步调用分派模式。和同步分派一样, 对于每 一个到来的操作调用,I rn  e c u t 都会调用应用定义的函数。但是,该函数可以 e  i m 在完成客户的调用之前就完成,从而释放它的控制线程。为了完成操作,服务器 随后会调用I r t 。 c u i 中的一个回调函 ( e  m n  数 服务器可以 从与 “ 原来接收调用的线 程” 不同的 线程中调用回调函数) 当 。 服务器发出 回调时,cr t e I u i 会收到操作 e  m n  的结果,并对其进行整编,发会给客户。 对客户而言,同步分派和异步分派是无法区分的,两种分派模式在线路上发      送的信息是一样的,只不过异步方法分派允许服务器用少量线程处理大量并发操
作,从而获得可伸缩性比同步分派更好的设计。
353调用与分派的 UL图 .. M

3 6

I 中间件关键技术的研究与实现 c e

图3 (,-b     8 ) -a 3 (是客户端采用t wy 进行 8) w a方式 远程调 o 用的U L 图3 ( M 图, -a 8)
描绘了 调用的 *氩糠郑 发起调用, 客户线程阻塞等待返回 图3 ( 描绘了下 值。 -b 8)
半部分:回复到达,客户线程解除阻塞处理返回值。这是一种同步调用,同步的

关键 Ot i 在 u o g上, gn 显然, 想异 如果 步调用则需要替换 Ot i , u o g 替换品 gn 便是
O t i A yc u o g sna gn

图3 (是服务器端分派请求的U L      -c 8) M 图,由图中 看出, 可以 请求分派一直占 用线程池线程到分派完成回复发送, 然后线程池线程才可入池被重新使用。这是 一 步分派,同 种同 步的关 键在 Io i n mn c g上, 然, 显 如果想异步分派则需要替换 I o i ,替代者便是I o i Ay > n mn c g n mn s c c g n 这样便可以      看出专门 抽象出 Ot i , o i 这两个类所带来的好处:改 u o g I mn gn n c g
变调用方式和分派方式可以在对整个框架影响很小的情况下进行。

远程方祛

图3 ( 客户端发起调用过程 C  a模式远程调用) -a 8) to y ww

第三章 I 中间件核心代码分析 c e

3 7

T a s ev r rn c i e

口 on mmo

返日返回 值

图3 ( 客户端收到服务器响 -b 8) 应的处理过程 ( DH模式远程调用) I Wy W

3 8

I 中间件关键技术的研究与实现 c e

S  a -

图3 ( 服务器端处理客户请求过程 ( o a模式远程调用) -c 8) t wy w

36桩和骨架模型 .
对中间件而言,当接口定义编译时,为客户端所生成的是桩,为服务器端生     

成的是骨架, 桩和骨架都是把接口的操作定义映射到I 核心模块调用的一些辅助 c e
类。

361  客户端桩 .  Ie .  c

I 中的对象代理对客户而言是透明的, c e 如果客户掌握了 足够的 信息 ( et. I ny d i Edo t 便可以 npi) n 创建出 一个对象代理, 进而请求服务。 l P x: eOj t c r yI : b c是所有客户桩的父 e o : ;  c e 类,它和Rfe e e r c 一比一关联。 个 en

第三章 I 中间件核心代码分析 c e

IP x: eOj t c r yI :b c 组合进一个 IDl aA eOj t I Dl a ; eOj t eo : : e c c eg e c:b c c eg eI :b c e e t : e ,  e t: :  e c e 是抽 象的, 有两个实 它 现类: eege: eOjt c ege : eOjt IDlaD: :bc和IDl aM: :bc c et I : e c e e t I : e, c
前者可称作直接代理,只用于进程内调用;后者是真正的远程代理。 直接代理      和远 程 代 理 均 要使用 Rfec ,直 接 代 理还可 能会 使 用 er e en

Oj td t, b c a e 而远程代理则可能 eA p r 会使用Cnei . on tn co

图3                                - 9客户桩的U ML图

IP xA :bc的     eOjt 所有远 法的 用 转发 c ege c: jt c r y c: e e o 程方 调 均 给IDlaAeO e, e e t :bc IP x: eOjt 一 e ege方 得 个合适的IDla: eOjt c r yI:bc用 -t lao 法获 一 eo : : e c g D et c egeI:bc e e t: : e c
( 直接代理或远程代理) 然后在此代理上执行调用。如果是直接代理,它便利用 ,

Oj td t 寻找Sr n 然后执行进程内 bc ae eA p r ea , vt 调用;如果是远程代理, 它便编组参
数,发送请求,解组返回值并返回。

I 并未      进程内 c e 规定 调用时一 要 用 代 并且IP x: eO e 通 定 使 直接 理, c r yI : 坷c eo : : t c 过 和它关 判断 联的Rfe e o 类型 er c 的bo en ] 属性cla npmzi 来确定是否 oo t Ot itn lci i a o o
使用直接代理。 但进程内调用时使用直接代理显然会得到性能上的提升,并且默 认情况下是可以使用直接代理的。

客      c r yI :bc 客户 包 定 远程方 ( 户桩继 承自IP x: e jt 桩 含自 义的 e o : : e, cO 法 和对应的 服务器骨架匹配) ,客户桩覆写了父类的虚函数_caDlaM、虚函数 rt ege ee e t 一“ a Dl aD 覆写后的这两个方法实际 eeegt , t ee 创建出的是I Dl aM :  b c c egt ; eOj t e e e I: e c :  的子类和 IDI aD:eOj t c eg e: : b c 的子类, 个子类将添加进对自 e et I : e c 这两 定义的 远程

I 中间件关键技术的研究与实现 c e

方法的处理。

客户进行远程调用之前通常做如下工作:用通信器根据写死的串或配置文件     

创建一个 IP x: eOj t c r yI : bc 实例,以 eo : : e c 这个实例为传入参数在客户桩句柄 (r y a l P xHn e的实例) o d 上调用静态方法 c c da 或静态方法 uCe eCs h k Cs ee t n h kda c t
从而返回一个类型合适的客户桩实例。最后即可在此客户桩实例上执行调用。

ce eCs 方法的目      t h kda c 的在于,通过执行远程调用 i i c s e  A方法同服务器端
Sr n 沟通,判断要向下造型成的目 e at v 标客户桩同要请求的 Srat e n 的骨架是否匹 v 配,不匹配则抛出异常。由于含有这样一个判断,cekd at hceC s方法被认为是安全 的向 下造型。nhceCs不含有这样的判断, uC e d a k t 不论实际匹配与否直接向下造型, 因此被认为是不安全的向下造型。

对于oea,  g m式的     y dtr n w a a a 通信,由 通 单向 不要 器的回 于 信是 的, 服务 复,
所以只能使用uC e eCs n hc d a o k t  对客户端而言,第一次连接服务器发生在调用 ce eCs      hc d a k t时 ( 使用 uC e eCs 的话则第一次连接服务器发生在应用代码中第一次远程方法调用 n hc d a k t
时) 。

362 e .  I 服务器端骨架 . c 服务器端骨架与客户端存根对应,客户端存根用于编组参数、向下调用、解      组返回值,服务器端骨架用于解组参数、向上调用、 编组返回值,由于用 I 的编 c e 码方式编码的数据不是自 描述的 ( 也因而紧凑、 传输效率高) 为了正确解码用 I , c e 的编码方式编码的字节流, 接收方必须提前知道它所期望的类型, 所以收方和发 方要有一个用于交换的数据类型的约定, sc 生成的桩和骨架满足这一约定。 利用 le i

若运行时发出      请求的桩和处理请求的骨架不匹 接收方无法防止对接收数 配,
据进行错误的解释。客户端的cekd a 调用可在某种程度上对此进行防范。 hceC s t

AeOjt 所有服务      是 c: e :bc 器端骨 架类的 类, 含有一 父 它 系列最基 远程方法 本的 的实现,如 v u iw  vtl  p g等等,它含有两个静态属性: i a c i , u i-i t r l  s i a c n eA r e e

st:d t g    tc t :i jd]一 l包 :。 架 提 tc :r 一 l和stc s: :r a : :i a i s sn l a o :d tg s, a] 含 I 骨 类 t 口 i n s sn t [ l [ c
供的 可供远程 所有 调用的 方法的 称; js包 骨架 名 一 d] 含 类继承 [ 树上所 有类的 类名。
前者用于请求分派, 后者可用于类型查询 (hceCs方法正是以此为基础) 生 cekd a t ,

成的骨架都将覆写这两个属性。

请     运行时 求分派 是 行为, 无法完 静 定实 所以: : e 含有一 全由 态绑 现, : e恻 c I: t c 个虚拟 成员函 一dpc, 骨架类都 覆写 个方 在这个方法中 数 iah 所有 st 要 这 法, 经过一
系列虚虚实实 ( vt l 指 i a的和非 v ul r u i a的)的调用,结合静态绑定的内 t r 容,最终
调用到请求的方法。

第三章 I 中间件核心代码分析 c e

Srat      e n 实现类要继承 自 v 骨架类,并要实现自定义的远程方法 ( 这些远程方法

在骨架类中以纯虚函数的形式存在) ,这样就可以只关注 自 定义远程方法的实现,

背后的 工作由自 成的 许多 动生 骨架类 其 及 父类: eOj t 成。 : :b c来完 I: e c

37插件模型 . 
插件是 I 为了扩展 I 通信器特性所专门使用的机制。 c e C 。 371插件原理 .. 

插件是一段可执行程序,可以单独编译和测试,但不能单独执行,它由主程     

序根据功能需要 “ 既插既用”的调用。插件与主程序相对独立,只要保证一致的 接口,双方内部的改动互不影响。另外,一个系统中的多个插件之间相互独立。 动态链接库是最常见的插件形式之一,      其中封装了一些可以被其它应用程序 共享的例程和资源。 no s Wi w 下典型的动态链接库为以 d 为后缀的文件,L u d l l ix n 下为以s 为后缀的文件。当要调用动态链接库中的方法时,可根据链接产生的定 o 位信息,方便地找到相应的方法。
372插件的 工e .. c 接口定义

I 定义了 C 。 一个Sc接口I :l i来代 le i c:u n 表一般的插件。 eP g
mo ue  d l Ie c



l o c a l


Pu i l n g

vidsoo o et y ; d  r

l aiea P g Maa r o l rc l i ng c n f e  n t u e P g gtuisi nm ) l i e l n t g  e u n  g (r a ; P n viadl isi nm ,  ip) o dPu n tn a eP g i d  g (rg  l n ; u vidsoo o er ; d t y

图3 0 :ui插件接口                          - I :l n 1 c Pg e 定义

对于需要扩展的功能模块来说,      需要定义一个 Sc 接口, le i 继承自I :l i c:u n eP g
接口,例如, " cl rc P g et d I :l i , ' 在该接口内,还可 l aie ae  i x ns :  n I o n f l n e c P g { % t u e u

I 中间件关键技术的研究与实现 c e

以定义一些该插件功能模块提供给核心模块调用的专有操作。在插件工程里,由 于对这些接口定义通过 I A I c P 进行了翻译,只需要实现相应的操作函数,就可以 e  提供相应的操作给 I 核心调用。 c e 373插件的调用过程 .. 3 .1应用程序侧的插件调用 .3 7. I 应用程序调用插件分四步进行,以I S L为例, C 。 cS e

() 1 首先获取插件管理器的引 用, I :l i aae t l i g=  m n a r gtui" eS " c :u n ngr r  n r  m uit- e l n I SL) eP g M P pg M c u o co > P g (c ; () 接着,向 2紧 插件管 器 理 请求 ISL插件, e l i 的 cS e g P g 参数就 插件 tu n 是 标
识符

u n - P g (c ; I :l i t l i二 l i r gt ui " eS " c :u n r u n p g Mg >e l n I S L) eP g P p g ( )最后,将得到的对象向下转换到相应的插件对象,    3

I SL:ui t s l i二c S :l i t: nmca(ui : c S :l n r  u n I SL:u n rd a i sp g ) e P g P sP g l e P g P :y C tl n
( )得到对象引用之后,就可以直接通过该引用去调用相应插件的操作了。 4

3 .2插件侧的插件入口点函数实现 .3 7. 插件的入口点函数将在 I      “配置文件中显式设置, 函数参数包括通信器对象和 插件标识符, 在入口点中主要提供插件对象的 初始化工作,并提供插件模块到I c e 核心模块的关联。

插件入口      点函数的工作分三步来执行:

() 过通     信器对 1通 象做参数调 cnrl e ro lui a d (  用Ilea:to cP gFc e 来获 et : P to l n a ) n g

得P toliad对 引 ro lun c e 象 用; ocPgFa
()      o cP g F a 对象引 2 通过P to l i a d ro lu n c e 用构造插件对象的实 在这一步 现, 插件 对象的 现类将 一 ro lui a d 的 用, 时 实 保留 份P to l n c 。 引 来随 通过该引 o cP g F a 用访问 通
信器中其它对象; ()      3 调用插件的初始化函数或相关环境配置函数,完成插件初始化。

38本章小结 .
本章首先介绍 I 模块结构和代码架构,      c e 然后在代码分析的基础上, 详细地刨 析了I 核心各模块间的工作原理, c e 为接下来所要介绍的两项互操作的技术实践打 下理论基础,并提供实践上的可能性。

第四章 I 传输层替换的实现方案 c e

第四章 I 传输层替换的实现方案 c e
41传输层替换的意义 . 
在中间件产生的早期,人们己经局限于使用 T P来做传输层协议,这一方面      C 是由于 I P网络所占 据牢不可破的统治地位,另一方面也是由于中间件最初的定位

有关,中间件最初的最大挑战就是如何统一多种软硬件*台差异,所以将它的重 点放在了传输层以上,也就是建立统一的网际互操作协议上。在这样的前提下, 无论是 GO IP协议,还是后来的 H P协议,以 O 及其它一些不同厂商团体对各自 C R A产品 OB 扩展出的 私有协议, 都是以 支持 T P协议为主的, C 并且这种支持都
是静态配置的,不适合扩展。

对 C R A中间件来说,不修改 O B的源码,开发者无法为GO      OB R IP增加新的

传输 制(bc a g e Gop xnb T n o F mwrRP 经拖 机 Ojt a m n r 的Etsl rs r  eo F 己 e M n e t  u e ie  pt r a a k 
已经提供了这些特性。 I 不仅支持 C      T P协议,还支持 U P协议,还支持安全的 S L c e D S 协议。I c e已

延 年 未 得 何 展2。 然 CRA O有 多 改 之 , c 多 , 取 任 进 1)显 , OB 的HP 许 可 进 处 而I 3 1 e

经大大地扩展了中间件传输机制的支持,但对于更多的底层传输方式,仍然存在 一定的互操作需求。比如说,在普适计算里,如果要做到无缝地实现支持不同通 信方式的信息设备间的交互,那么一定要有一个可互通互操作的中间层,而这一
层既要能符合中间件设计的基本要求,也要能够适应底层的不同传输机制的需要。

本文所介绍的实现方案,主要是在对 I      c e传输层协议相关源代码分析的基础 上,通过 I 己 c 有的插件机制,实现支持特定传输协议的插件。I 在运行时,可 e c e 以通过修改配置文件的方式,动态加载这些插件,无需修改 k 身的源代码。 e自

42替换技术 .
在介绍几个替换所借助的技术之前,先要确认一些替换所应遵循的原则。在

本文的实现中,综合考虑了一下几条原则:

. 替换不是非此即彼的概念, 而是应该 在尽可能不修改现有传输机制的基础 上 ,对新的传输机*辛榛畹睦┏洹L婊坏淖钪漳康模鞘够旌洗浠瞥晌
可能

. 对某些传输层协议,借助 sce的网络编程 A I okt P 也不能实现,所以,对非

sce 的A I okt P 访问,在 O B核心编码设计中必须有充分的考虑。 R . O B策略与传输机制的分离,必须贪穿于整个建模设计过程中。 R

I 中间件关键技术的研究与实现 c e

42 1 ..  串口端点对象设计

不同的传输机制有不同的特点,这些特殊的特点主要体现在端点对象的设计      上。串口通信的特点是数据位传送,传送按位顺序进行,最少只需一根传输线即 可完成,成本低但传送速度慢。所以,首先串口的端点对象应该设计为无连接的 协议,因为其本身就是被串口线一一对等连接起来的;其次,串口的通信实现跟 操作系统密切相关, 所以使用串口 进行数据通信的类应考虑跨*台性。此外,对 速度慢,应该在应用程序设计中有所考虑。

当 考虑成无连接的      端点 情况,当生成 Cm Edo t om npi 类之后, n 就不用考虑 Cm Ac t 和Cm Cn cr o m c p r o m on t, eo eo 直接设计 承自 r se 继 T nv 类的Cm T nv ; a ir o m r se a ir
在 Cm T nvr o m r se 类中, ai 调用了 第三方的 可跨*台的 操作串口 的类, 来支持具体 数据的 和发 所以Cm Ed i 的 计 类 第3 接收 送。 o m n o t 设 非常 似于 章第2 pn 节中的U P D
协议的端点设计。 4 22工厂模式 ..

为了 够有效地管      能 理不同 输协议的Ed i, 传 n ot p n 将采用工厂方 法模式, M 其U L
建模如下图所示,
- at s  :et <npiFc r t L f o : vc rEdo t tyr cr s : o y t d n a o P > 

) En {: o cco t  di nF.yyP ) o enppdtatrrr vi giEnoniatTPtt : d d 二d d (

I- -

1‘p‘.叼】 . 【.‘ . 凡 朋‘ 明, 了

. ,

_.

y },diur Co mEn pitatr uEptt m donFco d  n o noF y

+r t E do t c ao: pi ec n n

} 卜eo p t re E o a : i t nn d
E 中口 n 加

口 七 比s .

代rt :  o t we Ed i o  p n n

T p s pit eE d oe

1T . F


?}

}, 一, , ? { 。 , ‘ 一 ‘

图4                    - 1端点与端点工厂的U L图 〔 M 工厂方法模式)

如图4 所示, npiFcr和Ed i 都是 类型,      - 1 Ed n ao o t ty npn 抽象 ot 这种多 态性设计
将工厂类选择创建哪一个产品对象、如何创建这个对象的细节完全封装在具体工

厂 内 [。 果 上 的 计 要 入 的 输 协 支 , 么 系 中 类 部4 如 在 述 设 中 加 新 传 层 议 持 那 在 统 只 2 1

第四章 I 传输层替换的实现方案 c e

需要加入一个该协议的端点类以及它所对应的工厂类,没有必要在修改抽象层次

在Edo t 的 npi 以上 抽象工厂角 n 色或者其它具体工厂角色。
423 .. 插件机制
插件机制基于 3 节所提到的插件模型,      . 8 正是由于 I 提供了相应的插件模型, c e 才使得在不修改 k 源代码的情况下提供附加的传输层支持成为可能。 e 4 .1 C m .3 I o m插件实现原理 2.c e

在传输层替换过程中,利用工厂方法模式的特点,将新增加的端点类及该端      点对应的工厂类一并封装进动态链接库, 并提供统一的插件接口, 方便 O B核心 R

调用。 具体到串口 替换实 践中, 需要在插件工 设计并实现了 Cm Edo t 程中 om n i pn 和Cm Edo t cr两个 分别 承自Edo t o m npiF t n ao y 类, 继 n i 类和Ed iFcr类。 pn np n ao o t ty
4 .2插件调用 .3 2.

插件 的调 用 过程如 下 图 4 所示 ,时序 图反 映 的是 为 串 口设. 的 - 2 计

Cm Edo t cr对象 o m np n对象的 o m npiF t n ao y 和Cm Ed i ot 被调用过 程。


}f , i l。

- -- - - - 犷-- 丫 -- --一 - - - 一{- - -一

}、 , T            I 叼 , }
.                  l

- {一 } - - - 一 - - - 一
图4                                - 2插件调用时序图

如图      所示,当I 核心 行初始 程中, 始一 P to l i a d e c 进 化过 要初 个 ro lun c e o cP g F a 对象; 然后调用l dl i方法, o Pg a un 寻找需要载入的插件: 当找到配置文件中 要求载 入的 插件以 调 件实 产生 Cm Edotcr 对象, 后, 用插 现, o m npiF oy na t 并把它 端 加入
点工厂序列中,等到调用发生并需要使用串口机制时,根据需要由端点工厂对象

I 中间件关键技术的 c e 研究与实现

产生Cm Edo t 与发出 o m npi , n 请求或接收 请求的 相应连接对应起来, 完成相应协议
数据的传输。

43实现过程与实现结果 .
4. 3
1选择开发环境

使 用

作者所采用的I “版本是2 . 使用的底层I 线程模型为每连接一线程模型 .0 1, c e
C十 + 语言开发,开发环境为 V + b . C +. 0

4 32实现步骤 .

新建 l l 按照4 节所提内 . 2 容编写支持串口 通信的I C m c o m的相 e 首先 ,      d 工程,
关代码,其中单纯的串口读写访问使用了不依赖于硬件*台的第三方类。

编译d 工程, c o md。 l l 生成I Cm . 拷贝该d 到相应的系统路径下。 e l l l 然后 ,     
使用 c e 最后 ,      I 原有例程,只是修改配置文件,测试串口支持的插件。
43 3编辑配置文件 ..

在配置文件中共需要修改 4个部分,其中涉及到客户端和服务器端各有三个      部分。以 H l Wol例程为例 如下表所示 eo r l d
表 41 配置文件所需要修改的项 - 设置项

设置内容

客户端


服务器端 不设 设
设 设

代理

H l.oyhlxn eo r =eo or Px l m一1

端点 线程模型
插件配置

H l. do tc m 1 eo npis o - lE n = m p 
IeT ra P r o n c o = c .h d eC n et n 1 e i

不设 设 设

I .uil C MM I C M c a c P g .eO = eO M:e e e l nc c rt

对于代理和端点的 设置, o m表示的 C m 是新的 传输层协议,p  -1 代表所打开的 串口 o l 理, 使 是Cm , 为Cr ,同 如果 用的 o 2 则用一2 示。 a p 来表
线程模型目 前只能选择每连接一线程模型。 插件配置中实际上设置的插件d 的入口点函数,如果支持有多个不同插件,      l l
可以同时设置,互不干扰。

434实现结果验证 ..
在两台P      C机*蔚敉撸么 线直联,然后分别在 P A上运行 Sr r C机 ee v 程序, 一 另 台上运行 C et ln程序。 i 使用I 自 c 带的未经修改的H lW r 例程, e eo od l l 只

改 i 文件中的 配置 变tT 4  L 端点 信息, t - 1 0' 成“o m 1  运 将“p  0 0 改 c - " 先 行 c p  , 0 m p  ,

第四章 I 传输层替换的实现方案 c e

Sr r e e,再运行 Ci t v ln,运行结果正常。 e 插上网线,将配置文件改成原有的,即就是继续使用 , P协议来完成      r C H lWod eo r 例程的调用,运行结果正常。 l l

44本章小结 .
本文首先介绍 I 传输层替换的意义,      c e 然后确定传输层替换所要涉及的几个原 则,接着详细地阐述了如何通过新的建模方法和插件机制在实现传输层协议扩展 中的应用,最后对一些实现细节进行了描述。由于目前的研究还处于初始阶段, 在设计中如何针对不同传输协议的不同特性,同时兼顾到模型的通用性和插件机 制的灵活性,都有待下一步的工作去不断探索。

第五章 I 与C R A互通信的实现 c e OB

第五章 I 与 C R A互通信的实现 c e OB
51互通信的意义 .
虽然现有的大型系统中基本上都用到了中间件,      但是随着系统规模越来越大, 功能模块却越分越细,在一个大系统中,一些功能模块都由各 自的子系统来实现, 如果不同的子系统因为建设时期不同、设计初衷不一、或其它商务因素影响,分 别使用了不同的中间件技术,则子系统间的协同工作能力必将受到影响,进而影 响到整个系统的整体效能的发挥。 过去,这些子系统间的交互基本上都是以数据为中心,或以数据库为中心的。      这一方面是由 技术因素造成的,比如说对象级互操作技术不成熟,数据分发比接 口调用有更高的效率;另一方面也由于一些设计人员主观上认为,子系统间的互 操作性过强,会导致子系统间紧祸合,紧祸合就会导致各个子系统间的接口设计 实现复杂化,并且会给各个子系统的升级维护带来非常多的不便。 随着网格计算技术的提出,Ie e 网络由原来的访问资源的共享逐步向计算      n rt t n 资源的共享发展,在这样的技术思想变革的背景下,新的系统设计越来越强调业 务层面上的不同应用间的互操作性。原有的一些技术上的*徊欢瞎テ疲 用面向对象思想设计出的子系统,又可最大程度地减少接口改动对子系统间的影 响,在这些前提下,为了完成不同中间件技术搭建的子系统间的互操作,不同中

间 间互 信 有 需 【 件 的 通 就 了 求2 5 ]
I 作为一种新型对象级的分布式中间件,与其它中间件相比,在设计上,充      c e 分利用了其它各种中间件成功和失败的设计经验, 有很多先进的理念和独到之处, 但它已 彻底不是符合 C R A 规范的产品,为满足应用需要,仍需做出 OB 不断的努
力。

52互通信的实现技术 .
I 与 C R A的互通信,      B c e O 技术角度来说, 就是 I 核心与 O B的互通信, c e R 或

者说是 I 核心协议与 H P c e O 协议的兼容,由于 C R A规范跨厂商的行业标准地 OB 位, 这种兼容主要将通过修改I 源代码的I 核心协议模块, c e c e 来使 I 协议向 c e 处 于标准地位的C R A规范靠拢。 OB 对 I 进行 O 核心协议替换首先要考虑三个问      H P c e 题: 首 I 采用了紧凑的      先, c 。 编码方式, 无须字节对齐; O B 而C R A规范使用C R D 编码方式编码,C R的特点是需要字节对齐,对于 D 超过一个字节的数据类型都要 视情况进行填充对齐。I 要与 C R A能够进行互通信,编码格式上必须能有一 c e OB

I 中间件关键技术的 c e 研究与实现 致的处理方法 。

其次,c      I e使用的协议消息与C R A规范规定的协议消息比较, OB 无论协议消
息的种类还是内容有所出入,所以要综合二者做出取舍。要分析各协议的含义,

确定能够互通信的消息的集合,并对部分协议消息加以必要的修改,使之符合互
通信要求。

最后,I      对象代理是透明的,应用程序可根据所掌握的 Srat “ e n 的信息构造 v 出对象代理,不用初始化服务的介入; O B C R A规范规定代理是不透明的, 应用程

序不可构造出一般的Sr n的对象引用, e at v 需要通过诸如名字服务一类的初始化服 务获取对象引用或者直接获取 IR进而由C R A核心对象构造出对象引用。如 O OB 何统一两种对象代理的调用, I 客户端调用 C R A服务器或 C R A服务器 是 c e OB OB 调用 k 客户端所必须要解决的一个问 。 题。 上述是对 C     I 进行 H P 。 O 替换时必须解决的首要问题,解决了这三点, 才能够
同其它符合 C R A规范的产品进行互操作。 OB 521 ..  编码方式协调

H P O B 抽象的GO 协议的      R A中 O 是C IP 一种针对T PP C/ 的具体规范, I 其协议 状态机和编码规则是不可分的。 c 核心协议的协议状态机和编码规则是可以分开 I e 的,这一方面提供了更好的向 后兼容性,另一方面也为编码规则和协议状态机各
自的版本升级打下了良 好的基础。 5 .1编码方式的不同 .1 2.

公共数据表示 (D ) C R A调      C R 是 O B 用中将使用的 数据类型的正式映 客 射。
户机生成请求时,它不必知道请求要发送到什么地方,或者哪一台服务器将响应

该请求。 O B ( C R A 作为规范) GO 作为规范的一部分,定义消息结构和传 和 IP( 送) 被设计成允许实现一个接口的可能的多种不同 服务器之一来响应请求。规范
必须定义如何打包操作中的数据,这样所有可能的服务器都可以抽取参数并调用

远程操作,并且数据转换不会产生多义性。 字节顺序是指占内      存多于一个字节类型的数据在内 存中的存放顺序,通常有 小端、大端两种字节顺序。 小端字节序指低字节数据存放在内 存低地址处,高字 节数据存放在内存高地址处;大端字节序是高字节数据存放在低地址处,低字节 数据存放在高地址处。 存的生长方向 内 是不变的, 存中数据是由C U解释的, 而内 P 所以这个特性是由C U而不是内存来决定的。基于 X 6 P 8 *台的 P C机是小端字节 序的,而有的嵌入式*台则是大端字节序的。因而对 i, t , t 等多于 1 n u 1 u3 t i 6 i 2 n n 字节类型的数据,在这些嵌入式*台 上应该变换其存储顺序。

第五章 I 与 C R A互通信的实现 c e OB

H P使用了一种 “      O 由接收者负责使其正确”的方案:消息的发送者会用它的
原生字节序整编数据,接收者则会在必要时交换字节序。这种做法使得协议变得

更复杂,确有没有带来切实的性能提高,而且,因为中间节点可能会不必要地重
排数据的次序,对于要把消息或消息的某些部分转发给下游消费者的消息交换机

而言, 这种设计使得开发者很难设计出高效的实现。 I      c e的编码规则比较简单和紧凑,I c e采用固定的小端字节序整编所有数据, 并且总是按字节对齐,也就是说不进行任何填充。这在整编代码的简便性和尺寸
方面提供了相当的好处,并且使带宽消耗降低到了最低限度,这对广域网和低带

宽链接而言尤其重要。 所有通过 “协议交换的消息的有效负载都进行了封装。也就是说,I 是这     I c e 样发送每个有效负载的:先发送一个字节计数,后面跟着一块数据。开发者可以

藉此实现高效的消息交换机 ( 如事件服务) 比 ,只需要简单地对数据块进行拷贝, 中间节点就可以 把到来的消息转发给任意多个接收者,而无需解编和重新整编消 息。此外,固定字节序确保了,只有当最初的发送者和最后的接收者运行在大端 字节序的机器上时,才需要重排字节序。要转发消息的中间节点也无需对被转发
的数据进行字节交换。

5 .2统一编码方式的解决方法 .1 2.
C R编码的实现主要是考虑字节对齐。所以要在 I 进行 C R编码的支持,      D c e D 引入当前读/ 写位置标识变量、填充对齐等方法,并且要针对封装、嵌套封装做出 相应处理,比如将读/ 写位置标识进行入栈、出栈处理等,这个层面的工作过于琐 细,主要在 B s S em中修改。 ai ta cr
522协议适配 ..

5 .1 P协议和 I 协议比较 .2 H 2. O c e

对 C R A而言,      OB 一旦包装了所有数据, 就将使用 IR中的信息来创建连接。 O 您可以 区别 IR的结构, O 通常必须使用 T P作为 C 传送机制。 但是, 也可以 使用
其它传送 ( 再次提醒,请参阅 C R A 规范以获取详细信息) R 守护程序负 OB 。O B

责查找 IR指定的对象实现,以及建立客户机和服务器之间的连接。 O 一旦建立了

连接, IP将定义一组由 GO 客户机用于请求或服务器用于响应的消息。 客户机将发

送消息 类型 Rqe, cee e, cRq s F g e 和 M sg rr e s L aRq s Cn l u t r mn u t o t u t a e e e,  t a eaEo se ro 服务器可以 发送消息 类型 Rp ,  ceey C s on tn F g e 和 ey o t p ,  e n co,  mn l L aR l l C ei r t o a
Me ae r r s gEr o s o

I 中间件关键技术的 c e 研究与实现

I 的协议类型很简单,      c e 只有五种消息 类型: eu t Bt Rqe ,  l Rqe , c eus Rp , s ah t ey
V l a C n et n adt o nc o ,以及 Coe o nco . i e i l - n et n sC i

Vl aCnei 和C sCn c n 适      n tn le o ei 只 用于面向 接的 alt o co ie d o- n t o 连 传输机制。 使 在
用面向连接的传输机制时,在接受了到来的连接之后,服务器会做出响应,把一

条VlaCnei 消息发送给客户。 adt on tn ie co 该消息告诉客户, 服务器已 经准备好接受 请求;该消息还用于在客户和服务器之磋商协议版本。 adt onco Vla Cnei ie tn消息还 消除了GO IP中的一个固有的竞争状况: 没有现实的连接确认, 客户可能会向正在
关闭的服务器发送消息;当客户意识到服务器已关闭连接时,它不能再尝试发送
该请求,因为哪可能会违反 “ 最多一次”语义。

5 .2适配协议消息的处理方法 .2 2.

根据C R l(0     A .1) O B 1 .规范替 换了I 中 请 答复 c 的 求、 消息, e 取消了I 的 c 验证 e 连接消息, 保留了I 的 请求、 连接消 对于C R A.1) c 批 e 关闭 息, O B l(0 1 .规范中 规定
的其它消息暂时没有实现, 总之此次改动的目的 是初步实现 I 替换及同其它符 MP 合 C R A规范的产品进行互操作,完全是试验性质的,存在诸多不完善。 OB 以请求消息头为例,如下图51      -所示:

s rc Rqeta a{                        tut  usDt e it q etd                              n r usI ; e Ie :d ni y  ;                              c :I et t i d Ie :t ig e f c t                              c :S rnSq  e ; a s rn o ea in                              t ig  rto ; p bt m d ;                              ye  e o
I e :o t x c n e t                                e :C n e t  t x ; o Ecp u ai n  rm ;                              n as lt o p a s a
}                              ;

i5 ( I 请求头 1 1)  ' -a c l  e
s ut  us edr _ { t cR qeta e 11 r e H _
IP :e ie o txls      vc C ns tit O : r S .

us nd       l g ni e o g n
b oe n      o la
o tt        ce

sri c 斌 ev tc 川. c rqet闭; eus - r pne pc d e o s e et ; s x e r e e[ ;  d d  IP  e r d ]( de iGO 1 sv 3 ! A n  . 1

翻 叼s n  oc 俄沪 e c e  i

oj t ; bc 脚 e
o e tn pr i ; ao

翻r i 叩 C R 丸: tt阅 O日 O e c s              } ;

r usn- r c a e et gpi i l q i np ;

图5 何 GO L 请求                            - IP I 头 1

I 请求头和 IP.      GO 1 请求头差异较大,本文所做实现采用的作法是将 I 请 c e 1 c e

求头中的m d c tt oe o e 装入GO 1 的S veotts中, d t ,  t ,  x n IP. e iCn x i 1 rc eL t I nt fe装 ei a y c 入GO 1 的oj t   中,c的 IP. b c Ky I 请求消息体需要封装, IP 中 1 ee e s e 但GO M 请求消息

第五章 I 与 C R A互通信的实现 c e OB

体不对应封装,因此要去除封装以匹配 GO M  IP 0 523对象代理 ..
5 .1 .3 对象代理的不同 2.

不能采取舍去 I 透明的对象代理语义的做法,      c e 因为代理透明毕竟带来了应用

程序开发上的 便利。 作者采取了 保留I 代理语义透明的同时兼容C R A代理语 c e OB
义的做法,乍看似乎自 相矛盾,但结合 I 核心架构的特点并深入到 IR内部之 c e O 后就会发现这样做完全可能。
I R是一个高度结构化的字节序列,其内部结构如下图 52      O - 所示。

b H t- d n i i e ni gt e a l

标志(bt I ) y e

t( ys a 4 t) g bc
J 产 户 沪 , 尸、 产 ,

封装的   

白即 e p fl          o r e i

. }P r . 场S % k

J 户 户 护 产 沪 沪 护

_ 二 1 -- -- - - ‘二 一- -- - -- 一 s une ge p f > e ec n g ri q a d  t o e

之、一-一一一??-一

= } 座口 ,叫    国度 、 S e q u e n c e
Vio 2 s ei(bt) sn y e
hssi ott g (r n pruhr o( o) tst ojdC ( qec b Iy eune e es
< c t) ot> e

Sqec eune  < ge      d tg a
cmp n n> o o et

1 SI 其 有{ 一日eD 它 关 v r a n t  5 一
图5  IR结构示意图                                - O 2 

IR包含寻址服务器、      O 查找Sr n的全部信息, O e at v IR是标准化的,因此不同 的 C R A产品可通过 IR进行互操作。IR由 OB O O 服务器端生成,客户端通过某种
方式得到它,再利用它构造对象引用请求服务器端 Srat evns

所谓的      用 透明 针 O 中的o eKy 对象引 不 是 对IR bc e而言, bc e包 o, jt o eKy 含pa jt

sv t D 也 包 其 ee ea 的I, 可以 含 它S v 有关的 rn rr 信息,oeKy 具 容 什么 bc e的 体内 是 jt 对客户端 而言并不 重要, 端 要 只是 客户 需 做的 得到这 bc e, 拷贝 请 个o eKy 把它 到 jt
求信息中, 发送给服务器, 于。 eKy 由 b c e 是服务 jt 器生成的, 服务器0 然知道如何

解析它, 服务器从中 解析出pa  e a I, 后定 o, o定 ea , oI, n D然 位pa Dsv t  r 再由pa 位Srn vt

I 中间 c e 件关键技术的 研究与实现

发起向上调用,得到返回值, 编组返回 值等等。 I      c e的串化代理作用类似 IR O ,但 I c e的串化代理非常简单。I C 。串化代理由

I nt npi 构成,np n 服务 服务器 d t 和Edo t Edot ei y n i 寻址 器, 再利用I nt定位Sr n dt ei y ea. vt 所以I nt作用类似o eKy dt ei y b c ee jt

图5  C R A  e定位 Sr n的方式 - O B Sr r 3  e v e at v

S re 的tedol e r h aPo维护这个映像. v r

图5  I Sr r Sr n的                        - c e e定位 e at 方式 4 e  v v

通过上图5      -和图5 3 一可以 看出I Sr ; O B Sr : c e e和C R A v 定位Sr n的区 e  v ee e at v
别:c Sre定位 Sr n不需要对象适配器的I, I e r e  v e at v d 只用 Sr n 的I 就行了, e at d v 这

是由I 核 c 心架构的 e 特点决定的。 O B C RA中的o eAae之间 杂的 bc d t jt pr 是复 层次关 系, c的 个o eAae之间 行的关系, 存 而I 各 b c d t e j t pr 是并 不 在层次关系, 而 因 便于组 织和管 I 中 个连接 (o ei ) 理,c 每一 e Cn co 都含有对与 n tn 之相关的。 eAa e的 bc d t jt pr 引 所以 须对o eAae进 找。 用, 无 bc d t 行查 jt pr C RA中p d ea I的 成 O 策略 关, 论是 种 略,      oI Sv t 生 和PA的 有 但无 何 策 OB a ,  n d r
客户端都无法根据已知的服务器的 信息和 Sr n 的 端点 e at 信息构造对象引用, v 因为

服务 器端的C R A核 成的pa  ea I 以 合二者生 O B 心生 oI Sr n d 及结 d v t  ,  、 成的。 eKy bc e jt 都对 应用程序具有不可见性, 有时 bc e翻译 对象密钥” 很形象 所以 将o eKy 成“ jt 是
的。

第五章 I 与 C R A互通信的实现 c e OB

I 中则是另一番景象。c 不存在持久对象和暂态对象的差别, O B      c e I e 以C R A的 标准衡量,可以认为 I 中的所有对象都是持久对象,I 核心对应用程序交给它 c e c e

的I nt不做手 因 dt ei y 脚, 此在I 中 用 c 应 程序可以 e 直接根据I nt Edo t 造 d t , pi 构 ei n n y
对象代理。

5 .2  R A对象代理的 I 支持 .3 C B 2. O c e

要和 C R A的这种代理模型匹配,     B O 需要在 I 中加入对 IR的支持, c e O 需要将

I nt装入o eKy 在实 程中目 照下述原则改 dt ei y b c e 中, 现过 jt 前按 动:
. 改造后I      c 原先的代理语义依然有效。 e . 改造后 c      I 程序之间的通信可通过原先的串化代理,也可以通过 I 产生 e c e
的 IR O 。同时,I Sre产生一个 IR C R A i t c e r e  v O ,  B C e 可通过此 IR请求到 I O ln O c e

的服务; O B Sre产生一个】R I Ci t C R A  vr e O ,  ln可通过此 [R请求到 C R A的 c e e  O OB
服务。

. 改造后不向应用层添加额外的接口。     

上述目 基本己 现,c 中 前通过Cm uit: si TP x 构      标 经实 I 以 e o m na r t gor y 造 co : n o r
串化代理,改造后此函数既可以 接受原先简单的I 代理串,也可以接受 IR串, c e O 不论是哪一种 串,成功解析后都会返回相应的对象代理。C m ui t o m nar co

p xTSi 用于产生IR 这可在I Sr r O B C e 交互时使用。 r yot g o r n O, c e e同C R A  n e  v lt i 此处的      修改主要针对Rfe e Rfe e cr Rfe e ot g er c erc ao . en 的t r 方法 en , en F t y er c Si n 改 将根据Rfe e 造后 er c输出IRRfe e cr的ca( n si & 方法 en O , r c ao e n F ty rtc s t g s) e eeo t  t r n r 改 造后即可接收 I 代理串, c e 也可以 接受IR串, e r c在创建时将生成相应 O Rfe e en 的o eKy b c e字节序列, jt 这个序列中 含Int fe的 包 d t ,  t 信息。 ei a y c

53实现过程与实现结果 .
531实现环境 ..
使用 I 1 .     5 版本, O B c .1 e C R A选用开源的J O B产品,c 使用 C + a R c I e 十 开发,开

发 环境为V +6 ,  R 使用J a 发, 发 C +. J O B 0 a c a 开 开 环境为Els . v cp 3 o ie0
532实现步骤 ..

首先按照 5      .节提出的方法, 2 修改I 的C + c e +源代码, 使之在编码方式,协议 消息和代理体系三方面达到 C R A规范的标准。 OB 然后,编译 c      I 源代码,生成运行时库。 e
接着,使用 c      I e的服务器和客户端例程,完成依赖于 IR传递对象标识的测 O

I 中间件关键技术的 c e 研究与实现

试。

然后,测试I 的Ci t c e ln程序与C R A的Sr r e OB e e程序之间的互通性。 v 最后,测试 C R A的Ci t c 的Sr r OB ln与I e e e e程序之间的互通性。 v
5 3 3实现结果验证 . .

对 H lWol eo r l d例程进行测试,I c e的客户端可以访问 Jc R 的服务器端, aO B

J O B的客户端可以访问I 的服务器端, c 的客户端可以 a R c c 。 I e 借助 IR支持来访 O
问 I 的服务器端。说明 I 与 C R A的互通性 己经基本实现。 c e c e OB

54本章小结 .
本文首先介绍 I 与 C R A互通信的意义,然后确定 I 与 C R A互通信      c e OB c e OB 所需要解决的几个难点, 接着详细地阐述了如何具体解决这些难点的思路和方法, 最后对一些实现细节进行了描述。

第六章 总结

第六章 总结
在计算技术的新格局即将诞生的背景下,各种资源节点间的互操作性得到了      越来越多的关注。中间件一方面在解决异构环境下互操作性具有重要地位,一方

面也面临着应用上业务扩展受限以 及中间件间互通性不足的不断挑战。 。 k 作为一 种新型中间件,汲取了前人开发的丰富经验,具有了以往所有中间件所不具备的 特殊优点,其与新型计算技术的结合更给中间件技术领域带来了新的革新之风。 本文所作的主要工作和贡献是:      对网络通信引擎技术进行了较为详尽的研究。      本文先从网络通信引擎的结构、 接口 定义语言、 通信协议、 基础服务等多方面对其进行介绍, 在比 较中突出I 作 c e
为新型中间件产品的创新之处。

对网络通信引擎的核心代码进行分析消化,对其各核心功能模块进行刨析,      为进一步在 I 基础上进一步扩展其功能做铺垫。 c e
对“      传输层协议可替换构架”和 “C /O B IEC R A互操作”两项关键技术进行深

入研究,提出切实可行的方案,并实现之。 本文涉及的工作在理论上或模型实现上尚有很多的问题需要解决。有待进一     
步研究和实现的内容包括:

1      ,如何在使用其它传输机制的 情况下仍能使用线程池模型。 现有的可替换框 架理论上对所有的传输机制都可以,但是每连接一线程模型相比线程池模型效率 低了很多, 有必要通过进一步研究,能使线程池模型应用到其它传输机制上。 2      ,如何使用更方便的互操作构架解决 I /O B 互操作。目 cC R A e 前虽然实现了 I /O B c C R A的互操作, e 但这种互操作是需要修改I 的 c 源代码来实现的, e 有必要研

究新的互操作构架,比 如说使用 I 的 c 插件机制来完成现有的I/O B e cC R A互操作 e 功能, 或者进一步开发协议消息交换服务器, I 和 C R A协议消息的交换。 实现 c 。 OB

致谢

5 9

致谢
至此论文结束之时,我衷心感谢所有关心我、爱护我、帮助我的人。      首先,把我最诚挚的谢意献给我的导师吴宇红副教授,感谢吴老师在项目实      现和论文写作期间给予我的指导,以及三年多来对我学*、工作、生活的关心和 支持。吴老师渊博的学识、一丝不苟的工作作风、耐心的教学态度以及对分布式 系统和中间件领域敏锐的洞察力,都给我的学*和研究以莫大的启发。她严谨的

学风、豁达的胸襟和诲人不倦的精神令我终生难忘。从论文的立题到撰写,吴老 师不但从宏观*镏野盐照返 研究方向,还在一些具体的问题上给予我很多
耐心的指导。

这里要特别感谢王栋师弟、田伟师弟和裘楷师妹,      他们和我一起完成了I 的 c e 代码分析和替换研究工作, 我的论文成果离不开他们的大力支持。 还要感谢张岗山老师、刘炯老师、冯磊老师、李娜老师、周战琴老师在工作      中和生活上给我的帮助和关心。他们对科研和教学工作兢兢业业,对我既有作为 师长的循循善诱、答疑解难,又有朋友般的帮助与关怀。 感谢我的其它各位同门,他们是李全、胡羽文、杜能功、王志军、刘伟、      付 海涛、王炎、候景华、李昆等硕士。他们在我攻读硕士学位期间,给予我许多无 私的帮助;感谢他们与我在工作学*上的探讨与鼓励,感谢他们对我的 信任与支 持; 他们每个人身上都有着很多优秀的品质值得我去学*,与他们的相处丰富了
我的人生。

还要感谢我的其它师兄师姐师弟师妹们,      几年来,他们不仅对我的学*生活 给予了很大的帮助,同时大家融洽地学*和交流的环境也深深感染了 我。 感谢我的家人,感谢他们在我成长过程中付出的一切。他们的理解与支持,      是激励我在人生路上不断前进的永远动力。 感谢所有参加论文评审的各位专家、教授以及老师们。感谢他们对论文提出     
的宝贵意见。

参考文献

参考文献
[ JBc s ud g  o ptg  li '  i wv,  m nA M     u Fni t cm un r o tn s d  eCm u.  1 . k ,  n h ]  a e  i e uo tr a o v h C 4( )  17 一 6 4 1( 0)  7. 1 2 0 1
[ M. t nr aa,  v i c ptg v o n c lne E E     a aa ynn Pr s e m un: i ad aegs IE 2 ]  S y a e av o i i n  h l ,  s Pr nl  m n( 0)  1. e oaC m u.  11 一 7 s o 2 0 0

[ Xa- Sn l . e yMdl a :  e t e gn ao     e  , a R B tk. d w r t ky n t etn 3 i H u A n  l c ] n a ie eh e  o  e ri x
cm un.  rl Dsi C m u. 20)  一 9 o ptgJP ae ir .  pt 4  469 61 i .  ll  b o a t 6( 0 8

[ Moa u a e oz  hai al  a I .  d e r      K m rBh o A Siz S a K D s P O A i l a 4 hn  ,  r ]  . r ,  j .  .  C M dw e Fa e o f Prav C m un [. E r s e  ptg JlSp m e r w r o e s e  ptg  IE P v i cm un,  -et br m k  v i o i J E r  ] e av o i u y e 20.o2 o ) 03V1( .. , .N 3 [ I FsrC e e n Te  d  l rt  N C ptg     t,  Ks la,  Gi 2 Bupn f a w  m un 5 .  e .  sm ]  o h r :  e i o r  e o i
If t c r Mo a K u anLs  sC , 41 n a r t e r n  f n, At ,  20.  r u u ,  g a m s o l A 0 5 o

[ Epr r RprNxGn ao Gis Er e r e a h 5     Gop  o. t etn d ) u pa GiRs r 20 6 xe u e t e e ri r(,  n d e c 0 ]  t  o
一 00Mody1tJn 20 21. na,  ue  3 6 h  0

[      民 ,史 红 周 。 网格 终 端 和 普 适 计 算 的 发 展 趋 势 。 7 ]朱 珍
hp/si. . / w l dlsy yl3 d t :ctca c d n as g/ lO. f t/ .tc n o o x g j p

[ 张云勇, 江, 锦 等。 件技术原理与 用。      张智 刘 德 中间 8 ] 应 清华大 版社, 学出
20 年 1 04 0月,3 -5

[ Oj t  ae e r , C m o Oj t us r r r t te     M ngm nGopTe  m n  e Rqe Boe Acic r 9 bc a ] e t u h o b c e t k :  eu h ad  ci tnVro 3 , 2A aalahp/w . g r . n Seic i ,  i . 20. l e t: wo .g p fao e n  0 vib t  / s 0 t w m oJ [ ] o Ga EdnH Ii Dsi t Cm Mc s t  ,  .     ,  d o,  se ru d  .  o f rs 98 1 Edn .  d 0 d n .  i b e o i o P s 1 nd t r e 9

[ ]  ,  nri a Ba Tc o g hp/v u.mp dc/ /     nEtpsJ ae s  nl y t:a sno/ousj. 1 S NI . e re  n e o . / a c r t b 1U c v h tj e [ ] 3.  P  sn  W3 Rc m nao 4 n 2 3      S A Vro 1,  C e m ed i 2 J e 0 1 Wc O 2 ei . 2 o tn  u 0
hp/w .3 r T/ al- r/ t : ww .g Rs p2 al. t/ w o / o pt [ ]  n g  h N A r c o  e - i t Mi e r IE     i MciA  w  p a t Oj t rn d dl a . E 1 Hn n i .  e p o h  b cO e e 3 e dw e E C m u r iyJ ur b a 20. o pt Sc t a a -r r 04 e o e .  y u y  n

[』      吴宇 刘 基于 代理的 1 古玉洁、 红、 炯. 影子 4 战术网网 络管理系 研究. 统的 北 京邮电 大学学报. 0V17 2 3 2. 0 o .
[ ] Z o        ene      r , I . Dfr cs bte     ad  C R A 1     C 5 e n c i e     e I        B . e n  c w e  n O
h p/w . rc o /e s O B .m . t : wz o. mi V C R Ah l t/ w e c c t

[ ]  Bc i. d i en g  B Pr racA s tn.  e     e wt Vlan Hni C R A  fm ne ei s nhi 1 Bl k h a tg  n O 6 i l  i eo sr Aa m o
O T Met gF b u r 2 0 MG  C  en .e r ay 0 4 i ,

[ ]en gMih,F e i s  d  e  C ag A ot R A U L 1 H ni 7 n c i i T n I L t hne  u C B .  v h g '  i o  k b O R

l 中间件关键技术的研究与实现 e e

hp/w . g rde m r0- - .t t: wo .g os a / 0 0 p t/ w m o L / s4 2 6 p [ ]  n g  h p il k iru d  r mn i c Rv i     n M ciSme M r Dsi t P g m i wt I . io 1 Hni i ,  l a .  b e r a g h  e sn 8 e t o e
20 1 No e e 2 0 . .. 5  v mb r  4 0

[ ]  g s  c d A c oCneo:  b c Cetnl e f      a C Sh i. et-onc rA Oj t aoaPtr  1 D ul . m t c p r 9 o t n  e r i an o t r
C netg  I tli C m ui t n v e. oncn ad  iin o m n ao Sri s i n n az g  i ci e c

[ ]  C Sh i n C l l ,  ln ae s  ee p  e ie     . md ad  Ce ad A p i Ptr t D vl Et s l 2 D 0 .  c t  . en p y g  t o  o x n b n O B dl a .  eg  tr i C m ui tn (. n, ,  bi e R Mi e r i D s P t s  o m n aos  Rs g e. Cm r g d w e n  i ae n  n n ci L i i d a d ) U i rtPesA gs, 0. 3 3 n e i rs uut  1 9- 8 v sy  ,  2 3 4 0

[ ]  g s  cmd Crs  y ad a Oh a. ln ae s     aC Sh i, o ORa, Os a m nA p i Ptr 2 D ul .  t a 1 o l ' n n sm t p y g t n
t D vl a  gal Po cl Fa w r fr  B  dl a .  D s o  e p  Pugb   r oo r e o l e  t s  me ok  O o R Mi e r i e g d w e n  i n

Ptr iCm uitn (. n,  Cm rg U i rtPe , u , 0 ae s  o m n aos Rsge. a bde v sy s A gs2 1 t n  n ci L i i d,  i n ei r s u t  ) 0
4 9一 9 3 44

[ ] m t .  ' n C y a,  c r .ad  c an F     d D C ORa, Pa l L Mr e M,  Bs m n,  2 Sh i,  . y . ri ,  h ,  n u h 2 c ,  ,  .
Iae F lw r A s  ae  r c n m lt edd et  u i ei - dr o o e :  ei ptr f e iet  th ae e n dm lp x g e / l s d g t o f i n n u ir v e tl n

ad pt i . cei s t 7 Ptr  nugs Por s  fec n d a h g Poed g o h t ae L gae o r a C n r e i cn r s n f  h  t a e  n f  g m o e n ( o 20) t: ec. c uld/ 必sd /. f P P  0 hp/ ueo. s. u o pfI d. L 0 ; l t d d w t d e sp f

[ ]       Et s lTas rFa e o f R aT e R A e  i 2 O 3 MG  e ie n o   m w r o el i C B T R P  x nb r pt r k  r  -m O h F s
OMG ou n ob s 0 00 -2 T e ia sb sin ae  O d cmet  o/ 0 -91 .  i t l  mi o s  i MG ou ns r 2 h ni u s r n  d c met

Obs 0 1 1 5Obs 0 0-1 3ad  o/0 1 2 5 rO/ 0- - , O/ 0 1 - ,n obs 0- - . 2 00 r 2 01 r 2 00

[]     J a 2 阎宏. v 与模式. 4 a 第一版. 子工业出 电 版社, 0 年 1 月. 22 0 0
[ ]        E  R aki n ID E A E O U IN  O  A L  2  K   E  ata e.  D L W R           L I 5 i n  M S L TO  F R  P N T R S G  be o m n ao Tcnl i,  -  Ma h 01 E WO K .         i tn eho g s 2 2 3 Moi C m u c i l o e     r  20, 6 8  c
C n ee c P biain o 4 7 I E  0 . o frn e  l t N .  0  2 1 u c o 7 E 0

作者在读研期间的成果

作者在读研期间的成果
发表论文
(R O B传输层协议扩展研究与实现》 发表于 20 年西安电子科技大学通信学 05
术年会。作者:王博、吴宇红。

参加科研项 目
海军综合网络管理系统的研究

基于发布者一订阅者模型的战场信息分发系统的研究 网络电话系统 FeP r P的研发 e 广东移动直方站网管软件的研发 广东移动和北京移动 WL N网管软件的研发 A



热文推荐
猜你喜欢
友情链接: 团党工作范文 工作范文 表格模版 社科文档网 营销文档资料 工程文档大全