因此，對于EAI是否用，如何用，在每個省的具體系統建設中，存在著不同的思路。這里結合中國電信的各省實際情況，以及對當前EAI商用軟件平臺的研究，探討在中國電信轉型期間的EAI建設思路。
一、 EAI建設原則
電信運營企業(yè)是一個復雜的系統體系，它的運作是由多個既相對獨立又互相聯系的業(yè)務部門按照一定的流程協調進行，是人、網絡和組織的集成。在企業(yè)的信息化發(fā)展過程中，根據不同業(yè)務環(huán)節(jié)的需要開發(fā)了對應的應用系統，并且和企業(yè)外部的多個系統需要進行互聯，這是信息化發(fā)展的必然過程。隨著市場環(huán)境的變化，企業(yè)經營理念隨之更新，必然要求業(yè)務整合和流程調整。業(yè)務支撐系統必須隨時適應這種變化，根據業(yè)務整合的要求而進行系統和應用的整合。因此，企業(yè)應用集成將是一項伴隨業(yè)務整合、隨著變化的節(jié)奏而提出的針對運營支撐系統的重要工作。
在具體實施電信企業(yè)應用集成時，需遵循如下原則：
·核心交換數據模型；
通過以上應用集成平臺的組成部分，將系統原來的多對多網狀模型，轉變?yōu)樾切突蛟茽畹倪B接模型。并可通過開發(fā)部署對應的適配器和連接器，將電信企業(yè)不同的應用系統掛接到統一的應用集成平臺上，形成開放式、松耦合的電信支撐IT架構。各IT系統不再需要進行點對點直聯，不再需要知道與之交互系統的通信內部機制，而是統一通過應用集成平臺總線和周邊系統互聯。
周邊系統掛接到應用集成平臺上有兩種模式：
對于第一種模式，基本不需要對原有系統做任何形式的改造。只需在EAI平臺針對該業(yè)務開發(fā)特定的適配器，該適配器調用業(yè)務系統提供的服務接口即可。協議可以是SOCKET、SOA、J2EE等。當然也可以在原有服務調用的基礎上，面向EAI平臺，進行封裝一個connector agent，由connector agent對外與EAI平臺通信，對內調用業(yè)務系統的API。
對于第二種模式，可在原業(yè)務系統側開發(fā)封裝一個connector agent，由connector agent對外與EAI平臺通信，對內調用業(yè)務系統的API，或直接訪問業(yè)務系統的數據庫。在這種模式下，只要不涉及到功能的變化，同樣也不需要對原有系統進行改動，只需由應用集成商在統一的應用集成架構下，實現原有接口方式即可。
需要注意的是，由于EAI的星型架構，增加了系統間交互的環(huán)節(jié)，必然導致了系統間交互的性能下降，因此不適合于量大且實時處理性高的系統交互。比如將繳費前移到客服系統，帳務系統只負責銷帳的情況。在這種情況下，應考慮頁面級的集成，或業(yè)務邏輯服務的直接調用。
三、應用集成數據分析
在前面應用集成建設原則中提到，數據分析是應用集成整合的基礎。無論運營商采取何種集成方式，首先必須做好系統之間的整合數據分析。
應用集成數據分析包括如下內容：
1. 核心數據交換模型
而在有了EAI的建設思想后，這種硬性要求所有系統遵循和基于一套數據模型來開發(fā)和建設的思路改變了，轉變成為各自的系統不需要做多大的變化，仍可以維持原有的數據模型，只是在吸取各系統輸入和輸出的數據需求，以及抽取他們的共性，形成一套核心的數據交換模型。這套核心的數據交換模型只是各個系統的交集，而不是所有系統數據的全集。核心數據交換模型采用面向對象的方式構建，其技術實現就是由一組通用的、跨應用的、與領域相關的業(yè)務對象即通用業(yè)務對象--GBO（Generic Business Object），實現包含了所有應用系統相互通訊所需要的信息。
形成了核心交換數據模型后，就可以在將網絡傳輸的多對多簡化成星型或云狀的基礎上，再進一步將數據的映射也從多對多的數據映射簡化成多對一的數據映射。系統間的數據轉換，不再需要像傳統模式那樣，需要考慮和多個系統的數據模型的對應和映射了，只需要考慮本系統數據模型和GBO的映射關系即可，再由GBO轉換成對應系統的數據模型。這樣一來，大大簡化了數據維護的復雜度，增強了應用集成平臺的可擴展性。
對于電信企業(yè)新建的系統，可以在規(guī)范上要求其數據模型盡可能地向核心交換數據模型方面靠，因為模型越相近，轉換的工作量越小，轉換的效率越高。
通用業(yè)務對象-GBO主要包含三大部分內容：
業(yè)務對象BO的類型，實際就是業(yè)務對象的類名，比如客戶對象、產品對象、訂單對象等。
業(yè)務對象BO的操作，是業(yè)務對象對外提供的服務形式接口，與通用業(yè)務對象的數據部分(Meta Data)一起構成與適配器進行交互的完整對象。通用業(yè)務對象在業(yè)務流程中承載實例化的業(yè)務數據，并通過支持的操作(Verb)對外，即通過適配器對應用系統提供服務。
業(yè)務對象BO的屬性定義(Meta Data)實現共享信息和數據模型的EAI平臺化，從而從數據層面完成電信業(yè)務模型在EAI平臺上的相對獨立性。GBO的屬性定義支持多層次的描述，比如客戶對象下還可以包含多個用戶對象的描述。
2. 數據校驗和異常處理
對于新系統或同期改造系統，數據的校驗工作可由各自系統加入校驗模塊完成。對于歷史系統，可由EAI建設平臺集成商在connector中考慮實現。
在數據校驗出現異常時，提供多種異常數據的處理方式：
·異常數據的臨時存儲和恢復。比如三戶數據（客戶、用戶、帳戶）在接口傳遞時，由于網絡或其他原因，導致用戶數據的傳遞先于客戶數據前達到。此時，該用戶數據將無法通過一致性校驗（用戶對象的客戶ID在系統中不存在）。出現這種情況時，不得隨意將此異常數據丟失，而是需要將該數據存儲到異常數據隊列中，并定期檢查，是否有正常的客戶數據達到。一旦發(fā)現達到，則將原異常的用戶數據拿出，一并處理。
·異常數據的告警。發(fā)現有異常數據時，應能以各種方式進行告警，以便能及時處理。
四、 EAI運行管理
中國電信正在進行EAI建設的幾個試點，在實際運行過程中，遇到很多問題，但很多問題分析下來，技術的因素只是一方面，很多管理上的因素在很大程度上影響了EAI的實際運行。比如業(yè)務需求變化后，GBO需要進行擴充和改變，涉及到多方協調時，因管理組織不到位，從而制約了需求的響應程度。因此，為了讓EAI平臺達到可運行、可管理，必須重視如下兩個方面。
1. 核心數據模型的管理
·為各協作方制定提供通用業(yè)務對象管理守則；
2 . EAI平臺的監(jiān)控
五、 結語
EAI思想和技術的引用，在電信轉型期間，給電信企業(yè)的IT系統改造和建設，提供了嶄新的思路。但在建設EAI的過程中，不能是大家說EAI好，就跟風上EAI。必須根據實際情況認真分析，同時做好扎實的數據分析工作，以及打好周邊配套的管理基礎。在技術、數據、管理多個方面協同前進，才能收到EAI真正應有的效果。
作者供稿 原文刊登于中國計費網(www.billingchina.com)
