浅谈J2EE是否适合做核心业务系统

J2EE包含了四部分：Web客户端（Applet），Ｗeb服务端（JSP+Serverlet），AP客户端（JAVA APPLICATION），AP服务端（EJB），全面覆盖了计算机系统的各个层次。
在目前JAVA应用越来越广泛的今天，任何一家公司的核心业务系统，多多少少都会有JAVA实现的模块的，尤其是现在趋向于柜面多样化（高低柜），管理和核心一体化的形势下，B/S模式在核心业务系统的应用更是越来越普及。因此说国内公司的核心业务系统没有使用J2EE技术，那是不准确的。我想，比较准确的提法应该是：是否有公司以纯JAVA环境实现核心业务系统？答案肯定是有，而且在国内就有，相信国外也会有那么几家“有创造性”的公司会做这种事情。不过，可以负责任的说，不管是国内还是国外，都没有听说过有成功案例的。国内某家公司02年就实现过，但系统性能低，可靠性差，客户有苦难言，不到两年就换掉，这公司自已也不再推这版本了。
前面有些人一口咬定在外国已经有公司用J2EE实现，其实，那也是一知半解。参考IBM提供的国外成功案例，就明白他们其实只是用J2EE做了表示层。到过国外的朋友们都知道，在国外的银行，不象国内银行有个牢房似的营业厅，基本都类似于国内针对大客户的低柜业务柜台，因此外国银行柜台使用B/S界面的比例远大于文本终端，这使用J2EE实现表示层是很合适的。真正看过国外CORE　BANKING产品（尤其是世界上前几名产品）的人，应该都知道，其核心服务层大部分都是用COBOL写的，J2EE界面通过CICS或者MQ调用。J2EE只是实现了核心业务系统的“皮肤”。外国公司比国内公司更懂得“积累”，不要说用JAVA代替Ｃ，甚至70年代写的COBOL代码，也不会用Ｃ来重写它，一直能用到现在。看外国的产品，不同的系统模块，会有不同的运行和开发环境，COBOL，C/C++，JAVA甚至.net都有，主要就是看这个模块是什么年代开发的了。但总体上，通过良好的数据库结构设计，它们都能将这些五花八门的功能模块整合起来。不仅核心业务系统是这样，其实小到国际结算这种专业的部门级系统，也是这种情况。我个人看法，在外国公司眼中，对银行核心业务系统来说，用什么语言开发不重要，重要的是，成熟和稳定，能以最少的开发成本赚最多的钱，也就是说：软件公司的成本效益才是最重要！！！
我想单纯从技术角度谈谈纯J2EE实现的可行性。
1、首先，从投入产出角度看，用J2EE重写C/C++已经实现的代码，如果系统功能和性能没有质的革命，只是为了某些开发人员的喜好而换种语言，那么这种工作是百害而无一利。
2、其次，从JAVA运行环境的设计原理来看，它也不很适实现对性能、可靠性和稳定性要求很高的核心业务关键模块。JAVA设计的原意，是降低程序员的开发难度，将内存管理和对象生命周期管理的事情都由运行环境包揽了，这无疑提高了程序员的开发效率，降低了JAVA程序员的技术门槛；而C/C++需要程序员自已管理内存，需要程序员有丰富的系统底层知识和开发经验，提高了技术门槛，从软件公司的角度，JAVA肯定是受欢迎的。但偏偏从系统运行管理的角度来看，内存是影响系统性能和稳定性的最重要因素，JAVA的垃圾回收机制对内存使用的效率，远远比不上C++程序员自已的内存管理来得有效和稳定。举个例讲，即使在满负荷的情况下，Ｃ服务程序占用内存，一般几Ｍ最多几十Ｍ就到顶了，整个操作系统的内存仍然是充足的，系统稳定性仍然很好，可以一年365天，一天24小时不集停业务；而JAVA虚拟机一般在并发用户达到200左右，虚拟内存就长到最大值，其后就频频周而复始地申请－回收，直到回收不了而冻结请求，一旦冻结就会停止业务5分钟以上，这种情况在银行管理系统上，平均每一到两个月总会出现一次。管理系统是内部系统，偶尔出现一次不要紧，核心业务系统是对外的，一旦出现对外停业，客户在银行窗口排长队的情况，客户不骂娘，科技部领导不下台，那才叫奇怪了，这种风险，试想谁愿意承担呢？
3、J2EE的并发控制模式和负载均衡技术，也确实与专业交易中间件的差距较大，合适做WEB网站，不合适做OLTP服务器，具体技术差异我就不说了。我只是举个性能差异就说明问题：在某台P570（4C 16G）小型机上，在单用户下，实现同样功能，SERVLET+JAVA BEAN（模式一）花的时间，与SERVLET＋中间件＋Ｃ应用服务的模式（模式二）相比，差距不能40%，但并发越过100用户时，前后者差距达到了一个数量级，并发达到150时，模式一开始上不去了，JVM开始“freezen"，而后者一直上到并发数500，系统依然稳定。而且从资源利用率看，模式二的CPU占用低，内存占用稳定，数据库连接数随着并发数增长，模式一的内存占用增长快，CPU占用高，数据库连接数稳定在10个左右；从吞吐量看，模式二在不同并发数下保持稳定，二模式一则随着并发数上升而下降；究其原因，是因为J2EE的并发控制模式是每个请求并发一个线程来处理，导致内存竞争严重，数据库连接申请量多，导致数据库压力增加，操作系统内存使用不稳定，从而使性能在大并发的情况下，急剧下降。
J2EE和C/C++，应该讲各有优势，经过2年多的银行系统开发，我个人认为，最好的模式不是谁替代谁，而是互相整合。我感觉最好的模式是SOA模式：
1、界面多样化，文本终端上用Ｃ，B/S上JSP+SERVLET或FLEX
2、控制层用EAI平台，JAVA或者C都可以；
3、应用服务层使用专业中间件+C或者COLBOL应用服务；