專利名稱：基于tcp短連接的soap客戶端協(xié)議封裝方法
技術(shù)領(lǐng)域：
本發(fā)明方法屬于軟件協(xié)議接口領(lǐng)域，主要針對(duì)簡(jiǎn)單對(duì)象訪問協(xié)議 SOAP(SimpleObject Access Protocol)客戶端協(xié)議進(jìn)行封裝，是一種基于TCP短連接的 SOAP客戶端協(xié)議封裝方法。
背景技術(shù)：
目前電信運(yùn)營(yíng)商系統(tǒng)當(dāng)中，SOAP接口被普遍使用；但由于協(xié)議接口眾多，從而需 要開發(fā)多種SOAP接口 ；而每種接口都會(huì)制定相應(yīng)的WSDL文件，WSDL指網(wǎng)絡(luò)服務(wù)描述語(yǔ)言， 在通常情況下每得到一個(gè)接口開發(fā)需求，就要根據(jù)WSDL重新開發(fā)一次系統(tǒng)，也就是必須 重新發(fā)布一次源代碼版本，哪怕是升級(jí)已有的接口，也需要重新發(fā)布一次源碼；由此開 發(fā)電信軟件的行業(yè)通常設(shè)立接口組，某些部門專門就負(fù)責(zé)開發(fā)接口，因接口差異性大，開發(fā) 軟件成本也是相當(dāng)?shù)卮螅@些接口前期的開發(fā)，后期的版本維護(hù)、升級(jí)，都相當(dāng)?shù)南娜肆?成本。在此環(huán)境下，各運(yùn)營(yíng)商為節(jié)省協(xié)議接口之間的差異，就制定統(tǒng)一接口方式；例如中 國(guó)電信iSPP項(xiàng)目，就要求所有接口都是在SOAP方式下的統(tǒng)一接口協(xié)議；現(xiàn)在中國(guó)很多包括 HLR接口都是升級(jí)為SOAP接口方式；但這只是解決了網(wǎng)絡(luò)協(xié)議統(tǒng)一，并沒有真正解決業(yè)務(wù) 開發(fā)上的問題；并且升級(jí)為此接口方式會(huì)帶來這樣一系列問題(圖1為WSDL文件的發(fā)布 示意圖，這是老的方式)一)升級(jí)接口時(shí)在升級(jí)此接口，例如需要在SOAP協(xié)議的xml節(jié)點(diǎn)中添加一個(gè)參數(shù)信息節(jié)點(diǎn)；那么 就導(dǎo)致需要重新發(fā)布WSDL文件，所有使用此WSDL文件的系統(tǒng)(包括客戶端與服務(wù)端)都 要重新編譯并發(fā)布自己的應(yīng)用系統(tǒng)，帶來的維護(hù)與升級(jí)人力成本是非常大的；二)添加新接口時(shí)在添加新的SOAP接口的時(shí)候，同樣是要根據(jù)WSDL編譯出一套C/C++代碼或java 代碼以供相應(yīng)的開發(fā)語(yǔ)言調(diào)用(目前C/C++領(lǐng)域較流行的編譯工具為gSOAP，java領(lǐng)域較 流行的編譯工具為axis2)；這些工具的使用方法都是一樣的；在僅需開發(fā)客戶端的時(shí)候都存在同樣的問題要從WSDL文件編譯為C/C++或 java源碼，再重新編譯這些源碼，并修改業(yè)務(wù)參數(shù)后重新編譯發(fā)布新的應(yīng)用系統(tǒng)，也就是升 級(jí)應(yīng)用程序代碼才能解決問題。

發(fā)明內(nèi)容
本發(fā)明要解決的問題是現(xiàn)有SOAP的開發(fā)方式在接口文件WSDL文件發(fā)生變化時(shí)， 必須重新發(fā)布一次源代碼版本，因接口差異性大，開發(fā)軟件成本也是相當(dāng)?shù)卮?，這些接口前 期的開發(fā)，后期的版本維護(hù)、升級(jí)，都相當(dāng)?shù)南娜肆Τ杀?。本發(fā)明的技術(shù)方案為基于TCP短連接的SOAP客戶端協(xié)議封裝方法，針對(duì)客戶端封裝SOAP協(xié)議，把原本填在SOAP協(xié)議中的可變部分，即WSDL網(wǎng)絡(luò)服務(wù)描述語(yǔ)言文件提取出來，編譯為xml文件放置到客戶端應(yīng)用程序的的配置文件中，使SOAP協(xié)議可變部分全部 由配置文件對(duì)象經(jīng)過代碼轉(zhuǎn)換后生成SOAP協(xié)議體1)客戶端載入WSDL轉(zhuǎn)換后的xml文件；2)客戶端的應(yīng)用程序讀出配置文件，把xml結(jié)合要傳輸?shù)膽?yīng)用程序數(shù)據(jù)轉(zhuǎn)換為 SOAP消息體；3)在所述SOAP消息體加上SOAP消息頭，變成一個(gè)完整的SOAP請(qǐng)求；4)通過TCP短連接，將完整的SOAP請(qǐng)求發(fā)送給web services服務(wù)器，再處理一下 web services返回的內(nèi)容即完成了一次完整的SOAP接口調(diào)用；所有的web Services客戶端采用同一套客戶端源碼，采用統(tǒng)一的處理方式來向服 務(wù)器發(fā)出請(qǐng)求。使用第三方工具把服務(wù)端提供的WSDL網(wǎng)絡(luò)服務(wù)描述語(yǔ)言格式描述文件編譯為真 實(shí)的xml格式，所述第三方工具為gSOAP、soapUI。客戶端通過TCP短連接發(fā)送SOAP請(qǐng)求后，收到web Services服務(wù)器返回即斷開 socket 連接。SOAP協(xié)議原本就是在TCP短連接上實(shí)現(xiàn)的，一般的開發(fā)工具都是引入編譯的概 念；是把WSDL文件編譯成C/C++代碼、或編譯成java代碼后，讓這些源代碼給客戶端的應(yīng) 用程序直接使用；本發(fā)明是把原本填在協(xié)議中的WSDL文件提取出來，放到客戶端的配置文 件中；從而使SOAP協(xié)議可變部分全部由配置文件對(duì)象經(jīng)過代碼轉(zhuǎn)換后生成SOAP協(xié)議體； 使所有的web Services客戶端都可以采用同一套客戶端源碼，統(tǒng)一的處理方式處理各種各 樣的SOAP協(xié)議。本發(fā)明方法不涉及服務(wù)端SOAP業(yè)務(wù)處理；這點(diǎn)有別于目前軟件行業(yè)當(dāng)中流行的 SOAP軟件既處理服務(wù)端又處理客戶端；之所以僅對(duì)客戶端進(jìn)行封裝、犧牲了服務(wù)端封裝特 性，就是因?yàn)檫@樣可以有更強(qiáng)的針對(duì)性。本發(fā)明完成SOAP客戶端協(xié)議的封裝，使用字符流的方式進(jìn)行封裝，并且可以支持 各種各樣的SOAP協(xié)議運(yùn)行，因?yàn)楸景l(fā)明把SOAP消息體放到配置文件系統(tǒng)中了，因此當(dāng)WSDL 文件發(fā)生變更時(shí)，無需重新編譯和發(fā)布新的應(yīng)用程序，根據(jù)WSLD文件編譯得到的xml文件， 結(jié)合應(yīng)用程序數(shù)據(jù)即可轉(zhuǎn)換為SOAP消息體，用于SOAP接口調(diào)用。本發(fā)明的特點(diǎn)就是如果 WSDL文件發(fā)生變更，也就是接口格式發(fā)生了變更，無需重新編譯WSDL生成C/C++或java代 碼，更不需要重新發(fā)布應(yīng)用程序就可以直接解決問題，從而使得升級(jí)接口、添加新接口的時(shí) 候不需要像gSOAP、Axis —樣重新升級(jí)源碼。本發(fā)明在SOA架構(gòu)中，開發(fā)與升級(jí)web Services客戶端時(shí)，無需對(duì)應(yīng)用程序的源 碼進(jìn)行重新發(fā)布；這是與目前web Services開發(fā)工具所提供的功能特點(diǎn)不一樣的地方，如 目前的gSOAP、axis2等都需要重新編譯WSDL文件，它們都無法做到不重新編譯客戶端源碼。本發(fā)明就是要解決每次改變WSDL文件就要升級(jí)應(yīng)用程序這樣的問題，實(shí)現(xiàn)即使 WSDL文件生發(fā)變化了，只需要修改配置文件中xml格式即可。本發(fā)明在需要大量訪問不同 種web Services服務(wù)器的時(shí)候，能夠做到統(tǒng)一訪問方式，無需重新開發(fā)應(yīng)用程序；只需使 用第三方工具把WSDL翻譯成xml，并把xml配置到客戶端應(yīng)用程序配置文件中，就可以完 成整個(gè)web Services請(qǐng)求過程；使得各廠商、各平臺(tái)的web Services協(xié)議輕松得到統(tǒng)一的訪問，輕松融合在同一套客戶端應(yīng)用程序當(dāng)中。在WebService接口的平臺(tái)中，對(duì)于SOAP接 口，應(yīng)用本發(fā)明以后，當(dāng)接口格式發(fā)生變化時(shí)，不再消耗重復(fù)的開發(fā)成本，可直接轉(zhuǎn)到施工 環(huán)節(jié)，由現(xiàn)場(chǎng)工程人員直接對(duì)應(yīng)用程序進(jìn)行配置即可完成業(yè)務(wù)需求。


圖1為普通的SOAP開發(fā)方法圖2為本發(fā)明方法的應(yīng)用示意圖。圖3為SOAP客戶端消息結(jié)構(gòu)分解。
具體實(shí)施例方式如圖1，目前各web Serivces開發(fā)工具都是根據(jù)WSDL或由自己的開發(fā)工具來生成 WSDL文件，由WSDL編譯為C/C++或java代碼發(fā)布到web Serivces服務(wù)器，如果WSDL發(fā)生 變更，也就是接口格式發(fā)生了變更，那么就要重新編譯WSDL生成C/C++或java代碼，再重 新發(fā)布至服務(wù)器上去。例如電信行業(yè)中一個(gè)項(xiàng)目中遇到外圍接口有上百個(gè)，根據(jù)前述的方法，其中的 webservices服務(wù)器升級(jí)都需要重新發(fā)布源碼，無疑這種工作量不是產(chǎn)生在維護(hù)上，而是要 重新進(jìn)行開發(fā)。本發(fā)明在TCP短連接上封裝SOAP協(xié)議為整個(gè)系統(tǒng)的核心，針對(duì)客戶端封裝SOAP 協(xié)議，把原本填在SOAP協(xié)議中的可變部分，即WSDL網(wǎng)絡(luò)服務(wù)描述語(yǔ)言文件提取出來，編譯 為ml文件放置到客戶端應(yīng)用程序的的配置文件中，使SOAP協(xié)議可變部分全部由配置文件 對(duì)象經(jīng)過代碼轉(zhuǎn)換后生成SOAP協(xié)議體1)客戶端載入WSDL轉(zhuǎn)換后的xml文件；2)客戶端的應(yīng)用程序讀出配置文件，把xml結(jié)合要傳輸?shù)膽?yīng)用程序數(shù)據(jù)轉(zhuǎn)換為 SOAP消息體； 3)在所述SOAP消息體加上SOAP消息頭，變成一個(gè)完整的SOAP請(qǐng)求；4)通過TCP短連接，將完整的SOAP請(qǐng)求發(fā)送給web services服務(wù)器，再處理一下 web services返回的內(nèi)容即完成了一次完整的SOAP接口調(diào)用；所有的web Services客戶端采用同一套客戶端源碼，采用統(tǒng)一的處理方式來向服 務(wù)器發(fā)出請(qǐng)求。其中，使用第三方工具把服務(wù)端提供的WSDL網(wǎng)絡(luò)服務(wù)描述語(yǔ)言格式描述文件編 譯為真實(shí)的ml格式，所述第三方工具為gSOAP、soapUI等?？蛻舳送ㄟ^TCP短連接發(fā)送SOAP請(qǐng)求后，收到web Services服務(wù)器返回即斷開 socket 連接。在本發(fā)明當(dāng)中理論上所有的客戶端web Services程序都是不需要進(jìn)生重新 開發(fā)，而是結(jié)合本發(fā)明web Services客戶端協(xié)議，僅需修改配置文件中的xml格式；就 可以達(dá)到某接口升級(jí)不需要改變應(yīng)用程序，從而用同一個(gè)線程類即可以解決所有平臺(tái) webServices接口差異性，也就是說所有web Services客戶端都可以使用同一套通信源 碼，web Services協(xié)議部分是可以配置出來的；使得上百套接口系統(tǒng)采用同一套軟件版本； 可擴(kuò)展性強(qiáng)；應(yīng)用重載后二次開發(fā)量變小。
如圖2，本發(fā)明只要人工提前配置好各種接口，有新接口的時(shí)候也是配置這個(gè)新接 口 ；統(tǒng)一由WebService客戶端讀取這些配置文件，進(jìn)行調(diào)用接口即可；而如圖1，通常情況 下進(jìn)行Web Service開發(fā)的時(shí)候，需要編譯WSDL文件為程序源碼，然后重新編譯這些源碼 文件后再進(jìn)行接口發(fā)布；每新加入一個(gè)webService接口，就要重新編譯一次源碼；就要重 新發(fā)布一次客戶端系統(tǒng)。兩者對(duì)比可見WSDL變化帶來的影響面，圖1所示的現(xiàn)有方法完全受到WSDL文件 的影響，而本發(fā)明方法在將WSDL文件編譯為xml文件放置到配置文件中后，WSDL文件的變 動(dòng)就不再對(duì)后續(xù)客戶端的應(yīng)用程序產(chǎn)生影響，維護(hù)升級(jí)更加便捷，節(jié)省大量人力和成本。下面是本發(fā)明的開發(fā)思路，圖3為SOAP客戶端消息結(jié)構(gòu)分解，如圖3所示，SOAP消息頭中，劃線的部分為本發(fā)明填補(bǔ)的數(shù)據(jù)，SOAP消息體中，劃線的部分為應(yīng)用程序填補(bǔ)的 真實(shí)數(shù)據(jù)，其它為SOAP包體部分，即配置文件中讀取的xml格式(由WSDL轉(zhuǎn)換而來)。開 發(fā)思路就是本發(fā)明由客戶端自己封裝SOAP消息，SOAP消息由兩部分內(nèi)容組成1. SOAP消 息頭，2. SOAP消息體；而SOAP消息體是由配置文件中xml與客戶端的應(yīng)用程序真實(shí)數(shù)據(jù)組 成；這樣就可以生成完整的SOAP請(qǐng)求；客戶端通過建立TCP短連接發(fā)送出去，并處理返回 結(jié)果，即可；此種思路只能用來開發(fā)客戶端，主要就是用字符方式拼裝SOAP消息，并不支持 解析SOAP消息，SOAP消息的解析由服務(wù)器端所支持；而就是因?yàn)槟壳败浖袠I(yè)中流行的開 發(fā)工具都是同時(shí)支持SOAP服務(wù)端與客戶端的開發(fā)，所以目前軟件行業(yè)中流行的開發(fā)工具 在僅開發(fā)客戶端應(yīng)用程序時(shí)顯得特別復(fù)雜、與升級(jí)、維護(hù)代價(jià)過大問題。
權(quán)利要求
基于TCP短連接的SOAP客戶端協(xié)議封裝方法，其特征是針對(duì)客戶端封裝SOAP協(xié)議，把原本填在SOAP協(xié)議中的可變部分，即WSDL網(wǎng)絡(luò)服務(wù)描述語(yǔ)言文件提取出來，編譯為xml文件放置到客戶端應(yīng)用程序的的配置文件中，使SOAP協(xié)議可變部分全部由配置文件對(duì)象經(jīng)過代碼轉(zhuǎn)換后生成SOAP協(xié)議體1)客戶端載入WSDL轉(zhuǎn)換后的xml文件；2)客戶端的應(yīng)用程序讀出配置文件，把xml結(jié)合要傳輸?shù)膽?yīng)用程序數(shù)據(jù)轉(zhuǎn)換為SOAP消息體；3)在所述SOAP消息體加上SOAP消息頭，變成一個(gè)完整的SOAP請(qǐng)求；4)通過TCP短連接，將完整的SOAP請(qǐng)求發(fā)送給web services服務(wù)器，再處理一下web services返回的內(nèi)容即完成了一次完整的SOAP接口調(diào)用；所有的web Services客戶端采用同一套客戶端源碼，采用統(tǒng)一的處理方式來向服務(wù)器發(fā)出請(qǐng)求。
2.根據(jù)權(quán)利要求1所述的基于TCP短連接的SOAP客戶端協(xié)議封裝方法，其特征是使用 第三方工具把服務(wù)端提供的WSDL網(wǎng)絡(luò)服務(wù)描述語(yǔ)言格式描述文件編譯為真實(shí)的xml格式， 所述第三方工具為gSOAP、soapUI。
3.根據(jù)權(quán)利要求1或2所述的基于TCP短連接的SOAP客戶端協(xié)議封裝方法，其特征 是客戶端通過TCP短連接發(fā)送SOAP請(qǐng)求后，收到web Services服務(wù)器返回即斷開socket 連接。
全文摘要
基于TCP短連接的SOAP客戶端協(xié)議封裝方法，針對(duì)客戶端封裝SOAP協(xié)議，把WSDL文件提取出來，編譯為xml文件放置到客戶端應(yīng)用程序的的配置文件中，使SOAP協(xié)議可變部分全部由配置文件對(duì)象經(jīng)過代碼轉(zhuǎn)換后生成SOAP協(xié)議體，使所有的webServices客戶端都可以采用同一套客戶端源碼，統(tǒng)一的處理方式處理各種各樣的SOAP協(xié)議。本發(fā)明使用字符流的方式進(jìn)行SOAP客戶端協(xié)議封裝，支持各種各樣的SOAP協(xié)議運(yùn)行，如果WSDL文件發(fā)生變更，無需重新編譯WSDL生成C/C++或java代碼，更不需要重新發(fā)布應(yīng)用程序就可以直接解決問題，從而使得升級(jí)接口、添加新接口簡(jiǎn)單易行，維護(hù)方便。
文檔編號(hào)H04L29/06GK101834845SQ20101013369
公開日2010年9月15日 申請(qǐng)日期2010年3月26日 優(yōu)先權(quán)日2010年3月26日
發(fā)明者孫力斌, 宋海華, 龐海東, 張春飛, 陸志強(qiáng), 高福海, 魏本棟 申請(qǐng)人:南京聯(lián)創(chuàng)科技集團(tuán)股份有限公司