企業服務總線項目集成標準

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  集成開發規範

1. 建立工程按照集成需求業務進行劃分，格式爲「公司名」+「產品」+」業務名」，例如：AeaiESBHr、AeaiESBCrm
2. 工程下的目錄按照服務提供方（系統）進行劃分，若是隻有相同的服務提供方，也須要建立目錄進行劃分；
3. 流程名採用匈牙利命名法（在幾個字母聯合的時候，首字母大寫，如HR系統提供數據到門戶：HRDataToPortal），編碼長度不能超過20個字母；
4. 全部的消息流程填寫中文別名和描述，描述必定要寫清楚具體含義。
5. ESB集成項目主包名：com.agileai.esb；
6. 公共代碼直接放在com.agileai. esb目錄下，其餘代碼採用ESB默認生成的包名以及類名。

4.2  WEB服務規範

　　應用/數據接口以WebService方式進行發佈，採用Http通信協議進行同步通信，AEAI ESB服務代理支持SOAP 1.一、SOAP 1.2訪問協議，AEAI ESB的開發Web服務默認支持SOAP1.1，對於Web服務報文信息字段要求以下：

1. 各字段若無特別說明均爲字符串型；
2. 日期字段默認格式爲「yyyy-MM-dd」，如：2015-05-14；
3. 時間字段默認格式爲「HH:mm:ss」，如16:25:16；
4. 報文頭信息具備默認結構，容許自定義報文頭。

　　不管是在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服務。

1. 若是涉及到數據讀取，須要對應系統管理員提供提供數據視圖、字段說明、以及數據庫鏈接方式；
2. 若是涉及到數據寫入，須要對應系統管理員提供中間表以及存儲過程，ESB理論上不直接訪問實際的業務表；
3. 若是涉及到服務編排，須要對應系統管理員提供Web服務的SOAP調用樣例，請求和響應參數說明。

4.3.3  開發HTTP服務

　　根據服務提供方提供的數據庫交互方式（視圖查詢、存儲過程）進行Http流程的開發

• 提供數據庫鏈接信息，如帳號密碼及地址等（Oracle數據庫還須要提供SID），登錄ESB管理控制檯對數據庫資源進行註冊管理；

• 服務提供方需提供存儲過程或相關的查詢SQL語句；
• Http流程的返回值爲JSON或者XML格式（須要就實際業務進行選擇），調用方自行解析。

4.3.4  開發Timer服務

　　根據當前的輪詢方式，在AEAI ESB上改造爲Timer流程：

1. 服務系統管理員提供當前的輪詢策略（定時、間隔、自定義）；
2. 提供數據庫鏈接信息，如帳號密碼及地址等（Oracle數據庫還須要提供SID），登錄ESB管理控制檯對數據庫資源進行註冊管理；
3. 提供查詢全量數據仍是增量數據，查詢增量數據時的條件；

4.4  AEAI ESB測試規範

4.4.1  單元測試

　　單元測試由流程開發者本身來完成，單元測試是對完成一條流程後的最基本檢查，主要是用來檢測邏輯否正確，程序代碼是否正確， 組件節點命名是否按照規則，實例正確生成、以及字段和變量的拼寫錯誤，還包括所引用資源是否能夠等細節。

　　單元測試的依據是測試規格說明書，單元測試的目的是對流程功能基本驗證，該測試用來肯定執行結果否符合預期，單元自測以持續執行3次均成功方驗證爲成功。

4.4.2  結對互測

　　當局者迷，旁觀清。兩個開發人員具備相同的缺點和盲可能性很小，當採用結對互測試的時候會得到一個強大解決方案 ，能更快的發現並解決問題 。結對互測準確來講是一個測試方法，而不是其中的具體環節。

　　結對互測是指兩個流程開發人員相測試對方的流程，結對互測的基礎已完成開發人員已完成單元測試。

4.4.3  集成測試

　　大多數流程之間不是獨立的，而有關聯。多個流程的執行纔是真實的邏輯業務， 因此在有流程完成單元測試後，須要按照業務子系統對多個流程進行連貫的集成測試，用來發現執時是否能夠知足實際業務的須要。

　　集成測試能夠根據實際業務模塊或者子系統，來各自獨立進行。集成測試用來發現多個流程協做執行時產生的潛在問題，這其中包括流程數據業務一致性和穩定性等。

4.4.4  業務聯測

　　業務模擬測試時在集成以後進行的，當各個子系統的對應流程進行了集成 測試並經過後，能夠進行完整系統的業務模擬測試。一般業務聯測須要業務人員的參與和協做，在系統試運行初期進行。

　　業務模擬測試是全部流程的完整，各個被集成子系統和數據庫都以正常模 擬數據進行測試。此時AEAI ESB集成平臺對用戶來講是透明的，全部數據都經過業務人員在各自系統上進行模擬操做獲取 。