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

支付宝的涉及到钱的交易系统是tuxedo.

为什么要将核心系统换成J2EE?ＬＺ给个理由先。即使用另一种技术将现有的系统重新实现一遍（速度上的差异都忽略），如果你是银行方，你会换吗？即使技术突飞猛进，最终还是要换的话，那也是ＩＢＭ们做的事。现实一点的话，还是作银行的外围特色投行等业务。现在就大把机会。

这个是在胡扯,谁说银行的CORE BANKING业务不是很复杂的,我们的CORE BANKING业务现在老老实实地泡在大机上用cobol砌着,有些中小地区的就在iSeries上,java最多敢做一些前端点的工作,最近知道有一个组这一年处于多方面考虑,用java想替代原来在iSeries上跑得很爽的核心程序,一直在为performance烦恼着.

如果现有的核心系统用得好好的，速度快、稳定、容易扩展，就不要没事找事干，钱不是这样花的，也没人陪你冒风险

其实，银行的新业务很多都是构筑在现有的核心交易之上的，所以完全可以使用新技术集成

还有各种的分析系统，基本上都是从大机获取返传数据进行脱机处理，想用什么技术都可以

譬如我现在所在的职位，负责开发各种的信息管理，分行特色业务流程，OLAP之类比较前端的东西，基本上各种新技术都能尝鲜，.Net, Java, ROR, Python我用个遍，反正业务部门不管你用什么技术，能出东西就好

怎么没有，本人就做过一个

过程性语言需要什么架构，多拆方法，少用全局变量就行了，你要把面向对象和面向过程来比架构稳定性本来就不对。
要这么说，java也不用架构直接上来就过程式编程，不来框架这一套和C有什么区别

见过强词夺理的，没见过这么强词夺理的

 

不是强词夺理，你可以反驳我，如果我说错了，我也很高兴又学到东西，我认为之所以不换，和架构没什么关系，一个是性能，一个惯性(没坏的东西，干嘛要去修他)。至于架构，考虑到银行系统不可能几年就换个新系统，过10几20年，什么架构都是过时的，都是腐朽的。

那照你的逻辑，只要“多拆方法，少用全局变量”，就能用C写出UNIX了？

支付宝根本没有银行那么复杂的会计和业务系统。支付宝顶多只是一个简单的银行前置。