基于SOA的保险核心业务系统集成设计的研究.pdf

复旦大学 硕士学位论文 基于soa的保险核心业务系统集成设计研究 姓名 马俊杰 申请学位级别 硕士 专业 软件工程 指导教师 徐如志 牛军钰 20070920 摹于s o a 的保险核心业务系统集成设计研究摘要 摘要 随着市场的飞速发展 企业越来越注重于自己的信息化 从而 出现了一大批企 业应用软件系统 但由于各系统相对独立 由此带来了信息孤岛问题 s o a s e r v i c e o r i e n t e d a r c h i t e c t u r e 面向服务的架构 的提出正是为了解决该问题 为企 业的系统集成 信息共享提供了可行的策略 s o a 的三阶段实现 f u n d a m e n t a ls o a n e t w o r k e ds o a 和p r o c e s s e n a b l e ds o a 为各规模企业提供合适的解决方案 本文将围绕太平洋人寿保险分公司的业务需求展开讨论 当前核心业务系统 单 证管理系统 业绩考核系统三系统间的数据同步由每天凌晨数据库间数据批量导入来 完成 存在因信息同步延时而导致的业务数据异常问题 并且该方法弹性低 难以拓 展及维护 本文将以s o a 的思想建立系统架构 定义各系统所提供的服务 同时 以w e bs e r v i c e s 技术来包装系统 对外提供接口 并使用a o p 模式来改造客户端 实 现系统的集成 解决当前方案的不足 本文的主要工作为 1 分析核心业务系统 单证管理系统 业绩考核系统 定义各系统提供的服务 以及各服务间相需互调用的节点 2 在业务分析基础上 使用w e bs e r v i c e s 技术实现服务包装 发布 3 对当前系统应用端分析设计 通过a o p 模式改造应用端使其能在需求定义的 节点处调用所需服务 达到信息同步 4 在上述分析设计基础上 使用流程自动化相关技术来设计架构 使架构有更 高的弹性 更易于维护 关键词 保险公司 系统集成 s o a w e bs e r v i c e s 基十s o a 的保险核心业务系统集成设计研究 a b s t r a c l a b s t r a c t w i t ht h er a p i dd e v e l o p m e n to ft h em a r k e t e n t e r p r i s e si n c r e a s i n g l yf o c u so nt h e i ro w n i n f o r m a t i o n t h u s al a r g en u m b e ro fe n t e r p r i s ea p p l i c a t i o ns o f t w a r eh a v eb e e nd e v e l o p e d h o w e v e r a st h es y s t e mr e l a t i v e l yi n d e p e n d e n t i n f o r m a t i o ns i l oh a sb e c o m eab i gp r o b l e m s o a 侣e r v i c e o r i e n t e da r c h i t e c t u r e i sp r o p o s e dt os o l v et h ep r o b l e m i tp r o v i d eav i a b l e s t r a t e g yf o re n t e r p r i s es y s t e m si n t e g r a t i o na n di n f o r m a t i o ns h a r i n g s o a a c h i e v e di nt h r e e s t a g e s f u n d a m e n t a ls o a n e t w o r k e ds o a a n dp r o c e s s e n a b l e ds o a f o rt h es c a l e e n t e r p r i s e st op r o v i d et h ea p p r o p r i a t es o l u t i o n t h i st h e s i sw i l lf o c u so nt h eb u s i n e s sr e q u i r e m e n to fc h i n ap a c i f i ci j f ei n s u r a n c e c o m p a n y t h ec u r r e n ts o l u t i o nf o ri n t e g r a t i o no fc o r eb u s i n e s ss y s t e m c b s d o c u m e n t m a n a g e m e n ts y s t e m d m s a n dp e r f o r m a n c ee v a l u a t i o ns y s t e m p e s i sb a s eo nn i g h t l y b a t c hd a t a b a s eu p d a t e a n dt h ei n f o r m a t i o na m o n gt h et h r e es y s t e mi sa s y n c h r o n i z e d i t s m a k et h eb u s i n e s sd a t ae r r o r t h i st h e s i sw i l lu s et h es o at e c h n o l o g yt oc r e a t et h e a r c h i t e c t u r e d e f i n et h es e r v i c e st h a tp r o v i d eb yt h eb u s i n e s ss y s t e m a n dt h e nw i l lu s ew e b s e r v i c e st oi m p l e m e n tt h es e r v i c e s a n dr e b u i l dt h ef r o n t e n d sw i t ha o pp a t t e r n i m p l e m e n t t h ei n t e g r a t i o n t h em a i nw o r ko ft h i st h e s i sl i e sb e l o w 1 d e f i n i t i o no ft h es e r v i c e sp r o v i d e db yc o r eb u s i n e s ss y s t e m d o c u m e n t m a n a g e m e n ts y s t e ma n dp e r f o r m a n c ee v a l u a t i o ns y s t e m m a k ec l e a rt h ep o i n t w h e nt h e yn e e dt oc o m m u n i c a t ew i t he a c ho t h e r 2 b a s eo nt h eb u s i n e s sa n a l y s e i m p l e m e n ta n dd e p l o yt h es e r v i c e su s ew e bs e r v i c e s t e c h n o l o g y 3 r e b u i l dt h ef r o n t e n d sw i t ha o pp a t t e r n c a l lt h es e r v i c ew h e nn e c e s s a r yt o s y n c h r o n i z et h es y s t e m 4 c r e a t et h ea r c h i t e c t u r ew i t hp r o c e s s e n a b l e ds o a m a k et h es y s t e mm o r ef l e x i b l e k e y w o r d s i n s u r a n c ec o m p a n y s y s t e mi n t e g r a t i o n s o a w e bs e r v i c e s n 论文独创性声鹳 本论文是我个人在导师指导下进行的研究工作及取得的研究成果 论文中除 了特别加以标注和致谢的地方外 不包含其他人或其它机构已经发表或撰写过的 研究成果 其他同志对本研究的启发和所做的贡献均已在论文中作了明确的声明 并表示了谢意 作者签名 太保的业务分析 提出系统集成的需求及当前解决方案的局限性 并阐述如 何使用s o a 解决这些问题 对核心业务系统 单证管理系统和业绩考核系统进行分析 详细分析三者操 作上的业务流程 业务特点 明确它们之间的集成需要 然后在此业务基础 上 阐述如何基于s o a 设计集成方案 在业务分析的基础上 提出具体的技术解决方案 包括使用w e bs e r v i c e s 技 术对系统进行包装并发布 使用a o p 编程思想对应用端改造的设计等 以及 在完成上述实现后 使用p r o c e s s e n a b l e ds o a 进一步改造系统的方法 1 4 论文的组织结构 基于以上分析 本文将以如下结构对各问题加以阐述 第一章 绪论 总体介绍背景及课题研究内容 第二章 介绍s o a 及其相关技术概述 将从理论层面阐述s o a 概念及其实现要 点 第三章 太保具体业务分析 将分析核心业务系统 单证管理系统和业绩考核系 统所提供的服务 并阐述当前集成方案及不足 并从架构层面阐述如何通过基础s o a 制定实施方案 驰4 血其4 6 基于s o a 的保险核心业务系统集成设计研究 第一章绪论 第四章 技术实现方案 基于第三章所作业务分析 提出具体实现的技术方案 并在最后以流程自动化s o a 的相关技术设计系统 在前文的基础上 提出从基础s o a 向流程自动化s o a 迈进时所要面对的一些问题以及解决方法 第五章 总结部分 将综述本文所做的工作 整体设计体会及论证过程中的不足 笫5 哑共4 6 呃 莲于s o a 的保险核心业务系统集成设计研究 第 二帝面向服务的架构及其j 实现 第二章面向服务的架构及其实现技术 本章简要介绍s o a 的理论知识 特点 及其主要实现技术 由此为以后研究定 下理论基础 2 1 面向服务的架构 本节将简要介绍面向服务的架构的相关概念及其特点 2 1 1 面向服务的架构 s o a 概要 s e r v i c e o r i e n t e da r c h i t e c t u r e 面向服务的架构 1 9 9 6 年由g a r t n e r 最先提出 并 预言到2 0 0 8 年 至少6 0 的企业将使用s o a 作为其r r 架构 6 1 在理解s o a 前 必 须先理解s e r v i c e 服务 几乎所有组织都在提供着服务 比如银行提供贷款 存款 等服务 保险公司提供受保 理赔等服务 等等 从计算机角度来说 服务可以理解 为由系统对这些行为提供的支持 是系统对请求所执行的有意义的操作 但它不同于 软件设计上的模块的定义 方法的定义 后者从技术角度来分析 而服务是从业务的 角度来看待的系统功能 s o a 正是以s e r v i c e 为最基础元素的一个软件架构 作为一个软件架构 它定义 了基本的系统结构 并且定义了各服务间的通信 数据交换等规范 它主要有以下四 点要素组成 s e r v i c e 服务 作为s o a 的最基本元素 服务无疑是最重要的 正如前面所说 服务是从业务 层来看待系统 是对高级别业务概念的一种压缩 在s o a 中 一个服务一般包含以 下几个要素 c o n t r a c 卜 服务的描述 定义了该服务的目的 功能 约束条件和用法 i n t e f f a c p 服务向外暴露的接口 可供其它应用程序或者其它服务调用 i m p l e m e n t a t i o n j 匣务的具体实现 提供业务功能和业务数据 也就是通常 意义上需要被集成的应用系统 这些业务功能通过i n t e r f a c e 暴露以供其它使 用者调用 图2 1 显示了一个服务的主要结构 一个服务包装了和它相关的业务逻辑与业务 数据 缸6 饥共4 6 基十s o a 的保险核心业务系统集成 世计研究第二章面向服务的架构及其实现 图2 1 s e r v i c e 不惹图 a p p l i c a t i o nf r o n t e n d s 应用端 应用端是s o a 的具体操作者 初始化和控制整个应用系统 一般而言 这与单 系统的应用端并无多大区别 往往是一个用户图形界面 g u i 通过网页访问或者胖 客户机的程序访问 也可能是一个批处理程序或一个应用流程 比如用b p e l 写的一 个具体业务流程 作为应用端来操作服务的具体执行 s e r v i c er e p o s i t o r y 服务库 服务库用于对服务进行管理 可以从这里得到服务的所有详尽信息 服务库存储 服务的c o n t r a c t 信息 并且服务库还提供服务的物理信息 比如服务接口的地址 服 务的提供者信息 服务的约束条件和安全性条件等等 对于s o a 服务库并不是必须 的 它更多的是对服务的一种说明 但对于服务数量很大时 或者希望使用一些动态 寻找服务的功能时 建立服务库是必须的 图2 2 大致示意了一个服务被调用的过程 该过程类似于j a v a 中的远程方法调用 芦 鞠 i m wl 圈罢曰一圈 l 崮一 图2 2 服务被调用的过程 s e r v i c eb u s 服务总线 是一个软件总线 软件总线是分布式环境下技术基础的一种标准 它定义了各模 块i b j 如何协同工作 最有名的软件总线无疑是o m g 定制的c o r l 3 a 而最近较为主 流的j 2 e e n e t 也都属于这个范畴 服务总线用于连接所有的服务和应用端 当应 用端需要调用服务或者服务 日j 需要互相调用时 它们必须通过服务总线相互通信 服 务总线作为一个抽象的总线 是一系列的标准定义 包括连在其上的各节点的通信方 式 协议 路由 安全性 稳定性 可用性等等 s o a 丁f 是由以上四点构成 图2 3 描述了这个结构 第7 巩其4 6 基于s o a 的保险核心业务系统集成设计研究 第二章血向服务的架构及其实现 匹丌j 图2 3 s o a 的组成结构 2 1 2 面向服务的架构 s o a 特点 在上一节介绍什么是s o a 时 可以看到没有出现任何技术相关的词汇 可以说 技术无关性是s o a 最大的特点 这也是一个集成架构所必须有的特性 从本质上讲 s o a 并不是一种技术 也不是一种技术规范 它是用于规划架构蓝图的高层次概念 是一种架构和组织r r 基础结构及业务功能的方法 从设计层面来说 s o a 有很多特性 在此仅针对与我们将要研究的系统有关的几 点予以陈述v j 首先 s o a 的服务定义是粗粒度 c o a r s e g r a i n e d 的 服务的使用者并不具体关 心服务的内部实现 甚至可以不关心服务的业务模型 只需要了解服务提供的业务功 能 这样使得服务易于维护 一个服务的内部实现或业务流程的改变 并不影响到它 的调用者 甚至服务内部业务模型的重建也并不影响到它的调用者 这点对于数据库 层的同步来说 是很难实现的 其次 服务的独立性保证了松耦合和重用性 作为一个系统合成层面的架构 其 中最基本的元素 服务 往往就是一个系统 它是一个可以独立运行的单元 同时 s o a 的松耦合还体现在技术上的松耦合 从上一节服务的事业图可以看到 一个服务 并不关心它其中的实现具体使用什么技术 从这点上也增加了服务的灵活性和维护 性 以保险公司为例 由于业务的不断发展和技术的不断跟新 单系统的重构是经常 发生的 而新系统甚至常常用的和旧系统不一样的技术 而服务的技术松耦合 使得 这样单系统的重构不会影响到其它相关调用者 最后 正如本节丌头所提到的 s o a 不依赖与任何技术 这罩指接口1 b j 通讯和传 输技术 而非服务的实现技术 当业务被建立成服务后 它们可以通过多种技术手 段实现通信 比如 基于消息机制的传统e a i 中间件i b mm q 基于1 1 0 p 协议的 c o r b a 平台 或者基于s o a p h t t p 的w e b s e r v i c e 平台 这样的特点使得s o a 适合 第8 共4 6 撕 基十s o a 的保险核心业务系统集成设计研究 第 二章面向服务的架构及其实现 于各类企业 已经在应用集成上投入大量资金 购置i b mm q 等中i 日j 件的大公司可以 方便的基于这些中问件实现s o a 一些中小型公司也可以基于开放的w e b s e r v i c e 平 台实现s o a 企业实施s o a 将是一个非常漫长的过程 可按照以下三级别逐步实现 f u n d a m e n t a ls o a 在这个阶段 整个架构一般由两层构成 应用端和服务端 服 务端提供业务功能 应用端控制业务流程并依次调用需要的服务 n e t w o r k e ds o a 在这个阶段 会在上述两层的基础上增加中间层 该层包含中 间件服务 提供一些类似于适配器的功能或公共接口的功能 p r o c e s s e n a b l e ds o a 在该阶段 将在前三层基础上增加业务逻辑层 该层提供 流程服务 实现业务流程管理 业务流程管理即按照业务需要 将一系列系统服务按 照次序以工作流的形式执行并管理 该工作流可以是短暂的或复杂冗长的 可以由系 统独立完成的或由人为参加的 8 流程服务需要相关业务流程管理系统支持 该系统 被称为业务流程管理系统 b u s i n e s sp r o c e s sm a n a g e m e n ts y s t e m s b p m s 一个完整 的b p m s 一般需要包含以下几个功能1 9 流程建模 流程执行 流程监控 下部构造 2 2 实现s o a 的主要技术 本节将介绍s o a 的主要实现技术 以及在改造应用端时将要使用的a o p 技术 2 2 1 使用w e bs e r v i c e s 技术实现s o a w e bs e r v i c e s 是一个开放的技术平台 它定义了一系列标准 w e bs e r v i c e s 间的数 据交换以及w e bs e r v i c e s 本身的结构定义都基于x m l 由于x m l 是一种当前普遍被 接受的标准 所以基于x m l 使得w e bs e r v i c e s 能够得到更好的跨平台性 同时 w e b s e r v i c e s 还具备其它一些特性 比如由于其是一个开放的平台 所以有一系列w s 的 标准技术对其进行支持 如用于安全的w s s e c u r i t y 用于控制线程的w s t r a n s c a t i o n s 用于控制流程的w s b p e l 等 w e b s e r v i c e s 完全满足了s o a 中分布式 互操作 可重用 跨平台和松耦合等主 要特征 在实际的开发实现过程中 每个可构建的w e bs e r v i c e s 对应于s o a 中的服 务实体 服务实体所承担的业务功能由w e bs e r v i c e s 中的方法与函数实现 不同的 w e bs e r v i c e s 之间可灵活组合 以完成更复杂的任务 为s o a 解决软件复杂性提供支 撑 1 1 0 l w e bs e r v i c e s 的核心有以下三个基础技术 s i m p l e0 b j e c ta c c e s sp r o t o c o l s o a p 是一种传输访问协议 它基于现有的 因特网技术 f r p h t t p 或s m t p 等 定义了各w e bs e r v i c e s 日j 通过x m l 互相访 第9 以搀4 6 咖 基于s o a 的保险核心业务系统集成设计研究第二二章面向服务的架构及j 实现 问时 x m l 文件的结构 编码格式及文档转换格式等 以供不同技术平台通过该协议 互相访问 比如j 2 e e 平台和 n e t 平台间的互相访问 在应用中 支持w e bs e r v i c e s 调用的服务器将会将我们调用时提供的方法名和参 数包装成s o a p 封包 通过特定韵类文件 比如a p a c h 项目组的 o r g a p a c h s o a p m e s s a g i n g m e s s a g e 类 将该封包按照一定u r l 地址送到服务提供方 调用相应方法 w e bs e r v i c e sd e s c r i p t i o nl a n g u a g e w s d l 是一种x m l 技术 通过一个x m l 文件定义了w e bs e r v i c e s 的接口 包括w e bs e r v i c e s 提供的方法 所需要的参数类型 等等 从某个层面来讲 w s d l 类似于c o r b a 中的i d l 一个标准的w s d l 文件包含以下元素 用于定义文档的命名空间 一个w s d l 可以引入其它x m l 文件 比如 作为参数的业务对象为 一个x m l 文件 该文件可以通过i m p o r t 标签被引入到当前w s d l 中 用于定义数据结构 可以是所调用方法需要的参数的数据结构 用于定义服务需要的参数类型 此处可以引用t y p e s 标签里定义的数 据结构 也可以引用i m p o r t 中引入的业务对象 用于定义该w s d l 中所有的方法集合 该标签中包含多个 标签 每个 代表一个方法 每个 标签中包含多个 标签 标明该方法需要的参数 该参数将关联一个 定义的类型 w s d l 还有一些非必须的元素 比如 用于定义参数的编码方式 传递协 议 用于定义服务具体的u r l u n i v e r s a ld e s c r i p t i o n d i s c o v e r y a n di n t e g r a t i o n u d d i 提供服务的注册 查 询等功能 起到第二章中所说的服务库的作用 u d d i 的概念类似于j a v a 中的j n d i 需要服务器的支持 可以通过特定的x m l 文件与其打交道进行服务的注册 查询等 操作 2 2 2 使用a o p 技术改造应用端 在实现f u n d a m e n t a ls o a 时 应用端需要负责流程的控制管理和服务调用等工作 对于遗留系统应用端的改造 这样的工作往往要修改当前系统的代码 此时 可以选 用面向方面的编程 a s p e c t o d e n t e dp r o g r a m m i n g a o p a o p 通过请求拦截 为我 们现有的类增加新的功能 在实现a o p 时 我们需要了解以下几个概念1 1 1 a s p e c t 这是我们需要的功能 将被加载到业务方法上 j o i n p o i n t 这是程序运行过程中 可以被插入服务的节点 摹于s o a 的保险核心业务系统集成设计研究 第一章面向服务的架构及其实现 a d v i c e 是a s p e c t 的具体实现 a s p e c t 只是一个功能描述 用具体代码实现后我 们称之为a d v i c e p o i n t c u t 用于定义一个a d v i c e 应该被插入哪个j o i n p o i n t t a r g e t 我们的目标类 及业务功能类 p r o x y s p r i n g 使用代理类来实现a o p 代理类和目标类实现同样接口 并为目 标类增加新功能 w e a v i n g 包装 这是框架需要做的操作 即根据p o i n t c u t 在某j o i n p o i n t 插入相 应需要的a d v i c e 以把一个目标类包装成代理类 图2 4 大致展示了这一过程 d o i n p o i n t s 图2 4 实现一个a s p e c 第j 1 共4 6 虹 雉十s o a 的保险核心业务系统集成l 世计研究第三章基于s o a 的系统集成需求分析 第三章基于s o a 的系统集成需求分析 本章将描述太保当前运行的核心业务系统 单证管理系统和业绩考核系统三个系 统 这三个系统每个都包含一系列业务功能 此处只描述这三个系统将需要相互作用 的业务模块 3 1 太平洋人寿保险分公司应用系统分析 如前文所述 本文将阐述核心业务系统 单证管理系统和业绩考核系统三者间的 集成问题 在本节 将根据前文提出的业务流程 对各系统相应提供的业务功能加以 阐述 并简要阐述当前系统的集成方案及其局限性 3 1 1 核心业务系统 核心业务系统用于营业端处理保险业务 包括保单的销售 保单的理赔等等 在 此 我们将关心以下几个功能点 空保单录入 保险公司的主要业务为各类保险的销售 是一种无形商品 每份保 险对应一份保险合同 即保单 记录保险相关信息 在这些保单被销售前 需要先 将空保单录入到业务系统的保单库中 以供业务员使用 空保单入库时 需要录入相 对应的险种 唯一序列号 所属公司及业务员等信息 业务员维护 所有保单将通过各保险业务员来销售 在空保单录入系统时 需要 将保单录入到某业务员名下以供其使用 销售 所以系统需维护业务员信息 同时 由于保险业务员流动性大 与公司其它运营相关度低 所以太保的业务员信息在核心 业务系统中维护 包括业务员的录入 个人信息 所属机构 工号 职位相关信息等 以及业务员的修改 包括信息修改 查询 删除 业务员保单发放 当保单在单证管理系统里被领用后 可以直接在单证管理系统 里分配到业务员名下 然后在核心业务系统的空保单录入时 直接录入到该业务员下 但根据业务需求 有些险种无法预先确定到底哪些号段分配给哪个业务员 而是由业 务员当天来领取时爿 能确定 由此 在空白保单录入时 该保单是被录入在业务部门 库存内的 需要由业务员保单发放功能将该保单发放到该业务员 同时 这个数据会 由每天晚上的数据批量导入被导到单证管理系统 在单证管理系统中执行相关发放到 业务员操作 保单核销 保单核销包含两种含义 第一种为使用核销 及当一份保单生效时 即所对应空保单被使用 需要在空保单库中将该保单核销 该功能包括保单详细信息 筘1 2 衄共4 6 血 基十s o a 的保险核心业务系统集成设计研究 第三章桀十s o a 的系统集成需求分析 的录入 该保险相关信息 销售业务员信息 销售同期等 和库存修改两点 第二种 为作废核销 即当一份保单不是因为被销售而核销时使用 比如保单丢失 保单填写 错误 保单过期或需要将保单退回时使用 3 1 2 单证管理系统 如上节所说 保险公司的所有业务通过保单形式体现出来 所以 对保单的管理 对于保险公司来说是尤为重要的 单证管理系统正是用于处理各类与保单相关信息的 系统 该系统主要由两部分组成 一部分为保单的申请流程模块 一部分为保单的库 存管理模块 以下分别简述两部分的作用 保单申请流程 在阐述该模块功能前 需要先了解一下单证的生成过程 首先 由核保核赔部门根据分析 预测今年的市场前景 确定是否需要新建某一险种 或者 是否为已经存在的险种印制一定数量的空保单以备销售 将这些信息提交到计划财务 部 然后 经计划财务部审批确认后 这批保单将送交印刷厂印制 印制后将送到总 库部 由总库部确认后入部门库 当单证存在后 业务部门可以向核保核赔提出领用 申请 经核保核赔部审批同意后 由总库部从部门库存中发放相应单据到业务部门 然后各业务部门确认入部门库 最后再从部门库中发放到各业务员名下以供销售 保单库存管理 如前面所说 在保单的申请流程过程中 对应着各类的入库 发 放 这便是库存模块的主要功能 同时 库存模块不但需要管理保单的进和出 还需 要管理保单的核销 包括使用核销和非使用核销 当保单核销后 库存需要相应改动 并能保留所有的保单操作信息 以供各类查询 报表使用 基于以上两点需求 我们将关心单证管理系统的以下几个模块 新建 印制申请模块 该模块供核保核赔部门使用 根据业务需求 通过系统新建 一个险种 并输入该险种相关信息 以形成一个保单的样张并印制一定数量供使用 或者根据一个已经存在的保单样张 提出申请印制一定数量供使用 新建 印制审核模块 该模块供计划财务部及其它协同审核部门使用 当核保核赔 部新建 印制申请提交到计划财务部后 计划财务部可在此选择通过 退回 或转移给 其它相关部门 比如产品 丌发部 审批 最终由计划财务部审定通过后允许保单的印 制 初始入库模块 该模块供总库部使用 当一个单证新建 印制流程通过后 将由应 刷公司印制 然后交到总库部 总库部需要在系统中对这批单证入库 由于是新生成 的单证 所以命名为仞始入库 初始入库单在新建 印制审定时生成 在确认收到单证 后在系统中入库 系统修改库存信息 领用申请模块 该模块供各业务部门使用 一个保单被新建后 各业务部门就可 以提出对该保单的领用申请了 领用申请将被提交到核保核赔部 箱 3 舡共4 6 基十s o a 的保险核心业务系统集成设计研究 第二章笨十s o a 的系统集成需求分析 领用审核模块 该模块供核保核赔部门使用 当业务部提出领用申请后 核保核 赔部可以根据情况选择同意或退回 也可以出于业务目的改变领用的数量 单证发放模块 该模块供总库部使用 当领用审核通过后 系统会生成发放单 由总库部确认发放 系统生成验收入库单 等待相应业务部门入库 验收入库模块 该模块供各业务部门使用 验收入库单在总库部单证发放后生成 由业务部门在收到保单后确认入库 系统将增加业务部门库存 相应减少总库部库存 发放业务员模块 该模块供各业务部门使用 业务部门领用到一定量的保单后 需要经过业务员销售这些保单 所以需要将保单发给某个具体业务员 该功能将修改 库存 增加业务员单证持有量 减少业务部门库存 核销模块 该模块供所有有库存的机构使用 可以将保单从库存中核销 3 1 3 业绩考核系统 业绩考核系统主要负责记录业务员销售情况 生成各类报表 该系统不提供直接 的业务操作功能 在此 我们主要关注两方面 业务员的导入模块和单证销售情况的 导入模块 前者是向系统里添加业务员信息 后者是保单在核心业务系统中被销售后 在本系统中添加相应销售信息 以增加业务员业绩 3 1 4 太平洋人寿保险分公司系统集成现状及其局限性 当前 核心业务系统与单证管理系统之间的通信通过数据库层的夜间数据批量导 入来实现 如图3 1 所示 单证管理系统主要负责公司的各类保单的新建 印制 领 用和核销情况的管理及其信息维护 通过单证管理系统的领用 在核心业务系统才可 以使用保单 然后当保单在核心业务系统被使用后 需要到单证管理系统中核销 由 于两系统并未在应用层做任何系统集成 所以当保单从单证管理系统领用后 需要业 务人员手工在核心业务系统中输入 而当保单在核心业务系统中被使用后 将通过夜 问的数据采集工具从核心业务系统采集至单证管理系统 然后在单证管理系统的数据 库层运行存储过程对这些保单进行核销处理 业绩考核系统负责记录业务员的业绩 也需要核心业务系统数据的支持 而业绩考核系统与核心业务系统的数据同步也通过 同样的方法实现 第1 4 见共4 6 叽 塔十s o a 的保险核心业务系统集成设计研究第三章基于s o a 的系统集成需求分析 图3 i 通过数据库层的信息交换 为了实现夜间的数据采集 太保特意开发了相关的中间件一数据采集系统 该 系统每天凌晨零点开始运行采集数据 将核心业务系统中当天的保单销售数据及业务 员维护数据导入到单证管理系统和业绩考核系统的数据库 同时 单证管理系统和业 绩考核系统中也有定时启动的存储过程来处理这些被导入数据 图3 2 是在以上所述 几个系统的支持下 业务的运作模式 h u m a nt a s k 单证管理系统 核心业务系统 数据采集系统 熹耻 专 t i t t 一 d 兰矿 1 一 乎 入库单据 在领用申请审批流程通过后 单证验收入库时生成入库单 供收 到单证的业务部门签收 该对象将在业务部门验收入库时 由单证系统提交 到核心业务系统 主要包括以下字段 申请单i d 唯一标识 入库机构 入库时间 操作员 以上字段为入库单表头 下列字段为入库单明细 一个 入库单可以由多行明细组成 单证i d 对应与保险单证的单证i d 标识所入 库的单证 单证年份 相关业务员i d 单证流水号起始 单证段长度等 核销单据 当核心业务系统销售某一保单后生成 分别提交到单证管理系统 和业绩考核系统 通知此二系统销售情况 也可以是非使用核销 即在核心 业务系统中批量的作废核销 这种情况下只需要通知单证管理系统 主要包 括以下字段 核销单i d 唯一标识 核销机构 核销时 自j 操作员 以上 字段为核销单表头 下列字段为核销单明细 一个核销单可以由多行明细组 成 单证i d 对应与保险单证的单证l d 标识所核销的单证 单证年份 单证流水号起始 单证段长度 相关业务员i d 核销原因 包括使用核销和 各类非使用核销 其它说明等 业务员 作为三个系统都需要的信息 业务员的同步也是相当重要的 当业 务员数掘不全 只存在于其中某个系统而不存在于其它系统时 对于单证的 第1 9 艇共4 6 贝 基于s o a 的保险核心业务系统集成设计研究 第三章基于s o a 的系统集成需求分析 领用和核销都会造成很大的问题 为此 当核心业务系统维护业务员信息时 需要将该业务员信息作为业务对象 发送给其它两个系统 主要包括以下字 段 业务员i d 唯一标识 为该业务员工号 业务员姓名 性别 所属部 门 等级 不同等级业务员将有不同业绩考核公式 联系电话 地址 状态 在职 离职 是否可用等 3 2 3 应用端需集成的节点 如第二章所说 在实现f u n d a m e n t a ls o a 时 应用端仍然担任着相当重要的角色 它们负责业务流程的控制及服务的调用 在我们的应用中 从图3 2 流程图可以看到 在跨泳道的几个节点处 系统需要 相互通信 在上文中 我们列出了各系统间用于相互通信的接口 在节点处 将由应 用端 业务逻辑层 按照需要 通过接口调用其它系统的服务 达到信息同步 通过对业务流程的分析 我们可以定义出以下节点 单证管理系统中 当核保核赔部门新建一个单证后 需要将单证信息添加到 核心业务系统中 该步操作将在业务部门验收入库时手动完成 操作人员首 先需要根据单证代码判断系统中是否已经存在该类单证 如果确认为新单证 则需要先新建该单证再入库 单证管理系统中 业务部门领用申请审批流程通过后 需要验收入库 将单 证号段加入自己部门库存中 同时 需要手动在业务系统中将这批单证添加 入库 以供销售 核心业务系统中 当把一个业务系统库存下的单证发放到业务员时 需要同 时在单证管理系统中将该单证发放 该操作将通过夜间数据库批量数据导入 来处理实现 核心业务系统中 当一个保单被销售后 会在业务系统中将该单证做使用核 销 同时 需要在单证管理系统中和业绩考核系统中对该单证做使用核销 这些操作现在是通过夜间数据库批量数据导入处理来实现的 核心业务系统中 如果一个单证被作废核销 则该步操作会和使用核销一样 通过夜间数据库批量数据导入处理在单证管理系统中将该单证作废核销 核心业务系统中 当添加 删除或修改一个业务员信息时 该业务员信息需 要同时被添加到单证管理系统和业绩考核系统 这些操作现在同样也是通过 夜间数据库批量数掘导入处理束实现的 从上述分析可看出 当几个节点处的需求被包装成服务后 我们可以在应用端通 过调用改服务来达到系统通信的目的 完成数掘的即时同步 在这个阶段 各系统仍 然有个各自独立的应用端 在应用端需要同步的地方添加相关的调用代码 第2 0 i d 共 n l j i 基于s o a 的 险核心业务系统集成设计研究第三章基于s o a 的系统集成需求分析 3 2 4 系统架构的建立 第二章介绍了s o a 架构下的四个基本组成部件 在此处 我们将按照遵守这些 组成部件 将系统架构设计如图3 6 所示 s e r v i c eb u s 一s f m r o m 一 口t 口l 口f 口1 接口z 口i i 4 x 删 i 一 f 习f 习f 习 图3 6 系统架构 其中 服务层为我们在上一节中所定义的三个基础服务 s e r v i c er c p o s l t o r y 层存 储这些服务的信息并供调用者查询访问 具体技术及使用方法将在第四章阐述 应用 端将通过服务总线 访问s e r v i c er e p o s i t o r y 取得相关服务接口 并在代码中调用这 些服务 服务总线 s e r v i c eb u s 此处 由于系统基于初级的s o a 应用端将担负更多 的职责 所以相对而言s e r v i c eb u s 较为简单 只需关心各组件的可访问性 由于该块 内容更多的和技术相关 本文将在第四章再阐述相关内容的细节 在此 我们仅列出 相关考虑元素 通讯模式 不同的技术架构使用着不同的通讯模式 基于不同的通讯协议 以 c o r b a e j b 等为例 使用的是i i o p 协议 本文在技术环节上 将使用当前s o a 实 现中最为主流的w e bs e r v i c e s 技术 基于s o a p 协议 访问模式 一个服务的访问方法有很多 比如基于存根 s t u b 接口方法调用所 支持的r p c 模式 其特点是访问者持有服务的接口定义文件 存根 通过调用该接 口来调用远程服务 除此之外 基于消息机制的调用模式也是很常用的 该模式下 调用方将所需调用的方法名 参数等发送到调用管理器 由管理器负责调用具体方法 两者相比 r p c 模式需要访问者持有服务接日 并且当服务有所改变时 所有相关存 根都必须相应改动 但该模式能够在编译时发现调用错误 比如方法名错 参数不对 等等 而消息模式弥补了r p c 的缺点 使得服务的改动最小程度的影响到调用者 但缺点就是无法提供编译时的报错 在本文中 考虑到各服务都供公司内部使用 不 存在存根类散发 维护等问题 所以在初级阶段更多的将使用r p c 模式 第2 l 巩其4 6 口1 基十s o a 的保险核心业务系统集成设计研究第三章基于s o a 的系统集成需求分析 执行容器 将提供服务的运行环境 如前文所提 初级阶段的s o a 对容器的依 赖性并不高 只需提供服务的发布和可访问 而这往往和具体使用的技术相关 将在 本文的第四章详细介绍 可用性 包括可访问性 a v a i l a b l i t y 和可测量性 s c a l a b i l i t y 两方面内容 用 以保证服务能够被访问 能够及时回复 常用的手段有负载平衡 运行时监控等 对 于高级s o a 可靠性是相当重要的 以流程自动化为目标的高级s o a 必须确保每一 步不能出现任何问题 否则流程将被破坏 在本文所讨论的示例中 由于属于企业内 部集成 而且几个系统作为独立系统时都有一定的可用性控制 而流程则由应用端维 护 所以并不对可用性做过多关注 安全性 服务间的访问需要权限的控制 实现权限控制的方法有很多 比如用户 名认证 信任状文件认证 第三方安全控制框架等 以w e bs e r v i c e s 技术为例 它提 供了一套标准 w s s e c u r i t y 它使用基于s o a p 协议的安全性授权来控制整个架构的 安全性 事务性 对事务的管理是保证了数据的完整性和正确性 传统的事务性通过2 p c t w o p h a s ec o m m i t 机制控制 首先 由参与事务的各个模块分别做相关操作 当所 有模块都确认成功后 再统一执行存储 如果有任何一个模块出了问题 则所有模块 回滚 对于高级s o a 这样的机制明显是不足的 但在我们的示例中 流程还处在由 应用端控制的阶段 使用该控制模式能够很好的满足我们的需求 所以本文示例将主 要由应用端控制事务的完整性 而在下一章中 将对应用于高级s o a 的事务控制模 式加以简要阐述 3 2 5 改造后的流程描述及对当前缺陷的弥补 在前面几节阐述了服务的包装 系统的架构 在此 将简要描述一下当这一系列 改造实施成功以后 业务流程将是怎样的一个模式 首先回顾图3 2 在描述业务流程时 数据采集系统担任着相当重要的角色 而 当我们的改造实施后 数据采集系统将不再需要 数据库间将实时的同步而不需要夜 问批量的导入处理 这也是我们改造的主要目的 改造过后 新建 印制流程作为较为独立的功能 流程将没有任何改变 核保核 赔部门根据需要在单证管理系统中生成一批空白保单 并存放在总库部库存中 但在 单证新建审批流程被最终审定通过的同时 单证管理系统的应用端将调用核心业务系 统的接口将该单证信息添加到核心业务系统中 然后 各业务部门在单证管理系统中 提出领用申请 经过审批流程后 在单证管理系统中验收入库 同时 与初始入库操 作类似 单证管理系统的应用端在操作验收入库时调用核心业务系统的方法 将这批 单证添加到核心业务系统库存中 如果单证需要在核心业务系统中发放i i j l k 务员 则 鹕2 2 虹其4 6 口l 基十s o a 的保险核心业务系统集成设计研究第三章摹于s o a 的系统集成需求分析 在发放到业务员的同时 核心业务系统的应用端将调用单证管理系统的业务员发放接 口 在单证管理系统中将该信息同步 最后 核心业务系统中销售单证 其应用端在 核心业务系统中核销某一具体单证的同时 将调用单证管理系统和业绩考核系统的相 关接口 将单证核销情况加入这两个系统中 业务员的相关操作仍然将在核心业务系 统中完成 同时 类似于单证的核销 其相关信息将通过应用端对其它两个系统接口 的调用达到信息同步的目的 在这样的运作流程过程中 每个环节都可能会碰到异常 比如某个服务暂时不能 访问 正如我们上节所提到的可用性和事务性 这些将由应用端控制 在此将就可能 发生的这些问题的处理方法加以阐述 首先 当新建审批流程审定通过时 需要将新建单证信息提交到业务系统 此时