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

wangjia

现在有很多的保险公司开始要求使用J2EE架构的保险核心业务系统，但是J2EE架构的业务系统目前在国内并没有成功的案例，放眼世界也是很少的，而且我们不能忽视一点，那就是我们的国情，保单量非常巨大，因此保险核心系统的效率不能忽视。不知道，这些保险公司是出于什么样的考虑一定要J2EE，老实说，除了平台无关这个特性以及由之衍生的一些好处之外，我看不到什么好的地方。
大家可以讨论讨论。
2. 海归派与某些IT公司的怂恿
3. 其实目前号称会j2ee的公司和程序员更多,传统的技术会的人反而快成恐龙了
4. 性能不是问题,总能想到办法,而且性能本来就是j2ee的吹嘘点
在系统问题上不要贪大求洋，搞得好像离了J2EE不行。另外，也不要主动再去写Legacy系统，懂COBOL的员工不好找。
另外，我也赞同用了Tuxedo不要轻易换，首先Tuxedo效率挺高，另外，要保证业务系统的稳定。我估计BEA公司会长期支持Tuxedo
BlackOwlet，佩服您对技术和行业的理解深度！您的分析让我看准了方向。我希望甲方们能看到你的观点！
各位也许对所谓 j2ee核心业务系统 字面上的表述有误解,j2ee从来就没有打算替换TUXEDO、CICS或者其它什么产品，因为它只是一个架构，不是产品。之所以误解，完全是因为被一些
媒体文章和一些本身对j2ee没有深刻了解的人误导了,把j2ee说成一个形而上学的东西。
    举个简单的例子,大家也许会明白为什么要用j2ee。查询帐户余额，有几种方式：银行柜台、ATM、自助终端、网银、手机短信、WAP、电话银行等等。怎么实现不同方式（渠道）
下的帐户余额查询的呢？
    开发一个集中交易处理平台，将不同方式（渠道）下的余额查询都通过该平台发送给交
易中间件(cics或tuxedo)，再由交易中间件发送给后端业务逻辑处理模块，后端处理完后，将结
果返回给集中交易处理平台，再由集中交易处理平台将结果返回给各渠道。
    j2ee就是这个集中交易处理平台的解决方案。这样做的好处是：
    1、可以集中管理、监控、调度
      通过集中交易处理平台的“服务渠道”，接受不同渠道（即银行柜台、ATM、自助终
端、网银、手机短信、WAP、电话银行等）的访问请求，不同的“服务渠道”有不同的“服务
内容”，例如手机渠道只有“查询”类服务，没有存取款转帐服务。必要是可以增减“服务内
容”，或根据“服务渠道”和“服务内容”的访问量，调整参数，实现监控。

      类似的，集中交易处理平台的“服务网关”，会将请求发送到后端不同的业务处理系
统（如存贷款业务、信用卡业务、中间业务等等），网关的管理监控类似“服务渠道”。
    2、保护现有投资
      前端渠道和后端业务逻辑处理系统只需和集中交易处理平台约定好接口规范，银行现
有系统中大部分系统仍利用传统的连接方式，因此保护了客户的投资
    3、易于新业务的开发扩展，尤其是越来越多的中间业务
    当然，j2ee不是唯一的方案，但可以说是最好的方案，关键取决于你对业务的理解，对j2ee
的理解和实际运用水平