“组装”寿险应用

寿险行业样本程序不仅要满足保险公司不断变化的需求、极短的项目开发周期，而且由于保险公司的经营涉及到国计民生，所以在平衡时间、进度、成本的同时，还必须满足极高的稳定性、安全性、效率的要求。

当前，保险核心业务系统的需求快速膨胀，我们在这股浪潮中迎来了中国保险信息化建设的机会，同时也面临了巨大的挑战: 笔者所在公司的开发团队就从原来的两三个扩展到二三十个，我们需要保证所有的项目按照统一的技术标准和质量标准进行开发，随着项目团队的爆炸式膨胀，必然面临有行业经验的开发人员的不足，我们从原来的一个“师傅”带一个“徒弟”变成了一个“师傅”带好几个“徒弟”，我们需要新进入的员工快速的进入开发状态。我们面对保险公司不断变化的需求，极短的项目开发周期，我们需要保证项目保质按时的成功上线; 同时，由于保险公司的经营涉及到国计民生，所以我们在平衡时间、进度、成本的同时，还必须满足极高的稳定性、安全性、效率的要求。

样本的技术实现

我们经过十几年的积累，拥有了一套基于组件的寿险行业应用平台。平台的核心设计思想是以领域模型为基础的，当随着技术的升级，如新的Java技术的出现，我们的平台只需要变更通用的功能组件。当技术革命到来的时候，如从4GL升级到Java平台，那么所有的业务领域对象的命名、逻辑的划分、逻辑的设计都可以保留，除了基础组件的升级外，核心业务逻辑能够轻松地升级到新的语言平台。

我们选择J2EE作为寿险行业软件平台的基础平台，由于Java的开放性和平台无关性，让程序员们可以将更多的精力放到新框架的研究上，也就最终导致了Java社区的繁荣，Ajax、Struts、Spring、Hibernate等框架导出不穷，每个框架都或多或少地解决了这样或者那样的问题，但是我们需要使用什么样的技术来为我们的平台服务，成为我们的“样本程序”呢？我们面对技术的发展，特别是各种开源框架的态度是吸取精髓，为我所用，即我们绝不照搬开源框架的所有程序，我们分析和吸取这些优秀框架在解决每个层面的问题时所用到的核心思想，并在自己的平台上运用。回顾我们的平台的发展，早在各种框架出现之前，我们就实现了自己的“样本程序”，实现标准MVC模式; 在界面、业务逻辑层、数据库持久层都实现了自己的标准。随着技术的发展，我们在各个层面都有着技术上的升级，但是由于平台的良好规划，技术的升级并没有带来平台的大规模变化，需要修改的只是各个层直接的接口和调用部分，实现了平滑的升级，业务逻辑组件没有受到影响，保证了长期积累的业务组件的稳定性。图1是我们的“样本程序”的层次结构。

图1 样本程序层次结构

Ajax的网页前端展现技术

回顾J2EE的技术发展历史，浏览器端的实现技术并没有太多本质性的变化，直到出现了Ajax，才使得这个局面有所转变。Ajax给程序提供了不更新整个页面而能维护数据的能力，使得Web应用可以更加迅速地对用户的输入进行响应。在样本程序中，基于Ajax技术的原理，实现了中心服务器架构。我们将表现层、业务逻辑及数据层放在服务器，浏览器仅有使用者接口引擎。浏览器的使用者接口引擎仅用于反映服务器的表现层以及传达使用者的输入回到服务器的表现层。由浏览器所触发之事件亦送回服务器处理，根据业务逻辑来更新表现层，然后反映回浏览器。因为所有应用程序完全在服务器执行，数据及表现层都可直接存取，程序员只需使用服务器端相对较成熟的Java语言即可，无需再学习过多的JavaScript、DOM、CSS等。

前后台统一的校验功能

在样本程序中，通过一个数据校验处理程序以及每个页面所对应的校验配置文件，可以实现在网页前台和后台业务处理程序中的统一数据检验功能。

类Hibernate的持久化

Hibernate是Java应用与关系数据库之间的桥梁，它负责Java对象与关系数据之间的映射。Hibernate使Java开发人员从直接的数据库操作中解脱出来，可以将精力集中于业务逻辑的处理。样本程序对Hibernate进行了适当的改造，形成了有自己特色的持久层。

Hibernate使用映射文件来完成Java对象与关系数据之间的映射。但是，对于有上千数据表的保险行业的应用系统来说，映射文件的方式不仅不易于管理，在效率上也会有所影响。样本程序中实现的持久层，使用直接编码的方式，通过自动生成程序，将每一个数据表所需要数据操作的相关SQL语句直接生成，以期获得最高的效率。同时，由于保险行业业务系统的特点，一个数据表将可能会与许多数据表发生联系，但是，在一个具体的业务处理过程中，真正需要关注的只是少数的几个关联。因此，样本程序也选择不在数据持久层完成关系的映射，而是由开发人员在实现业务逻辑的时候，有选择地进行数据对象的关联。

缓存也是数据持久层不得不考虑的问题，Hibernate提供了事务范围、进程范围以及集群范围的缓存。集群范围的缓存太过复杂，而且最终的访问速度也不一定会比直接访问数据库快多少; 进程范围的缓存带来的是缓存并发访问的问题，需要谨慎地考虑加入到缓存中的数据; 事务范围的缓存最终的效果取决于缓存的命中率。对于保险业务系统来说，在大部分业务处理过程中，在开始阶段取得数据对象之后，不再会重复地查询这些数据对象。而对于类似于日终批处理这样的业务，才有缓存数据的要求，而且，所缓存的大多数是描述性的信息。所以，在样本程序中，实现了只读数据对象的全局缓存，针对于特定要求的业务逻辑，实现了事务范围的缓存。另外，在样本程序中，也抛弃了HSQL语言，从而使得整体框架更为轻量级，调试和开发更为高效。

类Spring的AOP

Spring的AOP处理提供了四种处理切入类型: around、before、after以及instruction。样本程序主要是通过around切入类型来实现容器的事务管理，通过利用工厂模式，将规范化的业务处理接口松散地耦合在一起，从而使业务系统的处理核心可以更加方便地重新组合，也就更加能够适应日新月异的保险系统的业务需求。

除了在每个层面使用合适的技术外，我们还必须考虑如何保证项目开发人员能够将精力集中在业务逻辑的实现上。J2EE应用服务器给程序开发提供了各个功能强大的接口与服务，如数据库连接池、安全服务等，这无疑是给应用程序开发者提供了很多的便利。但没过多久，程序开发者们就发现他们不得不面对数量繁多的配置文件和配置项，更不用说程序为了符合规范所必须实现的接口。如果读者有在EJB 2.0规范下开发程序的经验，就可以知道开发人员需要花多大的精力在EJB接口的定义和实现上，更不用说花费在EJB测试、上的精力了。

在我们实现的样本程序框架中，从前台的界面，到中间层的BLF，到数据持久层的持久化对象，对于一个中等规模的保险业务系统来说，所需要的代码量也是惊人的。

所以我们自己编写很多工具来完成“代码自动生成”，最典型的例子是从数据模型直接生成最终的程序代码。PowerDesigner无疑是最好的建模工具。PowerDesigner可以将模型信息存储成XML格式的文件，这样就为开发自动生成工具提供了很大的便利。设计人员在PowerDesigner中设计出系统的O/R模型之后，代码生成工具根据PDM中的相关信息，将访问相关的数据库表的对象自动生成。更进一步，对于单表的增加、删除、修改以及查询等功能，我们也可以通过自动生成工具来生成。

这样，大部分通用的代码和接口代码采取自动生成的发放，开发人员不需要关心具体的技术细节，如界面如何实现校验，业务逻辑中如何跟数据库交互，事务该如何控制等，他们想的更多的是界面如何优化使客户体验更好，业务逻辑如何实现效率更加高效。而且，当每个层面的技术实现发生变化的时候，只需要修改这些通用的生成程序即可。如当界面与应用服务器交互改用AJAX的时候，普通的开发人员的编程方式没有发生任何变化，当持久层的技术改用EJB或者Hibernate的时候，业务逻辑的实现也不会收到任何影响。

样本程序的组成

由于国内保险IT环境的特殊性，每个客户都要需要有自己独特的经营思想或者特点来保证他们的公司在激励的竞争中存活下来并脱颖而出，所以对系统通常也有自己特殊的要求，以致市面上没有一个产品能够同时满足这些风格各异的需求，我们必须采取平台加客户化定制的方式来尽快搭建系统。但是一个强大的平台，一些先进的技术远远不足以应对快速发展的市场所带来的这些挑战，我们需要有一套完整的“样本程序”来保证组件被正确而快速的组装，以应对客户提出的更高要求。

“样本程序”的首要作要是起到“样本”的作用，但是要起到良好的“样本”作用，几个类似于编程语言帮助手册中的例子程序是远远不够的。“样本程序”是一套机制，包括一系列的标准、文档、程序、规范和保证规范执行的制度，主要有以下几个部分组成:

1． 编程规范: 包括数据字典、界面规范、编程语言规范等，这些文档保证了在基于一个平台的多项目实施的过程中基本的标准。

2． 组件说明: 在整个保险业务平台中，包含了很多长期积累的横向组件，如界面校验组件、通用查询组件、打印组件、工作流组件、规则引擎组件等，还包括一些程序的生成工具等，这些文档按组件划分，从横向具体说明各个组件的详细用法。

2004年年底，监管部门开放了外资保险公司在国内进行团险业务的控制，所有保险公司都在同一起跑线上开始了竞争。此时，恰好也是我们进行系统平台升级的关键时刻，如何保证技术平台升级时原有业务功能能够保持稳定，同时加快适应新的需求，是我们必须面对的问题。而正是因为有了“样板程序”，使得我们在应对传统看来难度巨大的项目时得心应手。

3． 样本程序: 我们通过一个寿险行业的完整的业务场景，实现了一个完整的业务流程，我们将其中涉及到的功能分为若干的场景: 简单查询、复杂查询、打印、复杂业务逻辑保存、批量处理等，我们在每个不同的场景里详细地描述了这些场景中所用到的组件的方法，详细地说明了组件组装的约定和约束、组装的风格选择、组装中的注意事项、组装中的分情形变化等。我们认为，系统所需要的新功能必然可以分解为一个或者多个这样的场景，那么当需要开发新的功能的时候，开发人员只需要按照这些场景中所阐述的组件的组装方法将平台中的组件组装在一起，就能按照标准实现业务功能。在独立地描述每个场景功能的同时，针对保险行业流程复杂的特点，我们在样本程序里还着重描述了如何实现工作流的规划和运用工作流引擎实现。这样，除了组件的组装，在业务流程的实现上，不同的项目组也有了同样的“标杆”可以模仿。

4． 开发手册: 它是系统开发环境、数据库配置、应用服务器配置等的说明。每个项目组的使用的环境、数据库、应用服务器、配置管理方法等根据客户的关系虽然都有可能不同，但是所有的项目组的开发手册都遵循统一的标准进行编写，任何一个开发人员都能很快地融入开发团队，这对于一个通常上线周期只有2～3个月，但是涉及到众多功能，需要频繁的人力资源调配的项目来说是至关重要的。

5． 编程指南: 通常一个传统的项目中或多或少都有上面的各种文档，零散的存放于各个目录，这样就很难起到他们应该起的作用，我们通过“编程指南”，通过讲解整个“样本程序”的各个场景之间的联系，将各种规范、标准都有机地串连在一起，形成了一个开发人员在开发过程中的“功能分解场景查找样本场景抄样本程序发现样本程序中提到的规范遵循规范”的良性过程。

快速搭建应用

程序组装应该面对领域模型，既开发人员关注的应该是行业内的业务逻辑实现。我们的平台集成了保险行业领域系统开发所需要用到的几乎所有横向组件和绝大部分业务对象，通过“样本程序”，很好地指导了不同的项目在统一技术标准上的实施，针对不同的客户需求，从平台中选择合适的横向组件和业务组件进行组装，而这些组件都是经过长期验证的高可靠性的模块，这样就能最大程度地保证快速搭建的系统的可靠性。由于样本程序的指导性，使得我们的项目经理和程序员都能将大部分精力放在研究客户需求，满足业务逻辑上，而不用每天为技术问题焦头烂额，我们将横向组件的维护升级，业务组件的设计都进行了统一个管理，这样我们不仅在程序框架上做到了业务逻辑与界面的分离，还可以说我们还在整个组织中做到了“组件”和“组装”的分离，我们的员工能专注于保险行业领域的业务实现，使得他们能很快成长为行业专家，他们总是能够高质量、高效率地满足各个保险公司不同的但又随时变化的需求，有着良好的口碑。

通过“样本程序”的规划，我们将行业软件开发中的“组件”和“组装”分离开来，也使得我们对“组件”能有一个良好的规划。通常一个平台在面对多个项目实施的情况下，如何保证组件的统一性是一个巨大的问题，外国公司在面对这种情况时，通常采用“保守疗法”，即国内的实施团队没有权限修改组件，需要上报到国外开发中心经过层层论证、审批，最后统一修改，周期长达数周，这样虽然保证了稳定性和统一性，但是项目进度严重受到影响。我们的多个项目统一按照“样本程序”的规范进行组件的组装，虽然组装的具体方法可能略有差异，但是都能保证程序的质量和可靠性，我们会定期从不同的项目中挑选“组装”得优秀的组件，成为“样本”。同时，我们严格把握了新的“组装”模式的出现，保证新的组件能够成为新的“样本”。这样随着项目的不断发展，我们的“组件”在增长的同时，我们的“样本程序”也在不断地完善，范围也越来越大，越来越多的开发人员能从“样本程序”中获益，在项目数量、项目规模急速膨胀的时候，我们也保证了快速建设的系统在性能、扩展、安全、可监控、利于重构、兼容性等各个方面都处于一个良好的水平。

链接一:保险应用高要求

随着中国保险业在金融领域首先对外开放，中国保险业正呈现爆炸式增长的态势。据中国保监会统计，截至2005年底，中国共有保险公司82家，集团6家，资产管理公司5家，保险法人机构93家。仅在2004年7月底，就一次性审批获准筹建的中资保险公司达18家。外资保险公司也纷纷进入中国抢占这块广大的市场。保险市场的竞争日趋激烈，在保险产品同质化严重的情况下，保险公司越来越希望通过流程的创新、服务的创新在市场中取得立足之地。同时中国保监会规定，凡是在中国内地开展经营的保险公司，必须通过核心业务系统的验收，所以以核心业务系统为基础的IT系统已经成为了公司赖以生存的基础。保险公司也对IT系统从各方面提出了更高的要求。保险行业不同于银行的结算模式，其涉及的环节众多且处理周期漫长，决定了保险公司业务系统的复杂与多变; 同时由于国内保险行业的经营还在规范的过程中，所以保险公司的业务流程也处于不断变化和磨合的过程中，IT系统需要不断地适应变化; 同样作为金融企业，保险公司由于竞争更加残酷和激烈，保险公司相对于银行更愿意使用新的技术来建设IT系统，但是由于市场的激烈竞争，不管是新系统上线还是老旧系统升级，保险公司都要求在极短的时间内上线，满足业务运营的要求。

链接二:应用效果

正是因为有了“样本程序”，使得我们在应对传统看来难度巨大的项目时得心应手。2004年年底，监管部门开放了外资保险公司在国内进行团险业务的控制，所有保险公司都在同一起跑线上开始了竞争。此时，恰好也是我们进行系统平台升级的关键时刻，如何保证技术平台升级时原有业务功能能够保持稳定，同时加快适应新的需求，是我们必须面对的问题。我们曾经用“样本程序”来指导项目的实施，屏蔽了新的技术和框架，新的业务逻辑带来的学习的成本，通过我们跟客户的紧密合作，我们在短短两个月内完成了系统平台的升级，并顺利通过了保监会的验收，卖出了“外资团险第一单”。

2005年，一家有近十年历史的大型保险公司客户与我们合作进行保险核心业务系统的建设。由于来自业务快速发展的压力，这项涉及到全国几十家分公司原有分散系统和近千万历史数据的巨大工程必须尽快完成，对于传统的项目实施方法几乎是不可能完成的任务。通过“样本程序”，我们很快开发出了系统原型，跟客户清晰地沟通了需求。同时，通过“样本程序”的指导，我们和客户的几十人的开发团队能够以同样的速度和质量进行开发，保证了甲方投入人员的有效性。通过双方半年的共同合作，系统就成功上线了，保证了系统的顺利切换，并在后续的实际运行中获得了良好的效果。

随着保险行业的发展，我们的项目实施经验在不断地成长，我们的系统平台也在不断地升级，更重要的是我们的“样本程序”也得以不断完善，新的技术在不断加入，组件的划分在不断优化，组装的指导性也在不断加强。