前置机系统详细设计方案
综合前置系统解决方案
综合前置系统处理方案一、系统概述伴随银行同业之间竞争旳日趋剧烈，新旳业务品种、新旳金融工具曾出不穷，银行也在服务渠道旳整体概念理解上发生了很大旳变化，统一渠道已经是一种很明显旳趋势，所谓统一渠道即将前端旳应用系统在前置系统上进行整合。
Bankware ICI是基于Client/Server旳系统架构，以BCSS基础平台为基础，负责管理银行所有旳交易渠道，完毕交易路由、格式转换、合法性检查、一致性保障等任务，为基于一种机构和多种机构旳系统提供完全旳转接服务。
作为中心互换关键，Bankware ICI将银行旳各个系统有机地结合在一起，具有通讯管理、设备管理、任务管理、报文格式转换、交易路由选择、事务冲正处理、顾客终端服务等功能。
本产品旳模块化构造设计和良好旳通用性与易用性使Bankware ICI能很轻易地完毕外部网络旳接入，也很轻易连接外部主机。
作为国内优秀旳综合前置系统应用软件，Bankware ICI是银行系统整合处理方案、中间业务处理方案旳首选平台，并能为银行未来金融业务旳拓展提供强有力旳支持。
系统网络拓扑图如下：系统构造：Bankware ICI由基本应用模块和扩展应用模块构成。
基本应用模块是整个综合前置应用旳旳基础，是系统旳框架部分，它重要由如下几种部分构成：1、交易流程控制（TFC）2、通讯服务（CMS）3、格式转换（FCS）4、存储转发（SAF）5、交易日志（TJS）6、管理和监控（MAV）7、顾客终端服务（UTS）8、数据安全（DSS）扩展应用模块为综合前置系统旳应用扩展，它完毕了详细业务旳处理逻辑，是综合前置系统处理面向详细交易旳处理模块，它可根据业务旳需求随意增长和删除，是在基本处理模块框架下实现插件式旳应用扩展。
系统功能：1、交易流程控制系统关键，面向内部交易报文。
包括系统总控和脚本解释器两部分。
系统总控根据交易旳一般特性来驱动交易，并通过触发存储转发机制来负责保证交易旳一致性。
商业银行综合前置系统的设计与实现
（ ｃ ｏ ｌ ｆ ｎｏ ｍａｉｎＳ ｃ ｒ ｙＥ ｇｎ ｅ ｎ ， ｈ ｎ ｈ ｉ ｉ ｔｎ ｎ ｖ ｒｉ ， ｈ ｇ ａ ０ ２ ０ Ｓ ｈ ｏ ｆ ｒ ｔ ｅ ｕ ｔ ｎ ｉｅ ｒ ｇ Ｓ ａ ｇ ａ ａ ｏ ｇ Ｕ ｉｅｓ ｙ Ｓ ａ ｈ ｉ ０ ４ ） ｏＩ ｏ ｉ ｉ Ｊｏ ｔ ｎ ２
环境 中提供通信协议转换 。 （） ２交易 目标 ：对于收到的每一笔交易信息 ，对数据进行 检查处理 ，对有效报文 ，完成银行主机和各业务单位之间的
数据格式转化 。 （） 监控 ：对所有交易都有跟踪 监控 ，可 以方便地了 ３跟踪 解系统运行情况和交易情况。 （） ４能满 足各种不 同中间业务 的需要 。无论是代理现金或
ｓ ｓ ｅ ｂａ ｅ ｏ ｎ ｅ ｅ ａｅ ｂ ｓｎ ｓ ． ｉ ａ ｒ ｘ ａ ｉ ｔｓ ｏ ｈ ｙ ｔ ｍ’ ａ ｗｏ ｋ ｆ ｎ ｔ ｎ ｅ ｕ ｔ ． ｅ ｐ ａ ｔ ａ ｙ ｔｍ ｓｗｏ ｋ ｎ ｌ ｙ ｔｍ ｓ ｄ ｎ ｉ ｔ ｒ ｄｉｔ ｕ ｉ ｅ ｓ Ｔ ｓ ｐ ｐ ｐ ｔ ｅ ｎ ｔ ｅ ｓ ｓｅ Ｓｆ ｍｅ ｒ ， ｕ ｃ ｉ ａ ｄ ｓ ｃ ｒ ｙ Ｔ ｒ ｃ ｉ ｌｓ ｓｅ ｉ ｒ ｇ ｗｅ ｌ ｍ ｈ ｅ ｅ ａ ｒ ｏｎ ｉ ｈ ｃ ｉ ｉ ｎ ｏ ｎ ｏ ｅ ｃ ｍｍｅ ｃ ａ ａ ｋ ｎ Ｗ．Ｔ ｅ ｓ ｓ ｅ ｉ ｏ ｎ ｙ ｃ ｍ ｐ ｔ ｅ ｗｉ ｌ ｎ ｅ ｅ ａｅ ｂｕ ｉ ｅ ｓ ｒｉｌｂ ｎ Ｏ ｈ ｙ ｔ ｍ ｓ ｎ ｔ ｏ ｌ ｏ ａ ｉ ｔ ｏ ｄ ｉ ｔ ｒ ｄｉｔ ｓｎ ｓ ，ｂｕ ｌｏ ｃ ｎ ｍｅ ｔ ｔ ｅ ｄｅ ｎ ｆ ｂｕ ｉ ｅ ｓ ｂｌ ｈ ｍ ｔ ａ ｓ ａ ｅ ｈ ｍａ ｄ ｏ ｓｎ ｓ ｄ ｖ ｌ ｐ ｎ ， ｔ ｒ ｖ ｄ ｓｔ ｅ ｓ ｐ ｏ ｔｆ ａ ｋ ｅ ｅ ｏ ｍｅ ｔ ｉ ｐ ｏ ｉ ｅ ｈ ｕ ｐ ｒ ｂ ｎ ． ｏｒ
网管前置机综合管理系统的分析与设计
系统对前置机进程的管理采取手工和自动相结合的方式遥 在前台 客户端可以手工一键查看前置机目前运行的所有进程袁也可以一键重 启该前置机的所有进程遥 同时在服务器端通过设计程序袁定时的检测 前置机运行的每个必需的进程遥 如果发现某进程不存在袁自动触发重 启机制袁重启该进程遥 同时将该过程记录日志文件袁以备后查遥 2.5 前置机的空间管理
3 总结
本系统在实际的设计过程中袁 采用测试和设计相同步的原则袁边 测试袁边设计遥 对各个模块分别测试袁通过测试改进程序遥 整个程序设 计完成后再采用综合测试的方法袁对整个产品的各种功能进行整体的 测试遥 经过测试袁本产品基本上实现了原定的功能遥
系统设计完成后袁通过本系统可以对整个前置机进行实时监控和 有效的管理维护袁及时发现前置机运行中的各种故障并对部分故障进 行自恢复袁减少了故障的恢复时间遥 有效的保障了网管支撑系统的正 常运行遥 有力的支持了公司运维体制的改革遥
目前这 6 台前置机全部由普通服务器承担袁 受其他条件的限制袁 这几台服务器全部单机运行袁无法实现双机备份遥 因此一旦某台前置 机发生故障袁势必会造成一些设备不能正常监控或者固话激活系统的 某几个交换局不能正常使用电子工单遥 为了避免该类情况发生袁只能 尽力避免前置机发生故障或者在发生故障后能够及时发现袁 及时处 理遥 但是目前前置机还没有统一的管控平台袁故障不容易被及时的发 现和处理袁一旦发生故障袁往往时间较长遥
由于该系统采用 C/S 的结构袁 因此考虑使用习惯和兼容性的问 题遥前台客户端程序安装运行在 windows 平台的 PC 机上遥 机器的配置 满足 CPU 2.60GHz袁内存 1G 以上即可遥 后台服务器端程序运行在前置 机的 linux 平台上遥 1.3 程序设计语言的选择
多渠道综合前置系统设计和实现
多渠道综合前置系统是一个连接服务渠道和银行服务（或其他附加服务）的中间转接平台，从网络连接和数据交换的角度来看，起着网络路由器（或者交换机）类似的功能。
多渠道综合前置系统把所有对外的接口都形成标准化，特别是针对银行业务主机、第三方服务机构，通过统一的标准化接口可以减少不同接口之间数据转换的成本，提高数据的处理效率。
对于无法统一的数据接Ｅｌ也需要提供参数化的数据格式转换模块来完成数据接口的自动化处理。
３．２．２系统总体逻辑模型
在总体系统结构设计中，严格遵循通讯接入、应用处理、数据存储三层设计模式，保证在各个层面的线性扩展能力，便于安全分层控制，从而提高整个系统的可扩展性和安全性。
图３－２：ＭｌＦｓ系统的总体层次逻辑结构
数据处理层由数据库服务器、数据存储文件共享空间服务器和存储系统组成。
基础设施层构成了交换系统的ＩＴ基础架构，包括网络、主机和操作系统，操作系统采用开放式Ｕｍｘ系统。
数据处理层由ＤＢ２企业级数据库（也可以根据银行的要求选择Ｏｒａｃｌｅ或者其他关系数据库）为应用层提供数据处理服务。
为获得最有效的负载均衡能力、更好的系统可用性和可扩展性、成熟高效的进程间通信机制，并提供更有效的运行管理和监控手段，在应用层和基础设施层引入了中间件层。
对于典型的ＯＬＴＰ处理，如联机交易处理子系统采用Ｂｅａ公司的Ｔｕｘｅｄｏ。
前置机详细设计方案
前置机详细设计方案概述前置机是指在企业应用系统与网银系统之间，建立一个安全、稳定、高效的网关，以实现企业日常业务与银行业务的无缝对接。
本文档将详细介绍前置机的设计方案。
系统角色前置机作为企业应用系统与网银系统之间的网关，主要由以下三个角色组成：1.企业客户端：企业内部的报文生成系统，通过业务通信协议向前置机发送业务数据。
2.网银系统：银行内部的报文接收系统，通过网络接口接收前置机发送的业务数据。
3.前置机：作为企业客户端和网银系统的网关，负责报文的解析、加密、路由等任务。
技术架构前置机的技术架构主要分为以下几个部分：1.硬件架构：前置机采用高性能、高可靠性的服务器，保证报文处理的稳定性。
2.软件架构：前置机采用Java语言编写，运行在Tomcat应用服务器中。
通过Spring框架实现业务逻辑与底层资源的解耦，以及Mybatis框架实现数据持久化操作。
3.安全架构：采用HTTPS加密传输报文，基于数字证书实现认证和授权，保证报文传输的安全性。
4.业务架构：采用业务通信协议（XML或JSON格式）实现企业客户端与前置机之间的数据交换。
采用银行网络接口协议实现前置机与网银系统之间的数据交换。
报文处理流程企业客户端通过业务通信协议向前置机发送报文，前置机接收到报文后，进行以下处理：1.报文解析：前置机对报文进行格式校验和解析，以确保报文的完整性和正确性。
2.报文加密：采用HTTPS加密协议对报文进行加密，保证报文传输的安全性。
3.报文路由：根据报文的业务代码和银行账户信息，将报文路由到对应的网银系统。
4.网银系统响应：网银系统接收到报文后，进行业务处理，并生成响应报文。
5.响应报文处理：前置机接收到响应报文后，进行格式校验和解析，并将响应报文加密后返回给企业客户端。
数据库设计前置机的数据管理采用MySQL关系型数据库，用来存储企业客户和银行账户信息，包括以下几个表：1.企业客户信息表–客户编号–客户名称–客户类型–联系人姓名–联系人电话–联系人邮箱2.银行账户信息表–账户编号–账户名称–账户类型–银行名称–分行名称–支行名称–联系人姓名–联系人电话–联系人邮箱3.业务报文日志表–交易流水号–报文类型–报文内容–报文状态–报文时间本文档主要介绍了前置机的设计方案，包括前置机的系统角色、技术架构、报文处理流程、数据库设计等方面。
前置机方案书
前置机方案书(总3页)本页仅作为文档封面，使用时可以删除This document is for reference only-rar21year.March为了保证内网安全，防范摆渡木马、防止失泄密事件的发生，前置机主要实现了以下功能：1、具有强大的木马、病毒查杀功能：凡外来信息要进入涉密内网，首先要经过前置机进行木马、病毒查杀处理，能够实现接入用户选择的国内外主流杀毒软件，对外来磁介质进行木马病毒查杀，并能够根据用户需要实现双杀毒功能。
杜绝木马、病毒感染到涉密内网，造成失泄密事件或因感染病毒引起的网络安全隐患。
2、实现外来磁介质到涉密磁介质点对点的单向信息拷贝：前置机实现了外来磁介质的信息单向直接拷贝到涉密内网磁介质。
3、网络安全摆渡机利用触摸式一体机，实现了防范摆渡木马启动、查杀木马病毒的功能，实现外来磁介质与可管理内网磁介质之间的文件信息单向交换，摆渡磁介质之间信息传递单向点对点盘对盘的功能，有效防止了交叉失泄密事件发生的可能，并且实现了日志记录.摆渡审计等功能。
解决了利用普通电脑摆渡无法解决的失泄密隐患问题。
适用范围：1、有涉密单机、涉密内网的单位如存在涉密单机、涉密内网和互联网，需要在不同形态网络、主机之间频繁进行数据交换。
2、对外服务的窗口服务部门，经常需要与外来单位交换数据。
3、与其他单位有文件或数据交换需要的企事业单位或党政军单位。
摆渡要求：1）用户需要先对内部涉密磁介质在网络安全摆渡机上进行注册登记。
可以配置专用摆渡涉密内网磁介质，也可以使用用户原来在桌面审计系统已管理的磁介质。
外网磁介质可以使用专用磁介质，也可以使用原来使用的磁介质。
2）数据摆渡步骤如下：（a）先插入外来磁介质，（b）网络安全摆渡机对外来磁介质自动进行木马病毒查杀；（c）完成木马病毒查杀后，再插入内网摆渡磁介质；（d）进行盘对盘的数据拷贝。
5、实施后效果通过实施此套安全信息交换系统，有效的防止了摆渡木马、病毒传入涉密内网，确保传入内网信息的安全性，保证了内网的安全，杜绝了涉密内网的失泄密隐患，加强了单位信息交换的管理，提高了信息交换的效率。
银行前置系统的设计与开发
银行前置系统的设计与开发【摘要】银行前置系统是银行业务中至关重要的一环，本文围绕银行前置系统的设计与开发展开讨论。
首先进行了银行前置系统的需求分析，明确了系统的功能和性能要求。
然后详细介绍了银行前置系统的架构设计，包括系统的整体结构和各模块之间的关系。
接着对系统的功能模块进行了分析，包括用户管理、账户管理、交易处理等方面。
随后探讨了银行前置系统的技术实现，包括数据库选型、编程语言选择等内容。
最后对系统的性能优化进行了总结，并提出改进建议。
通过对银行前置系统的设计与开发进行探讨，可以提高系统的稳定性和效率，为银行业务的顺利进行提供支持。
【关键词】银行前置系统，设计与开发，需求分析，架构设计，功能模块，技术实现，性能优化，总结。
1. 引言1.1 银行前置系统的设计与开发概述银行前置系统是银行信息化建设中的重要组成部分，也是银行和客户之间信息交互的关键平台。
设计与开发一套高效可靠的银行前置系统，对于银行提升服务质量、增强竞争力具有重要意义。
银行前置系统的设计与开发过程中，需要充分考虑银行业务的特点和需求，结合最新的科技发展趋势，确保系统稳定、安全、高效运行。
该系统的设计与开发工作，不仅需要技术人员的深厚专业知识和经验，还需要团队合作、沟通协调，以确保项目顺利完成并达到预期的效果。
在银行前置系统的设计中，需充分考虑系统的可扩展性、灵活性和安全性，以适应未来业务发展的需求。
在开发过程中，需要充分了解银行业务流程，深入分析用户需求，将用户体验放在首位，确保系统稳定可靠。
在技术实现上，可采用先进的技术手段，如云计算、大数据、人工智能等，提升系统的性能和效率。
通过银行前置系统的设计与开发，可以提高银行的信息化水平，提升客户对银行的信任度，增加银行的竞争力，推动银行业务的持续发展。
银行前置系统的设计与开发工作至关重要，需要全力以赴，确保系统的质量和效果。
2. 正文2.1 银行前置系统的需求分析银行前置系统的需求分析是整个设计与开发过程中的第一步，它的目的是明确系统需要满足的功能和性能需求，为后续的架构设计和功能模块的开发奠定基础。
某银行省级分行应用前置系统整合方案
某银行省级分行应用前置系统整合方案自2000年起，某银行开始了生产业务的大集中工作——将银行省级分行的业务主机收至各大中心，分行仅保留大量的应用前置机，运行行内各种辅助业务系统。
这一举措实施以来，系统资源和人力资源的调配与使用更加合理，银行的整体管理能力和市场竞争力也得到了相应提高。
但在此项工作开展的同时，该银行也遇到了三大严峻的挑战。
银行省级分行在“大集中”后仅留有大量的应用前置机，运行着行内各种辅助业务系统。
由于各种开发及运行环境因素造成的系统不同，这些前置系统分布在大大小小几十台机器上，它们的硬件平台、操作系统和应用软件版本各不相同，系统的维护工作量很大。
在银行实行“大集中”运营管理模式之后，分行的技术人员上调造成的人员短缺使维护难度加大，现有系统管理人员由于缺乏系统相关资料和经验，很难独立完成前置和应用系统的服务器的安装与故障恢复工作。
每当遇到这种情况，都是由开发商派技术人员到现场来重新恢复系统，这样会延长系统宕机时间，可能直接影响到银行的生产。
如何在控制整体成本的条件下，对有限的人力资源进行合理调配; 如何能在众多的系统中应付突发的故障，把分散的数据资源合理利用，增加银行服务业务，提高服务质量；如何适应业务发展的趋势使扩展业务系统变得简洁可控，这些问题也都突出地摆在了分行领导的面前。
前置系统整合针对银行省级分行前置系统的现状，该银行确定了基于IBM x440+FAStT700 + VMware进行系统整合的方案，将10至20个原有中小系统整合到单一平台上来。
在服务器平台选型过程中，对于分散和今后仍然不断增加的前置业务，该银行认为，Intel架构的服务器整合从人员培训、管理上都更加容易，性价比也比较高，此外，该银行还认为，目前IBM x440可以承担关键应用的重任。
在单一IA架构硬件平台上通过VMware实现多个系统分区(System Partitioning)，对系统硬件资源进行动态分配，分别运行不同的前置业务；由两台x440 服务器构成在VMware之上的群集系统，实现对每一应用的双机互备，保证当其中一台宕机时所有的业务应用可以持续运行；为了更好地支持群集系统并保证其数据的可扩展性，该系统采用FAStT 700 SAN结构存储服务器，可以通过其存储分区功能来配合主机上的系统分区；同时通过IBM独有的I/O扩展技术对x440的PCI总线系统进行外部扩展，以支持多个系统分区时的I/O 需求。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
前置机系统详细设计方案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 ) 上送的交易。
串口方式如下图所示：接收进程负责从端口读取上送的信息，发送进程将处理结果写到通讯端口，它们与守护进程之间通过消息队列进行数据交换。
网控器可以有多个上行与下行板，为达到并行处理的目的，对应于每个通信端口，各启动一对相互独立的读／写进程对其操作，提高了系统效率。
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 ) 上送的交易。
(A)交易处理流程(1)销售终端 ( POS )经网控器发起请求。
(2) 接口读守护进程通过通信端口从网控器收到请求后,解包后送往交易消息队列。
然后继续新的监听(3) 交易处理守护进程从交易队列中读取交易信息, 调用Fork ( )复制自己，进行处理。
父进程继续新的监听。
(4) 子进程处理后将结果写交易结果消息队列。
(5) 子进程将处理结果写监控消息队列。
(6) 接口写进程从结果消息队列中读取处理的结果，打包并写通信端口。
由网控器将信息返回销售终端。
(B) 销售终端( POS )与接口读/写守护进程之间的交易数据格式遵循 ISO8583 标准。
(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.监控子系统作为一个完整的监控系统，应包括实时交易监控，系统资源和守护进程的监控三大部分，它们是相对独立的。
实时交易监控实时交易监控从监控消息队列中读取信息，经过格式转换后，将其写到实时交易监控窗口上。
通过实时交易监控，可以查看当天的最后一批交易处理的时间及结果，相应的统计信息( 如总笔数，总金额等 )。