4. 方案特点

    支持柜员交易大前置和网点柜员前置部署----综合业务系统的柜员前置的部署方案一般分为两种，一种是采用柜员交易大前置方式，即把柜员前置部署在成员行数据中心，网点只有终端。在这种部署方式下，成员端平台的柜员系统也安装在数据中心，通过socket通讯与成员端平台前置的通讯接口进行数据交互；第二种是网点柜员交易前置方式，即柜员前置按网点部署，每个网点均有柜员交易前置系统（一般为PC）。在这种情况下，成员端平台的柜员系统安装在网点的前置上，同样通过socket通讯与成员端平台前置的通讯接口进行数据交互。

柜员系统无缝嵌入----成员端平台的柜员系统不使用数据库、通讯中间件等第三方软件产品，只要有Unix系列的操作系统，网络能通，网点使用字符终端，该系统就能够运行。同时柜员系统具有完整的画面控制、设备参数驱动、数据通讯处理。各成员行的原综合业务系统的柜台前置系统，只要能够提供system调用，并释放终端外围设备的控制，就能够运行成员端平台的柜台系统，当成员端平台的柜台系统退出后，释放所有的资源（包括通讯资源、设备资源），让成员行的综合业务系统的柜台前置系统继续接管，完成无缝的嵌入应用。

成员端平台前置系统灵活的架构设计-----成员端平台前置系统采用模块化设计，所有模块划分为两类：基础应用模块和扩展应用模块。基础应用模块构成成员端平台前置系统的运行核心，提供与业务无关的处理逻辑，是前置系统的框架部分，构建出前置系统的运行环境；扩展应用模块与具体的业务密切相关，能够实现具体业务的处理逻辑。基础应用模块和扩展应用模块处理所需的输入数据及输出数据都是通过命名的内部报文传递。这种设计架构是实现“小核心大系统”的基础。

    成员端平台前置扩展应用模块是由子交易构成，面向的是内部报文，因此，子交易对外的输入和输出数据组织结构均相同，子交易只需要专注于自身的业务功能实现，不需要考虑其输入和输出的改变对其他子交易的影响。模块主体采用标准化处理流程，开发者使用系统提供的模块标准模板，非常容易构建出一个扩展应用模块。这种设计能够保证模块的稳定性，保持子交易间的数据隔离，对任何扩展模块的修改决不会影响其他应用模块，在扩展新业务的同时不会对原业务产生不良的影响。

成员端平台前置系统灵活的流程控制----扩展应用模块是子交易的集合，我们把处理相同或相似业务的子交易划分在同一个扩展应用模块中，子交易的功能非常单一，基本上不可能单独完成一个完整的业务处理，成员端平台前置系统的脚本语言就是通过脚本的描述，把不同单一功能的子交易有机组合，实现复杂的业务逻辑。

    流程控制的基础包括两个部分：脚本语言和脚本解释器。脚本语言提供一种二次开发语言，实现开发者定制业务处理流程。通过脚本语言，开发者可以定义变量，常量，可以访问数据库，可以对内部报文进行操作，可以调用所有扩展应用模块的所有子功能。脚本语言还提供逻辑判断运算，数值和字符串操作，并能够透明访问内部报文的所有域（与访问字符串变量完全相同）。

    成员端平台前置系统对于脚本的执行并非采用解释执行方式，编写好的脚本语言需要使用系统提供的脚本编译器，对脚本进行语法、语义的检查，并调用C语言编译器，最终生成操作系统可以识别的二进制代码片断。脚本解释器就是访问这些二进制程序，并严格按照脚本的逻辑进行交易的调度。这种实现方式能够大大提高脚本的执行效率。

    众所周知，对于某一个相同的业务，在不同的成员行之间的肯定会存在不同的处理流程，我们通过这种业务流程的描述（脚本），来实现各成员行的业务处理特性。

通用的帐务访问接口----在和核心业务系统的帐务接口设计上，成员端平台前置系统秉承我们一贯的设计原则，即通用性和灵活性，来实现成员端平台与核心业务系统之间的数据交换。

    单边记帐设计和会计分录相结合，可以灵活定制所有业务的记帐处理。所谓的单边记帐并非是在业务记帐时，一次只记一边，而是理解为成员端平台前置系统在组织帐务记帐处理时，根据会计分录配置，一次只组织该套会计分录中的一条，在把所有的分录完整发送到核心业务系统后，才提交记帐请求。因此，在核心业务系统的通用帐务接口实现上，继续保持帐务处理的完整性和一致性。

    这种实现方式，可以提供灵活的记帐处理，满足不同成员行之间略有不同的会计核算。

业务安全性有保障----该设计方案对业务安全控制严格，业务安全包括操作员权限控制、客户密码管理、业务授权管理及数据传输安全管理。

    成员端平台的柜员系统采用嵌入原业务系统的柜员前置中，在调用成员端平台的柜员系统时，通过命令行参数传递柜员号信息，该信息将通过通用帐务接口传递到核心业务系统，由核心业务系统对操作员的权限、状态等统一管理。某些业务需要输入客户的密码，在成员端平台，密码采用柜员系统和综合网关系统自有的密码加密算法进行加密处理，在综合网关系统的内部报文中不保存明文，在所有的登记表中也不对密码域进行解密处理和保存。因验证需要，可由综合网关系统进行密钥转换，还是以密文的方式，转换为由核心业务系统PIN-KEY加密的密文，交给核心业务系统进行验证处理。

    业务授权还是由核心业务系统完成。

    柜员系统和综合前置系统之间的报文传输采用MAC算法，对报文进行正确性验证。综合前置系统与核心业务系统同在一个局域网内，数据在网络上的传输无需进行加密处理，采用明文方式传递。成员端平台与前置系统也同在一个局域网内，均采用明文直接传输。

7×24支持----成员端平台前置系统设计能够满足7×24服务，通过对系统状态的管理，实现不间断的服务。