电信系统架构方案
国内软件业曾有人对行业性软件进行划分，在几个较大的行业中，排行前几位的分别是：通信、电力、金融……
但从对技术的要求与和安全性的要求上来说，通信行业的计费和金融行业的交易都是并称的。因此在通信行业软件形成之初，计费就成为了通信行业的核心软件，能否有实力作计费软件成为在行业中是否具有实力的标志。于是也就形成了中国通信行业著名的“九七”工程！这是完成电信行业核心业务层面的信息化工程。
继“九七”工程之后，2001年，中国的各电信公司根据国外电信公司的信息化进程和经验，总结提出要建立中国电信公司的运营支撑系统，这个系统是基于“九七”工程外围的运营支撑业务构建起来的，如果说“九七”工程是心脏，那么运营支撑系统就是四肢！心脏是为了提供肌体的动力，四肢才可以通过各种形式来获取利益，使心脏能继续生存下去。运营支撑系统在中国电信集团公司被称为“OSS”系统，全称是“Operation Support System”，在中国移动通信集团称为“BOSS”系统，全称是“Business and Operation Support System”。
在电信集团提出构建运营支撑系统的同时，各电信分公司还在筹划构建符合自己特点的ERP系统，与此同时，基于运营支撑系统之外的各种行业业务系统也开始了开发与规划。
电信行业软件历程
一、九七工程
九七工程是中国通信行业软件最初的形象。实际上在实施九七工程的时候，中国的通信行业基本上还是一家垄断的状态，那就是中国电信！
九七工程主要解决了电信行业最迫切需要解决的交换、计费、帐务、经营等最关键的业务过程。这些业务要求实时性非常强、对准确性的要求也非常高，因为系统的每一个数据都关系到电信的直接收入。
一些国内的软件公司借着这股春风发展了起来，也有一些公司从此开始涉足软件行业。
从技术和行业的应用成熟度来说，当时进行这项工程的条件是不具备的，但是，这项工程的实施却是必须的。所以，在实施这个工程的过程中，不少系统都是多次返工，虽然达不到实际意义上的7×24，但是至少可以得到比其他方式更精确的数据信息，这也就是这项工程的一大意义了。因此，在此后，尽管1997 年早成为过去，但是九七工程这个名词却一直被沿用下来，以代表这个特殊的意义——中国电信行业的第一次信息化。
二、OSS/BOSS系统
2001年，中国移动开始规划“BOSS”系统，2002年各省移动公司分别制定了自己的“BOSS”系统的技术规范和业务规范，但是，离真正实施还有一段时间，因为中国移动还需要进行统一的规划。
在中国移动制定规范的同时，中国电信集团也不甘落后，也开始制定自己的“OSS”系统的规范和实施规划，并在其上海研究院进行相关的试验。不过，因为其工作量过大，按照初步的估计，一个省级电信公司要实现“OSS”系统的规划，至少需要五年，投入至少有3到5亿以上的资金。按照这样的估算，中国电信集团要实现全国的“OSS”规划至少就需要90亿以上的资金投入，所以，一直到现在，中国电信集团的“OSS”系统还仍然无法进入实施阶段。
其他的电信运营商，诸如中国联通、中国网通、中国铁通等公司也都在纷纷筹划自己的相关系统。
技术方案概述
一、B/S结构
随着软件技术和网络的发展，各种行业软件业几乎都在进行着B/S与C/S结构的争论和演化。虽然大家都认为B/S结构更先进一些，但是，在某些特定的行业和业务中，C/S结构的系统仍然有着非常重要的地位和不可替代的作用。
加上B/S结构产品的开发难度要远大于C/S结构的系统，调试和测试工作都要比C/S结构的产品复杂得多。在此条件下，基于成本和效益的各种方案对此有很大的影响。
经过长时间的研究和探讨，通信行业的产品在体系结构上基本达成一致：在业务操作实现领域采用B/S结构，在某些特殊的功能实现上适当地采用C/S结构。
二、多层结构选择的必然
提到体系架构的选择，电信行业的大多数业务对系统的实时性、稳定性要求都非常高，因此电信行业软件业就成了所有软件中开发难度最大的一种。
目前国际上流行的两种软件体系，都采用了多层体系来进行大中型系统和关键系统的构架。
电信行业项目的实施中，也大都采用了中间件进行整个体系的构架，在J2EE体系成型之前，大多数系统都采用C/C++进行开发，一些关键的业务实现则采用 Corba体系。随着Corba与J2EE的融合，两大对立阵营的.Net与J2EE逐渐成型，电信领域的大型系统大部分都采用了基于Java的多层体系架构。如图2所示：
Web服务器：在Web服务器上，部署的是系统的表现层，用户通过浏览器进行浏览和信息交换。
应用服务器：主要提供组件的生存支撑环境，提供业务逻辑搭建的基础。
三、体系架构的选择
目前流行的两大体系是.Net和J2EE。
由于微软的产品大都稳定性、可靠性较差，虽然上手非常容易，但这恰恰不能达到电信行业对于可靠性的基本要求，所以，从体系到产品，微软都被全部屏蔽于行业重点业务的实现之外。
J2EE体系得到了较多大型厂商的支持，同时融合了Corba对语言无关性的特征（虽然其真正的可用还需要一段时间）以及其他优势，目前已经得到了绝大多数电信公司的认可，在通信行业领域内的开发商和集成商也都纷纷附和。
四、语言的选择
对于语言的选择，新的电信行业软件做了非常慎重的考虑，既要保证效率和实时性，还要能提供足够强大的稳定性，在J2EE推出之前，包括国外的电信行业项目也大都采用C/C++开发，但是，因为C++本身所固有的问题——内存泄漏，所以，系统的稳定性总是很难得到保障。
Java出现后，由于Java自身对C++的补充，稳定性方面得到了极大的提高。但，同时也发生了一个问题：因为Java需要运行在Java虚拟机上，经过这样一次解析后，其运行效率和速度都受到了很大的影响，当进行大数据量查询和统计分析的时候，Java的速度问题就很明显了。因此，在一些特殊的功能实现方面，又需要使用C/C++来进行速度的提升。
五、最终决定
通过上面的描述，我们已经基本上把电信行业软件开发的体系架构表述清楚了。图3是笔者早先完成的一个基于J2EE架构的产品开发技术框架，仅供参考：
1 J2EE实现整体设计原则与思想
该系统的设计，采用了组件化的设计思想，同时根据项目的特点，对J2EE的实现架构进行了适当的改进，使之能更适应电信目前的要求和今后扩展的需要。
系统采用J2EE体系架构进行整体结构设计，这也是国际上流行的解决大型企业应用及关键性业务应用的优秀技术。
2 功能设计
通过J2EE技术框架实现电信行业系统的所有功能。
3 体系结构
该系统必须采用多层体系结构。建议采用如图3所示的六层体系进行架构。
4 构架特点
下面按照数据库层、数据管理层、事务处理层、会话处理层、逻辑控制层、前端表现层的顺序对以上各层功能和特点进行详细的描述：
（1）数据库层
选用某种数据库，提供数据存储服务，同时，还需要提供灾难备份和恢复功能。所以，目前，电信行业内部对数据库的基本要求如下：
①支持ANSI/ISO SQL-89、ANSI/ISO SQL-92标准；
②支持中文汉字内码，符合双字节编码；
③支持主流厂商的硬件平台及操作系统平台；
④数据库系统应具有良好的伸缩性；
⑤支持主流的网络协议（如：TCP/IP、IPX/SPX、NETBIOS及混合协议）；
⑥具有良好的开放性，支持异种数据库的互访：
实现对文件数据和桌面数据库数据的访问；
实现对大型异种数据库的访问；
能够将原有异种数据库向本数据库无损失移植；
实现和高级语言互联的能力；
支持XA、ODBC 3.0、X/OpenCLI、JDBC等工业标准；
支持分布式事务及两阶段提交功能。
⑦具有支持并行操作所需的技术（如多服务器协同技术、事务处理的完整性控制技术等）；
⑧支持网络上同构或异构数据库之间数据的冗余性复制；具有多种复制功能模块（如实时复制、定时复制、双向复制、多点方式下的N向复制、复制转发，复制范围可整表复制或表中部分行复制或修改单元复制）；
⑨支持联机事务处理（OLTP），支持决策支持的建立，要求能够实现数据的快速装载、高效的并发处理和交互式查询；
⑩支持C2或以上级安全标准、多级安全控制；
支持数据库存储加密及相应冗余控制；
提供Web服务接口模块，对客户端输出协议支持HTTP2.0、SSL等；
支持联机存储和备份功能（如磁带方式、光盘方式）；
应具有强的容错能力、错误恢复能力、错误记录及预警能力；
数据库、表大小等技术参数可灵活设置，支持对多媒体数据及大数据量处理的技术需求；
应可以避免数据库死锁的出现，一旦死锁能够自动解锁；
开发工具易使用、开发效率高、维护方便；
支持多种CASE工具。
上面对数据库的各个方面都提出了要求，在电信行业内部，目前对于中小型非关键业务项目采用MS SQL Server 2000的比较多，大型项目基本上都避开微软的体系和产品，而采用Oracle和DB2作为系统的数据库选择。
（2）数据管理层
这是整个系统中唯一进行数据访问、数据控制和数据安全校验的部分，是系统中唯一与数据库交互的部分，这也从另一个层面提高了数据安全性。
另外，由于有些电信行业系统的分布地域比较广，采用这种方式有利于分布式数据的有效管理，可提高数据的利用率和有效性。
优点：专用的数据管理层屏蔽了系统的其他部分对系统数据库的直接访问，增加了系统数据的隐蔽性，提高安全性和可管理性。
具体实现的时候，可尽量采用应用服务器所提供的功能，采用容器管理实体Bean（也就是CMP Entity Bean）来开发数据管理层，这样可以降低开发人员的开发工作量，提高效率，提高组件的可重用性。而且，当数据库发生变化的时候，不需要做大量的编码，通过应用服务器本身就可以直接对这种变化做出相应的反应。
注：对于CMP和BMP的使用的基本观点是这样：对于完全新建的系统，也就是说没有老系统的存在，或者可以忽略老系统的数据库设计方式可能对新系统的数据库设计造成的影响的时候，建议采用CMP的方式来开发Entity Bean，这样就可以完全采用OO的方式从需求开始到分析设计和编码实现都依托于OO的思想进行整体的规划，系统实现也会相对比较合理。而对于不符合上述情况的系统，一般在前端流程实现和业务逻辑实现中可以考虑采用OO的过程，在数据库管理层的实现中需要考虑与前端的配合外，数据库管理层的设计和数据库层的设计建议采用面向数据的过程进行规划，否则，不仅仅用户可能会对工期不满，开发团队也将面临着数据抽取与转换的难题。
（3）事务处理层
系统中进行事务处理的主要部分。这部分将根据具体的业务逻辑和实现进行业务控制和事务处理。在业务进行变化的时候，不影响系统的其他部分。
由于有些规则和制度会因为时间和各种情况有一定的变化，因此很多业务的具体处理流程和过程都需要修改，这样的修改如果放在其他部分，就有可能影响到很多其他业务的正常开展。
优点：经过仔细考虑后，笔者认为：针对所有具体的业务增加专用的事务处理层，进行专项业务的处理和控制。提高系统整体的可重用性，降低系统各部分之间的耦合度。
通过这种方式，可以随时随地地增加一项业务，减少一个环节，都不会对其他部分造成大影响，除非这项业务有一些固有的特殊的页面展示要求，否则都可以方便的达到上面的功能。
例如：在业务重组和旧制度废除、新制度发布的时候，可以先按照新制度定制好流程组件，在新制度发布生效的时候，将旧组件卸下，新组件安装即可。在现有的应用服务器上使用时，甚至服务都不需要中断，对于一个业务的更新，仅仅需要一两秒钟的时间就可以完成。
缺点：一定程度上，这对效率有所影响，但相对于Internet网络状况对系统性能的影响来看，这种架构模式对整个系统性能的影响仍然是很小的。
笔者建议：
①如果遇到大数据量查询时，建议越过这种架构模式，直接通过安全的SQL连接方式从数据库中尽快获取信息。
②对于大型的电子商务系统也可以借鉴这种体系架构，但对于仅仅在局域网内工作的系统，就可以对本架构进行简化，因为局域网内的安全性相对较高，所以，可以考虑简化以提高系统性能和运行效率。
（4）会话处理层
会话层，处理与前端展现的会话信息，提供交互的第一个处理界面，处理简单、稳定的事务。不处理复杂的事务和变化较频繁的事务。
优点：提供对前端发送过来的请求和各种数据信息的处理，当前端展现发生变化的时候，不会影响到后台的服务组件代码。
提供对简单事务的处理，这些事务一般是通用型的、基本上不发生变化的事务流程。如电信行业的批复流程、审核流程等等。
（5）逻辑控制层
系统进行控制的部分。这部分将提供系统整体的控制，处理各个部分之间的关系，启动各层间的操作和运行。同时它可以屏蔽前后两层（前端表现层和会话处理层）之间的联系，降低系统的耦合度。
优点：这是MVC中的控制层，在采用J2EE进行系统架构设计时，IBM非常推崇这种模式。在本系统的架构考虑中也认为采用这种模式是相当合适的，但同时考虑到这个系统的实际情况，本文对这种模式作了扩展，将模型层分成两个部分，也就是数据管理层和事务处理层，具体原因已经在这两个部分作了解释。
这种模式是把控制权和所有权进行分离，当具体业务和会话表现等部分发生变化的时候，开发人员不需要修改控制层的代码，使得整个系统中各个部分的权责更加明确，降低了维护的工作量。
（6）前端表现层
系统中提供数据展现的部分，属于整个系统的UI。这也是用户对整个系统最直接接触的部分。将提供报表展现、报表定制和录入、数据输入和输出、信息浏览发布等等……
优点：这是一个完全独立的表现层，如果设计的比较好，就可以做到：其样式、风格都可以由美工进行直接的修改和设计。这些设计不会影响到任何后台的事务，因此，甚至可以做到随时更换风格。
5 性能实现
（1） 安全性
关于安全性的描述，请参见系统和数据安全管理中的描述。
（2）可靠性
系统的可靠性将在具体的项目开发过程中体现出来。因为每一项业务的添加与减少都对系统整体的稳定性产生一定的影响。开发过程中，只要对设计进行严格的检验和测试就可以保证整个系统的可靠性。
（3）灵活性和扩展性
按照目前所规划的技术架构，开发者可以随时在上面进行各个功能层的组合和分离，也可以将各个功能层分布在各个不同的服务器上共同提供服务，因此整个系统无论是在物理结构上还是在逻辑结构上都具有很高的灵活性和扩展性。
对于业务组件，开发者/使用者可以对其进行业务分割和重组，以提高组件的利用率，对于今后其他系统的开发也具有技术积累的意义。
同时，这些业务组件可以根据业务状况的变化进行更新和替换。比如说：某一项新的制度发布生效前，开发者可以提前按照新的制度开发好完整的业务组件，在生效的那个时间点，将老组件取下，新组件安装到服务器上。这样也就不会因为制度的变化影响到各个业务或者办公流程的顺利开展。
（4）实用性
系统的技术架构是专门针对项目的一些特性对J2EE原有的体系架构进行修改和完善后设计出来的。它既可以应付复杂多变的业务流程，对于一般十分稳定的业务流程也不会出现多余的问题，且具有相当好的扩展性和灵活性。
但从对技术的要求与和安全性的要求上来说，通信行业的计费和金融行业的交易都是并称的。因此在通信行业软件形成之初，计费就成为了通信行业的核心软件，能否有实力作计费软件成为在行业中是否具有实力的标志。于是也就形成了中国通信行业著名的“九七”工程！这是完成电信行业核心业务层面的信息化工程。
继“九七”工程之后，2001年，中国的各电信公司根据国外电信公司的信息化进程和经验，总结提出要建立中国电信公司的运营支撑系统，这个系统是基于“九七”工程外围的运营支撑业务构建起来的，如果说“九七”工程是心脏，那么运营支撑系统就是四肢！心脏是为了提供肌体的动力，四肢才可以通过各种形式来获取利益，使心脏能继续生存下去。运营支撑系统在中国电信集团公司被称为“OSS”系统，全称是“Operation Support System”，在中国移动通信集团称为“BOSS”系统，全称是“Business and Operation Support System”。
在电信集团提出构建运营支撑系统的同时，各电信分公司还在筹划构建符合自己特点的ERP系统，与此同时，基于运营支撑系统之外的各种行业业务系统也开始了开发与规划。
电信行业软件历程
一、九七工程
九七工程是中国通信行业软件最初的形象。实际上在实施九七工程的时候，中国的通信行业基本上还是一家垄断的状态，那就是中国电信！
九七工程主要解决了电信行业最迫切需要解决的交换、计费、帐务、经营等最关键的业务过程。这些业务要求实时性非常强、对准确性的要求也非常高，因为系统的每一个数据都关系到电信的直接收入。
一些国内的软件公司借着这股春风发展了起来，也有一些公司从此开始涉足软件行业。
从技术和行业的应用成熟度来说，当时进行这项工程的条件是不具备的，但是，这项工程的实施却是必须的。所以，在实施这个工程的过程中，不少系统都是多次返工，虽然达不到实际意义上的7×24，但是至少可以得到比其他方式更精确的数据信息，这也就是这项工程的一大意义了。因此，在此后，尽管1997 年早成为过去，但是九七工程这个名词却一直被沿用下来，以代表这个特殊的意义——中国电信行业的第一次信息化。
二、OSS/BOSS系统
2001年，中国移动开始规划“BOSS”系统，2002年各省移动公司分别制定了自己的“BOSS”系统的技术规范和业务规范，但是，离真正实施还有一段时间，因为中国移动还需要进行统一的规划。
在中国移动制定规范的同时，中国电信集团也不甘落后，也开始制定自己的“OSS”系统的规范和实施规划，并在其上海研究院进行相关的试验。不过，因为其工作量过大，按照初步的估计，一个省级电信公司要实现“OSS”系统的规划，至少需要五年，投入至少有3到5亿以上的资金。按照这样的估算，中国电信集团要实现全国的“OSS”规划至少就需要90亿以上的资金投入，所以，一直到现在，中国电信集团的“OSS”系统还仍然无法进入实施阶段。
其他的电信运营商，诸如中国联通、中国网通、中国铁通等公司也都在纷纷筹划自己的相关系统。
技术方案概述
一、B/S结构
随着软件技术和网络的发展，各种行业软件业几乎都在进行着B/S与C/S结构的争论和演化。虽然大家都认为B/S结构更先进一些，但是，在某些特定的行业和业务中，C/S结构的系统仍然有着非常重要的地位和不可替代的作用。
加上B/S结构产品的开发难度要远大于C/S结构的系统，调试和测试工作都要比C/S结构的产品复杂得多。在此条件下，基于成本和效益的各种方案对此有很大的影响。
经过长时间的研究和探讨，通信行业的产品在体系结构上基本达成一致：在业务操作实现领域采用B/S结构，在某些特殊的功能实现上适当地采用C/S结构。
二、多层结构选择的必然
提到体系架构的选择，电信行业的大多数业务对系统的实时性、稳定性要求都非常高，因此电信行业软件业就成了所有软件中开发难度最大的一种。
目前国际上流行的两种软件体系，都采用了多层体系来进行大中型系统和关键系统的构架。
电信行业项目的实施中，也大都采用了中间件进行整个体系的构架，在J2EE体系成型之前，大多数系统都采用C/C++进行开发，一些关键的业务实现则采用 Corba体系。随着Corba与J2EE的融合，两大对立阵营的.Net与J2EE逐渐成型，电信领域的大型系统大部分都采用了基于Java的多层体系架构。如图2所示：
Web服务器：在Web服务器上，部署的是系统的表现层，用户通过浏览器进行浏览和信息交换。
应用服务器：主要提供组件的生存支撑环境，提供业务逻辑搭建的基础。
三、体系架构的选择
目前流行的两大体系是.Net和J2EE。
由于微软的产品大都稳定性、可靠性较差，虽然上手非常容易，但这恰恰不能达到电信行业对于可靠性的基本要求，所以，从体系到产品，微软都被全部屏蔽于行业重点业务的实现之外。
J2EE体系得到了较多大型厂商的支持，同时融合了Corba对语言无关性的特征（虽然其真正的可用还需要一段时间）以及其他优势，目前已经得到了绝大多数电信公司的认可，在通信行业领域内的开发商和集成商也都纷纷附和。
四、语言的选择
对于语言的选择，新的电信行业软件做了非常慎重的考虑，既要保证效率和实时性，还要能提供足够强大的稳定性，在J2EE推出之前，包括国外的电信行业项目也大都采用C/C++开发，但是，因为C++本身所固有的问题——内存泄漏，所以，系统的稳定性总是很难得到保障。
Java出现后，由于Java自身对C++的补充，稳定性方面得到了极大的提高。但，同时也发生了一个问题：因为Java需要运行在Java虚拟机上，经过这样一次解析后，其运行效率和速度都受到了很大的影响，当进行大数据量查询和统计分析的时候，Java的速度问题就很明显了。因此，在一些特殊的功能实现方面，又需要使用C/C++来进行速度的提升。
五、最终决定
通过上面的描述，我们已经基本上把电信行业软件开发的体系架构表述清楚了。图3是笔者早先完成的一个基于J2EE架构的产品开发技术框架，仅供参考：
1 J2EE实现整体设计原则与思想
该系统的设计，采用了组件化的设计思想，同时根据项目的特点，对J2EE的实现架构进行了适当的改进，使之能更适应电信目前的要求和今后扩展的需要。
系统采用J2EE体系架构进行整体结构设计，这也是国际上流行的解决大型企业应用及关键性业务应用的优秀技术。
2 功能设计
通过J2EE技术框架实现电信行业系统的所有功能。
3 体系结构
该系统必须采用多层体系结构。建议采用如图3所示的六层体系进行架构。
4 构架特点
下面按照数据库层、数据管理层、事务处理层、会话处理层、逻辑控制层、前端表现层的顺序对以上各层功能和特点进行详细的描述：
（1）数据库层
选用某种数据库，提供数据存储服务，同时，还需要提供灾难备份和恢复功能。所以，目前，电信行业内部对数据库的基本要求如下：
①支持ANSI/ISO SQL-89、ANSI/ISO SQL-92标准；
②支持中文汉字内码，符合双字节编码；
③支持主流厂商的硬件平台及操作系统平台；
④数据库系统应具有良好的伸缩性；
⑤支持主流的网络协议（如：TCP/IP、IPX/SPX、NETBIOS及混合协议）；
⑥具有良好的开放性，支持异种数据库的互访：
实现对文件数据和桌面数据库数据的访问；
实现对大型异种数据库的访问；
能够将原有异种数据库向本数据库无损失移植；
实现和高级语言互联的能力；
支持XA、ODBC 3.0、X/OpenCLI、JDBC等工业标准；
支持分布式事务及两阶段提交功能。
⑦具有支持并行操作所需的技术（如多服务器协同技术、事务处理的完整性控制技术等）；
⑧支持网络上同构或异构数据库之间数据的冗余性复制；具有多种复制功能模块（如实时复制、定时复制、双向复制、多点方式下的N向复制、复制转发，复制范围可整表复制或表中部分行复制或修改单元复制）；
⑨支持联机事务处理（OLTP），支持决策支持的建立，要求能够实现数据的快速装载、高效的并发处理和交互式查询；
⑩支持C2或以上级安全标准、多级安全控制；
支持数据库存储加密及相应冗余控制；
提供Web服务接口模块，对客户端输出协议支持HTTP2.0、SSL等；
支持联机存储和备份功能（如磁带方式、光盘方式）；
应具有强的容错能力、错误恢复能力、错误记录及预警能力；
数据库、表大小等技术参数可灵活设置，支持对多媒体数据及大数据量处理的技术需求；
应可以避免数据库死锁的出现，一旦死锁能够自动解锁；
开发工具易使用、开发效率高、维护方便；
支持多种CASE工具。
上面对数据库的各个方面都提出了要求，在电信行业内部，目前对于中小型非关键业务项目采用MS SQL Server 2000的比较多，大型项目基本上都避开微软的体系和产品，而采用Oracle和DB2作为系统的数据库选择。
（2）数据管理层
这是整个系统中唯一进行数据访问、数据控制和数据安全校验的部分，是系统中唯一与数据库交互的部分，这也从另一个层面提高了数据安全性。
另外，由于有些电信行业系统的分布地域比较广，采用这种方式有利于分布式数据的有效管理，可提高数据的利用率和有效性。
优点：专用的数据管理层屏蔽了系统的其他部分对系统数据库的直接访问，增加了系统数据的隐蔽性，提高安全性和可管理性。
具体实现的时候，可尽量采用应用服务器所提供的功能，采用容器管理实体Bean（也就是CMP Entity Bean）来开发数据管理层，这样可以降低开发人员的开发工作量，提高效率，提高组件的可重用性。而且，当数据库发生变化的时候，不需要做大量的编码，通过应用服务器本身就可以直接对这种变化做出相应的反应。
注：对于CMP和BMP的使用的基本观点是这样：对于完全新建的系统，也就是说没有老系统的存在，或者可以忽略老系统的数据库设计方式可能对新系统的数据库设计造成的影响的时候，建议采用CMP的方式来开发Entity Bean，这样就可以完全采用OO的方式从需求开始到分析设计和编码实现都依托于OO的思想进行整体的规划，系统实现也会相对比较合理。而对于不符合上述情况的系统，一般在前端流程实现和业务逻辑实现中可以考虑采用OO的过程，在数据库管理层的实现中需要考虑与前端的配合外，数据库管理层的设计和数据库层的设计建议采用面向数据的过程进行规划，否则，不仅仅用户可能会对工期不满，开发团队也将面临着数据抽取与转换的难题。
（3）事务处理层
系统中进行事务处理的主要部分。这部分将根据具体的业务逻辑和实现进行业务控制和事务处理。在业务进行变化的时候，不影响系统的其他部分。
由于有些规则和制度会因为时间和各种情况有一定的变化，因此很多业务的具体处理流程和过程都需要修改，这样的修改如果放在其他部分，就有可能影响到很多其他业务的正常开展。
优点：经过仔细考虑后，笔者认为：针对所有具体的业务增加专用的事务处理层，进行专项业务的处理和控制。提高系统整体的可重用性，降低系统各部分之间的耦合度。
通过这种方式，可以随时随地地增加一项业务，减少一个环节，都不会对其他部分造成大影响，除非这项业务有一些固有的特殊的页面展示要求，否则都可以方便的达到上面的功能。
例如：在业务重组和旧制度废除、新制度发布的时候，可以先按照新制度定制好流程组件，在新制度发布生效的时候，将旧组件卸下，新组件安装即可。在现有的应用服务器上使用时，甚至服务都不需要中断，对于一个业务的更新，仅仅需要一两秒钟的时间就可以完成。
缺点：一定程度上，这对效率有所影响，但相对于Internet网络状况对系统性能的影响来看，这种架构模式对整个系统性能的影响仍然是很小的。
笔者建议：
①如果遇到大数据量查询时，建议越过这种架构模式，直接通过安全的SQL连接方式从数据库中尽快获取信息。
②对于大型的电子商务系统也可以借鉴这种体系架构，但对于仅仅在局域网内工作的系统，就可以对本架构进行简化，因为局域网内的安全性相对较高，所以，可以考虑简化以提高系统性能和运行效率。
（4）会话处理层
会话层，处理与前端展现的会话信息，提供交互的第一个处理界面，处理简单、稳定的事务。不处理复杂的事务和变化较频繁的事务。
优点：提供对前端发送过来的请求和各种数据信息的处理，当前端展现发生变化的时候，不会影响到后台的服务组件代码。
提供对简单事务的处理，这些事务一般是通用型的、基本上不发生变化的事务流程。如电信行业的批复流程、审核流程等等。
（5）逻辑控制层
系统进行控制的部分。这部分将提供系统整体的控制，处理各个部分之间的关系，启动各层间的操作和运行。同时它可以屏蔽前后两层（前端表现层和会话处理层）之间的联系，降低系统的耦合度。
优点：这是MVC中的控制层，在采用J2EE进行系统架构设计时，IBM非常推崇这种模式。在本系统的架构考虑中也认为采用这种模式是相当合适的，但同时考虑到这个系统的实际情况，本文对这种模式作了扩展，将模型层分成两个部分，也就是数据管理层和事务处理层，具体原因已经在这两个部分作了解释。
这种模式是把控制权和所有权进行分离，当具体业务和会话表现等部分发生变化的时候，开发人员不需要修改控制层的代码，使得整个系统中各个部分的权责更加明确，降低了维护的工作量。
（6）前端表现层
系统中提供数据展现的部分，属于整个系统的UI。这也是用户对整个系统最直接接触的部分。将提供报表展现、报表定制和录入、数据输入和输出、信息浏览发布等等……
优点：这是一个完全独立的表现层，如果设计的比较好，就可以做到：其样式、风格都可以由美工进行直接的修改和设计。这些设计不会影响到任何后台的事务，因此，甚至可以做到随时更换风格。
5 性能实现
（1） 安全性
关于安全性的描述，请参见系统和数据安全管理中的描述。
（2）可靠性
系统的可靠性将在具体的项目开发过程中体现出来。因为每一项业务的添加与减少都对系统整体的稳定性产生一定的影响。开发过程中，只要对设计进行严格的检验和测试就可以保证整个系统的可靠性。
（3）灵活性和扩展性
按照目前所规划的技术架构，开发者可以随时在上面进行各个功能层的组合和分离，也可以将各个功能层分布在各个不同的服务器上共同提供服务，因此整个系统无论是在物理结构上还是在逻辑结构上都具有很高的灵活性和扩展性。
对于业务组件，开发者/使用者可以对其进行业务分割和重组，以提高组件的利用率，对于今后其他系统的开发也具有技术积累的意义。
同时，这些业务组件可以根据业务状况的变化进行更新和替换。比如说：某一项新的制度发布生效前，开发者可以提前按照新的制度开发好完整的业务组件，在生效的那个时间点，将老组件取下，新组件安装到服务器上。这样也就不会因为制度的变化影响到各个业务或者办公流程的顺利开展。
（4）实用性
系统的技术架构是专门针对项目的一些特性对J2EE原有的体系架构进行修改和完善后设计出来的。它既可以应付复杂多变的业务流程，对于一般十分稳定的业务流程也不会出现多余的问题，且具有相当好的扩展性和灵活性。