如果大家关注SOA的事务一致性的处理，那么不妨看看我们是怎么解决的
本文原文链接： http://www.itpub.net/forum.php?mod=viewthread&action=printable&tid=1570361
作者: efscao 时间: 2012-2-5 17:58 标题: 如果大家关注SOA的事务一致性的处理，那么不妨看看我们是怎么解决的
SOA的理念日渐深入人心，银行业务系统也必将转向SOA，这意味着今后绝大多数应用都要成为服务的集成者——这就带来一个非常关键的问题：如何解决集成服务应用普遍存在的一致性问题？当前金融行业正在运用的集成服务应用平台和框架都只能通过一种自动撤消机制（即所谓冲正，效果类似数据库的回滚）来解决这个问题，但在许多业务场景中，自动撤消机制并不适用。
完善的服务层应用平台应该不 仅仅提供“自动撤消处理”机制，还提供“手动继续尝试处理或撤消处理”机制来解决这个问题。后者和下载文件时我们常用的“断点续传”的效果非常相似，能够 帮助业务人员在第一时间内用极为简单的操作修正一致性问题，同时，由于是在业务人员的监控下采取修正动作，马上可以看到修正结果，因此，不会有“自动撤消 处理”可能产生的资金风险，能够有效地提升业务办理效率和服务质量，并降低操作风险和系统的数据差错率。需要特别指出的是，这并不需要开发人员做出特别 的、额外的设计。
没看明白，是说将当前的撤销和冲正 和在一起吗？ 作者: efscao 时间: 2012-2-5 20:01
意思是：所有的服务接口，不但应该提供一个统一的冲正接口（当然，这个冲正也可以在服务系统内部触发，而不是依靠调用这个接口），还应该提供继续尝试处理 和撤销处理接口，前者可以完成先前没有完成的工作，后者可以抹除先前已经部分完成的工作。当然，服务接口的应答中还应该包含一个参数，表明当前这次服务调 用是否出了一致性问题，如果出了一致性问题，服务的消费者（例如，前台系统）就可以调用继续尝试处理和撤销处理接口来解决问题 作者: efscao 时间: 2012-2-5 20:05
完善的服务系统，除了提供一般的服务接口，还要提供一些一致性处理接口，这些处理接口仅包括一个统一的冲正接口是不够的，还应该包括统一的继续尝试处理接口和（部分）撤销处理接口 作者: pacman2000 时间: 2012-2-5 22:15
还是要人工处理，并没有从根本上消除不一致的问题啊。而且，即使有人工处理，每日的对账还是必不可少的。因为人工也可能有疏漏。 作者: efscao 时间: 2012-2-5 22:37
错了，这个人工处理是不同于现在的人工处理的，它是"傻瓜"式的，只需点击“继续尝试处理”或者“撤销”这两个按钮之一，直到全部成功或全部撤销 作者: efscao 时间: 2012-2-5 22:41
当然，有了这些接口不等于对账就不要做了。但要知道，有了这些接口，不上的帐将大大减少，并且这些错账的处理也可以用这些接口支持，从而大大减少错账处理的人工工作量 作者: kinghq 时间: 2012-2-6 08:26
你这不是要烦死用户么？现由数据库来保证的话，不会烦用户，最不济，用户还有撒气的地。 作者: efscao 时间: 2012-2-6 09:08
当你在一个SOA架构中，要集成多个WebService时，你怎么能够奢望数据都在一个数据库中？不在一个数据库中，你就不能依赖数据库事务机制来保证 一致性。并且，实际运行起来需要用户用这种“傻瓜”方式处理一致性问题的相对来说，比例还是很少的，通常不到1%，谈不上“烦死”。相反，现在的许多系 统，如果对账后错账较多，处理错账的人经常“烦死” 作者: taelons 时间: 2012-2-6 09:38
听起来象分布式事务处理的机制，我想到的是spring+atomikos 作者: nannan5000 时间: 2012-2-6 09:39
没看懂lz 想要实现什么 作者: 家住海淀 时间: 2012-2-6 09:41
手动继续尝试处理或撤消处理
还是需要手工核查？这个工作量吃得消吗？纵然分类，是不是没有问题的也得看一遍？
如果规则清晰，自动化并非不可能 作者: efscao 时间: 2012-2-6 10:13
我们的模型和事务模型还是有较大不同的。事务模型的目标是确保当某个步骤失败时，所有变动恢复原样。我们的模型有一半类似这个机制，但另一半则相反，尽管 某个时刻某个步骤没有成功，但我们还是试图让业务最终能够做成功，这是事务模型办不到的。实际业务环境中，后者可能更有效，你想，一个操作员费了很大劲， 输入了很多数据，然后点了确定按钮，但你的程序处理过程中某一步有问题过不去，你就因此全部回滚，并告诉操作员交易失败，操作员一定很不爽。前台应用做的 不好话，操作员还得再输一遍数据，那他恐怕就会有点烦了。 作者: 家住海淀 时间: 2012-2-6 10:26
efscao 发表于 2012-2-6 10:13
我们的模型和事务模型还是有较大不同的。事务模型的目标是确保当某个步骤失败时，所有变动恢复原样。我们的 ...
我只关心最终需要手工处理的交易量在全部交易量中的比例是多少？
作者: efscao 时间: 2012-2-6 10:34
家住海淀 发表于 2012-2-6 09:41
手动继续尝试处理或撤消处理
还是需要手工核查？这个工作量吃得消吗？纵然分类，是不是没有问题的也得看 ...
呵呵，是我没讲清楚，但这毕竟是一个大家以前从未设想过的新模型，解释和理解都要费点劲
再抄点东西给大家分享一下，欢迎拍砖啊
Service Center的一致性保障机制
Service Center为集成型服务应用提供了完备的一致性保障机制，这一重要特征使其非常适合被用作新产品服务和大前置等集成服务类应用系统的应用平台。 Service Center的一致性保障机制分为“自动撤消处理”和“手动继续尝试处理或撤消处理”两种模式（简称自动处理模式和手动处理模式）。所谓自动处理模式—— 也是当前金融行业已经运用的一些集成服务应用平台和框架所普遍采用的模式——就是在集成型服务应用的处理过程中，如果有一个步骤没有成功，则向访问者返回 失败，并由应用框架自动发起先前已经被该应用成功调用的服务的撤消处理。
需要注意的是，自动处理模式难以应对某些一致性问题。设想这样一个场景：客户带着现金来银行购买基金，柜台系统访问的代销基金集成服务应用一般要先调用本 行帐务系统的服务以登记现金的收取，成功后调用基金公司的购买基金服务，再成功后向柜台系统返回“交易成功”，由柜员收讫现金。如果规定时间内没有收到基 金公司应答（一个结果不确定的步骤），我们能够使用自动处理模式解决问题么？如果我们把这种未收到应答的情形当作失败步骤并启动自动撤消处理，结果很可能 就是客户既买到了基金，同时柜员又告知客户交易失败，向客户退还了现金！当然，有些银行采取这样的做法：即便未收到基金公司的应答，也当做成功步骤继续处 理。这就可能造成基金没有买到而客户现金却被收取，客户必然要投诉，而问题解决起来可能相当繁琐（在试图解决问题的时候基金价格很可能已经发生变动，或者 已经销售完）。
有些开发人员发现了这种问题，他们一般采用以下两种方式来处理：
1、 分解处理方式。在上述情形发生时，向柜台系统返回“没有收到基金公司应答”，根据操作说明，柜员需要立即查询基金公司的处理结果，如果成功，则收讫现金， 如果不成功，则进行一致性处理——撤消本行帐务系统的现金收取登记，或者单独调用基金公司的购买基金服务。
2、 整体处理方式。在上述情形发生时，向柜台系统返回“没有收到基金公司应答，请选择继续尝试处理或撤消处理”，柜员在终端上只能选择“继续”或“撤销”。一 旦选定，柜台系统会调用一个专门处理这种情形的一致性处理服务。如果柜员选择了继续尝试处理，该服务会先查询基金公司的处理结果，成功则返回“交易成 功”，柜员收讫现金，失败则返回“交易失败”，并启动自动撤消处理以撤消本行帐务系统的现金收取登记，柜员退还现金；如果柜员选择了撤消处理，该服务会先 查询基金公司的处理结果，成功则先调用基金公司的撤消购买基金服务，然后再调用本行帐务系统的撤消现金收取登记服务，最后返回“交易已经撤消”，柜员退还 现金。
（抱歉，不知道怎么发图）
图2.1 用整体处理方式处理一致性问题的服务应用
显然，从业务角度看整体处理方式要优于分解处理方式——对于柜员而言，操作压力大大降低，不容易出错；对于银行而言，不需要向柜员开放“撤消本行帐务系统的现金收取登记”和“单独调用基金公司的购买基金服务”等功能，更好地控制了操作风险。
但是整体处理方式需要开发人员针对具体应用进行极其细致而繁琐的一致性处理设计（图2.1仍然有许多情况没有考虑到），稍有不慎，则会导致难以想象的后果，因此，目前金融行业采用整体处理方式来应对这种情形的应用比例还相当低。
所谓手动处理模式，就是由Service Center的服务应用框架代替应用，提供统一的一致性处理服务，用一种标准化的、逻辑极其严密的整体处理方式来解决所有自动处理模式无法处理的一致性问题，从而大大降低开发人员的负担。
作者: 家住海淀 时间: 2012-2-6 10:50
一致性问题只是一个数据完整性问题
还要关注的就是对海量并发处理的响应 作者: efscao 时间: 2012-2-6 10:53
家住海淀 发表于 2012-2-6 10:50
一致性问题只是一个数据完整性问题
还要关注的就是对海量并发处理的响应
非常正确！
我再抄一些东西大家分享：
Service Center的服务重入机制
由于经常需要访问远程服务系统（尤其是合作企业的服务系统），许多集成型服务应用完成整个处理过程往往需要较长时间。如果处理线程/进程以堵塞方式——每 发出一个服务请求后线程/进程就处于堵塞状态，直到收到服务应答才继续执行下一个指令——执行集成服务处理流程的话，将会导致大量服务系统资源（内存和处 理线程/进程）的浪费，造成堵塞，数据差错急剧增多，甚至宕机。
以前面提到的代销基金为例。市场好的时候，基金销售量会直线上升，基金公司的服务系统可能由于压力增大而反应缓慢，很快就会导致银行端代销基金集成服务处 理线程/进程大量堵塞。通常，服务系统常备的处理线程/进程总数都在20到50之间（过多则操作系统调度效率会大大下降），在所有处理线程/进程都处于堵 塞状态时，就会产生大量排队等候处理的服务请求，服务系统响应能力和可靠性迅速下降，直至宕机。当然，有些服务系统在紧急时刻会创建更多的线程/进程，但 与大量排队等候处理的服务请求比较起来，仍然是杯水车薪。
有些银行采用部署更多的服务系统节点的方法来应对，这不但要大大增加部署成本，而且还不能根本地解决堵塞问题，只不过是延缓了宕机时刻的到来。
还有一些银行采用流量控制的方法来应对，即在调用处理时间可能较长的服务前，检查该服务当前的调用流量，超过一定的阈值则放弃调用，作为“调用流量已满， 暂停该类服务”错误来处理。这种方案一定程度上能够保证服务系统不至于宕机，但显然会招致柜员和客户的不满——为什么系统总是暂停服务？
目前，最根本的解决方法就是彻底改变这类服务应用的编程模型，把一个服务处理过程拆解为多个，无论是为客户端系统提供服务，还是调用其它服务系统提供的处理时间可能较长的服务，都采用异步工作模式——即服务应用的异步编程模型。
仍以代销基金为例。在柜员收取客户现金并通过柜台系统发出代销基金服务请求后，服务应用先调用本行帐务系统的服务以登记现金的收取，成功后向基金公司发出 购买基金服务请求，请求发出后服务应用休眠——保存当时的重要状态，释放处理线程/进程。在稍后一个时刻，银行收到了基金公司的应答，再唤醒该服务应用 ——分配处理线程，获取休眠时的状态。如果购买基金交易失败，则启动自动撤销处理，生成“交易失败”服务应答，结束服务处理过程，柜台系统受到服务应答 后，在终端上显式“交易失败”，柜员退还现金；如果购买基金交易成功，则生成“交易成功”服务应答，结束服务处理过程，柜台系统受到应答后，在终端上显示 “交易成功”，柜员收讫现金。
图2.2按异步编程模型重构的服务应用
服务应用的异步编程模型对开发人员的要求极高。开发人员必须极为小心慎重地针对具体应用制订相应的服务处理过程分拆方案，分拆后如何保障集成服务的一致性 则更是一些令人头痛的问题，因此，目前金融行业采用异步编程模型来开发的服务应用极为稀少，在国内，基本上仅限于银联和各大银行的交换系统。
Service Center提供了一种被称为服务重入的机制来解决堵塞问题。这种机制不要求开发人员改变他们习惯的编程模型，仍然只需要用一个流程来描述集成服务的完整 处理过程。运行时刻，这个流程在执行到某些耗时较长的处理步骤时，在处理步骤启动后可以执行Service Center的服务应用框架提供的“休眠”方法，由服务应用框架完成应用休眠工作。在这些处理步骤完成时可以执行服务应用框架提供的“唤醒”方法，由服务 应用框架唤醒应用，并让它从刚才调用“休眠”方法的语句处继续向下执行，直到完成整个流程。
服务重入机制使得基于Service Center构建的产品服务具有极高的吞吐能力，能够应对过去难以承受的突发的业务高峰，而这一切的获得并不需要开发人员做出许多改变和适应。 作者: 南东北西 时间: 2012-2-6 11:25
efscao 发表于 2012-2-6 10:53
非常正确！
我再抄一些东西大家分享：
归根结底还是分布式事务处理。
只不过是将分布式事务处理应用到金融业中。
个人的判断：
1. 如果是实时交易，要保证多系统间的事务处理，而不是传统的冲正方式，效果未必优于后者。
主要是保证事务处理会影响程序效率，而后者简单明了，当然冲正给柜员带来了麻烦，但系统做得好的话，柜员完全可以不必重新输入数据。
有可能某些特殊业务，实现多系统间的事务处理有必要性和优越性。
2. 如果是批处理，通常是自动化的。
实现多系统间的事务处理当然是必要的。
作者: 南东北西 时间: 2012-2-6 11:26
efscao 发表于 2012-2-6 10:53
非常正确！
我再抄一些东西大家分享：
归根结底还是分布式事务处理。
只不过是将分布式事务处理应用到金融业中。
个人的判断：
1. 如果是实时交易，要保证多系统间的事务处理，而不是传统的冲正方式，效果未必优于后者。
主要是保证事务处理会影响程序效率，而后者简单明了，当然冲正给柜员带来了麻烦，但系统做得好的话，柜员完全可以不必重新输入数据。
有可能某些特殊业务，实现多系统间的事务处理有必要性和优越性。
2. 如果是批处理，通常是自动化的。
实现多系统间的事务处理当然是必要的。
作者: taelons 时间: 2012-2-6 11:27
姑且不论这个代销基金的例子并不合适（代销基金根本不是LZ所说的流程）。
LZ所说的就是分布式事务处理的机制，分布式事务处理并不是“不成功则全部失败”，完全可以实现挂起、回退或继续 作者: 家住海淀 时间: 2012-2-6 11:30
taelons 发表于 2012-2-6 11:27
姑且不论这个代销基金的例子并不合适（代销基金根本不是LZ所说的流程）。
LZ所说的就是分布式事务处理的机 ...
全部的撤销和回退是一种相对理想的情况
对于部分成功和部分失败的情况，整个响应时间就有问题了，可能已经超过了超时处理的设定阈值 作者: efscao 时间: 2012-2-6 11:43
taelons 发表于 2012-2-6 11:27
姑且不论这个代销基金的例子并不合适（代销基金根本不是LZ所说的流程）。
LZ所说的就是分布式事务处理的机 ...
1、真没想到分布式事务处理机制还有这么强大的特性，是我孤陋寡闻了？假如在集成服务的处理过程中，你调用的一个WebService修改了一个文件中的数据，而后其他地方发生了问题，那么你认为分布式事务处理机制也能很好地对付这个问题么？
2、说到代销基金的处理流程，我只能说01年我在X行带领的项目组做代销基金时就是这样的流程，09年我做整个行的架构梳理和管控时，项目组提交上来的设 计文档也是这样的流程，X行的代销基金业务量在行业内不是第1也是第2.你也许可以说我以偏概全，但不能武断地说“根本不是我所说的流程” 作者: efscao 时间: 2012-2-6 11:55
南东北西 发表于 2012-2-6 11:25
归根结底还是分布式事务处理。
只不过是将分布式事务处理应用到金融业中。
一个需要在出现一致性问题之后再调用一个一致性处理接口的模型，难道还是（分布式）事务模型？ 作者: efscao 时间: 2012-2-6 11:59
如果你调用了合作伙伴的WebService，你能把他们家的数据库也纳入你的分布式事务机制中么？ 作者: 南东北西 时间: 2012-2-6 12:44
efscao 发表于 2012-2-6 11:59
如果你调用了合作伙伴的WebService，你能把他们家的数据库也纳入你的分布式事务机制中么？
虽然不同，核心还是分布式事务处理的理念，只是具体应用的适应性实现罢了。 作者: taelons 时间: 2012-2-6 12:55
efscao 发表于 2012-2-6 11:43
1、真没想到分布式事务处理机制还有这么强大的特性，是我孤陋寡闻了？假如在集成服务的处理过程中，你调用 ...
１、建议LZ了解一下分布式事务处理的概念，还有jta、jdo、atomikos、spring之类的规范和开源，商业的更不用说了
２、第一次听说银行代销基金还要调用基金公司的服务并等待应答。基金交易并不是适时的，成功不成功，晚上统一对账就知道了 作者: efscao 时间: 2012-2-6 13:07
taelons 发表于 2012-2-6 12:55
１、建议LZ了解一下分布式事务处理的概念，还有jta、jdo、atomikos、spring之类的规范和开源，商业的更不 ...
1、呵呵，我倒是认为分布式事务处理本身和SOA理念就是违背的。未来你访问你的合作伙伴时，你唯一的手段就是调用它的WebService ，而不是直接操作它的数据库（现在也不可能），把它家的数据库纳入你的分布式事务处理产品（不管用的是开源的，还是商业的）管控下
2、买基金的应用，你可以做成不实时的，但一些价格实时浮动的投资产品，你还能这么做么？ 作者: efscao 时间: 2012-2-6 13:33
如果多家银行都代销一家基金，你不调用一下基金公司的接口，怎么知道基金有没有卖完啊？先查询一下？不担心查询完后余量又变了？你不担心收了客户的钱，第2天又告诉他没买到，客户有意见？当然了，我们现在很多银行都是这么对待客户的，他们不怕客户有意见 作者: pacman2000 时间: 2012-2-6 13:42
efscao 发表于 2012-2-6 09:08
当你在一个SOA架构中，要集成多个WebService时，你怎么能够奢望数据都在一个数据库中？不在一个数据库中，你 ...
这是问题的所在，对于银行这种一致性要求非常高的应用状况，过多得拆分零碎的小系统，真的适合吗？如果能把联机事务处理涉及的数据库设成同一个，不是更好？ 作者: pacman2000 时间: 2012-2-6 13:45
efscao 发表于 2012-2-6 10:13
我们的模型和事务模型还是有较大不同的。事务模型的目标是确保当某个步骤失败时，所有变动恢复原样。我们的 ...
异步的情景，比如集中处理中心，现在已经用工作流的方式弄了。同步的情况，前台都有超时设置，这时候人工干预，对超时控制影响很大啊。 作者: efscao 时间: 2012-2-6 13:49
pacman2000 发表于 2012-2-6 13:42
这是问题的所在，对于银行这种一致性要求非常高的应用状况，过多得拆分零碎的小系统，真的适合吗？如果能 ...
如果是工农中建交，这么做是最好的，但是不是所有银行都能像这几家银行依靠自己的开发力量搞定所有应用的，所以... 作者: efscao 时间: 2012-2-6 13:51
再者，即便你能搞定自己的全部应用，你还得和其他企业合作，对接，这类应用数量会越来越多。仍然不可避免的要面对一致性问题 作者: efscao 时间: 2012-2-6 13:54
pacman2000 发表于 2012-2-6 13:45
异步的情景，比如集中处理中心，现在已经用工作流的方式弄了。同步的情况，前台都有超时设置，这时候人工 ...
我想，现在还没有哪家银行的银联卡前置系统（要访问人行交换系统）是用工作流做的吧 作者: efscao 时间: 2012-2-6 14:04
efscao 发表于 2012-2-6 13:54
我想，现在还没有哪家银行的银联卡前置系统（要访问人行交换系统）是用工作流做的吧
对于集中处理中心这种后台的、根本不需要讲究操作体验的地方，我觉得连工作流都不需要。只需业务员采集、整理信息，系统批量处理即可 作者: efscao 时间: 2012-2-6 14:05
pacman2000 发表于 2012-2-6 13:45
异步的情景，比如集中处理中心，现在已经用工作流的方式弄了。同步的情况，前台都有超时设置，这时候人工 ...
对于集中处理中心这种后台的、根本不需要讲究操作体验的地方，我觉得连工作流都不需要。只需业务员采集、整理信息，系统批量处理即可 作者: pacman2000 时间: 2012-2-6 14:08
efscao 发表于 2012-2-6 13:54
我想，现在还没有哪家银行的银联卡前置系统（要访问人行交换系统）是用工作流做的吧
银联接口的访问是同步的，也就是一个交易提交以后，要等待返回的。所以你看ATM上都有超时时间显示的啊。
这时候有人工处理参与，也不知道到底ATM界面超时了没有，很可能把事情搞得更复杂了。 作者: pacman2000 时间: 2012-2-6 14:10
efscao 发表于 2012-2-6 13:51
再者，即便你能搞定自己的全部应用，你还得和其他企业合作，对接，这类应用数量会越来越多。仍然不可避免的 ...
是的，对外接口毫无疑问必然是有一致性问题。这时候就要依据资金安全原则理清交易步骤，以及靠事后对账来处理差错。所以行内系统能简单点就简单点吧。 作者: taelons 时间: 2012-2-6 14:16
１、你对分布式事务的理解仍局限于数据库事务的范畴。在商业的RAD6能很容易的实现WebServices事务
２、不是“可以”，而是“必须”
作者: efscao 时间: 2012-2-6 14:18
pacman2000 发表于 2012-2-6 14:08
银联接口的访问是同步的，也就是一个交易提交以后，要等待返回的。所以你看ATM上都有超时时间显示的啊。
...
1、银联给大家的接口并非同步的，前置给ATM的接口才是同步的
2、各家银行目前的前置都是同步实现的，所以如果我们观察前置的进程，会发现总是有很多处于等候状况，如果这些前置是基于CICS等中间件开发的话，那么 我们就要担心应用服务器资源消耗的问题的，我们不得不加上流量限制，驳回很多终端的请求，所以，我们经常会看到系统忙、暂停服务，而异步模型可以让你不设 流量限制
3、异步模型和我们先前说的一致性处理是两回事，不要纠缠在一起，当然，如果没有很好的平台帮你应对，你可能真的就不得不把这些问题纠缠在一起考虑了
4、前端超时自有前端超时的一套处理机制，（一般是查询先前未知的处理结果，但像ATM这样的自助终端则基本上用冲正应对），和我们先前所提到的模型最好也不要纠缠在一起 作者: pacman2000 时间: 2012-2-6 14:25
efscao 发表于 2012-2-6 14:18
1、银联给大家的接口并非同步的，前置给ATM的接口才是同步的
2、各家银行目前的前置都是同步实现的，所以 ...
这样吧，就拿这个ATM跨行取款交易的例子，来看看你的模型是如何处理的？ 作者: efscao 时间: 2012-2-6 14:28
pacman2000 发表于 2012-2-6 14:10
是的，对外接口毫无疑问必然是有一致性问题。这时候就要依据资金安全原则理清交易步骤，以及靠事后对账来 ...
行内系统能简单就简单，这个说法完全同意，但很多银行不得不外购应用系统，还真简单不起来 作者: efscao 时间: 2012-2-6 14:36
taelons 发表于 2012-2-6 14:16
１、你对分布式事务的理解仍局限于数据库事务的范畴。在商业的RAD6能很容易的实现WebServices事务
２、不是 ...
1、如果你一定认为基于两阶段提交的（分布式）事务模型确实能普遍应对各种一致性问题，我也没什么可说的，不过到目前为止，银行系统似乎还没有一个运用两 阶段提交机制的，我记得2000年我们对几个商业软件做过两阶段提交机制的测试，并最终放弃。希望你能多创造一些案例，供我们大家参考
2、如果多家银行都代销一家基金，你不调用一下基金公司的接口，怎么知道基金有没有卖完？先查询一下？不担心查询完后余量又变了？你不担心收了客户的钱， 第2天又告诉他没买到，客户有意见？当然了，我们现在很多银行都是这么对待客户的，他们不怕客户有意见——这是我对买基金应用中“必须”不调用基金公司接 口的回答 作者: efscao 时间: 2012-2-6 14:46
pacman2000 发表于 2012-2-6 14:25
这样吧，就拿这个ATM跨行取款交易的例子，来看看你的模型是如何处理的？
这就是一个简单的、典型的异步模式的服务应用：
ATM发出取现请求后，服务应用判断出为他行卡，则向银联发出取现报文，发出后服务应用休眠——保存当时的重要状态，释放处理线程/进程。在稍后一个时 刻，银行收到了银联的应答，再唤醒该服务应用——分配处理线程，获取休眠时的状态。如果银联的应答是失败，则生成“交易失败”服务应答给ATM；如果银联 的应答是成功，则调用主机账务系统取现交易，成功后生成“交易成功”服务应答给ATM。
当然，向银联发出取现报文的同时会安装一个计时器，一旦超过时间，就自动唤醒该服务应用，此时，服务应用将认为银联应答不明确，并因此生成“交易失败”服务应答给ATM，同时启动自动冲正机制，防止一致性问题。
关键不在于写这样的异步服务，而是要提供一个平台，允许大家用同步模型来编写出可以按异步模式工作的服务应用
作者: taelons 时间: 2012-2-6 14:52
１、那为什么放弃呢？为什么一定要webservices？LZ在回避自己的理解错误
２、我做基金这行这么多年，第一次听说这种基金 作者: efscao 时间: 2012-2-6 14:58
taelons 发表于 2012-2-6 14:52
１、那为什么放弃呢？为什么一定要webservices？LZ在回避自己的理解错误
２、我做基金这行这么多年，第一次 ...
呵呵，也许基金这个名字改成其他投资产品比较合适 作者: efscao 时间: 2012-2-6 14:59
taelons 发表于 2012-2-6 14:52
１、那为什么放弃呢？为什么一定要webservices？LZ在回避自己的理解错误
２、我做基金这行这么多年，第一次 ...
为什么一定要webservices？呵呵，这个也要回答么？ 作者: efscao 时间: 2012-2-6 15:09
efscao 发表于 2012-2-6 14:58
呵呵，也许基金这个名字改成其他投资产品比较合适
刚核实了一下，用基金做例子确实不对啊，向taelons致歉。
记忆有误，应改成价格实时浮动的投资产品 作者: pacman2000 时间: 2012-2-6 16:01
efscao 发表于 2012-2-6 14:59
为什么一定要webservices？呵呵，这个也要回答么？
银行的OLTP本来就不是web，没必要什么都扯上webservice。而且SOA的S也只是service，可没说是webservice哦。 作者: efscao 时间: 2012-2-6 16:18
pacman2000 发表于 2012-2-6 16:01
银行的OLTP本来就不是web，没必要什么都扯上webservice。而且SOA的S也只是service，可没说是webservice哦 ...
这个基本同意。我们的OLTP不一定都非得搞成WebService不可，但我们集成其他应用，以及其他合作伙伴的功能，今后大都会采用 webService标准。退后一步，哪怕他们不是提供WebService，至少有一点是肯定的，他们会提供某种形式的service供我们集成，而不 是让我们直接访问他们的数据库。这就必然带来一致性问题。实际上，我们的模型是针对各种服务集成时出现的一致性问题，而不仅仅是webservice 作者: pacman2000 时间: 2012-2-6 17:06
本帖最后由 pacman2000 于 2012-2-6 17:11 编辑
efscao 发表于 2012-2-6 14:46
这就是一个简单的、典型的异步模式的服务应用：
ATM发出取现请求后，服务应用判断出为他行卡，则向银联发 ...
嗯？这里没看到你说的异常人工处理啊。
同步方式调用异步访问，这个在现有的综合前置，ESB等等系统里也有类似实现的。而且对于解决一致性问题来说，这个不是重点，异常处理才是重点。
比如说，银联提交成功以后，提交核心交易失败了。这时候的处理过程怎么样呢？假如冲正也失败了又怎么处理？ 作者: efscao 时间: 2012-2-6 17:24
pacman2000 发表于 2012-2-6 17:06
嗯？这里没看到你说的异常人工处理啊。
同步方式调用异步访问，这个在现有的综合前置，ESB等等系统里也 ...
？我记得我们谈到ATM是因为我们在讨论异步模型用在哪里（集中处理中心->银联前置->ATM前置），而不是一致性处理模型用在哪里。
要讨论一致性处理模型，还是看这个案例（taelons说的对，原先用基金不合适，我改成价格实时浮动的投资产品了）：
Service Center的一致性保障机制
Service Center为集成型服务应用提供了完备的一致性保障机制，这一重要特征使其非常适合被用作新产品服务和大前置等集成服务类应用系统的应用平台。 Service Center的一致性保障机制分为“自动撤消处理”和“手动继续尝试处理或撤消处理”两种模式（简称自动处理模式和手动处理模式）。所谓自动处理模式—— 也是当前金融行业已经运用的一些集成服务应用平台和框架所普遍采用的模式——就是在集成型服务应用的处理过程中，如果有一个步骤没有成功，则向访问者返回 失败，并由应用框架自动发起先前已经被该应用成功调用的服务的撤消处理。
需要注意的是，自动处理模式难以应对某些一致性问题。设想这样一个场景：客户带着现金来银行购买某种投资产品，柜台系统访问的代销投资产品集成服务应用一 般要先调用本行帐务系统的服务以登记现金的收取，成功后调用发行投资产品的公司的购买产品服务，再成功后向柜台系统返回“交易成功”，由柜员收讫现金。如 果规定时间内没有收到公司的应答（一个结果不确定的步骤），我们能够使用自动处理模式解决问题么？如果我们把这种未收到应答的情形当作失败步骤并启动自动 撤消处理，结果很可能就是客户既买到了产品，同时柜员又告知客户交易失败，向客户退还了现金！当然，有些银行采取这样的做法：即便未收到公司的应答，也当 做成功步骤继续处理。这就可能造成产品没有买到而客户现金却被收取，客户必然要投诉，而问题解决起来可能相当繁琐（在试图解决问题的时候产品价格很可能已 经发生变动，或者已经销售完）。
有些开发人员发现了这种问题，他们一般采用以下两种方式来处理：
1、 分解处理方式。在上述情形发生时，向柜台系统返回“没有收到...应答”，根据操作说明，柜员需要立即查询公司的处理结果，如果成功，则收讫现金，如果不成功，则进行一致性处理——撤消本行帐务系统的现金收取登记，或者单独调用公司的购买产品服务。
2、 整体处理方式。在上述情形发生时，向柜台系统返回“没有收到...公司应答，请选择继续尝试处理或撤消处理”，柜员在终端上只能选择“继续”或“撤销”。 一旦选定，柜台系统会调用一个专门处理这种情形的一致性处理服务。如果柜员选择了继续尝试处理，该服务会先查询公司的处理结果，成功则返回“交易成功”， 柜员收讫现金，失败则返回“交易失败”，并启动自动撤消处理以撤消本行帐务系统的现金收取登记，柜员退还现金；如果柜员选择了撤消处理，该服务会先查询公 司的处理结果，成功则先调用公司的撤消购买产品服务，然后再调用本行帐务系统的撤消现金收取登记服务，最后返回“交易已经撤消”，柜员退还现金。
图2.1 用整体处理方式处理一致性问题的服务应用
显然，从业务角度看整体处理方式要优于分解处理方式——对于柜员而言，操作压力大大降低，不容易出错；对于银行而言，不需要向柜员开放“撤消本行帐务系统的现金收取登记”和“单独调用公司的购买产品服务”等功能，更好地控制了操作风险。
但是整体处理方式需要开发人员针对具体应用进行极其细致而繁琐的一致性处理设计（图2.1仍然有许多情况没有考虑到），稍有不慎，则会导致难以想象的后果，因此，目前金融行业采用整体处理方式来应对这种情形的应用比例还相当低。
所谓手动处理模式，就是由Service Center的服务应用框架代替应用，提供统一的一致性处理服务，用一种标准化的、逻辑极其严密的整体处理方式来解决所有自动处理模式无法处理的一致性问题，从而大大降低开发人员的负担。
作者: efscao 时间: 2012-2-6 17:38
在ATM、自助终端等自助设备上通常不会应用这个手动处理一致性问题的模型，因为不存在运作这种模型的必需条件：业务人员。所以，我们通常也不会在这些终端上看到类似的代销投资产品的服务 作者: efscao 时间: 2012-2-6 17:43
说到银联卡，其实在柜台上办理的他行卡存款到是和我列举的代销投资产品非常相似，可以应用这个手动处理一致性的模型 作者: efscao 时间: 2012-2-6 17:57
现在柜面上的他行卡取款则通常都和ATM调用的他行卡取款是一个接口，自然一致性处理机制也一样，采用的自动撤销（即冲正）机制，但也可以改成手动的一致 性处理机制——如果特别强调客户的感受的话，不过这样自然业务操作员的体验要稍差一点，这就看业务设计部门是怎么权衡的了。以银联卡这么简单的业务而言， 似乎倒也没有改的必要。但如果柜员帮助企业用户做多个账户间的转账操作，而这些账户可能包含外行的，那么，应用这个手动的一致性处理机制可能就是必要的了 作者: jenifer23710092 时间: 2012-2-24 19:41
efscao 发表于 2012-2-6 17:24
？我记得我们谈到ATM是因为我们在讨论异步模型用在哪里（集中处理中心->银联前置->ATM前置），而不是一致 ...
是否可以采用消息处理机制？某只交易并行调用若干服务，每个服务都会根据一定的规范返回消息，若该交易，允许不是所有服务都成功，才成功，那么可以根据最后每支服务返回的消息结果，决定全部撤销还是部分撤销。
这些不同服务返回的消息通过MQ存储。 作者: efsca 时间: 2012-2-24 20:50
通常不会有并行调用的，一般集成服务时都是串行地调用后面的服务
你提到的处理模式其实就是现在许多前置和中间业务平台广泛采用的自动撤销处理模式 作者: CountOnMyself 时间: 2012-2-25 14:27
efscao 发表于 2012-2-6 17:24
？我记得我们谈到ATM是因为我们在讨论异步模型用在哪里（集中处理中心->银联前置->ATM前置），而不是一致 ...
你说的这种模式，本质上就是分布式事务的两阶段提交模式，这种技术２０年前就出现了，在ＴＵＸＥＤＯ、ＣＩＣＳ、ＴＯＮＧＥＡＳＹ等交易中间件上都有很好的支持。
但为什么除了一开始在大行的小分行上有所应用，到后来得改为超时反交易或补交易的处理机制？为什么有简单可实现的技术不用而要通过开发出多一倍的超时处理 交易来完成？ 这说明了这种2PC的模式，在真正大规模并发的关键型银行交易系统中是弊多利少，严重时甚至出现死锁关键资源而导致全行无法营业的情况。
不要再闭门造车想当然的研发什么产品了，多经历一些大型系统的建造，积累更多的经验再去思考大型银行系统技术平台真正的需要吧！
不要再随便胡吹领先世界５－１０年这样的疯言疯语了，永远没人把它当真。 作者: efsca 时间: 2012-2-26 18:50
CountOnMyself 发表于 2012-2-25 14:27
你说的这种模式，本质上就是分布式事务的两阶段提交模式，这种技术２０年前就出现了，在ＴＵＸＥＤＯ、Ｃ ...
1、你真的仔细看完了我们所提的手动处理模式了么？你真的看懂了么？？
2、要论大型系统的建造，我到真是造过不少，我们建造的前置系统在一家省分行的日均交易量都超千万，怎么说我们是闭门造车呢？这个模式实际上是在总结我们01年上线的前置系统几年来运行出现的问题并研究各种解决之后的一些成果。
3、我们可从没说过领先世界5-10这样的“疯言疯语”，不知你从哪儿看到的啊 作者: efsca 时间: 2012-2-26 18:58
efsca 发表于 2012-2-26 18:50
1、你真的仔细看完了我们所提的手动处理模式了么？你真的看懂了么？？
2、要论大型系统的建造，我到真是 ...
呵呵，不过我们倒是的确说过我们至少要领先一家国内的“号称世界领先”的平台软件开发商好几年的话，这个恐怕不足以让你得出我们领先世界5-10年这样的推论吧 作者: efsca 时间: 2012-2-26 18:58
CountOnMyself 发表于 2012-2-25 14:27
你说的这种模式，本质上就是分布式事务的两阶段提交模式，这种技术２０年前就出现了，在ＴＵＸＥＤＯ、Ｃ ...
呵呵，不过我们倒是的确说过我们至少要领先一家国内的“号称世界领先”的平台软件开发商好几年的话，这个恐怕不足以让你得出我们领先世界5-10年这样的推论吧 作者: efsca 时间: 2012-2-26 19:23
还不了解我们的，可以看看的我们产品介绍，欢迎大家交流和拍砖：
http://www.eframesoft.com/infos.php?type=1
http://www.eframesoft.com/infos.php?type=2
http://www.eframesoft.com/infos.php?type=3 作者: efsca 时间: 2012-2-26 19:35
版主，网站是不是出问题了 作者: jenifer23710092 时间: 2012-2-26 20:30
efscao 发表于 2012-2-6 17:24
？我记得我们谈到ATM是因为我们在讨论异步模型用在哪里（集中处理中心->银联前置->ATM前置），而不是一致 ...
图2.1 用整体处理方式处理一致性问题的服务应用
显然，从业务角度看整体处理方式要优于分解处理方式——对于柜员而言，操作压力大大降低，不容易出错；对于银行而言，不需要向柜员开放“撤消本行帐务系统的现金收取登记”和“单独调用公司的购买产品服务”等功能，更好地控制了操作风险。
但是整体处理方式需要开发人员针对具体应用进行极其细致而繁琐的一致性处理设计（图2.1仍然有许多情况没有考虑到），稍有不慎，则会导致难以想象的后果，因此，目前金融行业采用整体处理方式来应对这种情形的应用比例还相当低。
所谓手动处理模式，就是由Service Center的服务应用框架代替应用，提供统一的一致性处理服务，用一种标准化的、逻辑极其严密的整体处理方式来解决所有自动处理模式无法处理的一致性问题，从而大大降低开发人员的负担。
=================
是否这块可以用一种可配置的策略代替，比如你提到的流程，先怎么后怎么，增加服务治理、管理平台，基于策略的方式，某一类服务可以根据某一类的策略 保持一致性。例如，购买他行基金这种服务的撤销策略是，先查询是否成功，在进行下一步处理。 作者: efsca 时间: 2012-2-26 20:40
jenifer23710092 发表于 2012-2-26 20:30
图2.1 用整体处理方式处理一致性问题的服务应用
显然，从业务角度看整体处理方式要优于分解处理方式 ...
确实，不同的服务集成时会有不同的策略，这种控制可以采用配置方式。但这并非一种替代关系。多种模式，相当于处理一致性问题多种手段，是必须都拥有的，具体调用时采用哪种手段消除一致性问题，可以考虑以配置的方式进行控制 作者: CountOnMyself 时间: 2012-2-27 11:47
efsca 发表于 2012-2-26 18:50
1、你真的仔细看完了我们所提的手动处理模式了么？你真的看懂了么？？
2、要论大型系统的建造，我到真是 ...
不是人家看不懂你们，是你们自已没弄懂罢了。
自动和手动的主要差别在哪里，你自已根本没搞清楚。
说什么银联卡交易可以手动，你弄清楚银联通讯协议要求了吗？时间窗口是协议规定的，不是任何一方可以随意手动调整的。
所谓整体处理方式，说明白了不外乎两个方案：一是全局事务（ＸＡ协议），但我前面说过了，这玩意用不成；二是多个自动反交易的流程化，这种方式已是现实模 式，很多厂商的前置系统只要有流程引擎，有自动重发器的，都可以轻易实现，但反交易的开发量是一点少不了，没有你说的那么神秘。
国内厂商前置系统有精深积累的其实不少，你说得领先国内Ｎ年，有了解过国内所有产品了吗？又看过了多少银行正在使用的系统呢？ 作者: cavern1026 时间: 2012-2-27 13:42
看的比较晕！都是OLTP业务，还要把处理线程休眠，这样我使简单问题复杂话了！
会引出其他附带问题，比如重账等等！ 作者: efsca 时间: 2012-2-27 18:45
CountOnMyself 发表于 2012-2-27 11:47
不是人家看不懂你们，是你们自已没弄懂罢了。
自动和手动的主要差别在哪里，你自已根本没搞清楚。
说什 ...
我看有些人逻辑漏洞确实多，这要是数学专业的，考试恐怕是很难及格的。
我说领先国内某家“号称世界领先”的开发商N年，就可以推出我的意思是领先国内N年么？？也许不只是数学不行，我看语文也没过关。
我看，逻辑有这样漏洞的人，就不必来研究这种一致性问题了 作者: efsca 时间: 2012-2-27 18:53
cavern1026 发表于 2012-2-27 13:42
看的比较晕！都是OLTP业务，还要把处理线程休眠，这样我使简单问题复杂话了！
会引出其他附带问题，比如重 ...
确实，一般程序员是很难都理解这些模式的，让他们按照这种模式解决问题，也的确会像你所说那样，引出许多其他问题。那么我们怎么解决这个矛盾呢？那只能是 由一些思维极为严谨的开发人员在应用框架中提供一种统一的解决机制，这样就不需要所有应用开发人员再考虑这个问题了。能够开发这种应用框架的技术人员在整 个银行IT从业人员中比例恐怕不会超过1/1000。 作者: efsca 时间: 2012-2-27 19:11
CountOnMyself 发表于 2012-2-27 11:47
不是人家看不懂你们，是你们自已没弄懂罢了。
自动和手动的主要差别在哪里，你自已根本没搞清楚。
说什 ...
说什么银联卡交易可以手动，你弄清楚银联通讯协议要求了吗？时间窗口是协议规定的，不是任何一方可以随意手动调整的。
——你说的是超时吧，这和手动处理有什么关系啊。比如说跨行存款超时了，那么按照手动处理模式的设计，我们在柜面上可以选择“继续尝试”，服务系统会有一 个新的交易来处理你“继续尝试”的请求，它会先查询先前那笔超时的跨行存款成没成，成就可沿着跨行存款成功的分支继续处理下去，不成就再调用一次。先前的 超时在这里有什么障碍啊。
你说有自动重发都可以轻易实现——自动重发什么呀？冲正吧。好好想想吧，仅从操作者的界面来看，就是完全不同的，这和我说的手动处理模式能是一回事么 作者: CountOnMyself 时间: 2012-2-28 14:42
efsca 发表于 2012-2-27 19:11
说什么银联卡交易可以手动，你弄清楚银联通讯协议要求了吗？时间窗口是协议规定的，不是任何一方可以随意 ...
——你说的是超时吧，这和手动处理有什么关系啊。比如说跨行存款超时了，那么按照手动处理模式的设计，我们在柜面上可以选择“继续尝试”，服务系统会有一个新的交易来处理你“继续尝试”的请求，它会先查询先前那笔超时的跨行存款成没成
请问：银联协议有超时结果查询的报文吗？ 你真了解了银联交易协议吗？
再问：协议要求是超时就无条件认为失败，受理方要主动发起冲正以保证交易结果一致性。用你的平台手动模式，又查不了结果，怎么办啊？
三问：象这种交易协议与你平台的手动模式不匹配的情况，要求人家改协议？ 作者: CountOnMyself 时间: 2012-2-28 14:49
本帖最后由 CountOnMyself 于 2012-2-28 14:52 编辑
efsca 发表于 2012-2-27 18:45
我看有些人逻辑漏洞确实多，这要是数学专业的，考试恐怕是很难及格的。
我说领先国内某家“号称世界领先 ...
别人逻辑再怎么有问题，至少还知道众多的交易协议中，超时处理有三种模式：超时冲正（还原）、超時确认（重传）和超时查询。而你的逻辑，只知道一种模式， 还以为全世界的超时处理模式都可以统一在贵家平台的“超时查询”模式的大旗下。问题是，目前行业标准协议中，超时查询是用得最少的，其它两种大量存在。按 你的逻辑，是不是要让贵公司先把众多协议先统一掉，所以大家都不用再研究什么事务一致性，剩下你一个人研究好了？
这种果然是没有漏洞的逻辑啊，我又见到高人了！ 作者: efsca 时间: 2012-2-28 15:18
CountOnMyself 发表于 2012-2-28 14:49
别人逻辑再怎么有问题，至少还知道众多的交易协议中，超时处理有三种模式：超时冲正（还原）、超時确认（ ...
这个思维真是太有跳跃性了。
你怎么就断定我“只知道一种模式”啊？？我们又什么时候说过要“统一在超时查询模式下”啊？？
你仔细看过我们讲的自动模式了么？那个自动模式主要就是依赖超时冲正，这你没看出来么？！
别急着反击，先仔细看看别人说了什么，再好好想想自己该怎么发言。 作者: efsca 时间: 2012-2-28 15:33
CountOnMyself 发表于 2012-2-28 14:42
——你说的是超时吧，这和手动处理有什么关系啊。比如说跨行存款超时了，那么按照手动处理模式的设计，我 ...
1、我们这里需要超时后能够查询结果的功能，相应的报文就必须叫“超时结果查询”么？这是什么逻辑啊。
请你好好看看银联的“存款确认”接口，那个接口就是存款交易超时后用于查询先前存款操作结果的
2、银联协议要求“超时就无条件认为失败”？谁跟你讲的啊，取现、消费类交易是这样，存款类的呢？？
有些人可能做过一些应用，就立即认为自己是这个领域的专家了，这种专家还是少出点为妙！ 作者: CountOnMyself 时间: 2012-2-28 15:39
本帖最后由 CountOnMyself 于 2012-2-28 15:43 编辑
efsca 发表于 2012-2-28 15:18
这个思维真是太有跳跃性了。
你怎么就断定我“只知道一种模式”啊？？我们又什么时候说过要“统一在超时 ...
原来你是知道的啊？ 既然知道了，那你还是回答一下，你所提倡的手动模式，如何解决银联超时交易的问题吧？
首先告诉一点你没弄懂的事实： 银联协议是没有超时结果查询报文的，你好好考虑如何回答吧。
再告诉你一些你可能仍然没弄懂的事实： 银行交易的事务一致性问题，并不是仅仅系统请求端和系统服务端两方关系，而是涉及受理方机构、发送方机构、交换中心、接收方机构等多方参与者，而每一方都 涉及到终端、前置、核心等多套系统。这种交易的一致性，说白了就是N方*N个系统的一致性问题。
真能存在一个平台或者一个简单模式就能实现这种复杂场景的多方一致性问题吗？ 你们真的都认真考虑过了，而且认为有说服力？事实上，交易系统的复杂性和多样性，绝对超出你们想象范围之外，没有任何一个平台或者一种简单模式可以轻易解 决，是必须集中交易协议设计者、业务模型设计者、系统设计和实施者等多方的智慧才能完善解决的问题！
作者: CountOnMyself 时间: 2012-2-28 15:39
本帖最后由 CountOnMyself 于 2012-2-28 15:43 编辑
efsca 发表于 2012-2-28 15:18
这个思维真是太有跳跃性了。
你怎么就断定我“只知道一种模式”啊？？我们又什么时候说过要“统一在超时 ...
原来你是知道的啊？ 既然知道了，那你还是回答一下，你所提倡的手动模式，如何解决银联超时交易的问题吧？
首先告诉一点你没弄懂的事实： 银联协议是没有超时结果查询报文的，你好好考虑如何回答吧。
再告诉你一些你可能仍然没弄懂的事实： 银行交易的事务一致性问题，并不是仅仅系统请求端和系统服务端两方关系，而是涉及受理方机构、发送方机构、交换中心、接收方机构等多方参与者，而每一方都 涉及到终端、前置、核心等多套系统。这种交易的一致性，说白了就是N方*N个系统的一致性问题。
真能存在一个平台或者一个简单模式就能实现这种复杂场景的多方一致性问题吗？ 你们真的都认真考虑过了，而且认为有说服力？事实上，交易系统的复杂性和多样性，绝对超出你们想象范围之外，没有任何一个平台或者一种简单模式可以轻易解 决，是必须集中交易协议设计者、业务模型设计者、系统设计和实施者等多方的智慧才能完善解决的问题！
作者: efsca 时间: 2012-2-28 15:45
CountOnMyself 发表于 2012-2-28 15:39
原来你是知道的啊？ 既然知道了，那你还是回答一下，你所提倡的手动模式，如何解决银联超时交易的问题吧？ ...
“银行交易的事务一致性问题，并不是仅仅系统请求端和系统服务端两方关系，而是涉及受理方机构、交换中心、接收方机构等多方参与者，而每一方都涉及到终端、前置、核心等多套系统。这种交易的一致性，说白了就是N方*N个系统的一致性问题。
真能存在一个平台或者一个简单模式就能实现这种复杂场景的多方一致性问题吗？ 你们真的都认真考虑过了，而且认为有说服力？事实上，交易系统的复杂性和多样性，绝对超出你们想象范围之外，没有任何一个平台或者一种简单模式可以轻易解 决，是必须集中交易协议设计者、业务模型设计者、系统设计和实施者等多方的智慧才能完善解决的问题！”
呵呵，这段话说了一番大道理，这倒是没有什么大问题，我们也是这么认为的。所以，需要真正的专家仔细地考虑一致性的各种处理机制，并用以改进各个领域的工作，也包括某些制订标准的组织的工作————这恰恰就是我们的初衷 作者: CountOnMyself 时间: 2012-2-28 15:52
本帖最后由 CountOnMyself 于 2012-2-28 15:54 编辑
efsca 发表于 2012-2-27 19:11
说什么银联卡交易可以手动，你弄清楚银联通讯协议要求了吗？时间窗口是协议规定的，不是任何一方可以随意 ...
－－你说有自动重发都可以轻易实现——自动重发什么呀？冲正吧。
再回复你这个问题，重发什么？ 我还真不会告诉你太多，如果你自已真的懂了，你自已看看各种协议中，有哪些报文是可以存储转发的，就知道能重发什么了。如果你只知道“冲正”一种，说明你自诩的“有逻辑”就是在闭门造什么的了，别不让人家说你。 作者: efsca 时间: 2012-2-28 16:01
CountOnMyself 发表于 2012-2-28 15:52
－－你说有自动重发都可以轻易实现——自动重发什么呀？冲正吧。
再回复你这个问题，重发什么？ 我还真不 ...
通知类报文大多均可存储重发，当然不只是冲正。不过你这也太能断章取义了，你得把整条句子翻出来，好好看看我说那句话的目的——是在你无法弄清自动模式和手动处理模式的区别的前提下，举出冲正为例！
晕 作者: CountOnMyself 时间: 2012-2-28 16:04
efsca 发表于 2012-2-28 16:01
通知类报文大多均可存储重发，当然不只是冲正。不过你这也太能断章取义了，你得把整条句子翻出来，好好看 ...
通知类报文大多均可存储重发???
算了，不说你了，你继续造你的大好平台吧 作者: efsca 时间: 2012-2-28 16:10
CountOnMyself 发表于 2012-2-28 16:04
通知类报文大多均可存储重发???
算了，不说你了，你继续造你的大好平台吧
我不知道你对通知类报文是怎么理解的。不过我这里提到的“通知类报文”可决不是什么 某个参与方发个文本通知之类的，而是包括：冲正、存款确认等报文 作者: efsca 时间: 2012-2-28 16:11
CountOnMyself 发表于 2012-2-28 16:04
通知类报文大多均可存储重发???
算了，不说你了，你继续造你的大好平台吧
这是我们在2000年设计行内交换系统时采用的术语，就不知道你听过没有了 作者: CountOnMyself 时间: 2012-2-28 16:17
本帖最后由 CountOnMyself 于 2012-2-28 16:18 编辑
efsca 发表于 2012-2-28 16:10
我不知道你对通知类报文是怎么理解的。不过我这里提到的“通知类报文”可决不是什么 某个参与方发个文本通 ...
结算通知算吗？
清算通知算吗？
退货通知算吗？
授权完成通知算吗？
日切通知算吗？
双转单交易通知算吗？
订购类交易通知算吗？
汇款通知算吗？
重发试试看！
作者: efsca 时间: 2012-2-28 16:22
CountOnMyself 发表于 2012-2-28 16:17
结算通知算吗？
清算通知算吗？
退货通知算吗？
呵呵，说句实话，有些我还真是不知。05年后我再也未编写过这类程序。
但当年提出一个“通知类”的概念，不一定就是你现在想象中的通知报文，而是依据交易处理模式来划分的，请求/响应类的处理模式是整个处理过程完成后才返回应答；通知类报文则是收到后立即返回应答，而后才开始处理。
一个名词，各有各的理解，正常，而且，我的理解更可能是过时的，但我想我们也不至于纠结在这个分类名词上吧，有很多前面提到的具体问题，我想你还没有好好应答吧 作者: efsca 时间: 2012-2-28 16:25
“请求/响应类的处理模式是整个处理过程完成后才返回应答；通知类报文”，再补充一句啊，这是当年的概念，不要再断章取义了 作者: CountOnMyself 时间: 2012-2-28 16:28
efsca 发表于 2012-2-28 16:22
呵呵，说句实话，有些我还真是不知。05年后我再也未编写过这类程序。
但当年提出一个“通知类”的概念， ...
不是我没应答吧，是你没听明白罢了。
倒是你还一直在逃避， 你的手动模式可以解决银联超时交易的办法，在哪呢？ 作者: efsca 时间: 2012-2-28 16:29
CountOnMyself 发表于 2012-2-28 16:28
不是我没应答吧，是你没听明白罢了。
倒是你还一直在逃避， 你的手动模式可以解决银联超时交易的办法，在 ...
好，那就再发一遍：
发表于 2012-2-28 15:33:16 |只看该作者 CountOnMyself 发表于 2012-2-28 14:42
——你说的是超时吧，这和手动处理有什么关系啊。比如说跨行存款超时了，那么按照手动处理模式的设计，我 ...
1、我们这里需要超时后能够查询结果的功能，相应的报文就必须叫“超时结果查询”么？这是什么逻辑啊。
请你好好看看银联的“存款确认”接口，那个接口就是存款交易超时后用于查询先前存款操作结果的
2、银联协议要求“超时就无条件认为失败”？谁跟你讲的啊，取现、消费类交易是这样，存款类的呢？？
有些人可能做过一些应用，就立即认为自己是这个领域的专家了，这种专家还是少出点为妙！
作者: CountOnMyself 时间: 2012-2-28 16:31
efsca 发表于 2012-2-28 15:33
1、我们这里需要超时后能够查询结果的功能，相应的报文就必须叫“超时结果查询”么？这是什么逻辑啊。
请 ...
存款确认是查询结果的报文？
哈哈！！！
我服你了！！！
和你讨论这么久，才知道我在和一个什么人在讨论！
浪费时间了，你继续吧！
作者: CountOnMyself 时间: 2012-2-28 16:34
本帖最后由 CountOnMyself 于 2012-2-28 16:51 编辑
efsca 发表于 2012-2-28 15:33
1、我们这里需要超时后能够查询结果的功能，相应的报文就必须叫“超时结果查询”么？这是什么逻辑啊。
请 ...
“再问：协议要求是超时就无条件认为失败，受理方要主动发起冲正以保证交易结果一致性。用你的平台手动模式，又查不了结果，怎么办啊？”
这才是我的原话，是你说的意思吗？
我的问题是，协议要求你这样，你的手动模式如何支持？ 还是让你回答你的解决办法，别扯其它。
作者: CountOnMyself 时间: 2012-2-28 16:38
efsca 发表于 2012-2-28 16:29
好，那就再发一遍：
发表于 2012-2-28 15:33:16 |只看该作者 CountOnMyself 发表于 2012-2-28 14:42 ...
你再发100次都没用。存款确认报文，可不是5年前才出来的报文，象你说的2000年已经开始做，做了5年还没搞明白这个报文是干什么用的？
如果按你这位“砖家”的逻辑， 是不是还要弄出“取款确认”、“消费确认”、“授权确认”等查询类报文才能满足你的超时查询结果要求嘛？
我还真从来没把自已当过什么“砖家”， 没想到这次真真实实找到真正的”砖家“了！
作者: CountOnMyself 时间: 2012-2-28 16:48
本帖最后由 CountOnMyself 于 2012-2-28 16:52 编辑
efsca 发表于 2012-2-28 16:29
好，那就再发一遍：
发表于 2012-2-28 15:33:16 |只看该作者 CountOnMyself 发表于 2012-2-28 14:42 ...
兄弟，不好意思这次让你丢人丢大了。
一直都领会不了你的所谓“严密逻辑”， 这会才发现原来你们对协议理解的逻辑居然与全世界人是不一样的。
这里的都是行家，想信没人不知道存款确认＝存款重发，不过这与你的逻辑可能是格格不入的，你可能永远也接受不了这种“尊守交易协议”的逻辑。
所以只能说，兄弟，你的逻辑严密性，无敌了！
面对你这位“砖家”高人, 我还是退避了吧. 作者: efsca 时间: 2012-2-28 16:57
CountOnMyself 发表于 2012-2-28 16:31
存款确认是查询结果的报文？
哈哈！！！
我服你了！！！
思维惯性真的太蒙蔽人的眼睛了。到底是怎么回事，欢迎每个人都去了解一下跨行存款超时的工作机制：
http://www.docin.com/p-50681555.html
尽管这个跨行存款在业内未能大规模推开，但文档还是讲的很清楚的 作者: efsca 时间: 2012-2-28 16:58
CountOnMyself 发表于 2012-2-28 16:31
存款确认是查询结果的报文？
哈哈！！！
我服你了！！！
请直接翻到101页 作者: efsca 时间: 2012-2-28 17:01
CountOnMyself 发表于 2012-2-28 16:34
“再问：协议要求是超时就无条件认为失败，受理方要主动发起冲正以保证交易结果一致性。用你的平台手动模 ...
我何时讲过手动模式适合处理所有一致性问题？？ 作者: efsca 时间: 2012-2-28 17:02
CountOnMyself 发表于 2012-2-28 16:48
兄弟，不好意思这次让你丢人丢大了。
一直都领会不了你的所谓“严密逻辑”， 这会才发现原来你们对协议理 ...
老弟，我给你再加一个等号：
存款确认＝存款重发=存款查证
以破除你的思维定式 作者: efsca 时间: 2012-2-28 17:05
efsca 发表于 2012-2-28 17:02
老弟，我给你再加一个等号：
存款确认＝存款重发=存款查证
以破除你的思维定式
这个等式你那一部分还不一定成立呢
存款确认=存款查证！=存款重发
作者: CountOnMyself 时间: 2012-2-28 17:08
本帖最后由 CountOnMyself 于 2012-2-28 17:09 编辑
efsca 发表于 2012-2-28 16:58
请直接翻到101页
101页只告诉你存款超时要发“存款确认”，没告诉你这是个查询报文！文档不够使了，不知道该看哪份文档？
初学者是吧？ 那就虚心点， 我可以告诉你一些信息，你不是很能google吗？你就好好去搜索一下吧, 我贴点信息给你看看权当扫盲：
《中国银联银行卡联网联合技术规范V2.1 第1部分 交易处理说明.pdf》 P13：
--当终端在限定时间内接收不到存款交易请求的应答或检测到应答报文MAC错时，必须产生存款确认交易。
--当CUPS未收到发卡方对存款请求的应答时，CUPS向发卡方转发受理方发来的存款确认通知， 发卡方以存款确认通知做确认记账处理。
--当CUPS收到发卡方对存款请求的应答，而受理方未收到CUPS的应答时，受理方转发终端发来的存款确认通知，CUPS直接给受理方应答，不需要往发卡方转发。
--当存款确认的发送方收不到应答时，则将存款确认通知存放在存储转发队列中进行存储转发。
-- 发卡方一旦成功接收到存款确认通知，应无条件予以承兑。
--存款确认不允许跨越清算日。若受理方不能在CUPS日切前成功处理完存款确认交易，则应在事后进行差错处理。
--受理方完成存款确认交易后不能进行存款撤销，对账不平时通过差错处理解决。
作者: CountOnMyself 时间: 2012-2-28 17:12
efsca 发表于 2012-2-28 17:05
这个等式你那一部分还不一定成立呢
存款确认=存款查证！=存款重发
别死撑了，技术人员的绝症，死不认错！你愿意继续丢人，继续闹笑话就继续。 作者: CountOnMyself 时间: 2012-2-28 17:16
本帖最后由 CountOnMyself 于 2012-2-28 17:20 编辑
efsca 发表于 2012-2-28 17:01
我何时讲过手动模式适合处理所有一致性问题？？
没人要你解决所有， 是你说的适用于银联交易， 所以只要求你用此模式解决银联交易！ 作者: efsca 时间: 2012-2-28 17:19
CountOnMyself 发表于 2012-2-28 17:08
101页只告诉你存款超时要发“存款确认”，没告诉你这是个查询报文！文档不够使了，不知道该看哪份文档？
...
存款确认——本质上就是一个重复+查证的交易
即，如果先前没发生，那么记账返回结果，但是注意，帐不一定能记成！发卡方有可能帐户无效
如果先前有发生，则把先前的结果返回
在手动模式中应用这个接口是非常合理的，因为单纯的查证接口（如果存在的话）调用后，原交易失败的话，还要继续再调用一次存款交易，而这个存款确认接口可以一次性完成，可以说是手动处理模式所需的一个最理想的接口。 作者: CountOnMyself 时间: 2012-2-28 17:19
efsca 发表于 2012-2-28 17:02
老弟，我给你再加一个等号：
存款确认＝存款重发=存款查证
以破除你的思维定式
是别人的定式，还是你自已的定式？
这个交易与查证有哪怕半毛钱的关系？
有无条件承兑的查询交易吗？
无条件承兑＝查询？？？
也许你坚持你的逻辑永远正确，坚持将这种逻辑实现在你的领先XX N 年的平台上。
不过， 不问市场， 先问问这个坛子里的路人， 敢用吗？