金融服务平台概述.ppt

金融服务平台概述 Tulip Framework Tulip Studio 主要内容 项目背景介绍 总体架构 组件集 相关规范 农行现有系统架构 银行应用系统的发展趋势 数据趋于集中 处理趋于集中 系统更加开放 扩展方便 更好的适应地区差异化客户需求 *金融服务平台总体设计思想 问题提出 数据集中后，应用集中如何进行？ 各级业务部门提出的新型金融产品越来越多，如何做到高扩展性？ 业务处理流程千差万别，如何实现统一处理？ 解决思路－化整为零 新型金融产品的大部分业务逻辑都是在前置层上实现的 将各产品的逻辑拆分成具体的功能单元 对现有的金融产品所涉及的功能单元进行系统分析、归纳、总结，统一其处理方法 具体的业务逻辑通过配置参数体现 核心思想 利用面向业务的组件单元配置和架构模式，将业务模型从IT结构中分离，使开发人员只需关心业务逻辑和业务流程的分析，由金融服务平台来保障业务组件的运行、事务处理、安全校验等。 金融服务平台应用布局 *金融服务平台总体框架 金融服务平台基本概念 Tulip框架模块介绍 运行环境（Tulip Framework） 在UNIX环境下实现 基于CICS、Sybase、C Language、ESQL/C 开发管理环境（Tulip Studio) 在 .NET Framework下实现 基于Microsoft Visual Studio 2003/C# 产品信息（Product Information） 一个金融产品的实现包括产品逻辑的定义、产品运行数据、产品管理信息、产品统计分析数据等等，这些数据以各种方式保存在数据库中 金融服务平台物理结构 金融服务平台的几个特点 金融服务平台在功能设计上： 提供一组内核的基础服务和交易引擎，稳定高效 基于资源、组件的快速、规范的开发方法 灵活的交易流程配置、满足多业务流程定义需求，实现动态定义、 具有高扩展性 超强的数据格式转换功能（报文、文件、数据库），支持多种数据 格式的拆解、重组、解释 实现了统计报表的可视化配置 实时运行监控、运行日志、运行分析工具 提供B/S结构的管理工具，方便的实现产品管理 金融服务平台有以下优势： 架构清晰、开发便捷 有效的用户界面规范化、简化开发和管理 开放的标准组件，便于统一处理 节约开发时间 开发者关注的是业务逻辑，而不是技术 在松藕合、高聚合的平台实现下，最大化实现了组件的重用，复杂应用程序的开发时间显著减少 减少开发和维护成本 降低了开发技能需求，扩大了产品开发队伍， 降低了代码级错误重现，能快速投产和应用。 从而实现了 产品处理方法统一 产品开发方法统一 产品管理方法统一 产品维护方法统一 产品相关规范统一 交易引擎（Transaction Engine） 三部分主要功能 渠道接入 固定的头部信息、实现内外交易码转换 固定逻辑处理 安全检查 应用状态检查 流程控制 异常处理 组件集的调度 组件集（Component Set） 组件定义： 完成某种特定功能的一段执行代码，是由交易引擎调度的金融服务平台运行环境中的最小功能单元 组件集分类 格式转换类、客户信息及合约管理、票据管理、调试工具、通讯组件、手续费及滞纳金类、数据总线操作、枚举类、错误码操作类、表操作类、安全类（加/解密）、报表、对帐、明细记录 格式转换组件集(1)Format Component Set 设计思想分析 格式转换的三个方面 格式转换的方向（解包 、组包、重组、临时数据） 报文分类（8583类、XML类、一般报文、混合报文） 报文附加处理（加/解密、MAC校验、表达式处理、码制转换） 文件转换的两个问题 转换类型：文件→DB、 DB→文件、文件→文件 文件分类： 固定格式的一般文件体（头、固定体、尾） 不固定格式的一般文件体（头、不固定体、尾） 嵌套格式的文件体（头、嵌套体头、体、尾、尾） 报文组件设计 两个功能组件：组包、解包 外部报文 ==== 解包操作 ==? 内部运行数据总线 外部报文 ?== 组包操作 ==== 内部运行数据总线 附加处理的实现 动态或静态调用其他功能组件 文件组件设计 两个功能组件 文件 ?? 内部运行数据总线 ?? 数据库表 文件 ?? 内部运行数据总线 ?? 文件 *客户信息合约管理组件集Customer Component Set 组件集的基本分类 个人客户基本资料 单位客户基本资料 个人合约 委托单位合约 组件集设计 对后台相关客户信息表的增、删、改、查 合约是数据驱动模式下的项目、交易运行关联点 *票据管理组件集Bill Componen