soap協(xié)議精選(九篇)
前言：一篇好文章的誕生，需要你不斷地搜集資料、整理思路，本站小編為你收集了豐富的soap協(xié)議主題范文，僅供參考，歡迎閱讀并收藏。
第1篇：soap協(xié)議范文
AMBA 3 高級擴(kuò)展界面(AXI)協(xié)議由于大幅度擴(kuò)展了AMBA 2.0片上總線的性能和靈活性,因而具備了更多的優(yōu)勢,同時也增加了設(shè)計的復(fù)雜度。DesignWare IP為AMBA 3 AXI協(xié)議的解決方案讓設(shè)計者能快速、簡便地集成此高速協(xié)議,同時降低了風(fēng)險,加快了設(shè)計周期。為AMBA 3 AXI協(xié)議的DesignWare IP解決方案提供了存取三種主要需求元件的權(quán)限,包括綜合實現(xiàn)IP、驗證IP和使用Synopsys的CoreAssembler工具實現(xiàn)子系統(tǒng)自動集成。在基于AMBA 3 AXI協(xié)議的下一代高速設(shè)計中,這三部分的組合使得設(shè)計人員能充分降低設(shè)計和驗證時間。
技術(shù)背景――AMBA 3 AXI協(xié)議為了正確領(lǐng)會面向基于AMBA 3 AXI協(xié)議的工程設(shè)計挑戰(zhàn)的復(fù)雜性,我們必須理解AMBA 3 AXI協(xié)議自身的技術(shù)特點。AMBA 3 AXI協(xié)議是專門為實現(xiàn)下一代IC設(shè)計,由包括Synopsys在內(nèi)的30多家公司合作開發(fā)的。AMBA 3 AXI協(xié)議定義了一種單向通道的架構(gòu),它能有效使用寄存器片斷實現(xiàn)管道的高速連接。它支持多重突發(fā)事務(wù)、完成無序處理事務(wù),和高效使用讀、寫和地址/控制操作的通道的聯(lián)系,能使系統(tǒng)具有較高的性能和效率。這種性能只受設(shè)備能力的限制。
AMBA 3 AXI協(xié)議:通道的作用AMBA 3 AXI協(xié)議的架構(gòu)和以前的AMBA協(xié)議有很大不同,因為它引入了通道。五個獨立通道均由一組信息信號組成,使用一種雙向“VALID”和“READY”的握手機(jī)制。當(dāng)通道具有有效數(shù)據(jù)或者控制信息時,信息源使用“VALID”信號。目標(biāo)則使用“READY”信號表示可以接收數(shù)據(jù)。讀數(shù)據(jù)和寫數(shù)據(jù)的通道均包含“LAST”信號來表示最終的數(shù)據(jù)傳輸。讀和寫處理都有各自的地址通道。地址通道包含了某種事務(wù)處理所需要的所有地址和控制信息。讀數(shù)據(jù)的通道傳輸由從模塊到主模塊的讀數(shù)據(jù)和讀響應(yīng)信息。讀數(shù)據(jù)的通道包含了8、16、32、64、128、256、512或1024位的數(shù)據(jù)總線,以及用來表示讀處理過程完成狀態(tài)的讀響應(yīng)信息。寫數(shù)據(jù)的通道傳輸由主模塊到從模塊的寫數(shù)據(jù)和寫響應(yīng)信息。數(shù)據(jù)的通道包含了8、16、32、64、128、256、512或1024位的數(shù)據(jù)總線,同時對每8個數(shù)據(jù)位使用一個字節(jié)用來表示數(shù)據(jù)總線中哪個字節(jié)是有效的。支持非對齊的傳輸能更有效地使用總線以獲得更高的性能,更低的存取時間和更高帶寬。
AMBA 3 AXI的DesignWare IP解決方案隨著AMBA 3 AXI協(xié)議的復(fù)雜化,基于此協(xié)議的子系統(tǒng)的設(shè)計和驗證成為一關(guān)鍵問題,它需要大量的專門技術(shù)。DesignWare IP的解決方案專門為簡化設(shè)計任務(wù),給工程師提供存取通用設(shè)計和驗證IP模塊,以加快從模塊到子系統(tǒng)級別的實現(xiàn)和驗證過程。另外,coreAssember工具可自動集成子系統(tǒng)和測試實例。 設(shè)計人員使用為AMBA 3 AXI的DesignWare IP的解決方案可以快速集成,綜合和驗證基于AMBA 3 AXI的設(shè)計。
為AMBA 3 AXI的DesignWare綜合IPDesignWare綜合IP是解決方案三部分的第一部分,它可以快速實現(xiàn)高帶寬,低存取時間和高性能的基于AMBA 3 AXI的設(shè)計。綜合IP包含三個關(guān)鍵元素:互連總線制造,AXI到AHB的橋,主模塊和從模塊的通用接口。這些是新建任何片上系統(tǒng)的基本構(gòu)建模塊,它們使設(shè)計人員易于實現(xiàn)基于AMBA 3 AXI的架構(gòu)。這些IP元件也能幫助已有IP和專門應(yīng)用模塊轉(zhuǎn)化為基于AMBA 3 AXI,從而保證了產(chǎn)品的高重用性。
為AMBA 3 AXI的DesignWare Interconnect Fabric(DW_axi)具有的特點使其目前為止是基于AMBA 3 AXI協(xié)議設(shè)計的標(biāo)準(zhǔn)互連制造的最佳方案。DW_axi靈活的配置為工程師提供了一系列特色來匹配他們的具有優(yōu)先順序的設(shè)計需求。DW_axi是AMBA 3 AXI協(xié)議的RTL級互連實現(xiàn),它可以同時實現(xiàn)不同主從模塊之間的傳輸。它能配置支持最多16對支持所有協(xié)議中指定的地址和數(shù)據(jù)寬度的主模塊和從模塊。DW_axi是基于多重地址、多重數(shù)據(jù)總線架構(gòu)的,它有選項內(nèi)置于系統(tǒng)譯碼器。每個處理過程在地址通道包含有地址和控制信息,它們描述了所要傳輸?shù)臄?shù)據(jù)的自然狀態(tài)。數(shù)據(jù)在主模塊到從模塊之間傳輸時,從模塊使用寫數(shù)據(jù)通道,主模塊使用讀數(shù)據(jù)通道。在寫處理過程中,所有數(shù)據(jù)均從主模塊流向從模塊,AMBA 3 AXI協(xié)議具有一個額外的寫響應(yīng)通道來允許從模塊給主模塊發(fā)出信號表示寫過程的完成。這種多層互連架構(gòu)允許在所有5個AMBA 3 AXI的通道的不同主/從模塊對之間進(jìn)行并行傳輸。因此其系統(tǒng)帶寬并不受DW_axi限制,而是受外部主從模塊的限制。
除了提供組合式地址和數(shù)據(jù)通道的控制以外,DW_axi提供了內(nèi)部和外部流水線操作,稱為寄存器分割(register slicing)。它能使設(shè)計人員可以得到盡可能高的工作頻率、帶寬和性能。可配置的內(nèi)部和外部寄存器分割能應(yīng)用于單個的通道,無論是全路徑還是向前控制路徑,以提供時間和制造優(yōu)化性能的最大靈活性。為優(yōu)化SW_axi以獲得最佳性能和最小面積,它包含了一個從屬的可見特征,當(dāng)不是所有的從模塊對所有的主模塊是可見的情況下可以使用該特征。它定制主模塊的可見性用于對于正常和boot模式的從模塊的存取,結(jié)果使得任何邏輯的復(fù)雜度降低。這樣能以最少的邏輯得到優(yōu)化的性能。
AMBA 3 AXI協(xié)議的一個關(guān)鍵目標(biāo)是能互用已有的AMBA 2.0技術(shù)。為達(dá)到互用的目標(biāo),DesignWare IP解決方案包含了一個AMBA 3 AXI的橋梁,連接AMBA 2.0 AHB,稱為DW_axi_x2h。DW_axi_x2h支持和完整的基于AMBA 2.0的子系統(tǒng)之間的聯(lián)系,可以提供已有的基于AHB的子系統(tǒng)的復(fù)用。在lite模式中,單獨的受控元件可以直接連接至基于AMBA 3 AXI協(xié)議的總線。這種互用的一個明顯的優(yōu)點在于設(shè)計人員已經(jīng)擁有了大量的經(jīng)DesignWare驗證的AMBA 2.0 AHB和APB的綜合IP和驗證IP。它能提高復(fù)用的選擇,增加了設(shè)計人員用于有差異的設(shè)計的時間,而不用于通用子系統(tǒng)的創(chuàng)建和驗證。DesignWare綜合IP解決方案包括了另外一些基于模塊的通用AMBA 2.0的設(shè)計,比如AHB總線制造,DW_ahb,APB橋和制造,DW_apb,和一些設(shè)備,例如DMA、內(nèi)存控制器、I2C、SSI、GPTI、RTC,定時器和中斷控制器等。
還有一些可復(fù)用的基礎(chǔ)元件也易于實現(xiàn)基于AMBA 3 AXI協(xié)議設(shè)計,它們就是DesignWare的為主模塊和從模塊的通用接口模塊,稱為DW_axi_gm/gs。DW_axi_gm/gs采用了一種通用的接口,減少了從定制的IP或者專用應(yīng)用模塊轉(zhuǎn)為基于AMBA 3 AXI協(xié)議的總線的時間。當(dāng)定制的應(yīng)用或者IP連接至基于AMBA 3 AXI的總線時,設(shè)計人員不用擔(dān)心協(xié)議的細(xì)節(jié),因為DW_axi/gs模塊能處理大部分AMBA 3 AXI接口的細(xì)節(jié)。當(dāng)使用通用的接口時,一旦設(shè)計和AMBA 3 AXI的總線相連時,設(shè)計人員可以有更多的時間專注于驗證和檢查。
本文為全文原貌 未安裝PDF瀏覽器用戶請先下載安裝 原版全文
為AMBA 3 AXI的DesignWare Verification IPDesignWare IP的解決方案的第二部分是為AMBA 3 AXI的Synopsys的DesignWare驗證IP(VIP)。通過引入更多產(chǎn)品驗證的高級技術(shù),這些驗證IP提供了一種快速有效的方法來驗證基于AMBA 3 AXI的片上系統(tǒng)。AMBA 3 AXI的DesignWare的驗證IP包含以下元件:主模塊、從模塊、監(jiān)視器和驗證互連。每個元件均支持所有的AMBA 3 AXI的地址和數(shù)據(jù)寬度,以及所有協(xié)議傳輸和響應(yīng)的字節(jié)。VIP的主模塊和從模塊用于產(chǎn)生和響應(yīng)處理事務(wù)。驗證互連能產(chǎn)生一個具有完整互連功能的子系統(tǒng),以幫助在模塊級對多重模塊相互作用的集成過程中的測試。驗證IP包含完整的命令集,它可以完成定向事務(wù)處理,基于level命令的測試。驗證IP將迅速修正互連錯誤,功能錯誤,通過特殊例子的測試。
驗證IP已經(jīng)獲得AMBA3所確認(rèn)的認(rèn)證標(biāo)志。這個標(biāo)志表示DesignWare驗證IP已被證明能正確實現(xiàn)于AMBA 3 AXI的規(guī)范系統(tǒng),此系統(tǒng)是由來自ARM公司的規(guī)則集合所組成的基于斷言的AXI測試系統(tǒng)。當(dāng)驗證IP被應(yīng)用于模塊級,對于工程師,這些模塊的接口可以保證和AMBA 3 AXI協(xié)議規(guī)范一致。 由于這些模塊均已證明在AMBA 3 AXI上的正確性,因此設(shè)計人員能輕易在模塊級集成最終的子系統(tǒng)。DesignWare的驗證IP除了能用于創(chuàng)建現(xiàn)實的應(yīng)用系統(tǒng)外,還能被用于在子系統(tǒng)級進(jìn)行完全測試主模塊和從模塊之間作用。使用這些IP可以確定符合AMBA 3 AXI協(xié)議規(guī)范。
DesignWare驗證IP和參考驗證方法DesignWare驗證IP采用重用分層的、覆蓋驅(qū)動的、隨機(jī)約束的驗證方法,它可用于快速產(chǎn)生上千種傳輸過程。
帶約束的隨機(jī)驗證的生成是通過Synopsys的參考驗證方法(RVM)定義的。RVM是在驗證方法手冊中目前可以獲取的最好的實踐方法。它為自動產(chǎn)生處理事務(wù)來強(qiáng)調(diào)協(xié)議組合的最大數(shù)目制定了一種強(qiáng)大的方法。隨機(jī)約束、覆蓋驅(qū)動的方法相比于傳統(tǒng)的定向測試方法,可以為大而復(fù)雜的設(shè)計提供更好的產(chǎn)品和質(zhì)量的驗證。在定向測試的方法下,工程師通過寫單個的測試來驗證特殊的設(shè)計特點。此方法耗時巨大,尤其對于擁有大量相互作用的復(fù)雜設(shè)備更是可觀。慢慢地,設(shè)計往往在達(dá)到驗證質(zhì)量目標(biāo)前就流片,因而加大了提高成本的可能。
通過一種隨機(jī)約束、覆蓋驅(qū)動的方法,工程師可以為設(shè)計寫出描述實際輸入情形的高級的約束。先進(jìn)的驗證工具和驗證IP將使用這些約束自動產(chǎn)生成千種測試校驗實例而不用工程師去設(shè)計。功能覆蓋用于指導(dǎo)驗證和測量過程。它可以使驗證質(zhì)量目標(biāo)可以在流片之前較容易達(dá)到,即使對于更復(fù)雜的設(shè)計也是如此。參考驗證方法建于一種能重用的架構(gòu)之上,用于實現(xiàn)帶約束的隨機(jī)驗證環(huán)境,它能使模塊級的測試重用于模塊級、子系統(tǒng)級和多重項目之間。RVM驅(qū)動的驗證IP意味著設(shè)計人員只需寫最少的代碼,即可按順序產(chǎn)生成千上萬的測試,通過實際的總線流量足以強(qiáng)調(diào)模塊或子系統(tǒng)。基于Synopsys的RVM的環(huán)境提供了對于所有的驗證元件一種統(tǒng)一的接口,它極易理解,而且能加快地在其他的項目之間重用。
為加快一個基于AMBA 3 AXI協(xié)議系統(tǒng)的驗證,DesignWare驗證IP應(yīng)被用來依次驗證單個的元件接口,子系統(tǒng),最終是完整的系統(tǒng)。在模塊級,驗證IP可產(chǎn)生有效準(zhǔn)確的激勵以測試AMBA 3 AXI接口的應(yīng)用。如果測試是根據(jù)RVM指南生成的,此級別的測試可以在子系統(tǒng)級再次運行。由于DesignWare為AMBA 3 AXI的驗證IP均以通過AMBA3認(rèn)證,設(shè)計人員可以對于驗證過程的質(zhì)量足夠放心。
一個原始的基于AMBA 3 AXI的子系統(tǒng)的有效驗證可以用許多松散連接的IP和DesignWare驗證IP的設(shè)計模塊來實現(xiàn)。這樣可使互連、處理事務(wù)和特征能很快被驗證,同時很快創(chuàng)建一套高覆蓋率的測試。DesignWare驗證IP的主模塊和從模塊被用于替代元件,這樣主模塊的VIP即可用于創(chuàng)建定向和約束的隨機(jī)驗證事務(wù)。這種方法允許快速地創(chuàng)建子系統(tǒng)的激勵和響應(yīng),可以快速解決任何設(shè)計互連的問題。DesignWare驗證IP的監(jiān)視器被用于檢查是否適應(yīng)AMBA的需求以及提供和基于測試標(biāo)準(zhǔn)的得分板(scoreboard)的直接接口。
得分板實質(zhì)是測試程序的一個模塊,可提供一種自動智能的方法跟蹤事務(wù)、覆蓋和數(shù)據(jù)流。對于數(shù)據(jù),它可設(shè)置為跟蹤源標(biāo)準(zhǔn)數(shù)據(jù)并比較目標(biāo)數(shù)據(jù)來為所測試的數(shù)據(jù)路徑產(chǎn)生一個通過或失敗的標(biāo)準(zhǔn)。得分板和DesignWare驗證IP的監(jiān)視器直接相連,以使所有的事務(wù)和覆蓋數(shù)據(jù)被提取,捕獲和驗證。使用DesignWare驗證IP監(jiān)視器的優(yōu)點在于當(dāng)主模塊和從模塊的驗證IP被刪除或者被系統(tǒng)級別測試的真實RTL替代時,相同的基于得分板的驗證環(huán)境可以繼續(xù)使用。當(dāng)監(jiān)視器為無源元件時,它們可以用于整個驗證周期。
為了進(jìn)一步加快驗證過程,在模塊和子系統(tǒng)級的環(huán)境中應(yīng)該加入斷言IP從而能使用formal和hybrid formal的驗證工具,例如Synopsys的magllan工具。驗證環(huán)境應(yīng)包括驗證IP和斷言IP。驗證IP監(jiān)視器提供了高級模擬特征,例如:cross-port的覆蓋和得分板通告。由于ARM提供定義了斷言的IP作為可執(zhí)行規(guī)范,所以它可以作為參考的標(biāo)準(zhǔn)結(jié)果。所有的DesignWare的驗證IP元件已經(jīng)通過ARM提供的作為AMBA3確認(rèn)認(rèn)證過程的一部分的斷言IP的驗證。此外,DesignWare驗證IP的監(jiān)視器可以幫忙確定何時驗證完成,通過跟蹤和記錄每個事務(wù),提供覆蓋信息,給出違反規(guī)范的錯誤和警告。
驗證的最后一階段就是完整系統(tǒng)級別的驗證。在此階段,必須包括對于松散連接應(yīng)用的元件的RTL和IP。外部接口必須經(jīng)過驗證,其他的DesignWare驗證IP此時可以用來減少系統(tǒng)級測試的負(fù)擔(dān)。設(shè)計人員能廣泛使用DesignWare Verificaion IP,它是作為VCS Verification Library的一部分,DesignWare Library產(chǎn)品包括PCI Express?、串行IO、I2C、以太網(wǎng)、USB、USB-OTG以及成千上萬種基于存儲器的模型。DesignWare Verification IP中為ABMA 3 AXI的主模塊仍應(yīng)用于產(chǎn)生激勵因為原始子系統(tǒng)的測試能立即重用。另外的DesignWare Verification IP 還可以直接和得分板一起提供完整的智能驗證平臺。
驗證工程師也希望盡可能快地模擬驗證設(shè)計、標(biāo)準(zhǔn)測試、驗證IP和斷言IP。Synopsys VCS?模擬器可得到很高的模擬性能。VCS把完整的設(shè)計環(huán)境、設(shè)計、標(biāo)準(zhǔn)測試、驗證IP和斷言IP優(yōu)化成單個統(tǒng)一的內(nèi)核。這單個編譯的內(nèi)核能消除傳統(tǒng)模擬環(huán)境中經(jīng)常出現(xiàn)的通信和同步的問題。此方法具有5倍或者更多的模擬性能提高。對于驗證工程,這意味著以前需5天運行的測試現(xiàn)在可以在1天以內(nèi)完成。工程師能有更多的時間確保覆蓋數(shù)目,提高最終設(shè)計的信心。
集成一體:DesignWare IP和Synopsys的coreAssembler工具DesignWare IP的解決方案的第三部分,是Synopsys的coreAssembler工具。當(dāng)DesignWare Library IP和coreAssembler工具一起使用時,設(shè)計人員可在更少的時間內(nèi)自動集成模擬和綜合基于AMBA的子系統(tǒng)。coreAssembler工具能使子系統(tǒng)自動生成設(shè)計和AMBA 3 AXI和AMBA 2.0 AHB/APB元件的模塊集成。coreAsembler工具可減少含有DesignWare IP的專用子系統(tǒng)的生成時間。這再次讓設(shè)計人員可以專注于產(chǎn)品的其他測試或者差異性設(shè)計。coreAssembler工具完全支持“在工具流程內(nèi)專為封裝、集成和重用IP的結(jié)構(gòu)”,SPIRIT,格式,適合SPIRIT的第三部分和定制IP模塊能輕而易舉地封裝到裝配子系統(tǒng)。
本文為全文原貌 未安裝PDF瀏覽器用戶請先下載安裝 原版全文
在打包DesignWare的可綜合IP和驗證IP時使用了“裝配導(dǎo)向技術(shù)”。這是內(nèi)置的專門協(xié)議技術(shù),能使coreAssembler自動完成IP模塊的相互連接。Synopsys集成的專門技術(shù)是從AMBA IP和基于AMBA子系統(tǒng)的創(chuàng)建中多年形成的。它支持任何AMBA 3 AXI或者AMBA 2.0或者多層子系統(tǒng)的配置,另外還支持AMBALITE的配置。例如,設(shè)計人員具有AMBA 3 AXI互連的制造和AMBA 3 AXI到AMBA 2 AHB的橋元件,coreAssebler內(nèi)置的集成系統(tǒng)可以自動將兩個AMBA 3 AXI接口連接集成。這種自動構(gòu)造方法可以消除印制產(chǎn)生線的錯誤。所有的DesignWare Library 綜合IP元件和這種設(shè)計技術(shù)一起捆綁,還有一套缺省的參數(shù)。因此,產(chǎn)生一個子系統(tǒng)的初始設(shè)計就簡單到只需點幾下鼠標(biāo),選擇幾個下拉菜單以及配置一些子系統(tǒng)參數(shù)即可完成。
coreAssembler通過設(shè)計參數(shù)和系統(tǒng)級別參數(shù)的交叉?zhèn)鞑ヒ灾С謱哟问皆O(shè)計的方法,可以避免多重IP的錯誤配置。這些參數(shù),例如地址和數(shù)據(jù)寬度,可以在頂層被鎖住,然后傳播至低層次的IP模塊,可確保避免IP模塊的錯誤配置。這種內(nèi)置的自動化的參數(shù)檢查消除了IP配置錯誤的出現(xiàn)幾率,能大大減少子系統(tǒng)調(diào)試的時間。工程師能越快地完成第一個子系統(tǒng)的模擬和運行時間,驗證工程師就有越多的時間來驗證子系統(tǒng)需求功能的實現(xiàn)。
為得到最優(yōu)化的綜合結(jié)果,coreAssembler能自動運行Synopsys的綜合工具,包括PhysicalCompiler?和Design Compiler?。設(shè)計人員可以從多種綜合方法中選擇,例如面積-時延、時延-面積、ACS和低功耗優(yōu)化等等流程。coreAssembler 也可以將用戶定義的流程集成到其自動化的流程中。
為減少第一次模擬的時間,coreAssembler自動創(chuàng)建一個驗證的基礎(chǔ)架構(gòu),其包括DesignWare Verification IP專門達(dá)到集成子系統(tǒng)的目標(biāo)。另外產(chǎn)生這個架構(gòu)的同時,工具也產(chǎn)生DesignWare Verification IP用來測試子系統(tǒng)的激勵。目前,這些還是簡單的基礎(chǔ)測試,例如寫入一個IP元件的寄存器,再讀出來保證寫入的內(nèi)容的正確性。雖然這些看似容易,但其確是很多子系統(tǒng)設(shè)計的第一個里程碑,在傳統(tǒng)的子系統(tǒng)開發(fā)過程中,通常需要幾周的時間。使用DesignWare Library IP和coreAssembler流程,子系統(tǒng)的基礎(chǔ)測試可在幾個小時之內(nèi)完成。
自動化的流程也使設(shè)計新手變得很容易上手。比如,子系統(tǒng)以前是以32位數(shù)據(jù)線設(shè)計,而設(shè)計師在最后一分鐘決定需要使用64位數(shù)據(jù)總線以達(dá)到性能的要求。在傳統(tǒng)的設(shè)計流程中,工程師需要重新配置和修改很多RTL文件,它需要花費自己很多的時間,也許還會出現(xiàn)許多錯誤。而使用coreAssembler流程中,只需要通過一個在頂層一個參數(shù)的簡單修改就可以完成,這個修改可以自動地傳遞到所有低層次的模塊中。新的RTL代碼會重新自動產(chǎn)生,同時也生成新的測試架構(gòu)的文件。
總結(jié)
第2篇：soap協(xié)議范文
WebServices的基本元素是可擴(kuò)展標(biāo)記語言（ExtensibleMarkupLanguage，XML）、SOAP、Web服務(wù)描述語言（WebServicesDescriptionLanguage，WSDL）。XML用來編解碼數(shù)據(jù)，SOAP用來傳輸數(shù)據(jù)，WSDL用來描述WebServices及如何訪問WebServices。XML與超文本標(biāo)記語言（HypertextMarkupLanguage，HTML）一樣，都是標(biāo)準(zhǔn)通用標(biāo)記語言（StandardGeneralizedMarkupLanguage，SGML）。XML是Internet環(huán)境中跨平臺的依賴于內(nèi)容的技術(shù)，是當(dāng)前處理結(jié)構(gòu)化文檔信息的有力工具。SOAP是一種簡單的基于XML的協(xié)議，使應(yīng)用程序通過超文本傳送協(xié)議（hypertexttransportprotocol，HTTP）交換信息。WSDL是基于XML的用來描述WebServices及如何訪問WebServices的一種語言。WSDL可描述WebServices，用于WebServices的消息格式和協(xié)議的細(xì)節(jié)。使用WebServices技術(shù)作為接口技術(shù)的基礎(chǔ)有以下優(yōu)點。1）數(shù)據(jù)交換。WebServices使數(shù)據(jù)交換更方便，實現(xiàn)跨防火墻的通信，以一種最簡單的方式實現(xiàn)異構(gòu)系統(tǒng)間的互通信和數(shù)據(jù)交換，且能跨平臺。2）數(shù)據(jù)封裝。WebServices使用XML對數(shù)據(jù)封裝，使用者能且僅能看到該對象提供的功能列表。3）應(yīng)用程序集成。不同編程語言編寫的應(yīng)用程序通常都有一定的應(yīng)用環(huán)境，集成起來會有很多技術(shù)壁壘，需要花費較多資源才能實現(xiàn)。通過WebServices，應(yīng)用程序可用標(biāo)準(zhǔn)的方法把功能和數(shù)據(jù)“暴露”出來，供其他應(yīng)用程序使用，簡單方便。4）低成本。在實際項目中的開發(fā)成本最低，無論從軟件開發(fā)人員的培訓(xùn)和WebServices產(chǎn)品的購買都較廉價。
2接口的技術(shù)方案
2.1采用基于中間數(shù)據(jù)庫視圖方式
根據(jù)需要對外發(fā)送的數(shù)據(jù)，組織SQL語句，把結(jié)果以數(shù)據(jù)庫視圖的方式建立。其他系統(tǒng)的接口程序通過分配具有一定權(quán)限的賬戶，訪問中間數(shù)據(jù)庫視圖獲取數(shù)據(jù)。該方式的優(yōu)點：程序可自由訪問數(shù)據(jù)庫，訪問的內(nèi)容和訪問的組合方式均可由應(yīng)用程序自定義，并且可自定義SQL語句組織查詢結(jié)果。缺點：數(shù)據(jù)庫安全性差，非系統(tǒng)內(nèi)部程序可直接接觸到數(shù)據(jù)庫層面，對信息保密有隱患。
2.2采用基于REST風(fēng)格服務(wù)方式
表述性狀態(tài)轉(zhuǎn)移（RepresentationalStateTrans-fer，REST）代表了分布式超媒體系統(tǒng)的體系結(jié)構(gòu)風(fēng)格，是一種針對網(wǎng)絡(luò)應(yīng)用的設(shè)計和開發(fā)方式，可降低開發(fā)的復(fù)雜性，提高系統(tǒng)的可伸縮性。REST提出一些設(shè)計概念和準(zhǔn)則：①網(wǎng)絡(luò)上的所有事物都被抽象為資源；②每個資源對應(yīng)一個唯一的資源標(biāo)識；③通過通用的連接器接口對資源進(jìn)行操作；④對資源的各種操作不會改變資源標(biāo)識；⑤所有操作都是無狀態(tài)的。該方式的優(yōu)點：可利用緩存提高相應(yīng)速度。通信本身的無狀態(tài)性能使不同的服務(wù)器處理一系列請求中的不同請求，提高服務(wù)器可擴(kuò)展性。瀏覽器可作為客戶端，簡化軟件需求。缺點：安全性比SOAP低。對HTTP的依賴性高，需要通過HTTP的返回碼區(qū)分返回結(jié)果。
2.3用基于SOAP協(xié)議的WebServices調(diào)用方式
SOAP可以和現(xiàn)存的多種因特網(wǎng)協(xié)議和格式結(jié)合使用，包括HTTP，簡單郵件傳輸協(xié)議（SimpleMailTransferProtocol，SMTP），多用途網(wǎng)際郵件擴(kuò)充協(xié)議（MultipurposeInternetMailExtensions，MIME）。還支持從消息系統(tǒng)到遠(yuǎn)程過程調(diào)用協(xié)議（RemoteProcedureCallProtocol，RPC）等大量的應(yīng)用程序。該方式具備以下優(yōu)點。1）具有可擴(kuò)展性。SOAP客戶端、服務(wù)器和協(xié)議自身均能吸納新技術(shù)不斷發(fā)展，而且升級更新時也不必中斷已有的應(yīng)用程序。2）SOAP調(diào)用簡單。客戶端只需發(fā)送一個請求，服務(wù)器獲取請求后調(diào)用相應(yīng)的對象，然后把調(diào)用的結(jié)果返回給客戶端，完成一次調(diào)用交互。3）SOAP完全和廠商無關(guān)，與編程語言、平臺無關(guān)。缺點：較復(fù)雜，對于大量并發(fā)應(yīng)用，效率不高。根據(jù)以上方案的比較，結(jié)合智能電網(wǎng)通信管理系統(tǒng)對接口方面的要求，綜合利弊，采用基于SOAP的WebServices方式實現(xiàn)接口功能。
3接口的設(shè)計與解析
3.1功能結(jié)構(gòu)
智能電網(wǎng)通信管理系統(tǒng)接口軟件（以下簡稱接口）采用接口調(diào)用方主動發(fā)起數(shù)據(jù)請求，接口提供方返回相應(yīng)請求數(shù)據(jù)的應(yīng)答模式。接互示意如圖1所示。
3.2技術(shù)約定
為保證不同廠家開發(fā)的接口服務(wù)端和客戶端軟件能順利實現(xiàn)接口調(diào)用，對WebServices具體接口實現(xiàn)過程作出如下規(guī)范及版本約定：1）整個接口消息基于XML語言，必須符合XMLV1.0（及更高版本）規(guī)范和XMLSchema（及更高版本）規(guī)范；2）接口實現(xiàn)必須使用SOAP協(xié)議，接口描述必須使用WSDL語言；3）接口實現(xiàn)方必須向接口調(diào)用方提供本端服務(wù)的WSDL文件，建議使用WebURL方式實時提供；4）接口實現(xiàn)必須符合SOAPV1.1版本規(guī)范，高版本SOAP協(xié)議必須保證與1.1版本的兼容性；5）接口實現(xiàn)必須至少支持SOAP在HTTPV1.0協(xié)議上的傳輸；6）接口實現(xiàn)必須符合WSDLV1.1版本規(guī)范，高版本W(wǎng)SDL語言必須保證與1.1版本的兼容性；7）接口描述必須至少支持WSDL在SOAPV1.1協(xié)議上的綁定；8）接口實現(xiàn)必須支持WS-IBasicProfileV1.0（及更高版本）互聯(lián)互通協(xié)議。
4結(jié)語
第3篇：soap協(xié)議范文
1系統(tǒng)概述
企業(yè)服務(wù)總線的核心是由消息監(jiān)聽器、適配器、協(xié)議轉(zhuǎn)換器、消息路由器和服務(wù)調(diào)度器五部分組成.協(xié)議轉(zhuǎn)換作為企業(yè)服務(wù)總線的核心功能之一,可以為注冊到企業(yè)服務(wù)總線上的服務(wù)提供者和服務(wù)請求者提供可靠的交互服務(wù).ESB系統(tǒng)總體框架圖如圖1所示.企業(yè)服務(wù)總線的主要功能包括如下部分:1.消息監(jiān)聽功能:監(jiān)聽基于不同協(xié)議的消息.2.服務(wù)請求者與服務(wù)提供者之間的應(yīng)用協(xié)議的轉(zhuǎn)換:如果服務(wù)請求消息基于的協(xié)議與服務(wù)提供者所注冊的協(xié)議不同或者服務(wù)提供者所提供的服務(wù)消息是服務(wù)請求者無法解析,則需要對該協(xié)議進(jìn)行轉(zhuǎn)換.3.服務(wù)之間的消息轉(zhuǎn)發(fā)(路由):把請求消息轉(zhuǎn)發(fā)到目標(biāo)的服務(wù)地址.4.服務(wù)定位:查找服務(wù)的目標(biāo)地址.5.服務(wù)安全:對請求消息進(jìn)行認(rèn)證授權(quán).在企業(yè)服務(wù)總線中,協(xié)議轉(zhuǎn)換器主要功能就是如果請求消息基于的協(xié)議與服務(wù)者所采用的協(xié)議不同,則需要對該協(xié)議進(jìn)行轉(zhuǎn)換.
2協(xié)議轉(zhuǎn)換器的需求分析
各個系統(tǒng)在需要與其他系統(tǒng)交互的時候,要通過調(diào)用ESB來訪問目標(biāo)系統(tǒng)提供的服務(wù)接口獲取數(shù)據(jù),完成業(yè)務(wù)操作.各應(yīng)用系統(tǒng)作為服務(wù)消費方在調(diào)用ESB的時候,需要明確每個參數(shù)代表的含義,按照參數(shù)書寫格式要求來發(fā)送參數(shù),然后ESB會自動調(diào)用消費方服務(wù).但連接到ESB上的服務(wù)請求者和服務(wù)提供者可能采用不同的應(yīng)用協(xié)議,針對不同的應(yīng)用協(xié)議,ESB的監(jiān)聽器接收到的請求消息有不同的協(xié)議格式.如果ESB能夠支持現(xiàn)有的各種通信協(xié)議,那么對消息的處理就完全不考慮傳輸細(xì)節(jié),而直接通過消息請求和獲取服務(wù).如果沒有將一種協(xié)議轉(zhuǎn)換為另一種協(xié)議的工具,則服務(wù)請求者很難與給定的服務(wù)提供者進(jìn)行通信.與此需求相關(guān)的需求是使用者的數(shù)據(jù)格式可能與服務(wù)提供者使用的數(shù)據(jù)格式不同.因此,需要一種能夠提供此轉(zhuǎn)換的工具.
關(guān)鍵技術(shù)
1基本定義
SOAP即簡單對象訪問協(xié)議,是一個輕量級的、簡單的、基于XML進(jìn)行信息交換的通信協(xié)議.它可以和現(xiàn)存的許多因特網(wǎng)協(xié)議進(jìn)行結(jié)合使用,包括HTTP,SMTP.JMS是實現(xiàn)JAVA領(lǐng)域遠(yuǎn)程通信的一種手段和方法,是個遠(yuǎn)程通信協(xié)議,在其他的語言體系中也存在著類似JMS的東西,可以統(tǒng)一的將這類機(jī)制稱為消息機(jī)制.XML(ExtensibleMarkupLanguage)即可擴(kuò)展標(biāo)記語言,它是萬維網(wǎng)協(xié)會的XML工作小組所定義的可擴(kuò)展標(biāo)記語言,是一組規(guī)則與準(zhǔn)則的集合.XML作為通用的、自解釋的數(shù)據(jù)交換格式,已成為大多數(shù)應(yīng)用程序所采用,XML技術(shù)可以有效地解決不同協(xié)議下的數(shù)據(jù)之間的共享與交互.
XML現(xiàn)在已經(jīng)成為一種通用的數(shù)據(jù)交換格式,它的平臺無關(guān)性,語言無關(guān)性,系統(tǒng)無關(guān)性,給數(shù)據(jù)集成與交互帶來了極大的方便.XML是從標(biāo)準(zhǔn)通用標(biāo)記語言(SGML)中簡化修改出來的.XML將SGML的靈活性和強(qiáng)大功能與已經(jīng)被廣泛采用的HTML結(jié)合起來,簡化了計算機(jī)對文檔和數(shù)據(jù)交換的處理,使得現(xiàn)有的協(xié)議和軟件更為協(xié)調(diào),從而簡化了數(shù)據(jù)的處理和傳輸.使用XML標(biāo)記語言可以做到數(shù)據(jù)或數(shù)據(jù)結(jié)構(gòu)在任何編程語言環(huán)境下的共享.XML最大的優(yōu)勢在于它能對各種編程語言編寫的數(shù)據(jù)進(jìn)行管理,使得在任何平臺下都能通過解析器來讀取XML數(shù)據(jù).XML標(biāo)記語言的語法非常簡單,可以通過解析器在任何機(jī)器上解讀.并可以在各種計算機(jī)平臺上使用.逐漸成為一種數(shù)據(jù)交換的語言.
2協(xié)議轉(zhuǎn)換思想
ESB支持廣泛使用的協(xié)議(HTTP,JMS,SOAP等等).目前,我們設(shè)計的ESB系統(tǒng)支持的協(xié)議有:HTTP、SOAP和JMS協(xié)議,以后還將對其進(jìn)行擴(kuò)展.協(xié)議轉(zhuǎn)換模型用于當(dāng)服務(wù)的請求者與服務(wù)提供者基于不同協(xié)議時的消息轉(zhuǎn)換.消息監(jiān)聽部分監(jiān)聽到消息后,對其進(jìn)行適配,然后將其傳遞給協(xié)議轉(zhuǎn)換部分,協(xié)議轉(zhuǎn)換器主要負(fù)責(zé)將采用不同協(xié)議的消息轉(zhuǎn)換成內(nèi)部標(biāo)準(zhǔn)消息,經(jīng)由消息路由器路由后將其封裝成目標(biāo)方要求的協(xié)議形式的消息傳遞到目標(biāo)方.在進(jìn)行協(xié)議轉(zhuǎn)換時,標(biāo)準(zhǔn)消息的內(nèi)容主要由以下幾部分組成:用戶名、角色類型、IP地址、端口號、消息的狀態(tài)、消息的尋址信息和業(yè)務(wù)數(shù)據(jù).
網(wǎng)絡(luò)上傳輸?shù)南⒌膬?nèi)容常常分為消息頭和消息體,如應(yīng)用層的HTTP、SOAP、JMS消息.業(yè)務(wù)相關(guān)內(nèi)容存入消息體中,消息頭中包含與業(yè)務(wù)無關(guān)的管理信息,比如消息的優(yōu)先級、序列號、地址信息等.因此,對消息進(jìn)行解析時,可以對其消息頭和消息體分別進(jìn)行解析.譬如SOAP消息都使用XML形式編碼.處理接收到的SOAP消息應(yīng)該有兩個步驟,首先,識別應(yīng)用程序需要的SOAP消息的頭部分;其次,識別應(yīng)用程序需要的SOAP消息體部分;最后,檢驗該SOAP消息是否滿足要求,即消息的目的地址、參數(shù)信息等是否和目標(biāo)地址名稱、參數(shù)等相對應(yīng).
協(xié)議轉(zhuǎn)換模型設(shè)計與實現(xiàn)
1并行XML解析
XML在不同的語言里解析方式通常都是一樣的.基本的解析方式有兩種:SAX和DOM.利用SAX解析XML文檔,牽涉到兩個部分:解析器和事件處理器.解析器負(fù)責(zé)讀取XML文檔,并向事件處理器發(fā)生事件,如元素開始和元素結(jié)束事件;而事件處理器則負(fù)責(zé)對事件做出響應(yīng),對傳遞的XML數(shù)據(jù)進(jìn)行處理.DOM是基于XML文檔樹結(jié)構(gòu)的解析,DOM在分析XML文檔時,將組成XML文檔的各個部分映射為一個對象,在內(nèi)存中,這些節(jié)點形成一棵文檔樹,整棵樹是一個節(jié)點,樹中的每一個節(jié)點也是一棵樹,通過訪問樹中的節(jié)點來存取XML文檔的內(nèi)容.為了提高系統(tǒng)的效率,在這個協(xié)議解析器中,我們將采用一種并行的XML解析方式.并行XML解析可以充分利用多核計算機(jī)的優(yōu)勢來提高系統(tǒng)的性能.具體實現(xiàn)方式為:首先對XML文件進(jìn)行預(yù)解析,根據(jù)預(yù)解析的結(jié)果將XML文件劃分為多個小的XML文件,并將這些XML文件分配到不同的線程上,從而這些劃分后的XML文件就可以并行地進(jìn)行解析.
2協(xié)議轉(zhuǎn)換模型
在不同系統(tǒng)或不同系統(tǒng)的組成部分之間傳輸數(shù)據(jù)時,必須考慮接口參數(shù)差異問題.不同格式的數(shù)據(jù)是難以在系統(tǒng)內(nèi)部或者系統(tǒng)間傳輸?shù)?因此協(xié)議轉(zhuǎn)換器要解決這種異構(gòu)的問題.鑒于業(yè)務(wù)相關(guān)內(nèi)容通常存入消息體中,消息頭中包含與業(yè)務(wù)無關(guān)的管理信息,協(xié)議轉(zhuǎn)換器以分層方式進(jìn)行轉(zhuǎn)換,主要包括2個部分:消息頭轉(zhuǎn)換和消息體的轉(zhuǎn)換.在進(jìn)行協(xié)議轉(zhuǎn)換時,要對ESB系統(tǒng)支持的各個協(xié)議建立模型,每當(dāng)需要某種協(xié)議解析時,都要讀取對應(yīng)的協(xié)議模型信息.協(xié)議轉(zhuǎn)換可能會出現(xiàn)解析失敗的情況,這就要求將失敗信息記錄到日志文件中,方便系統(tǒng)查閱并進(jìn)行處理.
為進(jìn)行協(xié)議轉(zhuǎn)換,消息或服務(wù)必須要先進(jìn)行適配,在初次連接或者其協(xié)議發(fā)生變化時,要填寫其協(xié)議的格式,在此設(shè)計一個表格存儲在注冊庫中.這一表格包括字段序號(SQ),消息名稱,消息序號,消息類型,字段名稱,起始位,長度,字段類型,字段描述.其中,消息類型是指消息所使用的協(xié)議.協(xié)議轉(zhuǎn)換示意圖如圖2所示。協(xié)議轉(zhuǎn)換器要把收到的不同協(xié)議格式的消息轉(zhuǎn)換為內(nèi)部統(tǒng)一的消息格式即XML的格式,以方便內(nèi)部消息路由器對消息的路由;消息路由器對消息路由后,由系統(tǒng)內(nèi)向服務(wù)提供方或者服務(wù)請求方發(fā)送數(shù)據(jù)時,協(xié)議轉(zhuǎn)換器實現(xiàn)讀取XML文件,按照數(shù)據(jù)庫中對應(yīng)的注冊的協(xié)議的要求,形成指定的消息類型,并發(fā)送到目的地.而這里的轉(zhuǎn)換是需要服務(wù)請求方和服務(wù)提供方提前注冊他們支持的協(xié)議的詳細(xì)信息,我們將這些信息分別都保存在不同的表格里,并存入注冊庫.
因此,協(xié)議轉(zhuǎn)換器有兩個功能要實現(xiàn).一個是將接收到的消息轉(zhuǎn)換為內(nèi)部數(shù)據(jù)格式即XML文件.另一個功能是將內(nèi)部表示的XML文件轉(zhuǎn)換為注冊庫中查找到的目標(biāo)協(xié)議格式,在這一過程中,需要使用并行XML解析方式對XML文件進(jìn)行解析,從而能夠快速地實現(xiàn)協(xié)議轉(zhuǎn)換.在這個轉(zhuǎn)換的過程中,ESB系統(tǒng)首先要建立所支持的JMS、HTTP和SOAP協(xié)議的模型,從而為協(xié)議轉(zhuǎn)換提供相關(guān)的信息.協(xié)議轉(zhuǎn)換器過程圖如圖3所示,在這里以JMS和SOAP協(xié)議轉(zhuǎn)換為例.若獲取到對方的JMS或者SOAP消息,則在存入數(shù)據(jù)庫的同時,要首先根據(jù)之前注冊的JMS或者SOAP模型將JMS或者SOAP消息轉(zhuǎn)換為XML的格式,統(tǒng)一消息格式,方便系統(tǒng)對數(shù)據(jù)的處理.當(dāng)傳輸數(shù)據(jù)時,若傳輸?shù)氖瞧渌问降南?則其消息格式 為消息描述指定的格式,協(xié)議轉(zhuǎn)換器就利用消息描述表中對消息的內(nèi)容的描述進(jìn)行轉(zhuǎn)換,將XML格式的消息轉(zhuǎn)換為JMS或者SOAP消息.實質(zhì)上,在協(xié)議轉(zhuǎn)換器中,消息的轉(zhuǎn)換包括兩個層次上的協(xié)議轉(zhuǎn)換:服務(wù)請求方的數(shù)據(jù)到系統(tǒng)內(nèi)部的協(xié)議轉(zhuǎn)換,系統(tǒng)內(nèi)部的消息到服務(wù)提供方的協(xié)議轉(zhuǎn)換;服務(wù)提供方的消息到系統(tǒng)內(nèi)部的協(xié)議轉(zhuǎn)換,以及系統(tǒng)內(nèi)部的消息到服務(wù)提供方的協(xié)議轉(zhuǎn)換.
3協(xié)議轉(zhuǎn)換器的可擴(kuò)展性
設(shè)計模式使人們可以更加簡單方便地復(fù)用成功的設(shè)計和體系結(jié)構(gòu).為了實現(xiàn)協(xié)議轉(zhuǎn)換器的可擴(kuò)展性,協(xié)議轉(zhuǎn)換器的實現(xiàn)中應(yīng)用了工廠模式和適配器模式.協(xié)議轉(zhuǎn)換器的類圖如圖4所示:在協(xié)議轉(zhuǎn)換器的實現(xiàn)中,AbstractTransformer是所有協(xié)議轉(zhuǎn)換的一個基類,并且是一個抽象類,實現(xiàn)了接口Transformer和Amnotatedobject.其它的轉(zhuǎn)換類都實現(xiàn)了AbstractTransformer.
結(jié)語
第4篇：soap協(xié)議范文
關(guān)鍵詞： Android； Web Service； 智能家居； 嵌入式網(wǎng)關(guān)； 視頻監(jiān)控
中圖分類號：TP311 文獻(xiàn)標(biāo)志碼：A 文章編號：1006-8228（2017）03-44-04
Abstract： For the smart home system controlled by PC has disadvantages in price， mobility and operation， a new design and implantation scheme of smart home system based Web Service is proposed. The embedded Web Service server and ONVIF video monitoring server are built by transplanting gSOAP， the client end is realized by using KSOAP2 development kit. Users can control and monitor the remote smart home devices via Android phone and tablet. The system has advantage of simple， low cost， portable and practical， and it is worth to be promoted.
Key words： Android； Web Service； smart home； embedded gateway； video monitor
0 引言
智能家居（smart home）系統(tǒng)通過將家居設(shè)備進(jìn)行組網(wǎng)，將計算機(jī)技術(shù)和自動化技術(shù)進(jìn)行整合，實現(xiàn)居家環(huán)境監(jiān)測、視頻監(jiān)控、家電控制，以及危險預(yù)警系統(tǒng)等諸多服務(wù)，提高了人們的生活水平，現(xiàn)在正在慢慢走進(jìn)人們的生活[1]。目前，大多數(shù)的智能家居系統(tǒng)采用PC機(jī)進(jìn)行控制，這種控制系統(tǒng)造價高，不能移動，不方便操作。采用手機(jī)或者平板電腦遠(yuǎn)程連接家庭網(wǎng)絡(luò)，可以方便快捷的實施監(jiān)控[2-5]。但是，目前采用這種手機(jī)或平板控制的智能家居系統(tǒng)比較少，而且大部分的功能比較單一，界面設(shè)計簡單，無法提供良好的用戶體驗。
本文提出了一種采用Web Service技術(shù)的智能家居系統(tǒng)實現(xiàn)方案。用戶可以通過運行Android系統(tǒng)的智能手機(jī)或者平板，連接家庭網(wǎng)關(guān)，對家用電器進(jìn)行遠(yuǎn)程控制，對居家環(huán)境進(jìn)行遠(yuǎn)程視頻監(jiān)控。
1 系統(tǒng)硬件平臺
智能家居網(wǎng)絡(luò)總體框架如圖1所示。家庭中各個網(wǎng)傳感節(jié)點和Zigbee協(xié)調(diào)器組成星型通信網(wǎng)絡(luò)。各個傳感器節(jié)點和家居設(shè)備以Zigbee方式和協(xié)調(diào)器通信，協(xié)調(diào)器通過串口連接網(wǎng)關(guān)。本系統(tǒng)的網(wǎng)關(guān)采用基于ARM1176JZF-S內(nèi)核，主頻533MHz的高性能嵌入式芯片S3C6410。網(wǎng)關(guān)上組建嵌入式Web服務(wù)器和視頻服務(wù)器，提供Web Service服務(wù)。運行在手機(jī)或平板上的智能家居控制系統(tǒng)客戶端通過調(diào)用Web Service服務(wù)實現(xiàn)以下功能。
⑴ 通過獲取溫度傳感器、濕度傳感器、光照度傳感器、紅外傳感器的數(shù)據(jù)，實現(xiàn)對居室環(huán)境數(shù)據(jù)進(jìn)行持續(xù)的采集。
⑵ 對智能家電、智能窗簾和智能燈具等設(shè)備的控制。
⑶ 調(diào)用攝像機(jī)實現(xiàn)遠(yuǎn)程視頻監(jiān)控。
2 軟件框架
2.1 程序架構(gòu)
本系統(tǒng)采用目前流行的Web Service技術(shù)，實現(xiàn)安卓客戶端和網(wǎng)關(guān)服務(wù)器之間的通信。Web Service是一種跨平臺的分布式Web應(yīng)用程序。Web Service服務(wù)由服務(wù)器提供，客戶端可以在網(wǎng)絡(luò)上的任何一個位置調(diào)用此服務(wù)。Web Service三個重要的組成部分是SOAP、WSDL（Web Services Description Language）和UDDI（Universal Description Discovery and Integration） [6]。SOAP是一個基于XML的輕量型分布式計算協(xié)議，定義了調(diào)用Web Service服務(wù)的標(biāo)準(zhǔn)方法；WSDL用于描述訪問具體的接口的方式；UDDI用來管理、分發(fā)和查詢Web Service。
軟件框架如圖2所示。客戶端和服務(wù)器之間通過HTTP協(xié)議進(jìn)行SOAP消息的傳遞。網(wǎng)關(guān)服務(wù)器運行Linux操作系統(tǒng)，提供基于SOCKET的HTTP協(xié)議通信協(xié)議。然后再移植開源Web Service工具gSOAP來提供Web Service服務(wù)所需要的XML解析器和SOAP處理器。
2.2 服掌鞫順絳蟶杓
服務(wù)器端程序設(shè)計步驟：首先生成C/C++頭文件；然后使用SOAP編譯器編譯后生成RPC服務(wù)框架和序列化的數(shù)據(jù)類型代碼；最后將這些代碼鏈接到服務(wù)應(yīng)用程序中，就成為可供客戶端調(diào)用的Web Service。gSOAP編譯器同時會生成一個WSDL文檔用于描述這些服務(wù)。
在本設(shè)計中，客戶端的請求分為POST和GET兩種方法。GET方法用來處理靜態(tài)網(wǎng)頁，進(jìn)而為描述接口的WSDL文件提供支持。POST方法用來實現(xiàn)SOAP消息的傳輸，將接收到的HTTP數(shù)據(jù)包保存在內(nèi)存緩沖區(qū)，然后再進(jìn)行進(jìn)一步的處理。網(wǎng)關(guān)服務(wù)器對SOAP消息的處理過程如圖3所示。服務(wù)器在接受到客戶端的HTTP請求以后，調(diào)用相關(guān)模塊解析SOAP消息，然后根據(jù)解析結(jié)果提供相應(yīng)的服務(wù)。最后將執(zhí)行結(jié)果封裝成SOAP響應(yīng)信息返回給客戶端。
2.3 視頻服務(wù)器程序設(shè)計
采用建立在Web Service的SOAP通信框架基礎(chǔ)之上的ONVIF通信標(biāo)準(zhǔn)，進(jìn)行視頻服務(wù)器設(shè)計。ONVIF通過定義網(wǎng)絡(luò)視頻設(shè)備之間信息交換的通用標(biāo)準(zhǔn)，以實現(xiàn)不同廠家的視頻產(chǎn)品之間的互通性。ONVIF也是使用WSDL定義服務(wù)，使用XML語言描述數(shù)據(jù)，采用SOAP通信協(xié)議傳輸信息。ONVIF標(biāo)準(zhǔn)包括設(shè)備發(fā)現(xiàn)和設(shè)備管理兩大功能模塊，前者通過基于IP組播技術(shù)實現(xiàn)，后者通過傳遞SOAP消息進(jìn)行通信。SOAP通信框架按照以下步驟生成[7]。
⑴ 登錄ONVIF網(wǎng)下載WSDL文件，該文件描述了與媒體服務(wù)相關(guān)的Web服務(wù)消息格式、操作、數(shù)據(jù)類型、協(xié)議綁定和服務(wù)地址。
⑵ 從網(wǎng)上下載gSOAP 2.8.21工具，解壓后得到的wsdl2h和soapcpp2文件。
⑶ 使用wsdl2h工具將WSDL文件轉(zhuǎn)換成C/C++風(fēng)格的頭文件。
⑷ 使用soapcpp2工具將上一步產(chǎn)生的頭文件生成服務(wù)器端提供SOAP服務(wù)的框架（Skeleton）代碼。
3 安卓客戶端程序設(shè)計
3.1 客戶端與服務(wù)器之間的通信
在Android客戶端平臺上，調(diào)用服務(wù)器端的Web Service必須使用開發(fā)包KSOAP2，以實現(xiàn)SOAP協(xié)議的處理。KSOAP2是一個用于資源受限制的Java環(huán)境如Applets或J2ME應(yīng)用程序的第三方類庫。
安卓客戶端通過調(diào)用服務(wù)器端的Web Service服務(wù)，通過對遠(yuǎn)程數(shù)據(jù)庫的查詢、控制和管理操作，從而實現(xiàn)對家居設(shè)備進(jìn)行控制和監(jiān)視。本設(shè)計采用的KSOAP2軟件工具可以封裝用戶請求，以SOAP格式來調(diào)用Web Service，然后將返回的SOAP格式的數(shù)據(jù)信息解析為SOAP Objecet對象。KSOAP2調(diào)用Web Service步驟如下。
⑴ 下載Ksoap2-Android工具，并導(dǎo)入工程。
⑵ 指定Web Service的命名空間和調(diào)用Web Service方法的名稱。
⑶ 借助Soap Object對象傳遞參數(shù)。
⑷ 生成調(diào)用Web Service方法的SOAP請求信息，并指定SOAP的版本。
⑸ 調(diào)用Web Service，根據(jù)返回的數(shù)據(jù)，解析出結(jié)果。
3.2 客戶端設(shè)計
客戶端連接服務(wù)器的第一步是登錄，進(jìn)行身份驗證，其流程如圖4所示。首先輸入服務(wù)器的用戶名和密碼。如果服務(wù)器驗證通過，就可以建立客戶端與服務(wù)器之間的交互通道，在主界面中接收服務(wù)器響應(yīng)數(shù)據(jù)幀，同時更新所有家居設(shè)備的狀態(tài)信息。用戶登錄成功后，可以執(zhí)行如下相應(yīng)的動作。
⑴ 如果要控制設(shè)備或者查詢設(shè)備狀態(tài)信息，則通過Get方法發(fā)送控制幀或者查詢幀。
⑵ 如果要執(zhí)行視頻監(jiān)控則通過POST方法發(fā)送視頻控制命令。
⑶ 如果用戶需要更改密碼，就要輸入舊、新兩種密碼，如果密碼匹配，則服務(wù)器返回響應(yīng)碼“201”，表示密碼更改成功；否則可以向服務(wù)器發(fā)送控制或者查詢請求，服務(wù)器收到后，先返回一個響應(yīng)，然后執(zhí)行相應(yīng)的動作。
3.3 視頻監(jiān)控客戶端設(shè)計
3.3.1 設(shè)備發(fā)現(xiàn)和管理
設(shè)備發(fā)現(xiàn)的主要目的就是獲取ONVIF設(shè)備的服務(wù)功能和服務(wù)地址，為后面的視頻數(shù)據(jù)接收和播放提供基礎(chǔ)。ONVIF協(xié)議的設(shè)備發(fā)現(xiàn)模塊可以讓客戶端發(fā)現(xiàn)服務(wù)器的RPC的入口，本設(shè)計采用WS-Discovery發(fā)現(xiàn)協(xié)議實現(xiàn)該功能。WS-Discovery [8]協(xié)議采用SOAP和UDP組播協(xié)議，客戶端使用239.255.255.250：3702地址發(fā)送組播消息自動搜索ONVIF設(shè)備。服務(wù)器端的ONVIF設(shè)備收到組播消息后進(jìn)行響應(yīng)，客戶端根據(jù)收到響應(yīng)數(shù)據(jù)包來獲取相應(yīng)的設(shè)備信息，統(tǒng)計搜索到的設(shè)備個數(shù)。
3.3.2 流媒體數(shù)據(jù)接收及分片打包
網(wǎng)關(guān)服務(wù)器攝像頭自帶視頻采集、視頻壓縮編碼功能，輸H.264格式編碼的標(biāo)準(zhǔn)數(shù)據(jù)流?？蛻舳送ㄟ^RTSP會話接收服務(wù)器端的流媒體數(shù)據(jù)，一次完整的會話過程如下。
⑴ 連接服務(wù)器，同時發(fā)送一個RTSP DESCRIBE命令。服務(wù)器返回一個描述媒體類型、流數(shù)量等信息SDP。
⑵ 分析收到的SDP，為會話中的流發(fā)送一個SETUP命令建立RTSP。客戶端通過此命令將自己的端口號告訴服務(wù)器。
⑶ 流媒體連接過程建立成功以后，客戶端發(fā)送PLAY命令和TERADOWN來開始和結(jié)束視頻的播放，還可以發(fā)送快進(jìn)、快進(jìn)和暫停命令。在播放過程中，服務(wù)器使用UDP發(fā)送流媒體RTP包給客戶端。
本系統(tǒng)需要多個ONVIF IPC設(shè)備通信，為了提高數(shù)據(jù)傳輸速率和數(shù)據(jù)處理的效率，課題組采用Select網(wǎng)絡(luò)模型完成標(biāo)準(zhǔn)的RTSP會話過程。
3.3.3 流媒體解碼及顯示
為了能顯示視頻，客戶端需要首先移植FFMPGE。使用FFMPGE對接收到的RTSP流媒體文件進(jìn)行解碼，再將解碼后的信息轉(zhuǎn)換成為YUNV420P格式，然后再轉(zhuǎn)換為RGB24格式。最后再轉(zhuǎn)換成可在安卓設(shè)備上播放的ARGB_8888格式。轉(zhuǎn)換完畢之后，就可以將每一幀顯示在屏幕上。
4 結(jié)論
本文結(jié)合嵌入式系統(tǒng)和安卓平臺優(yōu)勢， 采用目前流行的Web Service技術(shù)，設(shè)計和實現(xiàn)了智能家居系統(tǒng)的服務(wù)器端和安卓客戶端程序。服務(wù)器端通過移植gSOAP和ONVIF協(xié)議來組建嵌入式Web服務(wù)器，提供Web Service服務(wù)。安卓客戶端程序給予KSOAP2開發(fā)包進(jìn)行設(shè)計，實現(xiàn)了服務(wù)器端的Web Service服務(wù)的調(diào)用。系統(tǒng)主要采用JAVA語言進(jìn)行開發(fā)，具有結(jié)構(gòu)簡單，開發(fā)難度低的優(yōu)點。系統(tǒng)操作簡單、成本低、使用方便，可以實現(xiàn)家居設(shè)備的遠(yuǎn)程控制和居家環(huán)境的遠(yuǎn)程視頻監(jiān)視，給人們生活帶來極大的便利，具有較高的使用價值和推廣價值。
參考文獻(xiàn)（References）：
[1] Lin H T. Implementing smart homes with open sourcesolutions[J]. International Journal of Smart Home，2013.7.
[2] 周恩，李文軍，鄭永軍等.Android平臺的智能家居控制系統(tǒng)設(shè)計[J].中國計量學(xué)院學(xué)報，2013.24（3）：261-265
[3] Z陽靜，鄒念育，雷冬鳴等.基于Android和WIFI通信的智能家居系統(tǒng)設(shè)計[J].大連工業(yè)大學(xué)學(xué)報，2016.1：67-71
[4] 黃成云，盧選民，李戈.基于Android的智能家居控制軟件設(shè)計與實現(xiàn)[J].計算機(jī)與現(xiàn)代化，2014.11：102-105
[5] Kumar S. Ubiquitous Smart Home System Using AndroidApplication[J]. Computer Science，2014.6（1）.
[6] 龔瑞琴，畢利.基于Web Service的Android技術(shù)應(yīng)用研究[J].電子技術(shù)應(yīng)用，2014.40（1）：134-136
第5篇：soap協(xié)議范文
關(guān)鍵詞:Web服務(wù);端到端安全;SSL;ESSL
中圖分類號:TP309文獻(xiàn)標(biāo)識碼:A文章編號:1009-3044(2009)13-3383-02
1 引言
Web 服務(wù)是一個嶄新的分布式計算模型,是Web上數(shù)據(jù)和信息集成的有效機(jī)制[3]。Web服務(wù)的新型構(gòu)架,Web服務(wù)的高效執(zhí)行方式,Web服務(wù)與其他成熟技術(shù)的有機(jī)結(jié)合以及Web服務(wù)的集成是解決現(xiàn)實應(yīng)用問題的重要技術(shù)。但是,Web 服務(wù)的安全問題也日益的突出,并逐漸成為Web 服務(wù)向前發(fā)展的一個瓶頸。當(dāng)然國內(nèi)外,Web 服務(wù)安全的研究有也不少的成果。但是還是不能夠完全滿足Web服務(wù)的端到端的安全需求。本文討論了SSL在保障Web服務(wù)安全方面不足,并在此基礎(chǔ)上提出擴(kuò)展的SSL,用以滿足Web 服務(wù)端到端的安全需求,在最后對擴(kuò)展的協(xié)議進(jìn)行分析,說明了它的優(yōu)勢以及應(yīng)用的意義。
2 SSL在Web 服務(wù)安全機(jī)制中的應(yīng)用分析
2.1 Web 服務(wù)安全需求分析
作為典型的分布式應(yīng)用,Web 服務(wù)的安全要求包括:數(shù)據(jù)的機(jī)密性、數(shù)據(jù)的完整性、不可否認(rèn)性、身份認(rèn)證、訪問控制、審計和安全管理等多個方面,同時還具有自身的特點[1]。對于Web 服務(wù)來說,保障其安全需要end-to-end的安全。當(dāng)然這并不是說point-to-point的安全機(jī)制以及其他的傳統(tǒng)的安全不可以應(yīng)用到Web 服務(wù),恰恰相反,由于目前大多數(shù)哦Web 服務(wù)使用http作為其傳輸層,因此在依賴于http原來的安全機(jī)制都可以在Web services中使用[1],例如防墻、SSL等。Web 服務(wù)在實施的過程中也許需要point-to-point 和end-to-end其中的一種或兩種的安全機(jī)制,這取決于受到的威脅的所處層次[1]。如果對于安全性要求不高或者威脅的層次比較低的話,像SSL、防火墻等都可以發(fā)揮很好的作用[1]。
2.2 SSL協(xié)議概述
SSL 協(xié)議(Secure Socket Layer)是Netscape 推出的一種安全通信協(xié)議,它提供Internet上保密通信的安全協(xié)議。SSL的Client和Server在正式交換應(yīng)用數(shù)據(jù)之前,需要建立會話密鑰以及有選擇地進(jìn)行身份驗證。會話和連接是SSL的兩個重要的貫穿始終的概念。連接建立在會話的基礎(chǔ)上,每個連接與一個會話關(guān)聯(lián)。Cipher Spec和master secret組成一個會話的主要加密參數(shù),可被多個連接共享。每個連接有獨立的會話密鑰。
SSL的安全服務(wù)位于TCP和應(yīng)用層之間,對應(yīng)用層是透明的[2,5],可為應(yīng)用層如:HTTP、FTP、SMTP等提供安全業(yè)務(wù),服務(wù)對象主要是Web 應(yīng)用,即客戶瀏覽器和服務(wù)器。
SSL有三種驗證模式[5]:
1) Client和Server都被驗證;
2) 只驗證Server、不驗證Client;
3) 完全匿名。
SSL協(xié)議提供的服務(wù)可以歸納為如下三個方面[5]:
1) 連接是保密的,對稱加密用于加密數(shù)據(jù);
2) 實體的身份通過公鑰加密得到驗證;
3) 連接是可靠的,帶密鑰的MAC用于保證信息的完整性。
2.3 和SSL在Web服務(wù)中的應(yīng)用分析
盡管SSL在Web 服務(wù)中能夠提供一定的安全保障,但是它只能夠提供點對點的安全,如圖1所示,而無法保障端到端的安全,如圖2所示,在高要求或者威脅層次較高的時候,它就無法滿足要求。在Web 服務(wù)的典型應(yīng)用中,SOAP消息往往不僅僅只是在兩個節(jié)點間傳輸,更多的情況下是要經(jīng)過很多的中間節(jié)點[6-7],而且每個中間節(jié)點都可能會對SOAP消息進(jìn)行處理。雖然SSL可以確保SOAP消息在兩個相鄰的節(jié)點之間的安全,但是由于在節(jié)點內(nèi)部SOAP消息是以明文出現(xiàn)的,所以,一旦其中一個節(jié)點受到了攻擊或者惡意的修改SOAP消息,都會造成SOAP消息的泄漏或異常。因此,SSL對于SOAP消息的端到端的安全性是不夠的[4],必須有一種更高級級別的安全機(jī)制作為保障。
3 擴(kuò)展的ESSL
為了解決上面我們提到SSL協(xié)議在保障Web服務(wù)安全中的不足,對SLL進(jìn)行擴(kuò)展,稱之為擴(kuò)展的SSL協(xié)議(Extended SSL,簡稱ESSL),這個改進(jìn)保留了SSL原有的安全特性,又可以滿足Web服務(wù)的end-to-end的安全需求。(ESSL術(shù)語只在本文中適用)
3.1 相關(guān)標(biāo)記
為了準(zhǔn)確表達(dá),我們使用下面標(biāo)記:
Ii:第i個節(jié)點,其中I1是消息的原始發(fā)送者(Requester/Provider),In是消息最終收到的消息的(Requester/Provider),0
info:原始的信息
infoi:經(jīng)過Ii修改后的信息,由Ii加密后發(fā)送給Ii+1
Ceri:Ii的證書
h():使用安全的hash函數(shù)進(jìn)行對消息的摘要
ski:Ii的私鑰
pki:Ii的公鑰
sgni:Ii數(shù)字的簽名
Sign(ski,m):Ii用自己的私鑰對消息m進(jìn)行數(shù)字簽名
Rec(pki,s):用Ii的公鑰對簽名s進(jìn)行驗證
E(pki,m):用Ii的公鑰加密消息m
D(ski,s):Ii用自己的私鑰解密加密的消息s
ki:Ii隨機(jī)生成的對稱密鑰
E(ki,m):用ki進(jìn)行加密
D(ki,s):用ki進(jìn)行解密
3.2 協(xié)議的流程的詳細(xì)描述
首先要說明的是,兩個相互通信的節(jié)點,在進(jìn)行消息的傳遞之前要進(jìn)行握手,在握手的過程主要是交換相互的數(shù)字證書以及協(xié)商相關(guān)的加密算法等。
協(xié)議的流程如下:
1) I1:生成簽名:sgn1=Sign(sk1,h(info)),加密信息:E(k1,info),生成數(shù)字信封:E(pk2,k1),I1把(sgn1,E(k1,info),E(k1,info),E(pk2,k1),(sgn1,Cer1))發(fā)送給下一個通信節(jié)點。
2) 中間節(jié)點Ii(1
3) In:收到消息(sgnn-1,E (kn-1,infon-1), E (kn-1,info),E(pkn,kn-1),(sgn1,Cer1,)),In首先解開數(shù)字信封D(skn,E(pkn,kn-1)),獲得對稱密鑰kn-1,然后獲取信息info=D(kn-1,E(kn-1,info))和infon-1= D(kn-1,E(kn-1,infon-1)),驗證In-1的簽名Rec (pkn-1,sgnn-1)=h(D(kn-1,E(kn-1,infon-1)))?,然后在驗證I1的簽名和原始信息的完整性Rec (pk1,sgn1)=h(D(kn-1,E(kn-1,info)))?。如果驗證通過就進(jìn)行下一步的操作,如果沒有就終止通信。
協(xié)議中對消息的解密以及驗證的流程如圖3所示。
協(xié)議中對消息加密處理的流程圖如圖4所示。
說明:當(dāng)i=1的時候,虛線框中的處理過程就不需要了,因為info1=info
4 ESSL協(xié)議的分析
4.1 安全性分析
從ESSL的流程可以看出,SSL原有的安全機(jī)制都被包含,同時由于在消息中加入原始信息發(fā)送者對原始信息的簽名以及它的數(shù)字證書,另外在原始信息和修改后的信息都被發(fā)送到最終接收者In那里,這樣最終的接收者In不僅能夠看出來中間節(jié)點對原始信息的修改,同時還可以驗證原始的信息及其簽名和消息的完整性。另外,協(xié)議使用原來的數(shù)字信封以及對稱加密,使得消息的機(jī)密性也有了保障。(下轉(zhuǎn)第3397頁)
(上接第3384頁)
綜上所述,使用ESSL可以保證Web服務(wù)端到端的安全。
4.2 速度分析
為了能夠達(dá)到端到端的安全需求,ESSL多發(fā)送了很多“冗余”的信息并且做了附加的加密和驗證,這樣對于傳送的速度以及驗證速度勢必有所影響。但是,為了信息的安全或者特殊的安全需要,可以用性能換取高安全。
5 結(jié)束語
該文分析了Web服務(wù)的安全需求,指出了現(xiàn)有的SSL在保障Web服務(wù)安全中存在的不足,并在SSL協(xié)議的基礎(chǔ)上做出了改進(jìn),提出了ESSL,使其達(dá)到Web服務(wù)端到端的安全需求,從而能夠保障Web 服務(wù)的端到端的安全。另外,在其它要求端到端安全的環(huán)境中,ESSL也有著廣泛的用途。
參考文獻(xiàn):
[1] Web Services Architecture[EB/OL].(2004-02)./2002/ws/.
[2] 宋志敏,王衛(wèi)京,南相浩.SSL V3.0及其安全性分析[J].計算機(jī)工程與應(yīng)用2000(10):145-147.
[3] 岳昆,王曉玲,周傲.Web 服務(wù)核心支撐技術(shù):研究綜述[J].軟件學(xué)報,2004,15(3):428-442.
[4] IBM Corporation.Web Service Conceptual Architecture (WSCA1.0) [EB/OL]./developerworks/cn/views/webservices/libraryview.jsp.
[5] 范紅,馮登國.安全協(xié)議理論與方法[M].北京:科學(xué)出版社,2003.
[6] 錢權(quán),嚴(yán)家德.Web Service的安全機(jī)制[J].計算機(jī)工程,2007,33(22):190-192.
[7] 石偉鵬,楊小虎.基于SOAP協(xié)議的Web Service安全基礎(chǔ)規(guī)范(WS-Security)[J].計算機(jī)應(yīng)用研究,2003(2):100-102.
第6篇：soap協(xié)議范文
Web service是一個平立的，松耦合的，自包含的、基于可編程的web的應(yīng)用程序，可使用開放的XML標(biāo)準(zhǔn)來描述、、發(fā)現(xiàn)、協(xié)調(diào)和配置這些應(yīng)用程序，用于開發(fā)分布式的互操作的應(yīng)用程序。
集成化物流管理控制系統(tǒng)(iWMS) 是自動化立體庫中的靈魂和中樞。是一個基于UNIX/Windows操作系統(tǒng)、在網(wǎng)絡(luò)環(huán)境下實現(xiàn)客戶機(jī)/服務(wù)器模式的軟件系統(tǒng)。其目的是集成地管理、協(xié)調(diào)和調(diào)度物流有關(guān)的有關(guān)物流活動，并及時與ERP（企業(yè)資源管理系統(tǒng)）等系統(tǒng)交換信息。執(zhí)行ERP系統(tǒng)所下達(dá)的采購計劃和物料需求計劃等，并將執(zhí)行結(jié)果及時反饋。
關(guān)鍵字：Web Service
集成化物流管理控制系統(tǒng)
企業(yè)資源管理系統(tǒng)
中圖分類號：C29 文獻(xiàn)標(biāo)識碼：A 文章編號：
第一部分 引言
Web Service是一項新技術(shù)， 能使得運行在不同機(jī)器上的不同應(yīng)用無須借助附加的、專門的第三方軟件或硬件， 就可相互交換數(shù)據(jù)或集成。依據(jù)Web Service規(guī)范實施的應(yīng)用之間， 無論它們所使用的語言、 平臺或內(nèi)部協(xié)議是什么， 都可以相互交換數(shù)據(jù)。Web Service是自描述、 自包含的可用網(wǎng)絡(luò)模塊， 可以執(zhí)行具體的業(yè)務(wù)功能。Web Service也很容易部署， 因為它們基于一些常規(guī)的產(chǎn)業(yè)標(biāo)準(zhǔn)以及已有的一些技術(shù)，諸如XML和HTTP。Web Service減少了應(yīng)用接口的花費。Web Service為整個企業(yè)甚至多個組織之間的業(yè)務(wù)流程的集成提供了一個通用機(jī)制。
第二部分 介紹Web Service
簡單來說，Web Service是一種跨編程語言和跨操作系統(tǒng)平臺的遠(yuǎn)程調(diào)用技術(shù)。
其實可以從多個角度來理解Web Service，從表面上看，Web Service就是一個應(yīng)用程序向外界暴露出一個能通過Web進(jìn)行調(diào)用的API，也就是說能用編程的方法通過Web來調(diào)用這個應(yīng)用程序。我們把調(diào)用這個Web Service的應(yīng)用程序叫做客戶端，而把提供這個Web Service的應(yīng)用程序叫做服務(wù)端。從深層次看，Web Service是建立可互操作的分布式應(yīng)用程序的新平臺，是一個平臺，是一套標(biāo)準(zhǔn)。它定義了應(yīng)用程序如何在Web上實現(xiàn)互操作性，你可以用任何你喜歡的語言，在任何你喜歡的平臺上寫Web service ，只要我們可以通過Web service標(biāo)準(zhǔn)對這些服務(wù)進(jìn)行查詢和訪問。
Web Service平臺需要一套協(xié)議來實現(xiàn)分布式應(yīng)用程序的創(chuàng)建。任何平臺都有它的數(shù)據(jù)表示方法和類型系統(tǒng)。要實現(xiàn)互操作性，Web Service平臺必須提供一套標(biāo)準(zhǔn)的類型系統(tǒng)，用于溝通不同平臺、編程語言和組件模型中的不同類型系統(tǒng)。Web Service平臺必須提供一種標(biāo)準(zhǔn)來描述Web Service，讓客戶可以得到足夠的信息來調(diào)用這個Web Service。最后，我們還必須有一種方法來對這個Web Service進(jìn)行遠(yuǎn)程調(diào)用,這種方法實際是一種遠(yuǎn)程過程調(diào)用協(xié)議(RPC)。為了達(dá)到互操作性，這種RPC協(xié)議還必須與平臺和編程語言無關(guān)。
第一 Web Service的優(yōu)勢
平臺無關(guān)。不管你使用什么平臺，都可以使用Web service。
編程語言無關(guān)。只要遵守相關(guān)協(xié)議，就可以使用任意編程語言，向其他網(wǎng)站要求Web service。這大大增加了web service的適用性，降低了對程序員的要求。
對于Web service提供者來說，部署、升級和維護(hù)Web service都非常單純，不需要考慮客戶端兼容問題，而且一次性就能完成。
對于Web service使用者來說，可以輕易實現(xiàn)多種數(shù)據(jù)、多種服務(wù)的聚合（mashup），因此能夠做出一些以前根本無法想像的事情。
第二 Web Service的發(fā)展趨勢
在使用方式上，RPC和soap的使用在減少，Restful架構(gòu)占到了主導(dǎo)地位。
在數(shù)據(jù)格式上，XML格式的使用在減少，json等輕量級格式的使用在增多。
在設(shè)計架構(gòu)上，越來越多的第三方軟件讓用戶在客戶端（即瀏覽器），直接與云端對話，不再使用第三方的服務(wù)器進(jìn)行中轉(zhuǎn)或處理數(shù)據(jù)。
第三 Web Service平臺技術(shù)
XML+XSD,SOAP和WSDL就是構(gòu)成Web Service平臺的三大技術(shù)。
XML+XSD：
Web Service采用HTTP協(xié)議傳輸數(shù)據(jù)，采用XML格式封裝數(shù)據(jù)（即XML中說明調(diào)用遠(yuǎn)程服務(wù)對象的哪個方法，傳遞的參數(shù)是什么，以及服務(wù)對象的返回結(jié)果是什么）。XML是Web Service平臺中表示數(shù)據(jù)的格式。除了易于建立和易于分析外，XML主要的優(yōu)點在于它既是平臺無關(guān)的，又是廠商無關(guān)的。無關(guān)性是比技術(shù)優(yōu)越性更重要的：軟件廠商是不會選擇一個由競爭對手所發(fā)明的技術(shù)的。
XML解決了數(shù)據(jù)表示的問題，但它沒有定義一套標(biāo)準(zhǔn)的數(shù)據(jù)類型，更沒有說怎么去擴(kuò)展這套數(shù)據(jù)類型。例如，整形數(shù)到底代表什么？16位，32位，64位？這些細(xì)節(jié)對實現(xiàn)互操作性很重要。XML Schema(XSD)就是專門解決這個問題的一套標(biāo)準(zhǔn)。它定義了一套標(biāo)準(zhǔn)的數(shù)據(jù)類型，并給出了一種語言來擴(kuò)展這套數(shù)據(jù)類型。Web Service平臺就是用XSD來作為其數(shù)據(jù)類型系統(tǒng)的。當(dāng)你用某種語言(如或C#)來構(gòu)造一個Web service時，為了符合Web Service標(biāo)準(zhǔn)，所有你使用的數(shù)據(jù)類型都必須被轉(zhuǎn)換為XSD類型。你用的工具可能已經(jīng)自動幫你完成了這個轉(zhuǎn)換，但你很可能會根據(jù)你的需要修改一下轉(zhuǎn)換過程。
SOAP：
Web Service通過HTTP協(xié)議發(fā)送請求和接收結(jié)果時，發(fā)送的請求內(nèi)容和結(jié)果內(nèi)容都采用XML格式封裝，并增加了一些特定的HTTP消息頭，以說明HTTP消息的內(nèi)容格式，這些特定的HTTP消息頭和XML內(nèi)容格式就是SOAP協(xié)議。SOAP提供了標(biāo)準(zhǔn)的RPC方法來調(diào)用Web Service。
SOAP協(xié)議 = HTTP協(xié)議 + XML數(shù)據(jù)格式
SOAP協(xié)議定義了SOAP消息的格式，SOAP協(xié)議是基于HTTP協(xié)議的，SOAP也是基于XML和XSD的，XML是SOAP的數(shù)據(jù)編碼方式。打個比喻：HTTP就是普通公路，XML就是中間的綠色隔離帶和兩邊的防護(hù)欄，SOAP就是普通公路經(jīng)過加隔離帶和防護(hù)欄改造過的高速公路。
WSDL：
好比我們?nèi)ド痰曩I東西，首先要知道商店里有什么東西可買，然后再來購買，商家的做法就是張貼廣告海報。 Web Service也一樣，Web Service客戶端要調(diào)用一個Web Service服務(wù)，首先要有知道這個服務(wù)的地址在哪，以及這個服務(wù)里有什么方法可以調(diào)用，所以，Web Service務(wù)器端首先要通過一個WSDL文件來說明自己家里有啥服務(wù)可以對外調(diào)用，服務(wù)是什么（服務(wù)中有哪些方法，方法接受的參數(shù)是什么，返回值是什么），服務(wù)的網(wǎng)絡(luò)地址用哪個url地址表示，服務(wù)通過什么方式來調(diào)用。
WSDL(Web Services Description Language)就是這樣一個基于XML的語言，用于描述Web Service及其函數(shù)、參數(shù)和返回值。它是Web Service客戶端和服務(wù)器端都能理解的標(biāo)準(zhǔn)格式。因為是基于XML的，所以WSDL既是機(jī)器可閱讀的，又是人可閱讀的，這將是一個很大的好處。一些最新的開發(fā)工具既能根據(jù)你的Web service生成WSDL文檔，又能導(dǎo)入WSDL文檔，生成調(diào)用相應(yīng)Web Service的類代碼。
WSDL文件保存在Web服務(wù)器上，通過一個url地址就可以訪問到它?？蛻舳艘{(diào)用一個Web Service服務(wù)之前，要知道該服務(wù)的WSDL文件的地址。Web Service服務(wù)提供商可以通過兩種方式來暴露它的WSDL文件地址：1.注冊到UDDI服務(wù)器，以便被人查找；2.直接告訴給客戶端調(diào)用者。
第三部分 Web Service在物流管理控制系統(tǒng)和企業(yè)資源管理系統(tǒng)接口中的應(yīng)用
集成化物流管理控制系統(tǒng)(iWMS) 是自動化立體庫中的靈魂和中樞。是一個基于UNIX/Windows操作系統(tǒng)、在網(wǎng)絡(luò)環(huán)境下實現(xiàn)客戶機(jī)/服務(wù)器模式的軟件系統(tǒng)。其目的是集成地管理、協(xié)調(diào)和調(diào)度物流有關(guān)的有關(guān)物流活動，并及時與ERP（企業(yè)資源管理系統(tǒng)）等系統(tǒng)交換信息。執(zhí)行ERP系統(tǒng)所下達(dá)的采購計劃和物料需求計劃等，并將執(zhí)行結(jié)果及時反饋。
一般企業(yè)再建造自動化立體庫前，自己的ERP系統(tǒng)（企業(yè)資源管理系統(tǒng)）已經(jīng)上線，而建造完自動化立體庫后，將集成化物流管理信息系統(tǒng)與ERP系統(tǒng)有機(jī)結(jié)合在一起，成為擺在企業(yè)信息化管理者面前的重要項目之一。有可能兩個系統(tǒng)服務(wù)器，操作系統(tǒng)，網(wǎng)絡(luò)等各種配套平全不同，在各種接口里，挑選出Web Service當(dāng)接口模式是有原因的。就像上面提到的，Web Service是一種跨編程語言和跨操作系統(tǒng)平臺的遠(yuǎn)程調(diào)用技術(shù)。不論什么操作系統(tǒng)、什么語言，Web Service都能很好地支持。下面就以用友ERP與IWMS做一個Web Service接口模塊的介紹：
第一 入庫下載物料編碼、供應(yīng)商信息、入庫單據(jù)信息
用友ERP系統(tǒng)采用UNIX操作系統(tǒng)，Oracle數(shù)據(jù)庫；集成化物流管理控制系統(tǒng)(iWMS)采用WINDOWS操作系統(tǒng)，SQL SERVER數(shù)據(jù)庫。
當(dāng)物料入庫前，先從ERP系統(tǒng)下載物料編碼、供應(yīng)商信息等基礎(chǔ)信息。通過物料編碼接口和供應(yīng)商信息接口兩個Web Service接口，IWMS系統(tǒng)從ERP系統(tǒng)中得到了基礎(chǔ)信息數(shù)據(jù)，這樣就可以開始接受入庫單據(jù)的信息了。
入庫單據(jù)信息包含入庫單據(jù)號、物料編碼、批號、批次、供應(yīng)商代碼、計劃入庫數(shù)量、實際入庫數(shù)量、規(guī)格等信息。
根據(jù)接受到ERP入庫的單據(jù)信息進(jìn)行相應(yīng)的轉(zhuǎn)換生成IWMS的入庫單據(jù)。
第二 入庫完成后回傳入庫單據(jù)實際數(shù)量
調(diào)用入庫單據(jù)，對物料清點碼盤后進(jìn)行組盤入庫，等該單據(jù)所有的物料全部入庫完畢后，將入庫單據(jù)的實際入庫數(shù)量回傳給ERP系統(tǒng)。
根據(jù)接口協(xié)議，回傳的入庫單據(jù)和ERP的原單據(jù)其他數(shù)據(jù)項一致，只有實際入庫數(shù)量不一樣。
第三 出庫下載客戶信息、出庫單據(jù)信息
客戶來提貨前，先從ERP系統(tǒng)填寫銷售出庫單據(jù)，出庫單再傳給IWMS系統(tǒng)。
出庫單出庫前，客戶等基礎(chǔ)信息要通過客戶信息接口這個Web Service接口傳遞給IWMS系統(tǒng)，然后才可以接受出庫單的信息了。
出庫單據(jù)信息包含出庫單據(jù)號、物料編碼、批號、批次、客戶代碼、計劃出庫數(shù)量、實際出庫數(shù)量、規(guī)格等信息。
根據(jù)接受到ERP出庫的單據(jù)信息進(jìn)行相應(yīng)的轉(zhuǎn)換生成IWMS的出庫單據(jù)。
第四 出庫完成后回傳出庫單據(jù)實際數(shù)量
調(diào)用出庫單據(jù)，配貨清點完畢，等該單據(jù)所有的物料全部出庫裝車后，將出庫單據(jù)的實際出庫數(shù)量回傳給ERP系統(tǒng)。
根據(jù)接口協(xié)議，回傳的出庫單據(jù)和ERP的原單據(jù)其他數(shù)據(jù)項一致，只有實際出庫數(shù)量不一樣。
第四部分 結(jié)語
本文介紹了Web Service在物流管理控制系統(tǒng)與企業(yè)資源管理系統(tǒng)接口中的應(yīng)用。
第7篇：soap協(xié)議范文
關(guān)鍵詞:SOA;企業(yè)應(yīng)用集成
中圖分類號:TP311.133.1文獻(xiàn)標(biāo)識碼:A
SOA&Enterprise Application Integration Design
Li Shu
(Sichuan Leshan Vocational&Technical College,Leshan614000,China)
Abstract:This paper describes enterprise application integration, and then analyzes the key technology of SOA and Web services,proposed SOA-based enterprise application integration solutions,this program flexible,loosely coupled nature,step by step integration,easily extensible.
Keywords:SOA;Enterprise application integration
一、企業(yè)應(yīng)用集成
(一)企業(yè)應(yīng)用集成的提出
企業(yè)應(yīng)用集成(EAI)是指企業(yè)中和企業(yè)之間的任何相連的應(yīng)用間無限制地共享數(shù)據(jù)和業(yè)務(wù)處理,從而使企業(yè)的整個業(yè)務(wù)、管理、資源等各個環(huán)節(jié),達(dá)到協(xié)調(diào)運轉(zhuǎn),效率優(yōu)化。從企業(yè)應(yīng)用集成的具體應(yīng)用范圍來看,企業(yè)應(yīng)用集成包括兩方面:企業(yè)內(nèi)部應(yīng)用系統(tǒng)集成和企業(yè)之間的應(yīng)用系統(tǒng)集成。EAI的模型如圖1所示:
(二)企業(yè)應(yīng)用集成的內(nèi)容
企業(yè)應(yīng)用集成的內(nèi)容涉及到以下幾個層面:
1.業(yè)務(wù)過程集成:當(dāng)對業(yè)務(wù)過程進(jìn)行集成的時候,企業(yè)必須在各種業(yè)務(wù)系統(tǒng)中定義、授權(quán)和管理各種業(yè)務(wù)信息的交換,以便改進(jìn)操作、減少成本、提高響應(yīng)速度。
2.應(yīng)用集成:為兩個應(yīng)用中的數(shù)據(jù)和函數(shù)提供接近實時的集成。
3.數(shù)據(jù)集成:在集成之前,必須首先對數(shù)據(jù)進(jìn)行標(biāo)識并編成目錄,另外還要確定元數(shù)據(jù)模型。這三步完成以后,數(shù)據(jù)才能在數(shù)據(jù)庫系統(tǒng)中分布和共享。
4.集成的標(biāo)準(zhǔn):集成的標(biāo)準(zhǔn)化促成了信息和業(yè)務(wù)數(shù)據(jù)的共享和分布,包括COM+/DCOM、CORBA、EDI、JavaRMI和XML。
5.平臺集成:要實現(xiàn)系統(tǒng)的集成,底層的結(jié)構(gòu)、軟件、硬件以及異構(gòu)網(wǎng)絡(luò)的特殊需求都必須得到集成。
二、面向服務(wù)的體系結(jié)構(gòu)
(一)SOA協(xié)作
面向服務(wù)的體系結(jié)構(gòu)(service-oriented architecture SOA)是一個組件模型。面向服務(wù)的體系結(jié)構(gòu)將應(yīng)用程序中的不同功能單元稱為服務(wù),并通過對這些服務(wù)之間定義良好的接口而將其聯(lián)系起來。接口是采用中立的方式進(jìn)行定義的,也就是說它應(yīng)該獨立于實現(xiàn)服務(wù)的硬件平臺、操作系統(tǒng)和編程語言。這使得構(gòu)建在各種這樣的系統(tǒng)中的服務(wù)可以以一種統(tǒng)一和通用的方式進(jìn)行交互。結(jié)構(gòu)模型如圖2所示。
三個角色是:
1.服務(wù)提供者:提供并自己的服務(wù),并且對使用自身服務(wù)的請求進(jìn)行響應(yīng);
2.服務(wù)注冊中心:用來存儲服務(wù)描述信息的信息庫;
3.服務(wù)請求者:指查找和調(diào)用服務(wù)的客戶端應(yīng)用程序,利用服務(wù)(UDDI)查找所需的服務(wù),然后使用該服務(wù)(綁定)。
(二)SOA的特點和優(yōu)勢
1.松散耦合
服務(wù)實現(xiàn)者可以更改服務(wù)中的接口、數(shù)據(jù)或者消息版本,而不對服務(wù)使用者造成影響。
2.基于行業(yè)標(biāo)準(zhǔn)
消除了使用特定標(biāo)準(zhǔn)而限制于服務(wù)使用者的需要。并且使用基于標(biāo)準(zhǔn)的技術(shù)可打破行業(yè)或技術(shù)平臺的壟斷并促進(jìn)所有服務(wù)的最優(yōu)組合。
3.可重用的服務(wù)
服務(wù)重用避免了重復(fù)開發(fā)之煩瑣,同時提高了實現(xiàn)中的一致性。服務(wù)的重用比起組件或者類的重用更容易實現(xiàn)。
4.同步服務(wù)調(diào)用(RPC方式)
同步服務(wù)對于要求實時響應(yīng)的應(yīng)用程序來說是至關(guān)重要的,例如Portal 或者Query。
5.異步服務(wù)調(diào)用
在異步服務(wù)調(diào)用中,調(diào)用方向消息收發(fā)服務(wù)發(fā)送一個包含完全上下文的消息,收發(fā)服務(wù)將該消息傳遞給接收者。
三、基于SOA的企業(yè)應(yīng)用集成(EAI)
(一)服務(wù)訪問流程
通過基于SOA的企業(yè)應(yīng)用集成框架實現(xiàn)的服務(wù)訪問流程描述如下:
1.企業(yè)門戶將用戶對某個服務(wù)的請求傳到后端支持服務(wù)總線的應(yīng)用服務(wù)器,如IBM的WebSphere;
2.應(yīng)用服務(wù)器通過UDDI查詢Web Service公共目錄或者經(jīng)驗證后訪問Web Service私有目錄,用得到的WSDL描述生成SOAP請求消息綁定服務(wù)提供者;
3.SOAP請求被傳遞到對應(yīng)的SOAP路由器,由SOAP路由器將該請求傳遞到對應(yīng)該服務(wù)的適配器;
4.適配器激活相關(guān)應(yīng)用系統(tǒng);
5.應(yīng)用處理結(jié)果返回適配器,經(jīng)適配器打包為包含處理結(jié)果的SOAP消息,返回給SOAP路由器,直至返回用戶處。
(二)主要組成部分功能描述
1.企業(yè)內(nèi)部Service Provider
企業(yè)內(nèi)部Service Provider中包含已有應(yīng)用或新開發(fā)的Web Service應(yīng)用,它們均被封裝為標(biāo)準(zhǔn)的Web Service組件,成為系統(tǒng)中的一個集成點。
對已有系統(tǒng)集成的關(guān)鍵在于對系統(tǒng)的封裝和包裹,可以先利用WSDL生成器生成該服務(wù)對應(yīng)的WSDL文件,然后生成服務(wù)器端基于SOAP的框架代碼,在框架代碼的基礎(chǔ)上開發(fā)Web服務(wù)適配器,通過該服務(wù)適配器,將XML格式的請求轉(zhuǎn)換為已有系統(tǒng)能解析的格式,同時,將已有系統(tǒng)處理后的結(jié)果轉(zhuǎn)換為XML格式。服務(wù)適配器還具備與后端服務(wù)器建立通信連接,驗證數(shù)據(jù)有效性等功能。
2.服務(wù)總線Service Bus
服務(wù)總線通過一個處于中間層的集中式服務(wù)器,為業(yè)務(wù)流程控制、服務(wù)路由、協(xié)議轉(zhuǎn)換和安全扮演著中央控制點的角色。以下對服務(wù)總線上的幾個關(guān)鍵功能作簡要介紹:
(1)工作流控制:定義工作流程,并協(xié)調(diào)服務(wù)間的交互,己出現(xiàn)一些推薦的標(biāo)準(zhǔn),如WSFL(Web Service Flow Language)等;
(2)事務(wù)管理:由于分布的,松耦合的應(yīng)用環(huán)境不適于使用傳統(tǒng)的事務(wù)技術(shù),對此,IBM,微軟和BEA聯(lián)合提出WS-Transaction;
(3)安全映射:對所有參與服務(wù)進(jìn)行統(tǒng)一管理,把安全性考慮隔離在單一構(gòu)件上,簡化開發(fā)和管理;
(4)服務(wù)監(jiān)控:監(jiān)控流程的執(zhí)行,利用記錄的數(shù)據(jù)來分析服務(wù)質(zhì)量和指導(dǎo)服務(wù)改進(jìn);
(5)SOAP路由器:用以實現(xiàn)SOAP消息的傳遞,路由器通過分析,找出對應(yīng)的Web Service適配器的位置,將SOAP請求傳遞到所請求的適配器;
(三)服務(wù)網(wǎng)關(guān)Service Gateway
對于企業(yè)外部集成,使用服務(wù)網(wǎng)關(guān),一方面可以安全地對外公開Web服務(wù),另一方面,防火墻之外的客戶也能調(diào)用這些服務(wù)。它包括一個服務(wù)管理模型和過濾器。服務(wù)網(wǎng)關(guān)能夠?qū)⒖蛻舳酥С值姆?wù)協(xié)議轉(zhuǎn)換為提供方支持的服務(wù)協(xié)議,如:客戶的請求可能是HTTP上的SOAP,但在內(nèi)部可以使用JMS協(xié)議上的SOAP。
(四)企業(yè)門戶Enterprise Portal
終端用戶界面集成特定用戶訪問的全部應(yīng)用程序和服務(wù)來提供可用、高效、一致的界面。組合式Portal將Web服務(wù)通過Portal即插即用,使EAI更加靈活。
四、結(jié)束語
SOA為企業(yè)應(yīng)用集成(EAI)提供了理想的集成框架,它是實現(xiàn)EAI的有力工具。基于SOA和消息中間件技術(shù),可以在不改變應(yīng)用系統(tǒng)原有底層架構(gòu)的基礎(chǔ)上實現(xiàn)靈活的、面向服務(wù)的應(yīng)用集成,未來相信面向服務(wù)的EAI會在企業(yè)信息化的進(jìn)程中得到更廣泛的應(yīng)用。
參考文獻(xiàn)
[1]宋善德,王雪飛.基于Web服務(wù)的企業(yè)應(yīng)用集成方案.計算機(jī)應(yīng)用研究,2003,6,127-129.
[2]宋波,李妙妍.面向Web服務(wù)的BPEL的研究與實現(xiàn).計算機(jī)工程與設(shè)計,2007,28(9).212-214.
[3]葉宇風(fēng).基于SOA的企業(yè)應(yīng)用集成研究.微電子學(xué)與計算機(jī),2006,23,(5).211-213.
[4]胡繼東,劉廣鐘.基于Web Services的軟件集成方法的研究與實現(xiàn).計算機(jī)系統(tǒng)應(yīng)用,2002,11,33-35
第8篇：soap協(xié)議范文
隨著Web Services由技術(shù)概念到實踐應(yīng)用的不斷發(fā)展，種種跡象表明，Web Services將是未來應(yīng)用架構(gòu)的一個極為重要的模式。
安全中間件是中間件的一種，為我們提供了CA認(rèn)證、數(shù)字證書、數(shù)字簽名等安全相關(guān)的通用編程抽象。應(yīng)用程序人員不必?fù)碛袑I(yè)的安全知識，即可通過調(diào)用安全中間件的相關(guān)API方便地使用所需的安全功能，從而使開發(fā)人員能夠?qū)Ｗ⒂跇I(yè)務(wù)邏輯的開發(fā)。
目前，傳統(tǒng)的基于PKI(Public Key Infrastructure)的安全中間件已經(jīng)可以滿足我們大部分的安全要求，但是這仍然是不夠的，因為傳統(tǒng)安全中間件基本上都是采用調(diào)用API的方式，從而直接導(dǎo)致了應(yīng)用程序與安全中間件的緊耦合性、平臺相關(guān)性與編程語言相關(guān)性。
基于Web Services的安全中間件的優(yōu)勢
具有松耦合性與跨平臺跨編程語言正是Web Services技術(shù)的最大特性，下面將討論傳統(tǒng)安全中間件與基于Web Services的安全中間件的各自運作模式及他們的不同，并總結(jié)出基于Web Services的安全中間件的優(yōu)勢。
傳統(tǒng)安全中間件產(chǎn)品一般以PKI為基礎(chǔ)，建立在X.509等安全標(biāo)準(zhǔn)之上，為開發(fā)人員提供了加密、認(rèn)證、授權(quán)、驗證等安全接口。下面是傳統(tǒng)安全中間件與基于Web Services的安全中間件的運作模式對比圖：
由圖1左邊可以看出，應(yīng)用程序是采用API調(diào)用方式使用安全中間件的，即傳統(tǒng)安全中間件是作為函數(shù)庫與應(yīng)用程序部署在一起的，這些都使得應(yīng)用程序與安全中間件之間產(chǎn)生了緊耦合，導(dǎo)致整個系統(tǒng)過于復(fù)雜而不好維護(hù)，喪失了靈活性。另外，安全算法是需要大規(guī)模計算的，對于計算資源寶貴的移動設(shè)備來說，以上并不是一個理想的解決方案。
采用Web Services技術(shù)的安全中間件，通過SOAP協(xié)議實現(xiàn)應(yīng)用程序與安全中間件之間的通訊。如圖1右邊所示，在本設(shè)計中，應(yīng)用程序與安全中間件之間的通訊采用了Web Services技術(shù)，通過SOAP協(xié)議進(jìn)行通訊。同時，為了保證應(yīng)用程序與安全中間件之間網(wǎng)絡(luò)通訊的安全，本系統(tǒng)中采用SSL用于保證傳輸層上的點對點完整性和機(jī)密性，在應(yīng)用層面上則是采用WS-Security規(guī)范保證SOAP消息的安全性。
在以上的對比分析中我們可以得知，在基于Web Services的安全中間件中，不管是J2EE或.Net編程技術(shù)，都可以通過標(biāo)準(zhǔn)的SOAP協(xié)議與安全中間件進(jìn)行通信，實現(xiàn)了編程語言無關(guān)性。再者，由于Web Services技術(shù)是基于網(wǎng)絡(luò)HTTP協(xié)議通過網(wǎng)絡(luò)進(jìn)行通信，從而去掉了應(yīng)用程序與安全中間件需要部署在同一操作系統(tǒng)、服務(wù)器上的限制，進(jìn)而實現(xiàn)了平臺無關(guān)性。最后，假設(shè)日后安全中間件內(nèi)部模塊進(jìn)行了更新升級，也不會影響到應(yīng)用程序，無需再編譯、再部署，從而實現(xiàn)了應(yīng)用程序?qū)优c安全中間件層之間的松耦合性。
由此可得出基于Web Services的安全中間件的優(yōu)勢有：編程語言無關(guān)性，平臺無關(guān)性與松耦合性。
基于Web Services的安全中間件的總體設(shè)計
本文將設(shè)計與實現(xiàn)一個基于Web Services的安全中間件，該安全中間件從理論上講，能夠?qū)崿F(xiàn)傳統(tǒng)安全中間件的所有功能，并且是基于SOAP通訊的，實現(xiàn)了松耦合及跨平臺跨編程語言性。
本中間件的功能主要分成兩大塊――證書模塊與密碼模塊。
證書模塊：證書申請，即個人通過安全中間件向CA申請證書；查詢證書，應(yīng)用程序可以通過該功能查詢自己或已收到的他人證書狀態(tài)；獲取證書，應(yīng)用程序可通過安全中間件獲取自己或他人的證書；撤銷證書，在個人丟失私鑰時，可以申請撤銷證書；驗證證書，可用于驗證他人證書的有效性。
密碼模塊：加密解密消息，使用各種算法對消息進(jìn)行加解密操作；生成會話密鑰，為通信的雙方生成會話密鑰；數(shù)字簽名，對消息進(jìn)行數(shù)字簽名；簽名驗證，可對已進(jìn)行數(shù)字簽名的消息進(jìn)行驗證其完整性和發(fā)送方身份。
總體框架：
基于Web Services的安全中間件的設(shè)計目標(biāo)，是為了讓所有類型的應(yīng)用程序都能通過由WS-Security保護(hù)的SOAP協(xié)議來獲取安全服務(wù)。本中間件總體框架如下圖所示：
如圖2所示，本系統(tǒng)采用分層的設(shè)計結(jié)構(gòu)。最上層為服務(wù)接口，以Web Services的形式給應(yīng)用程序，而不是傳統(tǒng)的采用API或RPC遠(yuǎn)程調(diào)用接口，消除了應(yīng)用程序?qū)优c安全服務(wù)層之間的耦合性，也使得應(yīng)用程序與安全中間件無需部署在一起，大大提高了企業(yè)信息系統(tǒng)的整體靈活性。
安全中間件在接收到請求后對其進(jìn)行解析，然后進(jìn)行相應(yīng)的操作并返回。在應(yīng)用程序接口下面，是兩個主要模塊接口――證書服務(wù)與密碼服務(wù)接口，設(shè)計這兩個接口的目的是為了日后系統(tǒng)的擴(kuò)展。
在兩個接口的下面，是兩個模塊的具體實現(xiàn)，這里的具體實現(xiàn)有兩種方式，一是使用各種成熟的組件直接實現(xiàn)服務(wù)，如Sun提供的JCE、JAAS及JSSE，微軟的CryptAPI或Intel的CDSA等；二是通過統(tǒng)一的PKI接口調(diào)用現(xiàn)成的PKI設(shè)施，其好處是可以隨以后需求的變更而靈活使用不同的PKI產(chǎn)品。PKI統(tǒng)一接口的下方PKI Provider xx是針對某一PKI產(chǎn)品所設(shè)計的專用轉(zhuǎn)換接口，實現(xiàn)從特定PKI產(chǎn)品自身接口到本系統(tǒng)PKI統(tǒng)一接口的轉(zhuǎn)換。
實現(xiàn)細(xì)節(jié)：
下面是本系統(tǒng)的服務(wù)接口設(shè)計，這里的服務(wù)接口是指本安全中間件開發(fā)給應(yīng)用程序的服務(wù)接口。本系統(tǒng)的Web Service的實現(xiàn)采用AXIS2開源框架。下面將使用AXIS2的services.xml說明服務(wù)接口的設(shè)計，并結(jié)合使用SOAP消息格式進(jìn)行詳細(xì)說明。
如services.xml文件中申請證書的xml配置如下：
urn:applyCert
本文就傳統(tǒng)安全中間件與基于Web Services的安全中間件進(jìn)行探討比較，進(jìn)而總結(jié)出基于Web Services的安全中間件的優(yōu)勢之處在于松耦合、跨平臺與跨編程語言。接著，提出基于Web Services的安全中間件的設(shè)計方案，并實現(xiàn)了上述三點優(yōu)勢。當(dāng)然，本系統(tǒng)目前還存在一些不足之處，在完整性方面，目前僅實現(xiàn)了基本的安全服務(wù)功能；在標(biāo)準(zhǔn)性方面，目前采用的Web Services安全規(guī)范仍處于草案階段而不是公認(rèn)的標(biāo)準(zhǔn)；最后是實用性，本系統(tǒng)目前仍處于測試階段，最終能否勝任安全強(qiáng)度的要求仍需進(jìn)一步的考驗。
參考文獻(xiàn)
[1] JP Morgenthal. Web Services for Enterprise Application Integration. [A] Journal, 2002,2(5 ): 14 ~16
[2] 張志擦. 中間件技術(shù). 北京:中國石化出版社，2002. 122~123
[3] 荊繼武. PKI系統(tǒng)研究：[博士學(xué)位論文]. 北京:中國科學(xué)院研究生院，2002
[4] 張振興. Web服務(wù)安全性的研究與實現(xiàn)：[D]. 華北電力大學(xué)碩士論文，2004
[5] 肖軍模，劉軍. 網(wǎng)絡(luò)信息安全. 北京:機(jī)械工業(yè)出版社，2003. 23~24
[6] Markham T. Security at the network edge. Information Survivability Conference, 2001,11. 279~286
第9篇：soap協(xié)議范文
關(guān)鍵詞： 區(qū)域醫(yī)療； 數(shù)據(jù)交互； 異構(gòu)系統(tǒng)； 信息化建設(shè)
中圖分類號： TN911?34 文獻(xiàn)標(biāo)識碼： A 文章編號： 1004?373X（2014）02?0051?02
隨著信息技術(shù)的飛速發(fā)展，各種管理信息系統(tǒng)已在醫(yī)療行業(yè)中得到廣泛應(yīng)用。同時，在新醫(yī)改的推動下，建立數(shù)字化“醫(yī)療聯(lián)合體”和“區(qū)域醫(yī)療平臺”成為醫(yī)療信息化發(fā)展的必然趨勢。但由于各個醫(yī)療部門的軟硬件條件各異，部門、單位特點不同，勢必造成多種關(guān)系數(shù)據(jù)庫共存的局面。多種異構(gòu)數(shù)據(jù)庫的存在嚴(yán)重限制了數(shù)據(jù)共享和交互的范圍。因此如何在保留原有成熟醫(yī)院信息系統(tǒng)（Hospital Information System，HIS）的基礎(chǔ)上，實現(xiàn)異構(gòu)數(shù)據(jù)庫間透明信息存取是首要解決的問題。
1 醫(yī)療信息系統(tǒng)現(xiàn)狀
我國從20世紀(jì)90年代初逐步開始醫(yī)療信息化建設(shè)。目前各種醫(yī)療信息化系統(tǒng)已經(jīng)開始部署到地方各級醫(yī)療機(jī)構(gòu)，典型的系統(tǒng)包括：醫(yī)院信息系統(tǒng)（Hospital Information System，HIS）、電子病歷系統(tǒng)（Electronic Medical Records，EMR）、醫(yī)學(xué)影像存檔與通信系統(tǒng)（Picture Archiving and Communication System，PACS）、檢驗信息系統(tǒng)（Laboratory Information System，LIS）和超聲信息系統(tǒng)（Ultrasound Information System，UIS）等。
為落實國家“十二五”深化醫(yī)藥衛(wèi)生體制改革規(guī)劃、物聯(lián)網(wǎng)發(fā)展規(guī)劃和電子政務(wù)發(fā)展規(guī)劃，需要對衛(wèi)生信息化建設(shè)及其應(yīng)用提出新的要求。國家已從戰(zhàn)略層面指出：根據(jù)當(dāng)前醫(yī)改對信息化發(fā)展形勢的要求，“十二五”期間衛(wèi)生信息化工作要在以區(qū)域衛(wèi)生信息化建設(shè)為重點的互聯(lián)互通和資源共享方面有所作為[1]。區(qū)域衛(wèi)生信息化建設(shè)發(fā)展的一個必然階段便是區(qū)域衛(wèi)生信息化中的數(shù)據(jù)交互建設(shè)，這是區(qū)域衛(wèi)生信息化建設(shè)中最重要的課題。數(shù)據(jù)交互的實現(xiàn)，能夠滿足政府更高效、更靈活、協(xié)同性更好的實現(xiàn)對醫(yī)療衛(wèi)生的管理，幫助醫(yī)療衛(wèi)生單位實現(xiàn)大量信息快速、有效、準(zhǔn)確地獲取、管理和傳遞，改進(jìn)工作流程，提高工作效率。
由于國內(nèi)醫(yī)療信息化建設(shè)水平參差不齊，且無統(tǒng)一的標(biāo)準(zhǔn)。不同的信息系統(tǒng)開發(fā)商在設(shè)計、實現(xiàn)過程中所采用的系統(tǒng)架構(gòu)、技術(shù)方法、開發(fā)平臺千差萬別，勢必出現(xiàn)不同醫(yī)療機(jī)構(gòu)間相同業(yè)務(wù)類型的數(shù)據(jù)存儲定義、語義表達(dá)方式不同。這些不同，形成了無數(shù)個孤立的信息系統(tǒng)，導(dǎo)致患者就診時醫(yī)生無法在第一時間內(nèi)準(zhǔn)確了解疾病史、藥物治療史、過敏史和前期檢查結(jié)果等，降低診療效率和診療質(zhì)量，增多患者重復(fù)檢查的次數(shù)，提高診療成本，加重患者經(jīng)濟(jì)負(fù)擔(dān)。 構(gòu)建異構(gòu)醫(yī)療數(shù)據(jù)交互平臺是實現(xiàn)區(qū)域衛(wèi)生信息化的核心環(huán)節(jié)。通過外掛中間件的方式，對醫(yī)院已有的HIS不做改動的前提下，在系統(tǒng)間高效、安全的傳輸和處理基于相關(guān)醫(yī)療信息標(biāo)準(zhǔn)的醫(yī)療信息。
2 系統(tǒng)設(shè)計
為了異構(gòu)醫(yī)療數(shù)據(jù)間的交互，首先必須建立穩(wěn)定可靠的系統(tǒng)架構(gòu)。如圖1所示，該系統(tǒng)架構(gòu)在保留原HIS和數(shù)據(jù)庫的基礎(chǔ)上通過外掛中間件的方式交互數(shù)據(jù)。當(dāng)某醫(yī)院有申請數(shù)據(jù)的需要時，通過HTTP請求以XML格式表示的有效數(shù)據(jù)。發(fā)送方通過數(shù)據(jù)訪問模塊從源數(shù)據(jù)庫中提取數(shù)據(jù)，然后基于HL7的醫(yī)療信息標(biāo)準(zhǔn)進(jìn)行數(shù)據(jù)轉(zhuǎn)換，以WS?Security的安全機(jī)制實現(xiàn)SOAP消息的安全傳遞，保證醫(yī)療數(shù)據(jù)標(biāo)準(zhǔn)、安全、有效的傳輸給數(shù)據(jù)申請方。
3 關(guān)鍵技術(shù)
在整個異構(gòu)醫(yī)療數(shù)據(jù)交互系統(tǒng)架構(gòu)中，數(shù)據(jù)的轉(zhuǎn)換、表現(xiàn)形式以及數(shù)據(jù)的傳輸安全是最核心的技術(shù)。
（1） 基于HL7的數(shù)據(jù)轉(zhuǎn)換模型。醫(yī)療信息傳輸與交換技術(shù)標(biāo)準(zhǔn)（Healthy Level Seven，HL7）是醫(yī)學(xué)信息系統(tǒng)應(yīng)用和執(zhí)行的標(biāo)準(zhǔn)，是基于消息實現(xiàn)數(shù)據(jù)傳遞的標(biāo)準(zhǔn)規(guī)范[2]，多個HIS之間進(jìn)行數(shù)據(jù)的交互都是以HL7為標(biāo)準(zhǔn)的。在HL7標(biāo)準(zhǔn)中，若干個字段構(gòu)成一個消息段，有一定順序和邏輯關(guān)系的消息段構(gòu)成一條消息，當(dāng)某事件發(fā)生時將消息按照一定的網(wǎng)絡(luò)傳輸協(xié)議傳送到接收方，接收方在消息的接收、解析之后將其送往應(yīng)用程序。相比于之前版本，HL7 v3版一個顯著的特點就是支持可擴(kuò)展標(biāo)記語言，運用XML技術(shù)來加強(qiáng)和改善醫(yī)療系統(tǒng)之間的數(shù)據(jù)交換能力。
（2） 可擴(kuò)展標(biāo)記語言XML。XML（eXtensible Markup Language）是針對包含結(jié)構(gòu)化信息的文檔而設(shè)計的一種標(biāo)記語言。在本系統(tǒng)的研發(fā)中通過以XML格式表示和傳輸以HL7標(biāo)準(zhǔn)建立的共享數(shù)據(jù)信息?？紤]到HIS數(shù)據(jù)的復(fù)雜性，它需要在數(shù)據(jù)類型、主外鍵值、數(shù)據(jù)完整性約束等方面的定義，使用XML schema定義XML文檔數(shù)據(jù)交換格式的標(biāo)準(zhǔn)[3]。
（3） 基于WebService和SOAP協(xié)議的異構(gòu)數(shù)據(jù)源交互模型。SOAP 調(diào)用的數(shù)據(jù)和方法的表達(dá)方式是基于 XML 的、可以使數(shù)據(jù)的型和值在表達(dá)上分離， 有利于應(yīng)用程序之間透明交換信息， 同時可以解決網(wǎng)絡(luò)傳輸安全性問題[4]。本研究采用WebService和SOAP協(xié)議建立異構(gòu)數(shù)據(jù)源交互模型，如圖2所示。該模型采用XML作為數(shù)據(jù)描述語言，轉(zhuǎn)換時首先通過數(shù)據(jù)交換中間件把各種異構(gòu)的輸入/輸出數(shù)據(jù)按照描述邏輯轉(zhuǎn)換為統(tǒng)一規(guī)則的XML文件，然后通過SOAP傳輸協(xié)議在各異構(gòu)系統(tǒng)之間的Internet網(wǎng)絡(luò)之間進(jìn)行傳輸，最后再通過數(shù)據(jù)交換中間件完成數(shù)據(jù)轉(zhuǎn)換。
（4） 異構(gòu)系統(tǒng)安全策略。采用基于WS?Security的安全機(jī)制實現(xiàn)SOAP消息的安全傳遞，其中對XML元素加密算法由WS?Security規(guī)范提供，這種加密算法滿足了消息級安全的需要[5]。同時，采用基于X.509證書的PKI技術(shù)實現(xiàn)對SOAP消息進(jìn)行加密、解密和簽名、認(rèn)證，最終實現(xiàn)安全的SOAP消息調(diào)用。
4 結(jié) 語
本文結(jié)合HL7 V3版本的特點和XML技術(shù)的優(yōu)勢，提出在保留原HIS和數(shù)據(jù)庫的基礎(chǔ)上，采用外掛中間件的方式實現(xiàn)異構(gòu)醫(yī)療數(shù)據(jù)交互的策略，構(gòu)建了數(shù)據(jù)交互的系統(tǒng)架構(gòu)，并闡述了關(guān)鍵技術(shù)解決方案，對實現(xiàn)區(qū)域衛(wèi)生信息化建設(shè)環(huán)境下的醫(yī)療數(shù)據(jù)交互提供了一個切實可行的方案。
參考文獻(xiàn)
[1] 佚名.攻堅醫(yī)改難題勇?lián)l(fā)展重任：2012年醫(yī)療衛(wèi)生信息化發(fā)展與未來展望[J].中國信息界，2012（12）：40?45.
[2] Anon. HL7 version 2： health informatics [M]. [S.l.]： [s.n.]， 2010： 107?128.
[3] AHMED K Z，UMRYSH C E.用J2EE和UML開發(fā)企業(yè)級應(yīng)用程序[M].康博，譯，北京：清華大學(xué)出版社，2002.
[4] 徐漢川，胡潤波，劉國忠.基于XML/SOAP數(shù)據(jù)交換中間件的設(shè)計[J].哈爾濱商業(yè)大學(xué)學(xué)報：自然科學(xué)版，2004，20（6）：665?670.
[5] 蔡小芳，張永勝.在Web服務(wù)安全中XML加密與簽名的應(yīng)用[J].計算機(jī)安全，2006（7）：20?23.