J2EE架构的银行核心业务系统

3、效率风险
任何一种架构实际都是有一定的适用范围。
2层的C/S架构适用的小型企业应用，因为有很多开发工具支持，开发周期快，即使有变化，重新开发的成本不会太大。
N层C/S架构（采用IBM-CICS,BEA-TUXEDO中间件），该架构已经把业务逻辑设计成一个一个独立的可供调用的SERVICES，增加或修改业务逻辑只是增加SERVICES或修改已有的SERVICES，客户端只作界面处理。这样的架构使得业务逻辑的变更极为方便，而这正是银行保险这样的应用更为关心的。这样的架构是专为OLTP应用设计的。

J2EE架构也可把业务逻辑后移，设计成SAERVICES，也可按连接池方式与数据库连接，从而减少DBMS的系统开销，但J2EE架构在应用服务的平衡负载方面与N层C/S架构比还是比较低级，特别是对于大型应用（如国内较大的保险公司，如果全国大集中，保单数都会在上千万，甚至上亿），对于这种规模的应用，不但服务端要构建集群架构，数据库可能也要构建集群架构（即构建多个同构的数据库（同表名，同库名，但存放在不同的数据库服务器中），数据按某种分片规则存放在不同的数据库中）。这种要求J2EE架构是很难支持的，至少目前这样。

合理的解决方案：
1、大型应用核心业务的架构要采用N层的C/S架构
支持大交易量大数据量的要求。
2、客户端可采用WIN终端方式
WIN终端的界面与WINDOWS的窗口界面风格相同，也可在WIN终端上运行浏览器，即如果是B/S结构也能支持。WIN终端方式客户端的程序是安装在WIN终端服务器上的，这样与纯C/S结构比，客户端维护也大为简单了，如果开发客户端程序的自动发布与安装程序，则一样可做到“0”维护。
3、客户端的浏览器化
如果确实需要，客户端也可设计成浏览器风格，但对于业务逻辑是调用TUXEDO或CICS服务，而不是调用J2EE服务，这样可充分利用或重用核心业务系统已有的处理逻辑（这也是保证系统稳定的重要手段），也即核心架构不动，但前端的展现架构可跟上潮流。

国外的大型应用系统的发展正是这样的，在美国还有很多银行或保险公司其核心系统还是用COBOL语言写的，还是用的VSAM文件系统，但在客户端，包括互联网上的电子商务可能比国内的同行做得更好，其基本思路就是保留原有的核心系统架构（原系统一般称为LEGACY系统），在外围则可引入新的技术手段。

拿亚马逊公司来说，该公司是互联网时代发展出来的新型公司，但其电子商务的网上交易处理则仍然采用的是TUXEDO这样的中间件就可看出，J2EE不该作为这个时代软件架构的“万金油”。

系统架构的设计更应着重于库表结构的设计及业务逻辑的SERVICES化，而是用TUXEDO, CICS的SERVICES还是用J2EE的SERVICES来实现则要视具体情况而言，即应用越大，或已有TUXEDO/CICS SERVICES，则不能轻言改变，如果应用规模不大，或者确实是新应用，则可尝试采用全新的架构。即架构是否要改变应是由应用决定的而不是由技术决定的。

另一个问题也是要注意的，一个新的技术从提出到实用是需要时间的。关系数据库理论是1970年提出的，关系数据库产品是到1980年代中出现的，但真正把关系数据库应用于大型应用系统的开发则是在1990年代的事了，成熟的时间是20年。小型应用多采用新技术，一是风险小，二是能加速技术的成熟（如果没有实际应用，新技术也是很难成熟的，因此小型应用的尝试也可看作是必要的贡献），而大型应用则应保守些，因为试验的风险太大，这方面用户方更需要头脑清新，但中国人赶时髦的热情一直是很高的，并且总是喜欢革命也而是改良，但这种习惯在大型应用系统