建站
咨詢
售后
建站咨詢
新聞中心
簡(jiǎn)介： 本文介紹如何提升 Java Web 服務(wù)性能，主要介紹了三種方法：一是采用 Web 服務(wù)的異步調(diào)用，二是引入 Web 服務(wù)批處理模式，三是壓縮 SOAP 消息。重點(diǎn)介紹在編程過(guò)程中如何使用異步 Web 服務(wù)以及異步調(diào)用和同步調(diào)用的差異點(diǎn)。本文還示范了如何在項(xiàng)目中使用以上三種方法，以及各種方法所適合的應(yīng)用場(chǎng)景。
成都創(chuàng)新互聯(lián)主要從事做網(wǎng)站、網(wǎng)站制作、網(wǎng)頁(yè)設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)郟縣,十余年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來(lái)電咨詢建站服務(wù):13518219792
Java Web 服務(wù)簡(jiǎn)介
Web 服務(wù)是一種面向服務(wù)架構(gòu)的技術(shù)，通過(guò)標(biāo)準(zhǔn)的 Web 協(xié)議提供服務(wù)，目的是保證不同平臺(tái)的應(yīng)用服務(wù)可以互操作。Web 服務(wù)（Web Service）是基于 XML 和 HTTP 通訊的一種服務(wù)，其通信協(xié)議主要基于 SOAP，服務(wù)的描述通過(guò) WSDL、UDDI 來(lái)發(fā)現(xiàn)和獲得服務(wù)的元數(shù)據(jù)。 這種建立在 XML 標(biāo)準(zhǔn)和 Internet 協(xié)議基礎(chǔ)上的 Web 服務(wù)是分布式計(jì)算的下一步發(fā)展方向，Web 服務(wù)為那些由不同資源構(gòu)建的商業(yè)應(yīng)用程序之間的通信和協(xié)作帶來(lái)了光明的前景，從而使它們可以彼此協(xié)作，而不受各自底層實(shí)現(xiàn)方案的影響。
JAX-RPC 1.0 是 Java 方面的 Web 服務(wù)的原始標(biāo)準(zhǔn) , 但是由于 JAX-RPC 1.0 對(duì) Web 服務(wù)功能的認(rèn)識(shí)有一定的局限，于是 JAX-WS 2.0 應(yīng)用而生。JAX-WS 2.0 開(kāi)發(fā)工作的主要目標(biāo)是對(duì)各項(xiàng)標(biāo)準(zhǔn)進(jìn)行更新，成功實(shí)現(xiàn)了業(yè)界對(duì) JAX-RPC 1.X 的各種期望。此外，JAX-WS 2.0 直接支持 XOP/MTOM，提高了系統(tǒng)附件傳送能力以及系統(tǒng)之間的互操作性。
實(shí)例剖析Web服務(wù)性能瓶頸
通過(guò)以上簡(jiǎn)述不難體會(huì)到，Web 服務(wù)以其 XML + HTTP 的松耦合、平臺(tái)無(wú)關(guān)的特性，集萬(wàn)般寵愛(ài)于一身，必將成為未來(lái)數(shù)據(jù)共享的基礎(chǔ)。但與此同時(shí)我們也應(yīng)當(dāng)認(rèn)識(shí)到世間完事萬(wàn)物均有其矛盾的兩面性：有優(yōu)點(diǎn)，必將存在缺點(diǎn)，Web 服務(wù)亦是如此。就像當(dāng)初 JAVA 大行其道的時(shí)候性能成為其致命詬病一樣，Web 服務(wù)也同樣面臨性能問(wèn)題，似乎“性能問(wèn)題”天生就是“平臺(tái)無(wú)關(guān)”揮之不去的冤家。但問(wèn)題終歸要解決，實(shí)踐是檢驗(yàn)和分析問(wèn)題的唯一途徑，讓我們先來(lái)創(chuàng)建一個(gè)簡(jiǎn)單的 Web 服務(wù)再來(lái)審視和分析隱含其中的性能問(wèn)題。
創(chuàng)建服務(wù)
創(chuàng)建服務(wù) Java Bean: 首先我們創(chuàng)建一個(gè)盡可能簡(jiǎn)單的書店服務(wù) Bean，服務(wù)的內(nèi)容只有一個(gè) qryBooksByAuthor，即根據(jù)作者 (Author) 查詢其名下的書籍 (List
圖 1. 書店服務(wù) Bean(BookStoreSrvBean)
服務(wù) Input- 作者 (Author) 的實(shí)體類 :
圖 2. 作者實(shí)體類 (Author)
服務(wù)出參 Output- 書籍 (Book) 列表的實(shí)體類：
圖 3. 書籍實(shí)體類 (Book)
至此我們的服務(wù)代碼已經(jīng)完成，我們不在此討論此服務(wù)的業(yè)務(wù)合理性，創(chuàng)建此服務(wù)的目的只是舉一個(gè)盡可能簡(jiǎn)單的實(shí)例以分析 web 服務(wù)的性能。
下面的任務(wù)就是開(kāi)發(fā) Web 服務(wù)了，手工編寫及發(fā)布符合規(guī)范的 Web 服務(wù)過(guò)程極為繁瑣，在此使用 IBM 的 Rational Software Architect（后面簡(jiǎn)稱 RSA）來(lái)進(jìn)行 Web 服務(wù)的服務(wù)器端以及客戶端的開(kāi)發(fā)。
發(fā)布 Web 服務(wù)
創(chuàng)建動(dòng)態(tài) Web 項(xiàng)目 : 發(fā)布 Web 服務(wù)的前提當(dāng)然需要一個(gè) J2EE 的 Web 項(xiàng)目，打開(kāi) RSA->File->New->Dynamic Web Project, 項(xiàng)目名稱為 testWebService, 其余選項(xiàng)根據(jù)需要進(jìn)行選擇 ( 注意需要選擇加入 Web 項(xiàng)目到 EAR)。創(chuàng)建好的 Web 項(xiàng)目和 EAR 項(xiàng)目效果如下 :
圖 4. Web 項(xiàng)目以及應(yīng)用項(xiàng)目的結(jié)構(gòu)
創(chuàng)建 Web 服務(wù)： 選中導(dǎo)入的 com.ibm.test.ws.srv.BookStoreSrvBean，右鍵 New->Other->Web Service 來(lái)創(chuàng)建并發(fā)布 Web 服務(wù)。創(chuàng)建的時(shí)候選擇常用的 JAX-WS 標(biāo)準(zhǔn) , 并選擇生成 WSDL 文件。由于 Web 服務(wù)的創(chuàng)建不是本文重點(diǎn)，此部分內(nèi)容暫且省略。服務(wù)創(chuàng)建完成之后就可以發(fā)布到上一步建好的 Web 項(xiàng)目中了。
創(chuàng)建客戶端
使用 RSA，客戶端的創(chuàng)建工作將會(huì)非常簡(jiǎn)單：右鍵點(diǎn)擊上面生成的 WSDL 文件 ->Web Services->Generate Client
圖 5. 創(chuàng)建客戶端界面
在此界面，根據(jù)實(shí)際情況選擇 server，JAX-WS 標(biāo)準(zhǔn)以及 Client 代碼的目標(biāo)項(xiàng)目，然后點(diǎn)擊下一步。
圖 6. 輸入客戶端信息
此界面暫時(shí)使用默認(rèn)配置，某些特殊選項(xiàng)將在后面章節(jié)進(jìn)行描述。
客戶端調(diào)用
由于 JAX-WS 規(guī)范大部分的 stub 調(diào)用代碼是實(shí)時(shí)生成的，我們只需要修改客戶端 WSDL 的 port 就可以用以下代碼進(jìn)行 Web 服務(wù)的調(diào)用。這里修改 WSDL 端口的目的是讓客戶端調(diào)用 RSA 提供的 TCP/IP Monitor 的虛擬端口，這樣我們就可以很輕易地看到 Web 服務(wù)實(shí)際的調(diào)用以及返回的 SOAP 消息了。
客戶端調(diào)用代碼如下 :
圖 7. 客戶端調(diào)用代碼
使用 TCP/IP Monitor 看到的 SOAP 消息如下 :
圖 8. Web 服務(wù)調(diào)用產(chǎn)生的 SOAP 消息
#p#
Java Web 服務(wù)性能分析
從以上實(shí)例我們可以看到，Web 服務(wù)的調(diào)用與傳統(tǒng)的 RPC 還是有較大差異的。最大的特點(diǎn)是調(diào)用雙方使用 XML 格式的 SOAP 規(guī)范消息進(jìn)行傳輸，這樣以文本進(jìn)行傳輸?shù)暮锰幨菕仐壛怂接袇f(xié)議，無(wú)論調(diào)用雙方是何種平臺(tái)，只要能夠構(gòu)造以及解析 XML 文本，并且存在雙方都支持的傳輸協(xié)議，那么調(diào)用就成為了可能。而 XML 的日益規(guī)范以及 HTTP 協(xié)議的普及更是給這兩個(gè)必要條件提供了堅(jiān)強(qiáng)的后盾，Web 服務(wù)成為未來(lái)通用的服務(wù)提供標(biāo)準(zhǔn)已是不爭(zhēng)的事實(shí)。
但是相信使用過(guò) Web 服務(wù)的人都曾經(jīng)經(jīng)受過(guò)其性能不佳的窘境，原因?yàn)楹挝覀兘Y(jié)合剛才的實(shí)例可以分析出以下幾點(diǎn)：
● SOAP 文本消息轉(zhuǎn)化導(dǎo)致效率低下
從剛才的 TCP/IP Monitor 監(jiān)測(cè)到的 request 以及 response 的消息我們可以看到，在發(fā)送消息時(shí)，我們傳入了 Author 對(duì)象，在實(shí)際的調(diào)用發(fā)生時(shí)，這個(gè) Author 對(duì)象會(huì)被轉(zhuǎn)化成 XML 格式的 SOAP 消息，此消息在到達(dá) Server 端會(huì)被解析并重新構(gòu)造成 Server 端的 Author 對(duì)象。Response 也是同理，Books List 也會(huì)經(jīng)歷 XML 序列化和反序列化的過(guò)程。最糟糕的是，這種過(guò)程會(huì)在每一次調(diào)用的時(shí)候都會(huì)發(fā)生，這種構(gòu)造以及解析的過(guò)程都會(huì)極大地消耗 CPU，造成資源的消耗。
●SOAP 文本消息傳輸導(dǎo)致傳輸內(nèi)容膨脹
以 request 參數(shù) Author 為例，必要的信息僅僅是”Bruce Eckel”這幾個(gè)字節(jié)，但轉(zhuǎn)化成 XML 消息后，可以從 SOAP 消息看到，多了很多 SOAP 規(guī)范的標(biāo)簽，這些信息會(huì)導(dǎo)致需要傳輸?shù)膬?nèi)容急劇增大，幾個(gè)字節(jié)很可能會(huì)變成幾千字節(jié)。當(dāng)調(diào)用頻度和參數(shù)內(nèi)容增多的時(shí)候，這種傳輸內(nèi)容的膨脹將不是一個(gè)可以忽略的影響，它不但會(huì)吃掉網(wǎng)絡(luò)的帶寬，還會(huì)給 Server 的數(shù)據(jù)吞吐能力造成負(fù)擔(dān)，后果可想而知。
●同步阻塞調(diào)用在某些情況下導(dǎo)致性能低下
同步阻塞調(diào)用是指客戶端在調(diào)用 Web 服務(wù)發(fā)送 request 后一直處于阻塞狀態(tài)，客戶端線程就會(huì)掛起，一直處于等待狀態(tài)，不能進(jìn)行其他任務(wù)的處理。這樣就會(huì)造成線程的浪費(fèi)，如果相應(yīng)線程占用了一些資源，也不能夠及時(shí)釋放。
這個(gè)問(wèn)題在純客戶端訪問(wèn) Server 端的情況下并不明顯，但如果是兩個(gè) Server 端之間進(jìn)行 Web 服務(wù)調(diào)用的話，阻塞模式就會(huì)成為調(diào)用 Server 端的性能瓶頸。
Web 服務(wù)性能優(yōu)化實(shí)踐
使用異步方式調(diào)用 web 服務(wù)
先需要強(qiáng)調(diào)一點(diǎn)的是，這里的異步方式指的是客戶端的異步，無(wú)論客戶端是同步還是異步，都對(duì)服務(wù)端沒(méi)有任何影響。我們期望的理想結(jié)果是：當(dāng)客戶端發(fā)送了調(diào)用請(qǐng)求后不必阻塞等待 server 端的返回結(jié)果。最新的 JAX-WS 標(biāo)準(zhǔn)中增加了這一異步調(diào)用的特性，更好的消息是，RSA 工具中也對(duì) JAX-WS 的這一特性進(jìn)行了支持，這樣就極大地方便了我們進(jìn)行異步調(diào)用客戶端的創(chuàng)建。
其實(shí)講客戶端配置為異步模式極其簡(jiǎn)單，只要在 RSA 生成 Client 端代碼時(shí)將‘ Enable asynchronous invocation for generated client ’ 選中即可 , 如下圖 :
圖 9. 異步客戶端創(chuàng)建選項(xiàng)
這樣在生成的客戶端的 BookStoreSrvBeanService 中就會(huì)多了 qryBooksByAuthorAsync 的異步方法。既然是異步方法，回調(diào) (Call Back) 就是必不可少的，在下面的異步客戶端測(cè)試代碼中可以看到匿名內(nèi)部類作為回調(diào) handler 的具體使用方法 :
圖 10. 異步客戶端調(diào)用示例代碼
測(cè)試代碼的輸出結(jié)果如下：
圖 11. 異步調(diào)用控制臺(tái)輸出
可以看到，當(dāng) Web 服務(wù)沒(méi)有返回時(shí)，客戶端仍然有機(jī)會(huì)做自己的輸出 :“not done yet, can do something else…”。有些人可能會(huì)認(rèn)為作為客戶端此處的輸出并無(wú)實(shí)際意義，但試想如果一個(gè) server 作為客戶端去訪問(wèn)一個(gè) Web 服務(wù)，如果在服務(wù)等待期間能夠有機(jī)會(huì)脫離阻塞狀態(tài)執(zhí)行自己需要的代碼，甚至可以使用 wait 等方法釋放被當(dāng)前線程占用的資源，那么對(duì)于此 server 來(lái)說(shuō)這將是一個(gè)對(duì)性能提升起到本質(zhì)作用的因素。
使 web 服務(wù)支持批處理模式
● 批處理模式簡(jiǎn)介
批處理顧名思義是采用一次性處理多條事務(wù)的方式來(lái)取代一次一條事務(wù)的傳統(tǒng)處理方式。Java Database Connectivty (JDBC) 中提供了大量的批處理 API 用于優(yōu)化數(shù)據(jù)庫(kù)操作性能，例如 Statement.executeBatch() 可以一次性接收并執(zhí)行多條 SQL 語(yǔ)句。批處理思想可以方便的移植到 Web 服務(wù)調(diào)用場(chǎng)景以達(dá)到優(yōu)化 Web 服務(wù)調(diào)用響應(yīng)的目的。通過(guò)實(shí)際 Web 服務(wù)調(diào)用時(shí)間戳分析不難看出網(wǎng)絡(luò)通訊是 Web 服務(wù)性能的瓶頸之一，因此通過(guò)減少網(wǎng)絡(luò)通訊開(kāi)銷來(lái)優(yōu)化 Web 服務(wù)性能，批處理模式是其中較為直接的一種實(shí)現(xiàn)方式。
●批處理模式適應(yīng)性
批處理模式雖然作用顯著，但是也不適合所有場(chǎng)景。使用批處理模式處理 Web 服務(wù)請(qǐng)求時(shí)需要考慮一下幾點(diǎn)：
1.不同 Web 服務(wù)執(zhí)行時(shí)間差異性
不同 Web 服務(wù)執(zhí)行時(shí)間不盡相同，因此在同時(shí)處理多 Web 服務(wù)請(qǐng)求時(shí)需要考慮這種時(shí)間差異性。一般情況下是等待最長(zhǎng)處理時(shí)間的 Web 服務(wù)執(zhí)行完畢后匯總所有 Web 服務(wù)執(zhí)行結(jié)果從而返回到客戶端，因此存在批處理多 Web 服務(wù)反而比順序單次調(diào)用 Web 服務(wù)消耗更長(zhǎng)時(shí)間可能性。需要在采用批處理模式前對(duì) Web 服務(wù)性能有清晰的了解，盡可能將性能參數(shù)相似的 Web 服務(wù)納入批處理，而分別處理執(zhí)行時(shí)間差異較大的 Web 服務(wù)。一般建議將性能差異在 30% 以內(nèi)的多 Web 服務(wù)可以考慮納入批處理。比方說(shuō) AccountWebService 中有一個(gè)獲取用戶賬戶列表的 Web 服務(wù) getUserAccounts，這個(gè) Web 服務(wù)執(zhí)行需要 15 秒，另外 UserWebService 中有一個(gè)獲取用戶目前 pending 的待處理通知 getUserPendingNotifications，這個(gè) Web 服務(wù)執(zhí)行需要 2 秒時(shí)間，我們可以看到這兩個(gè) Web 服務(wù)執(zhí)行時(shí)間差異較大，因此在這種情況下我們不建議將這兩個(gè) Web 服務(wù)納入批處理。而 AccountWebService 中有一個(gè)增加第三方用戶賬號(hào)的 Web 服務(wù) addThirdPartyNonHostAccount，該 Web 服務(wù)執(zhí)行需要 3 秒，此時(shí)就就可以考慮能將 getUserPendingNotifications Web 服務(wù)和 addThirdPartyNonHostAccount 放在一個(gè)批處理中一次性調(diào)用處理。
2.不同 Web 服務(wù)業(yè)務(wù)相關(guān)性
一般情況下建議考慮將存在業(yè)務(wù)相關(guān)性的多 Web 服務(wù)放入批處理中，只有業(yè)務(wù)存在相關(guān)性的多 Web 服務(wù)才會(huì)涉及到減少調(diào)用次數(shù)以提高應(yīng)用系統(tǒng)性能的需求。比方說(shuō)用戶在增加第三方賬號(hào) addThirdPartyNonHostAccount 以后會(huì)默認(rèn)自動(dòng)發(fā)送一條 pending 的 notification 給用戶用以提示用戶來(lái)激活增加的賬號(hào)，因此這種場(chǎng)景下可以完美的將 addThirdPartyNonHostAccount Web 服務(wù)和 getUserPendingNotifications Web 服務(wù)放入一個(gè)批處理中，在用戶增加完三方賬號(hào)后系統(tǒng)自動(dòng)刷新 pending notification 區(qū)域以提示用戶激活賬號(hào)。UserWebService 中有一個(gè)獲取用戶主賬號(hào)的 Web 服務(wù) getUserHostAccounts 和獲取用戶三方賬號(hào)的 Web 服務(wù) getUserNonHostAccounts，MetaDataService 中有一個(gè)獲取國(guó)家金融機(jī)構(gòu)假期數(shù)據(jù)的 Web 服務(wù) getFinacialAgencyHolidays，該 Web 服務(wù)明顯和 getUserHostAccounts，getUserNonHostAccounts 不存在業(yè)務(wù)上相關(guān)性，因此不應(yīng)該將它們納入批處理。
3.盡量避免將存在依賴關(guān)系的多 Web 服務(wù)放入同一個(gè)批處理中
將多個(gè)存在依賴關(guān)系的多 Web 服務(wù)放入同一批處理中需要專門考慮、處理多 Web 服務(wù)彼此間的依賴關(guān)系，進(jìn)而無(wú)法將方便的這些 Web 服務(wù)并發(fā)執(zhí)行而不得不串行執(zhí)行有依賴關(guān)系的 Web 服務(wù)，最悲觀情況下批處理響應(yīng)時(shí)間將是批處理中所有 Web 服務(wù)串行執(zhí)行時(shí)間和。原則上即使批處理中 Web 服務(wù)間存在依賴關(guān)系，通過(guò)動(dòng)態(tài)指定依賴關(guān)系也可以實(shí)現(xiàn)多 Web 服務(wù)的批處理調(diào)用。但是這樣將大大增加批處理實(shí)現(xiàn)的技術(shù)復(fù)雜性，因此不建議如此操作。
4.多線程方式處理批處理 Web 服務(wù)請(qǐng)求
批處理模式在服務(wù)實(shí)現(xiàn)端一般通過(guò)多線程處理方法來(lái)并發(fā)處理多個(gè) Web 服務(wù)調(diào)用請(qǐng)求。通過(guò)集中的解析器解析批處理模式請(qǐng)求，之后針對(duì)每一個(gè) Web 服務(wù)調(diào)用會(huì)啟動(dòng)一個(gè)單獨(dú)的線程來(lái)處理此 Web 請(qǐng)求，同時(shí)會(huì)有一個(gè)總的線程管理器來(lái)調(diào)度不同 Web 服務(wù)執(zhí)行線程，監(jiān)控線程執(zhí)行進(jìn)度等。在所有線程執(zhí)行完成后匯總 Web 服務(wù)執(zhí)行結(jié)果返回客戶端。
●批處理實(shí)現(xiàn)方式
批處理實(shí)現(xiàn)方式一般有兩種：靜態(tài)批處理模式，動(dòng)態(tài)批處理模式：
靜態(tài)批處理模式實(shí)現(xiàn)較為簡(jiǎn)單，但是相對(duì)缺乏靈活性。靜態(tài)批處理的核心思想就是在已有 Web 服務(wù)的基礎(chǔ)上通過(guò)組合封裝的方式來(lái)得到批處理的目的。舉例來(lái)說(shuō)將系統(tǒng)中已有的 Web 服務(wù)請(qǐng)求結(jié)構(gòu)組合成一個(gè)新的數(shù)據(jù)對(duì)象模型作為 Web 服務(wù)批處理請(qǐng)求結(jié)構(gòu)，在客戶端進(jìn)行批處理調(diào)用時(shí)通過(guò)初始化批處理請(qǐng)求數(shù)據(jù)對(duì)象，并將特定的 Web 服務(wù)請(qǐng)求對(duì)象賦值給批處理請(qǐng)求對(duì)象屬性的方式。同理在服務(wù)實(shí)現(xiàn)端在生成批處理響應(yīng)數(shù)據(jù)對(duì)象時(shí)也是通過(guò)將具體 Web 服務(wù)的響應(yīng)組合起來(lái)生成并返回客戶端。
動(dòng)態(tài)批處理模式實(shí)現(xiàn)較為復(fù)雜，但也能提供更大的操作靈活性。動(dòng)態(tài)批處理模式一般需要應(yīng)用采用 Java 反射 API 開(kāi)發(fā)具有容器功能的批處理實(shí)現(xiàn)框架?？蛻舳丝梢詣?dòng)態(tài)的向容器中增加 Web 服務(wù)調(diào)用請(qǐng)求，比方說(shuō)客戶端可以動(dòng)態(tài)的將 addThirdPartyNonHostAccount，getUserPendingNotifications 兩個(gè) Web 服務(wù)加入到這個(gè)容器中然后發(fā)起一個(gè)框架提供的批處理 Web 服務(wù)調(diào)用請(qǐng)求。該批處理 Web 服務(wù)在實(shí)現(xiàn)端將解析容器并將其中的各個(gè) Web 服務(wù)請(qǐng)求抽取解析并啟動(dòng)獨(dú)立的線程來(lái)處理。
#p#
壓縮SOAP
當(dāng) Web Service SOAP 消息體比較大的時(shí)候，我們可以通過(guò)壓縮 soap 來(lái)提高網(wǎng)絡(luò)傳輸性能。通過(guò) GZIP 壓縮 SOAP 消息，得到二進(jìn)制數(shù)據(jù)，然后把二進(jìn)制數(shù)據(jù)作為附件傳輸。以前常規(guī)方法是把二進(jìn)制數(shù)據(jù) Base64 編碼，但是 Base64 編碼后的大小是二進(jìn)制數(shù)據(jù)的 1.33 倍。辛苦壓縮的，被 Base64 給抵消差不多了。是否可以直接傳輸二進(jìn)制數(shù)據(jù)呢？ JAX-WS 的 MTOM 是可以的，通過(guò) HTTP 的 MIME 規(guī)范， SOAP message 可以字符，二進(jìn)制混合。我們?cè)?client 和 server 端各注冊(cè)一個(gè) handler 來(lái)處理壓縮和解壓。 由于壓縮后的 SOAP 消息附件與消息體中的部分不是基于 MTOM 自動(dòng)關(guān)聯(lián)的，需要單獨(dú)處理附件。在生成 client 端和 server 端代碼的時(shí)候需要 enable MTOM。 Handler 具體代碼在本文代碼附件中， test.TestClientHanlder, test.TestServerHanlder。 寫好了 handler 了之后還要為 service 注冊(cè) handler。
客戶端 handler 樣例代碼如下：
客戶端代碼
- public boolean handleMessage(MessageContext arg0) {
- SOAPMessageContext ct = (SOAPMessageContext) arg0;
- boolean isRequestFlag = (Boolean) arg0
- .get(MessageContext.MESSAGE_OUTBOUND_PROPERTY);
- SOAPMessage msg = ct.getMessage();
- if (isRequestFlag) {
- try {
- SOAPBody body = msg.getSOAPBody();
- Node port = body.getChildNodes().item(0);
- String portContent = port.toString();
- NodeList list = port.getChildNodes();
- for (int i = 0; i < list.getLength(); i++) {
- port.removeChild(list.item(i));
- }
- ByteArrayOutputStream outArr = new ByteArrayOutputStream();
- GZIPOutputStream zip = new GZIPOutputStream(outArr);
- zip.write(portContent.getBytes());
- zip.flush();
- zip.close();
- byte[] arr = outArr.toByteArray();
- TestDataSource ds = new TestDataSource(arr);
- AttachmentPart attPart = msg.createAttachmentPart();
- attPart.setDataHandler(new DataHandler(ds));
- msg.addAttachmentPart(attPart);
- } catch (SOAPException e) {
- e.printStackTrace();
- } catch (IOException e) {
- e.printStackTrace();
- }
- }
- return true;
- }
Web 服務(wù)端 handler 樣例代碼如下：
服務(wù)端代碼
- public boolean handleMessage(MessageContext arg0) {
- SOAPMessageContext ct = (SOAPMessageContext) arg0;
- boolean isRequestFlag = (Boolean) arg0
- .get(MessageContext.MESSAGE_OUTBOUND_PROPERTY);
- SOAPMessage msg = ct.getMessage();
- if (!isRequestFlag) {
- try {
- Object obj = ct.get("Attachments");
- Attachments atts = (Attachments) obj;
- List list = atts.getContentIDList();
- for (int i = 1; i < list.size(); i++) {
- String id = (String) list.get(i);
- DataHandler d = atts.getDataHandler(id);
- InputStream in = d.getInputStream();
- ByteArrayOutputStream out = new ByteArrayOutputStream();
- GZIPInputStream zip = new GZIPInputStream(in);
- byte[] arr = new byte[1024];
- int n = 0;
- while ((n = zip.read(arr)) > 0) {
- out.write(arr, 0, n);
- }
- Document doc = DocumentBuilderFactory.newInstance()
- .newDocumentBuilder()
- .parse(new ByteArrayInputStream(out.toByteArray()));
- SOAPBody body = msg.getSOAPBody();
- Node port = body.getChildNodes().item(0);
- port.appendChild(doc.getFirstChild().getFirstChild());
- }
- } catch (SOAPException e) {
- e.printStackTrace();
- } catch (IOException e) {
- e.printStackTrace();
- } catch (SAXException e) {
- e.printStackTrace();
- } catch (ParserConfigurationException e) {
- e.printStackTrace();
- }
- }
- return true;
- }
在 web.xml 中 service-ref 部分添加 handler. Server 端 handler 也是同樣添加。
配置代碼
TestClientHandler test.TestClientHandler
網(wǎng)頁(yè)標(biāo)題：Java Web服務(wù)性能優(yōu)化實(shí)踐
當(dāng)前鏈接：http://m.fisionsoft.com.cn/article/djjsehh.html
