JRES基础业务平台-应用组模块化方案.docx

应用工程模块化方案  目录 TOC \o "1-3" \h \z \u 1. 说明 3 1.1. 背景 3 1.1.1. 应用组工程发展现状 3 1.1.2. 应用组工程存在问题 3 1.1.3. 解决方案 4 1.2. 本文说明 4 2. 模块结构性分析 5 2.1. WEB服务器部分： 6 2.2. 应用服务器部分： 6 2.3. 分层模块设计 6 3. 模块功能性拆分 7 3.1. 基础业务框架 8 3.2. 工作流平台 8 4. 工程模块明细 8 4.1. 第三方适配模块 8 4.2. 数据库持久层适配模块 10 4.3. 流程引擎适配模块 11 4.4. 流程引擎扩展实现模块 11 4.5. 业务层公共模块 12 4.6. WEB层公共模块 13 4.7. WEB层控制逻辑模块 14 4.8. 远程接口模块 15 4.9. 业务实现模块 56 4.10. 页面资源模块 58 5. 约束规范 60 5.1. API接口声明约束 60 5.2. 模块配置约束 60 5.3. 模块依赖约束 60 5.4. 发布项约束 60  说明 背景 应用组工程发展现状 目前JRES平台应用组涉及的工程包含基础业务框架和工作流平台两大部分。这两部分工程介于技术平台与业务应用之间，它们需要担当部分支持二次开发的框架、平台功能的实现（如请求会话的管理、应用扩展点的设置、工作流引擎的实现等），同时在特定业务领域又需要担当部分应用功能的实现(如用户权限管理、系统元数据维护、工作流流程设计、工作流管理监控等)。 应用组具备上述需求范围，这决定了其工程发布项面临两类用户： 二次开发用户：这类用户通过使用、组装、改造应用组的发布产品，最终形成自有化的业务系统对外提供业务功能。此场景下，应用组的目标功能通过接口调用、扩展点植入等方式间接表现给最终使用用户。 最终使用用户：这类用户通过直接使用应用组开发的特定业务功能来直接完成日常业务操作。此场景下，应用组的目标功能通过用户界面、远程服务接口等方式直接表现给最终使用用户。 通过对应用组工程发布项识别，发现面对不同的用户，应用组的工程具备不同发布项： 二次开发用户：各类jar包、页面资源目录、服务定义资源目录、窗体定义资源目录 最终使用用户：各类jar包、页面资源目录、服务运行资源目录、窗体运行资源目录、应用配置文件、数据库定义及初始化数据 目前应用组的基础业务框架工程在业务部门进行个性化改造后存在两个较大的分支版本： 证券三部、证券二部、基财二部同属一条分支 银行一部、银行三部、基财一部同属一条分支 应用组工程存在问题 支持二次开发的框架、平台功能实现部分的设计不足，例如： 没有统一的事务管理器，导致和业务对接使难以保证事务一致； 请求会话管理管理相对薄弱，只能满足目前工作流平台的交互需求，对金融行业的其它系统未做行业扩展； 应用框架扩展点设计的通用性还待优化； 业务分层不够清晰，无法通过层与层之间的调用隔离业务影响； 基础业务框架多个版本出现不兼容的情况，两个分支版本的数据库无法兼容 基础业务框架的边界不够清晰，在特定业务领域中业务功能的实现(特别是UI的实现)过于个性化，具体业务对框架的侵入导致框架灵活性无法体现； 工作流平台对底层jbpm引擎的封装需要标准化； 解决方案 对应用工程进行分层分模块规划，梳理模块之间的依赖关系，标准化应用对外接口模块涉及的外部服务接口和数据接口 按模块识别产品发布项，按用户区分模块的发布项(设计期项、运行期项) 约束应用模块组织、交互、打包、发布规则，实现模块工程的高内聚以及模块之间的松散耦合原则；设计框架对模块的扩展点支持，允许在运行期按需自由组合不同的应用功能模块。 本文说明 本文适用于JRES平台应用组所有设计和开发人员、JRES平台相关组设计和管理人员、业务部门二次开发项目的设计和管理人员。 术语定义 数据总线：数据总线用于定义应用框架的数据传输协议。数据传输协议描述一套数据传输和交换标准，接入到数据总线的对象必须实现可序列化接口。数据总线可穿透应用的表现层、服务层或持久层，任意层次和模块的代码均可访问数据总线；数据总线定义模块不依赖非总线的其它模块。 服务总线：服务总线用于定义应用框架的远程调用协议。表现层与服务层、服务层各模块之间通过服务总线进行交互。服务总线的定义不依赖任何平台技术，但其实现会具体依赖平台技术的选型。业务API可以通过包装器包装，接驳到不同平台实现服务总线。总线上的API包装应保证事务的一致性，同时此类API的参数应满足数据总线规范；服务总线的运行依赖具体平台的