（计算机软件与理论专业论文）一种web服务代理自动生成工具.pdf

摘要 摘要 w e bs e r vic e 技术是目前企业应用集成领域的主流技术。它提供一种致编程 模型，从而在企业信息系统内外都可以利用通用的基础设施，并可采用通用的、增 量的方式进行应用程序集成。通常，对已有工具的集成是通过为其编写转调代码 ( 服务代理) 的方法来实现的，然而在已知工具所使用的开发技术的情况下，所 编写的转调代码是相似的。如果每次在集成相同类型工具时都由程序员手工编写 转调代码，则会增加许多重复性工作。 本文的研究目标是针对上述问题，研究现有的工具集成方法，在此基础之上 根据所涉及研究课题的要求，提出并实现一种实现服务代理生成自动化的解决方 案。 论文首先研究了w e bs e r v i c e 及服务代理自动生成的相关理论和技术，在现有 研究的基础上以自动编译为主要技术路线，利用待集成工具所使用开发技术的共 性，使用m a k e 作为自动编译工具，按照分层的思想给出服务代理自动生成工具 ( r c s a t ，r e p a c ec e n t e rs e r v i c ea g e n tt 0 0 1 ) 的体系结构设计与实现( 该框架分为 控制、功能和信息层等几个层次) ，本文还为其实现了一个生成器，并通过一个 背景项目中实际的测试用例，对r c s a t 的功能进行了检验。最后，对当前工作进 行了总结，并对未来工作方向给出了一些建议。 关键词：服务代理元信息m a k e f d ep y t h o n 扩展 a b s t r a c t a b s t r a c t w e bs e r v i c ei st h em a i ns o l u t i o nf o re n t e r p r i s ea p p l i c a t i o ni n t e g r a t i o n ( e a i ) i t p r o v i d e sak i n do fc o n s i s t e n tp r o g r a mm o d e l ，s oa l l i n f r a s t r u c t u r e sa r ea v a i l a b l ef o r e i t h e re n t e r p r i s ei n n e ro re x t e r i o r w e bs e r v i c ec a i li n t e g r a t ea p p l i c a t i o n si nag e n e r a l a n di n c r e m e n t a lw a y t h em e t h o do fi n t e g r a t i n ge x i s t e dt o o l si st og e n e r a t et h ea g e n t c o d e sf o rt h e m w h e nt o o l s d e v e l o p m e n tt e c h n o l o g i e sa r ea l r e a d yk n o w n ，t h e i ra g e n t c o d e sa r es i m i l a r i ft h et y p e so ft h ei n t e g r a t e dt o o l sa r ei d e n t i c a l ，t h er e p e a t e dw o r k l o a d w i l lb ei n c r e a s e d t os o l v et h ea b o v ep r o b l e m s ，t h i sp a p e rs t u d i e so na l la p p r o a c ho f t o o l si n t e g r a t i o n a n dt h e np r o p o s e sas o l u t i o nf o ra u t o m a t i c a l l yg e n e r a t i n gs e r v i c ea g e n t f i r s t l y ，t h et h e o r i e sa n dk e yt e c h n o l o g i e sw h i c h a r er e l a t e dt ow e bs e r v i c ea n dt h e g e n e r a t i o no fs e r v i c ea g e n t s a r es h o w e di nt h i sp a p e r b a s e do nt h ea n a l y s i sa n d r e s e a r c ho nt h ee x i s t i n gt e c h n o l o g y , at o o ln a m e dr c s a t ( r e p a c ec e n t e rs e r v i c e a g e n tt o o l li sp r e s e n t e d i tu s e s m a k e ”a sa u t o c o m p i l e t 0 0 1 t h i sf r a m e w o r ki n c l u d e s t h r e el a y e r s ：c o n t r o l l e rl a y e r ，f u n c t i o nl a y e ra n di n f o r m a t i o nl a y e r i na d d i t i o n ，w et e s t e d t h ef u n c t i o n so fr c s a tb yat e s tc a s e a tl a s t ，w es u m m a r i z e de x i s t i n gw o r ka n d p r e s e n t e ds o m ea d v i c e sf o rt h ef u t u r er e s e a r c h k e y w o r d s ：s e r v i c ea g e n t m e t a - l n f o r m a t i o nm a k e v d ep y t h o ne x t e n s i o n 创新性声明 本人声明所呈交的论文是我个人在导师的指导下进行的研究工作及取得的研 究成果。尽我所知，除了文中特别加以标注和致谢中所罗列的内容以外，论文中 不包含其他入已经发表或撰写过的研究成果，也不包含为获得西安电子科技大学 或其他教育机构的学位或证书而使用过的材料。与我同工作的同志对本研究工 作所做的任何贡献均已在论文中作了明确的说明并表示了谢意。 申请学位论文若有不实之处，本人承担一切相关责任。 本人签名：础 日期： 关于论文使用授权的说明 本人完全了解西安电子科技大学有关保留和使用学位论文的规定，即：研究 生在校攻读学位期间论文工作的知识产权单位属西安电子科技大学。本人保证毕 业离校后，发表论文或使用论文工作成果时署名单位仍然为西安电子科技大学。 学校有权保留送交论文的复印件，允许查阅和借阅论文；学校可以公布论文的全 部或部分内容，可以允许采用影印、缩印或其他复制手段保存论文。( 保密的论文 在解密后遵守此规定) 本学位论文属于保密在年解密后适用本授权书。 本人签名： 导师签名： 第一章绪论 第一章绪论 1 1 项目背景 本论文的工作来源于项目“系统设计工具集成技术研究”。该课题主要面向 综合电子信息系统的分布式协作开发工作，研制出一套系统设计工具的集成平台， 并提供相应的数据访问协议，实现系统设计工具之间的分布式协作。 综合电子信息系统是一类复杂的人机交互系统，系统的研制风险很大。目前， 研制单位在进行综合电子信息系统的需求分析、总体规划、指标论证、总体设计 时，主要依据的还是以往的经验，缺乏完整、科学的方法指导和有效的技术手段 及工具支持，设计分析过程和内容也缺乏统一的规范和要求，系统的研制风险较 大。 本项目提供了一种思路与手段，即采用基于仿真和组件的系统集成设计概念、 内容及过程，建立面向综合电子信息系统的分布式协作开发环境( 以下简称为分 布式协作开发环境) 。这种开发环境的主要特点是： 一、分布式协作开发环境中既包含一组基于仿真的系统设计工具，也包含一 组基于组件的系统设计工具。这些工具中既有自行研制的工具，也有商品化的工 具软件。 二、在完成同一设计任务时设计结果能够在不同工具之间相互衔接与利用， 使用不同工具完成同一设计任务的流程能够平滑相连。 三、设计工具的插件化使得分布式协作开发环境具有可扩充性。 四、工具的集成应当与组件的集成相互协调，尽可能采用一致的集成规范。 因此，作为建立分布式协作开发环境的重要工作之一，有必要进行有针对性 的系统设计工具集成技术研究。 1 2 研究目标、内容与关键技术 本项目的研究目标是研究面向分布式协作开发环境的系统设计工具集成技 术，研制分布式协作开发环境中的开放式、可扩展的系统设计工具集成框架，实 现对基于组件的系统设计工具的集成，为提高综合电子信息系统的开发水平提供 有效的、实用的支持。 本项目的主要研究内容是： 研究内容1 与协作单位合作研究分布式协作开发环境中工具的集成方法与 集成手段，研制系统设计工具集成框架，并将其加入分布式协作开发环境。 研究内容2 研究系统设计工具之间的数据交换规范和数据格式转换机制，并 2 一种w e b 服务代理自动生成工具 将其加入到集成框架中。 研究内容3 研究系统设计工具的数据统一管理技术，研制透明的数据管理与 访问服务平台，并将其加入到工具集成框架中。 研究内容4 研究针对系统设计工具的统一管理、控制与协同机制，并将其加 入到工具集成框架中。 研究内容5 在集成框架上集成一组分布式协作开发环境中的系统设计工具。 1 3 项目工作介绍 本项目研制的系统设计工具集成平台，包括以下几个部分：用于工具集成的 插件支撑层、提供相关功能服务和数据格式转换的服务容器层、统一数据服务层 和协同控制层。系统设计工具集成框架的总体结构如图1 1 所示： 1 插件支撑层：将待集成工具封装为插件，采用运行时支持机制调用插件 功能，屏蔽不同工具在数据和功能访问上的差异，为协作控制层和统一数据服务 层提供透明的、无差异的数据访问和功能调用，从而为数据集成、应用程序接口 集成奠定基础。另外，插件支撑层也可根据开发环境的要求，进行一定程度的共 同人机界面集成，实现集成工具的统一管理。因此，插件支撑层集中解决数据提 供、功能提供和部分数据转换问题。 2 服务容器层：为服务提供运行环境，接收、解析服务请求，并调用相应的 服务与返回服务计算结果。服务请求将采用语言中立的消息通信方式，由s o a p 技术实现。服务容器中服务所需的核心计算将由插件层提供。 3 统一数据服务层：统一数据服务提供与数据存储和数据访问相关的接口集 合。工具数据尽可能被其他协作者或者工具所使用，为避免工具在数据上产生相 互依赖，统一数据服务层集中所有的工具数据进行统一的存储和访问管理，并提 供一致的数据访问服务；为实现数据的统一，还需提供数据对象转换服务及版本 服务。 4 协同控制层：在数据集成的前提下，协同控制集成完成工具之间数据和 功能的组织、安排与调度，达到工具之间数据和控制流的平滑相连。 服务生成工具负责为分布式协作流程动态生成服务；服务容器中的主要负责响 应服务调请求，并将服务执行结果反馈给分布式协作开发环境。通过对服务生成 工具的使用，可提高工具集成的效率，减少集成开发人员的工作负担。 第一章绪论 疆 务 摄 送 l 系统设计工具i 系统设计工具2 l 系统设计工具3 1 分布式协作开il 分布式协作歼l1 分布戏协作开l 撼 卅发环境客户璇i 卅发环境客户端l 一发环境客户端i 堡 llilllii 口 j 【 ；! 毅鸯生成芏具 ； ! 撑 。 gi ， lg 崩 嘲- 酾- i - - t l - 一蓟i 甄鳓i 稚二 簧膏索 缆： 据据据 l 7 r b 刚l ；弓l 擎瑶；吲； 对访版 t 象阔 本 巅： 露 阻l。g芝lll 统一数据对象服务 据： 缪 雠用l 崮措i 文凸。薹| 乎 瑕 鬻 、琶章y 。j 、。一，l l l 飞i 一一一、一 l 图1 1 系统设计工具集成框架总体结构图 服务生成工具的使用可分为两个阶段：信息获取阶段和服务代理生成阶段。 信息获取阶段主要是由工具集成人员通过服务生成工具的用户界面根据待集成工 具的需要输入相应信息，服务生成工具将所获取到的元信息缓存于内建的数据结 构之中。完成信息获取工作后，服务生成工具对所获取的元信息进行分析，选择 与工具类型相匹配的服务代理生成控制器。在控制器的调度下各模块协同工作， 首先为服务代理生成中间代码并将其组织为个临时工程，m a k e f i m 生成模块为这 一工程生成相应的m a k e f i l e ，最后调用编译器的m a k e 工具生成服务代理的最终形 式：p y t h o n 扩展。 1 4 国内外研究现状 1 4 1 国外研究现状 在电子信息系统现代化水平比较高的国家，如美国、俄罗斯、以色列等，都 十分重视系统集成设计过程的一体化建设。在综合电子信息系统的集成设计与分 4 一种w e b 服务代理自动生成1 二具 析技术领域，研究工作主要可以分成三个方面。首先，针对系统设计内容和过程， 创造和发展了多种系统设计方法与技术，如系统快速原型法、面向对象设计、基 于组件的设计等，相应地开发了多种商品化的系统设计工具，如s y s t e ma r c h i t e c t d e s i g n e r 、s t k 、o p e n n e t 设计分析工具等；其次，建模与仿真被用作系统设计分 析与评估的主要手段和工具，例如利用仿真试验床或仿真系统来仿真分析和评估 上述设计方法和工具所得到的系统模型，根据仿真试验结果对系统设计进行修改 和优化等；第三，综合集成上述两个方面的技术、方法及工具，建立了集设计、 建模与仿真、测试评估等功能于一体的分布式协作开发环境，以满足复杂大系统 的一体化设计与分析的需要。 在分布式协作开发环境中，设计工具的集成是其中的一个关键环节。目前， 国外已经有一些开发环境在集成软件过程中多阶段开发工具与开发结果方面提供 了有效的支持，典型的有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 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 h a p s o d y r h a p s o d y 是基于模型驱动的、面向嵌入式应用软件开发的可视化建模与开发 工具，广泛用于系统建模，使得用户在系统建模时无需关注软件实现的细节，将 重点放在系统高层的功能划分、结构分解、行为规范和需求分析上。 综上所述，国外主流的商品化开发环境与工具都向着一体化以及集成设计和 开发的方向发展，反映出目前软件工程方法和工具的应用与发展趋势。然而，这 些开发环境与工具没有提供对基于仿真的开发过程与设计工具的必要支持，不能 直接运用到综合电子信息系统的建模、设计、仿真、评测评估中。 但是，上述国外商品化开发环境与工具中采用的一些先进技术，如：插件式 可扩充开发平台( 如e c l i p s e ) ，模型驱动的软件开发模式( 如r h a p s o d y ) ，支持 第一章绪论 用户界面集成、数据集成和过程集成等，这些对于分布式协作开发环境既是开展 研究的可行性依据，也是可借鉴的技术基础。 1 4 2 国内研究现状 国内在基于组件的综合电子信息系统设计方法以及分布式协作开发环境的建 立和应用方面基本处于空白，没有将系统设计方法及过程有机地结合起来，没有 形成基于组件的系统集成设计概念、方法及技术。但是在相关技术领域( 如指控系 统建模与仿真、系统设计工具等) 已经开展了研究与应用工作。国内在这些领域的 研究成果为开展基于组件的综合电子信息系统设计技术研究工作奠定了基础。 可见，国内在设计工具集成方面的研究相对国外起步比较晚，在集成技术的 研究面也相对比较窄。尽管如此，以上研究成果也为我们进一步研究工具集成提 供了一定的工作基础。同时也可以看到，开展面向基于组件的系统设计工具的集 成方法和技术的研究工作已经迫在眉睫。 1 5 论文的工作内容 如图1 1 所示，在工具集成的前提下，分布式协作开发环境可以协同控制集成， 完成工具之间数据和功能的组织、安排与调度，达到工具之间数据和控制流的平 滑相连的目的。 位于插件层的r c s a t 处于所涉及项目的最上层，是工具集成的起点。它为待 集成工具所提供的功能生成服务转调代码( 服务代理) ，使用编译器所提供的m a k e 工具将其编译为p y t h o n 扩展，并为服务代理生成w s d l 文件。服务容器通过p y t h o n 语言的动态特性在运行时调用服务的功能，屏蔽了不同工具在数据和功能访问上 的差异，为协作控制层和统一数据服务层提供透明的、无差异的数据访问和功能 调用，从而为数据集成、应用程序接口集成奠定基础。论文所涉及项目中使用 p y t h o n 扩展作为服务代理的实现形式，目前服务代理形式很多，但是出于对服务 的平台独立性，以及执行效率等方面的考虑，选择p y t h o n 扩展作为服务代理形式， 本论文着重讨论r c s a t 的设计和实现。 另外，特定工具的转调机制基本上是确定的，知道工具所使用的开发技术后 就可以直接为其生成转调代码。背景项目以c + + 为主要的开发语言，在这种情况 下，利用编译器所提供的m a k e 工具自动编译这些c + + 形式的转调代理生成p y t h o n 扩展。再根据服务接口信息，生成服务的描述文件，就可以在集成框架中以统一 的形式使用服务了。这一过程的自动化能够减少了集成开发人员的工作量，也提 高了工作效率。 6 一种w e b 服务代理自动生成上具 1 6 论文的组织结构 全文共分六章，第一章为绪论，介绍了论文所涉及研究项目的背景与意义。 第二章介绍了与工具集成相关的s o a 思想和w e bs e r v i c e 技术，以及服务代理生 成工具中所涉及到的主要技术。第三章从体系结构层次对r c s a t 进行了分析和设 计，给出了r c s a t 中各主要模块的设计思想和模块设计中主要问题的解决方案。 第四章从实现层次对r c s a t 中的主要组件进行了分析，给出了详细的解决方案。 第五章展示了论文所涉及研究项目中一个实际的测试用例，对工具集成中服务代 理生成及w e b 服务调用的全过程进行了分析。最后一章对本文所做的工作进行了 概括性的总结并给出了未来研究方向的一些建议。 第二章项目相关技术概述 2 1 1s o a 技术 第二章项目相关技术概述 2 1 项目中采用的主要技术 面向服务的架构( 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 ) 是一个组件模型2 1 ，它 将应用程序的不同功能单元- n 务( 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 可适应于任 何现有系统，并使得系统在集成时不必刻意遵循任何特殊定制。 s o a 帮助企业信息系统迁移到“l e a v e a n d 1 a y e r 架构之上，这意味着在不用 对现有的企业信息系统进行修改的前提下，系统可对外提供w e b 服务接口。这是 因为，它们已经被可以提供w e b 服务接口的应用层做了一层封装，因而在不用修 改现有系统架构的情况下，s o a 可以将系统和应用迅速转换为服务。s o a 不仅覆 盖来自于打包应用、定制应用和遗留系统中的信息，而且还覆盖来自于如安全、 内容管理、搜索等i t 架构中的功能和数据。由于基于s o a 的应用能够快捷地在 这些基础服务架构中添加新功能，所以能够应对市场变化，并有助于企业业务部 门开发新的应用功能。 种w e b 服务代理自动生成t 具 2 1 2w e b 服务 使用w e b 服务技术，应用程序可以通过与平台和编程语言无关的方式相互通 信。w e b 服务是一个软件接e l i 3 1 ，它描述了一组可以在网络上通过标准化的x m l 4 】 消息传递访问的操作。它使用基于x m l 的协议来描述要执行的操作或者要与另一 个w e b 服务交换的数据。在s o a 中，一组以这种方式交互的w e b 服务定义了特 定的w e b 服务应用程序。 w e b 服务所使用的x m l 可以用真正与平台无关的方式来描述任何( 所有) 数 据，从而实现跨系统交换数据。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 服务试图解决的主要问题是数据和应用程序集成的问题，以及将 技术性的功能转换为面向业务的计算任务的问题。这两个方面使企业可以就流程 或应用程序层面与他们的合作伙伴进行交流，同时为适应新形势或按照需要与不 同合作伙伴合作留有动态变更的余地。 本项目采用s o a 的思想对工具进行集成，将待集成工具的能力包装为服务， 通过调用服务接口实现对工具功能的使用，在高层次上采用b p e l ( b u s i n e s sp r o c e s s e x e c u t el a n g u a g e ) 实现对既定流程的设计和组织，系统从整体上看是松耦合的， 具有较强的可替换性，并屏蔽了工具集成的实现细节。 本项目采用s o a 的思想对工具进行集成，将待集成工具的能力包装为服务， 第二章项目相关技术概述 9 通过调用服务接口实现对工具功能的使用，在高层次上采用b p e l ( b u s i n e s sp r o c e s s e x e c u t el a n g u a g e ) 实现对一些既定流程的设计和组织，系统从整体上看是松耦合 的，具有较强的可替换性，并屏蔽了工具集成的实现细节。 2 2 服务描述语言( w s d l ) 服务描述语言是w e bs e r v i c e 技术的重要组成部分，w s d l 描述了分布在 i n t e m e t 环境中服务操作的抽象定义接口和服务的具体实现端口 1 2 】。对于使用标准 化的消息格式通信协议的w e b 服务，它需要以某种结构化的方式( u px m l ) 对w e b 服务的调用通信加以描述，而且实现这一点也显得非常重要，这是w e b 服务即时 装配的基本保证。w s d l 正是这样一种描述语言，w s d l 定义了一套基于x m l 的语法，将w 曲服务描述为能够进行消息交换的服务访问点的集合，从而满足了 这种需求。w s d l 服务定义为分布式系统提供了可机器识别的s d k 文档，并且可 用于描述自动执行应用程序通信中所涉及的细节。 w s d l 由a r i b a ，i n t e l ，i b m 和m i c r o s o f t 等开发商提出，以提交给w 3 c 作为 规范，目前w 3 c 最新的w s d l 工作草案是w s d l2 0 版，共分3 部分：核心语言( c o r e l a n g u a g e ) ，消息模式( m e s s a g ep a t t e r n s )定( b i n d i n g s ) 1 1 】【12 1 。w s d l 的基础是 m i c r o s o f t 的s d l ( s o f l w a r ed e f i n i t i o nl a n g u a g e ，软件定义语言) 和i b m 的 n a s s l ( n e t w o r k a c c e s s i b l es e r v i c e ss p e c i f i c a t i o nl a n g u a g e ，网络访问服务规范语 言) 的组合例。 w s d l 把与消息处理机制相关的项目简化为抽象的，把与协议和地址相关的 项目简化为具体的。在抽象层次上，w s d l 按照w e bs e r v i c e 发送和接受的消息描 述它，消息独立于具体的线上( w i r e ) 格式，通常用x m ls c h e m a 描述：在具体层次 上，通过一个或多个接口用绑定具体指明传输和线上格式。具体来说，w s d l 文 档在w e bs e r v i c e 的定义中使用下列元素： t y p e s 数据类型定义的容器，它使用某种类型系统( 一般地使用x m ls c h e m a 中的类型系统) 。 m e s s a g e 通信消息的数据结构的抽象类型化定义。使用t y p e s 所定义的类型来 定义整个消息的数据结构。 o p e r a t i o n 对服务中所支持的操作的抽象描述，一般单个o p e r a t i o n 描述了一个 访问入口的请求响应消息对。 p o r t t y p e 对于某个访问入口点类型所支持的操作的抽象集合，这些操作可以由 个或多个服务访问点来支持。 b i n d i n g 特定端口类型的具体协议和数据格式规范的绑定。 p o r t 定义为协议数据格式绑定与具体w e b 访问地址组合的单个服务访问点。 1 0 一种w e b 服务代理自动生成工具 s e r v i c e 相关服务访问点的集合 2 3m a k e f i l e m a k e f i l e 是编译器的目管理工具的规则定义文件。它描述了项目的编译、连接 规则，其中包括：工程中的哪些源文件需要编译以及如何编译、需要创建那些库 文件以及如何创建这些库文件、如何最后产生我们想要得可执行文件。它为自动 编译提供了可能性，极大提高了工作效率。 在一个完整的m a k e f i l e 中，包含了以下内犁】： 显式规则：它描述了在何种情况下如何更新一个或者多个被称为目标的文件 ( m a k e f i l e 的目标文件) 。在书写m a k e f i l e 是需要明确地给出目标文件、目标的依 赖文件列表以及更新目标文件所需要的命令。 隐含规则：它是m a k e 根据此类目标文件的命名( 典型的是文件名的后缀) 而 自动推导出来的规则。m a k e 根据目标文件的名字，自动产生目标的依赖文件并使 用默认的命令来对目标进行更新。 变量定义：就是使用一个字符串代表一段文本串，当定义了变量以后，m a k e f i l e 后续在需要使用此文本串的地方，通过引用这个变量来实现对文本串的使用。 m a k e f i l e 指示符：指示符指明在m a k e 程序读取m a k e f i l e 文件过程中所要执行 的一个动作。 注释：m a k e f i l e 中“群”字符后的内容被作为是注释内容( 和s h e l l 脚本一样) 处 理。如果此行的第一个非空字符为“f ”，那么此行为注释行。注释行的结尾如果存 在反斜线( ) ，那么下一行也被作为注释行。 在执行“m a k e 时首先执行终极目标所在的规则，接下来一层层地去寻找终 极目标的依赖文件所在的规则并执行。当终极目标的规则被完全的展开以后，m a k e 将从最后一个被展开的规则处开始执行，之后处理倒数第二个规则，依次回 退。最后一步执行的就是终极目标所在的规则。整个过程就类似于c 语言中的递 归实现一样。在更新( 或者创建) 终极目标的过程中，如果出现错误m a k e 就立即 报错并退出。整个过程m a k e 只是负责执行规则，而对具体规则所描述的依赖关系 的正确性、规则所定义的命令的正确性不做任何判断。就是说，一个规则的依赖 关系是否正确、描述重建目标的规则命令行是否正确，m a k e 不做任何错误检查。 2 4b o o s t p y t h o n b o o s t p y t h o n 1 4 1 是一个开源c + + 库，她提供了一个简明的i d l 式的接口用于 绑定c + + 类和函数到p y t h o n 。得益于c + + 编译期的内部处理和最近开发的元编程 第二章项目相关技术概述 ( m e t a p r o g r a m m i n g ) 技术，成就了b o o s t p y t h o n 不需引入一种新的语法而只用纯 c + + 的实现。b o o s t p y t h o n 丰富的特性集合以及她的高阶接口使得工程师像混合系 统那样做打包的事情成为可能，并且程序员让在应用c + + 高效的编译期多态性以 及p y t h o n 非常方便的运行期多态性的时候获得易用性和一致性； p y t h o n 和c + + 在很多方面相当的不同：c + + 一般编译为机器码，p y t h o n 是解 释处理的。p y t h o n 的动态类型系统( d y n a m i ct y p es y s t e m ) 【1 5 】作为语言具有灵活性 的基础常常被提及，然而c + + 的静态类型系统是她效率的基石。c + + 拥有一种复 杂和难以理解的编译期元语言( c o m p i l e - t i m em c t a 1 a n g u a g e ) ，然而在p y t h o n 里头几 乎所有事情都发生在运行期。 但是对于很多程序员来说，这些很大的不同也意味着p y t h o n 和c h 可以完美 的互补。p y t h o n 程序内性能瓶颈的部分可以用c + + 重写以带来最高的运行速度1 1 6 | ， 并且强大的c + + 库的作者们可以选择p y t h o n 作为中间件语言，利用她灵活的系统 集成能力。 b o o s t p y t h o n 的特性和目标与很多其它类似的p y t h o n 封装系统是一样的，企 图提供最大化的易用性和灵活性的封装方法，但是并不引入一种独立的封装语言。 取而代之的是，她提供高级的c + + 接口给用户用于封装c + + 类和函数，并且通过 静态元程j 芋( s t a t i c m e t a - p r o g r a m m i n g ) 管理大量内部的复杂性。b o o s t p y t h o n 超越了 早期封装系统提供的特性，包括： 一支持能够被p y t h o n 重载的c + + 虚函数。 对于低阶的c + + 指针和引用( l o w 1 e v e lc + + p o i n t e r sa n dr e f e r e n c e s ) ，提供 全面的生命期管理机制。 支持把扩展功能封装为p a c k a g e ，通过中心的注册机制作语言之间的类型 转换。 _ 通过一种安全和易用的方法，用于引入p y t h o n 强大的序列化引擎( p i c k l e ) 。 - 与c + + 对l v a l u e s 、r v a l u e s 的处理机制一致，所以可以对c + + 以及p y t h o n 的类型系统深入的理解。 开发b o o s t p y t h o n 最主要的目的是，通过使用c + + 的编译期内部处理，大量 的传统扩展模块样板代码可以被排除。每个封装的c + + 参数必须从一个p y t h o n 对 象中取得，根据参数的类型使用不同的过程( p r o c e d u r e ) 进行处理。同样地，函数的 返回类型决定了返回值怎样从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 的 信息和被封装的源代码一样多成为了可能，一些额外的信息由用户显式地提供。 通常这种”指导”是机械化的几乎不需要用户实际的干涉。因为接口的规范是用和表 述代码同样的全特性语言描述的，用户拥有了空前的能力，当他想进行控制的时 一种w e b 服务代理自动生成工具 候。 b o o s t p y t h o n 的主要设计目标是让用户可以只通过c + + 编译器，就能在p y t h o n 内使用c + + 类和函数【1 7 】。简单说，用户感觉就是直接从p y t h o n 里面操作c + + 对象。 其次p y t h o n 用户从c + + 接口里的琐碎错误中隔离开必须是可能的，例如访问已经 被删除了的对象。同样的，必须使c + + 用户从低阶p y t h o n ca p i 隔离开来，用更 好的选择去替换掉像手工进行引用计数管理和新的p y o b j e c t 指针管理这些事情， 他们都是容易导致错误的c 接口。支持基于组件的开发也是至关重要的，所以， 一个扩展模块中的c + + 导出类型可以被传递到另外一个模块导出的函数内应用， 而且不丢失任何重要信息，例如c + + 的继承关系。最后，所有的封装必须是非干 扰性的，不能修改甚至只是”查看”原始的c + + 代码。现存的c + + 库对于只有h e a d e r 文件和二进制文件的第三方来说，已经是可封装的了。 项目中在插件支持层使用b o o s t p y t h o n 将系统设计工具的功能进行统一的封 装，自动牛成具有p y t h o n 接口的模块组件。 2 5 可扩展标记语言( ) ( m l ) x m l ( e x t e n s i b l em a r k u pl a n g u a g e ，可扩展的标识性语言) 是一种简单、功能强 大且有效的扩展性标识语言。它是一种标准语言，被用来描述数据并将之结构化。 x m l 使用标记界定内容，x m l 中的标记可用来说明所描述的概念，使用属性来 控制它们的结构，允许我们自行定义任意复杂度的结构采用x m l 文件存贮信息具 有以下优越性驯： 1 有利于各种系统之间的信息通讯。由于x m l 是属于纯文本的资料，因此， 适合做信息交换使用。任何一个系统只要有x m l 的解析器( p a r s e r ) ，都可以使用 x m l 文件进行信息交换，即使装置内没有解析程式，x m l 文件对人来说也是可 读的； 2 有利于信息的保存。一般的文件和资料都是以二迸制形式存贮的，如果在 保存过程中有一些信息遗失，则可能整份文件都无法读取。x m l 使用纯本文的方 式保存信息，因此即使在信息的传送或保存过程中遗失一些资料，仍可取回未受 损的信息； 3 有利于信息的远程传输和格式转换。x m l 具有优秀的数据描述特点。x m l 是以文本形式来描述的一种文件格式，适合于各种平台环境的数据交换；x m l 使 用了有意义的标记( t a g ) 使其可以保持原数据的意思和构造，从而保证了不同系 统之间数据交换的灵活性；x m l 中用标记符号化的元素可以作为子元素形成数据 嵌套，使数据可以很好的描述要表现内容的层次关系；x m l 的标记名和关系可以 自由定义，使其成为“定义语言的语言”，也就是一种元语言。另外，就象我们使 第二章项目相关技术概述 用的自然语言，讲这种语言的人多了就会把它当作初次交流时的工具。同样在特 定的企业之间或在业界内归纳出一套标记集合，即约定用一套特定的x m l 应用语 言作为交流工具是很有价值的。鉴于x m l 的诸多优点，在我们系统设计工具集成 技术研究中，使用了x m l 作为中间的数据存储和转换格式。在数据格式转换模块 中，鉴于x m l 的各种功能，将x m l 作为转换的中间格式。另外，由于x m l 的 广泛通用性和易理解，工具中的一些配置文件以及消息发布文件也采用了x m l 表 示存储。同时，x m l 可以应用在各行各业并且具有相应的安全机制，这对信息的 安全传输提供了有力的保障 6 】。 第三章r c s a t 体系结构 第三章r c s a t 体系结构 3 1 需求分析 服务支持层的目的在于对工具进行封装，并将工具以服务的形式集成到分布 式协作开发环境中，屏蔽不同工具在数据和功能访问上的差异，为协作控制层和 统一数据服务层提供透明的、无差异的数据访问和功能调用，从而为数据集成、 应用程序接口集成奠定基础。另外，服务支持层也可根据开发环境的要求，进行 一定程度的人机界面集成，实现集成工具的统一管理。因此，服务支持层集中解 决数据提供、功能提供和部分数据转换问题。 3 1 1 数据集成视角 从工具提供数据服务的角度，可将工具划分为以下三种： 1 ) 数据不可被分析； 2 ) 数据可分析但数据格式不遵循领域标准； 3 ) 数据可分析且数据格式遵循领域标准。 针对第1 ) 种工具，若不对工具进行相应修改，协作开发环境无法对数据进行 抽取和变换，但可获取该工具的数据文件并根据工作流的安排与部署在网络上进 行数据文件的流转；针对第2 ) 种工具，协作开发环境可在获取数据文件的同时对 其进行分析，转化为符合该领域标准的数据，以便为其它工具所使用，此类工具 在协作开发环境中所占比例较大；针对第3 ) 种工具，由于其数据符合领域标准， 可直接为其它工具所利用，数据可直接在网络上进行传输而无需进行转换处理。 因此，服务支持层需要提供数据文件获取服务和数据文件转换服务。为了降 低服务间的耦合度，将数据文件转换服务划分为工具自身数据到领域标准数据的 转换，以及标准格式间的转换。由于工具自身数据到标准数据的转换与工具紧密 关联，因此将其和工具对应的插件相关联，而标准格式间的转换与工具没有必然 的联系，则将其抽取出形成一个单独的服务。 3 1 2 功能集成视角 从功能服务的角度考虑，协作开发环境并不改变工具本身所提供的接口，仅 在于提供统一的接口访问方式，工具所能够提供的功能服务取决于其自身所对外 显现的接口。 按照工具自身服务对外公开的程度，可将工具划分为以下四种： 1 6 一种w e b 服务代理自动生成t 具 1 1 应用型：工具不对外界提供任何形式的编程调用接口，工具的功能只能通 过图形化用户界面操作实现； 2 ) 命令型：工具通过丰富的命令行参数集为外界提