PDF《一种良构可扩展的构件运行平台容器系统》

第2卷第10期2007 年10 月708 一种良构可扩展的构件运行平台容器系统 范刚,曹东刚,周明辉,肖赞,梅宏(北京大学信息科学技术学院软件研究所, 高可信软件技术教育部重点实验室, 北京 100871) 摘要:随着 J2EE 等构件运行平台的迅速发展和广泛应用,构件运行平台要提供的功能越来越多,导致其自 身的结构越来越复杂.

因此如何设计一种良好的体系结构, 保持构件运行平台的灵活性和扩展性成为一项挑战. 本文提出一种良构可扩展的构件运行平台容器系统. 基于该系统, 构件运行平台在保持其结构模块化和灵活性 的同时,其功能可以容易地被进行扩展和定制,以满足不同用户的需求和适应动态多变的环境. 关键词:计算机软件与理论;

构件容器;

良构;

关注点分离 中图分类号:TP301 文献标识码:A 文章编号:1673-7180(2007)10-0708-7

0 引言 构件运行平台(Component Operating Platform),也 称为应用服务器(Application Server),为构件应用提供 运行支撑平台,极大地简化了应用开发.然而,随着 构件化应用越来越多,应用服务器要支持越来越多的 功能,导致其自身结构越来越复杂,环境变化时的适 应能力越来越差.构件容器是应用服务器设计和实现 的核心,其设计直接影响到整个应用服务器的架构. 构件容器为构件提供运行环境,为构件提供各种公共 服务,并代理构件之间的交互,具有众多交织的关注 点,容易使得容器结构复杂,和其他功能模块间相互 依赖,不利于应用服务器的管理、维护和功能扩展. 通常情况下,应用服务器要提供新的功能,就必须改 动构件容器的代码,如在 JOnAS 或PKUAS2004 上增 加集群能力,就需要手工修改生成客户存根的编译器 代码,并会对容器作大量的修改.因此,如何设计一 种良构易扩展的容器系统,是应用服务器自身良构化 的关键. 本文以 PKUAS2004 为工作基础,分析其存在的 问题,重构系统结构,使用适当的设计模式和合理的 框架来分离容器的关注点,建立了一种良构可扩展的 构件容器系统,并基于该系统,讨论了如何针对动态 多变的环境,扩展和定制应用服务器以满足特定领域 的需求,并保持应用服务器代码良好,模块性强.本 文所提出的各种机制和框架都已经成功地应用到 PKUAS2006 中,并在实际应用得到测试和检验.本文 的组织如下:第1节是问题分析;

第2节介绍 PKUAS 的容器系统;

第3节是实例研究;

第4节是相关工作 比较;

最后是结束语.

1 问题分析 PKUAS2004[1] 是一种典型的 J2EE 应用服务器, 它 使用基于 JMX 的内核来加载各种容器和服务, 提供了 基于静态编译的互操作框架来集成不同的通信协议, 使用基于截取器的拦截的调用方式来接入各种公共服 务.分析 PKUAS2004 的系统架构,其存在以下问题: 1) 在通信机制上,互操作框架采用静态编译的方 式来生成客户端存根 stub,客户端需要显示地引用 stub;

各种需要被远程访问的公共服务都需要特定的客 户端存根 stub 格式,增加任何服务方法都必须重新编 译;

集群和单机环境下客户存根 stub 有较大的差异, 需要改动消息格式并更改 stub 的生成方式. 2) 在服务接入上,各种公共服务接入的截取器以 基金项目: 国家重点基础研究发展规划项目计划 (973 计划) (2005CB321805) , 国家自然科学基金 (

60503029、

60603038、 90412011) , 国家高技术研究发展计划(863 计划) (2007AA01Z133) 作者简介:范刚(1983- ),男,硕士研究生 通讯联系人:曹东刚,讲师,E-mail: [email protected] 中国科技论文在线 SCIENCEPAPER ONLINE 第2卷第10期2007 年10 月709 中国科技论文在线 SCIENCEPAPER ONLINE 硬编码的方式存在于容器中,任何对服务的增删都会 影响容器系统模块,缺乏一种系统化的方法来扩展和 定制公共服务;

截取器接口比较杂乱,同时缺乏一种 系统的配置和调整机制;

只能为服务器端的服务提供 约束,而不能为客户端提供截取器,缺少一种客户/服 务器的整体视图. 3) 在功能扩展和服务集成上,任何模块的更新和 服务的增删都会影响容器系统模块. 上述问题的主要症结,在于应用服务器中容器系 统、通信框架、服务接入模块的结构化不清楚,彼此 间的合约不够清晰合理,导致关注点交织;

缺乏系统 的框架来指导和约束程序员的开发行为,导致代码和 结构杂乱.这些问题不仅仅存在于 PKUAS2004 中, 同样也存在于其它各种通用应用服务器如 JonAS 等中.随着应用服务器版本的演化,这些问题将渐趋严 重.因此,如何处理容器、公共服务和通信机制间的 复杂交互关系,成为应用服务器开发人员面临的主要 设计挑战. 应用服务器自身在规范定义方面的不完善,同样 加剧了上述问题. J2EE1.4[2,3] 以前的规范把构件模型和 远程模型混在一体,构件模型和远程模型重叠,这就 要求应用服务器在设计构件容器系统时考虑到构件的 分布性,容器需要维护构件的远程客户视图,在一定 程度上造成了容器和通信机制间的耦合.公共服务同 样可能需要被分布的客户端访问,而服务上下文传递 也需要通信机制的支持,通常存在和通信机制的耦合 问题.应用服务器中的容器为构件提供运行环境,需 要考虑各种关注点,如维护构件的客户视图,包括生 成构件远端代理等工作,为构件提供各种公共服务, 部署和加载构件化应用等.容器通常通过公共服务实 现某关注点,因此容器和公共服务之间直接或间接的 依赖不可避免,需要采取适当的设计模式和框架来分 离容器的关注点,减少容器系统和其他模块的代码耦 合,增强系统的可配置性和扩展性. 本文的目标是探索应用服务器的模块化体系结构 设计问题, 以J2EE 应用服务器为试验平台建立一个轻 量级的良构化容器系统,尽可能地分离容器中交织的 关注点,从而使系统结构良好、层次清晰,同时具备 良好的扩展和定制能力,支持系统功能扩展和演化.

2 良构的容器系统设计 模块化、层次化的软件架构具有很好的可配置性 和扩展能力,同时分层也降低了模块间依赖关系失控 的风险,有利于系统的维护和升级.本文运用关注点 分离原则和适当的软件设计模式,分离容器复杂的关 注点,提出了一种层次清晰的应用服务器核心架构. 如图

1 所示, PKUAS 的核心架构在纵向上可以分为 三层: 调用器 伺服器 容器 JRMP 调用器 截取器 服务截取器 服务API 事务管理器 代理管理器 通信层 远程框架 容器系统 服务框架 服务提供者 服务伺服器 图1层次化核心架构 Fig.

1 Layered kernel structure 1) 容器系统(Container System):容器为构件提供 运行环境,其主要功能是实现容器与构件的合约,维 护构件运行的上下文(如安全与事务上下文) ,管理构 件的生命周期(如类装载、实例化、缓存、释放等) , 为公共服务接入提供检查点以实现关注点分离. 2) 服务框架(Service Framework):实现公共服务 集成和接入,是容器和各种服务之间的胶合层.服务 框架能有效的集成和扩展服务,并能以一种可配置、 可调整的方式把公共服务接入到 EJB 调用逻辑中.服 务框架将各种服务逻辑分而治之并模块化为一个个可 插拔的服务截取器(ServiceInterceptor),而容器只需要 在EJB 交互过程中提供检查点供服务接入,从而把服 务逻辑彻底从容器系统中剥离出来.服务框架能为容 器向外屏蔽具体服务的实现细节,保持容器系统的稳 定性. 3) 远程框架(Remoting Framework): 是容器和底层 具体的通信实现间的胶合层.远程框架抽象了通信共 性,建立了一种一致的远程调用方式;

规格化了底层 通信和上层容器间的伺服器合约(Servant), 容器以伺服 器合约的一种实现体的方式在部署时被注册到调用器 (Invoker)上, 并在运行时被调用器回调. 具体的通信调 用器(如JRMP Invoker)以一种可配置的方式接入到 远程框架中.远程框架能很好的向上屏蔽底层通信细 节, 能有效的分离容器和通信机制交互部分的关注点. 这种架构具有很好的稳定性和扩展性.服务框架 第2卷第10期2007 年10 月710 是容器和具体服务提供者间的中间层,远程框架是容 器和通信层间的中间层.采用控制反转(IoC)的设计思 想,容器不再直接依赖于具体的公共服务和通信层, 具体的服务提供者和通信机制的实现以一种系统化 的、可配置的方式接入到容器当中,从而在一定程度 上分离了容器原本非常复杂的关注点.各个层次间合 约清晰, 各层之间的接口到实现的绑定都是可配置的, 系统具有很好的可配置性. 2.1 远程框架 远程框架为容器系统屏蔽了远程调用的所有细 节,如生成远端代理等. 本文采用动态代理(Dynamic Proxy[4] )以反射的方 式动态为客户端生成远端代理,供容器维护构件的客 户视图.本文的远程框架如图

2 所示,具有很好的灵 活性: (1) 动态代理可以将作用在多种构件接口上的方 法调用委派到统一的调用器(Invoker)接口上, 可以实现 多路复用. (2) 利用动态代理能很容易地将异构的类型 化的方法调用映射成一组非类型化的消息格式 (InvocationRequest/InvocationResponse)上, 这些消息包 括EJB 调用所必需的信息及可扩展的服务上下文映射 表,和具体底层通信实现无关,很好地抽象了通信共 性.(3) 更方便地支持需要分布调用能力的系统服务, 如安全、事务等.本文提出的远程框架不但可以支持 容器和构件,同样能支持系统服务,有效提高了系统 的复用性. 图2远程框架 Fig.

2 Remote framework 远端代理是一个类型化的代理,由构件接口、客 户容器(和动态代理绑定的回调对象)和一组客户端 截取器构成,有效地封装了底层通信逻辑及服务上下 文传递等逻辑.在服务器端,PKUSA 抽象通信共性, 形成底层通信和上层伺服器(Servant)之间的合约. 通过 动态代理,PKUAS 使用一致的调用器(Invoker)来代理 RMI 请求,服务器端调用器会将该请求分发到相应的 伺服器上.构件容器或系统服务作为一种伺服器被注 册到服务器端调用器上并在运行时刻被调用器回调. 此外,伺服器生成远端代理对象的工作对于伺服器而 言, 是一种典型的贯穿特性[5] . 本文将生成远端代理的 工作交给图

1 中的代理管理器(ProxyManager)生成, 在 一定程度上分离了容器的关注点. 2.2 服务的接入 如何不修改容器系统却能透明接入各种预定义和 可扩展的系统公共服务并供构件调用,是容器设计的 关键问题. EJB 构件通过 EJB 上下文来使用公共服务, EJB 上下文由容器提供.容器不直接提供服务,而是 接入服务,在EJB 交互过程中为各种服务提供约束. 为EJB 构件提供运行支撑环境是容器的核心业务,而 为各种服务提供约束则是贯穿在 EJB 调用上的横切逻 辑.本文使用截取器把各种服务逻辑在代码上从业务 逻辑中分离出来,并通过配置文件等元数据形式在部 署时组装截取器――即各种服务逻辑――实现公共服 务接入,从而实现了服务的透明接入.PKUAS 的服务 接入框架设计如图

3 所示. 业务层 容器 截取器 服务截取器 服务SPI 服务层 图3服务接入 Fig.

3 Service integration 图3包含两个接入层次:业务层和服务层. 一种良构可扩展的构件运行平台容器系统 第2卷第10期2007 年10 月711 中国科技论文在线 SCIENCEPAPER ONLINE 业务层:容器持有一组服务截取器,在EJB 业务 功能调用前后依次调用截取器对调用请求进行拦截. 服务层:各个服务提供服务截取器,运行时刻被 构建并接入到容器中,用于拦截 EJB 调用.服务截取 器依赖于服务相关的服务提供接口(SPI: Service Provider Interface),SPI 则从容器如何使用服务的角度 抽象并封装服务共性逻辑.为了更好地实现模块化, PKUAS 将所有对服务实现、 服务适配器的引用完全放 在服务层,保证容器层的稳定,从而使增删服务对容 器透明.框架支持用户自定义服务(约束) ,用户只需 要扩展 PKUAS 提供的截取器接口,完成自定义的服 务逻辑,再修改相应的系统或应用配置即可. 这种解决方案,有很高的稳定性:一致的截取器 接口,可以保证容器以统一的行为使用截取器,保证 容器代码的稳定性;

而容器不再持有具体服务实现的 引用,减少了容器和公共服务间的代码纠结.容器层 和服务层之间以可配置、可插拔的方式结合,具有很 好的定制和扩展能力. 此外,本文将基于截取器的服务约束扩展到分布 式调用上,彻底实现服务逻辑与业务处理和构件交互 正交. EJB 构件的客户/服务器交互是一种典型的请求/ 应答流程.针对这种请求/应答模式,系统提供多个检 查点,供截取器接入并在不同的时刻改变交互行为. 检查点包括:在发送请求消息之前、在调用容器之前、 在调用容器之后、在接收应答消息之后.针对一种特 定的服务约束,客户端截取器和服务器端截取器通常 是成对出现的.例如,为了加入安全约束,需要在时 刻①向请求消息中加入包括实体(Principal)和凭证 (Credential)在内的安全上下文,在时刻②从请求消息 中提取实体和凭证,进行认证和授权操作;

如为了给 客户端提供动态特性,需要在时刻③向应答消息中加 入服务器的更新信息,在时刻④从应答消息中提取相 应的更新消息,进而对客户端进行更新. 图4针对分布式调用的截取器机制 Fig.

4 Interceptor configuration for distributed invocation 应用部署时,根据服务器和应用自身的配置,按 需生成并组装应用所需的截取器链,包括客户端截取 器和服务器端截取器,前者在客户端被调用,后者在 服务器端被调用.客户端截取器会在命名查找时经命 名服务器序列化到客户端,也会在 EJB 创建 EJB 对象 时直接返回给客户端.服务器端截取器处................