（计算机软件与理论专业论文）基于混合语言的web服务容器设计与实现.pdf

摘要 在分布式协作开发环境中进行系统设计工作时，要求不同的设计工具之间能 够相互衔接与协作，从而使得设计任务的流程能够平滑相连。使用w e b 服务技术， 将工具的功能包装为服务，并使用服务容器为其提供运行时环境，可以很好的满 足分布式协作应用的需求，降低开发的复杂度。 现有的服务容器要求在服务开发时将功能实现逻辑与容器的处理逻辑绑定在 一起，使得服务与其所在容器产生了紧耦合，增加了服务开发和维护的工作量。 使用单一的静态语言无法解决这个问题，而使用单一的动态语言处理时会损失处 理效率。本文针对该问题研究并实现了一个基于混合语言的w e b 服务容器 r c w s c ，在保证效率的前提下解决了容器和服务之间的紧耦合问题。 在对已有服务容器的框架结构进行研究与分析后，本文提出了一个组件化的、 可动态扩展的w e b 服务容器核心架构，并在容器和服务之间使用p y t h o n 的嵌入式 应用技术引入动态语言层，分离了容器的处理实现和服务的功能实现。实验表明 r c w s c 有效降低了容器和服务开发之间的耦合度，保证了服务开发的效率和服务 运行的稳定性。 关键词：分布式协作开发w e b 服务服务容器混合语言 a b s t r a c t w h e nd e s i g n i n gi nd i s t r i b u t e dc o l l a b o r a t i v e d e v e l o p m e n te n v i r o n m e n t s ( d c d e ) ， i ti sc r u c i a lf o rv a r i o u sd e s i g nt o o l st oc o m m u n i c a t ew i t he a c ho t h e r u s i n gw e b s e r v i c e st e c h n o l o g y , w r a p p i n gt h et o o l s f u n c t i o n st os e r v i c e ，a n ds u p p l y i n gt h es e r v i c e c o n t a i n e ra st h er u n t i m ee n v i r o n m e n to ft h e s es e r v i c e s ，c a ns a t i s f yt h er e q u i r e m e n t so f t h ed i s t r i b u t e dc o l l a b o r a t i v e a p p l i c a t i o n ，a n dr e d u c et h ec o m p l e x i t yo fd e v e l o p i n g d c d e u s i n ga v a i l a b l es e r v i c ec o n t a i n e rt od e v e l o ps e r v i c em a k e st h ec o d eo fs e r v i c e f u n c t i o na n dt h ec o d et h ec o n t a i n e rb e i n gf i g h t - c o u p l i n gw h i c hw i l li n c r e a s et h et a s k so f d e v e l o p i n ga n dm a i n t a i n i n gt h es e r v i c e s t h i sp r o b l e mc a nn o tb er e s o l v e db yu s i n ga u n i q u es t a t i cl a n g u a g e ，a n dt h ee f f i c i e n c ym a y b el o s t w h e nh a n d l i n gi tb ys o m e d y n a m i cl a n g u a g e t h i sp a p e rp r e s e n ta n di m p l e m e n taw e b s e r v i c e sc o n t a i n e rr c w s c b a s e do nh y b r i dl a n g u a g e s ，w h i c ht o w a r d st or e s o l v et h ep r o b l e mo ft i g h t - c o u p l i n g b e t w e e nc o n t a i n e ra n ds e r v i c e s a f t e ra n a l y z i n gt h ef r a m e w o r ko fe x i s t i n gs e r v i c ec o n t a i n e r , ac o r ef r a m eo f r c w ci sp r e s e n t e d ，w h i c hi sc o m b i n a t i v e ，d y n a m i c e x t e n d e da n di n t r o d u c e dt h e d y n a m i cl a y e rb yu s i n gp y t h o ne m b e d d i n gt e c h n i q u ef o rs e p a r a t i n gt h ei m p l e m e n to f t h ec o n t a i n e ra n ds e r v i c e s t h ea p p l i c a t i o no fr c w cd e m o n s t r a t e st h a ti tc a nr e d u c e t h ed e g r e eo ff i g h t c o u p l i n gb e t w e e nt h ec o n t a i n e ra n ds e r v i c e s ，a n dg u a r a n t e e st h e e f f i c i e n c yo ft h ed e v e l o p i n gs e r v i c ea n dt h es t a b i l i t yo f t h er u n n i n gs e r v i c e k e y w o r d ：d i s t r i b u t e dc o l l a b o r a t i v e d e v e l o p m e n tw e b s e r v i c e ss e r v i c ec o n t a i n e r h y b r i dl a n g u a g e 西安电子科技大学 学位论文独创性( 或创新性) 声明 秉承学校严谨的学分和优良的科学道德，本人声明所呈交的论文是我个人在 导师指导下进行的研究工作及取得的研究成果。尽我所知，除了文中特别加以标 注和致谢中所罗列的内容以外，论文中不包含其他人已经发表或撰写过的研究成 果：也不包含为获得西安电子科技大学或其它教育机构的学位或证书而使用过的 材料。与我一同工作的同志对本研究所做的任何贡献均已在论文中做了明确的说 明并表示了谢意。 申请学位论文与资料若有不实之处，本人承担一切的法律责任。 本人签名：塞蛩远 日期泣塑垒兰恩鱼目 西安电子科技大学 关于论文使用授权的说明 本人完全了解西安电子科技大学有关保留和使用学位论文的规定，即：研究 生在校攻读学位期间论文工作的知识产权单位属西安电子科技大学。学校有权保 留送交论文的复印件，允许查阅和借阅论文；学校可以公布论文的全部或部分内 容，可以允许采用影印、缩印或其它复制手段保存论文。同时本人保证，毕业后 结合学位论文研究课题再攥写的文章一律署名单位为西安电子科技大学。( 保密的 论文在解密后遵守此规定) 本学位论文属于保密，在一年解密后适用本授权书。 本人签名： 导师签名： 日期超益复l 凰终 日期4 刎险垂 、立喜。 姐豫 第一章绪论 第一章绪论 1 1 项目背景 本论文的工作来源于“系统设计工具集成技术研究”项目。该课题丰要面向综合 电子信息系统的分布式协作开发工作，研制出一套系统设计工具的集成平台，并 提供相应的数据访问协议，实现系统设计工具之间的分布式协作。 综合电子信息系统是一类复杂的人机交互系统，系统的研制风险很大。目前， 研制单位在进行综合电子信息系统的需求分析、总体规划、指标论证、总体设计 时，主要依据的还是以往的经验，缺乏完整、科学的方法指导和有效的技术手段 及工具支持，设计分析过程和内容也缺乏统一的规范和要求，系统的研制风险较 大。 本项目提供了一种重要思路与手段，采用基于仿真和组件的系统集成设计概 念、内容及过程，建立面向综合电子信息系统的分布式协作开发环境( 以下简称 为分布式协作开发环境) 。它有以下几个特点： 一、分布式协作开发环境中既包含一组基于仿真的系统设计工具，也包含一 组基于组件的系统设计工具，这些工具中既有自行研制的工具，也有商品化的工 具软件。 二、在完成同一设计任务时设计结果能够在不同工具之间相互衔接与利用， 使用不同工具完成同一设计任务的流程能够平滑相连。 三、设计工具的插件化使得分布式协作开发环境具有可扩充性。 四、工具的集成应当与组件的集成相互协调，尽可能采用一致的集成规范。 因此，作为建立分布式协作开发环境的重要工作之一，有必要进行有针对性的系 统设计工具集成技术研究。 1 2 研究目标、内容与关键技术 本项目的研究目标是研究面向分布式协作开发环境的系统设计工具集成技 术，研制分布式协作开发环境中的开放式、可扩展的系统设计工具集成框架，实 现对基于组件的系统设计工具的集成，为提高综合电子信息系统的开发水平提供 有效的、实用的支持。 本项目的- 丰要研究内容是： 研究内容l 与协作单位合作研究分布式协作开发环境中工具的集成方法与 2 基丁混合语言的w e b 服务容器的设计与实现 集成手段，研制系统设计工具集成框架，并将其加入分布式协作开发环境。 研究内容2 研究系统设计工具之间的数据交换规范和数据格式转换机制，并 将其加入到集成框架中。 研究内容3 研究系统设计工具的数据统一管理技术，研制透明的数据管理与 访问服务平台，并将其加入到工具集成框架中。 研究内容4 研究针对系统设计工具的统一管理、控制与协同机制，并将其加 入到工具集成框架中。 研究内容5 在集成框架上集成一组分布式协作开发环境中的系统设计工具。 1 2 1 研究目标 本项目的研究目标是研究面向分布式协作开发环境的系统设计工具集成技 术，研制分布式协作开发环境中的开放式、可扩展的系统设计工具集成框架，实 现对基于仿真的系统设计工具和基于组件的系统设计工具的集成，为提高综合电 子信息系统的开发水平提供有效的、实用的支持。 1 2 2 关键技术 关键技术1 ：分布式协作开发环境中系统设计工具的可扩充集成支持技术，包 括基于元数据驱动的插件支撑机制等。 关键技术2 ：分布式协作开发环境中各类系统设计工具的数据转换技术，特 别要考虑分布式协作开发环境中可用的各种商品化工具的数据特征。 关键技术3 ：分布式协作开发环境中系统设计工具间的协同控制机制，包括 系统设计工具间数据流和控制流的表示规范及其执行引擎技术。 关键技术4 ：分布式协作开发环境中各类系统设计工具的数据集中管理与访 问技术，包括数据集中存储、版本控制、统一访问支撑机制。 关键技术5 ：分布式协作开发环境中系统设计工具的跨平台集成支持技术， 包括可屏蔽平台差异的脚本语言解释执行机制，跨平台数据通信消息通信机制， 跨平台数据转换机制等。 1 3 项目组工作简介 本项目研制的系统设计工具集成平台，包括以下几个部分：面向用户的工具 层、用于工具集成的插件支撑层、提供相关功能服务和数据格式转换的服务容器 层、网络层、统一数据服务层、协同控制层和服务管理层。系统设计工具集成框 架的总体结构如图1 1 所示： 第一章绪论 廖 夯 筒 岱 二= = = 2 i f 2 = = ：= f = = 2 2 = = = = i f 陌而蒋硐门丽砥吲而丽秤 州堡堑苎查皇塑l 捌丝! 堡查芝堂f 一苎! 竺查! 蚓1i 系统设计i ：具集成框架总体结构蚓 针对分布式协作开发环境对设计工具集成的要求，木项目采用咀数据集成为 丰，在其基础卜进步研究应用程序接口集成、协同控制集成和共同人机界面燕 成的研究思路，将整个集成框架分解为四个层次：插件支撑层、服务容器层、统 一数据服务层和协同摔制层。 、插件支撑层 在一体化、分布式协作开发环境中，由于待集成工具的多样性，工具对外界 提供的数据和功能各不相同协作开发环境获取工具数据和功能的方式也相善甚 远。为达到1 具间的互联、瓦通和百操作目的，统一数槲获取和功能调用的方式 是p 分必要的。 插件支撑层的日的在r 对工具进行封装，并将工具咀插件的形式集成到分布 式协作开敏环境中，屏蔽不同工具在数据和功能访问上的差异，为协作控制层和 统一数据服务层提供透明的、无莲异的数据访问和功能调用，从而为数据集成、 应用程序接口集成奠定基础。另外，插件支撑层也可根据开技环境的要求，进行 黛一幕黑一蒹 一 可服 孵务斧理 4 基丁混合语言的w e b 服务容器的设计与实现 一定程度的共同人机界面集成，实现集成工具的统一管理。因此，插件支撑层集 中解决数据提供、功能提供和部分数据转换问题。 二、服务容器层 服务容器为服务提供运行环境，接受、解析服务请求，并调用相应的服务与 返回服务计算结果。服务容器中服务所需的核心计算将由插件层提供。 服务请求将采用语言中立的消息通信方式。服务请求者将调用服务所需的参 数封装在x m l 格式的s o a p 消息中，再将s o a p 消息封装在高层应用协议中( 如 h t t p 、f t p 、s m t p 等) ，封装完毕的协议流通过服务容器和网络组件发送到服务 所在机器节点，并由该节点上的服务容器进行逆向协议解析，从而获得调用服务 所需参数。 一旦服务容器通过网络组件获取服务计算所需参数，将直接调用插件运行并 传递参数，插件运行时将进行参数的组装并调用工具自身接口，服务计算完成后， 将计算结果返回到服务容器，由服务容器再次将计算结果封装为特定的协议并发 送回服务请求者。 三、统一数据服务层 统一数据服务提供与数据存储和数据访问相关的接口集合。工具数据应尽可 能被其它协作者或工具所使用，为避免工具在数据上产生相互依赖，统一数据服 务层集中所有的工具数据进行统一的存储和访问管理，并提供一致的数据访问服 务；为实现数据的统一，还需提供数据对象转换服务。 四、协同控制层 在数据集成的前提下，协同控制集成完成工具之间数据和功能的组织、安排 与调度，达到工具之间数据流和控制流的平滑相连。 采用工作流脚本描述语言，表示协作环境中工具在数据上的前后传递关系以 及功能上的前后调用顺序，并通过工作流引擎对工作流脚本的解释以及透明的远 程服务调用，实现数据在内部网络中各个工具节点间的传递和工具局部能力的组 装，构建面向综合电子信息系统的专用开发环境。 工作流执行引擎负责分布式协作流程的执行；服务容器中的执行引擎则负责 本地功能的组装，并可将组装的功能以一个服务的形式提供给分布式协作开发环 境。通过对工作流引擎和本地引擎的利用，可达到提高本地组装能力和减少网络 传输负载的目的。 工作流引擎的实施可分为两个阶段：工作流部署阶段和工作流执行阶段。工 作流部署阶段主要是工作流设计人员通过工作流设计工具，针对其具体要求，对 设计开发人员进行安排与布置，将分布式环境下各个机器节点提供的服务进行合 理装配。完成工作流部署后，工作流引擎将工作流转换成中间表示形式。工作流 的执行阶段对中间表示形式进行解析，并根据工作流的部署要求，为木地或远程 第一章绪论 服务准备所需数据，通过服务容器和网络组件将数据进行封装和传输，发出服务 请求到目的机器节点并等待服务请求的返回。 1 4 1 国外研究现状 1 4 国内外研究现状 目前，美国、俄罗斯、以色列等都十分重视系统集成设计过程的一体化建设。 在综合电子信息系统的集成设计与分析技术领域，研究工作主要可以分成三个方 面。首先，针对系统设计内容和过程，创造和发展了多种系统设计方法与技术， 如c 4 i s r 体系结构框架、系统快速原型法、面向对象设计、基于组件的设计等， 相应地开发了多种商品化的系统设计工具，如c 4 i s r a r c h i t e c t f r a m e w o r k 、s y s t e m a r c h i t e c td e s i g n e r 、s t k 、o p e n n a 设计分析工具等；其次，建模与仿真被用作系 统设计分析与评估的丰要手段和工具，例如利用仿真试验床或仿真系统来仿真分 析和评估上述设计方法和工具所得到的系统模型，根据仿真试验结果对系统设计 进行修改和优化等：第三，综合集成上述两个方面的技术、方法及工具，建立了 集设计、建模与仿真、测试评估等功能于一体的分布式协作开发环境，以满足复 杂大系统的一体化设计与分析的需要。 在分布式协作开发环境中，设计工具的集成是其中的一个关键环节。目前， 国外已经有一些开发环境在集成软件过程中多阶段开发工具与开发结果方面提供 了有效的支持，典型的有e c l i p s e 、r a t i o n a lx d e ( e x t e n d e dd e v e l o p m e n t e n v i r o n m e n t ) 、r s a ( r a t i o n a ls o f t w a r ea r c h i t e c t ) 、v i s u a ls t u d i o2 0 0 5t e a ms y s t e m 和r h a p s o d y 。 、e c l i p s e e c l i p s e 是一个开放源码、基于j a v a 的可扩展开发平台，它提供了一个框架和 一组服务，通过插件式的组件来构建开发环境，支持基于g u i 和非g u i 的应用开 发环境，且独立于语言和运行平台。e c l i p s e 的核心组件包括：插件开发环境( p l u g - i n d e v e l o p m e n te n v i r o n m e n t ，p d e ) 、j a v a 开发工具集和e c l i p s e 平台，其底层由标 准j a v a 2 虚拟机支持。 二、r a t i o n a lx d e i b m 的r a t i o n a lx d e 是一个覆盖整个软件开发生命周期的设计、编码、测试、 团队沟通与构建文档的集成开发环境。它综合了软件分析、设计、程序开发以及 自动化测试，并以i b mw e b s p h e r es t u d i ow o r k b e n c h 或m i c r o s o f tv i s u a l s t u d i o n e t 作为基础平台。 三、r s a 6 基于混合语言的w e b 服务容器的设计与实现 i b m 的r s a 是一套设计与开发工具，它借助于u m l 2 0 技术实现了模型驱动 的软件开发模式。r s a 作为i b mr a t i o n a l 业务驱动软件开发平台的核心部件，提 供了需求管理工具、测试工具、配置与变更管理工具、项目管理工具的集成支持。 r s a 中，提供了u m l 到j a v a 、u m l 到c + + 、u m l 到e j b 的模型转化机制，为 模型驱动软件开发( m d a ) 的模型转换提供了多侧面的工具支持。 四、v i s u a ls t u d i o2 0 0 5t e a ms y s t e m 微软的v i s u a ls t u d i o2 0 0 5t e a ms y s t e m 包含了项目管理人员、架构师、开发 人员、测试人员、开发管理人员所使用的一组工具。它支持用户界面集成、数据 集成和过程集成，同时也支持用户界面、数据、过程三个方面的可扩展性。通过 使用一个公共的、跨工具集的数据仓库，v i s u a ls t u d i o2 0 0 5t e a ms y s t e m 解决了 在大多数软件开发生存周期工具中建立数据仓库这一问题，并肩动了一个聚合的 项目状态视图，团队根据能够收集到的规则来管理项目。 五、r h a p s o d y r h a p s o d y 是基于模型驱动的、面向嵌入式应用软件开发的可视化建模与开发 工具，广泛用于系统建模，使得用户在系统建模时无需关注软件实现的细节，将 重点放在系统高层的功能划分、结构分解、行为规范和需求分析上。 综上所述，国外丰流的商品化开发环境与工具都向着一体化以及集成设计和 开发的方向发展，反映出目前软件工程方法和工具的应用与发展趋势。然而，这 些开发环境与工具没有提供对基于仿真的开发过程与设计工具的必要支持，不能 直接运用到综合电子信息系统的建模、设计、仿真、评测评估中。 但是，上述国外商品化开发环境与工具中采用的一些先进技术，如：插件式 可扩充开发平台( 如e c l i p s e ) ，模型驱动的软件开发模式( 如r s a 、r h a p s o d y ) ， 支持用户界面集成、数据集成和过程集成( 如v i s u a ls t u d i o2 0 0 5t e a ms y s t e m ) 等， 这些对于分布式协作开发环境既是开展研究的可行性依据，也是可借鉴的技术基 础。 1 4 2 国内研究现状 国内在基于组件的综合电子信息系统设计方法以及分布式协作开发环境的建 立和应用方面基本处于空白，没有将系统设计方法及过程有机地结合起来，没有 形成基于组件的系统集成设计概念、方法及技术。但是在相关技术领域( 如指控 系统建模与仿真、系统设计工具等) 已经开展了研究与应用工作。国内在这些领 域的研究成果为开展基于组件的综合电子信息系统设计技术研究工作奠定了基 础。 可见，国内在设计工具集成方面的研究相对国外起步比较晚，在集成技术的 第一章绪论 7 研究面也相对比较窄。尽管如此，以上研究成果也为我们进一步研究工具集成提 供了一定的工作基础。同时也可以看到，开展面向基于组件的系统设计工具的集 成方法和技术的研究工作已经迫在眉睫。 1 5 论文的工作介绍 如图1 1 所示，在数据集成的前提下，分布式协作开发环境可以协同控制集成， 完成工具之间数据和功能的组织、安排与调度，达到工具之间数据流和控制流的 平滑相连的目的。 在插件支持层之上构建服务容器层，可以为通过插件支持层开发的服务提供 运行环境，接受、解析服务请求，并调用相应的服务与返回服务计算结果。服务 容器为内部网络中各个工具节点间的数据传递和功能的协同交互提供统一的透明 的通讯基础设施，辅助构建面向综合电子信息系统的专用开发环境。本项目采用 w e b 服务技术构建服务容器的整体框架。目前有着很多w e b 服务工具实现，但是 根据集成对象的特点和插件支持层的要求，决定使用c h 卯y t h o n 混合语言自行研 制w e b 服务容器r c w s c 。本文着重介绍r c w s c 服务容器的核心架构和相关扩 展机制的设计与实现。 1 6 论文的组织结构 本文共分七章，第一章为绪论，介绍了本文工作的研究背景与意义。第二章 列举了研究过程中涉及到的关键理论和技术。第三章分析了r c w s c 服务容器的 基础结构的设计问题与实现方法，包括容器整体结构的介绍和核心框架的设计。 第四章从协议扩展的角度，研究了w e b 服务技术为异构平台之间进行良好的开放 式互操作而提供的机制，并介绍了r c w s c 服务容器对机制的支持实现。第五章 介绍了r c w s c 服务容器的关键组件一服务调用组件以及p y t h o n 调用引擎的设计。 第六章在项目背景下比较了r c w s c 服务容器与现有的w e b 服务实现工具。最后 一章对本文所做的工作进行了概括性的总结并提出了对下一步工作的设想。 第二章r c w s c 服务容器设计与实现的相关技术 9 第二章r c w s c 服务容器设计与实现的相关技术 2 1s o a 技术 面向服务的架构( s e r v i c e o r i e n t e d a r c h i t e c t u r e ，s o a ) 是一个组件模型l lj ，它 将应用程序的不同功能单元一服务( s e r v i c e s ) 通过服务间明确定义的接口和契约 联系起来。接口采用中立的方式定义，独立于具体实现服务的硬件平台、操作系 统和编程语言，使得在这样的系统中所构建的服务可使用统一和标准的方式进行 通信。因此，对于分布式协作开发环境的分布式开发要求与集成更广泛的设计工 具，s o a 具有积极的支持作用。 s o a 又是在计算环境下设计、开发、应用、管理分散的逻辑( 服务) 单元的 一种规范。这个定义决定了s o a 的广泛性：s o a 要求开发者从服务集成的角度来 设计应用软件；s o a 要求开发者超越应用软件来思考，并考虑复用现有的服务， 或者检查如何让服务被重复利用；s o a 鼓励使用可替代的技术和方法( 例如消息 机制) ，通过把服务联系在一起而非编写新代码来构架应用。经过适当构架后，这 种消息机制的应用允许企业仪通过调整原有服务模式而非被迫进行大规模新的应 用代码的开发，使得在商业环境许可的时间内对变化的市场条件做出快速的响应。 与传统的应用集成技术不同的是，在s o a 中，围绕服务的所有模式都以基 于标准的技术来实现。大部分的通信中间件系统，如r p c 、c o r b a 、d c o m 、 e j b 和r m i 等也同样如此，但它们的实现都不是很完美的，在权衡交互性以及标 准定制的可接受性方面总是存在问题。s o a 试图排除这些缺陷。几乎所有的通信 中间件系统都有固定的处理模式，如r p c 的功能、c o r b a 的对象等，而服务既 可以定义为功能，又可同时对外定义为对象、应用等，这使得s o a 可适应于任 何现有系统，并使得系统在集成时不必刻意遵循任何特殊定制【2 j 。 s o a 帮助企业信息系统迁移到“l e a v e a n d 1 a y e r 架构之上，这意味着在不用 对现有的企业信息系统进行修改的前提下，系统可对外提供w 曲服务接口。这是 因为，它们已经被可以提供w e b 服务接口的应用层做了一层封装，因而在不用修 改现有系统架构的情况下，s o a 可以将系统和应用迅速转换为服务。s o a 不仪覆 盖来自于打包应用、定制应用和遗留系统中的信息，而且还覆盖来自于如安全、 内容管理、搜索等i t 架构中的功能和数据。因为基于s o a 的应用能很容易地从 这些基础服务架构中添加功能，所以基于s o a 的应用能更快地应对市场变化，使 企业业务部门设计开发出新的功能应用。 l o 基丁二混合语言的w e b 服务容器的设计与实现 2 2w e b 服务 w e b 服务技术是s o a 架构的实现方式之一。使用w 曲服务技术p j ，应用程 序可以通过与平台和编程语言无关的方式相互通信。w e b 服务是一个软件接口， 它描述了一组可以在网络上通过标准化的x m l 消息传递访问的操作。它使用基 于x m l 的协议来描述要执行的操作或者要与另一个w e b 服务交换的数据。在 s o a 中，一组以这种方式交互的w e b 服务定义了特定的w 曲服务应用程序。 软件业最终会接受这样的事实：跨多个操作系统、编程语言和硬件平台来集 成应用程序，不可能由任何一种专门的环境来解决。传统的做法是，调用远程应 用的程序通过自己发出的函数调用和请求的参数与远程应用紧密地联系在一起。 在w e b 服务出现之前，在大多数系统中采用的是固定的接口，但对于不断变化的 环境或需求，这样做缺乏灵活性和适用性。 w e b 服务所使用的x m l 4 】可以用真正与平台无关的方式来描述任何( 所有) 数据以跨系统交换数据，因此实现了应用程序间的松耦合方式。x m l 的通用性使 得w e b 服务不同于前一代组件技术，它允许语法结构( 句法) 与语法意义( 语义) 分离，每个服务处理和理解它的方式与它所存在的环境分离。因此，可以将某个 ( 些) 对象定义为一个服务，它可以与其他采用x m l 定义的语法的服务进行通 信，而每个服务又可以根据其本地实现和环境来转换和分析消息。因而，网络应 用程序实际上可以由各种实体组成，只要这些实体符合它们面向服务的体系结构 即可。另外，w e b 服务可以在较抽象的层面上工作，在这样的层面上可以按照需 要动态地重新评估、修改或处理数据类型。所以，从技术上来看，w e b 服务可以 更方便地处理数据，并且允许软件更自由地进行通信。 从更高的概念层面上来看，我们可以将w e b 服务视为一些工作单元，每个单 元处理特定的功能任务。再往上一步，可以将这些任务组合成面向业务的任务， 以处理特定的业务操作任务，从而使非技术人员可以考虑一些应用程序，这些应 用程序能够在w e b 服务应用程序工作流中一起处理业务问题。因此，一旦由技术 人员设计并构建好w e b 服务之后，业务流程架构师就可以聚集这些w e b 服务来 解决业务层面上的问题。这里借用汽车引擎来做类比，业务流程架构师考虑将整 个汽车引擎与汽车框架、车身、变速器和其他系统组合在一起，而不是研究每个 引擎内的各个部件。而且，动态平台意味着引擎可以与其他汽车制造商的变速器 或部件一起工作。所以，w e b 服务试图解决的丰要问题是数据和应用程序集成的 问题，以及将技术性的功能转换为面向业务的计算任务的问题。这两个方面使企 业可以就流程或应用程序层面与他们的合作伙伴进行交流，同时为适应新形势或 按照需要与不同合作伙伴进行合作留有动态变更的余地。 第二章r c w s c 服务容器设计与实现的相关技术 1 1 采用s o a 的思想，使用w e b 服务技术对工具进行集成，将待集成工具的能力 包装为服务，通过调用服务接口实现对工具功能的使用，并在此基础上构建服务 容器为这些服务提供运行时的环境，使得服务的开发者能够从平台之间的通讯交 互处理中解脱出来。这可以大大简化工具集成的复杂性，并为集成人员提供了更 为便捷的开发环境。 2 3s o a p 协议 s o a p 5 1 ( s i m p l eo b j e c t a c c e s sp r o t o c o l ，简单对象访问协议) 技术有助于实现大 量异构程序和平台之间的互操作性，从而使存在的应用能够被广泛的用户所访问。 s o a p 是把成熟的基于h t t p 的w e b 技术与x m l 的灵活性和可扩展性组合在了 一起。 s o a p 的一个主要目标是使现存的应用能被更广泛的用户所使用。为了实现这 个目的，没有任何s o a pa p i 或s o a p 对象请求代理( s o a po r b ) ，s o a p 是假 设你将使用尽可能多的存在的技术。几个丰要的c o r b a 厂商已经承诺在他们的 o r b 产品中支持s o a p 协议。微软也承诺在将来的c o m 版本中支持s o a p 。 d e v e l o pm e n t o r 已经开发了参考实现，它使得在任何平台上的任何j a v a 或p e r l 程 序员都可以使用s o a p 。而且i b m 和s u n 也陆续支持了s o a p 协议，和m s 合作 共同开发s o a p 规范和应用。目前s o a p 已经成为了w 3 c 和i e t f 的参考标准之 一o s o a p 的关注点在于异构平台之间的互操作性。它可以很好的弥补c o r b a 等 技术在互操作上的弱点。s o a p 开发的特性使得在异构计算环境中的系统无缝的进 行通讯和共享数据成为可能，从而在i n t e m e t 环境下消除信息孤岛，实现信息共享 和数据交换，达到信息的一致性【6 】。 s o a p 协议包括四个部分：s o a p 封装( e n v e l o p ) ，封装定义了一个描述消息中 的内容是什么，是谁发送的，谁应当接受并处理它以及如何处理它们的框架；s o a p 编码规则( e n c o d i n gr u l e s ) ，用于表示应用程序需要使用的数据类型的实例；s o a p r p c 表示( r p cr e p r e s e n t a t i o n ) ，表示远程过程调用和应答的协定；s o a p 绑定 ( b i n d i n g ) ，使用底层协议交换信息。 s o a p 消息是一个x m l 文档，包括一个必需的s o a p 封装，一个可选的s o a p 头和一个必需的s o a p 体。一个s o a p 消息包括以下部分：1 、在表示这个消息的 x m l 文档中，封装是顶层元素。2 、应用s o a p 交换信息的各方是分散的且没有 预先协定，s o a p 头提供了向s o a p 消息中添加关于这条s o a p 消息的某些要素 ( f e a t u r e ) 的机制。s o a p 定义了少量的属性用来表明这项要素( f e a t u r e ) 是否可选 以及由谁来处理。3 、s o a p 体是包含消息的最终接收者想要的信息的容器。s o a p 1 2 基丁混合语言的w e b 服务容器的设计与实现 还为s o a p 体定义了一个f a u l t 元素用来报告错误信息。 s o a p 头元素为相互通信的团体之间提供了一种很灵活的机制：在无须预先协 定的情况下，以分散但标准的方式扩展消息。可以在s o a p 头中添加条目实现这 种扩展，典型的例子有认证，事务管理，支付等等。头元素编码为s o a p 封装元 素的第一个直接子元素。头元素的所有直接子元素称作条目。 s o a p 体元素提供了一个简单的机制，使消息的最终接收者能交换必要的信 息。使用体元素的典型情况包括配置r p c 请求和错误报告。体元素编码为s o a p 封装元素的直接子元素。如果已经有一个头元素，那么体元素必须紧跟在头元素 之后，否则它必须是s o a p 封装元素的第一个直接子元素。体元素的所有直接子 元素称作体条目，每个体条目在s o a p 体元素中编码为一个独立的元素。 w 曲服务技术使用s o a p 协议作为主要的信息传递载体，并且制定了一系列 的规范和标准利用s o a p 头元素的扩展机制来应对服务请求者与服务提供者在交 互过程中所需的诸如信息安全、可靠性传递等非功能性的需求。这些规范和标准 被称为w e b 服务扩展规范。大多数w e b 服务技术实现工具都提供了对这些规范的 扩展支持。其中功能较强、灵活性较高的支持方式是构建服务容器为服务开发者 实现的应用程序提供运行时环境，并由服务容器承担对服务交互信息的处理，从 而使得开发者从繁琐的交互处理中解脱出来，可以专注于服务功能的实现。 目前常见的服务容器所提供的服务开发方法丰要是根据服务描述信息生成数 据绑定框架文件。在这些文件中，服务开发者通过接口可以获得记录了请求信息 的s o a p 消息表示实例或者直接获得由框架根据s o a p 消息生成的应用程序所需 的数据对象实例。然而这些框架文件使得服务的功能逻辑与容器的处理逻辑绑定 在一起，产生了紧耦合。使用单一的静态语言实现服务容器则为服务开发工作引 入了大量的手工操作。而使用单一的动态语言虽然可以节省编译工作量，但是其 实现的服务容器与静态语言实现的容器相比会损失部分的处理效率。如何在保证 效率的前提下降低容器与服务的耦合度从而减少服务开发的人工工作量正是本文 所关注的丰要问题 2 4b o o s t p y t h o n b o o s t p y t h o n 。7 】是一个开源的c + + 库。它提供了一个简明的i d l 式的接1 3 用于 绑定c + + 的类和函数到p y t h o n 。b o o s t p y t h o n 使得程序员在运用c + + 高效的编译期 多态性和p y t h o n 便利的运行期多态性时能够获得易用性和一致性【8 】。 c + + 语言的静态类型系统为应用程序提供了较高的执行效率，而p y t h o n 的 动态类型系统则使得应用程序具有较强的灵活性。两者的特性可以形成互补。 p y t h o n 程序内性能瓶颈的部分可以用c + + 重写以提高运行速度。c + + 程序则可以选 第二章r c w s c 服务容器设计与实现的相关技术 1 3 择p y t h o n 作为中间件语言灵活简便的集成各个模块。 b o o s t p y t h o n 使用c + + 语言实现了一个p y t h o n 封装系统。它为程序员提供了 高级的c + + 接口用于封装c h 类和函数，并隐藏了内部复杂的处理动作。它从函 数类型声明中获取大部分封装所需的信息。参数类型决定了使用哪一种方式从 p y t h o n 对象中取得c h 参数，而返回类型决定了函数返回值怎样从c + + 转换到 p y t h o n 。这种方法引入了用户指导封装，使得被封装的源代码几乎可以将所有的信 息都导入到p y t h o n 中。虽然这个过程需要用户显示的提供一些额外的信息，但是 由于接口的规范与源代码具有同样的特性，所以用户几乎不需要对封装过程进行 什么实际的干涉。 b o o s t p y t h o n 封装了引用计数管理和p y o b j e c t 指针管理，使得用户不必再使用 容易出现错误的c 风格的接口。同时，它还为基于组件的开发提供了支持，允许 一个扩展模块中的c + + 导出类型可以被传递到另外一个模块导出的函数内应用， 而且不会丢失诸如c + + 继承关系这样的重要信息。另外，由于b o o s t p y t h o n 的封 装是非干扰性的，所以它能够封装只有h e a d e r 文件和二进制文件的第三方程序库。 b o o s t p y t h o n 使得静态语言实现的程序可以便捷的使用p y t h o n 的动态数据绑 定技术在运行时生成动态数据对象。而p y t h o n 语言本身提供了使用动态数据对象 进行程序调用的方法，从而使得静态语言程序根据描述信息实现对任意程序的调 用成为可能。 项目中插件支持层利用b o o s t p y t h o n 的特性提供自动生成技术，将系统设计工 具的功能统一封装成具有p y t h o n 接口的服务实现。在此基础上，服务容器层在c + + 程序中通过b o o s t p y t h o n 和p y t h o nca p i 的支持实现了对这些服务实现的动态调 用，为容器和服务之间引入了动态语言层，降低了容器和服务的耦合度。 第二章r c w s c 服务容器的核心框架 1 5 第三章r c w s c 服务容器的核心框架 3 1r c w s c 服务容器的设计目标 服务容器为部署在服务端的服务实现提供了运行时环境，使得这些服务实现 只需关心与服务容器接口的交互，而不必应对复杂的应用环境。容器提供插件机 制以允许使用插件来扩展容器的能力或改善容器的性能，使得用户可以迅速的应 对应用环境的快速变化【9 】。因此，r c w s c 服务容器的主要设计目标之一就是可动 态扩展的组件化的核心框架，并提供灵活的扩展机制。 w e b 服务技术使用一系列的协议来完成服务请求者和服务提供者之间的消息 传递以及满足交互过程中的非功能性需求。服务容器允许使用者根据需要灵活的 可配置的对这些协议的进行有选择的支持。r c w s c 服务容器在设计时需要提供针 对协议的扩展机制，来保证实现了协议处理的扩展组件能够正确的协同工作。 服务容器的另一个主要功能是为服务开发者提供便捷的服务开发方法，并在 运行时根据接收到的调用信息调用相应的服务。这些服务包括简单服务和组合服 务。这两类服务在物理形式和调用方法上均存在差异。因此，r c w s c 服务容器的 的另一个主要设计目标是采取适当的方案降低容器和服务之间的耦合度，减少服 务开发过程的人工工作量，并在服务调用处理环节提供对多种服务调用方式的支 持。 本章主要介绍的是r c w s c 服务容器核心框架的设计。后两章分别介绍了容 器协议扩展机制的设计和服务开发和调用处理的设计。 3 2r c w s c 服务容器的基础架构 3 2 1 服务容器整体结构 下图显示了r c w s c 服务容器整体结构的组件视图： 一r 一 一一一一j _ 一一j 一。一j 一一。一。一。一。一一 m o d u l e f r a m e w o r k ( p h a s e p o l i c y 、h a n d 】e r c o n t a i n e r e n s m e 、p h a s e 、 m a n a g e m e n t h a n d l e r f a c t o r y ) s o a pm e s s a g em o d e l d o m 图3 1r c w s c 服务容器组件视图 1 6 基丁混合语言的w e b 服务容器的设计与实现 ( 1 ) s o a p 消息模型 s o a p 消息模型提供了与服务请求消息相对应的数据表示方法。该模型构建在 d o m 解析器之上。模型记录了服务请求处理流程中所需的关键信息，是服务容器 的中心数据。s o a p 消息模型需要尽量保证关键信息的完备性并使得消息表示独立 于特定的应用处理动作。这些关键信息主要包括： 原始消息：原始消息是指携带了s o a p 消息的协议消息以及s o a p 消息本身。 这些内容为容器提供了基本的处理对象。将s o a p 消息和协议消息分开是考虑到 在某些特殊的应用场景中可能要求转发s o a p 消息的完整内容。 服务信息：服务信息与客户端的请求意图相对应。它包括所要访问的服务名 称、操作名称以及动作( a c t i o n ) 。这些信息出现的位置并不固定，可能被记录在 协议消息中或出现在s o