烟草服务平台总体设计思路

1 总体设计

1.1 设计思路

卷烟零售客户是烟草行业最宝贵的资源，在日常的服务过程中，信息沟通的准确性和及时性是工作的难点。因此，如何创新服务方式，提升服务水平便成为了落实精准服务，全面推进营销工作上水平的思考方向。通过微平台传递特色服务，提高信息沟通的准确性，达成新型客我关系。作为烟草商业企业，面对众多经营能力各异，服务需求不同的零售客户，仅仅通过常规的拜访落实服务工作，客户经理的服务水平与营销效率难以得到提升，服务同步也就无从谈起。

烟草公司、零售户、消费者等众多参与者构成了一个生态系统，我们相信在这个系统中，再小的个体也有服务需求，而庞大的个体数量让服务具备个性化和差异化等特点。微平台通过消除烟草公司和服务对象之间的沟通距离，进行实时的交流和反馈，从而满足不断增长和变化的服务需要，达到全面提升服务质量和水平的目的。微平台基于以下几点进行设计：

一、进行有价值的服务

零售户和消费者是烟草行业最核心的资源，每个客户都有着自己的需要，给客户提供有价值的服务，才能够真正的打动客户，进而促成和谐双赢的伙伴关系。微平台通过收集和分析，制定相应的服务策略，服务模式由单一的服务内容向分类分层服务提升，实现服务从无目标、无重点、履行任务式的客户拜访向目的明确、重点突出的客户提升式的服务转变，提升客户的满意度和忠诚度。

二、消除地理上的限制

地理曾经是过去的一个商业上的一个重要因素，但从移动互联网以来，所有的人都能够卷入到一种跨越时空的一种交流里面。烟草公司很难和消费者直接对话，微平台通过公众账号采集消费者的需求和回馈，从而收集市场信息和市场波动，这在过去是难以想象和实现的。

三、用户价值第一底线

微平台通过集结零售客户和消费者，加深相互之间理解和信任，加强相互间的黏度和互动，通过“微会员”、“微点评”、“微留言”、“微活动”、“微客服”等“互联网+”时代的沟通方式，保护和坚守用户价值第一的底线。

综上所述，微平台通过不断满足卷烟经营的新需求，不断满足零售户和消费者的服务需要，推行主动式的服务和覆盖式的服务，打好“服务”这张牌。

1.2 设计原则

一、 全省统一设计原则

整体框架立足于全省系统，全省统一的企业号，各市公司建立或使用全省的服务号，微信服务平台的实施采用一个全省统一的公众号，通过本项目的功能开发，来实现省公司、地市公司和零售户分层管理，分层使用。

二、 先试点、后推广原则

本项目先在蚌埠烟草试点，成功后再向其它地市烟草公司推广使用。项目前期以蚌埠烟草业务需求为主，并结合安徽省烟草公司的需求，通过实施及试运行后的完善，逐渐形成一套可推广的微信服务平台。

三、 需求全面规划、分步实施原则

从需求规划上充分考虑各个业务部门、各个服务主体的需求，全面覆盖烟草工业、烟草商业、零售户和消费者的需求点，及未来发展可能存在的需求。

在项目实施中，建设的全过程中应当在整体需求规划的指导下进行，先期完成的项目内容在完成本部分功能要求的同时要为后期实施的项目留出必要的接口，保证项目的整体完整性。

按照短平快的要求，完成工商零消服务平台的建设，投入使用。

四、 不断探索、不断优化原则

微信营销和服务是一块新的业务领域，系统建设和使用过程中会不断的发现需要优化的内容，所以整个微信服务平台的建设是一个不断探索的过程，通过不断的实践，不断的优化才能让整个平台发挥出应有的效果。

另外鉴于本项目与安徽现有项目的密切关联的重要性，系统设计将重点在以下原则进行考虑：

1. 安全性

系统具有实时的数据备份功能，自我校验和纠错功能，可以保证数据的存储及读取的安全，以及数据交换的安全和一致性，并对网络中传输的数据采取必要的加密措施。

2. 可靠性

系统要支持长时间、高负荷的运行，要求软/硬件平台、应用逻辑两方面都稳定可靠，同时，系统架构的合理性也至关重要。

3. 实时性

系统能快速响应整个系统的请求动作，快速进行数据处理和运算。系统的最长响应时间不超过5秒，平均响应时间不超过2秒。

4. 扩展性

系统有很好的扩展功能，有良好的兼容性、可移植性，能够通过功能扩展以适用业务发展的需要。

5. 先进性

系统设计应采用先进的、成熟的且可持续发展的技术方法，并充分体现先进的管理思想和理念，与实际相结合。

6. 合理性

在系统设计时，充分考虑系统的容量及功能的扩充，方便系统扩容及平滑升级。系统对运行环境(硬件设备、软件操作系统等)具有较好的适应性，不依赖于某一特定型号计算机设备和固定版本的操作系统软件。

7. 可行性

软件系统的开发设计，应确保技术上的可行性，适合招标人的核心需要，满足主要功能需求，适应需求变化时的系统的免代码自定义和功能模块加减、调整。

8. 规范性

遵循国家局、烟草行业及安徽烟草商业企业有关标准要求及业务管理规范，信息分类编码标准化、信息接口标准化。

9. 整体性

整个系统充分考虑了与现有营销系统、物流系统、专卖系统、人力资源系统等其他相关系统的接口问题。

10. 经济性和冗余性

系统设计紧贴客户需求，同时为可能的增值服务留有空间，具有良好的性价比。系统留有适度的冗余，既可满足近期业务发展的需求，又不会过多增加系统负荷。

11. 操作简便性

系统人机界面友好，操作简便，可以使用快捷键完成部分操作。

12. 可管理性和可维护性

系统充分考虑了应具有的良好的可管理性和可维护性。

1.3 总体架构设计

总体架构分为展现层、应用层、支撑层、数据层四个层次：

1）展现层通过微信平台提供的企业号、服务号实现工业企业、企业内部员工、消费者、零售户访问应用的通道。

2）在应用层主要分为前台和后台两个部分，前台主要是为“工”、“商”、“零”、“消”提供访问的功能和应用。后台主要用于管理微信的企业号和服务号，同时为零售户提供O2O的应用。

3）支撑层是为微信的前台应用提供支撑，与现有的系统实现无缝对接，可以通过微信的平台与后台直接进行交互。

4）数据层利用现有的安徽烟草的数据仓库，利用支撑层为微信的前台提供数据支撑。

 

1.4 技术架构设计

1、系统的总体结构采用B/S/D浏览器/服务/数据库的三层结构，系统中采用B/S结构，遵循J2EE体系架构。内外部应用均按照J2EE规范，使用java、jsp、servlet等技术，实现系统所需管理功能。

2、系统采用面向服务的架构（SOA），符合Web Service标准的访问接口，应用软件要使系统模块化、构件化，以适应管理、业务流程的变化和使用权限的再分配。

3、微信应用可通过通讯网络、Internet或局域网方式与服务器端后台进行信息交互。

1.5 用户关系拓扑

工业通过微信提供的公众号可以获得经营信息，以及商业提供的消费信息。

商业通过承担平台运营成本和提供各种便捷服务，可以获得，消费者的消费信息、采集到市场的数据，提供客户满意度，同时通过公众号，实现品牌的网上营销。

零售户通过微信提供的公众号，提供徽映e家的扫码数据，商品展示和送货服务，可以查询到货源信息、实现订单跟踪、取得订货服务、通过商品展示与销售、获得固定客源。

消费者通过微信提供的公众号提供消费行为和个人信息，可以获得便捷，方便查找周边商店、在线选购商品，并可以预约送货上门，在商品选购和参与活动同时还可以获得积分，兑换想要的商品，同时还可以获得商业企业和零售户提供的其他服务。

1.6 技术路线

本系统在技术架构上将完全符合安徽烟草信息化建设的总体技术框架。与安徽烟草目前已建的统一门户、营销、物流、三项工作等信息系统采用相同的技术平台,后台与门户系统进行有效集成和整合，保持技术的延续性和一致性，实现业务系统的统一身份管理、统一权限管理和统一界面管理，前端采用HTML5开发，支持各种智能手机。

1.6.1 遵循J2EE标准技术架构

J2EE 应用服务器（Application Server）采用目前国际最先进的开发理念、拥有许多适合基于Web 的应用系统需求的特点：

三层结构体系——最适合Internet/Intranet网络环境，可以使系统有很强的可扩展性和可管理性。

分布式环境——可以保证系统的稳定性，同时拥有较高的性能。

面向对象的模块化组件设计——可以提高开发速度，降低开发成本。

采用JAVA技术——完全跨平台，适应Internet需要，并能得到大多数厂商支持，保护用户投资。

为了降低成本，并加快企业应用程序的设计和开发，J2EE 平台提供了一个基于组件的方法，来设计、开发、装配及部署企业应用程序。J2EE 平台提供了多层的分布式的应用模型、组件再用、一致化的安全模型以及灵活的事务控制。使用户不仅可以比以前更快的速度向市场推出创造性的客户解决方案，而且，平台独立的、基于组件的J2EE 解决方案不会被束缚在任何一个厂商的产品和API 上。

J2EE提供了一个企业级的计算模型和运行环境用于开发和部署多层体系结构的应用。

J2EE的应用模型图

客户层（Client Tier）

J2EE 应用可以是基于Web 的，也可以是不基于Web 的。

在基于Web 的J2EE 应用中，用户的浏览器在客户层中运行，并从一个Web服务器上下载WEB 层中的静态HTML 页面或由JSP 或servlets 生成的动态HTML 页面。

在不基于Web 的J2EE 应用程序中，一个独立的客户程序，可以不运行在一个HTML 页面中，而是运行在其它一些基于网络系统（比如手持设备或汽车电话）中的applet 程序。在客户层中运行，并在不经过Web 层的情况下访问Enterprise Oraclens。该不基于Web 的客户层可能也包括一个JavaOraclens 类来管理用户输入，并将该输入发送到在企业层中运行的Enterprise Oraclen 类来处理。

Web 层

J2EE Web 组件可以由JSP 页面、基于Web 的applets 以及显示HTML 页面的servlets 组成。

调用servlets 或者JSP 页面的HTML 页面在应用程序组装时与Web 组件打包在一起。就像客户层一样，Web 层包括一个JavaOraclens 类来管理用户输入，并将输入发送到在业务层中运行的Enterprise Oraclens 类来处理。

运行在客户层的Web 组件依赖容器来支持诸如客户请求和响应及Enterprise Oraclen查询等。

业务层

作为解决或满足某个特定业务领域（比如山西烟草、银行、或零售业）需要的逻辑的业务代码由运行在业务层的Enterprise Oraclens 来执行。一个Enterprise Oraclens 从客户程序处接收数据，对数据进行处理（如果需要），再将数据发送到企业信息系统层存储。一个Enterprise Oraclens 还从存储中检索数据，并将数据送回客户程序。运行在业务层的Enterprise Oraclens依赖于容器来为诸如事务、生命期、状态管理、多线程及资源存储池等提供通常都是非常复杂的系统级代码。

业务层经常被称作Enterprise JavaOraclens （EJB ）层。业务层和Web 层一起构成了3 层J2EE应用的中间层，而其它两层是客户层和企业信息系统层。

企业信息系统层

企业信息系统层包括企业的各种业务系统和数据库。

1.6.2 基于SOA进行设计

什么是SOA（Service Oriented Architecture，SOA）？许多销售商、应用程序供应商、系统集成商、架构师、作者、分析公司和标准机构对SOA都提供了定义。SOA的定义是多种多样的，实际上更多的是对SOA定义的补充，且众多定义相互之间是不冲突的。面向服务代表在商业和IT环境下关于服务的一种思考方式，SOA拥有各种各样的定义是因为定义通常要针对一个特定的对象，如给一个CEO解释SOA与给一个程序员解释SOA是不同的。SOA是一个范式、一种思考方式，SOA对于架构和设计是一个有价值的系统。SOA是一种帮助系统发展过程中保持可扩展性和灵活性的方法，也是解决业务与IT缺口的桥梁。

组件化整体架构的核心SOA。SOA的中心思想是模块化与封装这两大原则，模块化将复杂的大任务的分解成相对简单的小步骤，封装则将其内部的复杂性屏蔽代之以用清晰的接口。在这两项原则指导下，开发人员只需关注应用中与其相关的部分而无须知道其他部分的细节，只要各个组件都遵守接口“契约（Contract）”，这些组件的开发、测试和修改都相对独立，无须太多的协调，使得基于SOA的应用易于开发和维护。

SOA是一种应用架构思想，它着眼于日常的业务应用，并将它们划分为单独的业务功能和流程，即所谓的服务。SOA使用户可以构建、署和整合这些服务，且无需依赖应用程序及其运行计算平台，从而提高业务流程的灵活性。这种业务灵活性可使企业加快发展速度，降低总体拥有成本，改善对及时、准确信息的访问。SOA有助于实现更多的资产重用、更轻松的管理和更快的开发与部署。在当今的业务环境中，变化是毫无疑问的，因此快速响应客户需求、市场机遇和外部威胁的敏捷性比以往任何时候都更显重要。

面向服务的SOA体系架构的特点：

1、以业务为中心

SOA更多关注于用户业务，通过业务人员参与SOA系统的规划、设计和管理，使得IT系统能在对业务的深刻理解的基础上进行构建，实现IT系统与用户业务的密切结合。在具体实施中，通过把完成实际业务流程中的一项任务所需的IT资源组织为服务进行封装，从而达到以业务为核心，通过业务选择技术，避免技术制约业务的问题。

2、灵活适应变化

IT系统围绕用户业务构建，用户业务在实现层通过表现为一系列松散耦合的”服务“来实现，这些服务可以根据用户需求随需组合，使得IT系统对于业务的适应能力明显提高。

3、重用IT资源，提升开发效率

SOA强调对”服务“的重用，对原有IT资源的重用度提升是SOA带来的关键效果之一，大量具有高重用的服务资源，为快速构建新的业务功能和业务系统奠定基础，使得IT系统的开发和软件生产效率得到提升。同时，重用过程有利于保护用户前期的信息化投资和IT资产积累，节省IT系统开发成本，实现用户信息化的可持续性建设与发展。

4、更强调标准

SOA的实现强调基于统一的标准，SOA系统建立在大量的开放标准和协议之上，以实现系统及信息的互联互通和互操作。因此，SOA系统从规划到实施，标准都至关重要。

SOA使得应用系统的设计清晰化而且促进组件的重用。应用系统中所有的接口的定义与信息模型――包括数据及其语义、对象与过程模型――都高度一致。很多的企业应用由于缺乏同一的长远的规划，通常情况下很少共享数据，几乎从不共享程序逻辑。但很多的服务具有通用性，而非某一应用独有，一个通用服务架构（Common Service Architecture）能帮助企业在上述的原则下共享部分数据和程序逻辑。通用服务的概念是企业架构中的一个重要的有机部分，主要包括下面的通用服务：

1）通用应用服务：如通用的数据模型访问，数据的转换等等。

2）通用基础设施服务：包括应用的管理与诊断、日志、安全、系统的操作与维护。

3）通用系统服务：包括对不同的操作系统、网络平台以及其它的系统层的功能提供与平台独立的接口。

1.6.2.1 分层架构

典型的企业SOA平台连接许多企业应用资源，应用用户，并且负责许多服务提供者和服务消费者。通过把服务划分为相同服务的组来得到管理效果。一个普通服务组使后台系统（BES）资源对于服务消费者可用。另一个普通服务组连接应用用户或者前端系统（FES）到SOA平台。

编排服务连接基本服务到复合服务。将服务分组的做法可以有效的利用SOA平台每层统一的特点。适当领域的技术，开发模式，测试装置，部署配置，系统管理制度等，能为每层具体开发。

分层架构是最灵活强大的实现方法。简单来说，SOA的服务来自于由后台系统（BES）直接封装后提供的一组接口，也就是存取服务。

整合逻辑也将被看作一组服务，此服务有良好定义的已发布接口。这些服务是更高水平的服务，它利用更低水平的后台系统（BES）存取服务。这些服务实现被称作编排或协调的功能。

最后，在一个企业整合环境中，这些更高水平协调或更低水平存取服务的大多数用户应用将不直接支持服务接口。因此，另一组服务被要求组织服务具体到每个服务用户前端系统（FES）。

这给出了分成架构的基础，如下图所示：

SOA平台层次图

这个架构中有三层。每层有唯一一组技术需求和唯一的作用。

存取服务层负责发布一组BES（后台系统）的接口作为一个标准的服务。

协调服务层重新分组服务来实现整合逻辑。

用户服务负责使FES（前端系统）可以访问其它两层发布的服务，这些服务通常是FES（前端系统）不能直接进行调用的。

1.6.2.2 存取服务层

存取服务层提供由集成平台其余部分执行的终端服务。这层的关键架构的中心是设计和管理服务的重用。设计和开发存取服务需要应用资源域的技术，适配器开发和设置技术和消息组模型技术。

存取服务层是被发布的服务来提供单一后台系统（BES）的接口，主要目标是在平台上实现最大化的重用。其它层通过控件或通过一个发布接口来存取这些服务。它最简化的形式仅仅是一个通过控件来暴露的后台系统（BES）。例如一个J2EE连接架构适配器（J2EE CA）数据库适配器被安装和设置来把一个特殊的系统和每个需要的SQL语句所产生的服务连接到一起。然后这能够通过整合应用视图控件来存储。

1.6.2.3 协调服务层

协调服务层主要是完成传递新的服务的功能，这些新的服务是对存取服务层提供服务的一个重新组织。本层的主要架构特点是灵活性。协调服务层通过正确实现数据集中、流程定义、以及创建理想服务的Message Flow工具实现了这种灵活性。

在这层中需要实现各种的集成逻辑，并发布成为一个完整的服务。本层利用访问存取层向前端系统（FES）提供有意义的服务。

任何利用多于一个EIS系统的服务都需要纳入到这一层中来。对于通过worklist实现人为交互的服务也需要纳入到本层中来。正如上文中对于访问存取层的描述，一些协作层中的服务可能仅访问一个后台系统（BES）系统。如果这些服务需要完成功能包含集成的需求而不仅仅是来自单个后台系统（BES）系统，他们也同样应台包含在协作服务层中。适用于本层的一个简单原则：任何不属于消费层或访问存取层的服务都属于协作服务层。

独立的数据集成服务，如提供数据转换、数据映射（包括主键映射）、数据依赖路由的服务需要驻留在协作层。

1.6.2.4 请求服务层

请求服务层的主要目的是负责平台和应用服务请求者（例如前端系统（FES）系统）之间的连接，本层服务提供：

协议映射－映射为服务发布接口协议：JMS和Web Services。

Paradigm映射－同步到异步以及vice-versa。

数据映射－数据格式映射，聚集等。

服务请求者包括基于多种架构的应用，还有包括胖客户端、消息系统、套接字协议等在内的遗留系统服务请求者。一般都需要协议解释服务。对于支持诸如Portal，B2B服务，多渠道等平台协议，paradigm和数据格式的请求者，可以与平台直接接口。

例如一个请求层服务收到某个前端系统（FES）发出的事件，但是这个事件不具备足够的信息来调用相应的协作层，请求服务层的服务将完成接收事件，并向前端系统（FES）查询相关信息的功能。这是一个明显的功能加强，这类场景适合于请求服务层。当然，如果这个强化的过程需要向一个独立的系统进行查询，则意味着通过一个集成过程后成为请求服务层的一个独立服务。

1.6.2.5 端到端的视角

值得指出的一点是在审视从前端系统（FES）到后台系统（BES）系统之间的端到端通信时，这些层次都不是强制必须实现的。正如前文所讲述的，请求服务层仅当需要提供对SOA平台的标准接口技术进行访问时才是必要的。若一个前端系统（FES）本身支持SOA平台的标准，那么前端系统（FES）就可以直接访问其提供的服务，而跳过请求服务层。同样的，对于一些简单的集成需求，如查询独立系统中的可用数据就不需要进行服务的重组。当然，推荐的方式是永远不要忽略访问存取层，它保证了后台系统（BES）提供的各种服务在整个平台中保持一致性和灵活性。它还避免了跳过所有层次的设计场景的出现，因此可以保证满足平台管理原则。

端到端的视角

还有一点值得一提，在一个集成场景中，很多系统既是后台系统（BES）又是前端系统（FES），当然也不排除一些纯前端系统（如Portal）和固有后端系统（如数据库）的存在。当进行双向松耦合通信（如使用JMS）时，一个双向的集成需求可以转为实施两个单向的通信。这是一个在相同业务流程中既作前端系统（FES）又做后台系统（BES）系统的例子。

1.6.2.6 设计模式和分层

存取访问层和请求访问层中以基本的服务居多，而协作层中多为复合类型的服务。

作为一个一般的规律，服务最好以无状态的方式展示以获取最佳的性能，采用异步模式调用来保持与其客户端的松耦合状态。

无论如何，已经确证若访问存取层的双向服务是异步的，协作层服务将变为有状态的。因此拥有无状态、异步服务的期望是不能在所有层中得到满足的。作为一种权衡考虑，对于双向通信场景来说，在松耦合和性能之间最好的折中方式是在低层次的访问存取层中尽可能实现同步服务（例如后台系统（BES）系统中的服务都实现同步调用），而在较高层次的协作层中实现异步服务。

高层次的设计架构	更进一步的细节
双向访问存取层的服务应尽可能的使用同步方式。	这样可以为协作层带来最佳的性能。但是注意在峰值压力下服务的响应时间应尽可能的快，且后台系统（BES）应该有能力应对这些负荷。如果不能满足上述要求，应该使用异步服务调用。
协作层服务服务通常应采用异步方式。	这样可以最大限度的做到松耦合。

上述两点可以保证包含一个请求服务层服务，一个协作层服务，以及多个访问存取层服务的双向调用典型场景的最佳性能。在这类情况中，只要后台系统（BES）接口允许，所有的除请求服务层之外的服务都采取无状态方式。

上表中第二条标准（异步协作层服务）在屏蔽后端系统实施更改方面有着突出的优势，使后端的变化对协作服务层客户端来说是透明的。无论是访问存取层服务提供同步抑或异步接口，它都可以在协作层中保留一个异步接口。

有些场景很适合同步交互模式－ Portal对SOA平台服务的访问就是其中一种。通过以下的标准可以做出是否合适与上述场景的判断：

要求端到端的响应时间。

对于请求者的最初响应取决于由目标后台系统（BES）发出的响应。

目标后台系统（BES）在峰值负荷下可以提供更快的响应。

目标后台系统（BES）需要更高的可用性。

在这些场景中，建议以同步方式实现服务，但是要借助非同步模式来为协作层服务提供异步接口。因此，那些不需要高吞吐量的客户端可以使用异步接口。

高层次的设计架构	更进一步的细节
为了更高的性能，尽可能使用同步服务。	一些用例的非功能需求需要更快的响应和更高的容量。
如果一个流程运行时间较长，需要进行它与客户端维持长会话的相应配置。	流程的会话持续时间通过它的最大寿命（max-age）属性进行配置，默认值是一天。
为同步协作层服务提供一个异步接口，提供更多的松耦合特性。	第二个接口的实现需要利用非异步模式。

在某些场景中，访问存取层服务需要异步耦合方式，例如，需要访问一个复合协作服务，而不是一个事务性、非XA的资源。在这种情况下，最佳的方式为保持访问存取层服务的同步模式，且需要以非同步模式进行实施。

高层次设计架构 更进一步的细节

如果需要异步调用一个同步存取访问层服务，保持服务的同步模式，但是以非同步方式实施。项目特定的需求不应阻碍访问存取层服务的可重用性。

1.6.3 采用通用的MVC模式构建应用

在传统的Web业务里，例如ASP，CGI等，通常开发者将业务逻辑，数据逻辑、展示逻辑等混杂在一起，在同一个页面里既进行后台数据库的访问和操作，同时还包含业务流程和页面表示。这样编写出来的程序，既不利于程序员对业务代码的调试，同时也不利于编辑人员进行交互页面的设计。同时系统也不具备可扩展性，当要在现有业务上进行扩展的时候，通常无法借助于现有的资源和应用，而只能够重新编写，大大增加了投资，延长了系统上线的时间。

在如今的企业信息化应用系统的开发中，应该采用通行的MVC模式来构建应用。这种结构解决了前面所述的所有问题，可以完全地支持它的实现。MVC的逻辑图如下：

MVC模式

通过这种方案，可以迅速地实现整个业务，其优势和特点如下：

Model层由EJB组件来实现，EJB将具体的业务封装在组件内部，具备安全、高性能、可重用等优秀的特征。

View层由JSP和HTML组成。这一层次的特点是能够真实地展示和客户交互的界面，具备可描绘的功能。同时能够嵌套动态数据，可以进行动态页面的展示。同时可以借助J2EE的标准以及相关产品方便地进行客户端的个性化定制。根据每个客户的需求来展示不同风格的界面。

Controller是非常重要的一层，这一层是连接View和Model的纽带，同时也是将这两层进行最大限度分离的工具。通常由Servlet来实现，Servlet和JSP虽然同样都属于页面展示工具，但分属两层。主要在于JSP以脚本语言的形式存在，它的主要优势是进行动态数据的Web展示，而Servlet是一个完整的Java程序，进行业务的调用和流程的处理是它的长处。

通过这种模型的建立，的应用系统具备了非常好的性能和可扩展性。将业务组件和展示页面进行分离，并通过Controller来描述调用关系，一方面可以提高效率，另一方面也可以增加系统扩充的能力，使的系统可以适应最快速度的业务扩展。

1.6.4 采用SSH开发框架实现应用

典型的J2EE三层结构，分为表现层、中间层（业务逻辑层）和数据服务层。三层体系将业务规则、数据访问及合法性校验等工作放在中间层处理。客户端不直接与数据库交互，而是通过组件与中间层建立连接，再由中间层与数据库交互。

表现层是传统的JSP技术，自1999年问世以来，经过多年的发展，其广泛的应用和稳定的表现，为其作为表现层技术打下了坚实的基础。

中间层采用的是流行的Spring+Hibernate，为了将控制层与业务逻辑层分离，又细分为以下几种。

Web层，就是MVC模式里面的“C”（controller），负责控制业务逻辑层与表现层的交互，调用业务逻辑层，并将业务数据返回给表现层作组织表现，该系统的MVC框架采用Struts。

Service层（就是业务逻辑层），负责实现业务逻辑。业务逻辑层以DAO层为基础，通过对DAO组件的正面模式包装，完成系统所要求的业务逻辑。

DAO层，负责与持久化对象交互。该层封装了数据的增、删、查、改的操作。

PO，持久化对象。通过实体关系映射工具将关系型数据库的数据映射成对象，很方便地实现以面向对象方式操作数据库，该系统采用Hibernate作为ORM框架。

Spring的作用贯穿了整个中间层，将Web层、Service层、DAO层及PO无缝整合，其数据服务层用来存放数据。

1.6.4.1 Hibernate

在传统的程序结构中，只要有一点小的需求发生改变，将意味着放弃整个页面。或者改写。虽然前期的开发速度快，除非可以保证以后永远不会改变应用的结构，否则不要采用这种结构。

采用Hibernate作为持久层技术的最大的好处在于：可以完全以面向对象的方式进行系统分析、系统设计。

1.6.4.2 Spring

DAO模式需要为每个DAO组件编写DAO接口，同时至少提供一个实现类，根据不同需要，可能有多个实现类。可以用Spring容器代替DAO工厂。

通常情况下，引入接口就不可避免需要引入工厂来负责DAO组件的生成。Spring实现了两种基本模式：单态模式和工厂模式。而使用Spring可以完全避免使用工厂模式，因为Spring就是个功能非常强大的工厂。因此，完全可以让Spring充当DAO工厂。

由Spring充当DAO工厂时，无须程序员自己实现工厂模式，只需要将DAO组件配置在Spring容器中，由ApplicationContext负责管理DAO组件的创建即可。借助于Spring提供的依赖注入，其他组件甚至不用访问工厂，一样可以直接使用DAO实例。

1.6.4.3 Struts

Struts跟Tomcat、Turbine等诸多Apache项目一样，是开源软件，这是它的一大优点。使开发者能更深入的了解其内部实现机制。

除此之外，Struts的优点主要集中体现在两个方面：Taglib和页面导航。Taglib是Struts的标记库，灵活动用，能大大提高开发效率。另外，就目前国内的JSP开发者而言，除了使用JSP自带的常用标记外，很少开发自己的标记，或许Struts是一个很好的起点。

关于页面导航，我认为那将是今后的一个发展方向，事实上，这样做，使系统的脉络更加清晰。通过一个配置文件，即可把握整个系统各部分之间的联系，这对于后期的维护有着莫大的好处。尤其是当另一批开发者接手这个项目时，这种优势体现得更加明显。

1.6.4.4 SSH开发框架

软件行业的技术更新很快，虽然软件行业的发展不快，但小范围的技术更新特别快。一旦由于客观环境的变化，不得不更换技术时，如何保证系统的改变最小呢？答案还是选择优秀的架构。而SSH开发框架正是这样一种优秀的框架。

它可以让开发人员减轻重新建立解决复杂问题方案的负担和精力；它可以被扩展以进行内部的定制化；并且有强大的用户社区来支持它。它的好处主要表现以下两个方面：

1、 开发效率

软件工程是个特殊的行业，不同于传统的工业，例如电器、建筑及汽车等行业。这些行业的产品一旦开发出来，交付用户使用后将很少需要后续的维护。但软件行业不同，软件产品的后期运行维护是个巨大的工程，单纯从前期开发时间上考虑其开发效率是不理智的，也是不公平的。众所周知，对于传统的ASP和 PHP等脚本站点技术，将整个站点的业务逻辑和表现逻辑都混杂在ASP或PHP页面里，从而导致页面的可读性相当差，可维护性非常低。即使需要简单改变页面的按钮，也不得不打开页面文件，冒着破坏系统的风险。但采用严格分层J2EE架构，则可完全避免这个问题。对表现层的修改即使发生错误，也绝对不会将错误扩展到业务逻辑层，更不会影响持久层。因此，采用J2EE分层架构，即使前期的开发效率稍微低一点，但也是值得的。

2、 需求的变更

一般来说，很少有软件产品的需求从一开始就完全是固定的。客户对软件需求，是随着软件开发过程的深入，不断明晰起来的。因此，常常遇到软件开发到一定程度时，由于客户对软件需求发生了变化，使得软件的实现不得不随之改变。当软件实现需要改变时，是否可以尽可能多地保留软件的部分，尽可能少地改变软件的实现，从而满足客户需求的变更？答案是——采用优秀的解耦架构。这种架构就是J2EE的分层架构，在优秀的分层架构里，控制层依赖于业务逻辑层，但绝不与任何具体的业务逻辑组件耦合，只与接口耦合；同样，业务逻辑层依赖于DAO层，也不会与任何具体的DAO组件耦合，而是面向接口编程。采用这种方式的软件实现，即使软件的部分发生改变，其他部分也尽可能不要改变。

1.6.5 遵循组件化分层结构设计思想构建应用

组件化是企业信息化应用系统建设的一个整体趋势。由于组件所具有预制性、封装性、透明性、互操作性、通用性的特征，这使得“Write once，Run everywhere”成为技术上的可能。

组件化的整体架构一个最明显的好处就是组件的开放只涉及到业务逻辑的开发和将业务逻辑的接口用标准的接口进行封装，而那些重要和复杂的系统基础服务（infrastructure service），如状态管理（State Management）、交易（Transaction）、安全、资源池（Resource Pooling）等等。

采用组件技术可以实现灵活的接口定义、执行代码运行时刻的联编/载入以及通讯网络协议，支持异构分布应用程序间的互操作性及独立于平台和编程语言的组件重用。

组件化的整体架构具有下面这些优势：

1）多功能容器，对外部屏蔽了复杂度；

2）适合于大量并行开发；

3）“黑盒”组件的实现鼓励了更多的灵活性；

4）可进行针对接口的测试；

5）封装后的组件在可以在内部修改业务逻辑，而保持同样的接口，形成一个屏蔽变化的“防火墙”；

6）在使用上有更好的一致性；

采用组件技术可以实现灵活的接口定义、执行代码运行时刻的联编/载入以及通讯网络协议，支持异构分布应用程序间的互操作性及独立于平台和编程语言的组件重用。

以组件为基础的应用架构大大简化多层（Multi-tier）和Web应用的开发，利用应用服务器来避免应用客户端和数据库及其它企业信息系统（Enteprise Information System，EIS）的连接。客户端使用高层（high-level）的与平台独立的调用方式通过应用服务器访问数据库及其它企业信息系统。这样不仅屏蔽了企业内部IT架构的复杂性和异构性，也使得这样开发的应用具有良好的可移植性。

系统分层模型

1.6.5.1 分层设计基本准则

1、不得跨层调用，每一层都只与直接相临的层进行通信。

2、上面各层都建立在下层的基础上，隐藏下层的信息并为上层提供服务。

3、各层要封装自己的实现，向前一层提供访问接口。

4、各层支持分布式的部署，即可部署于不同的容器实例中。

1.6.5.2 各层说明

客户层

系统最终用户的使用界面和设备。包括基于浏览器的瘦客户端和基于GUI的胖客户端应用。

1、尽量减少与后台的交互。

2、界面符合用户的使用习惯。

• 交互层

用户和系统之间的交互管理，提供用户层的展现逻辑和对应用层的访问接口。也包括单点登录、会话管理、用户输入的逻辑校验等功能。

1、客户层访问的交互协议尽可能使用http/https。

2、是客户层的统一接入点。

• 应用层

业务逻辑的接口，实现业务流程的控制，是业务领域层的服务接口。

1、可以使用类似Session的模式实现。

2、启动事务控制。

3、公共的业务逻辑要集中处理。

• 业务领域层

根据业务需求进行抽象的业务对象模型，包括业务规则和逻辑处理的实现。

• 资源访问层

对系统的各种资源和外部系统统一的访问逻辑的实现。不作语义转换，只实现纯粹的资源访问。

• 资源层（EIS）

各种信息系统资源，例如：RDBMS、文件系统、原有系统、消息服务、邮件服务、交易服务中间件等。

1.6.6 采用velocity模板引擎

Velocity是一个基于java的模板引擎（template engine）。它允许任何人仅仅简单的使用模板语言（template language）来引用由java代码定义的对象。当Velocity应用于web开发时，界面设计人员可以和java程序开发人员同步开发一个遵循MVC架构的web站点，也就是说，页面设计人员可以只关注页面的显示效果，而由java程序开发人员关注业务逻辑编码。Velocity将java代码从web页面中分离出来，这样为web站点的长期维护提供了便利，同时也为我们在JSP和PHP之外又提供了一种可选的方案。 Velocity的能力远不止web站点开发这个领域，例如，它可以从模板（template）产生SQL和PostScript、XML，它也可以被当作一个独立工具来产生源代码和报告，或者作为其他系统的集成组件使用。Velocity也可以为Turbine web开发架构提供模板服务（template service）。Velocity+Turbine提供一个模板服务的方式允许一个web应用以一个真正的MVC模型进行开发。

1.6.7 支持主流中间件及数据库

本系统支持的中间件包括weblogic、webspere在内的等主流中间件，以及包括Oracele/DB2/SqlServer等在内的业界主流大型数据库。