（测试计量技术及仪器专业论文）分布式远程虚拟实验平台的研究和开发.pdf

摘要 摘要 随着网络技术的蓬勃发展，计算机网络技术应用到各个学科当中，于是产生 了分布式的实验操作平台。另外结合物理的学科特点以及实验在教学及科研中的 重要地位，提出了构建分布式远程虚拟实验平台的课题研究。 本论文针对目前社会上一些虚拟实验平台存在的问题，结合物理教育教学的 特点，分析了远程分布式的解决方案的优劣性，提出了以w e bs e 九r i c e 技术作为 我们实验平台的分布式远程解决方案，设计制作了分布式远程虚拟试验平台系 统。该系统由服务器和客户端两部分构成。服务器端充分考虑到多客户同时进行 实验的负载均衡问题，利用w e b l o g i c 构建服务集群，集群之上部署w e bs e i c e ， e j b 以及其他一些服务，安全可靠。客户端考虑到不同的用户在不同操作系统平 台之下进行实验，于是采用跨平台性好的j a v a 语言进行开发，并且建立了完善 的客户认证机制，安全方便。客户端平台在设计时，运用多种设计模式，因而框 架结构更加合理，并且有着很强的扩展性。 在构建以及实现分布式远程虚拟试验平台的框架之后，在客户端又设计制作 了远程数据处理实验，傅立叶变换演示实验以及虚拟电学实验，三个实验各有特 点，充分验证了虚拟实验平台框架结构的正确性。 在论文的后期，针对物理科研教学中的远程控制方面的实验，提出了基于 l a b e w 的d a t a s o c k 乩技术的解决方案，并且在虚拟实验平台的框架中，构建了 数据的转发控制模块。 由于w e bs e r v i c e 技术处于探索阶段，随着w e bs e i c e 技术的成熟，应逐步 完善系统平台，因而在论文的最后提出了改进平台的一些设想。 关键词：w 曲s e n ，i c e ，虚拟实验室，s o 印，电学实验，l a b e w a b s n 瞅 a b s t r a c t w i t h 廿l ed e v e l 叩m e n to f 廿1 ei i l t e i n e 乞m ec o m p u t e rf e c h n o i o g yi s 印p l i e d 幻 c v 哪w h e r e ，a n dt 1 1 ed i 鲥b u t e de x p c r i m e n tp l a 仃。彻s w e r er a i s e d b e c a u s et 1 1 e c h a r a c t e r i s t i co fp h y s i c sa n d l a te x p e r i m e t sp l a y e di m p o n a 眦r o l e smt e a c l l i 】唱a 1 1 d s c i e m i f i cr e s e a r c h ，w ep u tf o m 锄d 血es u b j e c to ft 1 1 ed i s m b u t e dv i 咖a le x p 出e n t p l a t f o r m im a d et l l ew e bs e r v i c et c c h n o l o g y 嬲d i s 扛i b u t e ds o l 啦i o nt oc o m m u m c a t ea f t c r a i l a l ) 嘣n gs o m ed i s m b u t e ds o l u d o n t h ed i s m b u t e d 啊删e x p e r i m e n tp l 砒f o r mw 够 m a d eo fs e c ra i l dc i i e m w 曲s e r v i c e s ，e j b “i c e sa i l ds o l eo m e rs e r v i c e sw e r e d 印l o y e do n 也ew e b l o g i cc l u s t e r i ti ss a f ea n dr e l i a b l e c 0 1 1 s i d e r e dd 妇l t1 l s e r s c 阳了o ne x p e r i m e m s 硼d e rd i 脓r e n to p e r a t i n gs y s t e mp 1 曲衄s ，1d e s i g n e d 趾d d e v e l o p e d 也ep l a t f b m 、v i mj a v a 删c hi sa9 0 0 dc o m p u t e i 1 趾g i l a g ct od e v e l o p s o f t 呲i nd i f f 醯e n ts y s t e mp l a t f o m a t 血et i r n et l l a tid 朗i g n e d 也ed i 蚵b u t e d v i m l a le x p e r i m e n t sp l a 仃0 蛐呜l 印p l i e ds o m ed e s i g np a t t e m st oi t ，s u c h 嬲a b s 协l c t f a c t o 啊s i n 舀e t o na r l ds oo n 1 1 - e r e f o r et h cp l a t f o n ns m l c t u r ei sm o r er e a s o n a b l e a 盘e rt 1 1 ed i g 啊b u t e dv i m l a le x 脚e n tp l 甜确 nh a v eb c e nd e s i 印e da n d d e v e l o p e d ，id e 啦皿e dt b r e ee x p 甜m e n t si nt h ec h e n t ，s u c ha sf f te x p e r i m e l l t ， e l e c t i i c 时e x p e r i m c n ta 1 1 ds oo n s t u d e m sc a i le a s i l yc a n yo u tt l l ee x p e si n t h e i f0 w n d o 衄 a tt 1 1 es a i n et i m e ，is o l v e ds o m eq l l e s 廿o n si nt h ee x p 甜m e i l to fm ed i g 廿i b u t e d c o m r o lo n 血er e s e a r c h i n ga n dt e a c l l i 唱o fp h y s i c s 诵md a t as o c k e tt e c h n 0 1 0 9 yo f 厶6 倒 a t1 a s t ，b e c a u s e 、e bs e r v i c ei ss t i l la tt l l es t a g eo fe x p l o r i n g ，t h e r es m la r es o m e q u e s t i o i l si n 也ed i s 砸b u l e dv i m a le x p e r i m e n tp l a t f b 姗w is h o u l dg o0 nw c 幢i n go n i t a tt 1 1 ee n do f 也et 1 1 e s i s w h a ts h o u l db ed o n ei i lt h ef i i t u r ew 够w r i t t e n k e y w o r d s ：w e bs e r v i c e ，r h l a le x p e r i m e n t ，s o a p ，e l e 砌c se x p e r i m e 鸲l a b e w 1 1 研究开发背景 第一章绪论 随着计算机科学技术的迅猛发展，i n t e r n e t 已经成为世界上覆盖面最大， 规模最广，资源最丰富的计算机信息网络。i n t e r f l e t 极大的推动了世界科学技 术的发展和传播，展示了信息网络对科研发展的巨大的推动作用。当前，科研项 目日渐复杂，规模日益巨大，很多项目需要跨学科大规模的合作才能得到有效的 解决；现代科研活动耗资巨大，实验设备成大型化趋势，造价昂贵，因此也迫切 需要热享实验设备来降低科研成本；另一方面信息网络的发展，极大地增强了科 研人员交互，协作和资源菇享的能力，为不同领域的科研人员提供了更有效的手 段，能更好的面对信息激增所带来的挑战。在此背景下，虚拟实验室概念应运而 生。 虚拟实验室( v j 巾l a ll 8 b o m t o r y ) ，也叫做“合作实验室( c o l l a b o r a t o r ) r ) ”， 最早在1 9 8 9 年由美国u i l i v e r s i t y o f r g 嘶a 的啪l i 釉w 【d f 教授提出，用来描述 一个计算机网络化的虚拟实验室环境。他致力于构建一个综合不同工具和技术的 电子化，网络化的科学研究集成环境。在这个环境里，科学家们可以非常有效的 利用地理上分布的各种资源来从事科研活动。w i l l f 形象的将虚拟实验室称为“无 墙的研究中心”。在虚拟实验室中，科研人员不管其地理位置分布如何，都能共 同从事科研，与同事们互相交流，使用仪器，共享数据与资源，在数字式图书馆 中存取信息，共同撰写研究报告等。 随着计算机技术和互联网技术的发展，虚拟实验室技术也经历了很大的变 革，发展和应用，促进了科研生产的发展，尤其是在高等学校中的应用，极大的 推动了高等学校的实验教学的发展。目前，全球和多高等学校设计并实现了基于 虚拟实验室技术的高等实验教学系统。如北京邮电大学的远程网络实验系统，韩 国k o n g g l l k 大学的基于互联网的互动虚拟实验室，以及大连理工大学的基于 i n t e m e t 的远程虚拟实验室系统等等。 另一方面，众所周知，实验是物理科研和教学中重要的一个非常重要的环节， 理论的提出需要实验结果来支持，新的科技产物的实用性也需要实验来证明。但 是有些实验是具有相当的危险性的，如果操作不当，不但不能取得成果，也会对 操作者的生命安全或者周围环境造成威胁；有些实验所需的器材相当贵重，或者 极其不易获得，或者在实验中的损耗相当大，这些都会提高实验的成本，增大实 验难度；另外由于同前学生的日益增多，而实验设备就显得相对短缺。而在计算 机的操作平台上进行的虚拟实验，不但能够克服以上的问题，还能够实现对原子 物理实验、化学实验等一些微观世界的模拟，对牛顿力学世界、数学环境等一些 抽象概念的模拟。在真实的实验操作之前进行虚拟实验，对于降低实验成本，增 大实验安全系数，以及获得正确的实验结果都会起到重要作用。 同时，虚拟物理实验的操作界面可以放在网络上运行，不同的客户端都可以 登陆进行实验操作，能够实现异地的实验人员对同一个实验操作的合作，交流以 及及时的解决实验中的各种问题。还有效的解决学生多，实验设备相对短缺的问 题，这是普通的实验过程所无法达到的。 综上所述，在网络技术以及虚拟实验室技术快速发展的背景下，结合物理自 身的一些特点，提出了建立分布式远程虚拟实验平台的研究课题。 1 2 论文工作 结合物理的学科特点，针对目前其他院校的虚拟实验室中存在的一些问题， 诸如用户不能自定义实验，无法将自己开发的实验加入到虚拟实验室平台中，无 法绕过防火墙以及安全性等一系列问题，采用面向对象和组件技术，设计完成了 分布式远程虚拟实验平台系统的开发。 由于用户可能会在各种异构平台上进行操作，而j a v a 具有天生优良的跨平 台特性，而因在论文的开发过程中，采用了j a v a 语言进行系统的开发工作，实 现了该平台系统的操作系统无关性。该平台系统分为客户端和服务器两个部分。 服务器端采用w e b l o g i c8 1 作为服务器容器，构架集群服务，部署w e b s e r v i c e s 服务，适用于多种语言开发的客户端进行调用，增加了系统的可维护性以及扩展 性，集群服务则可以有效地进行均衡负载，无损关机以及升级维护等。客户端利 用j a v a 实现了一个实验平台的框架，可以加载虚拟实验，充分利用服务器端部 署的服务进行工作。客户端可以根据需要选择自己所需要下载的实验部分的组件 2 进行安装，有效的减少了网络流量。利用x 珂1 配置文件进行实验室平台的动态生 成，方便不同用户的根据不同的需要缎建自己的虚拟实验室。在远程操作上，采 用s o a p 协议，可以安全的与服务器端进行通讯。 在完成了虚拟实验室平台的框架设计搭建工作后，设计完成了分布式虚拟电 路实验，傅立叶变换实验以及远程数据处理实验的开发，通过这些实验，进一步 验证了虚拟实验平台框架的正确性与可行性。 此外，针对在物理实验教学中利用l a b v i e w 进行远程控制实验的需求，对 l a b v i e w 的远程控制技术进行了分析，提出了基于d a t a s o k c e t 技术的远程控制 解决方案，针对利用彳c p i p 进行远程控制中存在的阔题以及需要，作了代理服 务器设置以及数据转发，数据日志以及数据控制模块，提高了原有实验数据转发 以及管理的效率。 1 3 论文的组织结构 本论文分为六章： 第一章为绪论部分，简要介绍了虚拟实验室的意义，描述了论文的研究内容 以及完成的工作。 第二章为分布式远程解决方案的确定，介绍了几种常见分布式的解决方案， 以及他们各自的优缺点，确定系统的分布式解决方案。 第三章程序的组成结构，包括服务器端和客户端两部，服务器端对系统的服 务器端的设计和开发进行了详细的介绍，介绍了w e b l o g i c 下集群服务以及 e j b w 曲s e r v i c e 的部署工作；客户端自动配置实验内容等 第四章介绍了客户端的具体的实验，包括傅立叶变换实验，远程数据处理实 验以及电学电路实验，重点介绍了电路实验的完成。 第五章介绍了l a b v i e w 远程控制的相关内容，提出了利用l a b 啊e w 建立远程 控制的解决方案以及在利用t c p 协议进行数据传输的过程中代理转发控制功能 模块的实现以及介绍。 第六章为总结和展望，总结了论文的工作，展望了进一步的研究方向。 分布式远程解决方案的确定 第二章分布式远程解决方案的确定 在第一章中，提到系统平台采用的是分布式对象技术，分布式对象技术主要 是在分布式异构环境下建立应用系统框架和对象构件，在应用系统框架的支撑 下，开发者可以将软件功能包装为更易管理和使用的对象，这些对象可以跨越不 同的软硬件平台进行互操作。但是目前分布式的远程解决方案有很多，目前主要 的分布式互操作标准有0 m g 组织的c o r b a 标准，m i c r o s o f t 的d c o m 标准，s u n 公司的r m i e j b 标准以及最新发展起来的w e bs e r v i c e 等等，究竟在我们的系统 平台中应该用那种分布式对象技术或者说哪一种分布式对象技术适合于我们 呢? 下面分别论述分布式对象技术的体系结构，并对几种标准加以详细的比较和 综合比较，并最终确定分布式远程解决方案。 2 1 几种分布式远程解决方案的介绍 2 1 1c o r b a 简介 公共对象请求代理架构( c o 砌o no b j e c tr e q u e s tb r o k e ra r c h i t e c t u r e ， c o r b a ) 是对象管理组实现分布式计算节点间的互操作性的规范。它的目标是定 义一个架构，该架构能允许不同种类的环境进行对象级通信，而无需考虑是谁设 计了分布式应用程序的两个端点。 c o r 队1 1 由对象管理组( 0 b j e c tm a n a g e m e n tg r o u p ，o m g ) 于1 9 9 1 年提 出。它定义了允许客户机服务器对象在对象请求代理( 0 b j e c tr e q u e s tb r o k e r ， o r b ) 的特定实现中相互作用的接口定义语言( i n t e r f a c ed e f i n i t i o nl a n g u a g e ， i d l ) 和应用程序编程接口( a p p l i c a t i o np r o g r a m i n gi n t e r f a c e s ，a p i ) 。0 r b 是在分布式对象间建立请求者一提供者关系的中间件。 c o r b a2 o 于1 9 9 4 年1 2 月被采用，它通过指定来自不同厂商的0 r b 如 何相互操作解决了互操作性问题。 c o r b a 在该体系结构中主要描述了以下内容： 4 分布式远程解决方案的确定 ( 1 ) 接口与i d l 语言 接口是c o r b a 系统中一个非常重要的概念，因为它代表了对象的服务能力， 为客户提供了操作对象的唯一方法。简单的说，接口就是一组相关函数的集合， 接口中每一个函数都给出了详细的说明，包括函数名、参数个数、参数类型、返 回类型以及可能抛出的异常。必须指出的是接口只定义了函数的原型，并没有给 出具体的实现，这就留给开发者足够的灵活性来提供他们自己的函数实现。接口 是通过一种中性的接口描述语言( i d l ，i n t e r f a c ed e s c r i p t i o nl a n g u a g e ) 来 定义的。虽然i d l 语言只提供了被o r b 操作的对象的概念框架，但是o r b 在运行 时并不需要i d l 的源代码。只要桩例程或运行状态下接口库中的等价信息是可用 的，o r b 就能通过特定的方式完成其功能。 ( 2 ) 桩和构架 桩( s t u b ) 可以看成是实际对象在客户进程中的映像，其中的接口必须是预 先定义好的，因此它为客户提供了一种静态的调用方式。与桩相对应的构架 ( s k e l e t o n ) 为服务器提供了一种静态的实现方式。i d l 编译器翻译描述对象接 口的i d l 文件，生成对应具体编程语言的i d l 桩和i d l 构架。桩负责将客户请求 进行编码，发送到对象实现端，并对收到的结果进行解释，然后把结果或异常返 回给客户。与此相反，构架对客户的请求进行解码，定位目标对象和请求执行的 对象方法，激活该方法，然后把结果或异常信息编码返回给客户端。 ( 3 )动态调用接口和动态构架接口 与桩和构架不同，动态调用接口( d i i ，d y n 锄i ci n v o c a t i o ni n t e r f a c e ) 和动态构架接口( d s i ，d y n a l i l i cs k e l e t o ni n t e r f a c e ) 提供了动态调用的方式 和动态实现的方式，它们使得用户可以在事先不知道对象接口信息的情况下通过 查询接口库或采取其它手段动态地获得对象接口信息，然后使用o r b 核心接口中 的d i i 动态调用方法构造客户请求并发送到对象实现。在对象实现方可以使用 d s i 的动态分发机制处理客户方的请求。与静态方式相比，动态方式提供了很大 的灵活性，但是它的工作效率没有静态方式高。另外，实现系统的接口大多可以 预先确定，所以大部分情况下都是采用静态方式。 客户方与服务器方所采用的方式并不一定要一一对应，也就是说，客户方支 持静态和动态两种调用方式，服务器方也支持静态和动态两种实现方式，经过组 分布式远程解决方案的确定 合得到的四种方式都可能出现，例如，客户方使用静态调用方式，而服务器方使 用动态构架接口是允许的，反之亦然。 ( 4 )0 r b 核心和对象适配器 与u n i x 的实现机制相类似，c 0 r b a 规范将那些相对固定的、单一的功能提 取出来交由o r b 内核实现以保证它的可靠性、高效性与可重用性。作为整个c o r b a 系统的基础，o r b 内核通过屏蔽诸如服务器位置、实现方式、通信协议等具体细 节为客户方与服务器方之间的通信提供了透明的传输机制。当前的应用系统存在 着各种不同的对象实现方式，例如可执行程序、面向对象的数据库等，他们有不 同的定位对象、解释对象、激活对象的方法。因此，如果将现存的所有对象实现 的解决方案都包含在o r b 内核中，它必将非常庞大、冗余并且难以移植。为了确 保o r b 内核的高效与可移植性，一个称为对象适配器( 0 m a ) 的中间层加入到o r b 与对象实现之间。定位目标对象的任务从0 r b 内核中分离出来交给对象适配器来 完成。 o r b 将收到一条调用消息，来为注册的对象调用一个特定的方法。o r b 截获 这条消息，并负责搜索一个能执行该请求的对象，将参数传递给它，调用它的方 法，然后返回结果。理论上，请求节点无需知道对象的位置、它的编程语言、它 的操作系统或不属于对象接口的一部分的任何其它系统方面的信息。 接口用一系列方法在外部把c o r b a 对象表现出来。一个对象引用可以识别 对象的一个特殊实例。c o r b a 对象的一个客户程序获取了其对象引用，并将它用 作句柄进行方法调用，就好像对象是位于客户程序的地址空间中一样。o r b 负责 搜索对象的实现所需要的所有机制，让它做好接收请求的准备，随后将请求传达 给它，并将回应( 如果有的话) 送回客户程序。 2 1 2d c o m 简介 d c 0 m 是m i c r o s o f t 的c 叫( 组件对象模型，c o m p o n e n t0 b j e c tm o d e l ) 的 分布式扩展，它在d c er p c 的顶端建立了一个对象远程过程调用( o r p c ) 的层 来支持远程对象。c 伽服务器能创建多对象类的对象实例。一个c 。 f 对象可以 支持多个接口，每个接口代表对象的一种不同的视图或行为。一个接口由一套功 能相关的方法组成。c o m 的客户程序通过获取指向一个对象接口的一个指针，并 6 分布式远程解决方案的确定 通过该指针来调用方法以实现与c o m 对象之间的互相作用，就好像对象驻留在 客户程序的地址空间中一样。c o m 指定任何接口都必须遵循一个标准的内存规 划，这与c + + 的虚拟函数表相同。由于该规范是二进制级别的，因此它允许集 成可能用不同编程语言如c 十+ 、j a v a 和v i s u a lb a s i c 等编写的二进制组件。 d c o m 的结构 d c o m 是组件对象模型( c 0 m ) 的进一步扩展。c o m 定义了组件和它们的客户 之间互相作用的方式。它使得组件和客户端无需任何中介组件就能相互联系。客 户进程直接调用组件中的方法。 在现在的操作系统中，各进程之间是相互屏蔽的。当一个客户进程需要和另 一个进程中的组件通讯时，它不能直接调用该进程，而需要遵循操作系统对进程 间通讯所做的规定。c 0 m 使得这种通讯能够以一种完全透明的方式进行：它截取 从客户进程来的调用并将其传送到另一进程中的组件。 当客户进程和组件位于不同的机器时，d c o m 仅仅只是用网络协议来代替本 地进程之间的通讯。无论是客户还是组件都不会知道连接它们的线路比以前长了 许多。 c 0 m 运行库向客户和组件提供了面向对象的服务，并且使用r p c 和安全机制 产生符合d c o m 线路协议标准的标准网络包。 2 1 3 肼i e j b 简介 r m i 是一个分布式对象模式。它使得使用j a v a 开发分布式程序更加容易。 由于不需要设计协议使得使用r m i 开发分布式程序比使用s o c k e t 更加容易。在 r m i 里面设计者就象在调用一个本地的类的方法一样，而实际上是在调用的时候 相应的参数被发送到远端的对象和然后被解释。最后结果返回给调用者。 一个删i 应用的流程 使用r m i 开发一个分布式应用包括如下几个步骤 1 ) 定义一个远端的接口 2 ) 实现这个远端的接口 3 ) 开发一个服务端，有3 件事服务端需要去做： 创建一个r m i s e c u r i t y m a n a g e r 实例，然后安装它。 7 分布式远程解决方案的确定 创建一个远程对象的实例( 这个例子中是f i l e i m p l ) 使用r m i 注册工具来注册这个对象。 4 ) 开发一个客户端 5 ) 生成s t u b s 和s k e l e t o n s ，运行r m i 注册器，服务端和客户端。s t u b 是客 户端的代理而s k e l e t o n 是服务端的框架 使用m i r e g i s t r y 或者s t a r tr m i r e g i s t r y 命令来运行r m i 注册工具到 w i n d o w 系统的默认的端口上，要运行i i f i 注册工具在一个其他的端口的话使用端 口参数。 蹦i 直接把分布式对象模型嵌入到j a v a 语言内部，使得j a v a 程序员可以自 然地编写分布式程序，不必离开j a v a 环境，或者涉及c o r b ai d l 以及j a v a 到 c o r b a 的类型转换。然而r m i 不遵守c o r b a 标准，基本上是j a v a - t o j a v a 技术， 它需要客户方程序和服务方程序都用j a v a 编写，难以实现与其它语言编写的对 象之间的互操作。 e j b 并不是一个产品，它是j a v a 服务器端服务框架的规范，软件厂商根据它 来实现e j b 服务器。应用程序开发者可以专注于支持应用所需的商业逻辑，而 不用担心周围框架的实现问题。e j b 规范详细地解释了一些最小但是必须的服 务，如事务，安全和名字等。软件厂商根据这些规范要求以保证一个 e m e r 口r i s eb e a n 能使用某个必需的服务。规范并没有说明厂商如何实现这些服务。 这使得通过阅读规范来学习剧b 更加困难，因为它允许厂商在不牺牲核心服务 的可移植性的前提下来提供一些增强功能。 e j b 体系结构 e j b 服务器是管理e j b 容器的高端进程或应用程序，并提供对系统服务的访 问。e j b 服务器也可以提供厂商自己的特性，如优化的数据库访问接口，对其他 服务( 如c o r b a 服务) 的访问，对s s l 3 0 的支持等。一个e j b 服务器必须提 供对可访问j n d i 的名字服务和事务服务支持。一些可能的e j b 服务器的例子如： 数据库服务器 应用服务器 中间件服务器 e j b 容器是一个管理一个或多个e j b 类实例的抽象。它通过规范中定义的 8 分布式远程解决方案的确定 接口使e j b 类访问所需的服务。容器厂商也可以在容器或服务器中提供额外服 务的接口。 现在没有e j b 服务器和e j b 容器间接口的规范。因为目前容器通常由e j b 服务器来提供，所以一旦接口标准化了，厂商就可能提供可以在任何兼容的e j b 服务器上运行的容器。 h o m e 接口列出了所有定位、创建、删除e j b 类实例的方法。h o m e 对象是 h o m e 接口的实现。e j b 类开发者必须定义h o m e 接口。容器厂商应该提供从h o m e 接口中产生h o m e 对象实现的方法。 远程接口( r e m o t ei m e r f a c e ) 列出了e j b 类中的商业方法。e j b o b j e c t 实现远 程接口，并且客户端通过它访问e j b 实例的商业方法。e j b 类开发者定义远程接 口，容器开发商提供产生相应的e j b o b j e c t 的方法。客户端不能得到e j b 实例的 引用，只能得到它的e j b o b j e c t 实例的引用。当客户端调用一个方法，e j b o b j e c t 接受请求并把它传给e j b 实例，同时提供进程中必要的包装功能。客户端应用 程序通过h o m e 对象来定位、创建、删除e j b 类的实例，通过e j b o b j e c t 来调用 实例中的商业方法。客户端可以用j a v a 来编程，通过j a v a 砌小来访问访问h o m e 对象和e j b 0 b ! i e c t ，或用其他语言编程并通过c o r b a i i o p 访问，使得部署的服务 器端组件可以通过c o 砌认接口来访问。 2 1 4w e bs e r v i c e 简介 w e b 服务技术组件是一套开放的规范。组件的基本部分包含h t t p 、x m l 、 s o a p 、w s d l 、u d d i 以及w s f l 。这部分的基础是m p ，它是一个被广泛运用的、 类似r p c 的简单协议，并且是防火墙友好的。接下来，是】( m l 中的通用数据表 示法语言，它同样被广泛使用。s o a p 是一个基于x h i l 的消息传递协议，它不确 定平台及语言。它同时支持消息传递和请求响应通信模型。与c o r b a 和d c 0 m 一样，它需要一个i d l 。它所使用的w s d l 是一个基于】( m l 的服务i d l ，定义 了服务接口和其实现特征。w e b 服务技术组件提供了s o a p 作为映射应用程序对 象到网络协议的开放标准0 r p c 。尽管s o a p 不受特定的传输协议的约束，h t t p 还是成为了早先在s o a p 采纳者中最受欢迎的协议。使用h t t p 时，s 0 a p 信封 使用x m l 作为请求和响应参数的编码方案。s o a p 消息实质上是一个遵循s o a p 分布式远程解决方案的确定 编码规则的h t t p 请求和响应。s o a p 端点就是一个基于h t t p 的、识别方法调 用目标的u r l 。与c 0 r b a 一样，s o a p 并不要求一个特定对象被连接到给定的端 点上。相反，需要由实现者来决定如何将对象端点标识符映射到服务器端的对象 上。在s o a p 中检查方法名称的名称空间u r i 与在d c o m 或c o r b a 中检查方法 名称的接口i d 在功能上是相同的。 w e bs e r v i c e s 体系结构是面向对象分析与设计( 0 0 a d ) 的一种合理发展 ( 1 0 9 i c a le v 0 1 u t i o n ) ，同时也是电子商务解决方案中，面向体系结构、设计、 实现与部署而采用的组件化的合理发展。这两种方式在复杂的大型系统中经受住 了考验。和面向对象系统一样，封装、消息传递、动态绑定、服务描述和查询也 是w e bs e r v i c e s 中的基本概念，而且，w e bs e r v i c e s 另外一个基本概念就是： 所有东西都是服务，这些服务发布一个a p i 供网络中的其他服务使用，并且封装 了实现细节。 w e bs e r v i c e s 是部署在i n t e r n e t 上并用于分布式计算的软件对象，通常情 况下他是一个应用逻辑单元，负责为网络中的其他组件提供数据或者服务。w e b s e r v i c e s 及组件技术和网络技术的优点于一身，他与一般组件的类似之处在于 同样都是可重用的软件模块，并且外界都无需关心其内部的实现细节。但与目前 普遍采用的组件技术有所不同，w e bs e r v i c e s 并不通过特定的对象模型来进行 访问( 如分布式组件对象模型d c o m j 远程方法调用r m i 或者i n t e r n e t0 r b 互操 作协议1 1 0 p ) ，而且借助通用的w e b 协议和数据表示方法，如h t t p ，x m l 和s o a p ， 正因为这样，w e bs e r v i c e s 理论上可以在任何平台上，别处任何编程语言来实 现。 作为一种可重用的软件组件，w e bs e r v i c e s 可以很方便的查找，组合或者 重组，它具有如下一些基本特征：良好的封装性，松散的耦合性，协议的规范性， 标准的开放性，高度的集成性。 从功能角度来看，w e bs e r v i c e s 的体系构架是基于服务提供者，服务请求 者和服务注册中心这三个角色。简单地说，服务提供者就是w e bs e r v i c e s 的拥 有者，他为其他服务和用户提供服务的功能，服务提供者在实现服务之后可以发 布服务，并且响应对其服务的所有调用请求。服务请求者就是w e bs e r v i c e s 的 使用者，它可以通过服务注册中心查找所需的服务，服务注册中心的作用则是把 1 0 分布式远程解决方案的确定 服务请求者与恰当的服务提供者绑定在一起，他负责纪录已经发布了的服务及其 提供者，并且提供对服务的检索。 服务提供者，服务请求者和服务注册中心这三个角色是依据逻辑关系划分 的，用他们表示的w e bs e r v i c e s 体系架构模型如图。在实际应用中，这些角色 的功能可能会出现交叉或者互换，比如某个w e bs e r v i c e s 既可以是某个服务的 提供者，同时又可以是其他服务的请求者。 w e bs e r v i c e s 体系架构模型 2 2 几种分布式远程解决方案的比较 2 2 1c o i m ad c o m 和e 。m 的局限性 尽管c o r b a 和d c o m 已经在各种平台上得到了实现，然而实际情况是建立 在这些协议之上的任何解决方案都依赖于单一厂商的实现。因此，如果要开发一 个d c o m 应用程序，分布式应用程序中所有参与的节点都必须以w i n d o w s 风格 运行。如果要开发c o r b a 应用程序，应用程序环境中的每个节点都要运行相同 的o r b 产品。现在也有来自不同厂商的c o r b a0 r b 能够相互操作。但是那种互 操作性并不能扩展到像安全与事务管理那样的更高级别的服务中去。不仅如此， 所有特定于厂商的优化在这种情况下将丢失殆尽。 这两种协议都依赖于严格管理的环境。要找到能成功地在外部调用d c 叫或 i i o p 的任意两台计算机的几率比较小。此外，程序员们必须处理数据排列和数 分布式远程解决方案的确定 据类型所需的协议唯一的消息格式规则。d c o m 和c o r b a 都是服务器对服务器通 信的合适的协议。然而，它们在客户机对服务器通信方面都存在严重的缺陷，特 别是当客户机遍布因特网时。 r m i e j b 由于基本上是j a v a _ t o j a v a 技术，它需要客户方程序和服务方程 序都用j a v a 编写，难以实现与其它语言编写的对象之间的互操作，因而不能满 足不同语言的开发者要求。 2 2 2w e bs e r v i c e 优劣性分析 不同于由d c o m 和c o r b a 解决方案所造成的单一厂商的实现要求，厂商们 一致认为，定义一个能让应用程序实现互操作性的分布式计算模型是每个人的最 大利益所在。而w e bs e r v i c e 组件的核心，即h t t p 、x m l 和s o a p 的实现可自 由地通过a p a c h e 开放源代码社区得到。w s d l 的免费实现可从m i c r o s o f t 和 i b m 处获得。因此一般的程序员能公开获取必需的工具以快速开发分布式应用程 序，此外，这些应用程序部署的支持可以被应用程序用户简单、划算地解决。 进一步讲，w e bs e r v i c e 是一个全新的开放的解决方案，它解决了c o r b a 所 解决的相同的分布式计算问题，同时又有更进一步的目标，那就是改进c o r b a 的 一些缺陷。1 】e bs e r v i c e 技术提供了一个全新的编程模型来利用开放因特网标准 建立分布式应用程序。这一全新的分布式计算解决方案采用特定因特网技术的开 放性解决了许多c o r b a 和d c o m 的互操作性问题。特别是，w e bs e r v i c e 使用 h 盯p 来实现防火墙友好和不确定有效负载； 将煳l 作为一个编码模式使用， 它能比d r 和c d r 更为广泛地被采用； 提供关于h t t p s o a p 服务器环境的免 费的经济价值建议，或提供关于o r b 框架的收费的经济价值建议；使用广泛深 入的u r l 因特网概念来解决对象识别问题；并且提供的不只是互操作性的承诺。 实际上，w e bs e r v i c e 的主要目标是跨平台的可互操作性。为了达到这一目 标，w e bs e r v i c e 完全基于x m l ( 可扩展标记语言) 、x s d ( x m ls c h e m a ) 等独立 于平台、独立于软件供应商的标准，是创建可互操作的、分布式应用程序的新平 台。在跨越防火墙通讯，软件和数据重用，应用程序集成以及b 2 b 集成四_ 种情况 下，使用w e bs e r v i c e 会带来极大的好处。换句话说，w e bs e r v i c e 在通过w e b 进行互操作或远程调用的时候是最有用的。不过，也有一些情况，w e bs e r v i c e 分布式远程解决方案的确定 根本不能带来任何好处，诸如单机应用程序，局域网的同构应用程序等 2 2 3 几种分布式远程解决方案的比较图 c o r b a 0 r b c t i v e x d c 0 h e j b 雕i w e bs e r v i c e 集成性 支持跨语言操作好好一般好 支持跨平台操作好一般好好 同络通讯好一般好好 公共服务构件好一般好好 可用性 事务处理好一般一般好 消息服务一般一般一般好 安全服务好一般好一般 目录服务好一般一般好 容错性 一般一般一般好 产品成热性好好好一般 软件开发商的支持度 一般好好一般 可扩展性好一般好好 2 3 分布式远程解决方案的确定 通过上面的比较，我们知道了c o r b a ，d c o m 和e j b 的局限性，也了解到w e b s e r v i c e 具有很多的优势，并且了解了什么情况下应该用w e bs e r v i c e ，什么情 况用w e bs e r v i c e 是不合适的，那么究竟在该平台应该不应该用w e bs e r v i c e 呢? 由于系统平台是分布式的多用户程序，而且用户可能工作在各种异构平台上 如w i n d o w s ，l i n u x 之上，而却会有跨越放火墙的通讯的可能性，因而采用w e b s e r v i c e 作为分布式远程解决方案是合理的，另一方面，由于w e bs e r v i c e 处于 一个新兴的阶段，是当今技术的最亮点，很多厂商对这种技术都处于研究和初步 1 3 分布式远程解决方案的确定 应用阶段，因而采用w e bs e r v i c e 技术就更显得具有科学研究探索的意义。下面 的图和分析说明了这一点： 以上这幅图是g a r t n e rg r o u p 在研究了所有i t 主流时尚技术的发展道路后， 作出的抽象模型。y 轴表明技术的受关注程度，而x 轴则表示技术的应用的成熟 度。每一项技术在从出现到成熟的整个过程都将沿着图中的曲线前进，而且典型 地，都将被划分为五个阶段： 技术显现：一门技术被发明或定义之后，开始进入公众的视野； 不断膨胀的期望期：由于该项技术的划时代的突破，使人们对这项技术有 着无比美好的想象和期望，这一阶段类似”网络的泡沫器”； 希望破灭之后的醒悟期：由于每项技术都不是万能的，真正获得使用仍然 需要务实的加以应用研究，因此此时人们发现这项技术似乎并没有期望中 那么有用，这一阶段类似”网络的泡沫破灭4 ； 豁然开朗的应用发展期：经过了一个阶段的开发和研究，该项技术终于走 上了良性发展的轨道，越来越多的人接受并使用了该项技术； 大量的工业化生产期：该项技术成为业界主流，大量应用在具体的环境中。 综上所言，采用w e bs e r v i c e 技术作为分布式远程解决方案，一方面可以 1 4 分布式远程解决方案的确定 解决系统平台的需求，另方面具有科研探索意义，所以最终系统平台采用了 w e bs e r v i c e 作为系统的分布式远程解决方案。 软件平台的结构方案 第三章软件平台的结构方案 3 1 软件平台结构的确定 在选定了利用w e bs e r v i c e 作为远程解决方案之后，又对整个系统平台的结 构进行了分析与设计。 既然选定w e bs e r v j c e 作为远程解决方案，那么系统平台从整体结构上看自 然而然的就分为服务器和客户端两部分。服务器端配簧部署w e bs e r v i c e 服务， 客户端则利用这些服务进行工作。 考虑到众多的客户端可能在一个时间内请求服务，并且如果服务器发生故障 会给用户带来诸多不便等一系列因素，决定采用集群技术作为我们的解决方案， 集群的解决方案也有很多种，究竟哪种适合该系统平台呢? 结合服务器端要部署 w e bs e r v i c e 服务，需要一个w e bs e r v i c e 容器的现状，最终确定了利用w e b l o g i c 作为w e bs e r v i c e 服务的容器，因为w e b l o g i c 经过部署可以构成一个w e b l o g i c 服务集群，可以满足我们对集群服务的要求。 客户端则充分考虑至u 不同用户可能会在不同的异构平台系统之上进行操作， 所以采用跨平台性较好的j a v a 语富作为我们的实现语言，针对一些其他的虚拟 实验中存在的问题，采用动态加载试验以及面向对象的编程方式，构架虚拟实验 平台的客户端框架，在框架中，可以根据不同的需要添加不同的实验，满足各种 用户的需要。 根据上面的分析，在论文的具体开发过程中，采用了j a v a 语言进行系统的 开发工作，实现了该平台系统的操作系统无关性。平台系统分为客户端和服务器 两个部分。服务器端采用耵e b l o g i c8 1 作为服务器容器，构架集群服务，部署 w e b s e r v i c e s 服务，适用于多种语言开发的客户端进行调用，增加了系统的可维 护性以及扩展性，集群服务则可以有效地进行均衡负载，无损关机以及升级维护 等。客户端利用j a v