基于体系结构的网构软件自适应方法

中国科学 E 辑: 信息科学 2008 年 第 38 卷 第 6 期: 901 ~ 920 www.scichina.com info.scichina.com 901 《中国科学》杂志社 SCIENCE IN CHINA PRESS 基于体系结构的网构软件自适应 方法 快递客服问题件处理详细方法山木方法pdf计算方法pdf华与华方法下载八字理论方法下载 梅宏①②*, 黄罡①②, 兰灵①②, 李军国①② ① 北京大学高可信软件技术教育部重点实验室, 北京 100871; ② 北京大学信息科学技术学院软件研究所, 北京 100871 * E-mail: meih@pku.edu.cn 收稿日期: 2007-12-24; 接受日期: 2008-03-06 国家重点基础研究发展规划(批准号: 2002CB312000)和国家自然科学基金(批准号: 90612011)资助项目 摘要 作为网构软件的基本特性之一, 自适应性是指软件系统在预设策略 的指导下自动地监测系统状态信息, 并在必要时对自身进行调整, 以提供更 好的服务. 针对网构软件可适应性、自适应可操作性及适应结果可信性 3 个 基本问题, 提出了一种以体系结构为中心的网构软件自适应方法, 即监测、 分析、规划、实施等自适应活动均围绕软件体系结构展开, 其中, 网构软件 运行状态和行为以运行时软件体系结构的方式实时展现和在线调整; 自适应 相关知识通过软件体系结构记录、组织和加工, 以实现系统状态和行为的自 动分析和调整规划. 关键词 网构软件 自适应 软件体系结构 中间件 网构软件是 Internet环境下一种新的软件形态, 具有自主性、协同性、反应性、演化性和 多态性等特点[1]. 这些特性在技术上的共性之一可归结为自适应性, 即, 网构软件在运行过程 中能够在合适的时刻、合适的场合、准确捕捉变化并进行合理的适应性调整, 以满足功能和质 量的需求[2]. 从国内外研究与实践看, 自适应技术并不是一个网构软件独有的、新的话题. 然 而, 不论已有成果和经验能否适用于网构软件, 系统化的网构软件自适应需首先解决 3个基本 问题: ■ 网构软件可适应性问题: 即, 哪些或哪类变化可以被感知或理解, 以及哪些或哪类适 应性调整可以被实施, 这是网构软件实现系统化自适应的首要问题. 理论上, 网构软件这种典 型的人工制品的所有变化都可以被感知或理解, 并实施适应性调整. 但 Internet 环境开放、动 态、难控等特点, 从实用或实践的角度限定了网构软件自适应的范围. ■ 自适应可操作性问题: 即, 在给定的可适应范围中, 如何操作才能实现自适应. 这是 网构软件自适应的核心问题. 以自治计算[3]为例, IBM从产业实践的角度给出了一个以知识为 中心、对可管理实体分步骤进行监测、分析、规划和实施的自治计算模型, 并按照人参与系统 梅宏等: 基于体系结构的网构软件自适应方法 902 管理的程度划分了基础级、可管理级、可预测级、自适应级、自治级等 5个可操作级别. 尽管 自治计算模型及其分级给出了一个具有普适意义的自适应可操作性原理, 但仍需针对网构软 件进行特化和细化, 如, 知识在每个活动中的表现及应用、活动之间的自动衔接等, 从而形成 实际可操作的网构软件自适应基本结构与机理. ■ 自适应结果可信性问题: 主要包括自适应操作是否正确以及是否达到预期效果. 这是 网构软件自适应得以实际应用的关键问题. 前者需要评估适应后的网构软件的功能正确性, 后者需要评估网构软件的性能、可靠、安全等质量属性(因为它们是网构软件自适应的主要目 标). 这些指标均属于网构软件可信性的范畴, 而可适应范围的有限性则决定了自适应的可信 性是网构软件可信性的一个子集. 从技术角度看, 上述 3个基本问题可分别具体化为“如何看待和理解网构软件基本形态”、 “如何监控网构软件并进行分析决策”、“如何评估网构软件功能正确性和主要质量属性”. 我们 认为, 软件体系结构(software architecture, SA)为系统化地研究并解决这些基本问题提供了一 条切实可行的技术途径, 因为: ■ SA为考察网构软件自适应范围提供了全面、系统、易于理解的模型: SA是一组构件、 连接子以及约束所描述的软件系统总体结构[4], 能够自然地描述网构软件的基本形态, 即, 一 组分布于 Internet 环境下各个节点的、具有主体化特征的软件实体, 以及一组用于支撑这些软 件实体以各种交互方式进行协同的连接子[5]. 因此, 网构软件的自适应具体表现为软件实体、 软件交互、以及运行环境的自适应, 这些因素可分别建模为 SA中的构件、连接子、约束和变 化. ■ SA 为网构软件自适应提供了强有力的可操作性支持: 首先, 自适应的广度和深度取 决于相关知识的获取(隐性知识转变为显性知识)、组织(劣构知识转变为良构知识)和加工(描述 性知识升级为推理性知识). 作为一种模型化、支持分析与决策的高层结构, SA是一种有效的 网构软件自适应知识的载体; 其次, 作为软件工程中分析和控制整个系统功能性与质量的主 要手段之一, SA相关的方法和技术可直接支持监测、分析、规划、实施等自适应主要活动; 进 一步地, 围绕 SA展开这些活动, 为整个自适应过程的无缝衔接提供了自然的支持. ■ SA 有助于网构软件自适应结果可信性的评估: 在传统软件系统开发过程中, 软件体 系结构是保障目标软件功能性、性能、可靠、安全等系统级质量属性的主要手段, 尤其体现在 对这些可信指标的评估方面. 网构软件作为传统软件在 Internet 环境下的一种自然延伸, 其可 信性评估在一定程度上可以复用或受益于已有的 SA评估方法与技术. 随着网构软件体系结构 模型研究[2]的深入, SA将在网构软件适应结果可信性的评估中起到越来越重要的作用. 基于上述讨论, 本文提出了一种基于体系结构的网构软件自适应方法. 本文余下的部分 组织为: 第 1节概述整个方法; 第 2节介绍关键技术; 第 3节以 J2EE性能基准程序 ECPerf为 例展示方法的可行性与有效性; 第 4节介绍相关工作; 最后总结 全文 企业安全文化建设方案企业安全文化建设导则安全文明施工及保证措施创建安全文明校园实施方案创建安全文明工地监理工作情况 并展望未来工作. 1 方法概述 所谓以软件体系结构为中心的自适应, 是指自适应知识由 SA 承载, 自适应活动基于 SA 进行. 如图 1所示的自适应模型, 为了有效支持自适应知识的获取、组织和加工, SA需具备 4 中国科学 E辑: 信息科学 2008年 第 38卷 第 6期 903 个特性. 其中: 图1 以软件体系结构为中心的网构软件自适应方法概览 ■ 反射性: 是指SA与目标系统的运行状态和行为之间具有因果关联关系, 即, 目标系统 运行状态和行为的变化会立即导致其 SA 的相应变化, 反之亦然. 具备反射性的 SA 称为运行 时软件体系结构[6], 它从体系结构层次明确了网构软件自适应的范围, 能够保证自适应环路分 析的变化和规划的调整与目标系统实际发生的变化和调整之间的一致性和准确性. 此外, SA 反射性是对目标系统所支持的管理操作或监控能力的一种高层抽象, 在一定程度上屏蔽了底 层管理机制的细节和异构性, 保证了自适应方法的通用性. ■ 动态性: 是指 SA 能够全面准确地描述反射性所能感知的变化和实施的调整, 如构件 和连接子的增加、删除、以及通过约束增删改而实现的修改. 具有动态性的 SA称为动态软件 体系结构[7]. 经典 SA 研究中的动态性往往是由设计人员预测而得, 难以自然描述反射性所感 知的正在发生的变化. 同时, 经典 SA 动态性大多假设通过编程实现, 其描述的调整与反射性 运行时可实现的调整之间存在失配的可能, 导致自适应规划难以完整、准确地实施. 因此, 我 们定义了一组操作原语以从反射性的角度修订经典 SA的动态性. ■ 推理性: 是指 SA 能够在反射性限定的范围内分析变化并推导出相应的适应性调整. 动态性必须显式描述变化及其相应的调整(即 What-to-change 和 How-to-change), 而推理性则 可以通过一些规则(即 Why-to-change)自动生成动态性描述, 是实现可预测、自适应、自治等高 级别自适应的关键. 推理规则有很多种, 我们目前采用了 3 种形式, 包括常用的 ECA 规则 (event-condition-action, 对于给定的事件, 根据给定的条件决定具体的动作)、模式(对于给定的 模式, 自动 检测 工程第三方检测合同工程防雷检测合同植筋拉拔检测方案传感器技术课后答案检测机构通用要求培训 系统中是否存在该模式并转换成另外一种模式)、风格(对于给定的风格, 自动 将使系统的整体或局部符合该风格). ■ 可信性: 是指 SA 所能体现的目标系统的功能正确性、性能、可靠、安全等指标符合 用户预期. 本质上, 网构软件自适应就是一种持续追求或保障可信性的过程, 该过程的输入是 不可信的目标系统, 输出则是变得可信的目标系统. 换言之, 可信与否是自适应过程启动和终 止的判定条件. 技术上, 可信性评估与自适应是两个相对独立的研究领域, 软件体系结构的评 梅宏等: 基于体系结构的网构软件自适应方法 904 估经过了长期的研究与实践, 我们将复用其中的成果与经验来解决自适应结果可信性的问题. 基于具有上述特性的 SA, 网构软件自适应的主要活动将自动执行. 其中, 监测活动利用 SA 反射性收集网构软件的运行信息, 并将这些信息展现为 SA 的动态性描述; 分析活动对当 前系统的 SA 以及监测活动产生的 SA 动态性描述进行可信性评估, 如果评估结果为不可信, 则激活规划活动, 否则终止此次自适应环路; 规划活动首先针对分析活动的可信性评估结果, 找到监测活动的动态性描述中可能导致不可信的变化, 然后利用 SA推理性得出适应性调整方 案, 并生成相应的动态性描述; 实施活动则将规划活动生成的动态性描述转换成反射性操作 并执行之, 最终调整实际系统. 这 4 个活动组成一个自适应环路循环往复地进行, 人的参与可 能导致自适应过程从任意一个活动开始或结束. 2 关键技术 2.1 软件体系结构模型 尽管目前尚无统一或 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 的 SA模型, 但多年的研究与实践在 SA的基本内涵方面达成了 许多共识[4,7]. 本文采用了如图 2所示的 ABC/ADL定义的 SA模型[8], 原因在于: 首先, 它具有 典型的软件体系结构模型的所有要素, 包括完成系统所需计算功能的构件、负责抽象构件之间 交互的连接子、对构件之间的交互拓扑结构进行描述的系统配置以及从系统全局角度出发需 要考虑的各种约束. 在此基础上, 它还新增了特定于网构软件的特性, 如 1) 区分类型和实例: Asset元素中的 Components和 Connectors是对类型的定义, Instances元素则是对构件和连接子 的描述. 区分类型和实例意味着网构软件体系结构模型是一个类型化的模型, 这样架构师就 有可能对设计好的模型进行验证, 以保证组装结果的正确性. 区分类型和实例的另一个好处 就是有助于构件类型和连接子类型的复用; 2) 兼顾复用和构造: 新构造的资产与可复用资产 具有一个本质的区别, 那就是前者可以根据当前的设计需要随时进行修改, 而后者对当前的 架构师而言是一个黑盒的资产, 只能进行恰当的使用而无法修改其定义. 因此, 需在兼容的前 提下显式区分新构造资产(newComponent 和 newConnector)与可复用资产(reusedComponent 和 reusedConnector); 3) 简洁有效的配置: 配置(Configuration)决定了构件之间的交互拓扑结构, 用松耦合的 link来确定构件的交互方式, 以适应网构软件交互方式灵活多样的特点. link的语 义可类比为演员(player)扮演某个角色(role). player是对构件计算功能的抽象, role则是对连接 子通信能力的抽象. 通过恰当的 link定义, 架构师就能指定系统中的每个构件应该在整个系统 中扮演怎样的角色才能完成满足目标系统的需求; 4) 可扩展的约束: 软件体系结构之所以受 到广大研究人员和实践者的关注就在于它允许架构师在系统开发早期对系统进行分析以便尽 早发现潜在的问题. 对系统结构进行分析的基础就是体系结构模型中的约束定义(Constraint), 如安全、事务、响应时间等. 架构师可根据特定的约束扩展已有的描述方式, 以便于约束的定 义、转换、保障和评估. 2.2 软件体系结构反射性 反射性主要的实现方式有三种, 其中, 反射式编程语言通过内嵌在编译器或虚拟机中的 特殊机制实现对运行程序的反射; 反射式中间件则通过内嵌在中间件的特殊机制实现对上层 中国科学 E辑: 信息科学 2008年 第 38卷 第 6期 905 应用构件的反射; 反射式构件模型通过定义一组需构件开发者实现的接口来反射构件的内部 实现. 三者各有利弊, 如, 反射式编程语言的反射能力理论上最为强大, 但特定于具体的语言, 且反射视图抽象层次偏低、系统化不足; 反射式中间件的抽象层次相对较高, 反射能力也很强 大, 但特定于具体的中间件, 且难以反射构件内部的具体实现; 反射式构件模型的抽象层次最 为贴近软件体系结构, 但反射能力依赖构件开发者的具体实现, 对全局的反射能力偏弱. 为此, 我们通过运行时软件体系结构集成了上述 3 种反射性实现方式, 且屏蔽了这些技术的异构性 以保障自适应方法的通用性. 图2 ABC/ADL定义的软件体系结构基本模型 如图 3所示, 运行时软件体系结构(runtime software architecture, RSA)的主体是一个内嵌 在中间件中的全反射框架[6], 该框架直接利用中间件的反射能力和编程语言的反射能力, 若部 署在中间件上的构件实现了反射式构件模型定义的接口, 则可直接调用这些接口以整合构件 模型的反射能力. 以中间件为主体是因为中间件是网构软件运行支撑平台的主要形式, 且中 间件易于整合编程语言和构件模型的反射性, 以使反射框架尽可能全面地覆盖整个系统. 目 标系统中的构件抽象为 RSA 中的构件; 构件之间若通过中间件交互, 则中间件的互操作功能 抽象为RSA中的(简单)连接子; 某些构件可能抽象为RSA中的(复杂)连接子, 这是因为该构件 或者是设计阶段 SA中的某个连接子, 或者有人显式指定; 中间件提供的安全、事务、持久等 功能抽象为RSA中构件或连接子的约束; 反射式构件模型提供的反射能力抽象为RSA中构件或 连接子的反射接口; 编程语言(Java)的反射能力则用来实现或增强中间件和构件模型的反射性. 2.3 软件体系结构动态性 按照 SA模型中元素的种类, SA的动态性可以分解为实体调整、实体间关系调整、实体属 梅宏等: 基于体系结构的网构软件自适应方法 906 图3 软件体系结构全反射框架 性调整等 3类操作原语. 定义如下: ■ 一个实体的调整定义为一个三元组, 记为 RE(E, ID, OP), 其中 E代表被调整的实体的 类型, 包括Host, Service, Component, Call四类实体, ID代表被调整实体的唯一标识符, OP代表 对该实体进行的操作, 包括 Add和 Delete(增加一个实体、删除一个实体)两种操作. ■ 一个实体间关系的调整定义为一个六元组, 记为 RR(E1, ID1, E2, ID2, R,OP), 其中 E1 和 E2代表被调整的关系所关联的两个实体的类型, ID1和 ID2代表这两个实体的唯一标识符, R代表被调整关系的唯一标识符, OP代表对该关系进行的操作, 包括 Add和 Delete(为两实体 之间添加关系、删除两实体之间的关系)两种操作. ■ 一个实体属性的调整定义为一个四元组, 记为RP(E, ID, P, V), 其中E代表被调整的实 体的类型, ID代表被调整实体的唯一标识符, P代表实体中需要进行调整的属性名, V代表调整 后该属性的值. 运行时软件体系结构能够监测的变化和实施的调整均可通过上述原语及其组合来描述. 这组操作原语可以视为一种软件体系结构操作语言(architecture manipulation language), 相应 的 SA动态性描述形成独立的文档, 以保持整个 SA描述的清晰、简洁、灵活. 2.4 软件体系结构推理性 推理性知识往往可以表示为“如果⋯那么”, 除了常见的 ECA(event-condition-action)规则, 我们还支持 SA 特有的推理性知识表示方式, 包括模式和风格. 模式抽象描述了 SA 的一个范 围较小的局部结构, 如工厂模式、适配器模式等; 而风格则抽象描述了 SA的整体结构或者一 个范围较大的局部结构, 如管道-过滤器风格、三层体系风格等. 模式和风格所抽象的结构可能 对可信性带来正面影响、负面影响或无影响, 相应的自适应包括消除具有负面影响的模式和风 格、或者实现具有正面影响的模式和风格. 但实际可操作的自适应主要有两种: 其一, 将具有 负面影响的模式和风格调整为无影响或具有正面影响的模式和风格; 其二, 通过对整个系统 的调整使其直接具备正面影响的风格. 因此, 基于模式和风格的推理性知识包括“如果存在某 种模式或风格, 那么调整为另外一种模式或风格”、以及“如果满足某种条件, 那么调整系统使 之具备某种风格”. 目前存在多种模式和风格的描述机制, 在不失一般性的前提下, 我们定义了如图 4所示的 中国科学 E辑: 信息科学 2008年 第 38卷 第 6期 907 元模型以定义便于推理、可操作的自适应知识. 其中, Component用于描述应用系统中各种类 型的构件; Connector描述构件之间的连接子, 它的作用是连接构件, 一个Component实例可以 通过 provide或 require关系与一个 Connector实例关联, 而被连接的 Component实例分别作为 提供者与消费者角色; Service继承了 Component, Service实例表示系统中一类特殊的构件, 即 中间件提供的各种服务; Host 用于描述分布式环境中的主机及部署在上的中间件, 两个通过 connect 关联的 Host 实例表示这两个主机之间物理上存在连接, 如果一个 Host 实例包含了一 个 Component/Service 实例, 表示该构件/服务部署在该主机上. 此外, 元模型中每类实体都有 其对应的属性, 以此定义应用系统中对应实体的状态. 管理者不仅可以通过使用 Component 与 Connector实体及相关的关系描述应用系统中的构件及构件之间关系, 还可以通过使用Host 与 Service 实体及相关的关系描述系统级的中间件业务能力, 从一个系统化的角度对应用系统 进行建模. 该元模型是可扩展的, 管理员可以通过扩展元模型来提高元模型的建模能力, 如定 义特殊的构件类型、复杂的连接子类型等. 图 4中的深色部分举例说明了如何对元模型进行扩 展. 其中, Method 用于表示两个构件之间的方法调用, 一组 Method 实例可以通过 postInvoke 关系关联 , 表示一个调用序列; Proxy 用于表示中间件提供负责远程调用的代理构件 , 而 ProxyConnector用于表示普通的Component实例与 Proxy实例之间的连接; ExceptionInterceptor 与 Buffer 均是中间件提供的一些辅助机制, 它们分别表示用于捕获应用系统异常与缓冲应用 请求的复杂连接子. 图4 软件体系结构模式和风格元模型 针对该元模型定义出的模式和风格, 可执行的推理包括: 1) 自动检测出目标系统是否具 有给定模式或风格; 2) 对于给定的负面影响模式(风格)及相应的无影响或正面影响模式(风格), 可自动生成由前者转换成后者的系统调整方案; 3) 对于给定的正面影响风格, 可自动生成使 梅宏等: 基于体系结构的网构软件自适应方法 908 目标系统具备该风格的调整方案. 具体细节将在“实例研究”部分论述. 2.5 软件体系结构可信性 2.5.1 正确性评估 网构软件自适应的正确性包含调整后的应用系统正确、以及调整操作可正确执行两个方 面. 系统校验(validation and verification)一直是 SA研究的重点之一, 主要的方法是在体系结构 描述语言中加入形式化的语义模型, 然后使用形式化方法对得到的 SA 模型进行校验. 本文采 用了 ABC/ADL的验证机制[9]: 1) 语法层次的校验. 主要是对构件接口的匹配和构件与连接子 的拓扑关系进行校验; 2) 实现层次的校验. 根据具体实现的语言和底层平台的规范, 进行类型 匹配等实现级的检查(替换构件实现时需要检查其是否在语法上满足构件契约); 3) 语义层次 的校验. 利用形式化方法描述构件行为和交互 协议 离婚协议模板下载合伙人协议 下载渠道分销协议免费下载敬业协议下载授课协议下载 , 对系统的整体特性, 如有效性(如, 是否有 死锁)和完备性(如, 是否所有请求接口都与合适的提供接口建立了连接等), 进行检查. 自适应操作最终由反射性执行, 在执行的过程中, 受到反射性实现机制的限制, 一些操作 不应该或者可能无法执行, 如, 对应用系统的配置超过底层平台规定的上下限, 试图执行底层 平台不支持的操作等. 在自适应过程中, 必须保证自适应操作能够执行且不会破坏底层机制 设定的各种约束. 调整操作的正确性验证主要分为 3个部分: 1) 平台与构件、服务之间关系的 验证, 必须保证构件或服务可以部署到其指定部署的主机上; 2) 构件与服务之间关系的验证, 必须保证构件可以使用其指定依赖的服务; 3) 属性的验证, 必须保证待系统中实体所有待修 改的属性可以设为指定的值. 2.5.2 有效性评估 自适应的目的是为了保障应用系统的质量属性, 在自适应调整之前, 应预先对调整方案 进行评估, 以确保其可以满足用户预期效果. 目前的 SA 研究中存在大量对系统质量属性进行 评估的算法, 我们的自适应方法可以复用这些算法. 特别地, 应加入对中间件等运行环境的考 虑, 以使得评估算法的输入数据更加丰富, 实现系统化的评估. 例如, 使用现有的可靠性分析 算法, 为其输入应用构件与中间件服务的相关信息, 则可对包括中间件在内的整个系统的可 靠性进行评估[10]. SA研究大多在设计时刻对目标系统质量属性进行评估, 往往需要通过预测的方式指定部 分输入参数, 如, 评估目标系统的响应时间需要预测构件操作、网络传输等步骤所需的时间, 这难免会造成评估的结果难以真实、准确地反映目标系统的实际运行状况. 而在我们的自适应 方法中, 可通过反射性得到实时数据, 从而使得评估算法的结果更为准确. 2.5.3 开销预评估 自适应开销是指执行一个调整方案所需要花费的时间与资源上的消耗. 在自适应调整之 前, 应尽可能预测开销, 以确保调整方案的性价比在用户可接受的范围内. 自适应调整是运行 时刻执行的, 调整消费的时间越多, 对运行中的系统就影响越大, 因此, 本文将着重考虑自适 应调整消费的时间. 执行一个自适应调整方案消费的时间, 等于执行该方案中所有调整操作 所消费时间的累加. 不同的方案有不同的执行步骤, 由此也导致执行时间各不相同. 我们在文 中国科学 E辑: 信息科学 2008年 第 38卷 第 6期 909 献[11]中给出了一个针对不同部署方案计算其部署时间的方法, 重点考虑了软件部署中各个步 骤所消费的时间. 在其基础上, 我们给出了一个自适应操作消费时间的计算公式, 它考虑了自 适应操作中可能涉及的所有步骤所消费的时间: Timerefactor = Tbuffer + Tgenerate + Ttransfer + Tdeactivate + Tundeploy + Tdeploy + Tactivate, 其中, Timerefactor表示自适应操作消费时间. 该计算模型将 Timerefactor定义为 7个步骤所消费时 间的累加, 这 7 个步骤消费的时间分别是: Tbuffer表示缓存客户请求以及释放缓存所需的时间, 由于调整操作执行需要消费一定的时间, 因此在执行开始前, 需要将客户请求保存在一个缓 存中, 当调整完成后再释放缓存中的请求并处理这些请求; Tgenerate表示生成一些辅助类所需的 时间, 例如生成截取器或者代理类等; Ttransfer表示将调整操作中需要部署的构件、服务或者辅 助类等传输到目标主机上所需的时间; Tdeactivate表示去活应用系统中需要替换部分所需的时间; Tundeploy表示卸载需要替换部分所需的时间; Tdeploy表示部署新添加的构件、服务或者辅助类所 需的时间; Tactivate 表示激活新添加的构件、服务、辅助类, 或者更新系统配置, 使自适应调整 最终生效所需的时间. 该计算公式包括了完成一次自适应调整操作可能涉及到的主要步骤, 在实际应用中, 绝大部分的调整仅执行其中的一部分, 计算开销时应针对不同的自适应操作 选择其中不同的步骤. 需要注意的是, 某些步骤在实际的执行过程中是可以并行执行的, 如 Ttransfer与 Tdeactivate和 Tundeploy, 即, 在去活以及卸载待替换部分的同时, 传输新添加的类, 这意 味着某些情形下实际的自适应开销也许会比预评估的结果更小. 2.6 全生命周期软件体系结构建模工具 由于人工智能、自然语言处理等领域还存在较多尚待解决的问题, 因此, 完全不需要人参 与的系统化的自适应目前还很难实现. 正如自治计算分级所体现的, 人适当程度的参与是自 适应切实可行的前提. 具体而言, 人的参与主要分为两种: 其一是参与自适应知识的获取、组 织和加工; 其二是参与自适应环路的执行. 基于前面的讨论, 我们的自适应方法中的自适应知 识通过 SA 描述, 自适应环路均通过 SA 执行, 因此, 以可视化的方式支持 SA 的建模和监控, 是一种便于人参与自适应的用户友好的方式. 为此, 我们采用了 ABCTool, 一种全生命周期软 件体系结构建模工具. 一方面, ABCTool提供了运行时软件体系结构的实时视图, 从而实现自 适应环路的实时监控, 如图 5所示的工具截图; 另一方面, 还可通过ABCTool可视化地定义网 构软件各个阶段的 SA基本模型(即经典的 SA建模)以及动态性和推理性. 图5 工程化的自适应知识获取 ABCTool的主要功能是支持开发者对网构软件各个阶段 SA的建模, 从而规约领域特定的 梅宏等: 基于体系结构的网构软件自适应方法 910 SA 和具体应用的 SA. 这些 SA 模型以及建模的过程均包含有助于自适应的知识. 例如, 在经 典的SA设计中, 如果经过评估发现当前SA不满足预期目标, 则需修改SA模型直至通过评估. 传统的 SA设计最终产生唯一的满足预期目标的模型, 但网构软件是多目标兼容且目标持续可 变, 这意味着某个不满足当前预期目标的阶段性的 SA 模型, 可能在目标变化后而变得适用, 如果当前 SA 模型变得不适用, 则需要调整为该阶段性 SA 模型[12], 这就是一种典型的网构软 件自适应. 因此, ABCTool 支持一种工程化的自适应知识获取, 即, 将工程化网构软件开发过 程及其制品作为自适应知识存储起来. 值得指出的是, 领域特定 SA建模产生的自适应知识一 般是领域特定的, 而具体应用的 SA建模则往往产生特定于该应用的自适应知识. 那些直接使 用 ABCTool定义的普适性规则、模式、风格则蕴含了常识性的自适应知识. 3 实例研究 ECperf基准测试是测量 J2EE应用服务器的行业标准, 主要用来测试基于 Java的电子商务 软件的可扩展性、性能和总体拥有成本. 本节将以 ECPerf为例, 展示如何使用本文提出的 SA 为中心的自适应方法对其进行调整, 以提高其性能与可靠性. 在实例研究中, 本文使用反射式 J2EE应用服务器 PKUAS[6]作为底层支撑平台. 3.1 SA模式驱动的自适应 SA模式是对网构软件中一个范围较小局部结构的抽象, 而这些抽象的局部结构可能会给 系统的可信性带来负面影响、正面影响或无影响. 为了提高系统可信性, 需要将具负面影响的 模式实例调整为无影响或具正面影响的模式实例. 本文提出的方法支持这种形式的自适应调 整[13]: 首先, 管理员使用 SA建模工具建立 SA模式模型, 包括不良模式模型(描述带来负面影 响的模式)和与之对应良好模式模型(描述无影响或带来正面影响的模式); 然后, 通过采集运 行时刻信息并与不良模式模型进行匹配, 检测出系统中可能存在的不良模式实例; 通过调整 规划得到调整方案, 该方案由本文给出的SA操作原语描述; 最后, 将基于 SA模型的调整方案 映射为中间件的实际操作, 完成实际的自适应调整. 该过程中, 除第 1步由管理员手工完成外, 其余步骤均可自动完成. 3.1.1 实例描述 在 ECPerf 应用中存在如下的不良模式: 如图 6 左半部分所示, 当某个客户需要购物的时 候, 它需要若干次调用远程的CartSesEJB中的 addItem()方法, 向购物车中添加商品, 最后再通 过调用 buy()方法提交订单. 由于客户端与服务器部署在不同的机器上, 因此这些调用都必须 通过网络, 调用参数与返回值都需要进行序列化与反序列化的操作, 而且还会花费大量的时 间通过网络传输数据. 这种采用过多次远程调用获取一组属性值的方法会极大降低性能, 是 应用中存在的一个典型的性能反模式, 称为“细粒度远程调用(fine-grained remote calls)”[14]. 为去除该不良模式带来的性能影响, 需要对网上书店系统进行调整. 一种调整方案就是 通过一次远程调用就将所需要购买的物品信息全部发送给 CartSesEJB, 而不是每向购物车中 添加一件商品就进行一次远程调用. 可以使用经典的设计模式“会话外观(session facade)”[15]对 系统进行调整. 如图 6 右半部分所示, 在服务器端添加一个会话外观构件, 客户端通过一次远 中国科学 E辑: 信息科学 2008年 第 38卷 第 6期 911 程调用将所需要购买的物品信息全部发送给会话外观构件, 然后再由该构件调用 CartSesEJB 中的相应方法, 通过一次远程调用完成所有的数据传输. 图6 ECPerf不良模式场景及调整后场景 3.1.2 不良模式检测 为检测该不良模式, 首先需要由管理员建立相应的不良模式模型, 如图 7所示: 如果一个 EJB与客户程序之间存在一个调用序列, 该调用序列中第 1个调用的返回值类型是 EJBObject, 紧接着调用至少 n个参数不为空的方法, 最后调用一个参数为空的方法, 而且这些方法调用都 是远程调用. 那么, 该应用中存在不良模式“细粒度远程调用”的一个实例. 在检测过程中, 该不良模式模型可以用于指导运行时刻的信息采集, 需要采集的运行时 刻信息包括应用系统中所有 EJB 的方法调用, 所调用方法的返回值、参数以及调用的类型(是 远程调用还是本地调用). 信息采集结束以后, 则可以进行不良模式检测. 首先查找出应用系 统中所有的 EJB, 然后对 EJB的调用序列与模型定义的调用序列进行匹配, 最后检测结果为如 下的不良模式实例: CartSesEJB 上{create,addItem,addItem,addItem,buy}, 该调用序列存在细粒 度远程调用不良模式. 图7 “细粒度远程调用”不良模式模型 3.1.3 建立良好模式模型 图 6 所示的“会话外观”模式需要修改客户端代码才能直接实现, 为了通过中间件自适应 梅宏等: 基于体系结构的网构软件自适应方法 912 而不是应用代码修改来实现从“细粒度远程调用”不良模式到“会话外观”模式的重构, 我们需 要定义一个特殊的良好模式, 如图 8所示. 图8 “会话外观”良好模式模型 在分布式环境中, 当位于不同服务器上的构件之间进行方法调用时, 由于它们运行在不 同的机器上, 客户端构件其实并不直接调用服务器端构件, 而是调用该构件对应接口的一个 实现, 该实现称为一个代理(proxy). 当接收到客户端发来的请求后, 代理构件负责将该请求转 发给远程的构件. 服务器端也存在一个代理构件, 它负责接受到远程请求, 对请求信息进行预 处理后(例如反序列化调用参数)再对服务器端构件进行调用. 客户端的代理构件一般称为客 户桩 Stub, 而服务器端的代理构件一般称为服务器端骨架 Skeleton. 而事实上, 这些代理构件 完成了构件之间的通信功能, 它们可以看作连接子的实现. 一般情形下, 代理构件由中间件根 据构件的接口自动生成, 以应用无法感知的形态存在于中间件为构件提供的运行环境中, 其 主要任务就是帮助应用系统完成网络通信, 允许通过修改代理构件来调整构件之间的交互. 与图 7所示的不良模式相比, 图 8的良好模式添加了两个代理构件, 其中, FacadeStub负责接 收客户端发送来的请求并保存这些请求, 当整个调用序列完成后将所有请求的信息发送到服 务器端, 它事实上是为客户端添加了 buyItems()方法; FacadeSkeleton完成会话外观构件的功能, 在接收到FacadeStub发送来的多个请求后, 再按照顺序依次将这些请求转发给CartSesEJB, 当 最后的 buy()方法执行完毕后, 再将返回值发送回客户端. 值得指出的是, 该模型中有两个视 图: 实线部分是应用视图, 仅仅描述了应用的信息; 而虚线部分是中间件视图, 描述的是中间 中国科学 E辑: 信息科学 2008年 第 38卷 第 6期 913 件上运行的应用系统实际状态. 在本例中, 良好模式的应用视图没有任何改动, 所有改动都在 中间件视图范围内, 这意味着所有改动对应用都是透明的, 即, 自适应调整是在不修改应用代 码的前提下完成的. 3.1.4 调整规划与实施 在检测出不良模式实例后, 首先应该根据 SA模式模型自动生成调整方案[13]. 通过比较不 良模式模型和良好模式模型得到一组调整操作(即两个图之间的差异), 按照操作之间的依赖 关系可将这些操作排序, 从而生成图 9所示的调整方案, 也即 SA的动态性描述. 在调整方案生成之后, 需要将其映射为 实际的中间件管理操作, 然后由中间件自动 完成实际的调整. 本调整方案将映射为 4 个 中间件操作: 1) 生成 FacadeStub构件: 调整操作 1~3 映射为该操作 . 与普通的 Stub 比较 , Fa- cadeStub 修改了 addItem()与 buy()方法, 不再 将 addItem()请求转发给远程的 CartSesEJB, 而是将参数保存并在调用 buy()时将所有保 存信息发送到服务器端. 显然, FacadeStub构 件是应用特定的, 但是, 针对细粒度远程调 用这一不良模式, 它对于每个函数的修改都 是有规律的, 可以由普通的 Stub 自动生成. 因此 , 为了能够全自动地完成自适应调整 , 管理员在输入了不良/良好模式之后, 还应输入模式相关的一些辅助构件自动生成算法, 这些 算法是模式特定的, 可以在不同的应用系统中复用. 2) 添加 Stub控制器: 调整操作 4~8映射为该操作. Stub控制器负责将普通的 Stub替换为 FacadeStub, 并在客户端调用 Create()方法时返回 FacadeStub. 3) 生成 FacadeSkeleton 构件: 调整操作 9~11 映射为该操作. 与普通的 Skeleton 比较, FacadeSkeleton 修改了 buy()方法, 在该方法中将重新解析由 FacadeStub 传来的多次操作的参 数, 并依次对CartSesEJB进行调用. 与 FacadeStub类似, FacadeSkeleton也可以自动生成, 其自 动生成算法是模式特定的. 4) 添加 Skeleton控制器: 调整操作 12~16映射为该操作. Skeleton控制器负责用指定的构 件, 即 FacadeSkeleton替换普通的 Skeleton. 值得一提的是, Stub/Skeleton控制器提供的是一种 通用的机制, 可以在不同的应用或针对不同的模式使用. 3.1.5 自适应效果评估 图 10展示了自适应前后的性能对比. 整个应用系统的运行环境如下: 部署 ECPerf应用的 机器配置有奔腾 4 2.8G Hz 的处理器以及 1G 内存; 部署 ECPerf 客户端的机器配置有奔腾 4 2.4G Hz的处理器以及 256M内存; 安装 ECPerf应用使用的数据库的机器配置是奔腾 4 2.8G 1: RE (Proxy, 6, ADD); 2: RA(Proxy, 6, name, FacadeStub); 3: RA (Proxy, 6, proxyType, Stub); 4: RE (ProxyConnector, 7, ADD); 5: RR (Proxy, 6, ProxyConnector, 7, require, Add); 6: RR (Method, 3, Proxy, 6, return, Add); 7: RR(Method, 4, ProxyConnector, 7, composite, Add); 8: RR (Method, 5, ProxyConnector, 7, composite, Add); 9: RE (Proxy, 8, ADD); 10: RA (Proxy, 8, name, FacadeSkeleton); 11: RA (Proxy, 8, proxyType, Skeleton); 12: RE (ProxyConnector, 9, ADD); 13: RR (Proxy, 8, ProxyConnector, 9, provide, Add); 14: RR (Component, 1, ProxyConnector, 9, require, Add); 15: RR (Method, 5, ProxyConnector, 9, composite, Add); 16: RR (Method, 4, ProxyConnector, 9, composite, Add); 图 9 SA模式驱动的自适应调整方案 梅宏等: 基于体系结构的网构软件自适应方法 914 Hz 的处理器以及 512M 内存; 所有机器之间的网络带宽为 100M. 左图是自适应调整前后进 行”addItem*n, buy”调用序列所消费的时间对比, 可以发现用户每多向购物车中添加一个商品, 调整后的优化效果大约为响应时间减少 75 ms. 这是因为每执行一次 addItem()操作就会导致一 次远程调用, 相比本地调用, 远程调用将会把大量的时间花费在网络相关的操作上, 主要包括 建立网络连接和传输数据, 在本应用中执行一次这些操作的时间是 70 ms左右. 而在进行自适 应调整之后, 由于使用一次远程调用取代了多次远程调用, 将需要的信息一次发送到服务器 端, 减少了网络传输带来的损耗, 因此缩短了响应时间. 右图的性能评测结果是在 ECperf 性 能测试结束以后提交的测试报告Order.summary中给出的, 对比的性能指标是客户新建一个订 单的响应时间 NewOrder Response Time. 可以发现, 在优化后响应时间缩短了 10.5%左右. 图 10 ECPerf自适应调整前后性能对比 3.2 SA风格驱动的自适应 SA 风格是对网构软件整体结构或较大的局部结构的抽象, 与模式类似, 这些抽象的结构 可能会给系统的可信性带来负面影响和正面影响或无影响, 为提高系统可信性, 需要将具负 面影响的风格实例调整为无影响或具正面影响的风格实例. 与模式不同的是, 风格的全局性 意味着可以直接将某种风格作用于运行系统, 本节将以 ECperf 为例介绍如何通过自适应实现 容错风格的直接生效. 3.2.1 实例描述 在 ECperf 的客户发出新订单的场景中, 客户首先选择商品的类型和数量, 然后点击浏览 器界面中的订购按钮, 生成一个新订单. 服务器端的对应动作是: OrderSes会话 Bean调用自己 的 newOrder方法, 在此方法中生成一个与新订单对应的OrderEnt实体 Bean实例. 当这个实体 Bean 被初始化时, 它会首先检查客户资金帐户的余额是否足够支付此次定单、是否为大额订 单等, 然后在数据库表中增加一条新记录. 这些活动会调用中间件提供的数据服务, 进行数据 库操作. 突发的网络断连或数据库系统瞬时故障会造成管理数据库连接的数据服务发生失效, 数据服务中缓存的数据库连接变为无效连接, 进而导致使用了无效连接的客户请求处理失败. 为降低数据服务失效所产生的失败客户请求的数量, 应使得 ECperf具备一定的容错能力. 容错机制大多包含错误检测和恢复两部分, 前者用于发现系统因出现故障而导致的异常状态, 中国科学 E辑: 信息科学 2008年 第 38卷 第 6期 915 后者则通过状态恢复操作将异常的系统状态恢复至正常状态. 这些容错机制与目标系统的功 能正交, 可直接施加到整个系统范围内任何满足某些基本条件的构件之上. 换言之, 这些容错 机制可以抽象为容错风格, 以有效提高系统的可靠性和可用性[16,17]. 3.2.2 建立容错风格 图 11(a)和(b)分别展示了两种较常见的容错风格, 其中, (a)是用于错误检测的异常捕获风 格, 是指基于编程语言的异常处理机制, 对运行时抛出的异常进行截获、分析, 以发现和定位 错误; (b)是用于故障恢复的缓冲重启风格, 是指当某一个构件发生失效时, 可以通过重启该构 件并将其设置为正确的状态来进行恢复, 在恢复过程中将缓冲所有到达的请求并在恢复成功 后重新定向被缓冲的请求. 处理 ECperf 中的数据服务失效需同时进行错误检测和故障恢复, 即, 需同时具备(a)和(b)两种风格, (c)就是这两种风格的混合风格. 图 11 混合了异常捕获和缓冲重启的容错风格 3.2.3 调整规划与实施 通过对比原始数据服务与满足异常捕获和缓冲重启风格的数据服务, 可以得到一组沟通 二者的调整操作, 并得到如图 12 所描述的调整方案. 进一步, 调整方案还要映射为实际的中 间件管理操作, 然后由中间件自动完成实际的调整. 首先, 当数据库连接失效并导致数据服务 发生故障时, 数据服务会向调用失效数据库连接的实体Bean构件抛出异常. 从SA的层次来看, 这个异常会沿着数据服务与实体Bean构件之间的连接子传递, 可被中间件提供的截取器捕获. 其次, 重启功能可以通过把一个更新数据库连接的截取器插装到数据服务内部来实现, 这个 位于数据服务和数据库之间的截取器可以更新已失效的数据库连接. 再次, 在请求转发器和 构件实例池之间的截取器可以在数据库连接恢复过程中阻塞调用 OrderEnt 的所有请求, 并在 数据库连接恢复成功后解除阻塞. 具体而言, 图 12所示的调整方案被映射为如下操作: 1) 新增一个用于捕获数据服务异常的截取器 DataServExceptInterceptor, 并加入到原有 EJB 容器的截取器链中 (对应调整操作 1~4). DataServExceptInterceptor 截取器实现了 handleException方法, 所有应用构件抛出的异常要经过这个方法的处理, 并向这个方法提供完 梅宏等: 基于体系结构的网构软件自适应方法 916 整的异常信息. DataServExceptInterceptor要对截获的异常信息进行分析、识别, 以确定异常是 否来自数据服务. 图 12 SA风格驱动的自适应调整方案 2) 新增一个用于恢复失效数据库连接的截取器 ConnectionInterceptor, 并插装到数据服务 中(对应调整操作 5~7). 当数据服务中的数据库连接失效后, 此截取器不断尝试获得新的数据 库连接, 并用新的有效数据库连接替换数据服务中的失效数据库连接. 3) 在请求转发器和构件实例池之间增加一个截取器 ReqBufInterceptor, 用于在数据服务 恢复过程中阻塞所有欲使用数据服务的新请求(对应调整操作 8和 9). J2EE中的任何新请求都 要先在实例池中获得一个空闲的实例后才能做下一步处理, 因此, 通过停止分配实体 Bean 实 例可以保证不会产生新的数据服务访问请求. 这种有选择的阻塞能力使得那些不使用数据服 务的应用构件的执行不受该截取器影响. 当数据服务恢复成功后 ReqBufInterceptor 重新恢复 实例分配. 4) 向全局的控制器 RecoveryManager中增加一条恢复策略[18](对应调整操作 10~12). 简而 言之, 这条恢复策略可以描述为“if(DataServExceptInterceptor 发现了数据服务异常)then(调用 ConnectionInterceptor 恢复数据服务并使用 ReqBufInterceptor 缓冲新到请求)”. RecoveryMan- ager 基于恢复策略协调恢复活动, 并作为中间件的一个服务存在, 其执行过程为: (a) 接收从 DataServExceptInterceptor 发来的异常信息 ; (b) 在确定是数据服务发生失效后 , 启动 ConnectionInterceptor 对数据服务进行恢复, 与此同时, 启动 ReqBufInterceptor 阻塞新到的实 体 Bean访问请求; (c) 待数据服务恢复正常后, 停止 ConnectionInterceptor的执行并解除对实 体 Bean请求的阻塞. 3.2.4 容错效果评估 为了评估上述自适应效果, 本文使用故障注入方法, 周期性地向 PKUAS中注入数据库连 接失效, 同时在客户端使用开源性能测试工具 OpenSTA 模拟并发的客户