天津移动业务支撑应急系统设计与实现

　　中国移动业务支撑系统经过近几年的集中化改造建设和不断完善，经过NGBOSS（新一代业务运营支撑系统）建设，业务支撑系统已经在市场拓展、客户服务等工作中发挥了重要的支撑作用，成为中国移动贯彻落实“服务与业务领先”战略的有力手段。

　　日益激烈的市场竞争和不断提高的客户服务质量需求对BOSS业务支撑能力和可靠稳定运行的要求越来越高，从面向客户服务的角度而言，无论何时出现何种情况，都需要移动运营商提供不间断的业务支撑服务，以保证客户满意度、客户服务质量、企业信誉等不受影响，对企业而言也可避免财务损失，增强企业竞争力。

　　与此同时，BOSS集中化改造、NGBOSS一阶段和二阶段建设在带来业务快速响应等众多优势的同时，也存在着系统故障点集中、风险集中的危险，如：系统故障、人为误操作、火灾、水灾、传输中断、电网停电等系统风险。因此，适时、合理地规划和开展中国移动业务运营支撑系统应急保障体系建设，已经成为中国移动的重要任务。

　　为保证业务持续运营，NGBOSS系统已经在系统架构上充分考虑其可靠性。NG-CRM/BOSS系统的关键应用系统的服务器都进行了高可靠性（HA）设计，杜绝了单点故障导致业务中断。在本地高可靠性的基础上，为了在出现灾难情况时（如地震、水灾、火灾、瘟疫、人为灾难故障），能够有效对系统和应用进行恢复，NGBOSS系统还建立了容灾备份系统，实现了数据及应用的容灾。

　　但是，在某些故障（如：数据库磁盘故障、软件错误等）发生时，HA并不能解决问题，同时由于这些故障预计能够在短时间内（4小时以内）能够解决，因此并没有必须进行容灾切换。

　　在这种情况下，运营商需要有一个应急系统，能够支持短时间的关键业务的运营生产，保证客户感受不到业务的中断。

　　通过业务支撑应急系统的建设，建立业务支撑网的应急风险预防、应急响应机制和恢复措施，保证在发生突发事件时，能够在特定的时间要求内，能够全部或部分恢复关键业务功能，提高关键业务连续运行能力，提升服务质量和服务水平，并降低运营风险，将业务损失降低到可接受的程度，以增强企业竞争力。

　　本文主要是针对天津移动业务支撑应急系统技术方案的研究，通过对现状的分析，确认系统建设范围，设计系统功能及技术架构以完成整体的建设方案。并且通过对应急场景的归纳总结，保证方案的可实施性和有效性。

　　论文主要分为以下章节：

　　第一章绪论，介绍了天津移动业务支撑应急系统的必要性和需解决的问题，提出了本文的研究内容及意义。

　　第二章对目前天津移动业务支撑系统的现状分析，确认建设方向、建设范围及具体内容。

　　第三章对天津移动业务支撑应急系统技术研究及选型。

　　第四章介绍天津移动业务支撑应急系统的建设方案，包括系统架构设计、功能架构设计、各模块设计、数据流设计、部署方案等。

　　第五章为天津移动业务支撑应急系统的应急场景的分析和确定，包含各子系统的应急场景及相关流程，为项目建设提供了验证依据。

　　第六章为天津移动业务支撑应急系统演练方案及演练总结。

　　第七章为结论与展望，对论文工作进行了总结，展示了本系统开发的主要成果及丞待完善的方面。

　　2.1.1功能现状

　　BOSS系统主要包括产品管理、信息管理、融合计费、综合结算、综合帐务、采集预处理、服务开通、合作伙伴管理、基础管理等九大功能域，如下图2.1.1-1所示。

　　2.1.3网络组织现状

　　为了充分保证BOSS/CRM系统的安全、可靠性，目前BOSS/CRM系统网络共分为三层：SAN存储层、核心网络层（内网）、接入网络层（外网DMZ）。其中，计费应用、帐务应用、CRM数据库、集中采集、测试、备份、统计分析、结算等核心服务器直接通过SAN交换机实现磁盘阵列、磁带库的存储和备份；计费应用、帐务应用、CRM数据库、集中采集、联机指令、测试、备份、统计分析、结算等核心服务器属于关键生产服务器，处于核心网络层，分别连接在移通大厦20层2台Catalyst 6509核心内网交换机及移通大厦22层2台Quidway S8505核心内网交换机上；考虑到系统的安全可靠性，把与外界联系紧密的服务器，如中间件、WEB、一级BOSS接口、DSMP接口、防病毒、认证、桌面管理系统、SOC服务器连接在IP1260防火墙上的DMZ区，即4台C4506交换机上；与OA、客服、采集、营业厅等系统的连接均通过异构防火墙连接在接入的Catalyst 6509交换机上。接入交换机Catalyst 6509（外网）、千兆防火墙IP1260、核心交换机Catalyst 6509（内网）组成BOSS系统的高速数据通道，采用负荷分担的方式进行工作，确保系统稳定、可靠的运行。

　　此外，随着世纪大道IT机房的启用，MIS、统一信息平台和经营分析系统将陆续搬迁至相应机房；目前在世纪大道机房设有4台Catalyst 6509交换机，分别与移通大厦机房、南开工业园机房对应连接，实现信息化系统及经营分析系统与BOSS系统的互联。

　　网络结构如下图所示。

　　图2.1.31 BOSS及CRM系统网络结构图

　　BOSS/CRM系统网络设备配置情况如下表所示。

　　表2.1.3-1天津公司BOSS/CRM系统网络设备配置情况表

　　序号设备名称或型号数量主要配置及说明备注

　　1 Catalyst6509交换机2分别配置2×48个10/100 Base-T电口，2×16个千兆光口，1个48口千兆光口。移通20楼，核心

　　2 Catalyst6509交换机2分别配置2×48个10/100 Base-T电口，2×16个千兆光口，1个48口千兆光口。南开工业园，核心

　　3 Catalyst6509交换机2分别配置2×48个10/100 Base-T电口，2×16个千兆光口移通20楼，连接外网

　　4 Catalyst6509交换机2分别配置2×48个10/100 Base-T电口，1×16个千兆光口南开工业园，连接外网

　　5 Catalyst4506交换机2分别配置1个控制卡（含2个光口）、1×6口GE卡，1个2GE+32口10/100M板卡，1个18口光口板卡移通20楼

　　6 Catalyst4506交换机2分别配置1个控制卡（含2个光口）、1×6口GE卡，1个2GE+32口10/100M板卡，1个18口光口板卡南开工业园

　　7 NOKIA IP1260千兆防火墙2分别配置2个双端口千兆卡移通20楼

　　8 NOKIA IP1260千兆防火墙2分别配置2个双端口千兆卡南开工业园

　　9华为S8505交换机2分别配置1个48口10/1000电口板卡，1个48口光口板卡移通22楼，核心

　　2.1.4风险分析

　　目前天津公司NGBOSS系统的业务连续性保障体系有三种模式，一种是多节点负荷分担方式，该方式主要用于系统接入层和业务逻辑层，有效地降低了个别节点故障对业务的影响程度；一种是磁带库、CDP和存储底层复制实现的数据级容灾（以下简称数据容灾）方式，该方式其实只是实现了系统中主要业务数据的备份，没有实现应用级容灾，不能在发生突发事件时，在特定的时间（RTO）要求内，能够全部或部分恢复关键业务功能；一种是双机备份共享存储（以下简称本地HA）方式，该方式主要用于系统核心层。对于系统核心层采用的本地HA模式来保障业务连续性，存在如下风险：

　　1)由于核心系统IO量较大，如发生系统单节点宕机等严重故障可能会造成由于IO未及时写入磁盘而产生的文件系统错误，导致备机启动失败。

　　2)人为因素、数据库逻辑错误或者存储故障造成的数据损坏从而引起业务中断，本地HA将无法解决。NG-CRM/BOSS系统全部业务要求7×24小时运行，存储阵列的使用强度大大增加，没有时间对存储系统进行定期维修和保养。因此，当使用一段时间后，存储系统的部件连续或同时出现故障的可能性增加。此外，随着存储系统的功能和性能越来越强，存储系统内部的控制软件也日趋复杂，就像一个操作系统，其本身也会出现故障或漏洞。部分省公司也曾经发生过由于存储故障造成业务系统长时间停机、数据丢失的重大故障。

　　3)在系统割接、平台软硬件维护或应用版本升级等情况下，本地HA都将可能无法满足业务连续性要求。

　　4)生产机房发生火灾、泡水等情况下，多节点负载分担和本地HA模式都不能保障业务连续性。

　　2.1.5风险应对措施

　　针对上述系统风险，可以通过应急系统的建设加以规避，以提高关键业务连续运行能力。应急系统是本地HA、多节点负载分担等业务连续保障模式的轻量级补充，可实现关键业务的快速恢复。本地HA是系统核心层的整体恢复体系，通过启动HA可以全面接管核心层生产系统。多节点负载分担可以在生产机房未发生火灾等情况下，确保业务连续性。

　　归纳起来，主要有两种情况下须进行生产系统至应急系统的切换：一种是主动应急，生产系统进行平台版本升级、应用版本上线、软硬件更换、数据库扩容等例行维护工作情况下，为了保障关键业务连续性，需要将生产系统切换到应急系统。一种是被动应急，生产系统的关键业务发生故障而且故障修复时间大于30分钟的情况下，生产系统应切换到本地应急系统。具体如下：

　　1)人为或数据库逻辑等因素引起的数据损坏：数据库的逻辑错误或人为的操作失误可能会导致生产中心关键系统数据库均不可用，在此情况下须启用应急系统。

　　2)应用版本升级场景：目前NG-CRM/BOSS系统有稳定的新业务上线流程，在上线前有着严格的测试流程。但是由于NG-CRM/BOSS业务关联性强，前期的测试有可能没有覆盖所有的业务流程。上线后，可能造成系统运行不稳定或者部分业务受理结果不正确。在此情况下，必须采取措施，避免错误继续扩大，同时需要回退更新。

　　3)前台业务受理中断场景：由于系统硬件、软件、网络故障导致实体、电子渠道业务受理中断，引起客户投诉与抱怨，为了降低客户投诉率，可以切换至应急系统满足关键业务的连续性受理。

　　4)系统割接场景：在进行系统割接时，为了不影响用户满意度以及集团的考核，可以切换到应急系统来满足关键业务的连续性。（如：自动台的余额查询、空中充值等）。

　　5)硬件维护场景：在系统维护过程中，可能会出现IBM/SUN/HP主机、网络设备、存储设备硬件维护或硬件微码升级的情况，可以切换到应急系统来保证关键业务的连续性。（如：IBM/SUN/HP硬件更换）。

　　6)平台软件维护场景：在系统维护过程中，可能会出现数据库需要补丁升级需要重启等情况，可以切换到应急系统来保证关键业务的连续性。（如：ORACLE/TEXUDO/WEBLOGIC软件补丁升级）。

　　7)前台业务受理中断场景：由于系统硬件、软件、网络故障导致实体、电子渠道业务受理中断，引起客户投诉与抱怨，为了降低客户投诉率，可以切换至应急系统满足关键业务的连续性受理。

　　8)生产机房发生火灾或泡水情况

　　2.2.1业务建设范围

　　应急系统基础建设阶段包括渠道及主要功能如下：

　　2.2.1.1营业前台应急功能

　　在生产系统切换至应急系统后，营业前台渠道应支持如下表格2.2.1.1-1所示的业务受理、信息查询及其他辅助功能。

　　表2.2.1.1-1营业前台应急功能表

　　业务功能功能域功能说明备注

　　开户业务受理可为客户建立档案、开通客户订购的移动服务及客户付费信息

　　充值业务受理可为用户进行充值的服务充值应至少包括：前台现金充值、充值卡充值、空中充值三种。

　　缴费业务受理可为用户进行缴费服务

　　停复机业务受理可为用户提供停机、复机的服务

　　补换卡业务受理可实现对SIM卡的写卡处理，实现IMSI码与ICCID码绑定，同时开通鉴权服务

　　用户资料查询信息查询可查询用户的准实时资料，如姓名、证件号码等信息

　　余额查询信息查询查询用户余额准实时数据信息

　　积分查询信息查询可查询用户的准实时积分值信息

　　账单查询信息查询可查询用户的准实时消费账单信息

　　PUK码查询信息查询可为用户提供查询PUK码的服务

　　家庭充值/缴费业务受理可为家庭用户提供充值或缴费服务

　　集团充值/缴费业务受理可为集团用户提供充值或缴费服务

　　套餐变更业务受理可为用户提供各类产品套餐的变更服务

　　营销方案业务受理可为用户提供营销方案的办理及撤销服务

　　号源查询信息查询可提供号源的查询服务

　　亲情组合及查询信息查询可为用户提供亲情号码组合受理及查询服务

　　用户订购信息查询信息查询可提供用户的营销方案、已开通业务、附加功能、增值业务、梦网业务、自有业务、国际功能的查询服务

　　查询GPRS流量信息查询可查询用户准实时的GPRS流量信息

　　清单查询信息查询可查询用户准实时的清单信息

　　2.2.1.2客服系统应急功能

　　在生产系统切换至应急系统后，客服系统应提供如下表格2.2.1.2-1所示的基本业务及用户信息资料查询功能。

　　表2.2.1.2-1客服系统应急功能表

　　业务功能渠道功能域功能说明备注

　　密码校验人工台/自动台信息查询可对用户输入的密码进行正确性校验

　　用户资料查询人工台/自动台信息查询可查询用户的准实时资料信息

　　余额查询人工台/自动台信息查询查询用户余额准实时数据信息

　　积分查询人工台/自动台信息查询可查询用户的准实时积分值信息

　　申请停复机人工台业务受理可为用户提供停机、复机的服务

　　用户订购信息查询人工台信息查询可提供用户的营销方案、已开通业务、附加功能、增值业务、梦网业务、自有业务、国际功能的查询服务

　　账单查询人工台信息查询可查询用户的消费准实时账单信息

　　PUK码查询人工台信息查询可为用户提供查询PUK码的服务

　　亲情组合及查询人工台业务受理可为用户提供亲情号码组合受理及查询服务

　　查询GPRS流量人工台信息查询可查询用户准实时的GPRS流量信息

　　清单查询人工台信息查询可查询用户准实时的清单信息

　　套餐变更人工台业务受理可提供为用户办理套餐产品变更的服务

　　查询有效期自动台信息查询可查询账户余额的有效期时间信息

　　话费查询自动台信息查询可查询用户话费准实时信息

　　欠费信息查询自动台信息查询可查询用户欠费准实时信息

　　2.2.1.3电子渠道应急功能

　　2.2.1.3.1网上营业厅

　　网上营业厅在生产系统切换至应急系统后，可支持如下表格2.2.1.3.1-1所示的业务受理、信息查询及其他辅助功能。

　　表2.2.1.3.1-1网上营业厅应急功能表

　　业务功能功能域功能说明

　　密码验证业务受理可对用户输入的密码进行正确性校验

　　用户资料查询信息查询可查询用户的准实时资料，如姓名、证件号码等信息

　　余额查询信息查询查询用户余额准实时数据信息

　　查询GPRS流量信息查询可查询用户准实时的GPRS流量信息

　　账单查询信息查询可查询用户的消费准实时账单信息

　　清单查询信息查询可查询用户准实时的清单信息

　　网上充值卡充值业务受理可支持网上营业厅通过充值卡进行充值的服务

　　停复机业务受理可为用户提供停机、复机的服务

　　套餐变更业务受理可为用户提供各类产品套餐的变更服务

　　亲情组合及查询业务受理可为用户提供亲情号码组合受理及查询服务

　　用户订购信息查询信息查询可提供用户的营销方案、已开通业务、附加功能、增值业务、梦网业务、自有业务、国际功能的查询服务

　　PUK码查询信息查询可为用户提供查询PUK码的服务

　　2.2.1.3.2掌上营业厅

　　掌上营业厅在生产系统切换至应急系统后，可支持如下表格2.2.1.3.2-1所示的业务受理、信息查询及其他辅助功能。

　　表2.2.1.3.2-1掌上营业厅应急功能表

　　业务功能功能域功能说明

　　密码验证业务受理可对用户输入的密码进行正确性校验

　　用户资料查询信息查询可查询用户的准实时资料，如姓名、证件号码等信息

　　余额查询信息查询查询用户余额准实时数据信息

　　查询GPRS流量信息查询可查询用户准实时的GPRS流量信息

　　账单查询信息查询可查询用户的消费准实时账单信息

　　清单查询信息查询可查询用户准实时的清单信息

　　网上充值卡充值业务受理可支持网上营业厅通过充值卡进行充值的服务

　　停复机业务受理可为用户提供停机、复机的服务

　　套餐变更业务受理可为用户提供各类产品套餐的变更服务

　　亲情组合及查询业务受理可为用户提供亲情号码组合受理及查询服务

　　用户订购信息查询信息查询可提供用户的营销方案、已开通业务、附加功能、增值业务、梦网业务、自有业务、国际功能的查询服务

　　PUK码查询信息查询可为用户提供查询PUK码的服务

　　2.2.1.3.3短信营业厅

　　短信营业厅在生产系统切换至应急系统后，可支持如下表格2.2.1.3.3-1所示的业务受理、信息查询及其他辅助功能。

　　表2.2.1.3.3-1短信营业厅应急功能表

　　业务功能功能域功能说明

　　密码验证业务受理可对用户输入的密码进行正确性校验

　　用户资料查询信息查询可查询用户的准实时资料，如姓名、证件号码等信息

　　余额查询信息查询查询用户余额准实时数据信息

　　查询GPRS流量信息查询可查询用户准实时的GPRS流量信息

　　账单查询信息查询可查询用户的消费准实时账单信息

　　清单查询信息查询可查询用户准实时的清单信息

　　网上充值卡充值业务受理可支持网上营业厅通过充值卡进行充值的服务

　　停复机业务受理可为用户提供停机、复机的服务

　　套餐变更业务受理可为用户提供各类产品套餐的变更服务

　　亲情组合及查询业务受理可为用户提供亲情号码组合受理及查询服务

　　用户订购信息查询信息查询可提供用户的营销方案、已开通业务、附加功能、增值业务、梦网业务、自有业务、国际功能的查询服务

　　PUK码查询信息查询可为用户提供查询PUK码的服务

　　2.2.1.4网络中断

　　网络中断业务受理流程：

　　1)在网络出现问题时，应急系统只在本机进行缴费信息的记录，生成缴费记录文件，不做任何后续操作；

　　2)网络正常而生产系统未恢复时，执行应急缴费提交，根据配置的应急系统缴费流程，完成相关应急操作；

　　3)生产系统正常后，同步应急数据到生产系统。

　　如图2.2.1.4-1所示：

　　图2.2.1.41网络中断业务受理流程图

　　2.2.1.5辅助功能

　　除以上提及的影响用户的业务应急功能之外，为了更加的完善应急系统的支撑能力，应急系统应提供如下表格2.2.1.5-1所示的基础辅助功能。如下表所示：

　　CRM数据库、客服数据库和帐务管理数据库中的数据，采用第三方软件（DSG realsync/Oracle goldengate/QUEST shareplex等）将应急业务需要的相关数据准实时从生产系统同步到应急系统。

　　计费数据库中的数据通过应用改造的方式来同步，生产系统生成一份账单文件和清单文件送到应急系统，应急系统使用入库进程入到应急数据库中，保证两个系统的数据一致性。

　　2.2.3应急数据回切

　　在生产系统恢复后，应急系统需要把故障期间的业务受理数据提交到生产系统。同时服务开通工单表（日志）也需要合并到BOSS生产系统。

　　应急交易数据提交需要将应急期间的业务受理交易数据和缴费交易提交到BOSS生产系统。应急交易数据提交需要对提交流量进行控制，避免对恢复后的生产系统正常处理产生影响。同时需要标识应急交易提交中发生错误的交易，供人工核对处理。

　　对业务受理交易，将订单及台帐相关数据搬到生产系统，重跑相关订单，因资料修改并不是完全在完工流程中完成，有部分业务在登记时已经修改，需要改造现有的完工流程，增加修改资料的环节，且回切业务不需要发指令。

　　对缴费类交易，应急系统发生的缴费相关数据导到ACT生产库，其中预存、结余数据需要更新到账务物理库和altibase。

　　对查询类业务，还需要将相关日志，台帐等导到生产系统，以便后续的查询。

　　2.2.3应急系统管理功能

　　1)应急系统版本管理

　　对应急系统软件的版本进行检查、监控，记录生产系统与应急系统软件配置文件和运行环境参数的差异，保证应急系统可执行代码与生系统同步升级，并记录应用软件版本升级轨迹。主要包括版本注册、版本一致性检查、版本更新控制、版本发布管理、版本更新等内容。

　　通过应急系统建立版本管理机制，自动完成生产系统、应急系统相应环境配置、软件版本号、软件更新日期等信息比对，对版本差异进行告警发送，提醒维护人员及时进行关注并处理。

　　2)应急系统数据管理

　　为保证应急系统在必要的时候能够及时接管生产系统，应急系统与生产系统的数据需保持一致性、完整性，应在应急系统中建立起与生产系统的数据同步审查机制，并通过数据核对帮助生产系统发现可能出现的问题，进一步完善和优化生产系统和应急系统。

　　应急系统数据管理主要包括：稽核配置管理、数据采集管理、数据比对管理、数据同步管理。

　　对各数据管理各功能模块异常状态进行监控，异常时进行告警发送，提醒维护人员及时进行关注并处理。

　　3)应急系统切换管理

　　包括对应急系统组织、人员、角色、权限的管理，明确应急系统组织架构，确保应急系统切换过程的有序进行。

　　收到切换指令后自动修改或人工修改接口地址并测试，保证应急系统能够正常运行。

　　生产系统恢复正常后，需要进行回切操作。

　　切换管理系统主要包括：人员管理、权限管理、切换管理、回切管理。根据应急系统组织机构，对不同的人员角色赋予不同的权限，要求管理平台界面化展示当前状态，操作人员实施一键式切换和回切操作，避免人为操作失误带来的切换风险。

　　4)应急系统演习管理

　　负责规划应急系统应急演习的相关流程与任务，通过系统切换和系统回切的操作，验证应急系统可用性和可靠性。

　　5)应急系统监控管理

　　实时监控应急系统的所有设备是否处于健康状态，监控应急系统软件的关键点，建立故障告警机制，保证应急系统的可用性。（需要和Toptea/BOMC进行分工）。

　　6)应急系统公告管理

　　告知应急切换原因，预计恢复时间，对用户的解释口径。

　　第三章天津移动业务支撑应急系统技术研究

　　3.1.1定义

　　持续数据保护(CDP)是一套技术手段，它可以捕获或跟踪数据的变化，并将其独立存放在生产数据之外，以确保数据可以恢复到过去的任意时间点。持续数据保护系统可以基于块、文件或应用实现，可以为恢复对象提供足够细的恢复粒度，实现几乎无限多的恢复时间点。

　　3.1.2与现有数据保护手段对比

　　CDP出现，是为有效弥补传统数据容灾保护手段不足而产生的。

　　CDP VS传统备份

　　传统的数据保护解决方案专注在对数据的周期性备份上，因此一直伴随有备份窗口、数据一致性和对生产系统的影响等问题。实际上，传统数据保护技术中采用的是对“单一时间点（Single Point-In-Time）”的数据拷贝进行管理的模式，而CDP可以实现对“任意时间点（Any Point-In-Time）”的数据访问，因此可以大大提高数据恢复点目标（RPO）。备份技术实现的数据保护间隔一般为24小时，因此用户会面临数据丢失多达24小时的风险，采用快照技术，可以将数据的丢失量风险降低到几个小时之内，而CDP能够实现的数据丢失量可以降低到秒级。

　　CDP VS数据复制（磁盘镜像）

　　另外一种在数据容灾中常见的数据保护技术是复制技术，它可以通过与生产数据的同步获得数据的最新状态，但其无法规避有人为的逻辑错误或病毒攻击所造成的数据丢失。当生产数据由于以上原因导致数据遭到破坏时（例如数据被误删除），复制技术会将遭到破坏的数据状态同步到容灾数据存储，使容灾数据也受到破坏。而CDP系统可以使数据状态恢复到数据遭到破坏之前的任意一个时间点，因而消除了复制技术所含的风险。

　　3.1.3总结

　　为了保障业务支撑应急系统能够支持短时间的关键业务的运营生产，本系统选择持续数据保护(CDP)技术进行建设。

　　3.2基于J2EE的多层技术架构

　　3.2.1J2EE技术介绍

　　J2EE是Java2平台企业版（Java 2 Platform,Enterprise Edition）。

　　J2EE核心是一组技术规范与指南，其中所包含的各类组件、服务架构及技术层次，均有共同的标准及规格，让各种依循J2EE架构的不同平台之间，存在良好的兼容性，解决过去企业后端使用的信息产品彼此之间无法兼容，企业内部或外部难以互通的窘境。

　　3.2.2J2EE四层模型

　　J2EE使用多层的分布式应用模型，应用逻辑按功能划分为组件，各个应用组件根据他们所在的层分布在不同的机器上。事实上，sun设计J2EE的初衷正是为了解决两层模式(client/server)的弊端，在传统模式中，客户端担当了过多的角色而显得臃肿，在这种模式中，第一次部署的时候比较容易，但难于升级或改进，可伸展性也不理想，而且经常基于某种专有的协议，通常是某种数据库协议。它使得重用业务逻辑和界面逻辑非常困难。现在J2EE的多层企业级应用模型将两层化模型中的不同层面切分成许多层。一个多层化应用能够为不同的每种服务提供一个独立的层，以下是J2EE典型的四层结构:

　　运行在客户端机器上的客户层组件

　　运行在J2EE服务器上的Web层组件

　　运行在J2EE服务器上的业务逻辑层组件

　　运行在EIS服务器上的企业信息系统(Enterprise information system)层软件

　　如图3.2.2-1所示：

　　图3.2.2-1J2EE四层结构

　　客户层组件

　　J2EE应用程序可以是基于web方式的,也可以是基于传统方式的。

　　web层组件

　　J2EE web层组件可以是JSP页面或Servlets.按照J2EE规范，静态的HTML页面和Applets不算是web层组件。正如下图3.2.2-2所示的客户层那样，web层可能包含某些JavaBean对象来处理用户输入，并把输入发送给运行在业务层上的enterprise bean来进行处理。

　　图3.2.2-2Web层组件图

　　业务层组件

　　业务层代码的逻辑用来满足银行，零售，金融等特殊商务领域的需要,由运行在业务层上的enterprise bean进行处理.下图3.2.2-3表明了一个enterprise bean是如何从客户端程序接收数据，进行处理(如果必要的话),并发送到EIS层储存的，这个过程也可以逆向进行。

　　有三种企业级的bean:会话(session)beans,实体(entity)beans,和消息驱动(message-driven)beans.会话bean表示与客户端程序的临时交互.当客户端程序执行完后,会话bean和相关数据就会消失.相反,实体bean表示数据库的表中一行永久的记录.当客户端程序中止或服务器关闭时,就会有潜在的服务保证实体bean的数据得以保存.消息驱动bean结合了会话bean和JMS的消息监听器的特性,允许一个业务层组件异步接收JMS消息。

　　企业信息系统层

　　企业信息系统层处理企业信息系统软件包括企业基础建设系统例如企业资源计划(ERP),大型机事务处理,数据库系统,和其它的遗留信息系统.例如，J2EE应用组件可能为了数据库连接需要访问企业信息系统。

　　3.2.3J2EE结构

　　这种基于组件，具有平台无关性的J2EE结构使得J2EE程序的编写十分简单，因为业务逻辑被封装成可复用的组件，并且J2EE服务器以容器的形式为所有的组件类型提供后台服务.因为不用自己开发这种服务,所以我们可以集中精力解决手头的业务问题.

　　1.容器和服务

　　容器设置定制了J2EE服务器所提供得内在支持，包括安全，事务管理，JNDI(Java Naming and Directory Interface)寻址,远程连接等服务，以下列出最重要的几种服务：

　　J2EE安全(Security)模型可以让你配置web组件或enterprise bean,这样只有被授权的用户才能访问系统资源.每一客户属于一个特别的角色，而每个角色只允许激活特定的方法。你应在enterprise bean的布置描述中声明角色和可被激活的方法。由于这种声明性的方法，你不必编写加强安全性的规则。

　　J2EE事务管理（Transaction Management）模型让你指定组成一个事务中所有方法间的关系，这样一个事务中的所有方法被当成一个单一的单元.当客户端激活一个enterprise bean中的方法，容器介入一管理事务。因有容器管理事务，在enterprise bean中不必对事务的边界进行编码。要求控制分布式事务的代码会非常复杂。你只需在布置描述文件中声明enterprise bean的事务属性，而不用编写并调试复杂的代码。容器将读此文件并为你处理此enterprise bean的事务。

　　JNDI寻址(JNDI Lookup)服务向企业内的多重名字和目录服务提供了一个统一的接口,这样应用程序组件可以访问名字和目录服务.

　　J2EE远程连接（Remote Client Connectivity）模型管理客户端和enterprise bean间的低层交互.当一个enterprise bean创建后,一个客户端可以调用它的方法就象它和客户端位于同一虚拟机上一样.

　　生存周期管理（Life Cycle Management）模型管理enterprise bean的创建和移除,一个enterprise bean在其生存周期中将会历经几种状态。容器创建enterprise bean，并在可用实例池与活动状态中移动他，而最终将其从容器中移除。即使可以调用enterprise bean的create及remove方法，容器也将会在后台执行这些任务。

　　数据库连接池（Database Connection Pooling）模型是一个有价值的资源。获取数据库连接是一项耗时的工作，而且连接数非常有限。容器通过管理连接池来缓和这些问题。enterprise bean可从池中迅速获取连接。在bean释放连接之可为其他bean使用。

　　2.容器类型

　　J2EE应用组件可以安装部署到以下几种容器中去:

　　EJB容器管理所有J2EE应用程序中企业级bean的执行，enterprise bean和它们的容器运行在J2EE服务器上。

　　Web容器管理所有J2EE应用程序中JSP页面和Servlet组件的执行，Web组件和它们的容器运行在J2EE服务器上。

　　应用程序客户端容器管理所有J2EE应用程序中应用程序客户端组件的执行.应用程序客户端和它们的容器运行在J2EE服务器上。

　　Applet容器是运行在客户端机器上的web浏览器和Java插件的结合。

　　如图3.2.3-1所示：

　　3.2.43J2EE优势

　　J2EE为搭建具有可伸缩性、灵活性、易维护性的商务系统提供了良好的机制：

　　1.保留现存的IT资产：

　　由于企业必须适应新的商业需求，利用已有的企业信息系统方面的投资，而不是重新制定全盘方案就变得很重要。这样，一个以渐进的（而不是激进的，全盘否定的）方式建立在已有系统之上的服务器端平台机制是公司所需求的。J2EE架构可以充分利用用户原有的投资，如一些公司使用的BEA Tuxedo、IBM CICS,IBM Encina，、Inprise VisiBroker以及Netscape Application Server。这之所以成为可能是因为J2EE拥有广泛的业界支持和一些重要的'企业计算'领域供应商的参与。每一个供应商都对现有的客户提供了不用废弃已有投资，进入可移植的J2EE领域的升级途径。由于基于J2EE平台的产品几乎能够在任何操作系统和硬件配置上运行，现有的操作系统和硬件也能被保留使用。

　　2.高效的开发：

　　J2EE允许把一些通用的、很繁琐的服务端任务交给中间供应商去完成。这样开发人员可以集中精力在如何创建商业逻辑上，相应地缩短了开发时间。高级中间件供应商提供以下这些复杂的中间件服务：

　　1)状态管理服务–让开发人员写更少的代码，不用关心如何管理状态，这样能够更快地完成程序开发。

　　2)持续性服务–让开发人员不用对数据访问逻辑进行编码就能编写应用程序，能生成更轻巧，与数据库无关的应用程序，这种应用程序更易于开发与维护。

　　3)分布式共享数据对象CACHE服务–让开发人员编制高性能的系统，极大提高整体部署的伸缩性。

　　3.支持异构环境：

　　J2EE能够开发部署在异构环境中的可移植程序。基于J2EE的应用程序不依赖任何特定操作系统、中间件、硬件。因此设计合理的基于J2EE的程序只需开发一次就可部署到各种平台。这在典型的异构企业计算环境中是十分关键的。J2EE标准也允许客户订购与J2EE兼容的第三方的现成的组件，把他们部署到异构环境中，节省了由自己制订整个方案所需的费用。

　　4.可伸缩性：

　　企业必须要选择一种服务器端平台，这种平台应能提供极佳的可伸缩性去满足那些在他们系统上进行商业运作的大批新客户。基于J2EE平台的应用程序可被部署到各种操作系统上。例如可被部署到高端UNIX与大型机系统，这种系统单机可支持64至256个处理器。（这是NT服务器所望尘莫及的）J2EE领域的供应商提供了更为广泛的负载平衡策略。能消除系统中的瓶颈，允许多台服务器集成部署。这种部署可达数千个处理器，实现可高度伸缩的系统，满足未来商业应用的需要。

　　5.稳定的可用性：

　　一个服务器端平台必须能全天候运转以满足公司客户、合作伙伴的需要。因为INTERNET是全球化的、无处不在的，即使在夜间按计划停机也可能造成严重损失。若是意外停机，那会有灾难性后果。J2EE部署到可靠的操作环境中，他们支持长期的可用性。一些J2EE部署在WINDOWS环境中，客户也可选择稳定性）更好的操作系统如Sun Solaris、IBM OS/390。稳定性最好的操作系统可达到99.999%的可用性或每年只需5分钟停机时间。这是实时性很强商业系统理想的选择。

　　3.2.5J2EE和.NET体系结构比较

　　作为彼此竞争的应用平台，J2EE和.NET开发平台在目标和体系结构上极其相似，但在实现上又完全不同。

　　（１）类似的平台基础构造J2EE和.NET两个平台在底层的执行引擎都源于托管的虚拟机概念,但.NET的CLR沿着Java虚拟机(JVM)走得更远，CLR在借鉴了JVM的自动垃圾收集、异常处理等机制的同时，又为.NET平台添加了多语言支持、组件自描述等新的特性。

　　在.NET和J2EE平台上，程序的编译都经过两个类似的过程。首先，特定高级语言编译器将C#（及其他.NET语言）和Java源代码分别翻译成中间语言(IL)和字节代码(ByteCode)。.NET在中间语言设计时通盘考虑了多个主流高级语言，在这一层面实现了.NET平台的跨语言承诺；J2EE的基石是Java语言，它最典型的特征是：一次编写，多次运行。跨平台是J2EE一直引以为豪的关键，这是通过JVM来实现的。

　　其次，在执行时，中间语言被即时编译器(JIT)编译成特定平台的二进制代码，字节代码则通过JVM解释执行，完成各自语言的指令功能。鉴于微软在“Wintel平台”上的代码优化功底，.NET代码的执行速度较之于Java有明显的优势是不争的事实。但在Unix/Linux平台上，由于.NET迟迟未能实现其跨平台的承诺，J2EE几乎成了惟一的选择，执行效率的比较也就无所谓。在代码执行的同时，通用语言运行时和Java虚拟机也都提出了异常捕捉、类型安全、内存分配和垃圾收集等自动化内存管理工作，大大减轻少了现代软件的内存泄漏问题，减轻了程序员的繁重负担。

　　面向对象程序设计在J2EE和.NET平台中都获得了直接的支持，单根继承加多接口实现是它们共有的特征。但在面向对象之外，.NET对现代组件编程提供了直接支持。当然，当下很多企业中间件都是基于J2EE平台，只是.NET从设计、编码、配置到运行都给予了组件编程更多、更直接的支持。

　　在基础的和企业级的服务上两个平台很难一决高低。从基础的集合、字符串操作到企业级的API接口，如JMS、JDBC、JAX和JNDI等，J2EE在这方面有着非常坚实的结构。微软.NET框架类库也不示弱，提供了从图画、网络、线程到ADO.NET、ADSI、Windows表单和ASP.NET等一系列的API。

　　除去API类库的无缝的功能复用外，对本地平台的调用操作也是值得关注的。CLR和Java虚拟机都支持本地方法的调用。在异构平台方面，J2EE更钟情于IIOP（Internet InterORB Protocol），而.NET则使用SOAP。

　　（2）相同的三层/多层体系基于三层/多层分布式计算结构已毋庸置疑地成为当今企业应用的主流模式，也是两个平台较量的着力点。

　　在客户端，表示层负责用户与系统的交互。对于不同的处理要求，.NET和J2EE都提出了基于桌面的应用程序和基于浏览器的Web应用的开发组件：Java Application与Windows表单、Java Servlet/JSP与ASP.NET双双形成犄角之势。但Windows表单依赖微软桌面系统的天然优势，无论在交互速度还是在界面的表现性能上都较Java Application稍胜一筹。Servlet/JSP与ASP.NET是目前企业在“瘦客户端”应用的重点，两者都基于HTTP请求/响应模型，通过HTML浏览器页面完成用户交互。虽然ASP.NET声称在底层通过编译执行获得了相当高的处理速度和服务器方控件的浏览器自适应能力，但目前并没有这方面的硬性数据，很难据此而论高低。在缓存、状态优化等方面两者可谓是旗鼓相当。另一个与客户端应用相关的技术是ActiveX与Applet，从目前的趋势来看，它们在两个平台上的地位逐渐边缘化，也不为大多数企业所接受。

　　在中间层，分布式业务组件负责企业应用的商业逻辑部署。由于这些业务组件经常负责处理数据库连接、网络资源和线程等高昂的资源，所以一直是三层/多层架构的关键和企业应用的核心。J2EE的EJB是一个成熟的、得到业界广泛支持的大型企业级组件框架，而.NET组件则是建立在新型的COM+服务之上，两者在组件与操作系统的交互、客户端资源共享等方面都有很好的支持。.NET则通过元数据支持自描述性的组件开发、XCOPY部署以及多版本共存，无需注册表和描述文件，对企业客户有一定的吸引力。

　　在后端数据层，两个平台都为数据库连接量身定做了一套数据存取模型：J2EE的JDBC和.NET的ADO.NET，它们在支持传统SQL数据源的同时，也支持新型的XML数据源。这方面由于更多地涉及到具体的数据库产品，很难说那种数据模型更有优势。

　　两种架构的简单对照如表3.2.5-1所示。

　　比较项J2EE.NET

　　通信协议Remote Method Invocation over Internet InterOrb Protocol(RMI/IIOP)XML

　　编程语言Java C#，VB.NET，COBOL等

　　运行时环境Java Virtual Machine(JVM)Common Language Runtime(CLR)

　　客户端Java Swing Windows Forms

　　目录服务Java Naming and Directory Interface(JNDI)Active Directory Services Interface(ADSI)

　　数据访问Java Database Connection(JDBC)Java Connectors ADO.NET

　　异步消息处理Java Message Service(JMS)Microsoft Message Queue

　　表示层技术Servlets，Java Server Page(JSP)ASP.NET

　　中间层组件模型EJB，JavaBean COM+，COM

　　安全访问JAAS COM+Security Call Context

　　事物处理Java Transaction Server(JTS)Microsoft Distributed Transaction Coordinator(MS-DTC)

　　开发工具Borland JBuilder，IBM VisualAge等Visual Studio.NET

　　表3.2.5-1 J2EE与.NET架构比较

　　天津移动业务支撑应急系统需要保障系统的高稳定性和灵活扩展性，需要和业务支撑系统生产环境快速互联互通，同时在考虑保护投资的情况，本系统采用基于J2EE的多层技术架构。