題注：
發表這篇解決方案，屬于非盈利目的。主要是為了讓大家了解一種接口技術解決方案文檔的編寫格式以及讓大家評審在我的這個技術解決方案中的不足之處，以便大家指出并加以改進。
轉載，下載或與各種形式使用這篇文章，必須注明文章的作者，出處。
其他未盡事宜，以國家法律規定的為準！
作者：南瘋
調用認證：
雖然接口雙方都是存在于電信內部網絡中，但是，仍不能排除接口服務被攻擊、惡意調用以及非法調用等。所以，從接口調用上，必須考慮調用的認證安全問題。
u 本方案中的接口，在客戶端調用服務端的時候，必須經過調用身份認證。考慮施工系統的開發平臺的多樣性，但同時接口服務運行平臺都是Windows的情況，本方案采用Windows安全身份認證的方式。即在訪問接口所在的服務的時候，都必須進行資格審查（使用Credentials發送認證信息）。
u 另外，接口采用SOAP協議，因此在接口配置上面需要屏蔽HTTP GET 和HTTP POST等其他協議。
u 在接口中審核并進行日志的記錄。
u 使用最低權限的進程帳戶運行 Web 服務（通過 Machine.config 中的 <processModel> 元素來配置）。
u 接口不支持動態生成WSDL,因此作為服務端，應該禁止文檔協議。
u 在服務端禁用跟蹤，禁用調式編譯
業務用戶認證：
由于接口涉及電信工程中的各個不同的業務，有獲取字典、獲得項目信息、發送開工報告等，所以，建立一套業務的用戶認證機制是必須的。不同的用戶，所具備有的授權不一樣，所能執行的業務也不一樣。同時，業務用戶認證中的用戶信息也是記錄接口日志中的重要組成部分。
本方案采用的是在接口信息中包含業務認證用戶信息的方式來進行認證。服務端在收到請求的時候，應先驗證業務的授權用戶，如果該業務用戶沒有執行當前業務的權限，應終止業務的執行，并給出非法用戶的警告信息反饋回客戶端。
一般情況下，業務認證的用戶是系統中的用戶。業務認證其實就是應用系統認證的組成部分。
業務認證的用戶信息經過加密之后包含在要發送的信息（XML體）中，即在發送的信息中包含業務用戶的信息（參見下面的數據格式說明）。
數據的安全表現為如何保證數據在網絡傳輸過程中不會被截獲并被解析其中的內容而引起信息泄露與如何保證數據在傳輸的過程中的數據的完整性兩個方面。
Web Service采用XML數據格式來傳輸信息。所以，無論是發送數據還是返回結果，都要求采用對XML數據加密之后來傳輸。至于采用何種方式的加密技術，本方案為了保密，只能在開發的時候由開發人員口頭告知。涉及到加密技術就要涉及到加密的密鑰問題。目前，外協系統和施工系統接口上有很多種類型的業務，到底是每種類型的業務采用不同的密鑰，還是按分組來采用同一種密鑰的方式，還是所有的業務全部采用同一種的密鑰的方式，按照需求各有不同的選擇。本方案采用的是最后一種的方式。密鑰的發布由作為服務方來發布，由客戶端獲取。密鑰的發布方式待定。
為了保證數據的完整性，首先：方案采用數據簽名（SOAP Security Extensions: Digital Signature）。利用XML的數字簽名（XML Digital Signature syntax [XML-Signature]）對SOAP進行擴展，在SOAP的頭元素中定義簽名屬性（<SOAP-SEC:Signature>）來實現。其次：限制并驗證 Web 方法輸入的類型、長度、格式和范圍，驗證對 XML 輸入數據的驗證是基于已協商的架構等。
事務是一組相關的任務，作為獨立于其他任務的獨立單元成功（提交）或失敗（中止）。分布式事務是影響多個資源的事務。要提交分布式事務，所有參與者都必須保證對數據的任何更改是永久的。不論系統崩潰或是發生其他無法預料的事件，更改都必須是持久的。即使只有一個參與者無法保證這一點，整個事務也將失敗，在事務范圍內對數據的任何更改均將回滾。
外協系統和施工系統是處于網絡之上的兩個分布式接口，使用的是分布式事務。要啟用分布式事務，可能需要通過網絡啟用 MS DTC（考慮外協平臺和施工平臺都是運行在Windows上），以便在使用應用了最新的 Service Pack 的較新操作系統（例如 Windows XP 或 Windows 2003）時使用分布式事務。如果啟用了 Windows 防火墻（Windows XP Service Pack 2 的默認設置），必須允許 MS DTC 服務使用網絡或打開 MS DTC 端口。
接口中的服務端和客戶端的環境事務始終相同，客戶端創建的事務上下文并應用對于服務端的當前的事務，以便對于該事務上下文是當前的。這樣的事務會造成性能損失，因為可能需要繼承原來的上下文，但是，這樣的事務確保了在數據庫操作的時候信息的完整性。接口中事務的發起總是由客戶端發起的，并負責事務的提交和回滾等控制。
在接口設計的時候就應該考慮性能上面的問題，不要在事后再加入性能。同時，在項目的開發過程要反復進行測試，可以從機器的吞吐量和響應時間兩個基本的指標來衡量接口的性能。接口上面的性能考慮主要從下面幾個方面來優化：
u 使用一次連接，多次調用，優化連接資源。
u 對于并行的接口調用使用異步的調用方式。
u 優化線程池減少競爭。
u 考慮使用XML壓縮。
u 如果不需要返回，考慮使用單工通訊的方式。
u 適當的設置（如果有代理）代理超時，頁面超時，WebService超時。
u 設計"大塊頭"的接口減少往返。
u 基于消息的編程而不是遠程過程調用(RPC) 。
u 使用XML字串作為參數。
u 盡量使用原始數據類型參數。
u 避免在調用之間維護服務器狀態。
u 考慮為復雜的WebMethod提供輸入校驗。
u 考慮對WebMethod的結果使用緩存。
u 選擇適用的大數據包傳送方式。
u 避免調用本地的WebService。
客戶端向服務端發送數據，服務端解析數據，反饋信息給客戶端，這中間的環節只要某一個環節出現問題，都會造成接口的失敗。按照失敗產生的環節分類，我們可以從三個方面來處理接口的失敗。
u 網絡連接失敗：在調用接口的時候，由于網絡不通，造成數據不能正常傳輸。這樣，客戶端應該能夠記錄發送的日志，按照一定的時間間隔重試發送。本方案定為重試發送20次，每次時間間隔2小時。如果一直發生網絡不通的情況，該發送日志被保存下來，待后手工發送。所以，客戶端系統應該實現手工發送數據的功能。
u 反饋錯誤信息：服務端在解析數據包，執行數據包業務的時候，可能會發生異常。所以，服務端應當能夠捕捉異常信息，比如“非法XML格式”等，然后反饋給客戶端。客戶端在接受到這類的錯誤信息之后，應當進行日志記錄，能夠自動或手工分析異常的信息。
u 網絡連接正常，但是無信息反饋：這種情況下，一般是服務端出現了異常，但是又沒有捕捉到的情況下發生。這種情況下，客戶端把這種錯誤當作“網絡連接失敗”來處理。服務端應能夠實現相同數據包重新發送過來的處理機制。