研发类课题管理系统RDPM架构设计说明书

研发类课题管理系统架构设计说明书文件版本：文件编号：发布日期：编 制：审 核： 批 准：国家开发银行版权所有内部资料 注意保密修订记录：版本号修订人修订日期修订描述目 录1 简介3 目的3 文档范围31.3 预期的读者和阅读建议3 参考文档3 包含文档3 相关文档3 缩略语和术语32 总体架构3 系统范围3 设计方法3 设计可选方案3 整体架构33 总体约束3 遵循标准3 文件约定3 目录约定3 对后续设计的约束3 其它34 系统逻辑结构3 总体结构3 子系统定义3 子系统一3 子系统二3 接口设计3 产品外部接口3 子系统间接口3 主要数据模型35 系统物理结构3 总体结构3 组件定义3 组件一3 组件接口设计3 组件与子系统对应关系36 系统部署3 网络结构图3 部署模式37 关键技术及公用机制3 关键技术设计3 公用机制说明38 系统重用设计3 以往设计的重用3 可重用性考虑39 系统功能实现310 开发平台与技术架构说明3 开发平台3 技术架构3 硬件设备说明3 软件说明311 系统非功能特性设计3 可扩展性3 可靠性3 性能3 可维护性3 平安3 审计3 容错性3 可移植性3 可部署性311.10 312 风险313 附录31 简介1.1 目的本设计文档的目的是根据?研发类课题管理系统用户需求规格说明书?对需求的描述，对研发类课题管理系统的业务实现进行了架构设计。本文档将指导后续的设计和开发工作，并对功能测试和性能测试工作起到辅助、参考作用。1.2 文档范围本文档主要描述研发类课题管理系统的架构设计，覆盖研发类课题管理系统的需求。研发类课题管理系统基于USE平台的UAAP框架进行构建，UAAP中已经实现的权限管理、菜单管理、人员及组织机构管理、统一授权接口等已经完成的功能不在本文档范围之内，以后系统实现的各种业务流程将会受到研发类课题管理系统设计的影响。本文档遵循自顶向下、逐层分解的原那么，对研发类课题管理系统进行架构设计：首先，根据对开行的系统范围的理解，提出总体设计方法，结合行内的平台及架构要求，给出了系统架构，从与外围系统关系、主要子系统、技术实现框架角度分别阐述研发类课题管理系统的构成。其次，在系统逻辑结构章节，结合以上各个角度的剖析，从平台实现、业务处理模式方面存在的差异，将研发类课题管理系统进行逻辑架构分解，划分为不同的子系统并分别阐述功能及设计思路。再次，在系统物理结构章节，对系统功能进行构件化的划分。此外，该文档对系统的部署、关键技术、系统重用设计、系统功能实现、开发平台与技术架构、系统非功能性设计及风险进行了说明。1.3 预期的读者和阅读建议本文档的读者必须对USE平台的体系结构或者设计方法有所了解本文档的阅读者为研发类课题管理系统开发过程的各角色：产品角色、系统分析架构角色、工程管理角色、代码角色、测试角色、文档角色，信息科技事务跟踪系统系统系统的部署角色、培训角色、维护角色；本文档组织方式：第一章 简介，描述文档的目的；第二章 描述总体设计思路，包括设计方法及备选设计方案和方案的选择；第三章 描述系统的逻辑结构。从最高层次上描述系统的逻辑组成；第四章 描述系统的物理结构。从最高层次上描述系统的物理组成；第五章 描述系统的部署情况；第六章 对系统架构中的关键技术及公用设计机制进行描述；第七章 如何重用以往设计产物及现有设计如何对将来重用产生影响进行描述；第八章 对系统中重要的用例或者有技术难度的局部进行功能实现的描述，以方便设计人员在进行设计、开发时进行参考；第九章 对系统依赖的第三方软硬件进行描述；第十章 对系统的非功能特性设计进行描述；产品经理应当关注该局部的描述是否与产品需求中产品的非功能性需求一致；开发人员应当在后续设计过程中对这局部设计进行关注，防止遗漏；测试人员应当根据这局部的描述制定测试案例，验证是否可以到达产品需求的要求。第十一章 描述架构设计中识别的风险，产品经理、设计人员、开发人员和测试人员 都应当随时关注这些风险，防止风险发生并及时采取躲避、减轻措施。第十二章 附录1.4 参考文档1.4.1 包含文档无1.4.2 相关文档作者文档名称文档版本出版日期出版单位或归属单位研发类课题管理系统工程组?研发类课题管理系统用户需求说明书?二一二年四月国家开发银行信息科技局1.5 缩略语和术语缩略语/术语全 称说 明CDB国家开发银行USE国家开发银行统一软件环境基于EOS Studio实现UAAPFRAMEUnified Authorization and Auth authentication Platform FrameUSE平台对统一授权平台框架BPM国家开发银行工作流平台基于FileNet Process EngineECM国家开发银行内容管理平台基于FileNet Content EngineEII国家开发银行信息交换平台ESB国家开发银行企业效劳总线基于TIBCO实现SOA面向效劳架构EP国家开发银行企业门户系统基于TAM实现RDPM国家开发银行研发类课题管理系统接口接口研发类课题管理系统对外系统的访问，统称接口效劳效劳研发类课题管理系统内部调用，统称效劳2 总体架构2.1 系统范围研发类课题管理系统面向全行研发类课题申报、管理和查看等部门，系统覆盖研发类课题管理全流程，包括：立项受理、付款受理、信息发布、成果共享等模块。研发类课题管理系统在开行2021版整体IT规划中，属于支持平台域，其所处的位置如下所示红色方框局部。主要用户包括：1研发类课题主管部门目前是国家开发银行研究院，作为研发类课题管理系统的管理归口部门，通过系统对全行研发类课题全流程电子化管理。2研发类课题主办部门总行各业务厅局均可申请课题，通过研发类课题管理系统进行课题申请、付款申请等操作。3普通员工全行所有员工，通过研发类课题管理系统查看权限内的共享课题成果。2.2 设计方案研发类课题管理系统的设计方法是在国家开发银行USE平台架构的根底上，采用符合SOA体系结构和对其进行SCA和SDO的落地标准进行设计。同时对系统内的公共功能进行参数化及灵活化的设计，来提高系统的重用性和扩展性。在业务方面，采用以课题从立项到成果发布的流程为主线，支持管理功能相对独立的设计方法，模块内部构件化和接口化来降低系统的耦合度，便于系统的实施及升级维护。1. 采用基于SOA体系结构设计方法采用基于SOA体系结构的“高内聚，低耦合的根本原那么。遵照国家开发银行USE平台架构系统将采用面向效劳的设计方法，把整个系统的不同功能单元称为效劳划分出来，通过这些效劳之间定义的接口和契约联系起来，接口是采用中立的方式进行定义的，它独立于实现效劳的硬件平台、操作系统和编程语言。这使得构建在各种系统中的效劳可以以一种统一和通用的方式进行交互。2. 采用SCA和SDO的落地标准进行设计SOA只是一种框架性的体系结构， 研发类课题管理系统采用USE平台进行建设，USE平台整合了SCA和SDO的标准和标准。SCA是SOA的落地架构框架标准，SDO是数据结构标准和数据存取原理标准。而这些标准，用现有的开发语言和技术框架都可以实现。效劳构件架构SCA的根本思想是将业务功能作为一系列效劳来提供，这些效劳组合到一起，以创立满足特定业务需要的解决方案。效劳数据对象SDO的设计是为了简化和统一应用程序处理数据的方式。利用SDO，应用程序编程人员可以一致地访问和操纵来自异构数据源的数据，包括关系数据库、XML数据源、Web效劳和其他信息系统。SCA和SDO获得更高的灵活性和更高的开发效率。可以在不改变应用程序情况下,使用不同的技术作为构件的实现,或者改变通信协议等，同时模块也可以容易的被重用和组装，易于修改和变更。3. 参数化和灵活性设计：考虑到国家开发银行研发类课题管理系统业务不断增长和变化带来的种种影响。基于用例的细粒度设计使得业务流程自身是可被组装的。流程可被拆分为多个单元。比方，针对不同的种类的课题在申报时需要提交的材料是不一样的，而且在最终评审和结题的流程中也是不一样的，同时不同种类的课题划分依据也会随着业务的变化而变化。这样在系统设计时就需要采用参数化的设计思想，定义和管理系统的参数及配置，调整参数以适应外部变化。 系统的具体设计如下：l 建立研发类课题业务办理的主体流程，建立以业务流程为主线的系统，表达信贷业务全生命周期的特点，即一条主线：课题立项备案、费用预算执行、合同签订支付、研发成果评审、研发成果发布。l 建立相对独立的业务支持管理功能，如：立项管理、合同管理、成果管理、机构管理、专家管理等。l 系统内部模块化、构件化的设计原那么，采用统一接口标准，降低各个功能单元之间的耦合度。2.3 整体架构方案，进行系统架构的设计，包括研发类课题管理系统与外围系统的关系，研发类课题管理系统主要功能模块和用户访问方式。研发类课题管理系统其与各其他系统关系描述如下：1. 通过企业信息交换平台EII平台获取全行用户、机构信息等根底数据。2. 通过统一授权系统拿到用户授权信息，与统一授权系统同步角色资源等授权信息。3. 与企业门户进行单点集成，用户可以通过直接访问和企业门户单点分别访问系统。4. 系统根据内部业务流程的需要，封装内部业务流程构件，使用BPM平台实现流程的调度、监控和管理。5. 通过与ECM集成对文档管理，进行文档的上传、下载、检索等功能。6. 通过AD进行用户登录认证管理。3 总体约束3.1 软硬件环境约束1、软件约束：l 本系统的开发基于国家开发银行USE开发平台；l 本系统的数据库基于Oracle 10g；2、平台约束：l 本系统工作流调度实现基于国家开发银行BPM平台；l 本系统授权实现基于国家开发银行UAAP系统；l 本系统内容存储实现基于国家开发银行ECM平台；l 本系统单点登录实现基于国家开发银行企业门户；l 本系统登录认证实现基于国家开发银行AD系统。3、环境约束：l 开发环境应用效劳器、数据库效劳器操作系统基于Windows Server 2021；l UAT测试环境应用效劳器、数据库效劳器操作系统基于Windows Server 2021；l 生产环境应用效劳器、数据库效劳器操作系统基于 Windows Server 2021；4、标准约束：l ?BPM平台业务系统集成命名标准?l ?USE平台-应用工程开发标准?l ?CDB-SOA_系统集成指导说明书?l ?BPM平台USE构件接口说明?l ?USE平台-软件开发编码标准?3.2 遵循标准l 本系统遵循JavaEE标准，主要包括：WebService、JMS、Servlet、JSP、JDBC、XML等。l 本系统遵循SOA架构下 SCA 1.0和SDO 2.1标准。l 本系统Java局部遵循面向对象设计并在设计中遵循UML工业标准。l 本系统遵循JavaSE 5.0 的技术标准及注解标准。l 本系统Java 依赖注入标准标准遵循JSR-330。.l 本系统遵循?ISMS-03-08-01-国家开发银行软件开发平安管理标准?3.3 文件和目录约定1、设计文档l 研发类课题管理系统数据库设计说明书2、开发文档：l USE开发平台下构件包配置信息采用properties、xml、eosinf、aegis 文件扩展名。l 日志文件为文本文件格式，文件命名：u 标准模块信息输出，系统名称_模块名称；u 标准模块错误信息输出，系统名称_模块名称_Error。3、目录约定u RDPM /src：源文件目录。u RDPM/conf：放置应用系统配置文件。u RDPM/build：放置编译代码。u RDPM/WEB：放置页面、样式、脚本。u RDPM/lib：放置所需第三方Jar包。3.4 对后续设计的约束国家开发银行研发类课题管理系统的后续建设及维护开发，应遵循本文档中列出的遵循标准、文件约定、目录约定中的要求。4 系统逻辑结构 根据系统功能实现的技术方式、数据处理模式及平台实现的异同，对研发类课题管理系统进行逻辑结构的分解。本系统由于功能模块关系较为紧密且系统业务逻辑相对简单清晰，因此不划分子系统，以下仅从总体结构进行阐述。4.1 总体结构结合对业务需求的理解和以业务流程为主线的根底上，对系统功能根据业务关联性进行划分，研发类课题管理系统的逻辑架构如以下图所示。研发类课题管理系统的逻辑架构设计，遵循系统内各个模块相对独立的松耦合原那么。根据系统内实现功能的主体对象及业务关联度，将系统划分为四大单元11个功能模块，分别是1、立项管理；2、合同管理；3、付款管理；4、成果管理；5、检索统计；6、业务参数管理；7、机构管理；8、专家管理；9、信息发布；10、系统管理；11、系统维护。4.2 功能模块定义4.2.1 功能模块概述模块名称主要功能立项管理完成课题立项、课题备案相关业务流程的发起、流转。合同管理完成合同备案业务流程的发起、流转。付款管理完成付款申请业务流程的发起、流转。成果管理完成成果发布业务流程的发起、流转；实现研究成果根据查看范围展示。检索统计根据用户需要对系统中数据进行分类汇总，并打印输出报表。业务参数管理将业务参数及业务规那么作为系统参数进行管理，以使系统灵活响应业务规那么调整。合作机构注册完成合作机构注册业务流程的发起、流转。专家管理完成专家注册业务流程的发起、流转。信息发布完成信息发布业务流程的发起、流转。系统管理完成用户相关的权限、所属机构管理，菜单项管理，角色管理等功能。系统维护通过系统界面完成系统相关维护功能，目前主要是数据库导入、导出。4.2.2 设计思路根据用户需求进行分析，并进行功能点的适当归纳总结后，可对系统功能进行以下分解设计：a、 业务流程功能单元包含立项管理、合同管理、付款管理3个逻辑功能模块，此功能组涵盖了课题从立项、商务直至验收后付款的主要业务环节，是课题管理的主要业务功能。b、 业务管理功能单元包含成果管理、检索统计、信息发布3个逻辑功能模块，主要是课题主管部门对课题管理业务过程进行归纳总结，并发布各项管理信息。c、 业务支持功能单元包含业务参数管理、机构管理、专家管理3个逻辑功能模块，此功能组为完成课题管理主要业务功能运行的根底。d、 系统管理功能单元由于机构管理、权限管理、用户管理、菜单管理、角色管理等功能从定位上具有同一性，因此考虑在此功能组内使用一个系统管理模块统一完成以上功能。此外，根据非功能需求，需要通过系统界面实现系统主要维护功能，因此在此功能单元内使用系统维护模块完成系统维护功能。4.3 接口设计 系统仅有外部接口。外部接口遵循开行各平台、系统接口标准。4.3.1 产品外部接口外部接口主要包括：EII、统一授权、AD、BPM、ECM接口。具体接口说明和交互方式如下：序号外围系统说明接口交互方式1业务流程管理(BPM)平台实现流程设计、步骤定义、节点设定并提供接口支持实时2企业内容管理ECM平台统一存储系统需管理的附件文档，并通过接口进行文档的上传、下载和查询。实时3企业信息交换EII平台在用户、机构信息发生变化时，EII将变化信息主动实时推送至本系统。实时4统一用户认证系统AD对用户进行身份认证检查实时5统一授权管理系统UAAP本系统与UAAP间双向同步用户、角色、权限的对应关系。实时6企业门户EP通过EP实现单点登录实时5 系统物理结构5.1 总体结构本系统物理架构设计采用纵向分层、层内模块之间松耦合的原那么，保证各组件的物理独立性，增强系统可扩展性，有利于系统分模块开发部署。研发类课题管理系统自身的物理组件主要分为五类：1、业务流程类；2、业务支持类；3、业务管理类；4、根底支持类；5、UAAPFRAME类。共10个组件包。1、 业务流程类组件是课题管理业务的主线，完成从课题立项、合同备案到付款申请的课题管理主体业务流程；包括课题过程管理组件包。2、 业务支持类组件对业务流程类构件提供业务的支持，保证业务的顺利开展；包括业务支持组件包、合作资源组件包。3、 业务管理类组件实现对业务的管理统计，包括对成果的发布和查询统计；包括业务管理组件包。4、 根底支撑类组件是业务实现的根基，在此根底上对业务流程类、业务支持类和业务管理类构件提供技术的支撑；包括通用工具组件包和流程管理组件包。5、 UAAPFRAME类组件提供了通用的和统一授权平台和企业门户集成，以及角色权限管理的功能；包括认证管理组件包，机构管理组件包，权限管理组件包及集成管理组件包。系统纵向分为四层，分别是展现层、业务逻辑处理层、数据持久层以及数据存储层。展现层主要负责向用户展示系统界面，响应用户在界面上的操作，并转化为系统请求传输至业务逻辑处理层调用对应的业务功能组件。业务逻辑处理层在实现业务功能时使用数据持久层中的持久化数据对象，由数据持久层将对持久化数据对象转化为对数据存储层物理数据实体的访问。5.2 组件定义5.2.1 课题管理课题管理组件包内部的4个组件属于业务功能组件，实现与课题申报、备案以及付款这一生命周期的业务流程相关的功能。这些业务功能属于业务需求方最关心的主体业务功能，是本系统的核心功能组件。课题管理组件包从展现层接收用户请求，经过处理后调用根底支持类组件，完成业务流程流转及流程附件管理；调用数据映射组件完成流程及业务实体数据增删改查；调用UAAPFRAME组件获取操作用户的所属机构、角色及权限。5.2.2 业务管理业务管理组件包内部的3个组件属于业务功能组件，实现主管部门对课题管理业务进行高阶管理统计分析的业务功能。这些业务功能能够帮助主管部门更好地对课题管理业务进行总结、分析，属于本系统的额外增值功能，并不影响主体业务功能。业务管理组件包从展现层接收用户请求，经过处理后调用根底支持类组件，完成业务流程流转及流程附件管理；调用数据映射组件完成流程及业务实体数据增删改查；调用UAAPFRAME组件获取操作用户的所属机构、角色及权限。5.2.3 业务支持业务支持组件包内部的1个组件属于业务功能组件，是课题管理类组件正常运行的前提，为课题管理类组件运行提供前置条件。主要实现业务参数配置。业务支持组件包从展现层接收用户请求，调用数据映射组件完成系统业务参数增删改查；调用UAAPFRAME组件获取操作用户的所属机构、角色及权限。5.2.4 合作资源合作资源组件包内部的2个组件属于业务功能组件，是课题管理类组件正常运行的前提，为课题管理类组件运行提供前置条件。主要实现课题管理组件包中课题相关的合作机构、专家资源的管理。合作资源组件包从展现层接收用户请求，经过处理后调用根底支持类组件，完成业务流程流转及流程附件管理；调用数据映射组件完成流程及业务实体数据增删改查；调用UAAPFRAME组件获取操作用户的所属机构、角色及权限。5.2.5 通用工具通用工具组件包内部的2个组件属于系统管理组件，是确保系统正常平稳运行的工具组件。系统各业务功能组件均需调用通用工具组件包的组件实现日志记录查询分析、异常捕获及处理。5.2.6 集成平台调用集成平台调用组件包内部的2个组件属于接口类组件，调用应用集成平台业务流程管理平台BPM、内容管理平台ECM提供的流程管理、文件管理效劳。系统各业务功能组件均需调用集成平台调用组件包的组件实现业务流程发起、流转及终止，文件上传下载删除等功能。5.2.7 UAAPFRAMEUAAPFRAME组件包内部的4个组件属于系统管理组件及接口组件，实现系统登录认证、用户管理、组织机构管理、权限管理、业务数据字典项管理、集成管理等功能。UAAPFRAME组件从EII接收用户机构同步信息，与统一授权系统双向同步用户角色权限信息，与AD集成进行用户登录认证。5.2.8 系统维护组件包系统维护组件包内部的数据库维护组件属于系统管理组件，实现数据库备份、恢复功能。数据库维护组件主要调用数据库备份、恢复的。5.3 组件接口设计设计编号接口名称接口描述接口提供组件目标组件接口调用方式1文件管理接口文件上传、下载、查询文档管理组件课题过程管理组件包、业务管理组件包、合作资源组件包方法调用2、流程管理接口流程创立、流转、终止、查询流程、查询工作项等工作流组件课题过程管理组件包、成果管理、信息发布组件方法调用3异常处理接口捕获程序运行过程中出现的系统异常、业务异常，并记录系统异常时间、描述、所属模块、线程等信息。对于业务异常那么统一处理用户反应页面。异常处理组件所有组件方法调用4日志管理接口将程序运行过程中的信息按照DEBUG, INFO, WARN, ERROR, FATAL五个级别记录到日志文件中日志管理组件所有组件方法调用5合作机构查询接口使用统一的方法对合作机构数据实体进行查询，并返回查询结果。机构组件课题过程管理组件包方法调用6专家查询接口使用统一的方法对合作专家数据实体进行查询，并返回查询结果。专家组件立项课题组件、备案课题组件。方法调用6 系统部署6.1 网络结构图研发类课题管理系统部署于开发银行内部生产网段，与外联网之间使用防火墙逻辑隔离，内外网之间没有数据访问需求。系统用户包括总分行用户均需要使用内网终端访问本系统。与研发类课题管理系统需要进行集成的外部系统，如BPM、ECM、ESB、AD系统也均部署于开发银行内部生产网段，从网络策略上确保可以互相访问。6.2 部署模式依据现有效劳器资源，设计了2套部署模式，其中模式一为单机运行，只使用1个效劳器分区，部署数据库效劳器、web应用效劳器WAS、USE运行环境以及研发类课题管理系统应用软件包；模式二为双机运行，设计思路为效劳器1和效劳器2互备运行，2台效劳器均部署数据库效劳器、web应用效劳器WAS、USE运行环境以及研发类课题管理系统应用软件包，其中效劳器1上的web应用效劳器WAS、USE运行环境以及研发类课题管理系统应用软件包为运行状态，数据库效劳器为待机状态，效劳器2上的web应用效劳器WAS、USE运行环境以及研发类课题管理系统应用软件包为待机状态，数据库效劳器为运行状态。具体如以下图所示。模式一的优点为节省效劳器资源，缺点为系统可用性较低，一旦发生效劳器故障，系统将无法对外提供效劳。模式二的优点为系统可用性较高，一旦发生效劳器故障，可利用事先准备的脚本，快速完成效劳器切换，确保系统效劳正常。考虑到本系统应用场景、重要性以及效劳器资源情况，目前采用模式一进行部署。在效劳器资源能够满足的情况下，优先考虑采用方案2进行部署。7 关键技术及公用机制7.1 关键技术设计7.1.1 SCA效劳面向效劳架构SOA要求我们将业务需求分解为假设干个功能相对独立、可被复用的效劳单元，通过效劳之间的相互调用完成一定的业务功能。这种架构有利于业务重组，它通过效劳的复用加速企业的信息系统开发，到达快速响应企业业务变化的要求。OASIS组织发布的效劳组件架构SCA是一组SOA编程模型标准，它描述了利用面向效劳架构SOA来构建应用程序和系统的模型；SCA装配模型定义了构成一个SCA系统的各种构件和他们之间的关系，包括：组合构件Composite、构件Component、效劳Service、引用Reference、实现Implementation等。系统构件装配是SCA装配模型的实现。通过可视化的方式定义组合构件Composite中的构件Component组成，定义构件中包含的效劳Service、引用Reference，构件引用所指向的构件效劳等。以下图是构件装配的概念结构图，从图中可以看出，一个构件由效劳Service、引用Reference、实现Implementation和属性Property四局部组成。一个构件可以有一个或多个效劳、引用和属性，但只能有一个实现。效劳和引用的接口Interface描述了其操作的范围；通过效劳绑定Service Binding来对外暴露效劳的访问；通过引用绑定Reference Binding来消费效劳。组合构件Composite作为构件的容器对构件进行包装和组织，并作为可发布的单元进行部署。图7.1 SCA效劳构件装配图对上图术语的详细解释如下表所示：术语 解释 效劳Service Service是一系列业务功能的集合，将某一个业务功能通过效劳的方式暴露出来，供外部应用访问。效劳可以用多种形式的访问协议进行访问，比方Web Service，JMS，Stateless SessionBean等。 引用Reference 构件的功能由其它构件的效劳提供，在构件环境中通过引用来进行指定。在运行时，根据配置找到引用对应的效劳，并注入到构件实现当中，类似依赖注入。 属性Property 对构件实现的字段设置默认值，在构件环境运行时，会把值注入到相应的字段中。 接口Interface 接口定义了效劳对外提供的功能范围，描述了效劳所包含的操作以及操作的参数。USE中支持两种接口的描述形式：Java Interfaces和WSDL PortType。 绑定Binding 绑定定义了效劳的生产和消费的方式，以及访问效劳所采用的协议。绑定可以分为效劳绑定和引用绑定。效劳绑定，描述了客户端可以使用什么样的机制来调用效劳。引用绑定描述了采用什么机制来调用外部的效劳。 实现Implementation 构件的实现是构件效劳功能的具体实现，SCA标准支持各种各样的构件实现方式，如：Java实现，C#实现，Python实现等等。USE目前只支持Java实现，以及USE特有的逻辑构件实现。 构件Component 对外提供效劳功能的单元，定义了构件的实现方式，以及构件提供了哪些效劳，引用和属性。 组合构件Composite 由一组具有业务上相互联系的构件组成，本身也可以定义对外的效劳和引用，其实质是一种更大粒度的构件。 装配Assembly 将一组具有业务上相互联系的构件组织到一个组合构件Composite中，在这个组合构件中定义构件的效劳，引用关系，构件的实现等，这个过程称为装配。 构件包Contribution 在USE中构件包Contribution作为一个部署单元，在其中包含了构件，构件实现以及一些额外需要的资源，比方：页面流、逻辑流、运算逻辑、数据集、jsp文件等。 提升Promote 组合构件中可以把构件中的效劳通过promote的方式对效劳进行重新包装，添加外部用户的访问方式。同时组合构件引用是对一个或多个构件的一个或多个引用的提升，所有的构件引用共享相同的配置。 连线wire 定义源构件引用连接到目标构件的效劳上，给引用进行赋值。7.1.2 构件装配以下图是构件装配的概念图：图7.2 SCA效劳构件装配概念图由上图可知： 一个组合构件可以包含多个构件。 每个构件可以定义多个效劳和引用；效劳和引用通过接口描述来描述其业务功能。USE中包含了两种类型的接口描述：Java接口和WSDL PortType。 可以为每个构件指定至多一个构件实现。 构件实现是构件效劳功能的具体实现。 可以为一个构件定义多个构件属性。 可以为效劳和引用定义一个或多个绑定信息。 效劳和引用的默认绑定是SCA绑定。 7.1.3 SDO数据对象Service Data Object，效劳数据对象。为效劳和应用提供一个简单统一的数据模型。USE支持SDO2.0标准，在数据传输过程缺省的对象类型是SDO对象。SDO对象可以根据实际的数据源决定它的实际表现，在使用过程中可以不必考虑其后端的实际数据类型和构建方法。7.2 公用机制说明7.2.1 USE平台应用技术架构模型的三个维度软件技术架构用来处理软件高层次结构的设计和实施。它以精心选择的形式将假设干结构元素进行装配，从而满足系统主要功能需求，并满足其他非功能性需求，如可靠性、可伸缩性、可移植性和可用性。我们用多个视图或视角组成的模型来描述它，该模型包括以下视角：l 逻辑结构视图逻辑结构主要支持功能性需求，即在为用户提供功能方面系统所应该提供的能力。一般基于流程的方式进行系统功能的分解，将系统分解为一系列的关键抽象，这些抽象大多数来自于面向功能的问题域，可以划分为业务流程问题域、业务问题域、技术问题域，采用组件的方式表现为业务流程、领域框架、应用根底框架、技术组件。l 技术实现视图技术实现视图从具体实现技术视角描述了系统的分层结构，每层均具有良好定义的职责，某层子系统依赖同一层或低一层的子系统，从而最大程度地减少了具有复杂模块依赖关系，得到层次式的简单策略，提高系统的稳定度，减少开发量。基于USE平台的JavaEE系统的技术分层结构自底向上包括资源层、逻辑层、效劳层、流程层和协同层。l 非功能需求视图非功能需求包括系统的平安性、可管理性、可靠性、可用性和扩展性，定义了系统如何满足功能需求之外的其他隐式需求。这些需求可以通过一个监控管理框架来提供，该框架包含系统共性能监控、应用与平台配置、管理仪表盘、效劳水平与质量、仿真与虚拟化等。图 71 USE平台的应用技术架构模型在面向效劳的体系架构中，针对上述的架构模型，规划了支撑上述3个视角的技术框架和标准：l 组件模型系统的逻辑结构由一系列组件组成，每个组件分别负责一组功能，提供本地调用接口、对外效劳、用户操作界面等。?组件标准?定义了组件自身的特性，设计系统逻辑结构的过程，实际上就是将系统拆分为组件的过程系统分解过程参看?USE平台工程实施方法论?。在一个基于组件的应用系统中，组件包是可部署的单元，因此系统的物理结构是以组件包为根本单位的。l 基于组件的技术架构基于组件包的技术架构是针对JavaEE系统技术分层结构的具体规划，系统将根据业务和技术的需要分解为多个组件包，在组件包内根据逻辑功能特性划分为协同层、流程层、效劳层、逻辑层和资源层。在实现组件包的过程中，允许对上述层次进行裁减，例如很多组件包就只有效劳层和逻辑层代码即可。l 管理监控架构为了满足对应用系统的非功能性需求，在JavaEE应用系统中需要一个面向管理监控的框架，这个框架采用微内核结合扩展点的架构模式，能够灵活的扩展管理监控内容，以便于非功能需求的实现与具体业务的实现相别离。7.2.2 USE ServerUSE ServerUSE运行环境是支撑SOA应用和效劳的运行环境，USE Server 由SCAService Component Architecture容器、构件运行环境、页面流引擎、逻辑流引擎、系统效劳、根底效劳等核心模块组成。USE Server是一个面向SOA的根底设施，实现了SOA的核心编程模型SCA 1.0、SDO 2.1的标准标准。根据USE平台的建设目标，USE Server保障了SOA应用或效劳稳定、平安、可靠、高效、可扩展地运行。USE Server运行在标准的J2EE应用效劳器之上，支持主流的应用效劳器如：WebSphere、WebLogic、JBoss、Tomcat等和主流的数据库Oracle、DB2、MS SQL Server、Informix、Sybase等。7.2.3 USE数据处理USE采用的编程模型是：流程+数据+人机交互。其中流程包括：页面流和逻辑流；数据包括持久化实体和非持久化实体，并采用SDO标准来描述这些数据的格式；人机交互采用富客户端控件来实现。以下内容阐述在USE的技术架构下，数据是如何存储，如何被获取以及如何在流程和客户端之间传递。7.2.3.1 数据上下文USE中所有的数据都是通过数据上下文来存储的。数据上下文是一个有固定分区的数据容器，它采用统一的Xpath语法对对象树进行取值和设值操作。在使用数据上下文时，只需要使用Xpath定位数据即可，不需要知道内部的具体数据类型。数据上下文分为多种数据区，其中包括请求上下文数据区、会话上下文数据区、页面流上下文数据区、逻辑流上下文数据区、MUO上下文数据区、流程上下文数据区。如以下图所示。图7.3 USE数据上下文每一种数据区的生命周期是不同的，由USE Server统一管理。详细描述参下表所示。数据区名称使用模块描述请求上下文页面流请求上下文数据区中放置的是一个完整的Http Request/Response过程中页面流产生的数据。当一个页面流实例接受到一个HTTP请求后，引擎创立一个请求上下文数据区，当引擎响应这个HTTP Request后，引擎销毁这个请求上下文数据区。页面流上下文页面流上下文数据区和一个页面流实例的生命周期是一致的。会话上下文会话上下文的生命周期与HTTP Session的生命周期是一致的，会话上下文数据区的数据来自与HTTP Session中的数据。逻辑流上下文逻辑流逻辑流上下文数据区的生命周期与逻辑流的生命周期是一致的。当一个逻辑流实例结束时，引擎会销毁这个逻辑流对应的逻辑流上下文数据区。MUO上下文MUO上下文是受管用户对象上下文，是为了在逻辑流、运算逻辑中防止用户随意使用Http会话中的数据，而构造的一个受管数据上下文区。用户需要在USE Governor中配置MUO中需要存放的数据对象，这些对象才能在逻辑流和运算逻辑中使用。7.2.3.2 数据流转过程图7.4 USE数据流转过程例如如上图所示，USE的核心数据流程是：1. 客户端浏览器发起HTTP请求，通过Key/Value对的形式将数据传输到效劳器端；2. 页面流引擎接到HTTP请求后将Key/Value对象转换为SDO对象，传递给页面流实例；3. 页面流调用逻辑流时，将SDO对象传递给逻辑流引擎；4. 逻辑流引擎又会将SDO对象传递给逻辑流实例；5. 逻辑流调用运算构件时，传入SDO对象。运算构件访问数据效劳完成业务操作后产生SDO类型的返回结果；6. 逻辑流引擎将返回结果传递给页面流引擎；7. 页面流引擎又将返回结果转发给JSP页面；8. JSP页面响应这个HTTP请求，返回到客户端浏览器，显示返回结果。完成一次数据流转。USE数据传输过程，缺省的对象类型是SDO对象，但是用户也可以采用自定义类型，比方POJO、W3C DOM等等。7.2.3.3 数据处理过程在介绍了数据上下文的分类和数据流转的原理后，再分析一下页面流、逻辑流各自的数据处理过程。1. 页面流数据处理页面流使用到的数据上下文分为三个数据区，包括会话上下文数据区，请求上下文数据区，页面流上下文数据区。如以下图所示。图7.5 页面流数据处理示意图(1) 会话上下文数据区会话上下文数据区存储的数据是当前用户所在的HTTP会话数据的一个映射。开发页面流的时候可以使用s:XPATH_EXPRESSION来访问会话数据区中的数据，访问会话数据区中表达式的前缀为s:。(2) 请求上下文数据区请求上下文数据区中放置的是一个完整的Http Request/Response过程中产生的数据，当USE的页面引擎接受到一个HTTP Request的请求后，它会将这个请求的Key/Value参数按照规那么，转换成一个或者多个Java对象放入到请求上下文数据区中；也可以使用复制图元访问或创立请求上下文数据区中的数据；调用业务逻辑或者效劳的返回值也可以设置到请求上下文的数据区中。访问请求上下文数据区中的数据可以采用r:XPATH_EXPRESSION或者不带前缀，直接使用XPATH_EXPRESSION访问请求上下文数据区中的数据。(3) 页面流上下文数据区页面流上下文数据区存储的是在页面流里定义的变量或者对象，访问页面流上下文的表达式为f:XPATH_EXPRESSION。页面流上下文数据区的数据生命周期相当于页面流流程级别的变量，在一个页面流实例中的不同的页面，业务逻辑，赋值操作都可以使用页面流上下文中的数据。2. 逻辑流数据处理逻辑流使用到的数据上下文为两个数据区，包括MUO上下文数据区和逻辑流上下文数据区。(1) MUO上下文数据区MUO上下文数据区中存放的是受管用户数据对象，访问的方式采用m:XPATH_EXPRESSION样式的表达式来访问和更新数据。在逻辑流中涉及用户数据HttpSession传递的过程时，因只允许对用户的局部数据有存取权限，这时就需要根据session中的局部数据构造一个受控的用户数据对象，用户只能对该受管用户数据对象做操作。(2) 逻辑流上下文数据区逻辑流上下文数据区和页面流的请求上下文数据区比拟类似，如果把一个逻辑流比作是一个Java方法，那么逻辑流上下文数据区中的数据包含的是这个Java方法传入的参数，以及这个方法中定义的成员变量。访问逻辑流请求上下文的数据直接采用XPATH_EXPRESSION访问，不需要加任何前缀。7.2.4 事务控制中小系统使用USE平台提供的事务控制机制，在逻辑构件对应的逻辑流作为事务控制的边界。设计中事务控制的边界限制在逻辑流内部，即不存在跨多个逻辑流的事物控制。如果初始设计时存在事物边界跨越多个逻辑流的情况，那么多个逻辑流需要合并成单个逻辑流。7.2.5 操作日志USE平台下对日志的逻辑划分为三类：效劳器日志、应用日志和构件包日志。其中应用日志供开发人员定位调试系统使用，包含跟踪日志、引擎日志和系统日志，通过平台提供的USE Governor配置实现；构件包日志记录用户登录和访问系统功能模块的业务日志，由系统开发人员根据用户需求实现具体功能。“操作日志是用户使用中小系统过程中，对各构件包级功能操作的记录。中小系统可以通过操作日志模块对用户登录和功能操作记录进行展现。系统提供统一的操作日志记录方法，SCMSLogUtil类统一处理日志信息。在各个功能模块中，只需要将用户的操作信息放入HttpServletRequest中即可。8 系统重用设计8.1 以往设计的重用8.1.1 架构重用基于行内多年基于SOA的架构设计、软件应用资产的积累以及USE开发环境的使用，研发类课题管理系统的物理架构分层设计可参考使用USE开发的其他系统采用成熟的四层架构。8.1.2 应用重用 研发类课题管理系统可使用BPM平台运行业务流程实例，使用ECM平台管理文件存储，使用统一授权系统进行用户角色权限管理。而无需在系统内部实现对应的流程引擎、文件管理引擎以及用户角色权限管理模块。8.1.3 组件重用用户机构权限管理组件可复用USE提供的UAAPFRAME；流程管理组件、文件管理组件可服用USE提供的BPM集成构件、ECM集成构件。简单便捷地实现与周边系统的集成接口，有效降低开发工作量。8.2 可重用性考虑本系统考虑实现较为通用的日志管理组件、异常处理组件，定义通用的组件接口，屏蔽系统差异性。以便在后续其他系统的开发设计过程中实现重用。9 开发平台与技术架构说明9.1 开发环境9.1.1 硬件设备说明开发环境部署8C32G效劳器1台，作为数据库效劳器与应用效劳器。效劳器部署于开行测试网段。物理位置*核建 99E 4892/88524TC 06PDR50/06PDT38主机SN号：06PDR52型 号：IBM BladeCenter HX5操作系统 Windows Server 2021 R2 64位中文版硬件资源配置划分(PCServer)配置4颗8核Intel Xeon E7 4820 8核心 2.0GHz,18MB L3缓存处理器内存：32GB磁盘：300GBRAID方式：5分类及命名*类 别：测试主机名：bejrdpm文件系统规划C:100G虚拟磁盘：默认网络配置需求*IP：Mask：Gateway：信息点位置：开发终端使用个人工作用电脑。9.1.2 软件说明软件版本描述IBM WEBSphere Application Server.0.41IBM应用效劳器Oracle.5数据库USE效劳器环境编译号1227USE应用运行支撑环境USE开发环境Buildid:N202109281702_1227USE应用开发支撑环境9.2 测试环境本系统测试环境与开发环境使用一套软硬件环境。9.3 生产环境待定10 系统非功能特性设计易用性用户登录系统后的首页需调用工作流组件，显示待办事项、在办事项。可维护性系统通过USE Governor监控当前在线用户的用户ID、用户名称以及用户IP地址。系统需在系统的业务配置组件中实现业务参数的修改，而不是通过数据库方式修改。平安性系统界面上的用户输入数据必须经过二级校验，通过页面文件实现页面级校验，通过应用组件实现后台校验，以确保用户输入的完整性、平安性。系统普通用户以及管理员的关键操作必须通过日志处理组件详细记录操作用户、操作内容、操作时间、日志级别等关键信息，以及系统功能质量需求中对于日志的其他记录需求。以满足审计需要。扩展性系统物理组件设计时遵循组件效劳化原那么、功能别离原那么、组件单向调用原那么，尽量降低组件之间的耦合性，组件之间采用明确定义、相对固定的功能调用接口，确保系统需要增加或改变原有功能时，能够在尽量少影响原有功能的前提下，完成系统变更及扩展。10.6高可用性系统设计了采用双机热互备的部署模式，如果硬件效劳器满足需求，可实现应用效劳器、数据库效劳器在2台物理效劳器之间灵活切换，以提高系统可用性，降低效劳器软硬件环境故障对于系统对外提供效劳的影响。10.7性能1. 系统采用的use运行平台支持应用效劳器集群的方式，以提升系统的并发处理能力。2. 对于大数据量的数据库表，可以采用分区表的方式来存储数据。3. 通过数据库连接池技术，提升数据库访问效率。4. 提供缓存控制将相对固定的数据缓存到内存中，从而节约了直接数据库访问所造成的硬盘速度瓶颈。11 风险暂无12 附录定义需要列在架构设计文档中的附加性信息等。