J2EE架构的核心业务系统？ - 第2页 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

也许我没有说清楚，我并不反对J2EE架构，对于中小系统完全可基于J2EE架构，对于已经有LEGACY系统的，同可在此之上加上J2EE层支持新的接入渠道，对于大型系统则可在基于OLTP中间件的核心系统外加上J2EE的中间平台。
一般而言，核心系统只有在效率有问题或业务处理逻辑要增加才能修改，而不要由于要增加不同的客户端接入而随便修改，后一种要求恰恰可通过在J2EE层来解决。
还有一个问题也是银行、保险公司都会遇到的，这些企业往往同时有多个系统在运行，甚至这些系统不是一家开发的，除非这些系统本身有一个比较好的可以互联的基础平台，否则在系统整合时是很困难的，而采用J2EE也是一种比较好的整合方案，即在中间层整合而不动原来各自的应用系统。
看了所有楼上的帖子，也想说几句：
第一、j2ee在交易系统中的主要问题： 1、交易速度的要求。2、交易量的需求。
第二、现在很多银行的系统中，引入了‘综合交易处理平台’的一个产品，他的主要功能就是类似于applicaition server。但是他支持的协议主要是OLTP中间件。在这个系统架构上就是c/s/s的系统。他在平台层封装了所有的通讯。我想这是j2ee的oltp版。
不管it集成商怎么吹嘘，重新利用legacy系统或者成功移植该系统，都是非常复杂和风险的事情。对于银行来说，我觉得柜台交易和其他渠道的交易分开来考虑未必不是一个好的选择。
可参考IBM的WBSCC:
900.cn.ibm.com/cn/industry/finance/solution/finance_solutions_2_detail.shtml
还有国内南天、高伟达、新宇的方案,都是针对银行的
谁能提供j2ee在保险公司的方案
IBM的那个是不是叫WSBCC啊？ 如果是那个，我就要告诉你，效率肯定不能处理大交易量，而且发展前景不明。那个是针对网上商务开发的，没打算成为核心系统用的软件。
中小银行的核心银行系统是可以考虑J2EE的，但我认为多考虑SOA更有用些，基于SOA的混合技术系统（java+legacy)应该适用性会更强
我很想知道楼上说“WSBCC效率肯定不能处理大交易量”的依据是什么，如此肯定，是否有压力测试报告或失败案例，拿出来给大家瞧瞧。
WSBCC也好，南天高伟达的银行j2ee方案也好，都不处理“业务逻辑”，只负责输入数据收集验证打包加密发送解包解密接收输出，以及渠道、网关、硬件的管理监控，还有一个重要功能是“交易定制”，就是定制上面哪些功能和交易输入输出画面及参数。对银行来说，并不需要照搬全套方案。
其实国内系统集成商提供的j2ee方案大多参考IBM的WSBCC，或直接用WSBCC。高伟达、南天、新宇等公司里面的人彼此都认识，或者都是从一个公司里出来的，所以做出来的东西都差不多，呵呵呵
SOA我觉得也是一回事，改socket监听为http+xml，更时髦一些，不过效率肯定更差一些
[B]可参考IBM的WBSCC:
900.cn.ibm.com/cn/industry/finance/solution/finance_solutions_2_detail.shtml
还有国内南天、高伟达、新宇的方案,都是针对银行的
谁能提供j2ee在保险公司的方案 [/B]
易保用的是J2EE。
J2EE进入银行核心业务的后台也是迟早的事，为什么这么说呢？从这两年公司招聘技术人员的情况来分析，熟悉或者了解Java以及J2EE框架的人员比较好招，而招对Unix C/C++等这些传统的开发工具的人员就相对少了很多。因此，使用J2EE，向这种架构去转型，对IT公司来说，也降低了人力成本，物以稀为贵。同时，如果统一到一种平台，也降低了技术管理的难度。市场现状如此，也促进了种架构的进一步发展，处理速度，并发性等等，迟早会得到解决。因此，一个IT公司不能不去跟这种潮流，何况用户对IT架构没那么敏感，最终还得看IT的选择。