【Jsp精品源码栏目提醒】:网学会员,鉴于大家对Jsp精品源码十分关注,论文会员在此为大家搜集整理了“网上车险理赔系统 - 计算机理论”一文,供大家参考学习!
目 录第一章 前言.................................................. 11.1 开发背景 ................................................. 11.2《网上车险理赔系统》运行效果.............................. 11.3 本文工作 ................................................. 2第二章 基本原理与方法技术.................................... 32.1 开发需求................................................. 32.2 设计中的需要考虑的问题 ................................... 5 2.3.1 传统两层客户机/服务器模式特点 ...................... 6 2.3.2 三层客户机/服务器模式 .............................. 6 2.3.3 三层体系结构与两层结构的对比....................... 82.4 J2EE 标准简介 .......................................... 10 2.4.1 j2ee 模型 ......................................... 10 2.4.2 EJB 简介 .......................................... 11第三章 总体设计及架构....................................... 123.1 整体架构 ................................................ 12 3.1.1 表示层 ............................................ 13 客户端.................................................. 13 服务器端................................................ 13 负载均衡方案............................................ 13 3.1.2 逻辑层:应用服务器集群 ............................ 16 3.1.3 数据层:中心数据库系统 ............................ 18 3.1.4 解决与数据库连接瓶颈问题.......................... 183.2 系统的菜单结构和基本功能说明 ............................ 22第四章 系统实现............................................. 244.1 以报案平台为例描述系统的实现过程 ........................ 24 4.1.1 EJB 技术 .......................................... 24 4.1.2 具体实现过程 ...................................... 264.2 报案子系统框架 .......................................... 32结束语...................................................... 38参考文献.................................................... 39致谢........................................................ 40 第一章 前言1.1 开发背景 随着中国加入 WTO,外国保险公司和保险机构逐步进入中国市场,保险公司间竞争更加激烈。
这种情况下,坚守诚信原则、提高服务质量成为各家公司主要经营理念。
而在各项服务中,客户最为看重的首先是保险公司的理赔速度和服务质量。
先进的保险公司争先利用现代高科技网络和技术是把所有理赔流程都通过网络实现。
使客户出险时在现场一个电话报案,就可即时得到保险公司查勘、定损、立案、理赔等全程服务。
平安产险 1998 年已经开发了车险承保、理赔程序,但由于当时技术和资金原因,它是两层 C/S 模式,只是实现了保险公司内各环节工作的电脑管理。
虽然没有引入远程定损、客户自动查询等新概念,但通过开发这套系统,我们明确车险业务的复杂程度,以及实现管理的数据流。
为未来面向对象开发,规划和定义类模型提供了可贵的开发经验。
网络技术迅猛发展、电子商务技术日趋成熟,这些条件为实现车险网上理赔提供了有利的客观条件。
2001 年平安产险为提高公司竞争实力,超前提出将所有理赔流程在 Internet 网上做让客户得到最快的理赔服务。
我们与易保公司合作,易保利用其组建网站的成熟经验,为我们集成系统提供了有利的支持。
同时,针对车险承保、理赔的特点,我们遵循 J2EE 标准,选用 BEA Weblogic 服务器,采用
JSP 方式,使用 EJB 组件实现业务逻辑,把构件模型扩展到网络环境。
1.2《网上车险理赔系统》运行效果 该系统是在 Internet 基础上开发的与保险公司车辆保险业务系统连接的网络系统,它实现了车险案件的报案、查勘定损、核损、立案、缮制、核赔、结案等操作。
这个系统的运行大幅度加快理赔速度,特别是小额案件的处理速 1度,就以北京分公司为例,在使用前车险及时立案率为 89.48%,使用后车险及时立案率为 93.11%。
另外,在使用该系统前,车险案件平均每人每日查勘 5.5 个案件,使用后提高到 9 个案件,增长 63.6%,明显提高了理赔效率;使用网上车险理赔系统后,小额车损案件(含第三者车损、玻璃破碎险、自燃险、新增设备损失险)立案、缮制等均由电脑自动完成,加大理赔工具的技术含量;使用网上车险理赔系统后,提高了理赔透明度及理赔控管的时效性。
一方面,车险理赔过程均为在线操作、完全透明,管理人员能及时发现、解决各环节中的问题。
如查勘定损,就实现了在线、实时复勘,能及时纠正外勤人员的定损偏差,理赔准确性得以大幅度的提高,更加为客户负责。
另一方面,能及时提示每个客户出险次数、查阅以往出险信息,能及时识破重复报案等保险诈骗行为,使公司的监督环节更加完善1.3 本文工作 本文介绍了网上车险理赔系统的总体设计和系统部分实现。
宏观上,本文共分为三部分: 第一部分:介绍了系统中使用的一些基本原理与方法; 第二部分:介绍总体架构。
深入剖析集成系统时的技术难点。
第三部分:以报案子系统为例,讲述系统的实现过程。
2 第二章 基本原理与方法技术2.1 开发需求 车险理赔流程图 系统由报案、查勘、核损、立案、缮制、核赔、结案、管理、系统管理 8个子系统组成,完成机动车辆保险理赔的全过程。
承保车辆出险后向有关部门报案,报案子系统记录下车辆的基本信息,生成报案号,并指示被保险车辆到附近的修理点进行查勘;查勘人员将需要修理和更换的项目录入查勘子系统系 3统,并提出相应的报价,再用数码相机拍摄车损部位,通过系统上传至定损中心;定损中心使用核损子系统查看车辆受损情况,核定更换、修理项目,对查勘点的报价给出核损意见,将案子回复到查勘点,查勘点再作出回复,以次往复,直到双方达成一致;案件经由立案平台,生成赔案号,由缮制部门进行缮制处理;核损平台再对案件进行核损,给出核损意见,最终结案;至此完成了案件的定损过程。
管理人员可以通过管理平台查看每个案件的处理过程,并对工作人员的业绩进行评估。
42.2 设计中的需要考虑的问题 网上车险理赔业务对系统的可靠性、可访问性、安全性都有很严格的要求每个处理节点都应具有极高可靠性和安全性的系统,具有高度冗余度,能独立完成所有系统功能。
车险理赔的报案、查勘定损、立案、缮制、核赔、结案等所有流程都在网上做,数据量庞大,数据之间关联复杂,要求系统具有强大的处理能力和快捷的响应速度。
要做到全国数据集中,数据库处理能力、以及数据库与应用服务器的无阻塞连接也是必须考虑的问题。
初步测算系统的运营压力为:每年 150 万个案件,需要 7800K 的网络带宽,每年的数据量约为 800G。
如果突破 150 万,增加 1 台 Web 服务器和 1 台应用服务器(约 50 万)并根据情况适当升级数据库(约 3040 万),加上相应的系统软件成本(4 个 WebLogic License),约 9 万 US,可以将年案件处理能力增加 4050 万。
系统开发后,应该便于改造和升级以迅速适应车险业务规定变化的要求。
52.3 客户/服务器模型2.3.1 传统两层客户机/服务器模式特点 应用程序从结构上一般分为四层:形式逻辑、业务逻辑、数据逻辑和数据存储。
而 所有的形式逻辑和业务逻辑均驻留在 Client 端, Server 则成为数据库服务器,负责各种数据的处理和维护。
这种模式需要在客户端运行庞大的应用程序,它多是基于局域网范围内进行的(比如在九十年代非常流行的一些基于数据库的信息系统就是根据这种模式构建的)。
随着 C/S 结构应用范围的不断扩大和计算机网络技术的发展,这种结构带来的问题日益明显,主要表现在以下几方面: a.系统的可靠性有所降低。
一个客户机/服务器系统是由各自独立开发、制造和管理的各种硬件和软件的混合体,其内在的可靠性不如单一的、中央管理的大型机或小型机,出现问题时,很难立即获得技术支持和帮助。
b.维护费用较高。
尽管这种应用模式在某种程度上提高了生产效率,由于客户端需要安装庞大而复杂的应用程序,当网络用户的规模达到一定的数量之后,系统的维护量急剧增加,因而维护应用系统变得十分困难。
c.系统资源的浪费。
随着客户端的规模越来越大,对客户机资源的要求也越来越高。
尽管硬件不断更新,但新的操作系统和新的应用软件的不断出现,使得用户对硬件的更新仍然跟不上软件更新的速度。
客户不得不在本地硬盘上装入大量的软件。
d.系统缺乏灵活性。
客户机/服务器需要对每一应用独立地开发应用程序,消耗了大量的资源,。
在向广域网扩充(如 Internet)的过程中,由于信息量的迅速增大,专用的客户端已经无法满足多功能的需求。
网络计算模式从两层模式扩展到 3 层模式,并且结合动态计算,解决了这一问题。
2.3.2 三层客户机/服务器模式 第一层:表示逻辑客户层。
它的主要功能是实现用户交互和数据表示,为以后的处理收集数据,向第二层的业务逻辑请求调用核心服务处理,并显示处理结果。
6 第二层:业务逻辑服务器组件。
这些组件由中间件管理,实现核心业务逻辑服务并将这些服务按名字广播、管理并接受客户的服务请求,向资源管理器提交数据操作,并将处理结果返回给请求者—客户或其他服务器。
第三层:数据资源管理器构成。
比如关系数据库,负责管理应用系统的数据资源,完成数据操作。
服务器组件在完成服务的过程中通过资源管理器存取它管理的数据,或者说请求资源管理器的数据服务。
在三层模式中应用服务器将整个应用逻辑驻留其上,而只有表示层存在于客户机上。
这种结构中,无论是应用的 HTML 页还是 Java Applet 都是运行时刻动态下载的,只需随机地增加中间层的服务 应用服务器,即可满足扩充系统的需要。
由此可以用较少的资源建立起具有很强伸缩性的系统。
这种模型实际上是基于全球网络范围内进行的,客户端统一的以浏览器的形式表现给用户,用户通过 HTTP 协议把任务提交给 Web 服务器,Web 服务器通过和数据库和应用服务器的交互把结果通过 HTTP 协议传递给客户端,然后客户端再通过浏览器显示结果。
在这种模式下的关键是数据传递的安全性和事务性这两个问题,因为 HTTP 本质是是一个无状态的连接,所以事务处理就变得非常重要,同时因为整个业务是基于全球网络体系结构的,所以安全性也变成一个值得关注的问题。
在三层结构中,中间件 Middleware 是最重要的部件。
所谓中间件是一个用 API 定义的软件层是具有强大通信能力和良好可扩展性的分布式软件管理框架。
它的功能是在客户机和服务器或者服务器和服务器之间传送数据,实现客户机群和服务器群之间的通信。
其工作流程是:在客户机里的应用程序需要驻留网络上某个服务器的数据或服务时,搜索此数据的 C/S 应用程序需访问中间件系统。
该系统将查找数据源或服务,并在发送应用程序请求后重新打包响应将其传送回应用程序。
随着网络计算模式的发展,中间件日益成为软件领域的新的热点。
中间件在整个分布式系统中起数据总线的作用,各种异构系统通过中间件有机地结合成一个整体。
每个 C/S 环境,从最小的 LAN 环境到超级网络环境都使用某种形式的中间件。
无论客户机何时给服务器发送请求, 7也无论它何时应用存取数据库文件,都有某种形式的中间件传递 C/S 链路,用以消除通信协议、数据库查询语言、应用逻辑与操作系统之间潜在的不兼容问题。
在数据库和客户之间增加应用服务器后,数据采集、传输、存储、发布、访问等都由中间件来做。
2.3.3 三层体系结构与两层结构的对比 三层体系结构是目前技术发展的一个潮流,它与传统的两层结构(客 户机/服务器C/S)相比,尤其是在处理大规模的业务上具有无可比拟的优 势。
以下对三层体系结构与两层结构做一对比: 8 两层结构 三层体系结构 客户端的负载 所有的业务逻辑都必须 可以将部分或全 安装在客户端,客户端必须 部的业务逻辑控制安 有足够的能力对这些工作进 装在应用服务器上,以 行处理,使客户端过于庞大, 减低客户端的负载。
负载重,效率低 对数据库服务器的 每个客户端都必须和数 只有应用服务器性能的影响 据库直接相连,而每一个连 和数据库直接相连,由 接,都会占用数据库的资源, 应用服务器处理客户 加重数据库的负载,如果连 端对数据库的连接请 接数目太多,就有可能使数 求,降低了对数据库资 据库的性能急剧下降,甚至 源的占用 会导致数据库的崩溃。
网络流量和负载 客户端直接使用 SQL 语 数据以交易包的 句访问后台数据库,网络流 形式传输,网络流量 量较大 小,同时客户端可以共 享应用服务器中的公 共数据(如数据字典 等),节省带宽,提高 了反应速度。
系统结构及工作量 客户端直接连接后台数 结构较复杂,编程 据库,结构简单。
编程简单, 的工作量和难度较大。
工作量较小 92.4 J2EE 标准简介2.4.1 j2ee 模型 SUN 定义了 j2ee 标准来简化 n 层企业级应用开发。
它定义了一套标准化的组件,并为这些组件提供了完整的服务。
J2ee 还自动为应用程序处理了很多细节如安全、多线程等。
J2ee 提供了一个多层结构的分布式的应用程序模型,该模型具有重用组件的能力、基于扩展标记语言的数据交换、统一的安全模式和灵活的事物控制。
多层开发可以使企业级应用具有很强的伸缩性,它允许每层专注于特定的角色。
例如:让 web 服务器负责提供页面,应用服务器处理应用逻辑,数据库服务器提供数据库服务。
J2EE 平台由一整套服务、应用程序接口和协议构成,它对开发基于web 的多层应用提供了功能支持。
J2ee 中包括以下 13 种核心技术: Enterprise JavaBeans EJB 技术 Java Interface Definition Language IDL Java Message Service JMS API Java Naming and Directory Interface JNDI Java Remote Method Invocation RMI 和 Object Serialization Java Servlet API Java Transaction API JTA Java Transaction Service JTS JavaServer Pages
JSP 技术 JDBC 数据库访问 API Extensible Markup LanguageXML Javabean Activation FrameworkJAF JavaMail 用来访问邮件服务器的 API。
BEA 公司通过其 WebLogic 服务器为整个 j2ee 规范提供了一个较为完整 10的实现。
它使建立和部署分布式应用的过程大为简化。
2.4.2 EJB 简介 在 J2EE 规范中,有一个重要的层次 EJBEnterprise JavaBeans这一名词利用了 java bean—这种可移植、可重用的 java 软件组件的声望,这一技术主要应用在企业逻辑的实现上。
Ejb 技术把 java 组件的概念从客户机域扩展到了服务器域,使 java 技术发展成为一种强健的、可伸缩的环境,能够支持以任务为关键的企业信息系统。
从概念上看,EJB 对象封装了业务对象及其概念,让开发人员把精力集中于解决方案的细节之上。
从设计的角度看,EJB应该轻便而相互影响地合并起来。
这一举措可以令单一的 EJB,不论其是否为商务应用程序都可能采用一个 EJB 代表自主开发还是第 3 方厂商开发却都能用于多种应用程序。
EJB 体系结构使编写应用程序变得容易:应用程序开发人员不必了解低层次的事务和状态管理的细节、多线程、资源共享和其他复杂的低级 API。
但是,允许专家级的程序员直接访问低级 API。
EJB 应用程序遵循 Java 编程语言的“一次编写,随处运行”的原则。
EJB 组件可以只开发一次,然后在多个平台上部署,而不需要重新编译或修改源代码。
11 第三章 总体设计及架构3.1 整体架构 服务站客 服务站客 户 户 Internet 防火墙 Web Server 负载平衡 Farm Web服务器 Web服务器 应用服务器聚簇 Application Application Server Server 数据库 HA结构 DB Server DB Server 或 聚簇 磁盘阵列 数据存储 12 整个系统具有明显的三层体系结构的特征,采用 Java 语言开发,具有很强的跨平台能力,同时有很强的可扩充性:可以在 2—3 台单 CPU 的 PC 服务器组成的小型应用环境中使用,也可以在包括 IBM 大型机、高端小型机的大型计算机中心运行。
以下是按层次描述各层次:3.1.1 表示层客户端 使用本系统的每个服务站只需要配置一台能够联入 Internet 的 IBM 兼容微机.若服务点业务量不大,可以采用 56K Modem,否则申请 128K ISDN,对大型服务点,采用 256K 以上的 Internet 连接。
服务器端 Web Server 集群由负载均衡设备和多台 Web Server 组成。
由于系统的主要功能均在逻辑层完成,因此表示层的负载相对较低,采用Apache 1.3.9,有效降低整个系统的成本。
整个 Web Server 集群的关键设备是负载均衡设备。
在该系统中,通过采用 Alteon 的第四层交换机来实现 WebServer 的负载均衡。
负载均衡方案 负载均衡建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
负载均衡技术有多种分类 : 软/硬件负载均衡 软件负载均衡解决方案是指在一台或多台服务器相应的操作系统上安装一个或多个附加软件来实现负载均衡,如 DNS Load Balance,CheckPoint 13Firewall-1 ConnectControl 等,它的优点是基于特定环境,配置简单,使用灵活,成本低廉,可以满足一般的负载均衡需求。
软件解决方案缺点也较多,因为每台服务器上安装额外的软件运行会消耗系统不定量的资源,越是功能强大的模块,消耗得越多,所以当连接请求特别大的时候,软件本身会成为服务器工作成败的一个关键;软件可扩展性并不是很好,受到操作系统的限制;由于操作系统本身的 Bug,往往会引起安全问题 硬件负载均衡解决方案是直接在服务器和外部网络间安装负载均衡设备,这种设备我们通常称之为负载均衡器,由于专门的设备完成专门的任务,独立于操作系统,整体性能得到大量提高,加上多样化的负载均衡策略,智能化的流量管理,可达到最佳的负载均衡需求。
一般而言,硬件负载均衡在功能、性能上优于软件方式,不过成本昂贵。
本地/全局负载均衡 本地负载均衡是指对本地的服务器群做负载均衡,全局负载均衡是指对分别放置在不同的地理位置、有不同网络结构的服务器群间作负载均衡。
本地负载均衡能有效地解决数据流量过大、网络负荷过重的问题,并且不需花费昂贵开支购置性能卓越的服务器,充分利用现有设备,避免服务器单点故障造成数据流量的损失。
其有灵活多样.