在基於SOA的應用集成項目中，用戶會定義很多服務接口用於系統之間的交互。作爲SOA應用集成中的基本元素，服務總線中的服務接口的定義規範對應用集成項目的實施具有重要的指導意義。
根據我的經驗，在應用集成項目中定義的服務接口大多數爲同步交互接口，比如Web Service接口，基本會佔接口總數的八、九成。即便是需要進行異步交互的業務，經常也是由多個同步交互服務接口組合實現的。在本文中，我將介紹服務總線中的同步交互服務接口的定義規範。
首先，總線中的一個同步交互服務的須根據如下模式進行設計：
在同步交互服務中，必須要包括如下三個基本的消息處理路徑：
① 請求消息處理：接收調用端發送的請求消息數據並進行處理
② 響應消息處理：將服務處理結果生成響應消息並返回給調用端
③ 異常消息處理：對請求路徑和響應路徑中產生異常進行捕捉，生成異常消息，並作爲響應消息返回給調用端
其次，在整個的服務消息處理的過程中，還需要包含如下元素：
- 服務日誌：用於記錄運行情況，包括調用時間、消息關鍵內容、成功/失敗、異常信息等。日誌記錄的操作放在響應消息處理路徑和異常消息處理路徑當中，採用異步方式記錄，以免日誌記錄操作影響服務的運行。
- 超時時間：在調用目標服務時，必須要設置調用超時時間，以免目標服務處理時間過長，導致服務總線中線程掛起的情況。超時時間建議不超過120秒。
- 報文校驗(可選)：針對需要對報文進行限制(報文大小、格式等)的服務，需要在請求消息處理路徑的起始處進行報文校驗，校驗失敗觸發異常消息處理路徑。
- 調試日誌(可選)：如果需要在處理過程中記錄調試日誌，必須要設置日誌級別，以免在服務正常運行時佔用過多的日誌空間，消耗服務性能。
最後，同步交互服務接口的報文定義規範可參考如下格式：
- 請求消息報文格式：
<Request>
<ReqMsgHeader> --請求消息頭，用於傳送服務請求的關鍵信息
<SID/> --序列號系統生成，調用的唯一標識序號
<Invoker/> --請求系統名稱，標識請求系統
<Key_1/> --業務關鍵字保留字段，用於記錄關鍵日誌信息和集成邏輯中的判斷條件，可定義多個保留字段
<Key_2/>
<Key_3/>
<Key_4/>
<Key_5/>
</ReqMsgHeader>
<ReqMsgBody> --請求消息體，請求消息的內容，可以爲XML或者格式化的字符串，一般情況下，不需要在服務總線中進行解析。用這種消息體字符串方式定義，目的是減少業務報文的變化對服務的影響，不需要對服務接口進行頻繁的修改。
</ReqMsgBody>
</Request>
- 響應消息報文格式
<Response>
<RespMsgHeader> --響應消息頭
<Result/> --響應結果 1成功 0失敗
<RespMsg/> --響應結果描述，簡單總結返回結果
<ExceptionInfo/> --異常信息，詳細的異常信息
<Key_1/> --業務關鍵字保留字段，用於記錄關鍵日誌信息和集成邏輯中的判斷條件，可定義多個保留字段
<Key_2/>
<Key_3/>
<Key_4/>
<Key_5/>
</RespMsgHeader>
<RespMsgBody> --響應消息體，如果服務返回複雜的結果，比如查詢服務，將結果數據以XML或者格式化字符串的形式放在該字段中。通常，該字段不需要在服務總線中進行解析。用這種消息體字符串方式定義，目的是減少業務報文的變化對服務的影響，不需要對服務接口進行頻繁的修改。
</RespMsgBody>
</Response>
以上是我根據之前的項目經驗總結的服務總線中同步交互接口的定義規範，供參考，實際項目中，可根據具體情況進行調整。
歡迎關注我的微信公衆號：
