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