J2EE架构的银行核心业务系统

据了解，目前国内完全J2EE架构的银行核心业务系统是没有的。都是基于Tuexdo或cics。
最近在看后台Tuexdo 的C代码，真是难以形容，竟有7、8千行的一个函数。对于维护来说，成本实在太高了。据说这些是当时的C高手写的程序，此致敬礼。

但是，有那么必要那么复杂吗？银行的业务都是标准的业务，不是很复杂。
突然，萌生了用J2EE架构的银行核心业务系统来replace的想法，呵呵，我也知道，这是不可能的，很多原因啦，至少银行方面是不同意的。偶然机会，和技术总监聊天的时候提了一下，下面是我们的看法：
1、从技术方面来讲，完全基于J2EE实现是可以的，performance已经不成问题。
2、技术团队的力量，对于团队来讲，专业技术（单就coding skill来讲）应该不是问题，但是我们对业务的理解还不够，是的，真正懂技术，有熟悉业务的人才真的很重要。
3、总体设计难度，业务模型的设计、数据模型设计都是难度很高的，国外有此类设计，但流程和国内不尽相同。
4、商业角度，core banking 成本真的很大。就软件行业来说，银行综合业务系统成本真的很高。
5、风险防范，没有人愿意担这个风险，现有系统的话，是不可能被replace的。除非是全新新开放，即使全新开发，也会稳妥的选择基于大家公认的成熟类似Tuexdo中间件，而不会采用J2EE架构。

所以，目前银行的软件系统群开发，都是尽量不要在核心上做，而是以外挂的形式开发，而且尽量基于J2EE架构（如果可以的话）。在银行软件业J2EE是趋势。一旦条件成熟，J2EE架构的银行核心业务系统 就会取得应有的地位。


javaeye 对行业解决方案的讨论不是很hot，希望大家都来发表啊。

金融行业软件，在技术上面是非常保守的，你要在技术上做一些改进，实在很难。其实不妨把精力放在软件系统的监控、健康检查这些方面，估计客户还是会比较欢迎你做这些技术改进的。

确实如此，金融行业的软件，有的是很久以前写的程序了，我们需现在看来，有些代码真的是不好的，效率也不高，设计上就存在问题（有些是上个世纪的代码了，记过n个人改动过，面目全非），可能是当时的技术发展的限制导致的吧。
但是银行方面就是不愿做技术改进，宁愿缝缝补补，性能跟不上了就用硬件来弥补，动不动就买HP的superdome或IBM的大机器，几千万几千万的砸进去，都tm让老外挣走了。反正他们花的也不是自己的钱，那可是我们纳税人的钱啊。一个应用软件对其硬件的需求，开发员比谁都明白。

要是把这些资金合理的规划，更多的比例花在软件上。而且有个真正的有能力，有责任心的人带队，做出来的东西未必会比人家的差。这是鄙人的感言。

j2ee做界面是没问题的

但是核心业务还是不行的

性能确实不行

比如说我手头有个倒数据的小软件,JAVA实现了的时间是DELPHI的一倍.汗


Tuexdo对数据库访问的性能.基本和JAVA就不是一个数量级

JAVA差的很远~~

首先，Tuexdo使用Pro*C，对数据库的访问性能无可挑剔。
我看了一些Tuexdo中的C代码，似乎陷入了这样一种情况，只要是访问的数据在数据库中，则就会通过访问数据库来获取。这样一来，数据库这边承受很大的压力。
如果基于J2EE来架构系统的话，可以考虑在多个层面上做缓存，减少对数据库的访问压力，这样一来，整体性能不见得差很远。

对于银行的业务来说,个体的数据都是异样的.怎么个缓存法,你说说

谁敢拍这个板把core bank系统全换掉？
出了问题谁敢负这个责？

是的，对于标准数据可以做缓存，但是业务上的数据都是现查数据库。
但是有个问题，我们的很多数据是直接通过访问数据库得到的数据值，或数据结果集，基本上在载体语言上不用再另做复杂的运算，这样一来，压力是在数据库端的，和应用不同载体语言的差异不是很大。
当然，一个金融系统不可能只用一门语言开发，在某些确实存在性能瓶颈的，比如年终、结息、跑批处理之类，可以用C做，这些业务基本上变动的很小。而在其他的很多交易，可以基于J2ee，在业务扩展，和维护方面都比C好。

J2EE的可靠性呢？
在系统资源的使用方面，C仍旧是有优势的。
java垃圾处理时的响应时间会比正常时差很多。
另外，作为24小时在线的核心业务系统，可靠、稳定、大数据量并发处理能力比技术的更迭更重要。

说到原有代码设计上的问题，
单纯看代码是很难看出设计上的问题的……
如果说哪位可以从函数的行数上看出什么设计上的问题，，真是高人了。拜服。

整体设计是不会有什么问题的，细部的函数设计上有些地方效率不高很正常，长期维护的代码，不同的人修修补补，水平参差不齐，出现这个结果很正常。但是这个和技术更迭无关，根本扯不到什么J2ee上去，J2ee开发就能保证不出现低效代码了么？

所以，这个替代方案的可行性本身就存在问题。
1、从技术方面来讲，完全基于J2EE实现是可以的，performance已经不成问题。
2、技术团队的力量，对于团队来讲，专业技术（单就coding skill来讲）应该不是问题，但是我们对业务的理解还不够，是的，真正懂技术，有熟悉业务的人才真的很重要。
3、总体设计难度，业务模型的设计、数据模型设计都是难度很高的，国外有此类设计，但流程和国内不尽相同。
4、商业角度，core banking 成本真的很大。就软件行业来说，银行综合业务系统成本真的很高。
5、风险防范，没有人愿意担这个风险，现有系统的话，是不可能被replace的。除非是全新新开放，即使全新开发，也会稳妥的选择基于大家公认的成熟类似Tuexdo中间件，而不会采用J2EE架构。[/QUTOE]
1、C的性能肯定仍旧比java好
2、在什么位置做什么事，又懂技术、又懂业务的人假设如果存在，你会怎么使用？
3、国外设计的流程和国内的流程当然不同，每个银行都需要在成熟的framework上定制自己的系统。这一点表述和你的第二点有什么区别么？
4、即使成本很高也有很多种做法，你想采用的做法是什么？例如，方案1、采用J2EE开发完整系统，完全替代现有系统；方案2、开发基于J2EE的中间件平台替换掉现有的Tuexdo层，然后再基于这个新的层进行业务开发；方案3、选择性的将现有业务层处理逐步打包迁移到J2EE构架……
5、和你说的第四点有区别么？好像是一个意思？
在你没有预备方案的情况下，成本和风险都不可控，然后，我说的就都是废话了……