WebX-Core2.0各功能点概要设计说明

概要设计说明

文档编号：__________________

部    门：_WebX框架组______

负 责 人：__杨建宝___________

文档创建信息

文档修订记录

目   录

1目标用户

2名词解释

本文档包括WebX2.0项目的WebX-Core组件的各主要功能点的概要设计，分别为：

1、开发、运行基础环境

2、平台提供持久化基础服务

3、单元测试模型

4、服务质量测试模型

5、开发环境易用性

6、Web安全

7、模块WebContext和Web资源加载

8、Jsp动态编译器的加载

9、Struts 1资源加载

10、Struts 1与Spring集成

11、集成测试

12、Acegi 1.x到2.x的升级（第3阶段）

13、Demo开发（第3阶段）

14、服务端DWR（第3阶段）

15、负载均衡方案（第3阶段）

16、基于SSL的安全传输（第3阶段）

17、表现层缓存content cache（第3阶段）

18、JMX服务器（第3阶段）

以下各章详细描述上述主要功能点的概要设计。

4开发、运行基础环境

4.1需求定义

WebX2.0的开发运行环境由eclipse、equinox、Spring、Spring-DM、第三方类库、WebX2.0类库构成

4.1.1目标

屏蔽OSGi bundle的复杂性，让开发者方便地创建应用模块。

4.1.2范围

本方案适用于一般的java应用或web项目。

4.1.3结构

具体由以下bundle构成：

1.OSGi runtime

可以使用任意的OSGi runtime，但是建议使用equinox，WebX2的各种测试都是在equinox上进行的；

2.Spring core

当前的Spring的jar都是bundle的形式，可以直接安装到OSGi环境中；core部分包括：

1)spring-core

2)spring-context

3)spring-aop及aopalliance

4)spring-beans

3.Spring DM

Spring DM是在spring core和osgi r4的基础上产生的，包括3个bundle：

1)Spring-osgi-core

2)Spring-osgi-io

3)Spring-osgi-extender，该bundle的Activator负责整个spring环境的启动

4.Spring 扩展

我们实现ORM、JdbcTemplate以及TransactionManager都是基于这部分spring的，包括：

1)Spring-tx

2)Spring-orm

3)Spring-jdbc

5.一般

这部分包括被许多开源系统引用的，来自jakarta commons项目组和其它开源组织的jar，我们已经将它们改为了OSGi bundle，包括：

1)日志：commons-logging, logkit, exalibur-logger

2)Junit

3)Commons-collection

4)Commons-httpclient

5)Commons-io

6)Commons-beanutil（MVC需要）

7)Commons-digester（struts需要）

8)Commons-lang

9)Xml处理：xalan, xstream

6.ORM

实现了Hibernate的ORM，这部分包括：

1)Hibernate

2)Dom4j

3)cglib

7.WebX core

包括：

1)支持单元测试的bundle，该bundle只能在执行针对服务实现类、DAO类以及其跨bundle的依赖进行单元测试时，才可引用，如果在集成运行时引用了它，则会导致错误；

2)用于加载来自不同bundle的hbm资源的bundle，开发者须将hbm资源放置在自己的bundle的/hib-res目录下，就可以在安装bundle的时候被加载；

3)用于提供SessionFactory服务的bundle

4)用于提供JdbcTemplate服务的bundle

8.WebX扩展

目前主要是将jmeter移植到OSGi环境下，用于在容器内测试服务的并发稳定性；

9.连接池和jdbc api

服务于ORM和JdbcTemplate，这部分bundle是为了适用于单元测试框架，才被作为bundle

10.MVC

这部分包含了大量的内容，但由于与mozilla JavaXPCom无关，故不赘述；

11.Acegi

Acegi框架依赖spring，由于它基于HttpFilter接口，故只能用于web应用。这里不详述；

12.Http服务

这里不详述。

4.1.4使用描述

对于使用、开发者来说，是不可见的。

4.2特征列表

1、支持MVC模块

2、支持服务模块，这种类型模块主要用于CURD的持久化操作；

4.3对外接口

无

4.4概要设计

4.4.1类图

类图见后面各章节中有详细描述。

5平台提供持久化基础服务

5.1需求定义

WebX2.0运行于OSGi和Spring-DM环境中，OSGi提供了良好的服务化软件模型，我们正是利用这一特点，以及Spring-DM的声明性服务编成特点。

5.1.1目标

通过将SessionFactory等对象实例服务化来为各个应用模块提供服务。这是技术型重用的具体实施之一。

5.1.2范围

本方案适用于一般的java应用或web项目。

5.1.3结构

    见下图

⏹图中的黑色箭头表示通过Package-Import和Package-Export形成（控制）的API（实例化和调用）关系，绝非服务的提供与消费关系。

⏹在WebX2框架中，应用模块之间将会存在大量的服务提供与消费关系。用绿色箭头表示

⏹框架本身向以用模块提供4个服务，分别是：

1)SessionFactory

2)TransactionManager1（用于Hibernate）

3)JdbcTemplate

4)TransactionManager2（用于JdbcTemplate）

5.1.4使用描述

Spring DM提供了声明式的服务引用，使用、开发者通过引用这些服务达到原来传统应用中的目的，但是在WebX2.0中，服务的重用依赖于模块的重用，通过将一些基础服务封装在某些模块中，达到了其整体的可重用价值。

5.2特征列表

1、    支持AOP事务处理

2、    支持JdbcTemplate

3、    支持Hibernate

4、    支持模块自管理的资源

5、    支持服务稳定性测试

5.3对外接口

见类图

5.4概要设计

5.4.1类图

图中所示的3个接口是服务框架为持久化提供的服务接口。考虑广大开发者的经验，我们延用了Spring提供的相应接口和hibernate提供的一个接口。

6单元测试模型

6.1需求定义

在OSGi环境下，开发一个继续支持简单的，脱离环境的单元测试方案。

6.1.1目标

6.1.2范围

本方案适用于web应用程序。

6.1.3结构

与Spring OSGi的行为相仿，WebX2.0单元测试模型通过提供替换的schema和handler对象来改变对相同的spring xml文件的不同的解析方法。也就是说：Spring OSGi core与WebX2.0 UnitTest不能同时存在。

6.1.4使用描述

6.2特征列表

1、支持单元测试

2、支持跨模块(bundle)的资源调用

3、支持动态资源加载

6.3对外接口

提供一个抽象类，没有接口。

6.4概要设计

以下为该模块的概要设计

6.4.1类图

单元测试（JUnit）基类

图中：我们提供了一个帮助开发者完成加载bundle内的hbm资源的基类。

扩展Spring 的namespace解析模型

图中：我们分别实现了两个DefinitionParser用于osgi:service和osgi:reference的解析，重载了的关键方法。以及一个NamespaceHandlerSupport用于加载这两个*Parser。

7服务质量测试模型

7.1.1目标

服务质量包括几乎所有非功能需求，在SOA方之下，将这些非功能需求列入QoS，即服务质量的范畴。

7.1.2范围

本方案适用于web应用程序。

7.1.3结构

图中：我们对Apache JMeter作了修改，使他可以运行于OSGi，这样，Jmeter就可以通过其

7.1.4使用描述

通过集成jmeter，提供在OSGi环境内测试服务的方法。

7.2特征列表

1、支持并发测试及统计界面

2、支持稳定性测试

3、支持容器内测试

7.3对外接口

7.4概要设计

7.4.1类图

测试方法：

图中：我们需要通过构造JavaSamplerClient的实现类，并在其规定的runTest方法里完成查找服务、调用服务的过程，并计算该过程的响应时间。

JMeter改造：

图中：通过一个BundleActivator来启动JMeter。这些是新增的类，其他新增的类还有：

org.apache.jmeter.save._SaveProp

org.apache.jmeter.util._UpdateProp

被修改的JMeter类：

org.apache.jmeter.JMeter

org.apache.jmeter.ProxyAuthenticator

org.apache.jmeter.gui.action.ActionRouter

org.apache.jmeter.gui.util.MeanFactory

org.apache.jmeter.protocol.java.gui.JavaConfigGui

org.apache.jmeter.save.SaveService

org.apache.jmeter.util.JMeterUtils

8开发环境易用性

8.1需求定义

WebX2.0应用的创建于一般java应用，不同，我们制定了一个基于eclipse plug-in项目创建模式的方法，开发者要延用这个方法，才能正确使用WebX2.0。

8.1.1目标

屏蔽OSGi bundle的复杂性，让开发者方便地创建应用模块。

8.1.2范围

本方案适用于一般的java应用或web项目。

8.1.3结构

    基于eclipse SWT开发的插件界面

8.1.4使用描述

一次性创建一个模块，支持两种类型：mvc模块和服务模块。

8.2特征列表

1．支持MVC模块

2．支持服务模块，这种类型模块主要用于CURD的持久化操作；

8.3对外接口

无

8.4概要设计

输出界面及工具设计，提交工具组开发。

8.4.1类图

无

9WebX安全

9.1需求说明

利用Acegi保护URL资源的安全并控制登录用户的访问权限

9.1.1目标

作为由多个模块（bundle）构成的web应用，新的安全系统必须能够满足简化的保证这些模块的安全性，在OSGi运行环境下，Acegi原有的设计模型不会受到破坏。

9.1.2范围

WebX用户、应用产品开发者

9.1.3结构

途中的应用指的是MVC模块，它们在安全问题上都要依赖Acegi模块提供的服务

9.2特征列表

1．Acegi资源的统一管理

2．FilterToBeanProxy服务化

3．多个MVC模块使用Acegi服务

4．在OSGi环境下实现URL保护

9.3对外接口

同WebX1.2

9.4概要设计

9.4.1类图

图中：原来的FilterToBeanProxy被重载，它原本通过唯一的一个WebApplicationContext确定Filter链条中其余的Bean，而新框架下，这些Bean由一个bundle负责管理，所以新的FilterToBeanProxy通过持有其BundleApplicationContext，完成定位这些Bean的过程。

10模块Web Context和Web资源加载

10.1需求说明

在OSGi运行环境下，创建适应标准HttpService支持的Web Context，该模式与标准的Web应用环境完全不同，我们主要通过自动生成代码来解决动态加载过程。

10.1.1目标

在OSGi环境和标准HttpService的基础上实现web资源的访问。

10.1.2范围

本方案适用于一个标准的web应用。

10.1.3结构

图示：每个MVC模块都要依赖标准的HttpService

10.1.4使用描述

使用者不必担心代码的复杂度增加，这些问题将由工具和向导完成。

10.2特征列表

1、每个模块自管理其Web资源

2、应用标准化，易于移植

10.3对外接口

同WebX 1

10.4概要设计

10.4.1类图

在这部分，我们将通过三个标准接口：

BundleContext

HttpContext

HttpService来完成Web Context的注册和Web资源的加载，此外，还有一个实现类，即：BundleEntryContext，该实现负责将基于bundle的资源路径映射到类似普通文件系统的访问模式。

11Jsp动态编译器的加载

11.1需求定义

OSGi在Web应用方面是一个非常简陋的环境，必须通过我们附加的代码才能完成对jsp的支持

11.1.1目标

在标准OSGi环境和HttpService模式下，支持jsp的编译和运行。

11.1.2范围

本方案适用于一般的java应用或web项目。

11.1.3结构

如图：每个包含Jsp资源的模块都必须依赖来自Jsp编译器模块的API

11.1.4使用描述

由工具或向导负责自动生成相关的代码，这些代码无须使用者再度调整。

11.2特征列表

动态编译Jsp，并且支持standard tag lib, jstl以及EL

11.3对外接口

无

11.4概要设计

11.4.1类图

图中：Apache提供了一个Jsp编译器，并且被封装为HttpServlet，而equinox提供了一个针对这个编译器的Wrapper，我们通过这个Wrapper来实现其加载。

12Struts 1资源加载

12.1需求定义

较之Struts 1在一个普通Web应用之下的加载过程，在OSGi环境下，则较为困难，必须有针对地设计开发适配系统来完成。

12.1.1目标

通过动态代码来加载Struts１的ActionServlet及其配置文件。这其中的复杂性要通过工具向导来掩饰。

12.1.2范围

本方案适用于一般的java应用或web项目。

12.1.3结构

如图：对于加载Struts1的问题，每个MVC模块将通过自动生成的代码段来完成。其中，每个MVC模块都有自己的struts配置。

12.1.4使用描述

这部分的代码由向导和工具自动生成，包括一些基本资源，使用者在后续的开发过程，如struts　action map的编写，需要手工完成。

12.2特征列表

3、支持多MVC模块

4、支持struts１缺省配置

5、提供工具向导，并一次完成

12.3对外接口

无

12.4概要设计

12.4.1类图

如图所示：新框架通过一个Servlet　Wrapper包裹ActionServlet，并加载它。

13Struts 1与Spring集成

13.1需求说明

在WebX　1里面，利用SSH框架将Struts 1对Action类的实例化过程，转交给Spring 来管理。新框架必须在OSGi环境下，完成这一过程。

13.1.1目标

在OSGi环境中，以及标准HttpService之上，完成SSH所实现的Spring管理的Struts1 Action对象，及其依赖关系。

13.1.2范围

适用于各种应用，开发者，WebX使用者。

13.1.3结构

如图所示：每个MVC模块自管理属于自己的（bundle内部）的Spring资源，而Struts1 Action对象就是由这些Spring管理的。

13.1.4使用描述

使用者只需了解原来的开发方法即可，新的代码由向导和工具一次性生成。

13.2特征列表

1、支持每个模块自管理struts资源

2、支持多模块的MVC结构

13.3对外接口

同WebX 1

13.4概要设计

13.4.1类图

图中：将对struts的RequestProcessor做重载，以改变其行为，原来的行为是通过唯一的一个WebApplicationContext来查找作为Action的Bean，新的行为必须针对每个模块保持自己的BundleApplicatoinContext，并且在仅属于自己的模块的范畴内访问Bean。

14集成测试

14.1需求定义

本阶段将对WebX2.0框架做一次比较全面的可靠性和性能方面的测试

14.1.1目标

针对Spring-DM的“服务代理”所引发的效率降低，重新作出评测。

14.1.2范围

本方案适用于web应用程序。

14.1.3使用描述

通过完成一个简单的应用，并通过Jmeter的HttpRequest实现效率评估。

14.2特征列表

4、MVC模块

5、Service接口

6、持久化层

14.3对外接口

无

15Acegi 1升级到2

15.1需求说明

WebX 1的安全模型采用了基于Acegi 1的架构，由于Acegi 2已经推出了较长一段时间，并且前一阶段的WebX1.5的demo开发中已经开始尝试Acegi 2，所以本阶段将在WebX2.0，即OSGi环境下，将前一阶段的Acegi 1升级至2。

15.1.1目标

适应Acegi的当前稳定版本。

15.1.2范围

适用于各种应用，开发者，WebX使用者。

15.1.3结构

同第二阶段；

15.1.4使用描述

使用者只需了解原来的开发方法即可，新的代码由向导和工具一次性生成。

15.2特征列表

简化的配置；

更好的兼容性；

15.3对外接口

同WebX 1

15.4概要设计

15.4.1类图

原来的（Acegi 1）的FilterToBeanProxy已经被新的springframework的DelegationFilterProxy替代。

16Demo开发

16.1需求说明

Demo是本阶段的工作重点，Demo的开发过程将进一步验证新框架的合理性和可靠性，在发布之前，尽量多地暴露问题。

16.1.1目标

将第二阶段的，基于WebX 1架构的demo资源，移植到WebX 2框架之上。

16.1.2范围

适用于各种应用，开发者，WebX使用者。

16.1.3结构

本阶段，将会在MVC层部署两个应用模块，同时在服务/持久化层开发部署两个模块，服务模块之间可能存在相互的服务依赖与消费关系。

16.1.4使用描述

这部分内容将被用于WebX用户（开发者）的入门参考。

16.2特征列表

模块化设计；

标准化（OSGi R4）兼容设计。

16.3对外接口

同WebX 1

16.4概要设计

16.4.1类图

请参考第二阶段的Demo设计文档，以及WebX2.0框架设计文档。

17服务端DWR开发

17.1需求说明

为了配合新的显示层开发模型，本阶段将开发服务端的DWR模型，通过该模型支持标准化的来自页面的json请求。

17.1.1目标

适应页面组件开发组推出的UI组件，及UI交互模型。

17.1.2范围

适用于各种应用，开发者，WebX使用者。

17.1.3结构

Web模块通过Http服务提供json服务；

持久化模块不能直接发布json服务，必须在提供了OSGi服务后，被Web模块引用后，间接发布。

WebX2.0借助了DWR的spring解决方案，直接将模块内的bean发布为json服务。

17.1.4使用描述

在Web模块中可以直接发布json服务；

服务层模块中的对象，必须经过Web模块的引用后，间接发布为json服务。

17.2特征列表

服务端标准兼容性；

Json标准兼容性。

17.3对外接口

同WebX 1

17.4概要设计

17.4.1类图

通过DWR提供的服务端spring解决方案，完成服务对象的json发布。

18负载均衡方案

18.1需求说明

通过Apache Http服务器提供的balance功能，为更广泛地部署WebX2.x提供技术保障。

18.1.1目标

为WebX能够适应更广泛的部署、支撑更加庞大的用户系统奠定基础。

18.1.2范围

适用于各种应用，开发者，WebX使用者。

18.1.3结构

18.1.4使用描述

负载平衡方案与应用系统无关，完全是发布期的任务。

18.2特征列表

无需复制session，与servlet容器无关。配置简单。

18.3对外接口

同WebX 1

18.4概要设计

19基于SSL的安全传输(Https)

19.1需求说明

保证WebX2.x可以提供安全传输通道。

19.1.1目标

19.1.2范围

适用于各种应用，开发者，WebX使用者。

19.1.3结构

Jetty本身包含了SSL组件。而WebX2的web应用模块并不与这些组件直接交户，而是通过OSGi的标准服务来完成。

19.1.4使用描述

利用jdk提供的keytool工具生成安全密钥对。

在OSGi运行是环境启动时提供必要的参数，即可通知jetty实现https通道。

19.2特征列表

https通道的设置与应用模块无关。

简单的密钥生成过程。

19.3对外接口

同WebX 1

19.4概要设计

19.4.1类图

20表现层缓存(content cache)

20.1需求说明

利用Apache Http服务器的content cache功能，进一步提高WebX2.x的响应效率。

20.1.1目标

静态资源的响应将由效率更高的缓存系统提供，同时，相同的url也会由缓存系统提供，从而大大提高系统的响应速度，降低应用服务器的压力和网络吞吐。

20.1.2范围

适用于各种应用，开发者，WebX使用者。

20.1.3结构

WebX2将利用Apache服务器提供的两个模块，其中mod_cache用于加速动态资源，而mod_file_cache用于缓存那些较少更新的静态资源。

20.1.4使用描述

本届属于发布期任务，与开发过程无关。

20.2特征列表

不干涉开发过程；

20.3对外接口

同WebX 1

20.4概要设计

20.4.1类图

21JMX服务器

21.1需求说明

利用Apache Felix提供的MOSGi服务器组件，为框架内运行的应用模块，提供JMX组件的注册服务。

21.1.1目标

为应用模块中需要管理和监控的对象和资源提供JMX编程环境。借助jakarta.apache.org/commons提供的Modeler实现一套Mbean的编写方法。

21.1.2范围

适用于各种应用，开发者，WebX使用者。

21.1.3结构

MOSGi在OSGi环境下实现了MbeanServer，我们可以利用这个实现，注册我们自己的Mbean。

21.1.4使用描述

WebX用户如果对管理对象感兴趣，可以根据我们提供的开发指南，编写管理内容。

21.2特征列表

标准化的管理接口；

声明式的Mbean创建方法；

21.3对外接口

21.4概要设计

22对传统war的支持

22.1需求说明

通过Spring DM 1.1对war的支持，为来自传统servlet容器系统的war包提供运行基础环境，使传统的web应用也可以运行于WebX2环境下。

22.1.1目标

使传统的war包，可以在WebX2环境下运行。

22.1.2范围

适用于各种应用，开发者，WebX使用者。

22.1.3结构

web extender将在OSGi启动时，扫描war文件，并试图发布它们，这些war必须是自管理的，也就是说，它们并不能与环境中的其它模块发生交互。

这里，jetty或tomcat比不需要加载HttpService。

22.1.4使用描述

只要对war增加META-INF/manifest.mf相应的描述，web extender便会试图使用一个ClassLoader加载这个war。其生命周期符合其它bundle的规则。

22.2特征列表

在WebX 2环境中兼容传统Web应用的发布和运行；为开发者提供的向前兼容的机会。

22.3对外接口

无