智慧校园校园一卡通解决方案1.1.1.系统总体设计本项目将结合学校的实际需求，为学校打造新一代校园一卡通平台，进一步提高校园的管理、服务和决策的效率及水平。
本方案一卡通的特点：✧以软件架构而不是以硬件设备为中心的校园一卡通系统；✧实现软硬分离、可集成多家厂商设备的校园一卡通系统；✧用户自主生成和管理密钥的一卡通系统；✧大集中模式的校园一卡通系统；✧插件式管理的校园一卡通系统；✧容错化设计的校园一卡通系统；✧引入通讯中间件的校园一卡通系统；✧集中式监控中心的校园一卡通系统；✧实现数据分析和挖掘的校园一卡通系统；1.1.1.1.设计原则本系统建设过程中遵循了以下原则：✧实用性：校园一卡通系统应充分体现大学内部管理的模式和特点，各应用系统的开发，应做到功能完善、使用方便、切合实际、运作高效；✧先进性：一卡通系统的建设要立足于当今世界先进且有发展前途的技术，由此实现的系统能随着未来信息技术的发展而不断平滑升级；✧可管理性：一卡通系统通过数千个终端机具来实现管理和服务功能，其管理难度大、维护成本高，系统必需从整体架构上、从具体功能上保证降低管理难度、降低维护成本、降低人员依赖，采用集中管理模式、图形化管理和监控工具，方便管理维护、出现故障能快速准确的定位问题；✧开放性：一卡通系统将随着学校业务发展而不断更新，基于性价比、厂商风险等因素考虑，系统必需采用开放的架构、开放的平台、开放的产品，提供完备的文档资料和接口程序，开放数据结构、学校掌握密钥和算法、选择国标和开放的行业标准、支持多种硬件，系统建成后学校可自行扩展升级、自主决定采购多种品牌的终端设备等；✧安全性：系统涉及资金，身份等重要的信息，应采用严格的分级管理技术，管理人员、查询人员分级按权限操作；采用多层体系架构，单层次出现故障，系统可继续运行较长时间；系统运行中间层次、中间环节不能保留敏感数据，以避免财务风险；一旦系统恢复正常运行，系统能够自动切换，无需人工干预；对于脱机运行（手持设备等）的设备，系统需要提供有效措施保障师生利益；提供审计功能，对于操作人员的各项操作进行审计；✧扩展性：系统在容量和功能上不仅能满足目前用户的需求，而且也易于扩展以保障用户今后的扩容和升级，如：卡片结构扩展、新增收费模式、增加信息点等，利用Web查询支持模块和Internet网，实现远程快速查询；✧可靠性：考虑到用卡场所情况复杂，系统必须针对交易的每个环节提供增强可靠性的措施，包括卡片可靠性设计、终端可靠性设计、布线和网络通讯可靠性设计、应用和数据库可靠性设计等全系列设计，确保系统在脱机状态下的可靠性高及在联机状态下的实时性强的要求，以及大规模并发交易情况下系统的稳定、高效和可靠性要求，避免单点故障。
✧保密性：系统设计上既充分考虑信息资源的共享，也实现了信息资源的保护和隔离，针对不同的应用和不同的网络通信环境，采取不同的措施，包括用户安全性、数据安全性、运行安全性等。
要求系统对数据传输进行加密传输，保证数据能在各个节点之间进行安全通信，保证数据传输的安全性，并且保证所采用的加密技术不可逆。
✧协调性：考虑到校园一卡通的金融特性和实时交易的特点，系统采取数据集中的架构以保证数据传递的及时性、数据的可靠性和唯一性，便于账目结算和数据准确。
✧前瞻性：系统管理平台在整体规划设计、各项技术性能指标以及采用设备产品上，既体现了现实的需求，又充分考虑了项目工程的未来发展，为后期建设留有充分发展的余地。
1.1.1.2.总体框架考虑到本系统核心为实时交易系统的特点，系统需采用多层体系架构，各层次接口清晰简单，易维护、易扩展。
下图为一卡通的整体框架：1.1.1.2.1.一卡通核心平台一卡通核心平台是系统管理的核心，它形成了校园一卡通系统的骨干。
在业务上，它实现了客户管理、商户管理、资金结算、交易处理等核心功能，是整个系统的交易和管理中心；在技术上，它实现了系统管理、系统容错、系统监控等功能，是整个系统的调度和控制中心。
它支撑和管理着各个一卡通应用系统的运行，并保证了新的应用系统的快速扩展和部署。
一卡通核心平台主要包括基础平台（客户管理、卡务管理、商户结算、现金充值、补贴发放、密钥管理、管理中心、报表管理、标准管理），监控中心（异常采集、异常分析、异常展示）三大内容。
1.1.1.2.2.一卡通数据库平台一卡通数据库平台集中管理和存储所有数据，主要包括两大类信息：✧基础信息：客户信息CIF、身份信息IIF、公共信息PIF；✧动态信息：账户信息AIF、交易信息TIF。
一卡通数据库保证了数据的一致性、完整性和及时性，最大限度地实现了信息共享。
1.1.1.2.3.一卡通应用系统一卡通应用系统是建立在核心管理平台和核心数据库之上的多个以校园卡为媒介的应用系统，主要分为四种类型：✧金融消费类。
主要用于处理校内的各种消费服务、圈存转帐等与现金有关的服务项目，比如餐饮收费、浴室收费、医疗收费、圈存转帐等；✧身份识别类。
一卡通系统中以校园卡进行电子身份认证，用以判断卡片的合法性和有效性。
可应用在门禁、图书借阅、通道控制、校门出入、考勤、会议签到、考试监管、学校老生指纹报道等重要场所；✧信息服务类。
通过多种信息渠道（网络、电话、短信），为持卡人提供校园卡的账户信息、消费数据等查询服务，为持卡人提供校园卡的挂失、转账等自助服务，为管理者提供金融数据、认证数据的分析。
流程接口类。
主要用于与图书馆、财务等第三方系统对接，实现了以校园卡为媒介的流程整合。
各应用系统相当于校园一卡通系统的前台部分，而核心管理平台则是其后台部分。
各应用系统主要借助于各种终端设备（POS机、多媒体设备等），负责各种服务信息的数据接收和初步验证，所有数据都通过通讯平台发送到后台核心管理平台进行处理和保存。
1.1.1.3.技术架构一卡通系统根据各个子系统不同的业务特点，分别选择了B/S、C/S架构。
1.1.1.3.1.C/S设计【多层技术架构图】✧架构组成⏹业务调度中心(BCC) ：业务通信平台的接入，业务优先级调度，业务提交和结果返回，多类型推送消息的支持；⏹业务处理单元(BU) ：后台数据库的连接管理，业务处理模块(BP)的集成，具体业务处理模块的调用；⏹一个业务调度中心（BCC）和多个业务处理单元（BU）组成一个业务处理组件，多个业务处理组件组成一个后台处理系统，以支持并发和容错。
✧架构特点⏹架构基于通信平台DRTP和CPACK交换技术；⏹架构采用集中并发处理技术和分布式部署技术；⏹架构和业务的独立，程序员只需要关注具体的业务逻辑实现；⏹架构采用了容错技术，可避免单点应用故障；⏹架构支持其他客户端以客户方式接收数据，如各类监控接收程序；⏹BCC平台无关，BU除数据库连接部分外也与平台无关；⏹架构支持优先级调度和各优先级可配置的LIFO或FIFO调度策略。
上图清晰的表明，本系统是构架在通讯中间件上的集中交易系统，是当前一卡通领域唯一满足学校要求的整体解决方案，与传统一卡通“就餐系统加补丁”的系统有着本质的区别，其独特的优势主要体现在如下几方面：✧集中模式⏹数据集中：除了在后台的数据库中，中间任何过程包括前置业务层、通讯中间件、应用服务器都不保留任何业务数据；⏹交易集中：所有业务逻辑处理全部集中在后台的应用服务器完成，中间过程因为没有数据支撑不能进行业务处理；⏹管理集中：业务开启和关闭、业务参数、运行监控等全部在后台集中进行。
✧软硬分离：通过标准的设备驱动封装，使本系统可以兼容多厂商的终端设备，彻底摆脱了传统一卡通系统中只能采购固定厂商设备的尴尬；✧多层集群：图中表明，终端设备并不是象传统一卡通厂商那样绑定固定的“工作站＋485卡”模式，而是寻找智能的“通讯平台”。
通讯中间件具有集群功能、且和传统一卡通的“工作站－－实际上就是服务器，因为其保留了完整的业务数据、进行完整的业务处理”不同，通讯中间件不保留业务数据，因此通讯中间件可以相互接管，即使一台甚至多台（只要由1台不停机）通讯中间件宕机，整个系统依然可稳定的运行。
这个独特的架构可以给学校带来如下好处：✧可维护性高：集中架构只需要维护中心数据库和业务系统，再配备本方案中强大的监控中心，通过图形化界面管理，使得整个系统可维护行得到了极大的增强；✧可扩展性强：简单的业务扩展只需要新增相应的硬件设备，复杂的业务扩展也只需要在管理中心进行数据库和业务逻辑升级即可；✧更安全可靠：由于实现了集中模式，整个系统不存在单点故障、不存在操作人员改帐的财务风险，使整个系统非常安全、稳定和可靠；✧运营成本低：⏹统一的后台管理，避免了分布式数据管理的风险和投入；⏹图形化监控中心，使整个系统运行状态一览无余，发现问题主动报警使管理人员能够在第一时间准确定位，不需要传统一卡通系统要求的“每个食堂一名联络员”，从而最大限度的节约了人力成本。
1.1.1.3.2.B/S设计对于部分B/S架构的子系统，我们采用了主流的跨平台的J2EE架构，该通用架构特点不再熬述。
1.1.1.4.积木式设计1.1.1.4.1.设计思路一卡通不同的业务系统，就如同一个个完整的电脑插件，需要的时候，“插”到一卡通核心平台上，扩展其应用；在不需要的时候，可方便的从一卡通核心平台上“拔”下来，停止相关应用。
同时，一卡通核心平台提供通用标准接口，第三方系统可按照通用标准接入；也可按照与第三方约定标准，采用定制标准接口接入第三方系统。
1.1.1.4.2.选配方法一卡通只需要采用基础平台，与任何一个或多个内容（这些内容包括：监控中心、金融消费类子系统、身份识别类子系统、信息服务类子系统、流程整合类子系统）进行组合，即可建成扩展功能或应用的快速升级。
1.1.1.5.并发性设计一卡通业务系统核心在业务处理过程，可将不同的业务处理封装成独立的业务处理单元，业务单元之间彼此独立，互不影响。
这些不同封装而成的业务单元，可按需分配组合成不同的业务群。
业务群与业务群可以相同，也可以不同。
这些组合而成的业务群，部署在不同应用服务器上，通过业务调度中心统筹进行调度不同的业务处理单元进行业务处理。
下图为并发性的实现示意图。
1.1.2.系统功能方案一卡通系统的核心是应用软件建设，而应用软件最终体现在设计的业务功能模块在多大程度上满足设计目标、设计原则的要求。
结合同行教训和国内外的成功案例，结合在学校调研中各部门的意见和建议，我们设计了如下的功能结构：基于构件化思路开发的校园一卡通系统已经形成了功能完备的标准化功能模块库，完全覆盖了学校的实际需求，其中许多功能模块客户目前尚使用不到，另外一些模块尽管名称和客户要求的类似、一致，但是功能已经远远超越了传统一卡通的范畴，还有一些功能进行了更加合理的部署―――可能进行了功能合并、功能拆分等。