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