综合前置：究竟是综合掉各个前置，还是综合调各个前置 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

渠道：交易发起的操作界面，需要提供柜员号（人员-柜面 或自动-ATM 或虚拟-网银），流水号，交易码，渠道代码
系统：业务处理或加工的IT应用，分账务系统，管理系统，外联系统，有的系统也可以主动发起交易，需要提供柜员号（人员或自动或虚拟），流水号，交易码，系统代码
外联系统：专指行外调用接口
前置：为丰富系统功能而在其外包装的部分，例如提供记录用于查询查复等，前置都是跟随系统，系统可以有前置，也可以没有前置，可以把前置和跟随的系统看成一个完成功能的整体
交易调度系统（综合前置）：接收渠道系统的交易请求，依次调度各个系统完成整个交易过程的系统，因此在这里负责对账最合适
原帖由 pacman2000 于 2011-3-18 14:03 发表

一字之差，两种思路。我比较支持后面的方式。


不知道其它公司是什么理解, 以我们自已实施的案例, 综合前置是以整合所有渠道类业务功能为目标的技术与业务功能一体化的综合性系统.
从技术上看, 它需要完成以下几项任务:
1. 负责实现所有渠道接口的报文接口协议适配, 统一完成与各种客户端系统及第三方系统的数据通讯.
2. 负责完成所有渠道类业务流程的管理和调度, 尤其是跨系统跨企业的业务流程的协同.
3. 负责完成所有渠道类业务(非核心系统业务)的业务处理逻辑处理及相应的业务数据管理.
从应用内容看, 理想的综合前置解决方案应涵盖以下业务内容(非记账部分):
1. 自助服务渠道类业务, 包括ATM/自助终端/网银业务/CC业务/手机银行业务
2. 支付类业务, 包括银联/现代化支付/网银互联/全国商行通兑/农信银/支付宝/各种银银转账业务
3. 各种中间业务(地方特色业务类)，包括TIPS，身份核查，银证转账，水费，电费，电话费，银企直连等等。
4. 其它各种跨系统业务协同接口，比如银联数据贷记卡系统接口， 核心--信贷管理系统T+0接口等。
换句话讲，综合前置承担的是整个渠道业务整合和综合处理的职责，以保证柜员前端系统，网银系统，语音平台，ATMC等渠道系统可以专心于功能展示， 以及使核心系统可以专心于账务核算。
因此，我们理解的综合前置， 是“综合掉各个前置”的意思， 即是把以前独立存在的卡前置，POS前置，中间业务平台，支付前置等系统综合到一起。
而楼主讲的综合调各渠道， 那是好多年前就已出现的数据交换平台或通讯服务平台，应该是还算不上叫综合前置。
现在人银行核心都在像小核心靠拢，只有存，贷，把前置整合在一起，前置系统会越来越大，会不会超过核心了，。。。。
综合调各个前置，我觉得已经不是前置的概念了，应该叫一个分发器，处理各种渠道报文的分发，当然也包括柜面，这样对以后支持集群也大有好处，我也比较赞成第二种
但要把对账放在前置，就会有多种状态处理的问题。首先是前置和各种渠道同步状态，在核心同步状态，这块的处理会比较麻烦，所以设计的时候就要考虑是不是把三个地方的状态都做成一致，这块需要好好考虑。。。
我作为甲方，跟一些公司交流过，有些公司实现的是所谓第一种模式，就跟三楼描述的，把能放的尽量放在一起，除了通讯路由，基本上都把代收代付逻辑整在一起，但象网银、call center很多渠道还是要自己的平台上实现，再通过“综合前置”与核心交互， 综合前置“外面还是挂了不少前置，不可能综合掉所有前置，最多综合掉一部分前置，但把太多的逻辑放在一个系统上，耦合度太高，过于集中，风险很大，不利于安全运行。 也有公司把主要负责通讯调度的平台（大概是第二种“综合调前置”、“渠道整合”平台）和业务逻辑平台分开，结构似乎更清晰一点，公司解释说以前放在一起，现在出于各种考虑把二者分开。我了解的是，以前是把通讯调度和业务逻辑放在一起，新的做法是分开，有点象SOA架构。
   我个人认为，从发展趋势上，SOA是方向，系统之间应该松耦合，ESB是向SOA迁移的基础平台 ，ESB既是一个通讯互联路由的平台，也是各种服务的注册、管理、安全控管平台，各种不同的外围应用，我认为应该分门别类，适度集中，比如支付类的业务放在一个系统上（统一支付平台），不同的系统之间通过ESB连接起来，应用分类集中，既减少前置的数量，也降低过于集中的风险。很多银行都开始建立ESB平台，但困难在于制定企业级的服务规范，通过梳理把存量系统逐步改造为SOA，否则建立ESB最多是使各系统之间的通讯协议和接口数据格式规范一些而已，只有分步进行服务治理才能获得SOA的好处。向SOA迁移似乎是一种方向，但不知道要经历多长时间。以前银行的系统基本上是C/S结构，刚开始用java开发，总担心效率、安全，现在基本上是B/S架构，j2ee应用在银行已很普遍，甚至有些国内公司已开发出java版的核心系统。
[ 本帖最后由 新新马甲 于 2011-3-20 10:41 编辑 ]
窃以为没有统一客户视图支持下的综合签约，单点登录，富集授权和前台设备的统一管理与有效客户识别与分流，就不是什么综合前端，无非是浮云而已
不要过多的纠缠于技术实现模式，首先要考虑业务需求的现实需求和未来趋势，关键还是要解决一个效能和体验的问题
有的时候要想清楚做综合前端的目标是什么，而不是仅仅的一个技术上进步，而依然应该是提高网点效能、提高客户感受、进而增加网点的盈利和销售能力，从这一点上来说，综合前端其实干的绝对不止是前端的事儿，范围要大得多了，还真不是一会儿能说的完的
原帖由 新新马甲 于 2011-3-20 10:23 发表

我作为甲方，跟一些公司交流过，有些公司实现的是所谓第一种模式，就跟三楼描述的，把能放的尽量放在一起，除了通讯路由，基本上都把代收代付逻辑整在一起，但象网银、call center很多渠道还是要自己的平台上实现，再通过“综合前置”与核心交互， 综合前置“外面还是挂了不少前置，不可能综合掉所有前置，最多综合掉一部分前置，但把太多的逻辑放在一个系统上，耦合度太高，过于集中，风险很大，不利于安全运行。 也有公司把主要负责通讯调度的平台（大概是第二种“综合调前置”、“渠道整合”平台）和业务逻辑平台分开，结构似乎更清晰一点，公司解释说以前放在一起，现在出于各种考虑把二者分开。我了解的是，以前是把通讯调度和业务逻辑放在一起，新的做法是分开，有点象SOA架构。
   我个人认为，从发展趋势上，SOA是方向，系统之间应该松耦合，ESB是向SOA迁移的基础平台 ，ESB既是一个通讯互联路由的平台，也是各种服务的注册、管理、安全控管平台，各种不同的外围应用，我认为应该分门别类，适度集中，比如支付类的业务放在一个系统上（统一支付平台），不同的系统之间通过ESB连接起来，应用分类集中，既减少前置的数量，也降低过于集中的风险。很多银行都开始建立ESB平台，但困难在于制定企业级的服务规范，通过梳理把存量系统逐步改造为SOA，否则建立ESB最多是使各系统之间的通讯协议和接口数据格式规范一些而已，只有分步进行服务治理才能获得SOA的好处。向SOA迁移似乎是一种方向，但不知道要经历多长时间。以前银行的系统基本上是C/S结构，刚开始用java开发，总担心效率、安全，现在基本上是B/S架构，j2ee应用在银行已很普遍，甚至有些国内公司已开发出java版的核心系统。
我始终认为， ESB是个技术概念， 综合前置是个应用的概念， 两者无法混为一谈。 好的综合前置， 应该是以SOA为技术体系架构， ESB则是实现这种架构的技术基础设施平台。 在ESB之上， 开发和部署各种专业化的应用组件或服务模块， 就形成了综合前置。由于在ESB上可以集群式部署各种各样的业务服务功能， 因此其业务部署可以分布式部署的， 不存在“耦合度太高，过于集中，风险很大”的问题。综合前置其所谓综合， 其实是其技术基础设施及技术体系， 而其功能模块却是可以无限扩展的。
至于B/S架构完成的, 仍然是属于表现层的工作, 比如网银, 在 前-中-后 的三层技术体系中, 完成的是前端层的工作, 与综合前置没有关系. 综合前置是不管B/S界面,C/S界面,甚至纯报文接口,都必须要提供支持的.
至于说j2ee在银行应用很普遍的说法,目前也只适用于管理系统或者前端界面层, 前置层和核心服务层目前仍然是无法适用的. 去年初交通银行的JAVA前端界面平台, 就是因为压力大而导致GC无法及时回收内存, 停业接近四个小时而被银监通报的.
原帖由 家住海淀 于 2011-3-20 10:48 发表

有的时候要想清楚做综合前端的目标是什么，而不是仅仅的一个技术上进步，而依然应该是提高网点效能、提高客户感受、进而增加网点的盈利和销售能力，从这一点上来说，综合前端其实干的绝对不止是前端的事儿，范围要大得多了，还真不是一会儿能说的完的
楼主讨论的是前置系统, 不是前端系统的概念. 前置系统是属于EAI/ESB的技术体系, 前端系统是属于portal的技术体系, 两者没有什么关系.