1. 介紹
1.1. 本文目的
本文的目的在于針對中國電信行業(yè)EAI的建設(shè)，從技術(shù)層面提出幾點架構(gòu)性建議，供電信運營商在系統(tǒng)的規(guī)劃中進行參考。其中涉及的內(nèi)容是基于多年在電信業(yè)的經(jīng)驗進行陳述，同時注意到在這些關(guān)鍵的技術(shù)架構(gòu)方面，直接影響到電信運營商業(yè)務(wù)支撐系統(tǒng)的長遠規(guī)劃。
1.2. 范圍
本文包含以下主題：
·EAI技術(shù)路線
·電信共享信息/數(shù)據(jù)模型
·接口參考模型與適配器架構(gòu)
·電信業(yè)務(wù)流程模版
·流程補償機制的實現(xiàn)--保證交易的一致性
·EAI的高端解決方案--業(yè)務(wù)行為監(jiān)控(BAM)
·解決EAI性能瓶頸
·電信行業(yè)EAI項目管理實施經(jīng)驗
2. EAI技術(shù)路線
2.1. EAI技術(shù)概述
企業(yè)應(yīng)用集成(EAI)的核心是使用中間件連接企業(yè)應(yīng)用。有多種不同類型的中間件可以提供EAI的功能。在選擇EAI中間件時需注意以下的基本特征：
·通過中間件將不同的應(yīng)用連接起來，保證應(yīng)用的獨立性，在不需要修改應(yīng)用自身的業(yè)務(wù)邏輯的同時，又解決了數(shù)據(jù)共享問題。
·對核心共享業(yè)務(wù)數(shù)據(jù)模型的處理與支持。
·實現(xiàn)業(yè)務(wù)流程自動化。確保各個部門在采用不同的系統(tǒng)的同時可以協(xié)同完成同一個工作。
·使應(yīng)用開發(fā)變得簡單。中間件提供簡單易用的編程接口，不需要考慮網(wǎng)絡(luò)和操作系統(tǒng)的復(fù)雜性。所以使開發(fā)者將精力集中在業(yè)務(wù)邏輯的開發(fā)上，而不需要關(guān)心消息是如何傳遞的，中間件會來處理通信問題。
·支持應(yīng)用架構(gòu)的不斷變更。可以方便地重新配制以增加或去除系統(tǒng)而不會影響其它系統(tǒng)。
·能夠提供實時接口和批處理接口，能夠提供同步和異步接口;
·必須保證數(shù)據(jù)的安全，只有目的應(yīng)用可以讀取;
·性能和數(shù)據(jù)吞吐量必須足夠，并且具有靈活的可擴展性以適應(yīng)企業(yè)的發(fā)展;
·必須具備恢復(fù)機制，當(dāng)數(shù)據(jù)傳輸過程中發(fā)生連接中斷等異�？梢源_保數(shù)據(jù)的恢復(fù)。
·對流程管理提供預(yù)定義的通用模版與行業(yè)模版。
2.2. 五大集成模式
業(yè)界公認的集成解決方案由五個組成部分：
·應(yīng)用集成：通過HUB或總線架構(gòu)，實現(xiàn)應(yīng)用與應(yīng)用之間的連接，完成相關(guān)的數(shù)據(jù)路由與數(shù)據(jù)格式轉(zhuǎn)換。
·信息集成：實現(xiàn)數(shù)據(jù)集成，在異構(gòu)的數(shù)據(jù)源之間實現(xiàn)數(shù)據(jù)層的直接整合。
·流程整合管理：實現(xiàn)業(yè)務(wù)流程管理，包括工作流管理、自動化流程兩層面。
·人員整合：實現(xiàn)應(yīng)用用戶界面統(tǒng)一的接入與安全機制，利用門戶技術(shù)進行構(gòu)建。
·構(gòu)建整合：通過J2EE應(yīng)用服務(wù)器技術(shù)設(shè)計實現(xiàn)節(jié)點的應(yīng)用。
目前只有IBM可以提供全部五種解決方案。
2.3. 第四代EAI技術(shù)
在系統(tǒng)應(yīng)用集成領(lǐng)域，如下圖所示，有四個重要的發(fā)展階段：
第一代，手工接口。主要特征包括：涉及的應(yīng)用數(shù)量較少、利用文件交換、利用批處理導(dǎo)入、批處理非實時性、高額維護費用、缺乏重用性、缺乏靈活性。
第二代，基于消息的端到端接口。主要特征包括：應(yīng)用與接口的數(shù)量增加、異步消息、異構(gòu)平臺、專注傳輸與消息的可靠性、較快的集成周期。不足之處主要是：接口數(shù)量劇增且復(fù)雜、相應(yīng)的增加維護與支持、缺乏可重用性。
第三代，星型(Hub/Spoke)架構(gòu)。主要特征包括：基于消息的Hub架構(gòu)實現(xiàn)路由與格式轉(zhuǎn)換，替代端到端的設(shè)計、工作流開始產(chǎn)生并包含于Hub中、大數(shù)量的應(yīng)用需要數(shù)據(jù)同步、實時或準實時的數(shù)據(jù)交換出現(xiàn)、以應(yīng)用為中心的看法得到改變。不足之處主要是：對Hub、適配器、工作流的編程與管理較為昂貴，同時重用性較低。
第四代，EAI解決方案中心。主要特征包括：提供得到驗證的行業(yè)業(yè)務(wù)流程模版庫，而不是從空白開始建起、提供一個為未來的業(yè)務(wù)與IT流程發(fā)展的系統(tǒng)平臺。提供共享數(shù)據(jù)模型實現(xiàn)機制、業(yè)務(wù)流程獨立于應(yīng)用、實時的客戶驅(qū)動流程成為通用模式、由業(yè)務(wù)分析員設(shè)計的工作流驅(qū)動Hub與應(yīng)用、遵循企業(yè)神經(jīng)系統(tǒng)(ENS)模式(Gartner Group)、快速的設(shè)計、開發(fā)、提交與維護、較高的重用性、定制化的組件得到普遍認可。
2.4. 技術(shù)方案分期實施在技術(shù)實施中，可針對項目的實際情況，分階段采用EAI的不同技術(shù)，通常分為兩類：
·部分業(yè)務(wù)采用EAI技術(shù)，其它部分根據(jù)此部分的實施結(jié)果來確定采用的技術(shù)路線，總結(jié)展開EAI對業(yè)務(wù)的覆蓋范圍。此類模式通常適合在原有系統(tǒng)基礎(chǔ)上進行EAI的改造。
·首先采用EAI的部分技術(shù)，特別是業(yè)務(wù)流程管理方面，而不是對EAI的全方位技術(shù)普遍采用。通常對工作流的實施可以放在后期執(zhí)行。此類模式適合于新建業(yè)務(wù)系統(tǒng)的情況。
3. 電信共享信息/數(shù)據(jù)(SID)模型
3.1. 信息/數(shù)據(jù)共享介紹
什么是共享信息/數(shù)據(jù)?在NGOSS中使用一個簡單的信息模型-共享信息和數(shù)據(jù)模型對數(shù)據(jù)進行定義和模型，即對所管理的數(shù)據(jù)的屬性、操作和相互間的交互進行描述。共享信息和數(shù)據(jù)模型的目的是對信息和數(shù)據(jù)進行共享和管理。因此，該模型通過多種視角對整個NGOSS系統(tǒng)中不同應(yīng)用系統(tǒng)的領(lǐng)域信息進行描述，包括業(yè)務(wù)視角、系統(tǒng)視角、實現(xiàn)視角和實時運行視角。業(yè)務(wù)角度是從基礎(chǔ)的業(yè)務(wù)需求中確定合約組件，系統(tǒng)角度則提供了合約組件的詳細內(nèi)容。在NGOSS中，從業(yè)務(wù)視角和系統(tǒng)視角對共享信息和數(shù)據(jù)進行了描述。這些信息通過合約組件在NGOSS系統(tǒng)中共享和重用，當(dāng)合約組件所需要的信息格式與通用的數(shù)據(jù)描述不一致時，需要將合約組件中的信息轉(zhuǎn)換成共享信息和數(shù)據(jù)模型中定義的標準信息。
3.2. 從不同視角去看共享信息/數(shù)據(jù)
如圖，從業(yè)務(wù)視角上看共享的數(shù)據(jù)和信息是指對業(yè)務(wù)實體的定義和相關(guān)屬性的定義，它確定了業(yè)務(wù)系統(tǒng)對共享數(shù)據(jù)和信息的需求;而系統(tǒng)視角則從系統(tǒng)角度出發(fā)，通過對業(yè)務(wù)實體的靜態(tài)和動態(tài)分析使用邏輯模型的方式對數(shù)據(jù)和信息進行了更深入的描述;而一個實現(xiàn)的視角則不僅將邏輯模型變成可以真正實施的物理模型，而且可以幫助我們驗證所設(shè)計的共享數(shù)據(jù)和信息模型是否能夠真正滿足業(yè)務(wù)的需求;最后，共享的數(shù)據(jù)和信息通過運行在各個合約組件中進行共享。
在企業(yè)范圍內(nèi)，建立企業(yè)數(shù)據(jù)模型至關(guān)重要，屬于企業(yè)技術(shù)的數(shù)據(jù)架構(gòu)的核心內(nèi)容之一。由于同樣的數(shù)據(jù)類型有不同的數(shù)據(jù)結(jié)構(gòu)，要找出具體的數(shù)據(jù)結(jié)構(gòu)適合所有應(yīng)用幾乎是不可能。所以，不靈活的企業(yè)實體關(guān)系數(shù)據(jù)模型沒有太大的使用價值。企業(yè)級的數(shù)據(jù)模型應(yīng)該是可以指導(dǎo)開發(fā)邏輯數(shù)據(jù)模型的工具。在建立好企業(yè)數(shù)據(jù)模型后，如何將數(shù)據(jù)模型在企業(yè)的系統(tǒng)平臺上承載起來，是一個現(xiàn)實問題。如下圖所示，EAI平臺是企業(yè)內(nèi)穩(wěn)定的架構(gòu)部分，同時也是溝通企業(yè)各個應(yīng)用系統(tǒng)的核心，因此將定義的企業(yè)數(shù)據(jù)模型承載到EAI平臺將是一個較為理想的解決方案。一方面，避免了定義好的企業(yè)數(shù)據(jù)模型被束之高閣，有名無實，失去應(yīng)用的價值;另一方面，EAI是擴充能力較強的平臺，可以維持較好的數(shù)據(jù)模型的動態(tài)演進。
3.3. 通用業(yè)務(wù)對象(GBO)
通用業(yè)務(wù)對象是IBM WBI(WebSphere Business Integration)在集成電信應(yīng)用系統(tǒng)時所定義的，是為了實現(xiàn)應(yīng)用系統(tǒng)之間交互過程中的數(shù)據(jù)映射，從而滿足數(shù)據(jù)共享的需求。
系統(tǒng)集成就是把多個應(yīng)用系統(tǒng)整合在一起，每個應(yīng)用系統(tǒng)通常會根據(jù)自己的需求來組織數(shù)據(jù)，這就造成相同的信息在不同的應(yīng)用系統(tǒng)有不同的表現(xiàn)形式，同一個實體可能在應(yīng)用系統(tǒng)A中采用簡單的結(jié)構(gòu)，而在應(yīng)用系統(tǒng)B中使用復(fù)雜的結(jié)構(gòu)，這給系統(tǒng)集成帶來很大的困難。如果采用點到點的數(shù)據(jù)映射，系統(tǒng)集成的復(fù)雜性隨應(yīng)用系統(tǒng)的增多而指數(shù)級增大，而采用系統(tǒng)集成中間件就可以減少復(fù)雜性。系統(tǒng)集成中間件通過通用業(yè)務(wù)對象來實現(xiàn)數(shù)據(jù)在各個應(yīng)用系統(tǒng)間的傳輸和共享。
通用業(yè)務(wù)對象是一組通用的、跨應(yīng)用的、與領(lǐng)域相關(guān)的業(yè)務(wù)對象，它包含了所有應(yīng)用系統(tǒng)相互通訊所需要的信息。各個應(yīng)用系統(tǒng)通過數(shù)據(jù)映射把它們內(nèi)部的數(shù)據(jù)信息轉(zhuǎn)換成通用業(yè)務(wù)對象或反過來把通用業(yè)務(wù)對象轉(zhuǎn)換成它們內(nèi)部的數(shù)據(jù)格式，從而解決了不同應(yīng)用系統(tǒng)之間的數(shù)據(jù)模型匹配問題。當(dāng)應(yīng)用系統(tǒng)變化時，只需提供新的數(shù)據(jù)映射使其能對應(yīng)到通用業(yè)務(wù)對象即可，不需要對系統(tǒng)集成中間件進行修改。通用業(yè)務(wù)對象最大的好處是使系統(tǒng)集成中間件的業(yè)務(wù)處理邏輯與應(yīng)用系統(tǒng)相對獨立。
圖1描述了在系統(tǒng)集成中使用通用業(yè)務(wù)對象的工作流程，具體描述如下：
(1)應(yīng)用系統(tǒng)A把需要傳送給應(yīng)用系統(tǒng)B的數(shù)據(jù)信息組織成應(yīng)用A業(yè)務(wù)對象。
(2)適配器A把應(yīng)用A業(yè)務(wù)對象映射到通用業(yè)務(wù)對象。
(3)系統(tǒng)集成中間件根據(jù)事先定義的處理邏輯把通用業(yè)務(wù)對象傳送給適配器B.
(4)適配器B把通用業(yè)務(wù)對象映射到應(yīng)用B業(yè)務(wù)對象。
圖1 在系統(tǒng)集成中使用通用業(yè)務(wù)對象的工作流程
適配器主要用來完成應(yīng)用相關(guān)業(yè)務(wù)對象與通用業(yè)務(wù)對象之間的映射，它可以通過關(guān)系對應(yīng)表自動完成映射。如圖2所示，映射處理器根據(jù)關(guān)系對應(yīng)表把應(yīng)用業(yè)務(wù)對象轉(zhuǎn)換成通用業(yè)務(wù)對象或反過來把通用業(yè)務(wù)對象轉(zhuǎn)換成通用業(yè)務(wù)對象。
圖2 適配器的工作模型
3.4. 共享信息/數(shù)據(jù)模型平臺機制
數(shù)據(jù)模型不是包括各應(yīng)用系統(tǒng)中的所有的數(shù)據(jù)元素，而是關(guān)于需要共享和可視的數(shù)據(jù)的模型。數(shù)據(jù)模型是以對各應(yīng)用通用的并以行業(yè)標準詞匯表達。例如自動化的業(yè)務(wù)流程，是通過通用業(yè)務(wù)對象(GBO)及其相關(guān)的活動表達的，應(yīng)用把這些交易轉(zhuǎn)換并反映到應(yīng)用自身的數(shù)據(jù)庫中。
WBI提供通用業(yè)務(wù)對象(GBO)的技術(shù)，該技術(shù)為建立數(shù)據(jù)模型提供了平臺機制，使用戶可以在此平臺上構(gòu)建通用業(yè)務(wù)對象，并與整個EAI平臺的各模塊協(xié)調(diào)融合。WBI同時提供了電信行業(yè)的通用業(yè)務(wù)對象模型，該模型是參照eTOM/TOM模型進行構(gòu)建，并提供了程序代碼基礎(chǔ)的模版。
WBI提供了完整的機制來支持通用業(yè)務(wù)對象(GBO)。同時包含GUI的工具生成、維護通用業(yè)務(wù)對象(GBO)。
圖3 數(shù)據(jù)架構(gòu)與流程架構(gòu)
如圖3所示，利用WBI提供完整的技術(shù)架構(gòu)模式，來完整的把業(yè)務(wù)承載平臺的數(shù)據(jù)架構(gòu)、業(yè)務(wù)流程架構(gòu)有機的協(xié)同起來，利用其內(nèi)在的機制完成整個架構(gòu)的實現(xiàn)。
4. 接口參考模型與適配器架構(gòu)
4.1. 設(shè)計理由和風(fēng)險
適配器完成的功能是實現(xiàn)應(yīng)用系統(tǒng)與EAI HUB之間的連接接口，主要包括數(shù)據(jù)與通訊兩個層面。在適配器設(shè)計與選型方面，EAI技術(shù)提供的方案有多種形式，根據(jù)不同的情況作不同的選擇。下面對常用的適配器類型進行分析。
基于數(shù)據(jù)庫的接口與適配器
應(yīng)用系統(tǒng)對外提供的接口是應(yīng)用數(shù)據(jù)庫，適配器通過對應(yīng)用數(shù)據(jù)庫的操作來實現(xiàn)EAI與應(yīng)用間的交互。此類接口是應(yīng)用系統(tǒng)可對外提供的最底層的接口類型，允許適配器直接訪問應(yīng)用的數(shù)據(jù)。針對此方式，盡管這也是常用方式之一，但其中有很多嚴重的不足。
使用數(shù)據(jù)作為應(yīng)用的接口，意味著將數(shù)據(jù)的結(jié)構(gòu)體設(shè)計暴露出來。當(dāng)應(yīng)用發(fā)生改變時，通常需要重新分析、甚至改變此數(shù)據(jù)接口。當(dāng)應(yīng)用系統(tǒng)的數(shù)據(jù)改變時，為了觸發(fā)外部應(yīng)用，通常需要使用基于應(yīng)用數(shù)據(jù)庫的外部觸發(fā)器或使用低效的循環(huán)查詢策略，這不是一個"干凈"的解決方案，外部應(yīng)用對維護數(shù)據(jù)的完整性也將負有責(zé)任，為此需要理解需要集成的應(yīng)用系統(tǒng)的結(jié)構(gòu)。總之，其結(jié)果將是一個難以維護的交錯系統(tǒng)。
基于API的接口與適配器
應(yīng)用軟件，通常提供內(nèi)置于軟件庫的API，作為與應(yīng)用系統(tǒng)交互的接口。相對數(shù)據(jù)庫接口而言，此類接口是一個更為"干凈"的解決方案。其問題是相對某種平臺，如操作系統(tǒng)、編程語言，此API庫可能不存在，為解決此問題，需要開發(fā)底層的代碼并進行長期的維護。同時當(dāng)支撐其運行的產(chǎn)品進行升級時，通常需要對此API進行升級以保證其兼容。另外，基于API技術(shù)，當(dāng)一用系統(tǒng)有事件發(fā)生時，一般難以提供自動通知功能，需要外部系統(tǒng)進行低效的循環(huán)查詢。
基于組件的接口與適配器
基于J2EE與CORBA的分布式對象技術(shù)，使應(yīng)用系統(tǒng)的接口有較好的可移植性。此類接口，可以屏蔽操作系統(tǒng)、編程語言的不同。此類接口屬于緊耦合模式，屬于發(fā)展中的技術(shù)，由于應(yīng)用系統(tǒng)本身需要提供組件接口，在實際應(yīng)用中限制了其應(yīng)用。
基于消息隊列的接口與適配器
應(yīng)用系統(tǒng)對外交互的接口為消息隊列，同時提供消息/數(shù)據(jù)傳輸?shù)目煽啃员Ｕ�。業(yè)界領(lǐng)先的消息中間件同時提供同步、異步兩種通訊方式。使用消息隊列，消息系統(tǒng)可以管理很多通訊細節(jié)。此種接口方式為典型松耦合模式，是EAI技術(shù)普遍使用的方式之一，可以實現(xiàn)接口的重用能力。
4.2. 主流的的實現(xiàn)方式
分析各電信運營商EAI平臺的建設(shè)情況，需要接入的業(yè)務(wù)應(yīng)用系統(tǒng)，如：綜合客服系統(tǒng)、資源管理系統(tǒng)、計費帳務(wù)系統(tǒng)，采用各自的應(yīng)用服務(wù)器或交易中間件，具有不同的架構(gòu)模式，對外提供不同的接口方式。在這種狀況下，不利于整體系統(tǒng)的統(tǒng)一維護、后期升級改造，以及今后其他業(yè)務(wù)系統(tǒng)的接入。在此綜合考慮以下幾方面關(guān)鍵因素，EAI業(yè)界推薦采用基于消息隊列的適配器，如下圖所示。
說明：圖中藍色區(qū)域為重用體系，對應(yīng)用連接提供統(tǒng)一接口。
采用基于消息的適配器比較其它方式有較為明顯的優(yōu)勢，特別是對整體架構(gòu)的規(guī)劃與實施有較大的參考作用，隨著系統(tǒng)承載平臺的逐步完善，此架構(gòu)會有更為顯著的生命力與綜合優(yōu)勢。下面簡單對此進行陳述如下：
·提供統(tǒng)一的接口模式，最大程度地滿足IT規(guī)劃的總體要求，保障最大的ROI，在新系統(tǒng)構(gòu)建之出至關(guān)重要。
·提供基于松耦合的接口方式，提高整個系統(tǒng)承載平臺的可重用性，將系統(tǒng)的重用范圍從流程擴展到接口層面。
·提高整體系統(tǒng)的可維護性，統(tǒng)一接口技術(shù)，并逐漸標準化，避免采用多種不同技術(shù)規(guī)范。一方面使承載平臺維護人員專注在業(yè)界領(lǐng)先的標準技術(shù)上;另一方面便于系統(tǒng)的統(tǒng)一升級換代。
·基于消息隊列的技術(shù)是一種成熟、穩(wěn)定、開放的技術(shù)，開發(fā)維護簡單、便利的技術(shù)手段，利于在實際項目中進行實施，降低項目的風(fēng)險。
4.3. 對實現(xiàn)技術(shù)的要求
為實現(xiàn)此類統(tǒng)一架構(gòu)，對消息中間件(隊列)提出如下基本要求：
·支持多種操作系統(tǒng)。
·提供包括C、C++、Java、ActiveX等多種語言的API接口，從而實現(xiàn)與不同編程語言的應(yīng)用系統(tǒng)連接。
·穩(wěn)定可靠，保證數(shù)據(jù)傳輸一次而且只有一次。
·高性能。
5. 電信業(yè)務(wù)流程模版
提供行業(yè)流程模版或通用模版是第四代EAI解決方案的特征。通過參照模版，一方面可以縮短開放周期、提高代碼質(zhì)量，另一方面可以規(guī)范業(yè)務(wù)流程，實現(xiàn)流程優(yōu)化。
IBM WBI提供遵循TMF規(guī)范的業(yè)務(wù)流程模版及通用模版。對業(yè)務(wù)流程模版的提供方式，一方面是提供文檔，更重要的是提供基于IBM EAI的代碼實現(xiàn)。
在IBM EAI解決方案中，針對電信行業(yè)提供了基于TMF規(guī)范的業(yè)務(wù)流程模版，在此僅列表說明：
用例(業(yè)務(wù)范圍)：
1. Customer Order Handling
2. Customer Service Configuration and Activation
3. Resource Provisioning and Allocation
4. Customer Billing Management
5. Customer Problem Handling
6. Product Development and Retirement
針對以上6個用例，提供基于產(chǎn)品的流程模版。對每一用例提供一類工作流模版，每一工作流模版又與對應(yīng)的自動化協(xié)調(diào)流程相配合。
6. 流程的交易補償?shù)膶崿F(xiàn)
當(dāng)一組流程需要與不同的應(yīng)用系統(tǒng)發(fā)生交易時，如果其中之一出現(xiàn)失敗，則需要進行交易在流程層面的回滾。在EAI領(lǐng)域，此類技術(shù)稱之為流程的交易補償，是保證交易與數(shù)據(jù)一致性的重要手段。IBM EAI提供流程的交易補償機制，只需要定義相關(guān)的補償節(jié)點。
7. EAI的高端解決方案--業(yè)務(wù)行為監(jiān)控(BAM)
BAM(Business Activity Monitoring)是EAI技術(shù)當(dāng)前發(fā)展最為快速、業(yè)務(wù)高級優(yōu)化最有效的手段，其宗旨在于實時獲得業(yè)務(wù)流程運行的狀態(tài)，自動提供客觀分析報告，以優(yōu)化、改進業(yè)務(wù)流程，其改進包括技術(shù)層面，也包括人員、管理層面。從技術(shù)層面分析，包括流程建模的仿真，業(yè)務(wù)運行中各節(jié)點的分析反饋，業(yè)務(wù)報表生成。
提供能力：IBM可提供統(tǒng)一技術(shù)的適合不同操作系統(tǒng)、不同編程語言的適配器。
BEA：從應(yīng)用層面，只能提供Java的實現(xiàn)技術(shù)，對C無此能力(通過Gateway轉(zhuǎn)換)。
1. 解決EAI性能瓶頸
重要性：性能是困擾EAI在電信實施的重要問題。
提供能力：IBM WBI的性能是BEA技術(shù)的10-100倍，可提供專業(yè)測試報告
IBM EAI產(chǎn)品包提供了一整套的產(chǎn)品用來定義、分析和監(jiān)控您的業(yè)務(wù)流程。在EAI的建設(shè)、試運行、生產(chǎn)環(huán)境不同的階段，針對業(yè)務(wù)流程都需要提供實時的分析，報告和模擬仿真功能。
8. 解決EAI性能瓶頸
采用EAI中間件技術(shù)，關(guān)鍵業(yè)務(wù)流程都通過EAI HUB來實現(xiàn)，因此系統(tǒng)的性能對于電信行業(yè)是一個關(guān)鍵因素。其中工作負載集中體現(xiàn)消息中間件與EAI在路由、格式轉(zhuǎn)換方面(Message Broker)。另外EAI系統(tǒng)對內(nèi)存的分配管理技術(shù)、對高峰值的內(nèi)存數(shù)據(jù)報的處理理論與技術(shù)、對高峰值的可靠傳輸?shù)谋Ｕ侠碚撆c技術(shù)多至關(guān)重要。這些將在實際項目的實施中至關(guān)重要，也是一些不成熟的EAI廠家在細節(jié)層面有意忽略(或根本沒有意識)之處。
IBM EAI技術(shù)在業(yè)界的性能處理能力一直處于領(lǐng)先地位，這也是基于多年的產(chǎn)品發(fā)展日益成熟起來的。
9. 電信行業(yè)EAI項目管理實施經(jīng)驗
EAI技術(shù)被定位為企業(yè)的神經(jīng)系統(tǒng)，是企業(yè)IT的架構(gòu)基礎(chǔ)。因此在業(yè)界的共識是，EAI的采用一方面是衡量某類產(chǎn)品的成熟度、可用性;更重要的是用戶在選擇一個長期的合作伙伴。同時我們必須面對的是EAI這種復(fù)雜技術(shù)的實施的風(fēng)險。從全球角度來講，只有50%的成功率，重要原因在于技術(shù)的復(fù)雜度與實施能力。
從國內(nèi)EAI項目的實施狀況來看，考慮到技術(shù)的復(fù)雜度與實施經(jīng)驗，目前主要采用與原廠商合作或全球知名的IT咨詢服務(wù)商合作來進行。
10. 總結(jié)
以上論及內(nèi)容是EAI技術(shù)的基礎(chǔ)與主流，并未涉及產(chǎn)品層面的細枝末節(jié)，對于電信運營商通盤考慮EAI的選型應(yīng)有一定的借鑒作用。 
