1 概述
企業服務總線（Enterprise Service Bus，縮寫 ESB），是SOA面向服務架構的骨干，在完成服務的接入、服務間的通信和交互基礎上，提供安全性、可靠性、 高性能的服務能力保障。采用 SOA 架構，基於ESB總線進行企業異構應用集成，可以有效降低應用系統、各個組件及相關技術的耦合度，消除應用系統點對點集成瓶頸，降低集成開發難度，提高復用，增進系統開發和運行效率，便於業務系統靈活重構、敏捷適應業務及流程變化。
本文對企業服務總線ESB集成項目中，基於AEAI ESB實現異構系統集成的相關規范、標准進行闡述、明確，為項目開展以及后續完善擴展提供技術參考和依據。
2 功能特點
AEAI ESB作為數通暢聯公司的企業應用集成產品，主要用來實現異構系統（如：不同的數據庫、消息中間件、ERP或CRM等）之間的資源整合，實現互連互通、數據共享、業務流程協調統一等功能，構建靈活可擴展的分布式企業應用。
相比傳統的企業應用集成軟件平台，AEAI ESB是一個全新的符合SOA架構的應用服務整合平台，是基於大量集成實踐經驗不斷完善、用於構建可管理、可擴展及經濟高效的EAI技術解決方案。
圖1.基於AEAI ESB總線的企業應用集成模式
AEAI ESB提供了從企業應用集成的設計、開發、部署，到運行、管理、監控各個生命周期階段的工具。它提供的圖形化、拖拽式開發方式，可以快速創建可擴展不同類型的數據（應用）集成流程，並全面支持服務及服務常用形式Web Service，簡化了服務的創建與封裝，並能夠使用戶靈活地編排服務，以滿足不斷變化地業務需要和業務處理流程。
AEAI ESB基於JavaEE體系構建，主要包含三個模塊：服務器ESBServer、設計器ESBDesigner、管理控制中心。ESBServer是AEAI ESB的運行環境，管理控制中心則是部署在ESBServer的Java Web應用，基於開發平台構建的。ESBDesigner是基於Eclipse Plugin開發的圖形化、拖拽式的設計Web服務、消息流程的構建工具。AEAI ESB主要功能及特點如下：
- 基於開放標准，高度可擴展
AEAI ESB的技術架構及實現基於開放式標准，支持SOAP、WSDL等規范，基於開放式標准如：SOAP、JDBC、JMS、JavaWS、JavaMail、Http等，便於系統遷移以及將來擴展。
- 支持企業級服務質量
支持的企業級服務質量，包括消息安全、失敗恢復、狀態診斷、服務管理、服務審計及消息可靠傳輸、事務的完整性等，提供數據交換過程和數據的跟蹤能力。
- 提供數據格式轉換功能
提供圖形可視化的異構數據格式轉換映射工具，能夠將數據從一種格式簡便快速地轉換成另一種格式。輸入數據和輸出數據可進行不同格式間的轉換,從而可快速集成異構應用。
- 支持多種服務/組件通訊方式
支持多種服務/組件通訊方式，如同步和異步等，用戶可以按照自己的需要，靈活定義通訊方式。
- 提供對Web Service的完整支持
既支持不同外系統提供的Web Service訪問、服務代理接入，又能夠將現有業務應用封裝成Web Service供復用。支持Web Service常用標准協議，如SOAP、WSDL等，同時支持Web服務的編排及不同粒度的服務封裝，便於創建松耦合及可復用的面向服務架構
- 監控與管理
提供了基於瀏覽器的管理控制台，能夠對監控節點、服務、組件及業務流程進行狀態查詢和監控管理。對監控、跟蹤和日志具有平台級的支持,還提供遠程跟蹤調試功能。
- 支持集中管理及分布部署
支持分布式應用及部署，開發的服務、組件及業務流程，可以分布式部署到網絡上的多個邏輯節點，實現分布式運算和應用，支持水平以及垂直擴展，滿足性能擴展需要。支持遠程增量部署，大大降低部署成本。
3 數據標准
3.1 信息采集規范
數據總線平台的建設與應用並非是不關注業務，數據的隨意流通。數據交換需要規范業務系統間交換的屬性。信息采集規范就是指規范業務系統數據采集交換的方式、頻率、加工策略等規范。例如：哪些業務系統的哪些數據要實現實時交換、哪些是觸發交換；采集的數據是全量、增量還是根據某些條件進行交換；是通過數據庫采集、文件采集還是服務獲取等。
3.2 數據內容規范
數據內容規范指數據交換過程中數據清洗、轉換的標准。要制定重復數據的基准、數據轉換的基准、清洗的規則、共享的方式。例如:不同單位的業務系統可能存在對某段同樣語義的描述信息，但是因業務系統開發商不同導致其信息存儲的格式和內容會有區別，再其他業務系統需要這條數據的時候，此數據應該從哪個業務系統獲取，或者是獲取出來進行比對、分析、處理之后再交換到其他業務系統。
3.3 數據維護規范
數據交換的需求可能是多種多樣，包括臨時的需求和長期的需求。長期需求可能是建立綜合數據庫、數據中心或是把A系統業務庫中的數據長期交換到B系統的業務庫中，因此需要制定數據維護的標准，定義不同系統的不同業務數據采用數據維護的方式。
例如：財務系統業務數據要保留交換的歷史數據，且采用時間戳的方式增量維護；OA系統業務數據僅保留3個月的數據，且采用觸發器的方式交換；人力資源業務數據采用主動到數據源端抓取業務數據的方式維護自身業務數據等等。
4 標准規范
4.1 集成開發規范
- 創建工程按照集成需求業務進行划分，格式為“公司名”+“產品”+”業務名”，例如：AeaiESBHr、AeaiESBCrm
- 工程下的目錄按照服務提供方（系統）進行划分，如果只有相同的服務提供方，也需要創建目錄進行划分；
- 流程名采用匈牙利命名法（在幾個字母聯合的時候，首字母大寫，如HR系統提供數據到門戶：HRDataToPortal），編碼長度不能超過20個字母；
- 所有的消息流程填寫中文別名和描述，描述一定要寫清楚具體含義。
- ESB集成項目主包名：com.agileai.esb；
- 公共代碼直接放在com.agileai. esb目錄下，其他代碼采用ESB默認生成的包名以及類名。
4.2 WEB服務規范
應用/數據接口以WebService方式進行發布，采用Http通訊協議進行同步通訊，AEAI ESB服務代理支持SOAP 1.1、SOAP 1.2訪問協議，AEAI ESB的開發Web服務默認支持SOAP1.1，對於Web服務報文信息字段要求如下：
- 各字段若無特別說明均為字符串型；
- 日期字段默認格式為“yyyy-MM-dd”，如：2015-05-14；
- 時間字段默認格式為“HH:mm:ss”，如16:25:16；
- 報文頭信息具有默認結構，允許自定義報文頭。
不論是在AEAI ESB中注冊的服務代理還是AEAI ESB中發布的服務都支持：用戶、密碼認證以及擴展認證模式，同時提供服務監控、服務調用統計功能，同時支持業務日志。
4.3 AEAI ESB開發規范
本項目中在AEAI ESB中開發的服務主要為Web Service、Http、Timer三種方式的服務，各單位內部及下屬各單位的業務系統既有的Web服務，在AEAI ESB中注冊服務代理方式，AEAI ESB提供消息轉發、服務監控、服務統計、以及服務認證和業務日志功能。
4.3.1 服務代理注冊
首先，登陸ESB管理控制台
選擇需要添加服務代理的工程，選擇服務代理標簽
點擊新增，進行WEB服務注冊代理
將需要進行代理的服務URL添加到對應位置（1），點擊解析按鈕進行服務代理注冊（2），添加認證類型（無認證，用戶密碼，擴展流程）（3），添加是否啟用業務日志（4）
在提供的ws服務中，service的name需要通過業務功能來命名，不能重復
| <wsdl:service name="XXX"> <wsdl:port name="erp_ryzw_receivePort" binding="tns:ErpRyzwReceiveServiceSoapBinding"> <soap:address location="http://localhost:9090/AEAIESB/wsproxies/XXX"/> </wsdl:port> </wsdl:service> |
4.3.2 開發WEB服務
對於既有系統不能提供Web服務接口的應用系統，且需要Web服務方式來集成，或者需要對既有的Web服務實現服務編排重組，可以在AEAI ESB開發Web服務。
- 如果涉及到數據讀取，需要對應系統管理員提供提供數據視圖、字段說明、以及數據庫連接方式；
- 如果涉及到數據寫入，需要對應系統管理員提供中間表以及存儲過程，ESB理論上不直接訪問實際的業務表；
- 如果涉及到服務編排，需要對應系統管理員提供Web服務的SOAP調用樣例，請求和響應參數說明。
4.3.3 開發HTTP服務
根據服務提供方提供的數據庫交互方式（視圖查詢、存儲過程）進行Http流程的開發
- 提供數據庫連接信息，如賬號密碼及地址等（Oracle數據庫還需要提供SID），登陸ESB管理控制台對數據庫資源進行注冊管理；
- 服務提供方需提供存儲過程或相關的查詢SQL語句；
- Http流程的返回值為JSON或者XML格式（需要就實際業務進行選擇），調用方自行解析。
4.3.4 開發Timer服務
根據當前的輪詢方式，在AEAI ESB上改造為Timer流程：
- 服務系統管理員提供當前的輪詢策略（定時、間隔、自定義）；
- 提供數據庫連接信息，如賬號密碼及地址等（Oracle數據庫還需要提供SID），登陸ESB管理控制台對數據庫資源進行注冊管理；
- 提供查詢全量數據還是增量數據，查詢增量數據時的條件；
4.4 AEAI ESB測試規范
4.4.1 單元測試
單元測試由流程開發者自己來完成，單元測試是對完成一條流程后的最基本檢查，主要是用來檢測邏輯否正確，程序代碼是否正確， 組件節點命名是否按照規則，實例正確生成、以及字段和變量的拼寫錯誤，還包括所引用資源是否可以等細節。
單元測試的依據是測試規格說明書，單元測試的目的是對流程功能基本驗證，該測試用來確定執行結果否符合預期，單元自測以持續執行3次均成功方驗證為成功。
4.4.2 結對互測
當局者迷，旁觀清。兩個開發人員具有相同的缺點和盲可能性很小，當采用結對互測試的時候會獲得一個強大解決方案 ，能更快的發現並解決問題 。結對互測准確來說是一個測試方法，而不是其中的具體環節。
結對互測是指兩個流程開發人員相測試對方的流程，結對互測的基礎已完成開發人員已完成單元測試。
4.4.3 集成測試
大多數流程之間不是獨立的，而有關聯。多個流程的執行才是真實的邏輯業務， 所以在有流程完成單元測試后，需要按照業務子系統對多個流程進行連貫的集成測試，用來發現執時是否可以滿足實際業務的需要。
集成測試可以根據實際業務模塊或者子系統，來各自獨立進行。集成測試用來發現多個流程協作執行時產生的潛在問題，這其中包括流程數據業務一致性和穩定性等。
4.4.4 業務聯測
業務模擬測試時在集成之后進行的，當各個子系統的對應流程進行了集成 測試並通過后，可以進行完整系統的業務模擬測試。通常業務聯測需要業務人員的參與和協作，在系統試運行初期進行。
業務模擬測試是所有流程的完整，各個被集成子系統和數據庫都以正常模 擬數據進行測試。此時AEAI ESB集成平台對用戶來說是透明的，所有數據都通過業務人員在各自系統上進行模擬操作獲取 。