我的大学: （转）J2EE架构的银行核心业务系统?

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

放眼看世界银行与保险公司的核心业务系统，真正用J2EE架构的确实很少，但作为IT公司与用户却都叫得要往J2EE架构转，这里的原因有几个：
1、IT公司必须炒作新概念，才能获得新利润
目前各银行与保险公司都有自己的核心业务系统，一般而言一个系统使用时间越长，系统会越稳定（使用过程实际是一个不断的排除BUG与系统优化的过程），但随着业务的发展，系统还是要有所发展的，如新增业务功能的处理，新增服务渠道等，一个好的架构，这些扩展都可在原有架构上有序的扩展，当然有的系统基础架构不好，或由于开发过程中的“大跃进”，使得每一次系统升级都要打快速补丁，最终导致破坏了原有良好的系统架构。
系统升级过程中破坏了原来较好的架构，这是如何做好软件工程的问题，与是否采用J2EE无关，而且在国内导致这个问题更重要的原因是用户方在软件方面的投入不足，要求的开发周期严重不合理，而打补丁的方法是最快最省市的方法，很少考虑该补丁对系统结构长远是否有不利的影响，结果是系统在几年后不得不作一次大规模的修改，否则原有系统已经无法打上新的补丁了。这种系统的维护升级方式实际上更花钱，而且风险更大，但用户似乎更能接受，如果采用平稳的升级方法，每次要投入较多的资金与时间，但风险小，长远来说更省钱，但国内用户很难接受这种理念，老觉得IT公司是要让用户付出更多的费用。实际上这样的开发方式IT公司更喜欢，因为每过几年可能会拿到一个较大的单子，但由于新的单子也不一定就落到原来开发公司的口袋里，而每次重新招标都会增加很高的市场成本，因此各公司会把更多的精力放在如何维护与客户的关系上，而对现有产品增加投入则没有动力。这就是国内软件业的现状，并且已经进入恶性循环，到一天国内的软件公司撑不下去了，则用户可能面临着不得不选国内的产品，但价格则可能是国内产品的几十倍或上百倍。当然国外的产品会在某些方面好于国内的产品，但如果国内的软件公司能取得合理的利润进入良性发展，也是可以把自己的产品做得更好的。
正因为在上述大环境下，IT公司当然更愿意鼓吹一切新的技术，而不论该技术是否成熟，也不论该技术是否适合用户的实际需要，因为只有鼓吹新技术才会使系统不断地重新开发，这样才会把市场的总盘子做大，也只有这样，大家才会有钱赚（因为在国内挣不到维护费，版权费，只有不断变才会有开发费赚）。但变的风险，开发商是不关心的。

2、用户希望简化客户端的维护
C/S结构，客户端程序的升级安装总是比较麻烦，再加上可能的病毒破坏，客户端操作人员的误删程序等都可能导致不能正常使用系统。用户方的IT技术人员都希望能捞到一种办法，使客户端象原来的笨终端一样，加电就能用，这样就省事很多。这样基于J2EE架构的B/S结构就很有吸引力。
用户的想法并不错，但简化客户端的维护，不一定只有采用J2EE架构一条路，而用户以为只有J2EE才是唯一的途径正是IT公司长期“教育”的结果。
用户方的IT人员，特别是CIO们缺乏战略眼光，即使采用传统的C/S结构，使客户端的升级维护可能会麻烦一些，但这只是战术方面的投入，而由于系统架构长期处于不稳定，特定是在升级过程中如何保证数据迁移不会导致数据“失真”（由于改变架构往往会换一家公司开发，而新的开发商对原有系统的数据库表结构不能完全了解，最省事的办法也是不负责任的办法，就是库结构一起改，然后进行数据迁移）这些战略方面的风险则很少关心。

架构变更的风险究竟有哪些呢？我们可作简单的归纳：
1、数据风险
在上述讨论中已经提及。
2、系统稳定性
除非是已经很成熟的应用了软件产品，否则任何一个开发的应用系统都要经过2—3年才能逐步稳定。而国内用户很少同意购买一个产品，再根据产品的要求来对自己的业务流程进行重组，这样实际上就没有真正意义上的软件产品，即使有一个产品的基本版本，在任何一个用户单位都要经过大量的修改或客户化才能适应用户要求，结果就是系统的稳定性被破坏，趋于稳定的周期加长。
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年。小型应用多采用新技术，一是风险小，二是能加速技术的成熟（如果没有实际应用，新技术也是很难成熟的，因此小型应用的尝试也可看作是必要的贡献），而大型应用则应保守些，因为试验的风险太大，这方面用户方更需要头脑清新，但中国人赶时髦的热情一直是很高的，并且总是喜欢革命也而是改良，但这种习惯在大型应用系统的规划方面实在是要不得。

最后希望在推广一种新技术时，IT公司要厚道一些，用户方要理智一些。另外也希望用户方在规划IT投入方面，在软件投入上的比例要更合理一些，特别是要加大对于服务维护的投入，如果软件公司挣到了该挣的钱，则软件公司会更注重提升产品本身的功能与性能，而不会（至少会少些）变着法子让用户不断换系统了。所谓买的没有卖的精，由于用户方的问题，逼得开方商另想生财之道也是没有办法的办法，但最终损失的是用户，是中国的软件产业。