四川电信资源管理系统设计说明 (2).doc

1框架概述后台运行环境：Weblogic 10.0 +JDK1.5.x-weblogic 10.0支持EJB3，整个后台框架采用SLSB+Spring+Entity Bean架构，具体参照框架层次划分。1.1 系统的部署方式目前原型阶段选用的是本机无GIS数据缓冲方式。1.1.1 本机有GIS数据缓冲方式1.专用客户端本机选用一个桌面数据库用于缓冲N天以前的GIS数据，N天以后的数据是在客户端启动后，系统自动从本地网的空间数据库服务器上拖下来加载到客户端的缓冲库中。该同步方式完全依赖于GIS数据库中的时间戳，对于GIS数据的清除，本地网数据库中只作逻辑上的删除（即标识删除字段）。2.专用客户端的GIS直接从本地缓冲库中加载数据，因此，GIS数据更新后首先会更新到本地的缓冲库，然后，再更新到远程本地网的数据库中。这种方式下如何保证GIS数据对象的标识在本机和远程本地网一致是比较关键的。3.资源属性的更新统一请求J2EE后台，由后台完成资源属性数据的更新。 *本机缓冲库需考虑数据的安全性，与远程数据库的一致性问题。1.1.2 本机无GIS数据缓冲方式该种方式和原有的资源管理系统类似，原有资源管理系统的性能，可通过设计上的调整得到部分优化，另外，也可以依赖GeoMedia Pro 6.0本身的性能改善。但具体性能比原有的资源管理系统提升多少，还须进一步检验。 1.2 J2EE后台框架层次划分如上图所示，后台通过Session Bean提供统一的接口与前台进行交行交互，Session Bean接受的参数中包括请求的服务（SID）及相应的参数和上下文数据；Session Bean在接到请求之后，通过Spring配置文件中的配置，将相应的服务映射到实际业务服务Bean执行；业务服务Bean采用Command模式，每个业务实体完成与前台相一致的功能；采用EJB3将业务实体持久化到数据库中去。1.3 前台与J2EE后台交互序列图以查找一个实体对象为例，其它情况的交互过程类似。 1.Java GUI客户端通过RMI访问BizService的Remote接口(WEB客户端通过Controller调过BizService的Local接口），通过Request对象将请求传到后台。2.BizService首先验证请求是否合法（是否有正确的serviceName,是否有权限访问该服务,参数是否符合要求)3.通过Spring的上下文对象取得服务的实现(Command模式)4.调用Command的execute(Request req, Response res)执行业务过程。每个Command的内部实现流程为：验证/前置转换/执行/后置转换。5.封装响应对象，将执行结果返回调用端。1.4 J2EE后台框架实现主要类图1.4.1 .facade包1.4.2 .core包具体业务服务/较验器/转换器都直接从Base抽象类上进行实现。 1.4.3 .util包1.4.4 .BizException类2实现细节2.1 业务服务每一个业务服务Bean均要实现Icommand接口，并且采用单例模式。*注：如果希望通过装配方式实现数据较验/前置转换/执行/后置转换的话，可能会采用原型方式。此部分，有待于原型阶段完成后，根据原型中业务服务的实现情况来做决定。每一个业务服务Bean的execute依赖Request和Response两个参数，Request中存放请求的参数及上下文数据；Response将处理的结果返回给调用者。系统实现BaseCommand对象，该对象中按如下顺序执行：1. 校验：对提交的参数进行校验，校验在一般情况下（以后重用的可能性较大）由校验器进行校验，在该Bean外新建实现Ivalidator接口的对象进行实现。特殊情况时可以直接在本Bean中完成，但不提倡。2.前置转换器转换：前端提供的参数可能不符合后台业务处理对象的要求，需要进行转换，通过该步骤完成。在一般情况下（以后重用的可能性较大）也由转换器进行转换，在该Bean外新建实现Itransformer接口的对象进行实现。3.执行：执行业务逻辑。4. 后置转换器转换：执行后的结果与前台需要的结果形式不相符，在该步中进行转换，与前置转换器的处理原则类似。采用单例模式，在实现时不允许对象域变量声明，函数内声明变量是允许的。对于放入到Request和Response中的对象必须是持久化对象。2.2 Spring配置在本项目中运用Spring中的IOC部分，通过修改Spring的配置文件，装配业务服务，达到解耦的作用。由于项目业务的复杂性，Spring文件将按专业分为多个配置文件，以方便查询、管理。注意事项：1.业务服务的标识在运行期间，后台程序需要根据前端Request中的serviceName属性（服务ID）查找相应的具体的实现类。为避免业务服务多的情况下服务ID重复，另外，为方便业务服务使用者根据标识即能知道对应的任务，本项目在此统一规范服务标识的命名规则：统一采用业务服务接口的全路径名称（全部小写）来作为标识。具体使用示例如下：业务服务A有一个IA接口和实现类Spring的配置参考如下： .客户端可直接使用如下方式：Request request = new Request(session.getUserName(),IA.class.getName);2.服务器端查找业务服务：SpringContextUtils.getBean(serviceName);3.Spring配置文件的装载本项目最终的Spring的配置文件很大，并且Spring在装载期间，会将其中的涉及的类均装入内存，并且会创建实例，因此，Spring的装载时间很长。为避免运行期间进行装载，会实现一个weblogic的启动类在weblogic服务器启动完成前实现Spring配置文件的装载。此种方式不利于热部署。weblogic的启动类，是指实现了mons.T3StartupDef接口的类，具体请参见该接口的JavaDoc。2.3 事务管理整个系统的事务是通过CMP的BizService来实现的，支持分布式事务提交。统一由EJB容器进行管理，Session Bean一进入就开启事务，如果在处理的过程中出现错误，则回滚事务，否则提交事务。省集中的接口也可以通过该种方式来实现。每个具体业务服务不用再考虎事务问题，如果业务处理过程中出错或者不负合业务需要，可简直通过抛出BizException或response的returnCode标识为失败，由BizService的容器来管理事务的提交和回退。可大大简化业务服务Command类的实现难度。2.4 安全性整个项目采用JAAS进行安全认证管理。授权模型如下： 业务服务的访问权限控制，在原型阶段暂不涉及。在后期，如通过菜单能完全解决授权问题，则不再考虑逻辑层面的权限管理。2.5 异常处理系统中的所有异常需要进行编号处理，内部的异常均要抛出，以便于检测事务执行的正确性，从而回滚或提交。2.6 日志记录系统采用Log4j进行日志管理。1、 在每一个类声明一个静态日志对象。2、 对日志信息进行分级定义；3、 在每一个函数的头尾加Debug信息；4、 在捕获异常之后处加Error信息，并再次将异常抛出；5、 在过程实现的关键位置写Info日志信息。2.7 查询重用一个系统中对数据查询占的比重都比较大，为保证查询逻辑能最大程度地达到重用，准备采用以下两种方式：1、命名查询：在实体bean中加入NamedQuery(name = findSchoolByName, query = select o.id, , o.address from School o where =?1)。此种方式，需要将具有命名查询的实体类名写到persistence.xml的unit中。在要使用的地方写如下代码Query query = getEntityManager().createNamedQuery(findSchoolByName);query.setFirstResult(100);query.setParameter(1, name);2、EntityQueryManager类该类在.util包，主要职责是负责创建Query对象，在业务逻辑代码中直接取得该Query对象，然后设置好参数后直接执行就可以了。例：public class EntityQueryManager() ./*直接使用JP-QL方式*/public static Query getXXXQuery(EntityManager entityManager) return entityManager.createQuery(Select o from A o where =:name and o.xx = :xx);/*直接使用原生SQL方式*/public static Query getYYYQuery(EntityManager entityManager) return entityManager.createNativeQuery(Select A.a1 from A where =:name and o.xx = :xx); .3 开发说明3.1 项目整个原型阶段由以下Project组成,具体如下：项目名 项目内容 人员 bgrmdb 数据库模型 *方 bgrmds 客户端和后台的交互规范 *方 ngrmdm 领域实体项目。 利用JPA定义领域实体和关系数据库实体映射关系。 原讨论采用根据专业建project的方式，但考虑到领域中一些抽象的实体通用的实体没地方放，因此，采用只建一个project的方式 需单独打包导出一个普通的jar包提供给其它地方使用 *李军周小波 ngrmbm 业务逻辑项目。 包括后台框架和业务服务实现部分。 业务服务的分包方式见下面分包中的描述 *李军周小波 ngrmgui 资源管理GUI客户端项目 原计划分专业做插件方式，考虑到前期对Ecpise RCP不熟习，因此在此合并到一个项目中。视代码和技术情况决定是否通过重构方式 来实现分专业做插件。 *方/黄 ngrmweb 资源管理web项目 原型阶段暂不考虑 ngrmgeo GeoMedia pro MapView封装 *李梁/柳 *为小组长3.2 分包目前大体的包结构如下：一级 二级 三级 四级 五级 说明 ngrm 本项目的英文缩写 biz 后台业务层面（还有客户端实现层等，以示区分） facade 前端门面 util 工具包，系统中常用的功能 core 后台核心类，如业务框架的主要接口 专业1 每个专业的包，在该下需建一个该包的常量类 业务1 logic 某个业务逻辑处理包 业务1 validator 某个业务校验包 业务1 transformer 某个业务转换器包 业务1 domain 某个业务领域实体包 1.分包时要遵循包内高内聚，包外低耦合的原则进行组织。2.包名在命名时遵循如下命名要求，通常情况下包名使用小写字母。3.原则上不支持使用第五级的validator/transformer)，建议在Command内部实现doValidate/doTransform来替换。3.3 单元测试测试包括两块：一是在代码编写完之后的运行测试，由于EJB3的部署问题，可以通过模拟的方式进行测试，也可以在本机安装应用服务器的方式进行；二是单元测试，单元测试要求如下：1、 重心放在对业务功能的测试上；2、 对于抽象层次较高者可以不进行测试；3、 要仔细设计单元测试用例，在每个过程测试时要进行覆盖测试和边界测试。4、 单元测试采用Junit;3.4 代码组织对于简单的项目代码按如下层级结构进行组织：一级 二级 说明 main 主程序位置 java 源代码位置 resource 配置文件、资源文件位置 test 测试程序位置 java 源代码位置 resource 配置文件、资源文件位置 lib 库文件存放位置 *适用于测试和开发共用相同的第三方类库，即测试部分没有附加的类库要求。对于复杂的项目可以按如下层级结构进行组织：| 一级 | 二级 | 说明 |main 主程序位置 java Java源代码 resource 主程序的配置、资源信息 lib 主程序要求的第三方类库 test 测试程序位置 java test源代码 resource test需要的资源、配置信息 lib test要求的第三方类库 3.5 编码约定1.编码规范命名规范参考公司的Java编码规范和Java命名规范2.尽可能使用Apach开源的公有类，如commons中的lang、io包。3.在书写代码时，要根据JavaDoc要求进行注释书写，以便于生成JavaDoc，就可以形成一份详细设计文档。 。类的JavaDoc中需将该类的作用进行描述，可以根据需要写出该类的调用示例；对于每一个类方法要将该方法的作用进行描述，并对参数含义进行描述参考例子：/*公司版权声明*/ package xx.xx2import xx.xx1 /*类的用途简要说明*类的使用限制*sample code:*A a = .* autho