前置机系统详细设计方案1.系统概述前置机系统的主要功能是预处理、存储和转发来自金融端末设备( POS. )，或者服务网点的交易请求，从而完成整个电子支付交易。
整个电子交易系统是一个三级的客户/服务器（CLIENT/SERVER）模式。
前置机处于整个系统的第二级，起到了承上启下的重要作用，它既是终端设备的SERVER，又是后台主机的CLIENT。
前置机具有复杂多变的接口，要求有较好的通用性、可靠性和高效率。
2.系统结构整个前置机系统可以分为交易接口、交易处理核心、系统管理、监控系统四大部分。
结构框图如下：3.处理模式和交易类型处理模式前置机与客户端之间，通过两次通讯完成一次交易，以减少通讯量。
首先由客户端发起请求，将相关数据( 交易码，交易数据，MAC 等) 送往前置机，前置机预处理完毕，将结果返回客户。
交易类型前置机处理的交易类型按终端设备可以分为:银行网点的终端设备：签到、签退、圈存、圈提、查询、转帐、下传黑名单和改密。
指定医疗机构的前端：签到、签退、查询、转帐、批上送、下传黑名单和改密。
商户终端设备：签到、签退、下传黑名单、查询、转帐、批上送和改密。
圈存机：签到、签退、圈存、圈提、下传黑名单和查询。
业务流程脱机业务流程联机业务流程4.交易接口目前系统与客户端的交易接口支持TCP/IP (包括中间件模式)和串口两种模式。
TCP/IP 方式通过对套接字socket 进行操作，或中间件模式完成数据的传输。
适用于客户端各种主机与前置机之间不同操作系统的通讯。
TCP/IP 方式如下图所示：Service_1 Service_2 .... Service_N守护进程Tcp_Server 通过fork( )调用,复制自己来处理不同的请求，以达到并行处理的目的。
考虑到fork()的调用在交易高峰期过多子进程的生成会导致系统在进程的切换和系统调用上占用过多资源, 在监控模块中采取一定的措施控制其子进程的个数，这将在监控模块中详细讨论。
中间件模式采用固定的通讯格式完成数据的传递.串口方式主要针对销售终端、指定医疗机构( POS ) 上送的交易请求，对通讯端口进行读/写操作，完成交易。
销售终端一般是通过网控器(NAC)与主机的端口进行联结，它们之间的数据格式遵循ISO 8583 的标准。
这对磁卡和IC卡同样适用。
这种方式用于处理销售终端、指定医疗机构( POS ) 经网控器( NAC )上送的交易。
串口方式如下图所示：接收进程负责从端口读取上送的信息，发送进程将处理结果写到通讯端口，它们与守护进程之间通过消息队列进行数据交换。
网控器可以有多个上行与下行板，为达到并行处理的目的，对应于每个通信端口，各启动一对相互独立的读／写进程对其操作，提高了系统效率。
5.交易处理核心IC 卡的交易是一种脱机交易。
营业点、指定医疗机构将这些脱机交易批量地上送到前置机，经交易处理核心的预处理后，转发给后台主机；由主机修改相应的帐户资料，并进行汇总，统计和清算。
所以，交易处理子系统是整个IC 卡系统的关键，它包含交易处理守护进程，安全认证，交易日志的管理和交易转发模块，与其它的相关子系统的关系如下：交易处理守护进程与接口守护进程一般是通过消息队列进行通讯，或者两者融为一体。
前置机系统的主要任务是预处理和转发批量的脱机交易数据，在设计交易处理子系统时，必须具有较高的处理速度和能力。
以下的系统设计过程中，都以实现这个目标为前提。
交易处理模块由于存在两种不同的通信接口方式，相应地，在前置机系统的交易处理模块分别采取了消息驱动与Fork ( )子进程的形式处理来自这两种接口的交易。
消息驱动这种方式将传统意义上的应用( 服务进程)根据不同的功能，相互独立起来，各个子服务进程( Services )之间读取消息队列中某一特定类型的交易消息，与不同的请求( 客户端的消息源) 建立有机的联结，处理交易后并将结果返回。
消息驱动的方式适用于不同操作系统之间的TCP / IP 通信。
交易处理流程(1) 客户端发起请求。
(2) 接口守护进程收到请求后,送往交易消息队列。
(3) 应用进程从交易队列中读取交易信息,进行处理。
(4) 应用进程将结果返回客户端。
(5) 应用进程将结果送往监控消息队列。
(A) 注释(1) TCP 接口守护进程接收到客户的请求后， 将其交易请求，通讯端口标识与相应的交易数据送往交易消息队列 。
然后继续新的监听。
(2) 各相应的服务进程( 如 批上送接收Batch_Recieve ， 下传黑名单Download_Blacklist ， …等，以下称为服务 Services ) 从交易消息队列 中读取请求进行处理，将结果返回客户。
同时，将交易内容及其处理结果送往监控消息队列 E 。
(3) 交易服务进程处理完交易，将结果送往实时交易监控消息队列。
实时交易监控进程从监控消息队列中读取信息， 转换后写到实时交易监控窗口 。
(B)实现BEA 系统有限公司在企业中间件方面的产品在金融领域倍受青睐。
该公司的中间件产品Tuxedo 具有联机交易能力，强大的消息处理功能以及面向对象的特点，能最大限度地利用系统资源，可以使用户快速地开发新的应用，同时保护原有的投资。
另外，Tuxedo 自带的冲正功能，为客户／服务的交易模式提供了交易完整性的保证。
用户只需要编写相应的客户和服务端的应用，无需考虑通信过程。
Tuxedo 可以支持现流行的各种不同的操作系统，为以后的业务扩展打下基础。
Fork 子进程交易处理守护进程接收到请求后，通过fork( )调用，复制自己调用不同的服务来处理不同的请求，以达到并行处理的目的。
子进程处理完毕，将结果回送相应的通讯端口，并写监控消息队列。
这种方式用于处理销售终端( POS ) 经网控器( NAC )上送的交易。
21 6(A) 交易处理流程(1) 销售终端 ( POS )经网控器发起请求。
(2) 接口读守护进程通过通信端口从网控器收到请求后,解包后送往交易消息队列。
然后继续新的监听(3) 交易处理守护进程从交易队列中读取交易信息, 调用Fork ( )复制自己，进行处理。
父进程继续新的监听。
(4) 子进程处理后将结果写交易结果消息队列。
(5) 子进程将处理结果写监控消息队列。
(6) 接口写进程从结果消息队列中读取处理的结果，打包并写通信端口。
由网控器将信息返回销售终端。
(B) 销售终端( POS )与接口读/写守护进程之间的交易数据格式遵循ISO 8583 标准。
(C) Fork( ) 方式不易控制服务进程的数量 ， 且每次复制自己时需占用较多的系统资源 。
在实现时，应对此作了一些安全性( 保护性 )的控制。
批次号的管理接收客户端批量上送的脱机交易，是前置机提供的主要服务。
前置机通过对批次号的管理来保证接收到的数据的正确性。
批次号是此批上送数据的唯一标识，批上送接收服务进程接收到客户端的数据后，将先检查此批次号的数据是否已被处理过。
如果曾被处理，则直接将成功的结果返回。
在前置机上建立一记录批上送信息的流水帐表，如有新的批上送业务，处理成功后保留其批次号和此批交易的总笔数与总金额等信息。
用流程图的方式表示此处理逻辑：与此相对应，客户端进行批上送时，要保证以下几点：(1)此批数据是未被上送或上送失败的；(2)此批数据的批次号是唯一的；(3)每批数据的内容是固定的。
也就是说，如果某批数据上送不成功，又有新的业务发生，此时新交易只能作为下一批。
安全认证模块安全认证是交易的必不可少的部分，也是业务发展的要求。
每笔交易都需经安全认证系统的校验。
校验信息( MAC )的生成主要采取基于DES 的X9.9 标准算法。
如果在交易过程中出现“信息校验错”，前置机将产生一新的MAC_KEY 和PIN_KEY , 经黑盒子的加密后下传，同时更新数据库中的数据。
客户端( 销售终端或商户PC )用保存的主密钥对其解密，作为计算下次通信MAC的MAC_KEY 。
有关“黑盒子”和密钥管理系统，在这里不作进一步的讨论。
交易转发模块交易转发有实时转发（联机交易）和临界值转发（脱机交易）两种方式。
通过修改参数文件的配置或根据交易信息来实现两者之间的转换，兼容以前的磁卡交易。
可以流程图的方式表示如下:否从区域（全国）联网的角度出发，前置机应提供动态的路由寻址，可将不同区域的不同卡种的交易转发到目的地，由不同的台主机进行处理。
（区域标识，卡种）这一二元组决定交易的目的地址，作为系统的动态参数，可随时更改适应不同的需求。
对于脱机交易的批上送，需启动一批处理守护进程( Batch_Server )接收批上送接收服务进程发来的消息，判断已处理的交易笔数是否已达到临界值（每批上传到后台处理的交易笔数），以便搜索数据库，将未上送的脱机交易打包，送往后台中心。
交易处理子系统返回给客户端的结果并不是真正的实时记帐的处理结果。
考虑到批上送的并发性对数据库的影响，批处理守护进程( Batch_Server ) 只是将数据库中未处理或上送失败的脱机交易分段，找出这些记录的起止序号等信息送往批处理消息队列。
它只是一个分派任务的进程，对数据库不做任何修改。
上送服务进程( Batch_Send ) 从批处理消息队列中读到消息后，按起止顺序号查找流水帐并锁住这一批记录，按照约定的格式打包发送，并根据中心返回的结果修改流水帐或记录异常流水。
Batch_Server 和Batch_Send之间的关系如下:批处理守护进程( Batch_Server )每次启动时先查找流水帐，统计库中未处理的交易，防止由于上次(异常)退出时批处理消息队列中未处理的消息长时间未得到处理。
上送进程( Batch_Send ) 利用通信平台Tuxedo 提供的函数，与IC卡后台主机的服务进程建立联结，完成批上送的任务。
交易日志凡涉及更改数据库的交易，须写日志文件或者记录到交易流水帐中，以备以后的核对和查询统计。
如果在交易过程中出现错误，在日志文件有详细的记载。
交易冲正由于系统的模式为客户/ 服务型，不可避免地遇到交易冲正的问题:(1) 客户方由于超时无法将交易发往服务方;(2) 服务方无法将结果回送给客户方。
对于前置机上述情况的交易冲正，由中间件Tuxedo 内部机制完成，保证交易的完整性。
但对于串口的通信方式，只能由客户端( 主要是POS )的超时控制来实现，重做此次交易。
6.监控子系统作为一个完整的监控系统，应包括实时交易监控，系统资源和守护进程的监控三大部分，它们是相对独立的。
实时交易监控实时交易监控从监控消息队列中读取信息，经过格式转换后，将其写到实时交易监控窗口上。
通过实时交易监控，可以查看当天的最后一批交易处理的时间及结果，相应的统计信息( 如总笔数，总金额等)。