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流程：
- 服務系統管理者提供目前的輪詢政策（定時、間隔、自定義）；
- 提供查詢全量資料還是增量資料，查詢增量資料時的條件；
4.4 AEAI ESB測試規範
4.4.1 單元測試
單元測試由流程開發者自己來完成，單元測試是對完成一條流程後的最基本檢查，主要是用來檢測邏輯否正确，程式代碼是否正确， 元件節點命名是否按照規則，執行個體正确生成、以及字段和變量的拼寫錯誤，還包括所引用資源是否可以等細節。
單元測試的依據是測試規格說明書，單元測試的目的是對流程功能基本驗證，該測試用來确定執行結果否符合預期，單元自測以持續執行3次均成功方驗證為成功。
4.4.2 結對互測
當局者迷，旁觀清。兩個開發人員具有相同的缺點和盲可能性很小，當采用結對互測試的時候會獲得一個強大解決方案 ，能更快的發現并解決問題 。結對互測準确來說是一個測試方法，而不是其中的具體環節。
結對互測是指兩個流程開發人員相測試對方的流程，結對互測的基礎已完成開發人員已完成單元測試。
4.4.3 內建測試
大多數流程之間不是獨立的，而有關聯。多個流程的執行才是真實的邏輯業務， 是以在有流程完成單元測試後，需要按照業務子系統對多個流程進行連貫的內建測試，用來發現執時是否可以滿足實際業務的需要。
內建測試可以根據實際業務子產品或者子系統，來各自獨立進行。內建測試用來發現多個流程協作執行時産生的潛在問題，這其中包括流程資料業務一緻性和穩定性等。
4.4.4 業務聯測
業務模拟測試時在內建之後進行的，當各個子系統的對應流程進行了內建 測試并通過後，可以進行完整系統的業務模拟測試。通常業務聯測需要業務人員的參與和協作，在系統試運作初期進行。
業務模拟測試是所有流程的完整，各個被內建子系統和資料庫都以正常模 拟資料進行測試。此時AEAI ESB內建平台對使用者來說是透明的，所有資料都通過業務人員在各自系統上進行模拟操作擷取 。