（模式识别与智能系统专业论文）应用于三层结构的软件互操作的研究.pdf

摘要 摘要 随着软件技术和网络技术的发展，基于三层体系结构的软件开发正成为当 前分布式软件系统开发的主流。相应地，为业务逻辑提供运行环境的应用服务 器的地位和重要性也已经被迅速认可，并被认为是继操作系统和数据库系统之 后的第三类里程碑式的系统软件。 论文主要围绕三层软件体系结构中应用服务器的主要关键技术展开研究。 不同的应用服务器通常针对不同的应用领域，本文针对校园“一卡通”系统的 需求，设计并实现了适用于该领域的应用服务器。 首先，本文在对软件互操作进行深入详细讨论的基础之上，设计了一种适 用于“一卡通”系统的互操作协议。该协议是面向过程的协议，将过程作为客 户请求的对象，客户通过调用部署在应用服务器上的过程实现自身的功能。 其次，本文设计并实现了使用该协议通信的客户端服务代理和应用服务器。 在应用服务器的设计中，解决了客户连接管理、过程管理、过程动态调用和提 高应用服务器效率等关键问题。 最后，本文对应用服务器的可行性和运行性能进行了测试。 本文的研究对于三层体系结构中互操作系统的设计与实现有一定的参考借 鉴作用。 关键词： 软件互操作互操作协议三层结构软件系统应用服务器 a b s t r a c t a b s t 陀c t w i t t lt h ed e v e l o p m e n to fs o f h v a r ea 1 1 dn e tt e c h n o l o g y ，m r e e t i e rs o r w a r es y s t e m a r c h j t e c t i l r ei sb e c o m i i l gt 1 1 em a i n s 仃e 帅o fc u r r e n td i s t r i b u t e ds o f h v a r e s y s t e m d e v e l o p m e n t a c c o r d i i l g l y ，m es 诅m sa n di m p o n a i l c eo fa p p l i c a t i o ns e n ，e rh a sb e e n r e c o g l l i z e dp r o m p n y i tw a sc l a i l e dt 1 1 a ta p p l i c a t i o ns e r v e rw a sam i l e s t o n eo fm e t l l i r dc l a s ss y s t e ms o r w a r e t 1 1 er e s e a r c ho ft l l j st 1 1 e s i sf o c u s e so nt h ek e yt e c h n o l o g i e si nt h ek e m e lo f d e v e l o p i l l g 印p l i c a t i o ns e e ri nm et h r e e t i e rs o f h v 甜es y s t e ma r c h i t e c t u r e f i r s t i nt l i st 1 1 e s i s ，a i li i l t e r o p e r a b i l i t yp m t o c o lf o rc 锄p u so n e 一( 知dn e t w o r k i n f o 姗a t i o ns y s t e n li sd e s i g n e d t h em t e r o p e r a b i l i t yp m t o c o li so r i e n t p m c e d u r e h t t l ep m t o c o l ，c l i e n tr e q u e s tp r o c e d u r eo nt h ea p 叫i c a t i o ns c r v e rt oa c t l i c v et h eb u s i l l e s s o b j e c t s e c o n d ，t 量i i st i l e s i sd e s i 弘sa | l dd e v c l o p st h ec l i e n t e n ds e i c e sp r o x ya n d 印p l i c a t i o n s e n ，e r u s i n gt l l ei n t e m p e m b i l i t yp m t o c 0 1 i n d e v e l o p m e n to ft 1 1 e a p p l i c a t i o ns e r v e r ，t t l em a i l a g e m e n to fc o r u l e c t i o n ，t t l em a n a g e m e n to fp r o c e d u r e ，也e d y n a i i l i ci n v o l 【i n go f p r o c e d u r ea n ds on oa r es o l v e d a tl a s t ，t i l i st l l e s i se x a m i l l e st l l ef c a s i b i l i t ya n dm en l i l t i m ep e r f o r r n a n c eo fm e a p p l i c a t i o ns e r v e l 1 1 h ec o n t e n to ft h ed l e s i si su s e 砌f o rt h ed e s i g na i l dt 1 1 ed e v c l o p m e n to ft 1 1 e m t e r o p e r a b i l i t ys y s t e mi i lt t l et l l r e e - t i e rs o f t w a r ea r c h i t e c t u r e k e y w o r d s ： s o 凡a r e i n t e r o p e 豫b i l j 坝i n t e m p e m b i l i t y p r o t o c o l ，t l l r e e t i e r s o f h v a r e a r c “t e c t l 工，印p l j c a t j o ns e n r e r 图目录 图目录 图1 1 三层结构的校园“一卡通”系统结构图 3 图1 2 已有三层结构“一卡通”系统中应用服务器的结构4 图1 3 已有三层结构。一卡通”系统中应用服务器的结构4 图2 1 0 s i 参考模型 7 图2 2t c p 口参考模型8 图2 3 互操作体系结构在网络体系结构中的位置 1 0 图2 4 互操作体系结构1 l 图3 1 消息头部格式一1 7 图3 2 请求消息的消息体格式 图3 3 响应消息的消息体格式 图3 4p o i n t e r 类型结构 1 8 1 8 2 l 图3 5 数据类型的编码一2 2 图3 6p o i n t e r 类型的数值字段 图3 7 请求消息的消息体 图3 8 响应消息的消息体 2 3 2 4 2 5 图目录 图3 9 被动关闭式连接 图3 1 0 主动关闭式连接 图4 1 基于应用服务器的三层分布式结构 图4 2 客户端服务代理结构 图4 3 基于t c p 协议的网络程序开发 图4 4 互操作协议层对网络接口层的调用方式 图4 5p a 髓m e t e r 的内存结构 图4 6 应用服务器的基本结构框架 图4 7 消息接收线程流程图 图4 8 验证过程流程图 图4 9i 唧o i e l s h r t 的流程图 图5 1 测试采用的表结构 v i i 孙 砣 弘 站 弼 甜 锣 针 钇 配 表目录 表3 1s p c p 消息类型 表目录 表3 2 服务器运行结果取值 1 6 1 9 表3 3s p c p 数据类型2 0 表3 4 输入输出类型编号 表4 1v + 6 o 中的过程调用约定 2 3 s 4 表5 1 测试的硬件环境6 l 表5 2 测试的软件环境6 l 表5 3s t u d e t 中字段与s p c p 数据类型的对应关系 表5 4 应用服务器的测试结果 表5 5 平均响应时间的比较 v i i i 6 3 6 3 6 4 南开大学学位论文版权使用授权书 本人完全了解南开大学关于收集、保存、使用学位论文的规定， 同意如下各项内容：按照学校要求提交学位论文的印刷本和电子版 本；学校有权保存学位论文的印刷本和电子版，并采用影印、缩印、 扫描、数字化或其它手段保存论文；学校有权提供目录检索以及提供 本学位论文全文或者部分的阅览服务；学校有权按有关规定向国家有 关部门或者机构送交论文的复印件和电子版；在不以赢利为目的的前 提下，学校可以适当复制论文的部分或全部内容用于学术活动。 学位论文作者签名：籼 如6 年j 月坷日 经指导教师同意，本学位论文属于保密，在年解密后适用 本授权书。 指导教师签名：学位论文作者签名： 解密时间：年月日 各密级的最长保密年限及书写格式规定如下： 南开大学学位论文原创性声明 本人郑重声明：所呈交的学位论文，是本人在导师指导下，进行 研究工作所取得的成果。除文中已经注明引用的内容外，本学位论文 的研究成果不包含任何他人创作的、己公开发表或者没有公开发表的 作品的内容。对本论文所涉及的研究工作做出贡献的其他个人和集 体，均已在文中以明确方式标明。本学位论文原创性声明的法律责任 由本人承担。 学位论文作者签名：彳协 抛z 年j 月矿日 第一章绪论 第一章绪论 第一节论文背景 随着计算机软、硬件技术和网络技术的发展，软件运行平台正从单机环境 发展为网络环境。近年来出现的电子商务_ 电子政务等模式是这一发展的典型 表现。相应地，软件结构也发生了很大变化，特别是那些由分布在不同结点上 的分布式程序构成的大型软件系统，其结构完全不同于单机环境下的软件。它 们必须充分利用和适应网络环境特有的分布性、开放性、演化性、异构性、并 发性等特点，实现其更好的灵活性、适应性、可移植性、可伸缩性和可维护性l 。 也就是说，分布在不同结点上的应用程序不仅需要能够互相通信，还需要能够 互相协作，以共同完成大型任务。 在8 0 年代中期出现了客户机服务器的软件结构，应用程序的处理在客户机 ( c u t ) 和服务器( s e r v 盯) 之间分担，这种结构也被称为两层软件结构。这 种结构因为其灵活性得到了广泛应用，但对于大型软件系统而言，在系统的部 署和扩展性方面还是存在着不足。为了克服客户机，服务器结构的不足，一种新 的、更具生命力的体系结构被广泛采用，这就是三层软件结构闭。 与两层软件结构相比，三层结构具有以下优点： 三层软件结构采用表示层，业务逻辑层，数据层的结构，客户请求、程序 处理和数据操作被隔离。 三层软件结构是个更灵活的体系结构，它把显示表示逻辑从业务逻辑中 分离出来，而业务逻辑层处于中间层，有利于系统扩展。 三层软件结构具有更好的移植性，可以跨不同类型的平台工作，允许客 户请求在多个服务器问进行负载平衡。 三层软件结构的安全性更易于实现。 应用服务器位于三层结构的中间层，负责处理前台请求和业务逻辑，为业 务逻辑提供运行环境，是运行在网络环境中的系统软件应用服务器应当为业 务逻辑提供如下三方面的功能：嗍 口业务逻辑的运行环境，具体功能包括：管理业务逻辑的生命周期、管理 业务逻辑运行，管理业务逻辑的描述信息。 第l 页 第一章绪论 口互操作机制，具体功能包括：业务层与表示层之间的通信、业务层与数 据层的通信、业务层内部各个业务逻辑之间的通信等。 口公共服务，具体功能包括：查找服务、事务服务、安全服务等。 尽管应用服务器的概念出现的时间并不长，但其地位与重要性迅速被广泛 认可，并得到了产业界和学术界的双重支持。在世界范围内，已经有众多开发 组织正在从事应用服务器的研究工作，已经有多个应用服务器产品面世。这些 应用服务器产品分别针对各自的应用领域，突出不同的特点，为各自领域的应 用系统提供高层次的运行平台。 1 2 1“一卡通”系统概述 第二节项目背景 南开太阳校园“一卡通”系统是为服务高校的数字化管理而开发的软件系 统。在不断地升级和演化的过程中，系统的体系结构同样经历了由两层到三层 的转变。 “一卡通”系统最初采用基于客户机服务器模式的两层结构开发，具体结 构是所有的表示逻辑、业务逻辑和数据操作都集中在客户机之上，数据库管理 系统部署在独立的服务器上。采用这种结构实现的系统在初期满足了将业务逻 辑与数据分离的要求，但随着系统不断地演化、功能不断地复杂、客户端规模 不断地扩大，这种两层的设计模式所固有的安全性能差、可维护性差、不易于 系统集成、消耗资源等不可克服的缺点日益严重聊。 为了克服两层结构的缺点，将基于两层结构的系统改进成基于三层结构， 以适应发展的需要，具体的结构是最顶层为校园“一卡通”j 系统的服务器，向 下连接中间层应用服务器，再向下可以连接校园“一卡通”! 的各个子系统的控 制计算机，采用三层结构的系统结构如图1 1 所示d l 。 第2 页 第一章绪论 1 2 2 问题的提出 图1 l 三层结构的校园“一卡通”系统结构图 在三层结构的“一卡通”系统中，涉及到了应用服务器的设计，但在这种 设计中应用服务器却仅仅起到了管理网络连接的作用，并没有将应用服务器和 部署在服务器上的业务逻辑从根本上分开，它们之间仍然具有紧密的耦合关系， 其结构如图1 _ 2 所示。在这种设计中，应用服务器与业务逻辑虽然被设计成不同 的软件模块，但最后需要被静态链接在一起。采用这种方式将会十分不利于业 务逻辑的修改，即使是对业务逻辑的一点小小的修改，都会导致整个服务器端 软件的重新编译、链接。 第3 页 第一章绪论 一f 噩量嚣 广i _ 卜一 臣圃 厂面_ 1 一 臣圈 i 竺! 卜一 i 釜塑生i 图1 2 已有三层结构“一卡通”系统中应用服务器的结构 第三节论文的主要研究和实现的内容 论文对已有的三层结构的“一卡通”系统的体系结构进行了分析，从软件 互操作的角度对系统中应用服务器进行了深入研究。在此基础上，提出了一种 适用于“一卡通”系统的互操作协议，并给出了使用该协议的客户端服务代理 和应用服务器的设计与实现，从而最终解决了如何实现将应用服务器与业务逻 辑的开发过程分离这一核心问题。论文中的设计将业务逻辑实现为动态链接库， 应用服务器运行的时候将根据客户的请求动态加载这些业务逻辑，并实现业务 逻辑的动态调用。论文中设计的应用服务器的结构如图1 3 所示。 j 玄产， | - - ，一q e 势幽f j 一一i 一 - i 萋繁襞攀 ， 一一一业嚣避舭 量荦蛭蟊夏曛葑照目搬= 蠢* ：， - 卜 寓声抽 i i、l 业并j ! | ! 圳n 。i 图1 3 已有三层结构“一卡通”系统中应用服务器的结构 第4 页 第一章绪论 第四节论文的结构 本文其它部分安排如下： 第二章，分析了实现软件之间互操作的必要技术基础，介绍了互操作体系 结构的概念与分类。 第三章，分析了已有互操作协议的特点和要素，在此基础上提出了适用于 “一卡通”系统的互操作协议。 第四章，针对第三章提出的互操作协议，对应用服务器和客户端服务代理 进行了设计并详细说明了它们的实现方法。 第五章，对论文实现的应用服务器进行了可行性测试和数据完备性测试， 并与目前广泛使用的应用服务器产品j b o s s 的运行性能进行了比较。 第六章，总结与展望。 第5 页 第二章软件互操作体系结构 第二章软件互操作体系结构 由于资源分布的不均匀，软件系统的运行环境也从单机环境发展到了网络 环境。通信技术和计算机网络技术的突飞猛进，为在不同计算机之间传递消息 提供了物理基础。t c m p 及其实现提供了基本的通信机制，但由于网络通信的 复杂性，这种支持远不能满足业务逻辑开发人员的需要，开发人员需要提供更 高层次的支持，而应用服务器则恰好为软件系统组成部分之间的互操作提供了 必要的支持。 第一节互操作体系结构产生的背景 随着计算机技术的发展，软件的运行环境从单机环境发展到了网络环境。 与运行于单机环境的软件不同，运行于网络环境的软件系统所包含的多个组成 部分通常分布于网络的不同结点之上。通信技术和计算机网络技术的突飞猛进， 为在计算机之间传递消息提供了物理基础。t c p i p 及其实现提供了基本的通信 机制。 计算机网络是由多个互连的结点组成的，结点之间需要不断地交换数据与 控制信息。要做到有条不紊地交换数据，每个结点都必须遵守一些事先约定好 的规则。一个协议就是一组控制数据通信的规则。这些规则明确地规定了所交 换数据的格式和时序。这些为网络数据交换而制定的规则、约定与标准被称为 网络协议p j 。 网络协议对计算机网络是不可缺少的，一个功能完备的计算机网络需要制 定一整套复杂的协议集。对于结构复杂的网络协议来说，最好的组织方式是层 次结构模型。计算机网络协议就是按照层次结构模型来组织的。计算机网络体 系结构是网络层次结构模型与各层次协议的集合【5 j 。 2 1 1o s i 参考模型 许多标准化机构积极开展了网络体系结构标准化方面的工作，其中最为著 名的就是国际标准化组织i s o 提出的开放系统互连参考模型o s i ( o p e ns y s t e m 第6 页 第二章软件互操作体系结构 i n t e r c o l l l l e c t i o n ) 。o s i 参考模型将计算机网络分为七层，如图2 1 所示。自下而 上，依次称为物理层、数据链路层、网络层、传输层、会话层、表示层和应用 层。低三层称为通信层，是对通信网而言：高四层称为用户层，是对用户的f6 1 。 业川i 旺 表q 1 z 0 i z 杂；斗j 衰如旺 传辕曩沸蛙 氆嚣咄边异 图2 1o s i 参考模型 上慨， o s i 参考模型各层的功能简述如下：【7 1 ( 1 )物理层：物理层的主要功能是利用物理传输介质为数据链路层提 供物理连接，透明地传输比特流。该层为物理连接提供机械、电 气、功能、规程等特性。 ( 2 )数据链路层：在物理层提供比特流传输服务的基础上，用于在相 邻结点间建立数据链路，传送以帧为单位的数据。本层通过差错 控制、流量控制等，将不可靠的物理传输信道变为无差错的可靠 的数据链路。 ( 3 )网络层：该层的主要任务是通过执行路由选择算法，为进网分组 选择合适的路径。为进网报文提供具体的逻辑信道，并控制通信 网有效运行。 ( 4 )传输层：设立传输层的目的是为网内的通信实体建立端一端差错 控制、顺序控制、流量控制、管理多路复用等。向用户提供可靠 的端一端服务，透明地传送报文。 第7 页 第二章软件互操作体系结构 ( 5 ) ( 6 ) ( 7 ) 会话层：设立会话层的主要目的是提供一种有效的方法，组织和 协调两个会话用户间的对话，并管理他们之间的数据交换。 表示层：表示层主要用于处理在两个通信系统中交换信息的表示 方法。它包括数据格式的变换、数据加密和解密、数据压缩和恢 复等功能。 应用层：应用层是o s i 参考模型的最高层，是直接面对客户的一 层，是计算机网路与最终用户的界面，它为应用进程访问o s i 环 境提供手段，同时为应用进程提供服务。 2 1 2t c p i p 参考模型 在讨论了o s l 参考模型的基本内容后，回至0 现实的网络技术中。t c 肋p 是 2 0 世纪7 0 年代中期美国国防部为其研究性网络a r p a n e t 开发的网络体系结 构。t c p ，i p 参考模型分为四个层次，在下而上，依次为主机一网络层、互联网 络层、传输层、应用层。其中，t c p i p 参考模型的应用层与0 s i 参考模型的应 用层对应；t c m p 参考模型的传输层与o s i 参考模型的传输层对应；t c p i p 参 考模型的互联网络层与o s i 参考模型的网络层对应；t c p i p 参考模型的主机一 网络层与o s i 参考模型的数据链路层和物理层对应。在t c p i p 参考模型中，对 o s i 参考模型的表示层、会话层没有相应的协议。t c p ，i p 参考模型如图2 2 所示。 图2 2 t 咖参考模型 第8 页 毯 崖 帛 酬 腓 嗍 第二章软件互操作体系结构 2 1 3 互操作体系结构的位置 目前，大多数的网络通信都建立在t c p i p 参考模型的基础上。当前的操作 系统几乎都将t c p ，i p 参考模型的实现作为默认的网络软件库。例如：各种u n i x 操作系统中的套接字库s o c k e t o ，各种w i n d o w s 操作系统中的套接字库 w i n s o c k 1 i b 等。如果软件开发人员需要使用t c m p 提供的各种服务，那么无疑 就要使用操作系统提供的套接字编程接口s o c k e t a p i 。 套接字编程接口提供了一组a p l 软件开发人员通过使用a p i 可以在t c p 、 u d p 和i p 的基础上开发应用程序。基于套接字的开发方式较为繁琐，要求对计 算机网络环境有比较深刻的了解，而且这种开发方式的测试和调试十分困难。 特别当服务器需要根据客户的不同请求内容区分不同的处理过程时，这些问题 表现得尤其突出。随着网络技术的发展，人们很快就不满足于直接基于套接字 的开发过程1 4 j 。 造成上述局面的原因在于基于套接字的交互方式层次较低。交互双方进行 的是类似l ，o 操作的过程，不同软件之间需要约定专门的信息格式、数据类型等。 从根本上说，原因在于t c p 仃p 参考模型中没有相应的层次与0 s i 参考模型中的 会话层和表示层对应，因此处理这些问题的任务就落在了使用s o c k e ta p l 的开 发人员的肩上。 在单机环境中，一个软件系统由许多子程序组成，软件的功能主要通过子 程序之间的协作完成。将相同的作用方式应用到新的软件运行环境一网络环境 中，人们开始考虑实现与单机环境类似的在不同结点上应用程序之间的直接调 用。如果一个程序能够直接调用其他结点上的过程，而不必关心底层复杂的通 信细节，那么开发网络环境的应用程序时就可以将注意了集中在更高层次的业 务逻辑上。 由于网络环境存在明显的异构性，网络软件的形态也各不相同，这给它们 之间的协作造成了很大的困难。随着软件应用范围的扩展，人们发现软件之间 的互操作正在成为发展过程中的瓶颈。这正是对互操作技术的研究经久不衰的 原因。 实际上，互操作体系结构对应网络体系结构中的高层协议。互操作体系结 构的出现，是对t c p 仃p 中缺少的会话层、表示层的补充和发展。互操作体系结 构在网络体系结构中的位置如图2 3 所示。 第9 页 第二章软件互操作体系结构 图2 3 互操作体系结构在网络体系结构中的位置 第二节互操作体系结构的概念 所谓软件互操作，就是指异构环境下两个或两个以上的软件实体，尽管它 们实现的语言、执行的环境不同，但它们可以相互通信、协作，以完成某一特 定任务。这些实体包括应用程序、对象、子程序等。互操作体系结构一般采用 客户机服务器模型，服务器为服务的提供者，客户机为服务的使用者。 随着对软件互操作的研究的不断深入，出现了多个不同的互操作体系结构。 通过对这些体系的比较，可以得到它们的一些共性：一个互操作体系结构主要 由互操作协议、互操作接口定义语言和功能查找匹配方式组成。它们之间的层 次、与互操作实现的对应关系，以及与低层协议之间的关系如图2 4 所示1 4 】。 第l o 页 第二章软件互操作体系结构 图2 4 互操作体系结构 低层协议：低层协议是互操作协议所依赖的低层通信机制，目前广泛使用的 是t c p ，也可以使用其它协议。 互操作协议：软件互操作的关键是在相互合作的实体间传递消息，因此需要 约定通信双方之间的消息类型和消息格式，所有这些约定共同构成了互操作 的高层协议。互操作协议解决了软件实体如何合作执行。 互操作接口定义语言：接口是一组相关操作的集合，定义了由服务器提供的 客户可见的那些过程的特征，例如：过程名称、过程参数、参数属性等。互 操作接口是特定于具体实体间交互的约定，接口定义语言是定义约定用的语 言，约定的内容是后续具体交互的依据。 服务查找方式：开发人员并不关心从哪里可以获得接口提供的服务、服务的 具体使用方法等，他们关心的是能否获得需要的服务。因此，服务器的定位、 过程的调用这些具体的工作就成了互操作体系结构的一部分，通常称为服务 查找匹配。 第1 l 页 第二章软件互操作体系结构 第三节互操作体系结构的分类 互操作体系结构依据处理互操作接口间差异的方法不同，大致可以分为以 下两类：1 8 】 基于接口标准化的方法 接口标准化方法的着眼点是统一提供服务的实体接口，对于每个标准接口 所提供的潜在的功能，互操作实体均有一致的理解，这个标准接口由一种规约 语言来定义，从而将互操作组件的接口和具体实现分离开来，这个标准的接口 可以根据客户方和服务方的运行环境，自动地绑定于各自特定的环境，客户使 用这个由标准接口产生的、符合本地环境特点的接口存取服务方服务。 基于接口桥接的互操作方法 接口桥接的基本思想是：互操作实体独立使用各自的接口，通过转换的方 法来处理客户和服务器上互操作组件接口间的差异。客户方的请求接口和服务 方提供的接口可以不是精确匹配，也就是调用操作的实际参数的形式和提供服 务的软件实体的形式参数存在形式上的差异；或者客户方某个对象或过程的功 能需要由服务方多个对象或过程复合来完成，这就需要开发一个描述语言，开 发人员利用这个接口描述语言，说明过程调用的真正参数，以及这些参数是如 何经过重组和转换、匹配目标过程的形式参数，系统在运行时刻根据这个描述 自动产生处理转换的代码，并将客户方和服务方的软件成分结合起来。 根据互操作的软件实体的不同，互操作软件体系结构还可以有如下的分类 方法： 口面向过程的互操作体系结构：客户通过调用服务方的过程来实现互操作，其 目标是使得本地实体在调用远程实体的时候，采用与本地调用相同的调用方 式，就像在本地进行过程调用那样简单。需要注意的是，这里所说的过程与 函数的概念是相同的，它们都可以有参数和返回值，在下文中将不区分过程 与函数。 口面向对象的互操作体系结构：采用了面向对象的方法，将各个软件实体抽象 为不同的对象，并通过对象的相互作用实现互操作。同样，在这种体系结构 中客户可以像访问本地对象一样访问远程对象。 第1 2 页 第- 二章软件互操作体系结构 第四节小结 本章首先分析了软件系统由单机环境发展到网络环境的特点，讨论了网络 体系结构的特点，由此引出网络环境下软件互操作和互操作体系结构的概念， 以及互操作体系结构在网络体系结构中的位置。最后总结了现有互操作体系结 构的分类。 第1 3 页 第三章互操作协议 第三章互操作协议 通过上一章的讨论，我们已经清楚了互操作体系结构的概念及分类。本章 将详细讨论互操作体系结构中的互操作协议与接口定义。 第一节互操作协议的概念 3 1 1 已有的互操作协议 首先，从讨论已有的互操作协议开始，这样可以使我们对互操作协议的概 念和发展过程有一个清晰的了解，更可以使我们总结它们的异同、优缺点和适 用环境。 i i o p 在c 0 砌；a 中，互操作协议采用基于因特网的o r b 间协议i i o p 。1 1 0 p 仅仅 采用少量的、简单的消息就可以支持全部c o r b a 功能，包括对象访问、对象的 动态迁移等。在i i o p 中数据采用公共数据表示，这种表示具有可变的字节顺序 和对齐的数据类型。1 1 0 p 可以映射到任何面向连接的可靠的低层协议上。i i o p 是一个面向对象的协议。 s o a p 在w 曲服务中，互操作协议采用简单对象访问协议s o a p 。s o a p 是一种基 于) 洲l 的协议，因此它天生具有跨平台、跨语言的特性。虽然叫做简单对象访 问协议，在协议中并没有涉及对象的概念，实际上它是面向过程的协议。 3 1 2 互操作协议的要素 通过对已有协议的分析，可以发现互操作协议通常由消息约定、数据表示、 连接管理、低层协议映射组成【4 】。 消息约定 软件互操作的目的是在分布在不同网络结点上的软件实体之问传递消息， 第1 4 页 第三章互操作协议 因此必须约定统一的消息类型和消息格式。基本的消息类型应该包括请求消息、 响应信息、错误报告信息等。 数据表示 在单机环境中，函数之间的数据传递是通过公共运行时堆栈完成的。调用 函数将传递给被调用函数的数据压入堆栈，被调用函数在运行时将数据从堆栈 中取出，在结束时将返回值压入堆栈，调用函数从堆栈中获得返回值。但在网 络环境中，软件实体间不存在公共的运行时堆栈，单机环境中的数据共享方法 也就失去了意义。在不同实体之间共享数据，首先要解决的是如何在实体之间 传递数据，也就是如何在网络上表示数据。一般的做法是在调用方将数据串行 化，使之变为可以在网络上透明传输的比特流，在接收方在将比特流恢复为数 据。 连接管理 调用的发起者和被调用者之间要建立起连接就涉及到连接的管理，其中包 括连接建立、连接撤销等。 低层协议映射 对于复杂问题，人们通常采取的方法是分而治之。互操作协议也不例外， 顾名思义互操作协议关注的问题是如何实现互操作之类的高层次功能，如何实 现网络传输、差错控制、流量控制是低层网络协议所关注的。因此，需要低层 提供怎样的服务、如何将互操作协议映射到低层协议也是需要考虑的。 第二节简单过程调用协议 目前已有的互操作协议有各自的优缺点。s o a p 具有跨平台、跨语言的优越 性，但协议本身的效率不高，s o a p 是以x m l 为基础的，一次调用就要传输一 次) a l 文档，对于简单调用有效数据只占l 文档的很少部分，s o a p 是建 立在其他应用层协议之上的，现在比较广泛的应用是建立在h t t p 协议上，因 此还要考虑h 1 1 甲的开销。o p 协议得到了广泛的应用，但该协议中的某些部 分在“一卡通”系统中并不需要，同样项目中的某些需求在该协议中没有很好 的支持，例如大数据量数据的支持等。以上这些原因促使采用自行设计互操作 协议的方式。根据自行开发协议的特点将其称之为简单过程调用协议，简称为 s p c p ( s i 皿p l ep m c e d u r ec a l lp r ) t o c 0 1 ) a 第1 5 页 第三章互操作协议 根据“一卡通”系统业务逻辑的特点和对性能的要求，s p c p 采用面向过程 的方式。开发人员可以将业务逻辑以过程的形式部署在服务器上，客户机调用 过程提供的服务实现应用功能。下文将从消息约定、数据表示、连接管理和低 层协议映射四个方面详细描述s p c p 。 3 2 1 消息约定 s p c p 定义了五种消息：请求消息、响应消息、拒绝请求消息、关闭连接消 息、错误信息消息。表3 1 列出了上述五种消息。 表3 1s p c p 消息类型 j ：、。、消意奚型! 溪饕蓼萋醋i ：黧：、黔酒箍黼码i ：二瀑 请求消息客户l 响应消息服务器2 拒绝请求消息 服务器3 关闭连接消息客户 4 错误信息消息服务器5 请求消息由客户发起，用来表示客户端希望调用服务的信息。响应消息由 服务器发出，用来表示服务器端业务逻辑的运行结果。拒绝请求消息由服务器 发起，它为服务器提供的拒绝服务的机会，服务器在运行的过程中出于对性能、 资源分配、安全性的考虑需要拒绝某些服务请求。关闭连接消息由客户发起， 该消息用于主动关闭连接方式中，当客户已经完成了所有希望的调用请求，可 以向服务器发出关闭连接消息结束本次连接。错误信息消息由服务器发起，当 服务器收到的消息并不是其期待的类型或消息的格式不正确时会发出该消息。 典型的s p c p 消息由两部分组成：消息头部和消息体。其中，消息头部是必 需的，因为有些消息仅仅由头部信息即可给予完整描述，消息体根据具体的消 息类型是可选的。 所有的s p c p 消息都是由消息头部开始，消息头部长6 字节，具体结构如图 3 1 所示。 第1 6 页 第三章互操作协议 图3 1 消息头部格式 在消息头部中，第一个字段是消息类型，长度为1 字节，取值范围如表3 1 所示。第二个字段是消息标志，长度为l 字节，目前只用到了最低两比特，其 中最低位表示消息中数据表示的字节顺序，第二位表示客户要求的连接方式。 在互操作协议数据的字节顺序是一定要考虑的问题。目前，存在着多种体 系结构的处理器产品，这些处理器产品之间并不兼容，其中一个主要方面就是 字节顺序。假设一个整数需要两字节存储，那么在存储器中，这两个字节中表 示整数高位的那个字节是存储在连续两字节的低地址字节还是存储在高地址字 节，相应地，字节顺序也就相应分为大端方式和小端方式。在s p c p 中，0 表示 小端方式1 表示大端方式，并且字节顺序是由客户端确定的，也就是说，在一 次调用中无论服务器采用何种字节顺序，字节顺序标志的取值由客户决定并保 持不变。连接方式在连接管理一节中详细讨论。 最后一个字段是消息长度，长度为4 字节。该字段表示除消息头部以外的 消息体的字节数，因此，消息体最大长度为2 ”1 字节。 下面分别介绍每一种类型消息的格式。 1 请求消息 请求消息代表了对服务器提供服务的调用。请求消息由消息头部和消息体 组成。由于在s p c p 中所有消息都包含消息头部，而且消息头部各字段的含义和 取值在上文已详细说明，所以下文不再赘述。 在s p c p 中，服务器以模块为单位实现对过程的管理。可以说模块是过程的 容器，在一个模块可以包含若干过程，每个过程实现了某一个服务功能。开发 第1 7 页 第三章互操作协议 人员可以通过向服务器加入模块实现新服务的添加，在客户端看来服务器端提 供了许多服务，这些分别属于不同模块的服务就是客户调用的基本单位，每一 个请求消息就是对一个服务的调用，对服务调用信息的编码组成了请求消息的 消息体。消息体的格式如图3 2 所示。 图3 2 请求消息的消息体格式 模块名长度字段的长度为1 字节，该字段指出被请求服务所在模块的名称 长度，取值为名称字符串中字符的个数，因此，模块名长度不能超过2 5 5 个字 符。 模块名字符串字段的长度为模块名长度字段中数值加1 ，该字段指出被请求 服务所在的模块的名称字符串，以0 结束。 服务名长度字段的长度为1 字节，该字段指出被请求的服务名称长度，取 值为名称字符串中字符的个数，因此，服务名长度不能超过2 5 5 个字符。 服务名字符串字段的长度为服务名长度字段中数值加1 ，该字段指出被请求 的服务名称字符串，以、o 结束。 参数部分是对服务对应实现过程中涉及的参数的编码，它的长度和内容随 所请求服务的不同而不同，因此在图3 2 该字段用虚线标出。该字段的具体内容 将在数据表示一节中详细描述。 2 响应消息 响应消息是服务器对客户调用请求的响应。响应消息由消息头部和消息体 组成。响应消息的消息体如图3 3 所示。 图3 3 响应消息的消息体格式 第1 8 页 第三蕈互操作协议 服务器运行结果字段和服务运行结果字段称为请求结果字段，该字段的长 度为4 字节。其中服务运行结果字段返回过程的运行情况，该值由过程的返回 值提供，由过程的开发人员定义该值的含义。服务器运行结果字段返回过程运 行期间服务器的运行情况，该值由服务器提供，具体数值含义如表3 2 所示。 如果服务器在已经部署的模块中找不到请求消息中指定的模块，那么服务 器运行结果将返回1 ；如果服务器在模块中找不到请求消息中指定的服务，那么 服务器运行结果将返回2 ；如果请求消息中的调用参数与模块安装使用的配置文 件不符，那么服务器运行结果将返回3 ；如果过程运行结束的返回值不为0 说明 过程运行过程中出现错误，那么服务器运行结果将返回4 ，这时应该继续查看服 务运行结果字段的数值得到具体错误类型；当服务正常结束时，服务器运行结 果将返回0 。 表3 2 服务器运行结果取值 月蘑基运礴鞋：? 鞭冀襄：、翼； 0 服务器正常 l 模块不存在 2 服务不存在 3 调用参数不匹配 4 服务运行异常 参数部分是对服务的实现过程中包含的参数的编码，它的长度与内容随所 请求服务的不同而不同，因此在图3 3 该字段用虚线标出。该字段的具体内容将 在数据表示一节中详细描述。 3 拒绝请求消息 拒绝请求消息用于通知客户，服务器由于某种原因拒绝了客户的请求消息。 客户发出的请求消息对于服务器来说是随机的，可能在某一个时段中服务器要 处理大量的客户请求。如果这些请求的数量超过了服务器能够承担的范围，这 种情况对服务器是不安全的。可以想象到的一种情况是服务器可以使用的地址 空间被请求消息耗尽，服务器无法申请新的内存来完成正在执行的请求。新请 求无法得到执行，正在执行的请求无法结束，这样就形成了死锁。因此，当服 务器负担过重时应该拒绝客户的新请求消息。拒绝请求消息只包含消息头部。 第1 9 页 第三章互操作协议 4 关闭连接消息 在主动关闭连接方式种，关闭连接消息用于通知服务器客户完成了所有需 要的服务请求，并希望关闭连接。客户发出关闭连接请求后，就会关闭与服务 器的连接。关闭连接消息只包含消息头部。 5 错误信息消息 当服务器收到的消息并不是期待的类型或消息的格式不正确时发出错误信 息消息。错误信息消息只包含消息头部。 3 2 2 数据表示 在软件互操作的过程中，服务器和客户之间需要互相传递数据，s p c p 将这 些数据定义为过程的参数，客户到服务器的数据对应过程的输入参数，服务器 到客户的参数对应过程的输入参数。s p c p 定义了1 1 种数据类型，过程的参数 可以是这些数据类型中的任何一种。这些数据类型的名称、含义、与c ，c + + 类型 的对应关系如表3 3 所示。将编码1 至1 0 的数据类型称为简单类型，p o i n t e r 类 型称为复杂类型。 表3 3s p c p 数据类型 摹添p 妻蘧瓣妾童。!含义：jj 墨j 迁黼蒸纛漩镞垂荫为蘸誊 i n t e g e r 8 8 位有符号整数 1c h a r i n t e g e r l 61 6 位有符号整数 2s h o r t i n l e g e r 3 2 3 2 位有符号整数 3i m i n t e g e r 6 4 6 4 位有符号整数 4 l o n g u n s i 粤删i n t e g e r 8 8 位无符号整数 5 u m i g n e dc h a r u n s i g n e dh l t e g e r l 6 1 6 位无符号整数 6 u i l s i g n e ds h o n u i l s i 印c di i l t e g e r 3 2 3 2 位无符号整数 7 m l s i g n e di n t u n s i 髀di n t e g e 耐 6 4 位无符号整数 8 u m i 卸e d1 0 n g f l o a t 单精度浮点数 9n o a t d o u b l e 双精度浮点数 1 0d o u b l e p o i n c e r 内存块的抽象 1 1 各种内存结构 第2 0 页 第三苹互操作协议 s p c p 简单数据类型的含义比较容易理解，它们与c c + + 语言中的定义一致。 需要详细描述的是p o i n t e r 类型。p o i n t e r 是对一块连续的内存空间的抽象表示， 也可以理解为对指针类型，通过设计这种数据类型可以在客户和服务器之间传 递任意大小的内存块。p o i n l e r 的二进制表示是一个结构体，在结构体中并不包 含所指向的内存块。它的定义如图3 4 所示。 内靠块挺缱 内存胰肚 图3 4p o i n t e r 类型结构 p o i n t e r 结构在内存中占用8 字节，前4 字节存储本结构所指内存块的长度， 后4 字节存储本结构所指内存块在本地地址空问的首地址，通过这些信息可以 唯一确定地址空间中的一块内存。p o i n t e r 结构的c 语言定义如以下程序片段所 示。 t y p e d e f s t r u c t u n s i 印e di n tl e n 群h ； 加e n g t h 为内存块的长度 v o i d + p 廿；，p 仃为内存块首地址 p o i l l t e r ； 引入p o i n t e r 类型的目的是增加s p c p 的灵活性和数据完备性，在很多应用 中不仅需要简单类型的数据，例如字符串、图像信息等都可以存储在一块内存 中，进而由p o n c r 类型表示。为了使s p c p 尽可能简单，在s p c p 中并没有引 入数组、结构体、类等复合数据类型，对于这些类型都可以通过p o i l l t e r 类型表 示，只是复合类型的字段要由过程的开发人员自行划分、处理。 s p c p 具有可变的字节次序。消息在具有相同字节顺序的机器间传输时不必 改变字节序；当消息在两个不同字节顺序的机器间传输时，可以由消息发送者 决定消息字节的顺序，而消息接收者负责交换接收到的数据的字节顺序以便匹 配它的本地字节序。s p c p 消息的消息头部中包含指出正确字节顺序的标记。 定义了数据类型之后，数据表示另一个需要解决的问题是如何在客户与服 第2 l 页 第三章互操作协议 务器之间传输这些数据。要在客户和服务器之间传输数据客户端需要将数据的 本地表示形式变换为可以在网络上传输的字节序列，并将这个序列发送到服务 器，这个过程称为序列化。服务器收到这个序列后将数据从字节序列变换为服 务器的本地表示形式，这个过程称为解序列化。通过定义在客户和服务器之间 传输的字节序列的统一格式就可以实现在不同体系结构间的透明传输。从前文 中可以