基于SOA框架的银行档案管理系统的制作方法

本发明涉及软件开发技术领域，尤其涉及基于soa框架的银行档案管理系统。

背景技术：

国内银行的档案管理系统伴随着近十年银行信息化的建设初步实现了信息化：一方面对各营业网点业务系统产生的业务数据实现了电子化存储，并建立了总分支三大阶层之间的信息共享机制；另一方面对柜台业务产生的原始票据、会计凭证、客户服务影像也逐步向电子化方向发展。

目前我行现有电子档案系统涵盖了个人银行部电子档案系统，统一会计档案管理系统，资金后台集中业务管理系统，人行支票交换影像系统和信用卡gui系统，以ecm(enterprisecontentmanagement)为体系架构统一的ecm核心功能以及统一的ecm技术标准^[1]。提供了搜索引擎服务(包括文档。图片和视频影像等)，借助该系统建立了全行档案管理平台，能够有效分类存储各个系统的非结构化数据且提供针对内容的特定服务，但我行所有应用系统都与档案平台通过api集成，业务关联度较高档案平台与应用系统之间的非结构化数据标识、访问策略不够明确和统一；平台本身非结构化数据与应用流程合理结合的应用框架不完善；平台管理的基础管理与档案管理功能界定不够明确。但随着银行总行及分支行层面的应用内容管理需求量增长，需要一个快速的访问协议通道来获得emc的数据，需要专业要求高的一个客户端来提高员工体验度。在总分行管理层面，目前emc领域仅仅仅局限于单个系统针对性的功能支持，需要对管理的非结构化数据的集成、挖掘和高级应用用进行开发研究，拓展其在全行的应用领域方面，提升数据的价值应用；在支行层面，一些网点的需求目前还无法提供，也无法向分行提供更简便易用的应用接口去开发。这都需要通过实施emc客户端来将应用拓展，通过利用现有的web框架技术实现soa与多种框架集成，根据当前管理系统结构，细分出子系统，实现了各种系统模块功能，再结合系统权限审批工作流控制，将银行档案管理系统能更稳定、快捷、安全。

银行档案管理系统就是基于以上原因以业务资料管理子系统之间集成共享、结构化数据和数据内容相互分离及高效的搜索查询和保存管理为目标进行设计和实现的。首先进行了银行档案管理系统的可行性分析，查出原先应用系统和档案管理系统接口的不集成，系统功能模块的实现化、权限审批流程的复杂化等一系列需求。基于需求的考虑，设计了一个基于soa构架子系统之间集成共享、结构化数据和数据内容相互分离及高效的搜索查询和保存管理为目标的银行档案管理系统。

soa参考模型由三个角色构成：服务注册中心、服务使用者、服务提供者，三者之间通过查找服务、发布服务、绑定与调用操作进行相互实现与执行。服务使用者是服务的请求者，它发起对服务注册中心的查询服务需求间接获得得服务描述，然后遵从服务描述的接口和地址按照约定和服务提供者进行绑定与调用的服务。

服务注册中心是一个服务中介，它将从服务提供者的逻辑名称映射到提供程序的地址，从而为服务提供者发布的服务进行维护与保管。服务注册中心提供服务的注册、查找与定位。在本文第五章节中，将基于银行档案管理系统建立一个该系统的服务总线esb承担了服务注册中心所有的职责。

服务提供者是服务的拥有者，它是一个实现服务接口的软件实体，接收和执行来自服务使用者的请求，并提供相关服务功能、接口和参数的描述到服务注册中心，以便服务使用者发现并使用该服务。

发布服务是指服务提供者将描述信息发布到服务注册中心，只有这样才可以被用户发现并使用该服务。在发布的操作中，若服务提供者需要进行发布信息的修改，需通过服务注册中心身份验证，才能进行描述信息修改。

查找服务是指服务使用者通过服务注册中心查找自己所需服务，服务使用者的新需求如何能被服务提供者发现，这需要服务注册中心的接口来接收来自服务使用者的请求。在查找操作中，一般分为两类，一类为宽泛查找，既服务使用者通过国际通用的行业标准分类来查询比较宽泛的关键字，并逐步缩小范围，知道需求得以满足；另一类是通过关键字的唯一性来得到请求信息，且结果也是唯一的。

绑定与调用是指服务提供者将服务描述返回给服务使用者，并生成服务代理，建立服务使用者与提供者的通讯渠道，使用者根据从服务注册中心得到的绑定信息，包含服务调用参数、访问路径、传输协议、调用结果等，从而实现服务的远程调用。

由于数据库在与业务逻辑层在互相交换的过程中多次需要进一步封装数据库从而调用接口。因此增加数据持久层到数据库和业务逻辑层之间。读取隐藏数据和所有操纵中的数据访问代码细节，完全抽象出开发应用程序时使用的数据物理细节。

需求分析是每个系统开发技术人员工作中最重要的面对环节之一，是支撑于系统开发分析和软件设计分析之间的重要桥梁，它侧重于从整个业务需求的过程角度进行分析，主要内容包括数据挖掘需求和业务流程的需求，业务流程和实现功能管理之间的关系。其工作质量是整个开发工作的成败来说是决定性的。

银行档案管理系统是针对行内员工业务需求来设计的，系统主要是将已有纸质实物档案进行系统定位的同时，将现有的电子档案(所有业务部门产生的资料、账务等)集合成一个新的平台(ecm)，从而方便行内员工进行调阅、汇总数据等多重功能。

综上所述，针对现有技术存在的缺陷，特别需要基于soa框架的银行档案管理系统，以解决现有技术的不足。

技术实现要素：

本发明的目的是提供基于soa框架的银行档案管理系统，便于对银行档案进行管理，自动化程度优。

本发明为解决其技术问题所采用的技术方案是，

基于soa框架的银行档案管理系统，该系统包括有模块集成单元、档案管理子系统、业务资料管理子系统、数据存储与查询单元，权限管理单元；

模块集成单元包括有归档服务模块、报表服务模块、定制查询模块、实物管理模块、电子档案查询模块、服务定位模块、检索服务模块、系统管理模块：

归档服务模块：根据对私、对公客户在我行柜台开立的基本信息，主要包括客户户名、联系方式、账户性质、账户明细、公司印鉴信息、法人信息、营业执照等，对于已核销客户资料做好销户日期，统一将基本信息进行归档服务，以便后续查阅；

报表服务模块：根据记录网点、分行和总行形成的每日会计账务信息单元，在会计账务中的各职能部门工作成果的体现，如月、季、年的各条线的收入支出、存贷款发放、理财类产品、中行人行调拨等，在季度、年度工作总结会议或者金融产品结构调整新方向，都需要汇总各条线信息形成报表，管理系统需要查询后有生成关键信息报表的功能，对管理层决策产生帮助；

定制查询模块对信息筛选查询需求：系统需要实现查询符合特殊条件的信息：主要是能做到根据日期、金额、账户信息等类型的查询等；

实物管理模块是档案的入库指的是档案按照现有的业务资料分类进行系统配比后存放指定的位置，形成档案的记录，档案的出库则指的是档案期满指定时间进行统一销毁或者转移到其他的档案存储地，档案的借调，则是指用户档案管理系统中进行调阅权限的申请，系统去判别是否有该权限并进行答复，注明用户姓名，借阅时间等，最后档案的归还则至系统消记已借阅档案的记录；

系统管理模块：在银行档案管理系统中，系统管理模块首先涉及到第一个方面用户和用户权限管理，而不同的用户涉及到在档案管理系统中不同用户权限，因为每个条线涉及到的用户权限分类实在太多，展示了银行运营条线不同的用户的权限，在分行级别管理层就可以有权限对于自己条线员工的权限进行审批的权利，当用户发生新增或者修改时，用户的角色也就发生改变，如果存在用户角色进行删除，那用户的权限也就随即会进行注销，分行管理人员维护这些基本信息主要就是能够对上述信息进行新增、修改、查询和删除等功能，并且能够体现业务工作信息之间的逻辑关系，修改和删除建立在查询的功能之上，并只针对拥有权限的客户开放。

进一步，业务资料管理子系统提供对近期业务数据的查询搜素，而档案管理子系统则将业务资料子系统归档后的数据进行保存和存储，另一方面，档案管理子系统还提供了对实物档案的管理查询功能，业务资料管理子系统可以定期或者不定期的向档案管理子系统进行历史数据的迁移和归档；

业务资料管理系统涵盖了五大应用系统：个人银行部电子档案系统，统一会计档案管理系统，资金后台集中业务管理系统，人行支票交换影像系统和信用卡gui系统，如图子系统架构，这些系统所产生的业务数据需通过分流进入业务资料管理子系统，一些需要采集的信息通过扫描机录入内容，从而服务器进行存储，ecm服务主要体现在提供非结构化数据的存储和管理，但不保存业务元数据。

进一步，数据存储与查询单元对银行档案的数据长期安全的保存时开发这个系统最重要的一部分，是衡量设计一个系统成功的标准，这部分如果考虑不周全会导致查询效率的低下、系统负载的加重及网络资源严重被占用的后果，本系统的设计理念是基于考察银行档案的特点和机构组织结构方面的总结而形成的一个安全稳定、效率快捷、网络资源不被占用的银行档案管理系统；

由于银行档案的数据查询时间不是按时间平均分布的，越是临近查询日期的档案查询率越高，而在前一年的档案查询率明显不高，所以为了查询时间达到最短，本文提出以档案时间不同进行分类存储，查询频率高的档案存储到查询时间快捷的介质中，而查询频率低的银行档案分布在储存成本低、查询速度较慢的介质中去，所以查询的频率是使用何种存储方式的重要区分原因；

档案在线存储所考虑的问题是确保数据的响应快速，即存储效率的提高，其次才考虑到是存储成本，因为硬盘的速度响应以及数据读取的速度都比其他介质快很多，为此保证查询的快捷性与精确性，在行内业务发生一年的时间内，可以将数据存储在光纤磁盘阵中，这样可以保证对这些数据查询的高效率，在档案发生一年以后，查询频率呈下降趋势，此时的存储方式应该是在保证数据可搜查到的前提下，降低成本存储；

离线存储方式的重点是低存储成本与数据安全并存，因为当前的数据极少被用来查询，所以此阶段，选用一种既存储成本低廉和安全的介质是重要处理，现业务部门对于要历史影像能否进行离线光盘查询，对此本文建议先使用dvd光盘作为现阶段存储介质，考虑到它的容量很大(4g-9g)，并且存储成本相比其他介质很低，对存储环境的要求也相对较低；

系统对支持离线数据在数据刻录时，需要进行加密技术处理，经过科技人员加密的数据光盘在本行系统外都无法使用，只有在行系统内使用专用的客户端查询程序才可读取光盘，以次保证对离线光盘查询安全性考虑，如果光盘不需要加密，该系统在刻录时也需提供离线查询工具同步进行刻录在光盘上，以方便离线进行查询，具体到某一张存储光盘是否需要进行数据加密，都均可通过管理员操作系统参数配置来决定，离线存储的同时还要提供备份数据和发布光盘的功能，即在档案数据处于在线存储阶段内，都可将数据录入光盘，作为对在线数据存储的备份；另外，刻录好的光盘可以下发各分支行所，来满足各分支行所本地查询和存储的需求。

进一步，权限管理单元包含有员工权限、业务部门审批、档案管理部门审批这三大功能模块；

(1)权限发起：实现通过internet网页申报调阅非本条线报表，可以由分支行行员工通过身份证实名制在网上填写基本信息注册用户，信息通过审核后，即可填写档案管理平台权限审查表，提交后完成申报权限工作，网上提交申请表，由外网服务器获取申报数据；

(2)权限申报管理：对用户所申报权限进行核查，无权限资格提示报错；填报无误的权限转入内网服务器，等待下一步评审；

(3)权限审核管理：根据填报信息从基础数据库内调出相关设计部门完整信息，对申报权限进行分类，如运营报表、反洗钱核查信、信贷审核等等，不同的类型需要走不同的业务审批流程，如涉及面临人行检查等类似对外检查需调阅报表，同时按照其紧急程度进行分类；

(4)权限发放管理：这是流程的核心，在这一步主要将权限分配给各个分管部门审批，同时具有顺序和并行的工作模式，一般都将经历权限等级核查、制定审核时间表、权限发放，建立起银行档案管理系统后，将大大降低过程推进部门的人工工作量及减少纸质化，甚至能完全替代此项工作，做到各个流程的自动化，网络化，每个专项部门都只需要面对自己的职能界面即可，每一步审批完成后，管理系统都将自动分配下一步任务给相应的部门；

(5)审批流程检索：申报人和部门管理相关人员可以根据各自权限查询到权限审批所处的流程阶段及情况；

(6)权限结果反馈：由申报权限对方部门主管对发起人申报权限批示，如果不符合规章制度，将权限结果反馈给申报者；

(7)系统维护：系统维护人员定期备份数据库，对数据安全和人员权限进行管理。

本发明的优点在于，在各部门业务系统中，通过客户端api接口将业务id号传递给档案管理系统中，银行档案管理系统会根据用户业务产生的id号在数据库中查找影像数据并提取出来发送到部门权限所能查阅的系统中，该用户只需进行下载或者在线浏览方式显示出来，设计新颖，是一项很好的设计方案，很有市场推广前景。

附图说明

下面结合附图和具体实施方式来详细说明本发明：

图1是本发明档案管理系统结构图；

图2是本发明子系统架构划分图；

图3是本发明权限系统功能结构图；

图4是本发明银行档案管理系统权限界面流程图；

图5是本发明银行档案管理系统中管理员操作流程图；

图6是本发明ssh框架的工作流程图；

图7是本发明银行档案管理系统架构图；

图8是本发明信息服务适配器图；

具体实施方式

为了使本发明实现的技术手段、创作特征、达成目的与功效易于明白了解，下面结合图示与具体实施例，进一步阐述本发明。

如图1所示，基于soa框架的银行档案管理系统，该系统包括有模块集成单元、档案管理子系统、业务资料管理子系统、数据存储与查询单元，权限管理单元；

模块集成单元包括有归档服务模块、报表服务模块、定制查询模块、实物管理模块、电子档案查询模块、服务定位模块、检索服务模块、系统管理模块：

归档服务模块：根据对私、对公客户在我行柜台开立的基本信息，主要包括客户户名、联系方式、账户性质、账户明细、公司印鉴信息、法人信息、营业执照等，对于已核销客户资料做好销户日期，统一将基本信息进行归档服务，以便后续查阅；

报表服务模块：根据记录网点、分行和总行形成的每日会计账务信息单元，在会计账务中的各职能部门工作成果的体现，如月、季、年的各条线的收入支出、存贷款发放、理财类产品、中行人行调拨等，在季度、年度工作总结会议或者金融产品结构调整新方向，都需要汇总各条线信息形成报表，管理系统需要查询后有生成关键信息报表的功能，对管理层决策产生帮助；

定制查询模块对信息筛选查询需求：系统需要实现查询符合特殊条件的信息：主要是能做到根据日期、金额、账户信息等类型的查询等；

银行档案除了电子档案呈现，实物也是不可或缺的部门，在2004年前，我国还未普及电子档案扫描，多数银行依然使用纸质档案进行保存，那实物档案管理就需要做到档案入库、档案出库、档案的借调以及档案的归还。

实物管理模块是档案的入库指的是档案按照现有的业务资料分类进行系统配比后存放指定的位置，形成档案的记录，档案的出库则指的是档案期满指定时间进行统一销毁或者转移到其他的档案存储地，档案的借调，则是指用户档案管理系统中进行调阅权限的申请，系统去判别是否有该权限并进行答复，注明用户姓名，借阅时间等，最后档案的归还则至系统消记已借阅档案的记录；

系统管理模块：在银行档案管理系统中，系统管理模块首先涉及到第一个方面用户和用户权限管理，而不同的用户涉及到在档案管理系统中不同用户权限，因为每个条线涉及到的用户权限分类实在太多，展示了银行运营条线不同的用户的权限，在分行级别管理层就可以有权限对于自己条线员工的权限进行审批的权利，当用户发生新增或者修改时，用户的角色也就发生改变，如果存在用户角色进行删除，那用户的权限也就随即会进行注销，分行管理人员维护这些基本信息主要就是能够对上述信息进行新增、修改、查询和删除等功能，并且能够体现业务工作信息之间的逻辑关系，修改和删除建立在查询的功能之上，并只针对拥有权限的客户开放。

用户权限设定

系统管理模块需要定期的维护，无论纸质档案或者电子化档案，随着长时间的保管，到了期满20年，将会定期清理过期档案，以便系统容量使用率得到提高。

进一步，业务资料管理子系统提供对近期业务数据的查询搜素，而档案管理子系统则将业务资料子系统归档后的数据进行保存和存储，另一方面，档案管理子系统还提供了对实物档案的管理查询功能，业务资料管理子系统可以定期或者不定期的向档案管理子系统进行历史数据的迁移和归档；

业务资料管理系统涵盖了五大应用系统：个人银行部电子档案系统，统一会计档案管理系统，资金后台集中业务管理系统，人行支票交换影像系统和信用卡gui系统，如图子系统架构，这些系统所产生的业务数据需通过分流进入业务资料管理子系统，一些需要采集的信息通过扫描机录入内容，从而服务器进行存储，ecm服务主要体现在提供非结构化数据的存储和管理，但不保存业务元数据。

在银行档案系统未集成时，员工查询其他条线的档案时，只能申请该系统的权限进行该类型业务的查询，例如图2所示统一会计档案系统的界面，这个系统的功能就过于单一，且只能会计条线的员工才可以进行查阅搜索。这就会造成系统资源的浪费，也会给科技维护人员增加工作量，所以将这些前台应用系统接口和银行档案系统进行集成，做到统一管理，减少每个部门科技人员工作量，精简了流程的纸质化。

进一步，数据存储与查询单元对银行档案的数据长期安全的保存时开发这个系统最重要的一部分，是衡量设计一个系统成功的标准，这部分如果考虑不周全会导致查询效率的低下、系统负载的加重及网络资源严重被占用的后果，本系统的设计理念是基于考察银行档案的特点和机构组织结构方面的总结而形成的一个安全稳定、效率快捷、网络资源不被占用的银行档案管理系统；

由于银行档案的数据查询时间不是按时间平均分布的，越是临近查询日期的档案查询率越高，而在前一年的档案查询率明显不高，所以为了查询时间达到最短，本文提出以档案时间不同进行分类存储，查询频率高的档案存储到查询时间快捷的介质中，而查询频率低的银行档案分布在储存成本低、查询速度较慢的介质中去，所以查询的频率是使用何种存储方式的重要区分原因；

档案在线存储所考虑的问题是确保数据的响应快速，即存储效率的提高，其次才考虑到是存储成本，因为硬盘的速度响应以及数据读取的速度都比其他介质快很多，为此保证查询的快捷性与精确性，在行内业务发生一年的时间内，可以将数据存储在光纤磁盘阵中，这样可以保证对这些数据查询的高效率，在档案发生一年以后，查询频率呈下降趋势，此时的存储方式应该是在保证数据可搜查到的前提下，降低成本存储；

离线存储方式的重点是低存储成本与数据安全并存，因为当前的数据极少被用来查询，所以此阶段，选用一种既存储成本低廉和安全的介质是重要处理，现业务部门对于要历史影像能否进行离线光盘查询，对此本文建议先使用dvd光盘作为现阶段存储介质，考虑到它的容量很大(4g-9g)，并且存储成本相比其他介质很低，对存储环境的要求也相对较低；

系统对支持离线数据在数据刻录时，需要进行加密技术处理，经过科技人员加密的数据光盘在本行系统外都无法使用，只有在行系统内使用专用的客户端查询程序才可读取光盘，以次保证对离线光盘查询安全性考虑，如果光盘不需要加密，该系统在刻录时也需提供离线查询工具同步进行刻录在光盘上，以方便离线进行查询，具体到某一张存储光盘是否需要进行数据加密，都均可通过管理员操作系统参数配置来决定，离线存储的同时还要提供备份数据和发布光盘的功能，即在档案数据处于在线存储阶段内，都可将数据录入光盘，作为对在线数据存储的备份；另外，刻录好的光盘可以下发各分支行所，来满足各分支行所本地查询和存储的需求。

在上文讨论管理系统的性能需求时，要求系统具备易用和可维护，充分考虑系统的分类性、安全性。要达到这些要求，应该采用先进、成熟的技术框架，结合第二章对soa和三大框架的介绍，可以看出，spring、struts及hibernate(简称为ssh)集成框架能够满足该系统设计要求。第二章综合分析了soa与各框架自的特点与作用，现在通过将这个整合过的架构来构成一个整体框架。soa成熟的标签库来实现web服务通讯协议兼容性；而spring、struts及hibernate框架同soa框架能够很好结合，把事务管理和依赖注入方面的优势用到业务逻辑层。

随着我国银行业大力发展，每日需产生上万张会计凭证及上千次影像视频，对于在当今信息盗窃流失案严重的时候，确保银行档案管理系统安全就尤为重要。在使用soa服务架构的银行档案管理系统中，由于网络服务提供了一个重要途径提供soa的要求，任何提出的问题，如soa安全性，可以对web服务相关的。在另一方面，web服务是众所周知的xml1_based技术。所以网络服务的安全性可以直接受xml安全的影响。在这下一章节，本文会提出一个新的安全框架来防御在soa环境中的威胁，特别是wsdl的攻击。

如图3所示，权限管理单元包含有员工权限、业务部门审批、档案管理部门审批这三大功能模块；

(1)权限发起：实现通过internet网页申报调阅非本条线报表，可以由分支行行员工通过身份证实名制在网上填写基本信息注册用户，信息通过审核后，即可填写档案管理平台权限审查表，提交后完成申报权限工作，网上提交申请表，由外网服务器获取申报数据；

(2)权限申报管理：对用户所申报权限进行核查，无权限资格提示报错；填报无误的权限转入内网服务器，等待下一步评审；

(3)权限审核管理：根据填报信息从基础数据库内调出相关设计部门完整信息，对申报权限进行分类，如运营报表、反洗钱核查信、信贷审核等等，不同的类型需要走不同的业务审批流程，如涉及面临人行检查等类似对外检查需调阅报表，同时按照其紧急程度进行分类；

(4)权限发放管理：这是流程的核心，在这一步主要将权限分配给各个分管部门审批，同时具有顺序和并行的工作模式，一般都将经历权限等级核查、制定审核时间表、权限发放，建立起银行档案管理系统后，将大大降低过程推进部门的人工工作量及减少纸质化，甚至能完全替代此项工作，做到各个流程的自动化，网络化，每个专项部门都只需要面对自己的职能界面即可，每一步审批完成后，管理系统都将自动分配下一步任务给相应的部门；

(5)审批流程检索：申报人和部门管理相关人员可以根据各自权限查询到权限审批所处的流程阶段及情况；

(6)权限结果反馈：由申报权限对方部门主管对发起人申报权限批示，如果不符合规章制度，将权限结果反馈给申报者；

(7)系统维护：系统维护人员定期备份数据库，对数据安全和人员权限进行管理。

为了更好的进行该银行档案管理系统的系统设计和详细设计，需要对银行档案管理系统主要权限审批流程进行分析。下面首先对该银行档案管理系统整体流程进行分析。用户(在这里是全行员工)要使用权限流程系统，必须进行登录验证，员工信息验证成功后，方能进入该系统。员工信息验证通过后，系统根员工角色的分配，显示不同的主界面，菜单主界面可以包括员工权限管理、部门权限管理、权限任务消息提示、权限分配管理、权限流程管理、权限流程结果、系统维护等模块的操作菜单，是根据不同员工分配角色显示对应菜单。图4为该银行档案管理系统权限界面流程图。

部门管理模块主要用于综合管理员对普通用户的添加权限、删除权限、修改权限及查询权限的操作。部门管理员管理模块主要包括部门综合管理员的登录、添加管理员、查询管理员、删除管理员及修改管理员密码几部分。当在系统的登录页面中，输入正确的帐号和密码后，如果该管理员为系统管理员，则具有添加管理员、所有管理员查询、管理员删除及修改管理员密码操作的权限，如果该管理员为普通管理员，则具有修改自己密码的操作。图5为该银行档案管理系统中管理员操作流程图。

整合后的ssh框架的工作流程在soa框架上对应改动后如图6所示。

银行档案管理系统的在网络中的部署分为三个层次，分别是数据核心层、接入应用层和ie接入层。数据核心层部是存储由业务资料管理系统传递过来的数据库，通过etl程序将抽取出数据仓库的数据中来，然后通过转换加工传递到档案管理子系统数据库中，数据库不仅存放客户的其他数据，而且还包含了前台业务部门所产生的数据。接入层系统的接入业务资料档案管理子系统的应用服务器，银行行所分支机构、部门的用户主要通过该层接入系统，然后通过用户权限认证后进入系统，通过接入层业务资料档案管理子系统可以通过面向服务的soa架构对接银行已划分出的业务应用系统(个人银行部电子档案系统，统一会计档案管理系统，资金后台集中业务管理系统，人行支票交换影像系统和信用卡gui系统)，以实现更灵活的对接服务方式。为了达到安全要求，除了三层之间通过两道防火墙进行隔离，在接入层也安置了了web应用防火墙，意在保护web应用的安全性，防止由于web应用原有的编程问题和漏洞导致的安全隐患，比如sql注入防御、跨网站脚本、命令注入操作系统、劫持会话、随意篡改参数和url、溢出缓冲区等攻击类型。

银行档案管理系统采用三层架构体系，分别为：表现层、业务逻辑层和数据持久层，这三层的架构最主要的目的是为了降低层次间的耦合度，而在业务逻辑层中，重点实现了该系统的主要功能。如图7所示。

架构图的中间层为银行档案管理系统的核心业务逻辑层，主要功能包括了归档服务、报表服务、定制查询、实物管理、电子档案查询、服务定位、检索服务、系统管理等功能，这个系统架构的功能分布贯穿了档案管理的的整个过程，以使档案管理业务能够顺利开展。通过上述架构的规划，系统的数据存储层通过业务资料管理子系统集成的其他部门业务系统数据，以作为银行档案管理系统的数据基础。通过ecm平台的建设，ecm在前后台之间架起档案管理服务这个重用的中间支柱，然后通过查询方式导出数据、报表、影像方式等通道的集成实现为业务部门、管理部门数据服务的释放，使档案管理业务可以高效灵活的展开。

该档案管理系统通过对档案管理系统业务流程的需求分析和对系统功能模块的梳理，采用了具有整合优势的基于soa的体系架构，主要以webservices的实现方式，与个人银行部电子档案系统，统一会计档案管理系统，资金后台集中业务管理系统，人行支票交换影像系统和信用卡gui系统实现相互集成，通过这种集成，公司的客户信息、账务报表、查询服务都可以根据对应的需求及时、准确的到达员工的目的，让档案服务提升到一个更高的水平。

基于soa的银行档案管理系统的架构，不仅使已有的系统如个人银行部电子档案系统，统一会计档案管理系统，资金后台集中业务管理系统，人行支票交换影像系统和信用卡gui系统等充分发挥出其应用价值，还使得各前台业务系统的接口设计开发灵活、快捷和高效，其得益于该系统基于soa的理念，也得益于清晰的层次结构，层次之间的配合是一种服务请求者和服务提供者之间的清晰的解耦合的结构，各层次中的模块之间也是松耦合的组成，ecm的业务逻辑层和数据存储层之间是松耦合的，在业务逻辑层中的实物管理和业务资料管理子系统等服务渠道系统之间也是松耦合，这种松耦合的结构合成遵循基于服务接口的设计，使得业务资料管理系统的请求管理模块的改动在接口不变的情况下，对于其他模块式透明和互不影响的，正是由于这个特点，银行档案管理系统的设计非常便于开发和维护，这种灵活性系统衍生到支撑整个档案管理业务的持续性，业资料管理子系统的接口新增或改变只需改变业务逻辑模块而对整个ecm架构没有影响。

请求模块实现电子档案查询：通过在emc银行档案管理平台上输入用户帐号、凭证种类、交易同期(8位数字，起始同期及终止日期)、交易机构代码、交易金额、网点流水号、柜员工号、借贷标志、凭证号码等交易信息来查询电子档案时，满足查询要求的会计凭证电子化就会被输出，之后还能可凭此会计凭证来映射到对应的影像文件。

在业务系统前端或通过web方式，各级银行会计档案查询员可以通过自己的查询权限来查询或打印会计凭证及影像。目前的设置是网点员工只能在统一会计档案系统中调出本网点的会计凭证，分行级别的管理员工可以拥有属于相关业务权限的调阅全行会计凭证。在当统一会计档案系统成功接口到业务资料子系统中，全行员工就可以直接根据权限进入全行银行档案管理系统中会计凭证查阅模块进行电子档案的查询。在进入本系统的时候界面会提出请求，包括对用户的身份信息，访问权限和通过登陆的系统等信息进行确认和记载都将被请求管理模块集中管理。对请求资源进行统一的定位由服务定位负责并由此得到解析并访问该资源所需要的附加信息，格式可以有业务id文件格式等。因为其他系统中的有些功能需要本系统功能的支持，并且本系统中的部分功能需要对其他系统的操作才能完成，例如业务资料子系统和档案管理系统的协作完成才能满足非结构化数据应用需要。业务资料子系统的功能是提供业务相关的服务给业务员，并且提供接收消息的服务给emc服务平台。如果该服务基于soap协议，那么需要它向emc服务平台提供wsdl描述文件，或者提供发送消息和客户端插件给emc服务平台。档案管理子系统中批量归档及其它服务都包含在emc服务平台，客户端插件也由emc服务平台统一提供。

当批量清单操作请求管理时，web服务器上部署了emc平台对外发布的大部分服务指令，只有批量归档服务单独部署在归档服务器上外，这些服务既有面向业务系统的，也有面向业务员的；有soap服务，也有http服务；有实时的，也有异步的；总行部署了全文检索服务。实际上的一连串的实时操作请求组成了异步操作。业务资料子系统在操作中需要注意调用顺序，一般流程是注册请求后到等待处理再到获取结果。辅助的操作请求包括处理进度查询以及处理请求撤资销毁。除了非结构化数据可以交由业务员在业务系统登记后直接与emc服务系统的web服务器交互传输，原则上其它的应用请求均由emc服务系统与业务资料子系统交互完成。soap服务端口需要统一，当前8848为emc系统面向业务资料子系统的的统一端口，8849为批量归档服务统一端口，80为面向业务员的soap及http服务统一端口。

归档服务实现业务资料子系统的定期归档，批量数据的归档在在本服务体系中指的是非结构化数据应用领域中批量新增文件和批量更换文件。这就需要系统模块中的归档服务来实现。但以前那种过多的迁移操作是不适合如今的大量非结构化数据批量归档，因此，业务资料子系统直接发送请求到目的地主机上，并由此批量归档服务被独立出来。因此减少数据的迁移操作是硬性要求，而非技术原因，所以emc服务系统不支持集中接收后分发的处理模式。当银行工作日结束的时候，业务资料子系统下的前台业务数据被各个系统分流到业务资料子系统。调用本系统的归档服务在此时进行工作，即对业务数据压缩和加密，然后业务资料子系统依靠企业总线接收到文件和数据格式，并对收到的数据文件解压和解密、最后导入本系统中。当对过期资料进行归档时，业务资料子系统需要调用归档服务，档案管理子系统将对这些过期数据进行储存，从而减少业务资料管理子系统的存储空间。webservice接口提供查询服务，调用本服务完成归档档案数据的查询可以帮助业务资料管理子系统或者为日后新增应用系统进行查询，通常会提供预留接口给分行未来新增特定应用。另外增加元数据的管理功能为本系统封装emc以实现内容服务，通过本服务可以完成与内容服务有关的内容查询服务。

服务定位实现档案实物检索服务，本系统另外还实现了实物档案的资源定位服务，其中实物管理是银行档案管理系统的重要保障基础。当业务人员调用一笔客户的，支票记录时，通过电子影像的查阅可能不能检测到支票上的印鉴章的鉴定，需要支票实物再进行确定，这就需要在电子档案查询的时候，同时给出实物存储的具体id地点，以方便银行业务人员随时进行实物档案的调阅。实物的调阅以前都是纸质流程跟踪，易导致记录的错误，跟进不及时，难以统计等问题。本文将在档案管理系统中实现实物入库、出库、借阅、归还等一系列流程化的管理。

银行业务档案仓库充当着档案实物管理的职责，这包括银行银行业务档案的实物入库、出库、借阅、归还、新增或补充等方面的管理。对银行档案库房的管理内容有很多，主要包括增加档案库房、停用档案库房、编辑档案库房，其中增加档案库房需的管理需要银行档案管理员填写档案库房名称、所属哪个业务部门、最大柜位数等基本信息，根据银行档案管理系统自动给出对应库房的代码，完成信息填写后提交这些信息，在业务层方法，新增的库房记录主要可以通过调用数据库访问方法来完成。

当纸质银行档案进行统一前置扫描机的扫描上传后，在银行档案管理系统中进行入库操作时，将事先计划的存储位置信息编辑在该档案信息那，随后由档案管理员填写需要新增档案的信息内容(包括：所属业务部门，业务办理时间，入库数量，档案分部门类，档案名称，档案编号，仓库编号，柜位号码，入库时间)。当员工在档案管理系统中进行该实物档案的服务定位时，相应的该档案的实物信息全部列出，员工只需要在访问界面上进行实物档案的出库操作，在银行档案仓库管理员会收到档案出库指令，管理员只需要对对需要出库的实物档案流程进行记录即可，包括：借阅实物档案的资料编号，接收仓库编号，接收柜位号码，经办员工号，经办时间等基本内容进行核实并做记录，同时将需出库的实物档案的状态修改为出库状态。但员工进行借阅实物档案操时作，系统会首先将检查用户是否有借阅权限，有借阅权限的用户将被记录下基本用户信息其能容包括：实物档案编号，借阅时间，借阅人(或业务部门)，借阅原因，审批人工号，并标记为已借阅档案，没有权限的用户系统将会给出拒绝反馈信息。

当业务部门员工进行实物档案归还后，银行仓库管理员需要在档案管理系统中将实物信息与原始借阅记录进行对照，然后在系统流程中将借阅信息包含归还实物档案的时间，借阅状态等进行修改，同时还须将实物档案的状态置为可使用状态，因此档案管理系统中实物档案的借阅流程将会结束。当实物业务档案具备即时增加修补的，如公司印鉴卡进行重新核验后发现该公司的印鉴卡系公司伪造，那调阅的印鉴卡就会存在实物档案的修改与补充，所以档案管理人员需将归还的实物档案调入仓库之前在系统中进行增加或修补的备注记录。

业务逻辑层主要负责处理应用程序的业务逻辑和管理事务、允许与其他层互相作用的接口、管理业务级别的对象的依赖。在spring框架中，业务对象中的setter方法接受的是接口，利用属性的set注入进行初始化。

只需要提供属性的set方法，然后去属性文件中去配置好让框架能够找到applicationcontext.xml文件的beans标签。标签beans中添加bean标签，指定id，class值，id值不做要求，class值为对象所在的完整路径。bean标签再添加property标签，要求，name值与user类中对应的属性名称一致。value值就是我们要给user类中的username属性赋的值。

当参数为非字符串类型时，在配置文件中需要制定类型，如果不指定类型一律按照字符串类型赋值。当参数类型不一致时，框架是按照字符串的类型进行查找的，因此需要在配置文件中制定是参数的位置。

spring中的delegating-actionprox是action之中的type属性。而delegatingactionproxy是org.apache.action.action的子类，转交给真正的action实现调用请。

这样的实质是让struts在运行期实际上加载了delegatingactionproxy

delegatingactionproxy达到指向实际action的目的，也就是针对了调用代理，struts最后将调用到实际上spring管理的action实例。通过如此的调度方式，spring就可以得到对action的实质管理权，这使得它可以对action进行调度，并为提供action实例给struts。在action已经被spring完全接管后，我们就可以把这个action看作为spring里面的一个bean，这样spring提供的所有服务都能被充分利用如依赖注入、实例管理、事务管理等。

应用开发者在应用和数据库之间需要创建一个持久层，我们在系统中应用持久层。在银行档案管理系统应用中，因为需要频繁地与数据库交互，并且使得交互更加有效而迅捷，所以这个数据库需要存储应用到数据库的数据，也对数据进行更新、检索、删除、对应user表，建立如下映射类。

为任何域对象创建和配置新dao所必需的全部步骤。三个简单的步骤是：定义一个接口，它扩展genericdao并包含所需的任何查找器方法。将每个查找器的命名查询添加到域对象的hbm.xml映射文件。

emc平台需要接收客户端(比如业务部门资料档案)提交的数据一般都是在action类定义实体类实例的方式来实现的，springmvc则主要是通过定义action方法参数来使emc接收。

银行系统中因涉及到很多其他业务部门的系统，比如个人银行部电子档案系统，统一会计档案管理系统，资金后台集中业务管理系统，人行支票交换影像系统和信用卡gui系统，而这些系统组成了档案管理系统中的业务资料管理子系统，为了使得业务资料管理子系统中的数据能够安全稳定快速传递到emc平台共享，需要确保业务资料管理子系统与个人银行部电子档案系统，统一会计档案管理系统，资金后台集中业务管理系统及人行支票交换影像系统和信用卡gui系统的接口连接一致。

当业务资料管理子系统系统与emc进行集成时，由业务资料管理子系统生成待发送数据包，然后通过webservices服务将发送请求发送到emc服务的服务器端。emc服务端在接受完数据后，将数据分配完毕后发送给客户进行电子查询。下面主要详细介绍业务资料管理子系统和emc的集成过程。

如果客户查询的业务对应的业务资料管理子系统有最发生变更时，业务资料管理子系统便会根据业务逻辑模块定义的逻辑生成相应的数据发送列表进。如果此时达到发送的要求时，业务资料管理系统便需要给客户发送相关的电子查询服务，以影像或者报表形式通知客户相关查询信息。具体的数据传递工作由集成的业务资料管理子系统完成。集成的流程是业务资料管理子系统中部署了emc的webservices客户端接口，当系统调用客户端接口时，客户端再调用emc的webservices服务端接口，通过这个过程来把数据传递到emc，平台收到数据传递完成的动作后，接口再通过标准的xml指令将发送情况返回给业务资料管理系统，业务资料管理子系统会解析这些xml信息，然后更新业务资料管理系统数据库中对应的消息发送列表。

通过uddi目录搜寻，我们可以随机地改变一个服务的提供方而不会让客户端收到影响的程序配置。所有的访问都必须通过soap来进行，只要wsdl接口安装没问题，对外客户是完全没有办法直接搜寻并访问到服务器端的数据的。通过运用wsdl和soap请求，我们可以达到创建一次性接收大量数量接口可能。需要强调的是soap请求分为文本方式和远程调用(rpc)这两种方式，文本方式：web服务所有的联系是通过soap进行的，而soap又是基于xml的，版本之间可以通过使用不同的dtd或者xmlschema来加以区分。所以我们只需为不同的。版本提供不同的处理就方式可以轻易地实现版本监控的目的

在银行档案管理系统中，先将业务端口所传递的业务id号和元数据导入到xml传输协议文件中，再将此传输协议文件进行加密压缩处理使其通过soap协议，从而顺利传递到各条线对应的系统中间，当每个部门对应的系统一旦接收到此压缩文件后，立即进行解压解密的处理写入数据库中。而spring框架提供的applicationcontext实现会根据配置文件中的描述信息来实现对象生命周期管理，配置管理以及依赖管理等功能。spring所提供jaxrpcportproxyfactorybean封装了构造webservice业务资料管理子系统的细节，可以通过参数配置来创建dynamicproxy和dii类型的webservice业务资料管理子系统。无论是webservice的配置发生变化，或是改用不同的服务实现时，都不会使业务资料管理子系统应用代码的产生影响。这很好地实现了业务逻辑与webservice调用之间的解耦，解决了业务资料管理子系统与emc平台更好的集成，特别是当各条线部门业务系统与档案管理系统进行交互时，将调用数据归档服务器进行数据归档处理。在各部门业务系统中，通过客户端api接口将业务id号传递给档案管理系统中，银行档案管理系统会根据用户业务产生的id号在数据库中查找影像数据并提取出来发送到部门权限所能查阅的系统中，该用户只需进行下载或者在线浏览方式显示出来。

作为在soa架构中，esb用来作为一个解析转化消息的盒子，制定标准化的soap/http格式，如图8信息服务适配器：ims企业套件中soap网关与ims连接，soap网关是一个小服务程序运行在apacheaxis2soap网关与ibm平台的websphere应用服务器相结合的主机z/osunix系统服务tomcat上。随后soap网关接受soap/https请求并把它作为xml的ims连接在tls，同时ims连接在z/os操作系统运行的调用生成的xml转换器转换数据到imspl/i应用格式ims连接再通过多段消息otma。利用ims标准，此web服务适配器完全融入银行档案管理系统soa基础架构，并且性能(往返时间)的web服务类似于corba。

随着银行档案管理系统所涉及的前台业务系统越来越多，对档案管理系统中数据层的传递需求也越来越大，esb担负着处理消息(message)集成的作用越明显。在本文中这里的消息指的是业务资料管理子系统与档案管理子系统之间的沟通。但因业务系统归属的不同部门，业务种类的繁多，导致每个业务应用系统都拥有自己的方言(语言)，即各自的消息格式。作为基础架构的eai系统，必须能够对系统范畴内的任何一种消息进行解析，但是传统的eai系统中的消息处理大多是被动的，消息的处理需要各自中间件的私有方式支持，比如当员工在档案管理系统需要搜索一名客户的基本资料与人行征信结果，但是系统反应出只有人行征信界面中反馈的结果与客户信息，与当时的需求是客户信息与征信结果分开不一致。这可能是传统的eai系统中对于指令的解析会断章取义。esb能够在底层支持现有的各种通讯协议，那么对消息的处理就完全不考虑底层的传输细节，而直接通过消息的标准格式定义来进行。这样，在esb中，对消息的处理就会成为esb的核心，因为通过消息处理来集成服务是最简单可行的方式。这也是esb中总线(bus)功能的体现，不仅仅是提供消息交互的通道，更重要的是提供服务的智能化集成基础架构。

建设soa环境的核心构件esb(enterpriseservicebus)，支持异构环境中的服务、消息以及基于事件的交互，并实现适当的服务级别和可管理性。esb应支持多总线方式服务调用，并要提供编辑服务的能力以支撑合成服务的结构，提供项目控制和xml(标准语言集)数据功能转化，以实现对注册服务的随时监控与管理。具体包含这样的几项功能：注册服务管理，运用协议方式对服务的注册、版本、性质、状态等内容进行管理，提供服务者检索等功能。编辑服务，应能通过概念包含几个级别较低业务功能的工作流来创最新的服务业务。这样的工作流变成最新的服务业务，并公布在服务协议库中。项目管理必须解决项目中存在的漏洞。项目管理保证在其管理下的项目处理的内原性、一致性、独立性和长久性。数据转化，以xml作为soa的数据转化平台。数据转化必须解决以各种样式保存下的数据情况，将所需要用的数据转化成xml文档，然后保存、经办或者转化成为其它的格式。服务监管，服务监管应对正在运行的soa服务执行、监控、问题跟踪等进行实时的监控和管理。服务调整，esb的服务调整应提出同步调整、异步情况、批量文档、批量数据这4种形式。资源配置，应提供文件配置、数据库配置和消息排列配置等多种方式，并与外部文档、数据来源与消息排列迅速、简易的集成，进行数据互换。

作为银行档案系统中系统传输的中介esb平台，它需要的作用包括调解功能，安全网关，注册表，负载平衡和故障转移。为了能有效的管理esb系统，设计出一个esbm管理系统尤为重要，并为esb提供以下功能：

1、注册表管理。ebsm提供了一个全球自助服务商注册的用户界面，降低了本地esb的注册表解耦性。获得统一供应商注册表，使得只有子系统本身才可能会改变他们的供应商数据。设计时间和运行时注册的分离，强制执行的管理规则，通过集中，允许一致性(无同行同步)和先进的动态路由(见动态跟踪开关)。

2、安全网关管理。esbm提供安全的网关登记，每个安全网关实例都有它自己的安全元数据。esbm保持所有安全网关实例一致的状态，安全元数据在几秒钟内就会更新。。

3、联邦esb的管理、维护和监控。ebsm通过esb拓扑模型提供了联邦esb的集成视图。新的esb实例可能会推出一个管辖权，预先定义的状态，包含中介规则，集中管理和上传到这些实例。所有的情况下，为随后的供应商和安全注册成为准备。可用性的实例进行监测和可视化的中心，在对应的子系统中，所有esb传递规则都是由所属这个对应系统的小esb提供管理、监测和维护。

4、供应商的库存和监控。esbm对provider提供的集成视图，其浏览状态可以检查(服务器运行、平网服务操作)，并且服务版本(wsdl版本和相关的xsd)可以下载。provider的信息传递路径可以在几秒钟内随时作出改变，反映了云行为。

5、治理执法。esbm提供了一个集中soa治理，其中一个管理规则是，每一个provider注册接口去连接必须检查服务定义的质量。这样的规则是由集中esbm执行，并在esb检查他们在esbm监测。

6、知识库整合。在每个子系统的服务接口设计中可能存在几种不同的质量保证过程。质量保证过程确保wsdl致力于版本控制系统的状态标签，允许wsdl库自身质量保证过程。

7、部署工具的集成。每个平台定义了它自己的应用部署程序的过程。如果一个平台的部署工具启动供应商注册，那它使用esbm提供的程序注册的web服务接口。但如果是直接使用注册表服务接口，就可能绕过集中管理的强制执行。注册表绑定或者解除绑定接口是esbm强制治理规则。

8、高协调性和安全性。全球所有的esb实例是由wsbm中央管理的ssl双向认证，管理系统与其托管组件之间的连通性与“看门人”模式是兼容的，正如所使用的一样。没有防火墙规则的变化而引入esbm需要。

9、联邦管理模式。该esbm通常遵循一个联合管理模式的管理系统是分布式的和他们代表他们的一些能力，中央系统能更好的协调，而中央管理系统支持多个esb，将其为子系统进行服务。

作为实现esbm管理系统，esbm网状分布，通过esbm散步点状的esb去对应各自的档案管理子系统来实现接口之间协议的传递与数据的传送。

以上显示和描述了本发明的基本原理、主要特征和本发明的优点。本行业的技术人员应该了解，本发明不受上述实施例的限制，上述实施例和说明书中描述的只是说明本发明的原理，在不脱离本发明精神和范围的前提下本发明还会有各种变化和改进，这些变化和改进都落入要求保护的本发明范围内。本发明要求保护范围由所附的权利要求书及其等同物界定。