电信转型期的EAI建设思路
钟健松
2004/05/14
经过几年不断的分拆整合，中国电信逐步稳定下来，开始静下心考虑企业的IT规划和改造。从2002年开始，中国电信请IBM进行IT战略规划（ITSP）咨询，确立了中国电信的IT战略远景和分阶段的实施举措。在ITSP的规划指导下，各省开始根据自身实际情况，着手自有IT系统的滚动建设和改造的工作。在ITSP的蓝图中，非常重要的一个核心就是要将原企业紧耦合的IT架构转变为构架在通用IT基础设施之上的松耦合架构。而在架构松散耦合化之后，各IT系统间的集成整合就变得非常关键和重要了。此时如果再采用传统的点对点接口方式来处理庞杂的系统交互，企业的IT系统间的联系就会变成复杂、难以维护的网状联接。正是基于这方面的考虑，EAI技术的引入，在电信转型期的系统改造过程中，就成为非常热门的话题。但EAI对于中国电信而言，无论是技术还是管理，都是一个全新的东西，新技术的引进，势必会带来很大的风险。
因此，对于EAI是否用，如何用，在每个省的具体系统建设中，存在着不同的思路。这里结合中国电信的各省实际情况，以及对当前EAI商用软件平台的研究，探讨在中国电信转型期间的EAI建设思路。
一、 EAI建设原则
电信运营企业是一个复杂的系统体系，它的运作是由多个既相对独立又互相联系的业务部门按照一定的流程协调进行，是人、网络和组织的集成。在企业的信息化发展过程中，根据不同业务环节的需要开发了对应的应用系统，并且和企业外部的多个系统需要进行互联，这是信息化发展的必然过程。随着市场环境的变化，企业经营理念随之更新，必然要求业务整合和流程调整。业务支撑系统必须随时适应这种变化，根据业务整合的要求而进行系统和应用的整合。因此，企业应用集成将是一项伴随业务整合、随着变化的节奏而提出的针对运营支撑系统的重要工作。
在具体实施电信企业应用集成时，需遵循如下原则：
·建立统一的系统交换集成平台，以取代系统间多对多的网状联接；
·数据的整合分析是应用集成的基础，同时需尽可能地建立统一编码体系；
·对新建或需要重新改造的系统，以统一规范的方式纳入应用集成框架（如：尽可能采用SOA架构）；
·对历史系统，提供多种接口方式，减少旧有系统的改造量；
·根据实际情况采用商用EAI平台软件，在不用商用EAI平台的情况下，利用EAI思想构建应用集成平台；
·在构建应用集成平台时，加强对应用集成平台的监控管理。
基于以上原则，在有效处理企业IT系统应用集成过程中，就必须要考虑如下问题：
·集成的架构和对遗留系统的处理；
·数据的集成和交换；
·应用集成平台的管理。
下面针对这些问题，逐一阐述。
二、 应用集成架构
在应用集成框架中，主要包含如下部分（见图1）。
·核心交换数据模型；
·应用集成逻辑处理组件；
·数据映射和转换；
·消息处理；
·事务控制；
·流程管理；
·服务提供等；
·面向不同系统的适配器；
·挂接在各个应用系统上的连接器；
·在应用集成平台上的运行监控模块；
·根据实际需要的统一用户管理。
通过以上应用集成平台的组成部分，将系统原来的多对多网状模型，转变为星型或云状的连接模型。并可通过开发部署对应的适配器和连接器，将电信企业不同的应用系统挂接到统一的应用集成平台上，形成开放式、松耦合的电信支撑IT架构。各IT系统不再需要进行点对点直联，不再需要知道与之交互系统的通信内部机制，而是统一通过应用集成平台总线和周边系统互联。
周边系统挂接到应用集成平台上有两种模式：
1. 原有系统能提供对外服务接口，满足系统间数据交互的需求；
2. 原有系统为封闭式系统，以传统的接口表、文件等方式和外界进行接口处理。
对于第一种模式，基本不需要对原有系统做任何形式的改造。只需在EAI平台针对该业务开发特定的适配器，该适配器调用业务系统提供的服务接口即可。协议可以是SOCKET、SOA、J2EE等。当然也可以在原有服务调用的基础上，面向EAI平台，进行封装一个connector agent，由connector agent对外与EAI平台通信，对内调用业务系统的API。
对于第二种模式，可在原业务系统侧开发封装一个connector agent，由connector agent对外与EAI平台通信，对内调用业务系统的API，或直接访问业务系统的数据库。在这种模式下，只要不涉及到功能的变化，同样也不需要对原有系统进行改动，只需由应用集成商在统一的应用集成架构下，实现原有接口方式即可。
需要注意的是，由于EAI的星型架构，增加了系统间交互的环节，必然导致了系统间交互的性能下降，因此不适合于量大且实时处理性高的系统交互。比如将缴费前移到客服系统，帐务系统只负责销帐的情况。在这种情况下，应考虑页面级的集成，或业务逻辑服务的直接调用。
三、应用集成数据分析
在前面应用集成建设原则中提到，数据分析是应用集成整合的基础。无论运营商采取何种集成方式，首先必须做好系统之间的整合数据分析。
应用集成数据分析包括如下内容：
·交互数据的内容；
·输入数据内容；
·输出数据内容；
·交换数据的方式；
·同步、异步；
·实时、定时；
·主动、被动；
·Socket、J2EE、JCA、File、Table、Web Service、Queue、Service；
·完整性校验；
·交换数据的存储；
·独立存储；
·实时获取；
·交换数据的封装；
·核心交换数据模型；
·交互动作；
·加解密。
1. 核心数据交换模型
在电信运营商支撑系统建设早期，各个应用系统的数据模型都是各自单独定义的，企业在信息整合和管理上难度极高。于是，在电信企业内部和软件市场上都流行了一阵，在电信企业内部整体实施统一数据模型。理论上它可以让所有的应用系统在同一个数据库上，协调管理同一组数据, 这样数据整合的问题便迎刃而解。 但在具体实施过程中，发现不但统一数据模型必须定义得像一个包罗万象的百科全书，各个应用系统也必须在性能上做巨大妥协来匹配对其来说并非最优的数据模型和存取方式。
而在有了EAI的建设思想后，这种硬性要求所有系统遵循和基于一套数据模型来开发和建设的思路改变了，转变成为各自的系统不需要做多大的变化，仍可以维持原有的数据模型，只是在吸取各系统输入和输出的数据需求，以及抽取他们的共性，形成一套核心的数据交换模型。这套核心的数据交换模型只是各个系统的交集，而不是所有系统数据的全集。核心数据交换模型采用面向对象的方式构建，其技术实现就是由一组通用的、跨应用的、与领域相关的业务对象即通用业务对象--GBO（Generic Business Object），实现包含了所有应用系统相互通讯所需要的信息。
形成了核心交换数据模型后，就可以在将网络传输的多对多简化成星型或云状的基础上，再进一步将数据的映射也从多对多的数据映射简化成多对一的数据映射。系统间的数据转换，不再需要像传统模式那样，需要考虑和多个系统的数据模型的对应和映射了，只需要考虑本系统数据模型和GBO的映射关系即可，再由GBO转换成对应系统的数据模型。这样一来，大大简化了数据维护的复杂度，增强了应用集成平台的可扩展性。
对于电信企业新建的系统，可以在规范上要求其数据模型尽可能地向核心交换数据模型方面靠，因为模型越相近，转换的工作量越小，转换的效率越高。
通用业务对象-GBO主要包含三大部分内容：
·业务对象BO的类型；
·业务对象BO的操作；
·业务对象BO的属性。
业务对象BO的类型，实际就是业务对象的类名，比如客户对象、产品对象、订单对象等。
业务对象BO的操作，是业务对象对外提供的服务形式接口，与通用业务对象的数据部分(Meta Data)一起构成与适配器进行交互的完整对象。通用业务对象在业务流程中承载实例化的业务数据，并通过支持的操作(Verb)对外，即通过适配器对应用系统提供服务。
业务对象BO的属性定义(Meta Data)实现共享信息和数据模型的EAI平台化，从而从数据层面完成电信业务模型在EAI平台上的相对独立性。GBO的属性定义支持多层次的描述，比如客户对象下还可以包含多个用户对象的描述。
2. 数据校验和异常处理
有交互接口的任意两个系统都必须对各自取/放的数据进行业务规则检查（比如三户规则中的一致性校验），保证己方提供和获取的数据的业务正确性。
对于新系统或同期改造系统，数据的校验工作可由各自系统加入校验模块完成。对于历史系统，可由EAI建设平台集成商在connector中考虑实现。
在数据校验出现异常时，提供多种异常数据的处理方式：
·异常数据的临时存储和恢复。比如三户数据（客户、用户、帐户）在接口传递时，由于网络或其他原因，导致用户数据的传递先于客户数据前达到。此时，该用户数据将无法通过一致性校验（用户对象的客户ID在系统中不存在）。出现这种情况时，不得随意将此异常数据丢失，而是需要将该数据存储到异常数据队列中，并定期检查，是否有正常的客户数据达到。一旦发现达到，则将原异常的用户数据拿出，一并处理。
·异常数据的告警。发现有异常数据时，应能以各种方式进行告警，以便能及时处理。
四、 EAI运行管理
中国电信正在进行EAI建设的几个试点，在实际运行过程中，遇到很多问题，但很多问题分析下来，技术的因素只是一方面，很多管理上的因素在很大程度上影响了EAI的实际运行。比如业务需求变化后，GBO需要进行扩充和改变，涉及到多方协调时，因管理组织不到位，从而制约了需求的响应程度。因此，为了让EAI平台达到可运行、可管理，必须重视如下两个方面。
1. 核心数据模型的管理
通用业务对象--GBO，实际上是一种整合的技巧和最佳实践经验。这种技巧不仅需要在技术上，规范整合关键的信息表达并优化信息交流的效率，而且要通过有效的管理机制为多边开发和维护过程提供组织上的保证。尽管GBO在很大程度上减少了多对多的复杂数据映射，但GBO不是万能的灵丹妙药。业务的变化，仍然会需要多方系统一定程度的变化，从而引发多方的协调工作。如果协调失灵，轻则延误工时，重则整个工程整合失调，必须返工。所以，有必要对于通用业务对象的定义和变更制定全套的管理程序，由一个既懂技术又通管理的跨部门跨系统集成商的组织来负责。该组织的职责包括：
·为各协作方制定提供通用业务对象管理守则；
·配合总体平台构架确定通用业务对象的技术框架；
·组织通用业务对象的需求分析和定义；
·保管通用业务对象的信息模型并将其版本化；
·注册和通用业务对象相关的数据转换模块；
·确保变更管理的及时性和一致性；
·提供和通用业务对象相关的品质保障。
2 . EAI平台的监控
由于EAI平台处于企业IT系统的核心地位，属于企业公用的IT基础设施，如果EAI平台出现问题，企业的IT系统就会变成一个个的信息孤岛。在辅以备份等各种手段的同时，EAI平台还需提供实时的图形化监视和控制界面，以便即时了解和控制EAI平台的运行。
五、 结语
EAI思想和技术的引用，在电信转型期间，给电信企业的IT系统改造和建设，提供了崭新的思路。但在建设EAI的过程中，不能是大家说EAI好，就跟风上EAI。必须根据实际情况认真分析，同时做好扎实的数据分析工作，以及打好周边配套的管理基础。在技术、数据、管理多个方面协同前进，才能收到EAI真正应有的效果。
作者供稿 原文刊登于中国计费网(www.billingchina.com)