您真的了解@WebService吗?
生活随笔
收集整理的這篇文章主要介紹了
您真的了解@WebService吗?
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
SOAP Web服務無論如何都不是最先進的技術-盡管它仍然存在,但是基于REST的Web服務卻提供了激烈的競爭。 無論如何–這絕對不是REST vs SOAP帖子!
我觀察到了一些實例,至少可以說,使用基于Java的SOAP Web服務的方式不太理想。 我認為,這是由于對一般的JAX-WS (基于SOAP的Web服務的Java EE規范)的一些基本知識缺乏了解而引起的。
這篇文章中提到的是與使用JAX-WS構建的基于SOAP的Web服務相關的基本知識。 討論的一些要點是:
- @WebService批注的POJO的生命周期是多少?
- 線程安全嗎? 如果在您的Web服務上觸發并發客戶端請求會怎樣?
@WebService批注
從技術上講,@ WebService批注是將POJO轉換為SOAP端點所需的全部。 不足為奇的是,這就是我們通常要做的全部工作–用@WebService和其他輔助注釋(例如@ WebMethod,@ WebParam等)注釋類,部署WAR,啟動SoapUI ,運行一些測試并榮耀一下!
您應該了解有關用@WebService注釋的POJO的事情
- 由Web容器提供在WAR中部署的帶有@WebService批注的POJO(這很重要)
- 生命周期 – POJO的單個實例服務于客戶端的請求。 非常類似于Servlet。
- 并發方面 (線程安全)–它們不是線程安全的 。 多個線程可以同時訪問 Bean的同一實例。 盡管如果您的服務是無狀態的,即不使用實例變量來存儲狀態,這不是問題,盡管您可能仍然會遇到可伸縮性問題(畢竟,它只是一個實例!)。 如果您的POJO使用實例變量存儲狀態,那么您將陷入困境,并且肯定會遇到由于并發線程訪問Web服務類的單個實例而導致行為不一致的問題。
。
- 人們應該使Web服務成為無狀態的 –忘卻風格。 不要最終將狀態存儲在實例變量中
- 如果您確實選擇使用實例變量,請確保您是開發人員,以線程安全的方式對Web服務進行編碼。 這里有多個選項,其中一些選項包括使用良好的舊同步 (雖然還不理想!), 線程安全集合 (ConcurrentHashMap)等。
- 最佳解決方案IMO –如果使用的是與Java EE兼容的應用服務器(例如Weblogic),則應始終將Web服務部署為EJB (在這里我不會深入探討EJB的詳細信息!您可以參考我以前的文章)如果有興趣)。
- 你會從中得到什么? (1)EJB 默認是線程安全的 。 您無需擔心將并發和線程安全作為業務邏輯的一部分–您可以免費獲得它! (2) EJB是池化組件 –容器將實例緩存在內存中,并根據請求將其分配給客戶端。 免費的可伸縮性 ( 注意 – EJB池配置是特定于容器的,并且每個服務器都定義了實現此目標的特定方式)(3) EJB默認是跨國的 –如果您將后端數據庫作為Web服務邏輯的一部分進行訪問,EJB是理想的(事務的細節最好由真正了解它們的人來處理!我不會試圖表現得好像我知道它們是端到端一樣讓自己感到尷尬)
- 如何“啟動”我的Web服務? (1) 僅使用@Stateless批注 –這將使您純粹的POJO變成一個成熟的EJB ,它現在可以享受所有容器服務(2) 將您的Web服務部署為不是作為WAR,而是作為打包在EAR中的EJB-JAR 。 這將確保EJB容器抓住您的POJO,并編織出我一直吹牛的所有魔力!
測試中
我不是測試專家,但是JMeter這樣的工具可以讓我看起來更聰明! 為自己和用戶JMeter提供一個方便,以簡化SOAP Web服務測試過程。 沒那么難。 下面的瑣碎示例
客戶角度
- 至于從現有的WSDL生成存根,我肯定會選擇Java SE本身內的標準功能 。 我只是在說明這一點,因為過去它對我來說是完美無缺的,而不是嘗試使用其他實現(例如Axis 2或Apache CXF)
- 我并不是要破壞它們,但是當JDK本身有一個有據可查的標準工具時,我看不到浪費時間研究其他東西的價值! 只需跳到JAVA_HOME / bin ,尋找wsimport命令并進行破解即可。
- 提供存根生成功能的大多數IDE都利用此工具
這只是種快速的咆哮。 希望有道理
干杯!
翻譯自: https://www.javacodegeeks.com/2015/02/do-you-really-understand-webservice.html
總結
以上是生活随笔為你收集整理的您真的了解@WebService吗?的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 电脑密码忘记了怎么办忘记电脑密码了如何进
- 下一篇: 将策略插入JBoss Apiman