一种支持动态配置的构件模型及构件工厂

摘要

本发明公开一种支持动态配置的构件模型及构件工厂，该构件包括业务接口、构件体和管理外壳；其中，构件体用于包含子构件；管理外壳提供支持动态配置的元接口。在Java平台下，构件工厂基于体系结构描述实例化构件，包括：元接口实现框架、ADL解析器、字节码动态产生器和类动态加载器。其中，元接口实现框架提供基于体系结构的动态配置方法，包括：生命周期协调器将构件由运行状态切换到相对静止的安全配置状态；在安全期内，成员管理器用于在构件体内部添加、删除或者更新子构件，绑定连接器用于对构件接口之间的连接关系进行动态调整。本发明使得第三方可以通过构件元接口对其体系结构进行在线配置，可有效提升系统在运行阶段的动态扩展性。

说明书

本发明专利申请要求申请日为20110913、申请号为201110270377.5的中国在先申请的 优先权。

技术领域

本发明涉及计算机软件技术领域，特别是指一种支持动态配置的构件模型及构件工厂。

背景技术

随着Internet成为主流的运行平台，软件呈现构件化服务架构的同时，其运行期内上下 文情境(计算上下文、环境上下文和用户上下文)的动态改变又使得软件自身必须响应这些 变化而做出“演化性”调整。可见，“演化”是软件生命周期中最昂贵的活动，它是在软件基 础框架的高效机制支持下，软件系统以进化方式动态调整体系结构的配置组成、以确保其行 为和结果满足当前运行环境的适应性过程。从内在机理来看，基于体系结构的动态配置技术 为系统的动态演化提供了使能机制和有效途径。对于运行期的构件化系统而言，系统的配置 行为主要包括动态添加构件、删除构件、更新构件，以及动态建立连接、解除连接和重定向 连接等。

从当前的业界实践来看，随着对构件内涵和外延认知的不断拓展，构件也从具有相对独 立功能和可复用价值的小粒度单元，向着大粒度、松耦合的服务型构件演进。在产业界，以 Web Service、CORBA、EJB和COM+为代表的服务端构件模型，已成为企业部署分布应用的 主流规范。但是，这些构件模型都缺乏在构件层级对动态配置提供显式支持的能力。从技术 角度来讲，这些商用构件大都作为向外界提供/请求服务的、可重用的黑盒单元，缺乏对构件 管理和控制的语义描述，构件及其运行容器在开放性和扩展性上仅提供了有限的支持。

面对商业构件及其分布应用缺乏动态配置与演化能力的现状，业界和学术界展开了广泛 研究，发布了一些有益的成果。例如，CCM(CORBA Component Model)扩展了传统的CORBA 规范的内容，通过显式建立或撤销对称接口之间的松耦合连接依赖，不仅提高了服务构件的 复用能力，也清晰地刻画了应用的软件体系结构。借助于体系结构高层视图，可以支持动态 的CORBA应用配置等高级管理任务。再比如，JMX(Java Management Extensions)为应用 程序和网络管理监控定义了体系结构、设计模式、接口以及各种服务等。通过这套标准的代 理和服务，可以为基于EJB的分布式应用植入资源管理功能框架。但是，严格来说，JMX只 是一个网络应用管理框架，尚不具备对构件化软件运行时进行动态配置的支持。

中国发明专利ZL200410000773.6，公开了一种构件化软件系统在线增加新功能的方法， 属于软件技术领域。该方法包括以下步骤：

(1)开发支持新功能的新构件；

(2)在线演化现有构件的实现体，向软件系统加载新构件的实现体；然后在构件容器中的 消息与具体实现函数之间的映射表中增加代表新功能的消息与新构件实现体中新具体方法之 间的关联；

(3)为新的构件接口生成骨架程序并加载到系统中，替换老的骨架程序；

(4)更新与运行时刻软件系统对应的文件形态的软件系统，使软件系统中包含新的构件。

该中国发明专利申请的技术方案是面向EJB构件，利用接口定义与接口实现相对分离的 特点，构件的接口等在演化过程中是不变的，只有实现构件功能的具体对象变化。

文献(《分布式系统动态配置技术的研究与实现》，窦蕾，王树凤，徐田荣，计算机科学， 2005，32(12))描述了由国防科学技术大学研制的、遵循CCM规范的分布式构件平台StarCCM。 借助容器并间接利用底层CORBA平台，提供了动态配置所需的大量结构和语义元数据，通 过对构件实施的强大调控能力来增强系统的动态特性，提供5类动态配置基本机制：系统信 息描述及计算机制、构件状态检测机制、构件行为控制机制、构件状态传递机制、动态配置 算法描述机制。

文献(《一种支持软件可信演化的构件模型》，丁博，王怀民，史殿习等，软件学报，2011， 22(1))基于关注点分离原则和动态软件体系结构技术，提出了一种支持软件环境适应能力细 粒度在线调整的构件模型ACOE(Adaptive Component model for Open Environment)。ACOE将 软件环境适应能力中的感知、决策、执行等关注点封装为独立的构件和连接子，通过动态软 件体系结构技术来支持它们的在线重配置。

纵观国内外研究动向可以看出，当前演化研究的热点集中于通过对现有构件平台的修改 和扩展来提高应用的动态配置能力。所采用的方法主要包括：对原有的构件计算平台进行较 大扩展，开发人员在分布构件管理框架下编写大量处理系统动态特性的代码，负担重、复杂 度高；依靠平台提供的动态配置所需的大量结构和语义元数据等反射要件实现应用的动态配 置，但对构件平台的反射能力需求较高；依靠构件容器对构件的特殊调控来提高系统的在线 演化能力，但也需对容器进行扩展。因此，现有的基于构件建造的软件系统为了实现动态配 置需要额外付出较大代价。

发明内容

本发明的目的是针对服务构件架构下的应用系统缺乏行为动态性和结构灵活性的现状， 在沿袭传统构件模型基本特征的基础之上，提出一种具有良好的构造性(体系结构易于刻画) 和演化性(体系结构易于动态配置)的构件模型及构件工厂，以提高构件化应用在运行阶段 的开放性、适应性和可扩展性。

达到上述目的，本发明的实施例提供了一种显式支持体系结构动态配置的构件模型及构 件工厂，构件模型包括：业务接口、构件体和管理外壳；其中，所述业务接口模块是构件与 外界的服务交互点；所述构件体模块用于嵌套包含子构件；所述管理外壳模块提供支持动态 配置的元接口。所述构件工厂用于在Java平台下创建构件实例，以实现构件从静态体系结构 描述到可运行实例的无缝过渡。

作为上述技术方案的优选，所述管理外壳模块提供支持动态配置的元接口，包括：

生命周期协调元接口，用于提供对构件的运行状态进行动态调控的接口；

成员管理元接口，用于提供对构件内的子构件成员进行动态配置的接口；

绑定连接元接口，用于提供对构件之间的接口绑定进行动态配置的接口；

进一步的，本发明实施例还提出了前述的支持动态配置的构件模型的实例化工厂，以实 现构件从静态体系结构描述到可运行实例的无缝过渡，所述构件工厂包括：

元接口实现框架模块，用于遵循构件模型的元接口标准定义，在Java平台下提供元接口 的内核编码实现，为动态创建构件实例提供基础类库；

ADL解析器模块，用于载入构件的体系结构描述，生成一棵可被字节码动态产生器执行 的实例化任务树；

字节码动态产生器模块，用于一边遍历所述实例化任务树，一边基于ASM字节码框架 创建构件实例对应的各对象实体的字节数组；

类动态加载器模块，用于把字节数组转换为类的实例，采用双亲委托的加载链机制，将 返回的Class对象载入JVM，以创建可运行的构件实例。

作为上述技术方案的优选，所述的构件可运行实例的特征在于基于对象范型创建与构件 实例相映射的一组对象集，具体包括：

业务接口对象，构件的每个业务接口对应一个业务接口对象，该对象拥有业务接口实现 对象的强引用，用于将对接口的操作调用分派给对应的实现对象来执行；

业务接口实现对象，与业务接口对象一一对应，该对象不仅提供了业务接口的具体功能 实现；

元接口对象，由外壳元接口实例化得到，用于接收外界对构件的动态配置请求，并委派 给相应元接口实现对象处理；

元接口实现对象，每一个元接口对象都将对应一个实现对象，用于接受元接口对象的委 托请求，是观测、控制和调整构件行为或结构、实现动态配置逻辑的核心实体；

上下文对象，用于建立上述对象集与构件之间的映射关联，由它来维护构件自身运行的 上下文属性，该对象将构件的其它关联对象的引用存储在专用数据结构中，以维持各对象之 间的因果联系。

作为上述技术方案的优选，所述元接口实现框架模块的方法包括：

生命周期协调器，用于将目标构件及其子构件由正常运行状态正确切换到相对静止的安 全配置状态，有效避免生命周期协调过程中因阻塞重入请求而引发的构件异常死锁；

成员管理器，用于在构件的构件体内部动态添加、删除或者更新子构件；

绑定连接器，用于在构件的业务接口之间动态建立/解除连接，或者对已经存在的绑定进 行重定向。

作为上述技术方案的优选，所述ADL解析器模块的实现装置包括：

AST转换器单元，用于一边读取载有体系结构描述的XML文档，一边将其变换成一个 特定的结构化中间表达——抽象语法树；

任务规划器单元，用于一边遍历抽象语法树，一边定义构件实例化过程中的各种任务， 最终生成一棵可被字节码动态生成器执行的实例化任务树。

作为上述技术方案的优选，所述字节码动态产生器模块的实现装置主要包括：

业务接口实现类产生器单元，用于创建业务接口实现类，它基于AOP(Aspect Oriented  Programming)动态编织技术，可将拦截型的多维控制代码动态添加到构件的业务接口实现类 中；

元接口实现类产生器单元，用于创建元接口实现类，它基于线性混入技术，将所述元接 口实现框架单元内的混入式多态类聚合在元接口实现类中；

上下文类产生器单元，用于创建上下文类，它是与每一个构件实例相对应的背景环境对 象，由该对象维护构件自身运行的上下文属性，可将构件的其他关联类的引用存储在专用数 据结构中，以维持各对象之间的因果联系。

作为上述技术方案的优选，所述生命周期协调器用于将目标构件由正常运行状态切换到 相对静止的安全配置状态，具体包括：

向目标构件发送第一控制指令，以使目标构件从正常运行状态切换到准停态，在此期间， 当目标构件需要向外界发出新的服务请求时，将会在请求中自动追加一个预设特殊标识，且 与该请求直接相关的中继处理请求都会保留特殊标识；此状态结束之前，目标构件向其子构 件发送第二控制指令，以驱动子构件切换到等停态，它自身则转入等停态；其中所述第一、 二控制指令中包括预设标识；

在等停态阶段，所述目标构件除了有选择地响应带有预设特殊标识的重入请求外，将强 制阻塞其他任何外来请求；而内部子构件的计算行为不受约束，当任务处理完毕后变为空闲， 该子构件由等停态切换到允停态，并由内向外依次向目标构件发送第三控制指令；其中所述 第三控制指令中包括预设标识；

所述目标构件接收到子构件的第三控制指令后，向全体子构件发送第四控制指令，以使 所有子构件切换到安全配置状态；其中所述第四控制指令中包括预设标识；

当所有子构件切换到安全配置状态时，目标构件也切换到安全配置状态。

作为上述技术方案的优选，所述成员管理器用于在构件体内部动态添加、删除或者更新 子构件，具体包括：

成员配置合法性检查单元，用于前摄式验证，采用谓词型约束检查以确保成员管理的合 法有效；

成员添加单元，用于在构件内部动态添加指定的子构件；

成员删除单元，用于动态删除指定的子构件；

成员更新单元，用于以新的子构件替换指定的子构件。

作为上述技术方案的优选，所述绑定连接器在构件的业务接口之间动态建立/解除连接， 或者对已经存在的绑定进行重定向的方法及装置包括：

绑定配置合法性检查单元，用于前摄式验证，采用谓词型约束检查以确保绑定连接配置 的合法有效；

绑定建立单元，用于在构件业务接口之间动态建立连接；

绑定解除单元，用于解除已经建立的接口连接关系；

绑定重定向单元，用于将已经存在的接口绑定重新定向到新的接口上。

本发明的有益效果是：本发明给运行阶段的软件系统和应用带来新的亮点。它使得第三 方可以在必要时通过管理外壳上支持体系结构动态配置的元接口，对该构件的运行状态、内 部实体组成及其互连关系等进行局部地在线调整或重构，而不会影响系统整体的稳定运行， 从而以很小的代价换来软件系统良好的行为动态性和结构灵活性，可有效提升运行期系统的 扩展性和动态适应能力。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术 描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一 些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这 些附图获得其他的附图。

图1为SMC构件的抽象模型。

图2为基于SMC/ADL的构件体系结构描述。

图3为构件工厂的总体架构。

图4为构件实例与其对象空间之间的映射。

图5为ADL解析器的构造方法及装置。

图6为字节码产生器的构造方法及装置。

图7为上下文类的构造方法。

图8为生命周期协调器驱动下的构件状态切换步骤。

具体实施方式

下面将结合本发明的附图，对本发明的技术方案进行清楚、完整地描述，显然，所描述 的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领 域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护 的范围。

以下通过一个具体的实例对本发明做进一步说明。

本发明提供一种具有良好的构造性(体系结构易于刻画)和演化性(体系结构易于动态 配置)的构件模型SMC(SoftMan Component)，由业务接口、构件体和管理外壳组成。其中， 业务接口是构件与外界的服务交互点；构件体用于嵌套包含子构件；管理外壳提供支持动态 配置的元接口。

如图1所示，SMC构件定义为一个三元组，即SMC＝<BI，CB，MShell>。各模块特征描 述如下：①业务接口BI(Business Interfaces)：是构件与外界环境和其它构件的交互点，封 装了构件作为服务实体的业务功能逻辑。BI接口定义为一个四元组，即 BI＝<int erfaceName，type，multiplicity，signature>。根据与外界交互的目的不同，接口的type分 为对称的两类：provided和requested。multiplicity连接多重性表达构件之间基于接口的显式 依赖进行绑定时可以允许的连接数目约定。基调signature则描述了接口的操作名、返回类型、 形参等语法特征。②构件体CB(Component Body)：SMC利用构件体形象地刻画构件的层 级嵌套特征。在图1中，复合构件C的构件体中封装了3个(α、β和γ)具有一定配置结构 的“子构件”集。而这些直接“子构件”仍可以继续嵌套其他的“子构件”集，直至CB为空 结构的原子构件。③构件管理外壳MShell(Management Shell)：与传统构件基于容器的内 核级运行、管理和控制机制不同，MShell为描述、控制和调整构件的行为和结构从构件级别 提供了显式的高层接口。为了与功能性业务接口相区别，把这些支持动态配置的非功能接口 称为元接口。在图1中，示意了SMC构件的管理外壳缺省提供3标准元接口，它们分别是： LifeCycleCoordinator(生命周期协调元接口)驱动处于运行常态的构件进入可配置的安全状 态，或者逆向激活；MemberManager(成员管理元接口)用于在构件体内部添加、删除或更 新子构件；BindingConnection(绑定连接元接口)用于对构件之间的接口绑定进行动态配置。 上述元接口为动态操纵和控制SMC构件的运行行为或内部结构提供了使能机制。需要说明的 是，MShell提供了针对构件微观行为和结构进行特殊管控的“灰盒框架”，但是，它本身并 不进行任何的控制处理，所有的非功能关注均由其元接口来实现。这些元接口与管理外壳之 间松散耦合，使得各种与动态配置相关的非功能关注可以独立表达和封装。

为了支持基于软件体系结构的动态配置，本发明选择可扩展标记语言XML作为元语言， 提出定义和表达SMC构件及其系统体系结构的规约语言——SMC/ADL(SMC Architecture  Description Language)。

图2基于SMC/ADL的建模元素(业务接口、构件、接口绑定等)，对图1所示复合构件 的体系结构配置进行了抽象刻画。其中，<component>标签描述了构件的标识符(name)和 类型(type)属性。业务接口特征由<businessinterface>元素表达，其type属性指定了构件的 类型provided或者requested；multiplicity连接多重属性(multiplicity＝[1..1]OR[1..n]OR[0..n] OR[0..1])描述了构件之间基于接口绑定时的连接数目约定。例如，对于requested接口而言， 如果其multiplicity＝“1..1”，则表示系统运行前，该接口必须进行绑定；如果multiplicity＝ “0..1”，则表示系统运行前此接口不必绑定或者需要时与另一个provided接口动态绑定；基 调signature属性则提供了接口的操作名、返回类型、形参等语法特征描述。<componentbody> 标签描述了构件体的配置特征。在构件体内部，分别利用3个<subcomponent>标签刻画了构 件C与构件α、β和γ之间的“父-子”包含关系。为了描述构件C内部的连接配置情况，定 义了2个标识构件之间绑定关系的标签：一个是水平绑定<horizontalbinding>标签，即：指定 隶属于同一父构件的、不同直接子构件的required和provided接口之间的连接依赖；另一种 是垂直绑定<verticalbinding>标签，即配置父构件与内部的直接子构件之间的连接关系。需要 说明的是，SMC/ADL描述的抽象系统就是一个包括不同粒度子构件的、多层级、结构化的 复合构件，其中每一个复合构件就是一个子系统；同时，系统也可以看作是一个粒度最大的 复合构件。因此，从这个意义上来讲，复合构件和系统只有层次上的差异。

体系结构描述仅仅从全局配置的角度给出了构件的静态抽象，构件工厂为实现从体系结 构的高层结构模型到可运行系统的过渡提供了可能。它能够将定义的建模元素映射为显式的 体系结构实例，支持系统模型向可运行实体的转化。在软件工程领域，成熟的分布式对象技 术已经成为创建构件运行平台的有效方案。SMC构件的实例化也将采用面向对象(Java平台) 的技术路线来实现。

图3所示为构件的实例化装置——构件工厂的总体架构，各个模块的功能描述如下：

①元接口实现框架模块，遵循构件模型的元接口标准定义，在Java平台下提供元接口的 内核编码实现，为动态创建构件实例提供基础类库；

②ADL解析器模块，用于载入基于XML表达的构件体系结构描述文档，从ADL (Architecture Description Language)中抽取与构件实例化相关的语义，生成一棵可被字节码 动态产生器执行的实例化任务树(ITT，Instantiation Task Tree)；

③字节码动态产生器模块，一边遍历ITT树，一边利用ASM字节码框架调用不同的字 节码生成模板来创建构件实例对应的各对象实体(包括：业务接口类、元接口类、业务接口 实现类、元接口实现类和上下文类)的字节数组byte[]；

④类动态加载器模块，用于将创建字节数组byte[]转换为类的实例，采用双亲委托的加载 链机制，将返回的Class对象载入JVM，以创建可运行的构件实例。

从宏观结构来看，基于SMC的软件应用可以分解为一组层级嵌套的构件及构件之间的交 互关系；从微观组成来看，分布对象技术支撑下的构件化系统本质上又表现为对象风格的软 件架构。在对象范型的软件体系结构中，SMC构件实际上对应于一组具有关联的对象集合， 且本质是通过这些对象之间的协作完成构件的业务功能和演化操作。

图4为对象范型下，构件实例映射的一组对象空间，具体包括以下5类对象：

①业务接口对象，构件的每个业务接口对应一个业务接口对象，该对象拥有业务接口实 现对象的强引用，用于将对接口的操作调用分派给对应的实现对象来执行；

②业务接口实现对象，与业务接口对象一一对应，该对象不仅提供了业务接口的具体功 能实现；

③元接口对象，由外壳元接口实例化得到，用于接收外界对构件的动态配置请求，并委 派给相应元接口实现对象处理；

④元接口实现对象，每一个元接口对象都将对应一个实现对象，用于接受元接口对象的 委托请求，是观测、控制和调整构件行为或结构、实现动态配置逻辑的核心实体；

⑤上下文对象，用于建立上述对象集与构件之间的映射关联，由它来维护构件自身运行 的上下文属性，该对象将构件的其它关联对象的引用存储在专用数据结构中，以维持各对象 之间的因果联系。

在界定了构件运行对象空间的边界之后，构件工厂的核心功能将变得更加明确，即依据 构件的体系结构描述，将构件实例具体映射为与其一一对应的一组关联对象集合，并使得这 些对象之间协调配合以实现构件的功能计算(业务服务逻辑)和非功能计算(动态配置逻辑)。

图5为ADL解析器模块的构造方法及装置。ADL解析器是加载、分析和处理构件体系 结构描述的专用工具，也是构件实例化流程的第一阶段。从基本层面上来讲，ADL解析器是 流水化作业的：首先，读取载有体系结构描述的XML文档(*.smc)；然后，AST转换器将 其变换成一个特定的结构化中间表达——抽象语法树(AST树)；继而，任务规划器一边遍历 AST树，一边定义构件实例化过程中的各种任务，最终生成一棵可被字节码动态生成器执行 的实例化任务树(ITT树)。

AST树中的每个Node映射于体系结构的建模元素及其属性。其中，每个Node包括：type (节点类型)、parent(父节点)、children(子节点列表)和property(节点属性)。为便于访 问AST树，除根节点外，其余节点均含有指向其父节点的parent域。当生成正确的AST树 之后，任务规划器接管后续工作。它负责遍历AST树，每当访问到AST树中代表构件或者 接口类型的节点时，就会在ITT树中注册一个新的任务节点。由此可以看出，ITT树的每一 节点实际上表征了一项将参与到构件实例化过程中的、既相对独立又与其他节点存在关联和 数据交换的字节码创建任务。

图6为字节码产生器的构造方法及装置。字节码动态产生器的职能是执行ITT树制定的 任务规划，以动态生成SMC构件映射的类空间。这里需要说明的是，采取动态创建构件映射 的类空间的策略主要基于以下客观实际：众所周知，字节码是Java编译器编译源文件(.java) 之后的产物，它的实例化即为Java对象。但是，在支持SMC构件运行的对象空间中，有些 对象(如服务接口实现对象)是由构件的设计实现人员直接提供源码；而还有些对象(如外 壳元接口实现对象、上下文对象)则是由构件工厂自动生成的。尽管元接口实现框架提供了 统一的外壳元接口编码实现，但是，它们并不属于构件的私有源码资源，更不可能直接实例 化为有效的对象实体。由此诞生了字节码的动态生成方案，即：对于前一类对象，为了与构 件的动态配置机制相适应，通过字节码重构增强其基础代码的功能；而对于后一类对象，则 基于内核实现框架，完全从无到有进行动态创建。

ObjectWeb ASM是轻量级的Java字节码(ByteCode)处理框架。它可以基于访问者模式 生成二进制格式的字节码，还能够在类被JVM装入内存之前完成动态创建或重构。基于ASM 框架，字节码动态产生器首先，启动对ITT树的深度优先遍历；然后，一边访问ITT的任务 节点，一边通过内嵌的调度器确定任务类型；接着调用相应的字节码producer模板来构造不 同的字节码对象，最终衍生出构件对应的类集合空间。限于篇幅，这里以代表性的业务接口 实现类producer、元接口实现类producer和上下文类producer为例，阐述不同producer的字 节码构造方法。

①业务接口实现类producer：从本质上讲，SMC构件间的交互是通过其接口处的若干操 作调用来进行的。因而，为了对构件业务接口的服务行为进行特殊控制，设计了服务接口实 现类producer，以利用Java字节码的动态重构技术，自动地将拦截型的多维控制代码(如演 化监控、日志、权限等)，动态编排与封装在构件服务接口实现的Class类中。为了以一种有 效的方式完成控制关注点的动态注入，可以将这些关注点刻面化，每一个刻面都对应一个字 节码拦截器(命名规则为*Interceptor)。在服务接口实现类producer的协调与管理下，拦截型 代码以一定的次序和编制规则共同作用于类的原方法，完成刻面公共代码和方法中基础代码 的动态组合与编排。对于不同拦截代码的织入都一律转换成通用的weaveInterceptorCodeBlock 方法调用。拦截器会把方法m的Method对象、MethodVisitor、编织的位置pos和方法参数的 常量表索引beginIndex传入weaveInterceptorCodeBlock，该方法内部又通过不同visit事件的 先后调用(时间的先后)，转换成字节码的位置调整(空间的前后)，最终产生一个服务接口 实现类的Class文件。拦截框架还对各种控制关注点进行了细化处理，将每一次的方法拦截 细分为before(前置型)和after(后置型)两种方式。由此可以看出，为了支持动态演化， 业务接口实现类producer实现了在构件服务接口的方法被访问之前/之后自动植入跟踪代码或 新的控制逻辑。这样，在系统性能无明显额外代价的情况下重构了一个临时class类，不仅没 有影响构件的原有功能，而且以灵活的、实时的代码插装方式为支持动态配置注入了特殊的 验证机制。

②元接口实现类producer：在外壳元接口的内核实现中，始终贯彻分散关注、代码重用 和功能拆分原则，将元接口不同控制关注点的默认实现都保留在独立的Abstarct类中来提供。 但是，Java类只能够继承单一父类，所以高层接口无法通过多重继承的方式在同一个类中获 得元接口的多态实现。为此，将元接口的多态实现视为不同的混入类。每个混入类要么实现 了元接口定义的若干方法，要么重载其他混入类的特定方法以体现元接口“控制行为”的多 态性。在混入类的实现中，采用了简单而有效的模式编程策略，避免了引入其他混入机制而 带来的额外开销。该模式策略如下：在接口特定方法的实现中，如果直接引用超类中的成员 属性或者方法实现，则以“this”为前缀重新命名后再使用，并在类中声明；如果需要调用 被覆写的超类中的成员方法，则在引用的方法名称前用“super”前缀重新标识，也在类中声 明；对于新增的属性和方法，则不加任何特殊前缀。这样，在构件实例化的过程中，再利用 线性混入机制，有序地地将元接口的混入式多态“行为”有机地聚合在一个类中，从而动态 生成新的、具有多重继承优点的子类。其基本方法是：在List类型的mixinClasses容器中存 放着n个待混入的混入类的线性列表(MC0，MC1，......，MCn-1)，那么新派生的子类C 将由mixinClasses列表逆序方式混入继承得到。即，混入的线性序列为：MCn-1继承MCn-2， MCn-2继承MCn-3，以此类推，直至MC1继承超类MC0。由此可见，新生成的子类C与 它的基类之间的继承关系，可以表达为一个有向无环图。为此，我们提出由基类构造C的全 序化规则：类C以基类MCn-1作为全序的最后部分，前面是类MCn-2的全序(MCn-2作为 全序的最后部分，前面是类MCn-3的全序)，以此类推，直至类MCB0的全序(类MCB0作 为全序的最后部分，前面为空)。按照线性全序化规则，在混入一个Mixin类时，其代码将做 适应性修改后，才能结合到C类中。对于用“_this_”前缀标识的属性或者方法成员，截取前 缀后直接混入C类中；而对于用“_super_”前缀标识的成员方法，为了区分多个父类中重载 的同名成员，正确标识继承后的引用关系，利用Map型容器counters保存了以“_super_”前 缀命名的重载方法与一个递增计数器n(从1开始)的映射关系。当执行动态混入操作时， 可以根据混入的顺序依次利用“n”后缀给同名的重载方法更名，并删除“super”前缀，既保 持了子类命名空间内标识符的惟一性，又能够将多重继承特性注入一个普通的元接口实现类， 从而满足了内核对外壳接口功能的运行时支持。

③上下文类producer：负责维护构件运行属性的上下文类Context由该产生器动态创建。 上下文类存储了与构件相关的各类对象的reference。与reference注册相关的专用数据结构包 含4个集合型的成员变量，分为两类(如图7所示)：一类是有序的List列表，包括shellItfImpls 和businessItfImpls，分别持有外壳接口实现对象和业务接口实现对象的reference；另一类Map 容器，包含shellItfs和businessItfs，它们各自存储着指向外壳接口对象和业务接口对象的指 针。上下文对象具有initial()方法体，主要实现两方面的功能：一是，利用new()操作分别创 建构件各个外壳元接口的实现对象和业务接口的实现对象，并通过List列表的add()操作，将 上述对象分别添加至shellItfImpls和businessItfImpls中；二是，再次利用new()操作创建外壳 元接口对象和业务接口对象，在利用构造函数初始化对象时，通过setImplReference()方法分 别设置外壳元接口及其实现对象，业务接口及其实现对象的委托关系；并使用HashMap的put() 操作，将上述对象的缺省描述字符串与其对象引用的键值对(String，Object)分别存入shellItfs 和businessItfs容器。此外，context对象的getShellItfs(String)方法还提供了通过shellItfs的get() 操作获得任意元接口对象引用的操作，进而使得构件对象空间里的各个实体，能够在上下文 边界内方便地获得所需元接口的对象引用及其控制逻辑。

元接口实现框基于Java平台，以抽象类集合的方式提供了默认实现。这样，在构件实例 化的过程中，就可以通过继承、多态机制，动态派生出元接口实现类的子类，最终加载成为 元接口实现对象而运行。接下来，本实施例将阐述生命周期协调器、成员管理器和绑定连接 器三个元接口的内核实现方法。

生命周期协调元接口定义及其实现方法描述如下。

在开放、多变的分布式环境下，SMC构件之间会基于功能依赖形成动态而复杂的交互调 用场景。如果对正处于运行态的构件实施动态配置，将可能导致系统崩溃。为了维持系统一 致性并确保动态配置过程中系统整体处于相对稳定状态，在动态配置操作实施之前，生命周 期协调器必须驱动目标构件由运行常态跃迁至相对“静止”的可配置状态；同理，当动态配 置任务成功提交后，生命周期协调器还应将调整后的系统局部恢复到可运行的常规状态。生 命周期协调元接口定义如下：

其中，normalToSafeConfigurationState()和safeConfigurationToNormalState()将驱动目标构 件(包括子构件)在“运行常态”和“强安全配置状态”两个宏状态之间透明地跃迁。

通过对SMC构件交互机制及其特征的缜密分析，我们发现，在对一个目标构件SMC_OBJ 实施生命周期协调的过程中，如果不能正确处理它的重入请求，则很可能因阻塞不当而导致 SMC_OBJ无法进入预期状态。最简单的请求重入情况是，目标构件SMC_OBJ向另一构件 SMC′提出服务请求R，而SMC′为了响应该请求又一次向SMC_OBJ发出新的请求R|R′。显 然，SMC_OBJ的生命周期协调器一旦强制阻塞了该请求，将使得目标构件因不能进一步响应 由自身参与的重入请求，而导致其初始请求R无法获得正常应答，故SMC_OBJ将陷入死锁 状态。为了界定目标构件何时进入“冻结”状态，我们给出如下判定规则：目标构件进入相 对静止的可配置阶段，当且仅当其到达“强安全配置”状态。相应地，目标构件处于“强安 全配置”状态，当且仅当以下条件同时成立：①在动态配置即将开始之前，目标构件(包括 内部子构件)自身发出的全部请求都已经得到处理，并且也未响应其他构件提出的请求；②在 动态配置结束之前，目标构件(包括内部子构件)不会自行向外发出服务请求，也不会响应 其他构件提出的请求。

图8把生命周期协调器驱动下的SMC_OBJ及其内部子构件的状态切换过程划分为以下 几个阶段，各阶段的状态特征及其实现方法描述如下：

①运行常态(Normal Running)：这是SMC_OBJ及其子构件实例化之后的普通可运行状 态，动态配置成功提交后也必须将构件复原至此初态。

②准停态(Ready for Stop)：这是一个只有SMC_OBJ才具有的中间状态，用于表征它 已经开始为到达预期终态做出准备。当SMC_OBJ接收到生命周期协调器的准停消息 (READY_FOR_STOP)之后，它进入此状态。在“准停态”维持期间，SMC_OBJ仍然可以 正常响应外界请求并经处理后返回计算结果，也可以接收“准停态”之前发出请求但此时才 返回的处理应答，但是，当SMC_OBJ由于计算需要向外界发出新的服务请求时，将会在常 态下的请求R^out中自动追加一个特殊标识(通过在参数消息中建立一个唯一的特殊值绑定的 方式来实现，简记为R^out§)。我们还规定，与R^out§直接相关的中继处理请求都会保留特殊标 识。所以，当带有特殊标识的中间请求(R^out§|R1|R2|...Rn)再次(或多次)被SMC_OBJ接 收时，仍然能够被快速识别重入身份而立即得到响应。此状态结束之前，SMC_OBJ会向直接 子构件发出等停消息(驱动子构件进入等停阶段)，然后转入下一状态。

③等停态(Wait for Stop)：SMC_OBJ及其子构件都具备的状态，它刻画了构件在等候 停止阶段的行为特征。对于SMC_OBJ而言，该阶段的终止标志是它接收到全体直接子构件 的允停消息(ENABLE_TO_STOP)。在此阶段内，SMC_OBJ可以接收其他构件返回的任何 应答，但是，除了有选择地响应带有Rout§标识的重入请求外，它将强制阻塞其他任何外来请 求。对于SMC_OBJ内部的直接子构件来说，当接收到等停消息(WAIT_FOR_STOP)后， 即进入了“等停态”(注意，由于构件的层级嵌套特征，这一状态实际上是由外向内次第传播 的)。在“等停态”持续期间，由于SMC_OBJ作为对外屏障已经发挥了请求选择性拦截的作 用，所以，子构件的行为(请求服务、接收应答、响应服务和返回应答)就没有必要再受约 束。

④允停态(Enable to Stop)：在这一状态下，SMC_OBJ及其全体子构件都不再响应任何 请求，也不会发出任何服务请求，步入闲置期。对于复合的SMC_OBJ来说，当其最内层的 子构件没有任何处理任务而空闲时，将由“等停态”转入“允停态”，并且向直接父构件发出 允许停止自身的消息(ENABLE_TO_STOP)。当位于次内层的直接父构件陆续接收到其全部 子构件发来的允停消息后，亦将自身状态变迁为“允停态”。如此由内即外逐层发生允停状态 的传播，直至SMC_OBJ成为最后到达“允停态”的构件。此时，SMC_OBJ会向子构件发出 STRONGLY_SAFE_CONFIGURATION消息，驱使子构件进入“强安全配置态”。

⑤强安全配置态(Strongly Safe Configuration)：在此阶段内，SMC_OBJ及其全体子构 件都处于闲置状态，既没有需要响应的服务请求，也不会提出服务请求；并且在对其实施动 态配置期间，如果没有生命周期协调器激活，整个构件都将陷入无行为的“冻结”状态。由 此满足“强安全配置”状态的充要条件。上述方法有效避免了生命周期协调过程中因阻塞重 入请求而引发的构件异常死锁，为驱动目标构件顺利进入“强安全配置态”提供了正确性保 障。

成员管理元接口定义及其实现方法描述如下。

在动态配置安全期内，成员管理器用于在构件的构件体内部添加、删除或者更新子构件， 其元接口定义如下：

其中，addComponent()用于在构件内部添加指定的子构件成员，removeComponent()用于 删除指定的子构件，updateComponent()用一个新的子构件替换指定的子构件。为了确保对子 构件成员实施配置重构管理的合法性，必须在执行操作之前进行谓词型的约束检查(如表1 所示)。仅当这些谓词都返回预期的布尔值时，再利用该元接口实现对象中缺省设置的List 类型的subSMComponentsList属性变量，保存、删除或更新其子构件成员的引用，以此实现 父构件对构件体内部子构件成员的动态维护与管理。

表1成员管理动态配置之前的谓词型约束检查

绑定连接元接口定义及其实现方法描述如下。

绑定连接器包括两方面功能：一是绑定，即对拟连接的接口的型构、兼容性、绑定数目、 构件生命周期状态等等合法性检查，在满足安全约束验证的前提下进行与绑定相关的参数设 置与维护，从而为两接口之间的通信交互提供使能机制；二是解绑定，即撤除两构件之间已 经建立的接口连接。

在基于体系结构层次的动态配置中，绑定连接器主要实现对构件之间基于接口的直接连 接进行重构，具体包括三个方面功能：一是绑定bind()，即对拟连接的两个接口的型构、兼 容性、绑定数目约束等进行合法性检查，在满足安全约束验证的前提下进行与绑定相关的参 数设置与维护，从而为两接口之间的通信交互提供使能机制；二是解绑定unbind()，即撤销 两构件之间已经建立的直接接口连接，解除原本紧耦合的构件关联；三是绑定重定向rebind()， 即对已经存在的接口连接进行调整，使得构件之间的互联关系柔性可调。绑定连接元接口定 义如下：

对于bind操作而言，首先根据接口名称(“XXX”)和服务接口对象引用(obj_proItf)两 个参数，分别利用各自的反射器获得其接口描述符rDesc和pDesc；然后，执行一系列的合法 性先验检查，即谓词型的函数验证(如表2所示)。当全部谓词都返回“真”值时，在绑定连 接器中设置一个MAP型属性成员bindings，利用put方法将(“XXX”，obj_proItf)作为键/值对 添加到集合中，从而为构件之间基于接口的服务调用建立关联。unbind是bind的逆向操作， 它利用remove方法从bindings中删除指定接口所关联的值映射，以解除绑定关系。但是，在 移除映射之前，仍需对接口的有效性(ifExistingBusinessInterface())和绑定的存在性 (ifExistingBinding())等可能造成解绑定异常进行验证。

表2bind()操作执行之前的谓词型约束检查

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉 本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本 发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。