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