|
锁定老帖子 主题：J2EE架构的银行核心业务系统
精华帖 (14) :: 良好帖 (2) :: 新手帖 (0) :: 隐藏帖 (2)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-06-18
最后修改：2009-06-18
hlylove 写道
wendong007 写道
退一步讲，LZ谈到的这几点，最多也就是说J2EE可以replace Tuexdo，说不上有多大的优势，银行为什么要替换呢，进一步讲，LZ讲的有些观点是根本不成立的，对一个银行来讲，成本问题算不上多大的问题，对他们来说可靠性才是最重要的
至于缓存的问题，我倒希望银行能够采用一下，把我的帐户余额缓存一下……
当然是取钱时缓存了，把所有钱都取出来，余额为零。再到另一个取款机上继续取。 太爽了 |
| 返回顶楼 | |
|
发表时间：2009-06-25
brofe 写道
wendong007 写道
退一步讲，LZ谈到的这几点，最多也就是说J2EE可以replace Tuexdo，说不上有多大的优势，银行为什么要替换呢，进一步讲，LZ讲的有些观点是根本不成立的，对一个银行来讲，成本问题算不上多大的问题，对他们来说可靠性才是最重要的
至于缓存的问题，我倒希望银行能够采用一下，把我的帐户余额缓存一下……
有创意。 看来作者的余额还是很可观的。 我可不想缓存余额。呵呵 |
| 返回顶楼 | |
|
发表时间：2009-07-06
君淋天下 写道
hlylove 写道
wendong007 写道
退一步讲，LZ谈到的这几点，最多也就是说J2EE可以replace Tuexdo，说不上有多大的优势，银行为什么要替换呢，进一步讲，LZ讲的有些观点是根本不成立的，对一个银行来讲，成本问题算不上多大的问题，对他们来说可靠性才是最重要的
至于缓存的问题，我倒希望银行能够采用一下，把我的帐户余额缓存一下……
当然是取钱时缓存了，把所有钱都取出来，余额为零。再到另一个取款机上继续取。 太爽了
不会出现你这种情况的，他又余额锁定，即使有缓存也不可能出现这种情况的，它有个余额锁定的，如果有缓存只有可能出现这种情况，去到另外一个ATM去取发现没有钱，可能过了一会儿再去取，发现钱又有了。主要是只要你去取钱他就会锁定一个数目2.5k，如果是小于这个数字，他也会锁定这个钱的。缓存的就是是这个钱，只可能是你“吃亏”，不会出现你“沾光”的现象，不过这个也是一种安全机制，这个是和OCS的鉴权机制是一样的 |
| 返回顶楼 | |
|
发表时间：2009-07-06
不保护it的现有资产怎莫行呢，都是人民币啊
|
| 返回顶楼 | |
|
发表时间：2009-07-16
缺少足够的动力。除非有革命性的变化，否则没那么容易推陈出新。时代变迁需要革命。
|
| 返回顶楼 | |
|
发表时间：2009-07-17
如果说重新做，用已经成熟的设计思想去设计，当然会比以前的系统好。
但从语言上来说，java的优势其实很不明显。 外挂，很明显的一个好处就是耦合性低。 |
| 返回顶楼 | |
|
发表时间：2009-07-17
引用一个资料“目前在COBOL方面的投资已经超过3万亿美元，据称用COBOL书写的程序超过了1000亿行，并且以每年大约50亿行代码的速度在增长。”
这其中金融行业的占比有多少不得而知，不过10%总有的吧？为什么这么古老并且是商也的语言构建的系统，都没有人去动它，没有把这些这些系统改成c语言的实现？ 再想想，我们的目的是解决问题。而现在的核心系统已经很好的解决了这个问题，你又没有更好的方式解决它，为什么要换？ 至于楼主说的可行性，俺觉得可以。但性能、安全性，俺没那个能力保证。 |
| 返回顶楼 | |
|
发表时间：2009-08-11
愿意结交做过核心系统的朋友，共同交流！
|
| 返回顶楼 | |
|
发表时间：2009-09-19
做银行核心业务，必须要有核心。国内做银行系统的公司，都是没有真正自己设计和开发的核心。基本都是引进国外的。我们必须承认，这一点国外的东西的确是要先进。
|
| 返回顶楼 | |
|
发表时间：2009-10-13
liqiqi 写道 做银行核心业务，必须要有核心。国内做银行系统的公司，都是没有真正自己设计和开发的核心。基本都是引进国外的。我们必须承认，这一点国外的东西的确是要先进。
这个绝对不是先进~这叫成熟稳重…… |
| 返回顶楼 | |
