（计算机软件与理论专业论文）基于gt30的网格服务容错的研究.pdf

上海大学硕士学位论文 t h e p o s t g r a d u a t et h e s i so f s h a n g h a iu n i v e r s i t y 摘要 故障是所有计算机系统都应该考虑的影响自身性能的关键因素之一。虽然网 格的各个计算结点都对自身结点提供各种容错机制，但是这并不能够保证作为一 个虚拟计算机的网格的整体故障能够得到很好的控制和处理。因此，网格的一个 至关重要的研究领域就是容错。 本文首先比较了现在的网格服务容错的研究，对它们的优点和缺点做出一个 完整的分析。针对现有的容错模型，我们提出了一种新的网格服务容错机制，并 在g t 3 ( g l o b u s t o o l k i t3 ) 上实现我们的这种机制。首先我们在g t 3 网格服务容器 中建立一个容错机制控制模块，它将为每一个用户提出的网格服务请求建立一个 监控线程，这个监控线程将定期地为这个请求的网格计算服务做检查点以保证计 算的中间结果不会因为故障的发生而丢失；同时监控线程还定期地检查服务的状 态，当一个服务因故障而中断时，在由容错控制模块将该服务恢复到的最近的检 查点信息。在做检查点时，为了能够保存g t 3 中的服务的中间运行状态，我们 采用了修改j a v a 虚拟机，从而扩展现有的虚拟机a p i ，使得它有能力保存j a v a 程序执行现场。 本文第一章我们分析网格容错研究的必要性。第二章我们提出我们的网格服 务容错在g t 3 平台下的设计以及整个设计用到的关键性技术和难点。第三章， 我们将详细分析了我们研究的平台g t 3 ，这是我们以后工作的基础。第四章我们 提出要实现网格服务容错需要得检查点算法，即对j a v a 虚拟机做出扩展，并提 供a p i 来对j a v a 线程的执行状态进行保存和恢复。第五章，我们结合上面的工 作，提出我们的容错控制模块的设计实现。最后，我们对本课题所作的工作进行 一个总结和展望。 关键词：故障，容错，网格，服务 上海大学硕士学位论吏 a b s t r a c t f a i l u r e1 5o n eo ft h ek e yf a c t o r st h a ti m p a i rt h ep e r f o r m a n c eo ft h ec o m p u t e r s y s t e m a l t h o u g ht h eg r i d ，w h i c hi ne s s e n c ei so n ek i n dc o m p u t e rs y s t e m ，p r o v d e s f a u l t t o l e r a n c eo ne v e r yn o d e ，t h ef a i l u r eo f t h e 鲥d sw h o l ea c t i o ne a n tb es o l v e d s o t h er e s e a r c ho f f a u l t t o l e r a n c eb e c o m e so n eo f t h ee s s e n t i a ld o m a i n so f t h e g r i d s i nt h i sp a p e r , f i r s t l yw e c o m p a r ec u r r e n tm a i nr e s e a r c h e so ng r i d sf a u l t t o l e r a n c e a c c o r d i n g t ot h i sc o m p a r i s o n ，w e p u tf o r w a r do n en e wm e c h a n i s m o ff a u l t t o l e r a n c e o nt h e 鲥da n di m p l e m e n ti to nt h eg t 3 ( g l o b u st o o l k i t3 ) i no u ri m p l e m e n t a t i o n ， f i r s t l y , w es e tu p ac o n t r o l l i n gm o d u l ei ng r i ds e v e r ，w h i c hi sr e s p o n s i b l ef o r r e c o r d i n g t h er e q u e s to f c l i e n ta n dt h et e m p o r a r y r u n n i n g s t a t u st oe n s u r et h a tt h ee x e c u t i o nc a l l b er e c o v e r e d m e a n w h i l e ，i tc h e e k st h es t a t eo ft h ee x e c u t i n gg r i ds e r v i c et ok e e pt h e s e r v i c ea c t i v e t or e c o r dt h es t a t eo f 也es e r v i c et h a tr b n sa saj a v at h r e a d w ee x p a n d t h ej a v av i r t u a lm a c h i n et o p r o v i d ea p if o rr e c o r d i n gj a v at e m p o r a r ye x e c u t i o n s t a t u s i nt h ef i r s t c h a p t e r , w ea n a l y z et h en e c e s s i t yo ft h e f a u l t - t o l e r a n c eo ng r i d c o m p u t i n g i nt h es e c o n dc h a p t e r , w ef o r w a r do u rd e s i g no f o u rm e c h a n i s m ，t h ek e y a n dr e l a t e dt e c h n i q u e si nt h i si m p l e m e n t a t i o n i nt h et h i r dc h a p t e r , w eg i v ead e t a i l i m p l e m e n t a t i o no ft h eg t 3 ，w h i c hi st h eb a s i so fo u rw o r k t h e n ，w ep r o v i d eo u r a l g o r i t h ma n di m p l e m e n t a t i o n o f t h e e x p a n s i o no f l a v av i r t u a lm a c h i n e a n dt h e n ，w e p r o v i d e t h e i m p l e m e n t a t i o no fo u rf a u l t t o l e r a n c e o ng t 3 a tl a s t w e g i v e a c o n c l u s i o na n df u t u r ew o r ko f o u rr e s e a r c h k e y w o r d s ：f a i l u r e ，f a u l t - t o l e r a n c e ，g r i d ，s e r v i c e 上海人学硕十学位论文 原创性声明 本人声明：所呈交的论文是本人在导师指导下进行的研究 工作。除了文中特别加以标注和致谢的地方外，论文中不包含其他 人已发表或撰写过的研究成果。参与同一工作的其他同志对本研究 所做的任何贡献均已在论文中作了明确的说明并表示了谢意。 期兰皇! 盐纠 本论文使用授权说明 本人完全了解上海大学有关保留、使用学位论文的规定，即：学校有权保 留论文及送交论文复印件，允许论文被查阅和借阅；学校可以公布论文的全部 或部分内容。 ( 保密的论文在解密后应遵守此规定) 签名：瘫盟导师签名幽日期：翌苎幽 1 i i 上海大学硕士学位论文 第1 章绪论 1 1 网格计算发展 随着如今复杂深入的科学技术的发展和越来越庞大的工程的出现，现今的计 算机系统无论是集群还是大型机都越来越不能适应这些发展的高性能的计算能 力的需求。因此人们提出了一种“网络虚拟超级计算机”或“元计算机”的概念来获 得超强的计算能力。上世纪9 0 年代初，对于i n t e r n e t 上大量增加的主机但利用 率并不高的状况，美国国家科学基金会( n f s ) 将其四个超级计算中心构筑成一 个元计算机，逐渐发展到利用它研究解决具有重大挑战性的并行问题。它提供统 一的管理、单一的分配机制和协调应用程序，使任务可以透明地按需要分配到系 统内的各种结构的计算机中，包括向量机、标量机、s i m d 和m i m d 型的各类计 算机。n f s 元计算环境主要包括高速的互联通信链路、全局的文件系统、普通用 户接口和信息、视频电话系统、支持分布并行的软件系统等。 元计算被定义为“通过网络连接可获得的计算资源，形成对用户透明的超级 计算环境”，而目前人们更多的使用的术语则是“网格计算( g r i dc o m p u t i n g ) ” 1 , 2 。 它更系统化地发展了起初元计算的概念，它通过网络连接地理位置上分布的各类 计算机( 包括集群) 、数据库、各类设备和存储设备等各类硬件软件资源，形成 对用户相对透明的虚拟的高性能计算环境，应用于包括了分布式计算、高吞吐量 计算、协同工程和数据查询等诸多领域。网格计算被定义为一个广域范围的“无 缝的集成和协同计算环境”。网格计算模式已经发展为连接和统一各类不同远程 资源的一种基础结构。 网格计算主要需要解决三个主要的问题【2 ，3 】。首先是异构性。由于网格是由 分布在广域网上不同管理域的各类的计算资源组成，怎样实现网格内的异构机器 间的合作和转换就成了首要问题。其次是可扩展性。随着资源规模不断扩大、应 用不断增长的情况下，网格系统应该保证这些资源能够被加入到当前的网格并且 不降低性能。最后是动态自适应性既可靠性。在网格计算中，某一处的资源出现 故障或失败的可能性较高，资源管理必须能动态监视和管理网格资源，从可利用 的资源中选取最佳资源服务。 网络服务( w e bs e r v i c e s ) 4 】出现为网格解决以上几个问题带来了更有效 的机制。开放式网格互连体系结构( o g s a ) 【2 ，3 】就是由网络服务发展来的新的 网格体系结构。o g s a 最突出的思想就是以“服务”为中心。在o g s a 框架中，将 切资源都被抽象为服务，包括计算机、程序、数据、仪器设备等。o g s a 在 原来w e b s e r v i c e 服务概念的基础上，提出了“网格服务( g r i ds e r v i c e ) ”的概念， 上海大学硕士学位论文 t h e p o s t g r a d u a t et h e s i so fs h a n g h a iu n i v e r s i t y 用于解决服务发现、动态服务创建、服务生命周期管理等与临时服务有关的问题。 基于网格服务的概念，o g s a 将整个网格看作是“网格服务”的集合，但是这个集 合不是一成不变的，是可以扩展的，这反映了网格的动态特性。网格服务通过定 义接口来完成不同的功能，服务数据是关于网格服务实例的信息，因此网格服务 可以简单地表示为“网格服务= 接n 行为+ 服务数据”。 以网格服务为中心的网格模型具有如下好处：( 1 ) 解决了网格的异构性问题。 由于网格环境中所有的组件都是虚拟化( v i r t u a l i z e d ) ，因此，通过提供一组相对统 一的核心接口，所有的网格服务都基于这些接口实现，就可以很容易地构造出具 有层次结构的、更高级别的服务，这些服务可以跨越不同的抽象层次，以一种统 一的方式来看待；( 2 ) 解决了可扩展性问题。虚拟化也使得多个逻辑资源实例映 射到相同的物理资源上成为可能，在对服务进行组合时不必考虑具体的实现，可 以以底层资源组成为基础，在虚拟组织( v i r t u a lo r g a n i z a t i o n ) 中进行资源管理。 通过网格服务的虚拟化，可以将通用的服务语义和行为，无缝映射到本地平台的 基础设施上。 1 2 网格系统可靠性问题及其重要性 从1 1 我们知道，网格系统是作为一个“虚拟计算机”提供给用户使用的。 对于计算机系统而言，设计者必须考虑的一个重要问题就是可靠性，因为这是计 算机系统的性能和用户友好性的体现。计算机系统的可靠性可以用平均无故障时 间( m t t f ) 来度量，即计算机系统平均能够正常运行多长时间，才发生一次故 障。系统的可靠性越高，平均无故障时间越长。可维护性则可用平均维护时间 ( m t t r ) 来度量，既系统发生故障后维修和重新恢复正常运行平均花费的时间。 系统的可维护性就越好，平均维修时间越短。计算机系统的可用性定义为： m t t f ( m t t f + m t t r ) + 1 0 0 。由此可见，计算机系统的可用性定义为系统保持 正常运行时间的百分比。计算机产业界通常用如下表所示的9 的个数来划分计 算机系统可用性的类型。下表就是一个可用性分类表。 上海大学硕士学位论文 t h e p o s t g r a d u a t et h e s i so fs h a n g h a iu n i v e r s i t y 表1 计算机系统性能分类 计算机系统的可维护性标准 可用性分类可用水平年平均停机时间 容错可用性 9 9 9 9 9 9 靠八 竺! ! ! l 篓兰夕 运行支持组件集 一 里! ：! 查生主塑竺苎堡苎苎 一1 4 一 上海大学硕士学位论文 t h ep o s t g r a d u a t et h e s i so fs h a n g l l a iu n i v e r s i t y 容错中间件中的任务就是要保存和恢复网格服务的执行。这个中间件有三个 模块构成，网格服务状态保存组件( f ts a v e r ) ，网格服务恢复组件( f tr e c o v e r ) ， 网格服务状态存储件( f tr e c o r d e r ) 以及网格服务错误探测器( f td e t e c t o r ) 。 整个中间件的执行流程如下：状态保存组件定期的将服务的运行状态获取 到，并将这种状态以一种高效的形式保存在状态存储件中。探测器每隔一定的时 间就对容器内的服务进行扫描，如果探测到某个服务运行失败，则命令服务恢复 组件从存储件中找到相应的服务状态并恢复这个服务。 ( 2 ) 组件设计中的问题 网格服务状态保存组件就是要定期的保存网格服务的状态，并将这种状态保 存到存储件上。保存的过程有两点值的注意的问题。一是保存频率( f o s ，t h e f r e q u e n c yo f s a v i n g ) ，这是影响应用程序执行的效率的关键。二是如何保存，虽 然我们已经在上一节里面通过扩展虚拟机来保存服务的中间执行状态，但是并没 有解决在这整个g t 3 平台中如何合理的嵌入保存着一个组件。 保存的频率是应该可以由用户编程或者手动控制的，这是因为错误的发生概 率会因为应用的不同而不同，比如在通信频繁的应用中，错误率会因为网络上的 各种不确定因素而增高，如果在这个时候服务状态的保存还是保持为一个相同 值，那么大量的计算将会因为服务恢复模块恢复到不适宜的位置，造成了大量的 计算时间和资源使用率的降低；又比如再存计算的应用中，如果对外界条件的以 来较少，整个计算发生错误的概率也讲大幅的降低，因此，设置一个较大的保存 时间间隔是对于整体性能是有帮助的。因此对于改组件我们必须将它设计为一个 可有用户指定的值，在这样每种应用中，用户都可以根据该应用的具体情况将改 参数进行调整，已达到网格服务执行的最高效率。 整个保存的思路就是更具用户提供的保存频率，每隔一个固定的时间，g t 3 的服务组件首先暂时停止当前服务的执行，然后，通过前一节中的虚拟机修改的 方法所提供的a p i 将这是后的服务的执行状态获取到，最后是将这个所获得的 状态以一种通用的对象形式保存到一个高度可靠的存储介质中。由于这一保存过 程对与用户是不可见的是透明的，因此我们必须将要将这一实现过程作为g t 3 的系统组件一样，不需要仟何用户的参与活动，就像网格客户端需要调用网格服 务时候，用户就不必了解整个客户端和网格服务的交互过程，用户只需要实现出 自己需要的处理，剩下的事情都交给了g t 3 平台来处理。因此我们需要在实现 这一个保存过程的时候，将整个组件嵌入g t 3 平台。 错误探测器，是实现网格服务容错的关键。当它在扫描整个服务容器内的服 务时，如果发现某个服务没有继续运行时，它就命令服务恢复组件恢复这个服务 的执行。这里一个问题是如何确定一个服务是否正常的执行。为了确定一个服务 上海大学硕士学位论文 三生! ! ! ! 里! ! ! 苎! ! 皇! ! ! ! ! ! ! 翌竺业! ! 旦呈! 二竺! 堡 时候正常执行，我们需要和整个g t 3 联系起来。因此我们将在以后整个实现框 架的时候来介绍这个问题的解决方法。 对于服务恢复组件，它在接到探测器的命令后，就开始从纪录其中查询发生 故障的服务的状态纪录，找到以后，重新开始一个新的网格服务并且它的执行状 态就是发生故障前的最后一次保存的状态。但是它必须注意如何将新生成的网格 服务实例正确的放入整个容器中。 - 1 6 上海大学硕士学位论文 ! 皇! 呈些型些尘墼些塑墼坠坠筌坚一 第3 章网格服务容错的平台分析 为了实现对g t 3 服务的容错，我们必须要对整个g t 3 容器如何与客户端交 互以及服务如何实现有一个详尽的分析和认识。我们分析的是当前最常被采用的 j a v a 实现的g t 3 版本，之所以采用j a v a 版本是因为j a 、a 语言良好的跨平台 能力，它是实现网格特别是网格的异构特性的最好工具。本章的主要目的就是分 析出整个网格容器和网格服务实现以及客户端如何调用网格服务。正如我们在研 究过程中发现，g t 3 是一个庞大的软件，要完整的分析出每一个功能对于实现我 们的容错是没有必要的，因此我们只是对在容错过程中需要使用的组件进行分 析。这里我们对g t 3 分析的目的有两点：( 1 ) 通过分析，我们可以了解到网格 服务是怎样在网格容器中被客户端调用到的，既网格服务通客户端的交互过程。 ( 2 ) 通过分析，我们可理解服务在运行时如何组织，管理和维护。通过这两点， 我们就可以为了能够实现网格服务容错机制奠定一个扎实的基础。 图3 1g t 3 中的主要组件 如图3 - - 1 所示，我们就将分两个部分来对g t 3 做分析，在逻辑上他们分别 是服务实现基础设施和协议处理组件。 实际上因为我们的g r i ds e r v i c e 是一种w e b s e r v i c e ，那么它也就是一种远程 对象技术，那么g t 3 容器也就是一个远程对象容器。e j b ( e n t e r p r i s e j a v ab e a r l s ) 容器这种现在流行的企业级b e a n s 的容器为e j b 提供了e j b o b j e c t 和 e n t e r d r i s o b e a l l 以及相关的工厂等，e j b o b j e c t 也就是我们g t 3 容器中的协议处 理组件，主要处理对b e a n s 实际调用前以及调用后与客户端相关的操作，而诸如 e a t e r p n s e b e a n 一类的组件则负责生成e j b 。在g t 3 容器里，协议处理组件和服 上海大学硕士学位论文 t h e p o s t g r a d u a t et h e s i so f s h a n g h a iu n i v e r s i t y 务实现基础设施就对应于e j - b o b j e c t 和e n t e r p r i s e b e a n 。在整个客户端到服务器 端交互过程中，服务实现基础设施并不参与任何处理，这样的实现使得g r i d s e r v i c e 的编写者将自己的更多的精力放在g r i ds e r v i c e 应该处理的逻辑服务上， 而不是牵涉具体的交互事务。同时，协议处理组件将截取各种客户端请求，并代 理这些请求调用相应的g r i ds e r v i c e 提供给客户端的具体服务，通常是以某个函 数或方法的形式出现的。 3 1 协议处理组件 协议处理组件的作用则主要是负责处理两层协议，网络协议( 通常人们选者 的是h t t p 协议) 和s o a p ( s i m p l eo b j e c ta c c e s sp r o t o c 0 1 ) 协议。在g t 3 容器 中g t 3 前端控制器主要是用来处理网络协议的( 通常g t 3 容器采用h t t p 协议 作为网络层协议来负责将s o a p 消息在网络上进行传递) ，而w e be n g i n e 则是用 来处理s o a p 协议的( 通常g t 3 容器采用的w e bs e r v i c e 引擎是开放式源码工 程提供的a p a c h e a x i ss e r v e r ) 。g t 3 前端控制器的作用就是接收某种固定协议( 通 常为h t t p ) 的多个客户端请求，根据设定的通信格式分析这些客户的具体请求， 再调用下层的w e bs e r v i c e 引擎，并且负责将每个客户端的调用结果返回给客 户。w e bs e r v i c e 引擎的作用则是根据前端控制器提供的信息处理s o a p 消息， j a x r p c ( j a v a a p if o r ) 。i l b a s e dr p c ) 句柄处理和w e b 服务配置，之所以采用 w e bs e r v i c e 引擎是g r i ds e r v i c e 实际上就是 一个w e bs e r v i c e ，因此我们这里需要w e bs e r v i c e 引擎来处理这些请求。 3 1 1 网络协议终端 图3 2 网络协议终端u m l 图 上海大学硕士学位论文 t h e p o s t g r a d u a t et h e s i so fs h a n g h a iu n i v e r s i t y 我们也把g t 3 的网络协议终端称作h t t p s e r v l e t ，这是因为网络协议终 端在功能上就等价于一个w e b 容器中的s e r v l e t ，主要负责处理容器同客户 端间的网络层通信。当容器启动时，它作为容器的一个固定组件也同时启动运行， 并开启一个等待套接字，等待客户端的连接请求。每当一个客户请求到达，终端 就将这个请求接收到并保存起来，在根据当前容器被客户端服务的情况，决定是 否立即为该请求服务还是延迟为该请求服务。当终端为请求服务时，它首先为客 户端分配一个处理线程，处理线程根据h t t p 协议分析出客户端的请求，分析请 求的类型并将该请求转换成相应的格式，传递给下层的a x i s 继续处理，当下层 处理完毕以后，终端在接过控制权，将接受的处理结果以h t t p 协议包的形式返 回给客户端。 如图3 2 所示，g t 3 的网络协议终端主要包括以下几个实现类。 s e r v i c e c o n t a i n e r 类，s e r v i c e d i s p a t c h e r 类，s e r v i c e r e q u e s t q u e u e 类，s e r v i c e t h r e a d 类，s e r v i c e t h r e a d p o o l 类。 1 s e r v i c ec o n t a i n e r 这个类是整个g t 3 运行的入口，g t 3 也是通过它将加载所有需要的组件。 从网络协议终端结构图中我们可以看到，它包含两个重要的结构，一个是 d i s p a t c h e r ，另一个是c o n t a i n e r s ，前者为各个客户请求分配处理器，后者则是当 前所有存在的容器个数。s e r v i c ec o n t a i n e r 根据系统管理员开启容器时提交的命 令设置自己的各项运行参数，比如应该建立的套接字的u r l ( u n m e dr e s o u r c e l o c a t i o n ) 和端口，并根据这两个参数建立监听套接字，并将这个监听套接字传 送给d i s p a t c h e r 。 2 s e r v i c er e q u e s tq u e u e 服务请求等待队列。它将从监听套接字出接受到的连接套接字同监听套接字 连在一起，作为标示客户端请求的标示，并将所有的这些请求存放起来。 3 s e r v i c et h r e a d 工作者线程。它在生存期内，从请求队列中获取请求，然后分析 4 s e r v i c et h r e a dp o o l 工作者线程池。它相当于工作者的容器，并能够计算出当前的等待线程数目。 5 s e r v i c ed i s p a t c h e r s e r v i c e d i s p a t c h e r 在接到c o n t a i n e r 传递给自己的监听套接字后，首先建立一 个服务请求队列s e r v i c e r e q u e s tq u e u e 和一个服务者( s e r v i c e t h r e a d ) 队列。开 始运行时，它将在监听套接字进行监听，如果有客户端连接请求，则将连接套接 字同监听套接字组成一个服务请求放入服务请求队列，等待服务者线程的服务。 上海大学硕士学位论文 t h e p o s t g r a d u a t et h e s i so fs h a n g h a iu n i v e r s i t y 每当d i s p a t c h e r 接受一个新的服务请求后，它将判断当前的服务线程是否太多， 如果是，就让该请求继续等待，否则新生成一工作者线程或是从在工作者队列中 取出一个线程为该请求服务。 3 1 2w e b e n g i n e 由于所有的网格服务都是w e bs e r v i c e ，因此，g t 3 应该需要存在组件来处 理在网格服务件通信的数据。g t 3 采用了a x i se n g i n e 来处理这种网格服务通信 的s o a p 消息。 o g s a 实现底层采用了a x i s 的通讯方法，a x i s 给出了以s o a p 为传输协议的 通讯框架，它由些子系统协同工作的。 a x i s 是用来处理消息的，运行中央a x i s 处理逻辑时，一系列句柄( h a n d l e r s ) 按顺序一一激活。激活的顺序是由两个因素来决定的，部署配置和引擎是用户还 是服务器。用来传递每个句柄激活的对象是消息上下文( m e s s a g e c o n t e x t ) 。一 个消息上下文是个结构体，包括以下一些主要部分：一个请求消息( r e q u e s t ) ， 一个回复消息( r e s p o n s e ) ，一组属性。 触发a x i s 通讯的基本方法包括作为服务方和作为客户方的触发： 作为服务方s e r v e r ，传输监听( t r a n s p o r tl i s t e n e r ) 将创建一个消息上 下文，同时激活a x i s 处理流程。 作为客户方c l i e n t ，应用代码( 通常由a x i s 的客户端编程模型支持) 将生成 一消息上下文并且激活a x i s 处理流程。 a x i s 流程的任务只是简单地通过配置好的句柄组来传递结果消息上下文， 其中每个句柄都按照事先设计的行为跟消息上下文打交道。 作为服务方和作为客户方的消息路径如下： 1 服务方的消息路径 服务方消息路径如图3 3 所示，圆柱体代表旬柄链，在每个旬柄链是一组 句柄对象。 一2 0 - 上海大学硕士学位论文 t h e p o s t g r a d u a t et h e s i so f s h a n g h a iu n i v e r s i t y 吲 请求层全局层服务层 一n ：m i 、 眼务 芝请求 i 2 l f l 晴求句柄请求 、 滁卜 ， r 、i 阿 i i ) 一 f - ) y u i 淆求唰糯 同商句柄 a x i s 引擎 图3 3 服务方消息路径 消息通过某种协议方式到达传输监听。如果监听者是一个h t t ps e r v l e t 这 个监听的任务就是把特定协议的数据打包成一个消息对象 ( o r g a g a c h e a x i s m e s s a g e ) ，同时把消息放进消息上下文。消息上下文也附有 许多属性，比如属性“h t t p s o a p a c t i o n ”被设置成s o a p a c t i o nh t t p 头的值。 消息上下文完成之后，监听把它交给a x i s 引擎( a x i s e n g i n e ) 。 a x i s 引擎的首要任务是通过名字查找传输。传输是包含有请求链或者回复 链或者两者兼具的对象。一个链( c h a i n ) 是一个旬柄，它包含有一系列被依次 激活的句柄。如果传输请求链存在，就激活它，这样导致激活链中所有的句柄。 之后引擎定位到全局请求链并将它激活。这个过程执行到现在，某个旬柄已经设 簧了消息上下文的服务句柄域( s e r v i c e h a n d l e r ) ，这个域决定了我们将激活这 个句柄来执行特定服务功能，例如对后台对象的远程过程调用。a x i s 上的服务 是s o a p s e r v i c e 类的实例，这个类可以包含请求和回复链，但必须包含有一个提 供方( p r o v i d e r ) ，提供者是仅仅是一个句柄用来负责实现真正服务后台逻辑。对 于r p c风格的请求 ，提 供者是类 o r g a p a c h e a x i s p r o v i d e r s j a v a r p c p r o vj d e r 。 2 客户方的消息路径 客户方的消息路径与服务方的消息路径相似，只是顺序不同罢了。如图3 4 所示 上海大学硕士学位论文 t h e p o s t g r a d u a t et h e s i so fs h a n g h a iu n i v e r s i t y 消息 喜 信封服务层全局层传输层 mf i 翌 服务 、句柄ii 请求 、 刃层消 i 用 请求 息服j ” 霉m 从j l 务 1 让j ：画： 请求 回应句柄 a x i s 引擎 图3 4 客户方的消息路径 在客户方，服务旬柄( s e r v i c e ) 首先被调用，因为服务是有远端节点来提 供的，所以不存在提供者p r o v i d e r ，但仍然存在请求链和回复链。服务请求链 之后再激活全局请求链。传输发送者作为一特殊的句柄用来执行那些特定协议的 操作，这些操作有必要和目的s o a p 服务者进行消息交换。 a x i s 中使用r p c 的方式是基于s o a p 的r p c ，r p c 调用和响应是在s o a pb o d y 元素中传送，使用如下的表示方式。 一个方法调用被建模成一个s o a p 中的数据类型：结构( s t r u c t ) ； 该方法调用显示为一个结构( s t r u c t ) ，包含对应每个 i n 或 i n o u t 参数 的存取标识。该结构的名和类型可以使用过程或方法的名来标识并命名； 每个 i n 或 i n o u t 参数都被表示为一个存取标识，该存取标识的名和类型 都对应于相应参数的名和类型。它们的次序也是按照原来r p c 调用中的原始次 序： 一个方法响应同样被建模成一个结构( s t r u c t ) ； 该方法响应显示为一个结构s t r u c t ，包含对应每个 o u t 或 i n o u t 参数的 存取标识。而第一个存取标识是返回值，而随后则是按照原来次序的返回参数； 每个 o u t 或 i n o u t 参数都被表示为一个存取标识，该存取标识的名和类 型都对应于相应参数的名和类型。而对应于返回值的存取标识名应当是 “r e s u l t ”，同时应该带有h t t p ：w w w w 3 o r g 2 0 0 l 1 2 s o a p r p e ”命名空间修 饰限定。如果该r p c 调用具有返回值的话，那么“r e s u l t ”存取标识必须出现： 如果r p c 调用没有返回值的话，那么“r e s u l t ”存取标识则必须不能出现； 方法调用出错应使用s o a pf a u l t 元素来编码。如果一个绑定协议对于错误 表达还有额外规则，那么这些规则都应当被遵守。 2 2 上海大学硕士学位论文 t h e p o s t g r a d u a t et h e s i so fs h a n g h a iu n i v e r s i t y 3 。2 服务实现基础设施 服务实现基础设施的存在主要是为了实现，管理和维护服务及其实例，在 g t 3 中包括以下各组件：服务框架，实例生成，维护管理。服务框架实际上是所 有的网格服务的抽象，它为每个w e b 服务定义了要成为网格服务所必需的条件， 这些条件包括用来表示服务状态的服务数据( s e r v i c ed a t a ) 集合、服务数据查 询接口。实例生成在g t 3 中就是工厂( f a c t o r y ) ，它主要提供根据网格服务生成 相应的实例以及该生成的实例的生命周期管理的基础设施，这就为一个资源同时 为多个客户服务提供了可能。服务及其实例维护管理则包括了容器中为层次化的 存储服务，查询和发布服务实例，服务以及实例的注册。 3 2 1 服务框架 服务框架是所有服务的一种抽象。在g t 3 中，所有的网格服务都是扩展了 服务框架而实现的，就如j a v a 中，一个子类扩展一个抽象类，这样子类本身就 具备了抽象类的一切功能一样。 图3 5 服务基础设施框架 s e r v i c e s k e l e t o n 就是g t 3 中所有服务的父类，它为所有的网格服务提供了所 有必要的属性和方法。这些属性包括一个服务数据集合用来容纳该服务所有的可 能的服务数据( s e r v i c ed a t a ) ，一个查询引擎用来查询服务数据，个通知引擎 用来对某些服务数据的改变做出反应。在g t 3 中，服务数据用来表示当前服务 的状态信息，这对于网格服务应用的编写是至关重要的。 2 3 上海大学硕士学位论文 t h ep o s t g r a d u a t et h e s i so fs h a n g h a iu n i v e r s i t y 服务数据集合是一个服务中服务数据的容器，它为s e r v i c e s k e l e t o n 内部使用 提供一些增、删、改等功能。查询引擎是建立在一个服务数据集合上，这个查询 引擎可以对它的服务数据集合上的数据进行各种操作，并将这些操作以a p i 的 形式提供给用户。通知引擎则是s e r v i c e s k e l e t o n 为了对某些服务数据的状态监控 而设置的，当通知引擎管理的服务数据发生改变，那么它将通知所有订阅了这个 服务数据的服务去完成既定的动作。 同时网格服务还提供了预创建、销毁、激活、钝化等操作。所有的这些操作 的提供都为网格服务生成、管理等提供一个基础。 3 2 2 实例生成 网格服务不同于一般的w e bs e r v i c e 在于前者提供了实例化使得同一个服务 可以被多个用户同时使用。在g t 3 中，实例生成就是有工厂类来完成的，它可 以将一个服务生成该服务的实例。下图是一个工厂类u m l 图。 f a c t o r y s e r v i c e s k e l e t o nf a c t o r y d e l e g a t i o n s k e l e t o n f a c t o r y s k e l e t o nl1 - b a s e a c t o r y s e r v i c e d a t a s k e l e t o n f a c t o r y s o d ej l * c r e a t e s e r v i c e o b j e c t 1 r r e g i s t r y s e r v i c e + p o s t p e r s is t e n t c r e a t e d e p l o y m e n t + a c ti v a t e s e r v i c e 1 r+ c r e 8 t e s e r v i c e + c r e a t e s e r v i c e 1l + u p d a t e r e g i s t r y + d e a c t i v a t e i n s t a n e e + c a n c e l s w e e p e r 图3 6 服务工厂u m l 图 所有的服务的工厂都应该扩展f a c t o r y s e r v i c e s k e l e t o n 这个类，并实现 c r e a t e s e r v i c e o b j e c t 这个方法，在该方法中生成一个具体服务的实例。这个 f a c t o r y s e r v i c e s k e l e t o n 提供了服务实例的预创建、创建、钝化等功能。但是真正 的这些实例的生成工作是通过f a c t o r y d e l e g a t i o n s k e l e t o n 来实现的。后者主要提 供了c r e a t e s e r v i c e 方法，这个方法就是主要的生成实例的实现。它包括了生成实 例，为服务实例添加一些必要的服务数据，将服务实例注册到相应的服务维护管 理器中，并将服务实例部署起来。 上海大学硕士学位论文 t h e p o s t g r a d u a t et h e s i so fs h a n g h a iu n i v e r s i t y 3 2 3 服务维护管理组件 服务维护管理组件是用来存放网格服务以及网格服务实例的组件。图3 7 是 服务维护管理组件的u m l 图。 图3 7 服务维护管理组件u m l 图 s e r v i c e n o d e 就是维护实例的基础单元。所有的网格服务实例都是存放在 s e r v i c e n o d e 中的s e r v i c e 属性项中的，并且所有的网格服务实例在起形成一个 以s e r v i c e n o d e 为结点的树型结构，这样所有的实例就被统一的组织起来。如下 图： 图3 8 s e v l c c n o d e 实例 一。 - 2 5 上海大学硕士学位论文 t h e p o s t g r a d u a t et h e s i so fs h a n g h a iu n i v e r s i t y 上图就是一个网格容器中的服务实例的组织结构。所有的服务实例都作为整 个树的叶子保存起来，当需要使用的时候可以通过整个树的搜索来的到。 s e i c e n o d e 主要提供了的功能包括：b i n d 方法将网格服务实例同一个具体 的u r l 联系起来；r e s o l v e 方法将一个u r l 解析为一个服务实例；g e t a l l s e r v i c e s 方法将该s e r v i c e n o d e 结点以及器子结点的所有服务实例得到。 通过提供以上的功能，s e r v i c e n o d e 主要可以将所有的网格服务实例进行管 理。 上海大学硕士学位论文 t h ep o s t g r a d u a t et h e s i so fs h a n g h a iu n i v e r s i t y 第4 章网格服务容错的检查点技术实现 在2 2 1 小节中，我们给出了一个扩展j a v a 虚拟机方案。通过扩展，虚拟机 提供a p i 来支持网格服务容错的检查点算法的实现。这一章中我们将解决如何 实现对j a v a 虚拟机的扩展，并提供了两类服务t s s 和t s r 。 在实现过程中，我们首先对j a v a 虚拟机源代码进行了深入的研究，在此基础上 对j a v a 虚拟机做出一定的扩展，并针对j a v a 虚拟机的不同执行办法，增加了一 些l i n u x 内核系统调用，从而提供了一些j a v a a p i 函数即是t s s 和t s r 的a p i ， 使得在用户程序级上可以访问j a v a 虚拟机内部的些重要信息，以达到对j a v a 线程状态进行保存和重构等目的。由于j a v a 虚拟机的实现版本k a f f e 是源代码开 放的，因此本文中我们选定了它作为我们的工作基础。 我们首先以k a f f e 作为实例分析虚拟机的实现，并在详细分析虚拟机的工作机制 的基础上，提出我们的扩展设计方法。