某大型银行深化系统之十四：技术架构

传送门 ☞ 轮子的专栏 ☞ 转载请注明 ☞ http://blog.csdn.net/leverage_1229

技术架构

        在上述功能架构中，除了核心层外，应用层及服务层都包括了用户UI界面，因此服务中包括了Mashup所需的WebAPI，需要采用MVC的WebApp框架来实现。整套系统的技术架构如下图所示，根据总体架构的设计思想，自定而下包括了客户端、服务层、核心层、系统软件平台、基础设施。整套技术架构建设在B/S架构模式下。

客户端
        用户入口，完成UI界面的功能，包括在Windows下的浏览器界面、XPE嵌入式系统的扫描终端、流程定义工具、监控、报表展现等等，通过ActiveX嵌入方式提供浏览器的通用环境，支持B/S和C/S两种方式。
服务层
        每个服务都包含了业务处理界面，采用典型的MVC框架构成自治系统。服务包括了展现层、控制层、业务层、持久层。服务层框架大部分采用JSF+Spring+Hibernate的WebApp框架，通过OR-Mapping等工具自动生成大部分的代码和框架，规范服务的编制。横向扩展通过Hiberate的二级分布式Cache在WebLogic容器中完成分布式复制和备份。
核心层
        包括了以流程管理为中心的工作项池、流程定义、流程监控、优先级管理、统计报表，以及统一日志管理，SSO单点登录系统，以及ECM等。
系统软件平台
        包括了支持各类服务的Weblogic容器及中间件、Documentum 内容管理ECM、Oracle关系型数据库，包括了支撑各类平台所需的RedHat AS4(Linux)、Windows Server 2003、IBM AIX等操作系统。
基础设施
        包括了以扫描补录中心为代表的高速内部局域网，各类服务运行时的主机服务器、数据库服务器，提供影像存储的SAN等网络存储介质，同时为达到系统的稳定性和提高系统响应性和扩展性而引入的LVS负载均衡器。

        技术架构中，层次之间的连接主要包括了Mashup技术及WebAPP框架。

1Mashup架构

        Mashup架构由3个不同的部分组成，它们在逻辑上和物理上都是相互脱离的（可能由网络和组织边界分隔）：API/内容提供者、Mashup站点和客户机的Web浏览器。

1.1API/内容提供者

        它们是正在进行融合的内容提供者。为了方便数据的检索，提供者将自己的内容通过Web协议对外提供（例如REST、Web服务和RSS/Atom）。

1.2Mashup站点

        即mashup所在的地方，是mashup 逻辑所在的地方，而不是执行这些逻辑的地方。从一方面来说，mashup可以直接使用服务器端动态内容生成技术（例如Java servlets、CGI、PHP或ASP）实现为类似传统Web应用程序。另外，合并内容可以直接在客户机的浏览器中通过客户机端脚本（即JavaScript）或applet生成。客户机端的逻辑是直接在mashup的Web页面中嵌入的代码与这些Web页面引用的脚本API库或applet（由内容提供者提供）的组合。mashup使用的这种方法可以称为胖Internet应用程序（RIA），这意味着它们是以交互式用户体验为导向的。客户机端进行数据集成的优点包括：对mashup服务器的所产生的负载较轻（数据可以直接从内容提供者那里传送过来）、具有更好无缝用户体验（页面可以请求对内容的一部分进行更新，而不用刷新整个页面）。
        通常，mashup都使用服务器和客户机端逻辑的组合来实现自己的数据集成。mashup应用程序都使用了直接由用户提供的数据，（至少）使一个数据集是本地的。另外，对多数据源的数据执行复杂查询所需要的计算是不可能在客户机的Web浏览器中执行的。

1.3客户机的Web浏览器

        是以图形化的方式呈现应用程序的地方，也是用户交互发生的地方。正如上面介绍的一样，mashup通常都使用客户机端的逻辑来构建合成内容。

2WebApp框架

        WebApp应用框架主要负责各类服务组件以及业务系统的构建，即内容提供者。WebApp框架主要由展现层，业务层，控制层，数据持久层组成。
        整套设计思想中，从数据建模出发采用的是Top-Down设计思路；页面构建采用的是Bottom-Up组装方法；两部分工作最终汇集点在业务层（Services）。通过这种分工的方法，可以最大化地实现从业务建模到页面组件的复用。
        WebApp框架包括了表现层的一套组件，框架主要着重的是支持数据库操作，管理数据库连接以及规范架构。
        目前框架主要采用的技术为 JSF、Spring、Hibernate。在表现层是JSF，在持久层是Hibernate，框架使用Spring来管理bean之间的依赖关系。WebApp框架是一个全新的软件产品，基于JSF组件模型，可以大量重用JSF的组件；基于Spring的技术进行事务管理；基于Hibernate的数据库持久策略，提供了完整的数据库操作过程。
        该框架也具有“自动生成框架”的功能。可以通过Bottom-Up设计理念，从数据模型生成的代码工程。输出是一个搭好的骨架式代码，这个“骨架”分成三层：表示层，业务层，数据持久层。项目开发人员需要进行的是“填充骨架”的程序开发。

        WebApp框架最上层是页面部分，它使用JSF技术实现，主要负责页面呈现。
        接下来是Backing Bean，Backing Bean也属于表现层，主要进行的是页面组件绑定，页面呈现后台处理，页面动作处理，页面跳转控制。同时负责调用Service层。
        Service层，也就是业务层。它负责处理业务逻辑，同时负责调用下层DAO进行数据库操作。本层主要编写相应的业务逻辑，开发人员在本层增加业务逻辑处理代码，已有的代码只是对本表的增、删、改、查，在编写代码时可以调用其他dao中的方法，取对应的数据。
        DAO层，属于数据持久层。DAO层主要进行的是针对一个数据库表的CRUD(增删查改)操作。POJO层是数据持久层的一部分。POJO也是数据持久层的一部分，是对数据库表进行ORM映射的。
        该框架的优势较为明显：较好的使用技术框架，可以大大提高项目开发速度，提高组件的可充用性，降低开发成本，降低程序员进入门坎。各层次的职能非常明确，确保了程序的可维护性，对于团队分层协作开发提供了牢固的基础，能极大的提高项目开发速度以及应对需求变化的能力。

3代码结构

        架构代码部分主要的包结构是Backing、Entity、Dao、Service这四个部分。这四个部分的名称比较明确，很好的划分了层次内容。其中Backing是JSF中的backingbean，处理表现层。Service是业务层，实现业务操作。Entity与Dao是属于持久层。Entity是hibernate中ORM的数据持久化类，是一些普通的POJO，与数据库表一一映射，entity下有hibernate的hbm文件，表示数据库表与实体的映射关系。Dao是直接与数据库操作的内容。
        每个路径下，都按表来划分的，即一个表会对应一个backing,一个entity,一个Service,一个dao。同时在backing与Service中，我们定义了一个base一个sub,sub是提供给用户后续开发使用的。
        因此，技术框架使用自动框架生成工具，自动生成。下面清单介绍了框架的主要内容。
JSF表格页面、增加页面、修改页面；
BackingBaseBean，BackingSubBaseBean；
Service接口和具体实现类；
Dao实现（包括基本方法）；
配置文件faces-config.xml、applicationContext.xml、web.xml；
生成后所需要的JAR包。
        注：生成后所需要的JAR包部分是与代码生成工具一起提供的，有了框架代码和Jar包，即可以构造出完整的开发工程，进行项目开发。

4框架机制

        由于本框架使用的是JSF+Spring+Hibernate的架构，因此WEB-INF路径下几个配置文件web.xml以及applicationContext.xml、faces-config.xml是比较重要的。Web.xml定义了使用的框架faces-config.xml定义了JSF页面的backingbean以及跳转关系，而applicationContext.xml定义了bean的依赖关系，即使用依赖注入的功能。
        针对每个表的操作，框架提供了从表现层业务层到持久层的过程。这种过程也可以作为项目后续开发的一个参考。以一个表对应的页面为例。他的页面展现的应该是表格功能。页面由JSF实现，现有的页面使用了一些开源的组件，这些由于来源不够稳定的原因，今后不会使用。faces-config.xml定义了页面的backingbean。Backingbean中有一个相应Service的私有成员，它的实例化我们使用spring的依赖注入控制。Backingbean支持页面的数据取得，数据操作方法相应，这些与业务相关操作，是交由其Service进行。
        每个Service都有至少一个DAO的成员，它的实例化也是靠spring的依赖注入控制。我们在Service中进行对数据的逻辑操作，其最后与数据库交互的过程，是由DAO完成。DAO基本上是Hibernate的内容，DAO中提供了完整的数据库操作方法，封装好了一些常用的查询，插入删除功能，也提供了按sql语句进行操作。
        对于service中的非数据库操作，spring也提供能相当完善的无缝插入，对于JMS、WebService、RMI等分布式远程调用都提供了相当灵活而简单的帮助类，当注入到具体的业务处理实现类中后能让调用者根本无需知道具体的实现方式，对业务的实现提供能很好的扩展性，适应性，标准性和开放性。
        对于项目的开发过程中，使用了框架之后，DAO,POJO不需要修改，主要需要后续开发的是针对需求功能开发页面和backingbean。对backingbean可以在现有的subbackingbean进行，针对需求实现业务，在Service中开发业务逻辑。Service中对数据库的操作，调用DAO类相应方法。
        其中对于service层和DAO层的服务能力通过web容器集群来横向扩展，在DAO层通过web容器集群的session复制原理来实现在多容器环境中数据的同步存储，对service层通过web容器集群负载均衡达到对效率的优化整合，提高service层的响应能力，以最终到达整体应用的适用性，安全性和扩充性。