1、系統對接設計1.1.1 3.7.3對接方式系統與外部系統的對接方式以web service方式進行。系統接口標準：本系統采用SOA體系架構，通過服務總線技術實現數據交換以及實現各業務子系統間、外部業務系統之間的信息共享和集成，因此SOA體系標準就是我們采用的接口核心標準。主要包括：服務目錄標準：服務目錄API接口格式參考國家以及關于服務目錄的元數據指導規范，對于 W3C UDDI v2 API結構規范，采取 UDDI v2的API的模型，定義 UDDI的查詢和發布服務接口，定制基于 Java和SOAP的訪問接口。除了基于 SOAP1.2的Web Service接 口方式，對于基于消息的接口采用

2、JMS或者MQ的方式。交換標準：基于服務的交換，采用HTTP/HTTPS作為傳輸協議，而其消息體存放基于SOAP1.2協議的SOAP消息格式。SOAP的消息體包括服務數據以及服務操作，服務數據和服務操作采用 WSDL進行描述。Web服務標準：用 WSDL描述業務服務，將 WSDL發布到UDDI用以設計/創建服務，SOAP/HTTP服務遵循 WS-I Basic Profile 1.0,禾用J2EE Session EJB較現新的業務服務， 根據需求提供 SOAP/HTTP or JMS and RMI/IIO限口。業務流程標準：使用沒有擴展的標準的 BPEL4WS對于業務流程以SOAP服務形式

3、進行訪問，業務流程之間的調用通過SOAP數據交換安全：與外部系統對接需考慮外部訪問的安全性，通過 IP白名單、SSL認證 等方式保證集成互訪的合法性與安全性。數據交換標準：制定適合雙方系統統一的數據交換數據標準，支持對增量的數據自動進行數據同步，避免人工重復錄入的工作。1.1.2 3.3.8接口規范性設計系統平臺中的接口眾多，依賴關系復雜，通過接口交換的數據與接口調用必 須遵循統一的接口模型進行設計。接口模型除了遵循工程統一的數據標準和接口 規范標準，實現接口規范定義的功能外，需要從數據管理、完整性管理、接口安 全、接口的訪問效率、性能以及可擴展性多個方面設計接口規格。 接口定義

4、約定客戶端與系統平臺以及系統平臺間的接口消息協議采用基于HTTP協議的RESTM格接口實現，協議棧如圖4-2所示。業務消息會話數據HTTP/HTTPSTCP/IP底層承載圖表 錯誤！文檔中沒有指定樣式的文字。1接口消息協議棧示意圖系統在http協議中傳輸的應用數據采用具有自解釋、自包含特征的JSON數據格式，通過配置數據對象的序列化和反序列化的實現組件來實現通信數據包 的編碼和解碼。在接口協議中，包含接口的版本信息，通過協議版本約束服務功能規范，支持服務平臺間接口協作的升級和擴展。一個服務提供者可通過版本區別同時支持 多個版本的客戶端，從而使得組件服務的提供者和使用者根據實際的需要，獨立演進，

5、降低系統升級的復雜度，保證系統具備靈活的擴展和持續演進的能力。 業務消息約定請求消息URI中的參數采用UTF-8編碼并經過URLEncod卻碼。請求接口 URL格式：http|https:host:port/app name/business component name/action ； 其中：協議：HTTP RES彩式接口host :應用支撐平臺交互通信服務的IP地址或域名port :應用支撐平臺交互通信服務的端口app name：應用支撐平臺交互通信服務部署的應用名稱business component name : 業務組件名稱action :業務操作請求的接口名稱，接口

6、名字可配置應答的消息體采用JSONR據格式編碼，字符編碼采用 UTF-8。應答消息根節點為“response"，每個響應包含固定的兩個屬性節點：“status 和“message'。它們分別表示操作的返回值和返回消息描述， 其他的同級子節點 為業務返回對象屬性，根據業務類型的不同，有不同的屬性名稱。當客戶端支持數據壓縮傳輸時，需要在請求的消息頭的“Accept-Encoding ” 字段中指定壓縮方式（gzip）,如消息可以被壓縮傳輸則平臺將應答的數據報文進 行壓縮作為應答數據返回，Content-Length 為壓縮后的數據長度。詳細參見 HTTP/1.1 RFC2616b

7、 響應碼規則約定響應結果碼在響應消息的“status ”屬性中，相應的解釋信息在響應消息的 “message'屬性中。解釋消息為終端用戶可讀的消息，終端應用不需要解讀可 直接呈現給最終用戶。響應結果碼為6位數字用。根據響應類型，包括以下幾類 響應碼。如表4-1中的定義。表4-1響應碼對應表響應碼描述0成功1XXXXX系統錯誤2XXXXX輸入參數不合法錯誤3XXXXX應用級返回碼，定義應用級的異常返回。4XXXXX正常的應用級返回碼，定義特定場景的應用級返回說明。數據管理.1 業務數據檢查接口應提供業務數據檢查功能，即對接收的數據進行合法性檢查，

8、對非法數 據和錯誤數據則拒絕接收，以防止外來數據非法入侵，減輕應用支撐平臺系統主 機處理負荷。對于接口，其業務數據檢查的主要內容有以下幾個方面：?數據格式的合法性：如接收到非預期格式的數據。包括接收的數據長度， 類型，開始結束標志等。?數據來源的合法性：如接收到非授權接口的數據。?業務類型的合法性：如接收到接口指定業務類型外的接入請求。對于業務數據檢查中解讀出非法數據應提供以下幾種處理方式：?事件報警：在出現異常情況時自動報警，以便系統管理員及時進行處理。?分析原因：在出現異常情況時，可自動分析其出錯原因。如是數據來源 非法和業務類型非法，本地記錄并做后續管理，如是數據格式非法，分析網絡傳 輸

9、原因或對端數據處理原因，并做相應處理。?統計分析：定期對所有的非法記錄做統計分析，分析非法數據的各種來 源是否具有惡意，并做相應處理。.2 數據壓縮/解壓接口根據具體的需求應提供數據壓縮/解壓功能，以減輕網絡傳輸壓力，提 高傳輸效率，從而使整個系統能夠快速響應并發請求，高效率運行。在使用數據壓縮/解壓功能時，應具體分析每一類業務的傳輸過程、處理過 程、傳輸的網絡介質、處理的主機系統和該類業務的并發量、峰值及對于所有業 務的比例關系等，從而確定該類業務是否需要壓縮 /解壓處理。對于傳輸文件的 業務，必須壓縮后傳輸，以減輕網絡壓力，提高傳輸速度。在接口中所使用的壓縮工具必須基于通用無

10、損壓縮技術， 壓縮算法的模型和 編碼必須符合標準且高效，壓縮算法的工具函數必須是面向流的函數，并且提供 校驗檢查功能。 完整性管理根據業務處理和接口服務的特點，應用系統的業務主要為實時請求業務和批 量傳輸業務。兩類業務的特點分別如下：1 .實時請求業務：(1) 采用基于事務處理機制實現(2) 業務傳輸以數據包的方式進行(3) 對傳輸和處理的實時性要求很高(4) 對數據的一致性和完整性有很高的要求(5) 應保證高效地處理大量并發的請求2 .批量傳輸業務：(1) 業務傳輸主要是數據文件的形式(2) 業務接收點可并發處理大量傳輸，可適應高峰期的傳輸和處理(3) 要求傳輸的可靠性高根據上

11、述特點，完整性管理對于實時交易業務，要保證交易的完整性；對于 批量傳輸業務，要保證數據傳輸的完整性。3.1.3 接口雙方責任 消息發送方遵循本接口規范中規定的驗證規則，對接口數據提供相關的驗證功能，保證數據的完整性、準確性；消息發起的平臺支持超時重發機制，重發次數和重發間隔可配置。提供接口元數據信息，包括接口數據結構、實體間依賴關系、計算關系、關 聯關系及接口數據傳輸過程中的各類管理規則等信息；提供對敏感數據的加密功能;1.1.5接口安全性設計及時解決接口數據提供過程中數據提供方一側出現的問題; 消息響應方遵循本接口規范中規定的驗證規則， 對接收的數據進行驗證，保證

12、數據的完 整性、準確性。及時按照消息發送方提供的變更說明進行本系統的相關改造。及時響應并解決接口數據接收過程中出現的問題。 異常處理對接口流程調用過程中發生的異常情況， 如流程異常、數據異常、會話傳輸 異常、重發異常等，進行相應的異常處理，包括：對產生異常的記錄生成異常記錄文件。針對可以回收處理的異常記錄，進行自動或者人工的回收處理。記錄有關異常事件的日志，包含異常類別、發生時間、異常描述等信息。當接口調用異常時，根據預先配置的規則進行相關異常處理，并進行自 動告警。3.1.4 接口的可擴展性規劃與設計各個系統間的通信接口版本信息限定了各個系統平臺間交互的數據協議類 型、特定版本

13、發布的系統接口功能特征、 特定功能的訪問參數等接口規格。 通過 接口協議的版本劃分，為客戶端升級、其他被集成系統的升級、以及系統的部署 提供了較高的自由度和靈活性。系統可根據接口請求中包含的接口協議版本實現對接口的向下兼容。 系統平 臺可根據系統的集群策略，按協議版本分別部署，也可多版本并存部署。由于系 統平臺可同時支持多版本的外部系統及客戶端應用訪問系統， 特別是新版本客戶 端發布時，不要求用戶強制升級，也可降低強制升級安裝包發布的幾率。 從而支 持系統的客戶端與系統平臺分離的持續演進。為了保證系統平臺的安全運行，各種集成的外部系統都應該保證其接入的安 全性。接口的安全是平臺系統安全的一個重

14、要組成部分。 保證接口的自身安全，通 過接口實現技術上的安全控制，做到對安全事件的“可知、可控、可預測” ，是 實現系統安全的一個重要基礎。根據接口連接特點與業務特色，制定專門的安全技術實施策略，保證接口的 數據傳輸和數據處理的安全性。系統應在接口的接入點的網絡邊界實施接口安全控制。接口的安全控制在邏輯上包括：安全評估、訪問控制、入侵檢測、口令認證、 安全審計、防（毒）惡意代碼、加密等內容。 安全評估安全管理人員利用網絡掃描器定期（每周）/不定期（當發現新的安全漏洞時） 地進行接口的漏洞掃描與風險評估。掃描對象包括接口通信服務器本身以及與之 關聯的交換機、防火墻等，要求通過掃描器

15、的掃描和評估，發現能被入侵者利用 的網絡漏洞，并給出檢測到漏洞的全面信息，包括位置、詳細描述和建議改進方 案，以便及時完善安全策略，降低安全風險。安全管理人員利用系統掃描器對接口通信服務器操作系統定期（每周）/不定期（當發現新的安全漏洞時）地進行安全漏洞掃描和風險評估。在接口通信服務器 操作系統上，通過依附于服務器上的掃描器代理偵測服務器內部的漏洞，包括缺少安全補丁、詞典中可猜中的口令、不適當的用戶權限、不正確的系統登錄權限、 操作系統內部是否有黑客程序駐留，安全服務配置等。系統掃描器的應用除了實 現操作系統級的安全掃描和風險評估之外還需要實現文件基線控制。接口的配置文件包括接口服務間相互協調

16、作業的配置文件、系統平臺與接口對端系統之間協調作業的配置文件，對接口服務應用的配置文件進行嚴格控制， 并且配置文件中不應出現口令明文，對系統權限配置限制到能滿足要求的最小權限，關鍵配置文件加密保存。為了防止對配置文件的非法修改或刪除， 要求對配 置文件進行文件級的基線控制。 訪問控制訪問控制主要通過防火墻控制接口對端系統與應用支撐平臺之間的相互訪 問，避免系統問非正常訪問，保證接口交互信息的可用性、完整性和保密性。訪 問控制除了保證接口本身的安全之外，還進一步保證應用支撐平臺的安全。為了有效抵御威脅，應采用異構的雙防火墻結構，提高對防火墻安全訪問控 制機制的破壞難度。雙防火墻在選

17、型上采用異構方式，即采用不同生產廠家不同 品牌的完全異構防火墻。同時，雙防火墻中的至少一個應具有與實時入侵檢測系 統可進行互動的能力。當發生攻擊事件或不正當訪問時，實時入侵檢測系統檢測 到相關信息，及時通知防火墻，防火墻能夠自動進行動態配置， 在定義的時間段 內自動阻斷源地址的正常訪問。系統對接口被集成系統只開放應用定義的特定端口。采用防火墻的地址翻譯功能，隱藏系統內部網絡，向代理系統提供翻譯后的 接口通信服務器地址及端口，禁止接口對端系統對其它地址及端口的訪問。對通過/未通過防火墻的所有訪問記錄日志。 入侵檢測接口安全機制應具有入侵檢測（IDS）功能，實時監控可疑連接和非法訪問

18、等 安全事件。一旦發現對網絡或主機的入侵行為， 應報警并采取相應安全措施，包 括自動阻斷通信連接或者執行用戶自定義的安全策略。實施基于網絡和主機的入侵檢測。 檢測攻擊行為和非法訪問行為，自動中斷 其連接，并通知防火墻在指定時間段內阻斷源地址的訪問，記錄日志并按不同級 別報警，對重要系統文件實施自動恢復策略。 口令認證對于需經接口安全控制系統對相關集成系統進行業務操作的請求，實行一次性口令認證。為保證接口的自身安全，對接口通信服務器和其它設備的操作和管理要求采 用強口令的認證機制，即采用動態的口令認證機制。 安全審計為了保證接口的安全，要求對接口通信服務器的系統日志、 接