通過寫這篇文章，我冒著被.NET和Java社區(qū)拒絕的巨大風(fēng)險(xiǎn)。 試圖解釋Java術(shù)語WCF （代表Windows Communication Foundation）是什么。

從WCF到Java的映射并不是很簡單。 我缺乏對(duì)WFC使用者應(yīng)該了解的與服務(wù)通信類型的了解：請求/響應(yīng)或異步消息傳遞。 我很難想象這對(duì)于用戶來說是完全透明的……除非WCF框架“消除”消息傳遞的異步性并照顧等待響應(yīng)消息。 如果最新發(fā)生，那么實(shí)際上沒有異步消息！

像往常一樣，使用Java（我真的很想念它與.NET一起使用），存在技術(shù)規(guī)范，并且這些規(guī)范有各種實(shí)現(xiàn)。 盡管通常使用這些應(yīng)用程序進(jìn)行測試，因此聲稱可以支持所用規(guī)范的明確實(shí)現(xiàn)，但從理論上講，最終選擇是在部署期間或在應(yīng)用程序啟動(dòng)之前完成的。

每當(dāng)我們談?wù)摲?wù)時(shí)，我們都會(huì)擁有實(shí)際的服務(wù)及其消費(fèi)者。

讓我們從消費(fèi)者開始。 為了發(fā)送異步消息，最好針對(duì)JMS （Java消息系統(tǒng)規(guī)范）編寫它們。 JMS的使用者只需要知道目標(biāo)隊(duì)列或主題的邏輯名稱即可。 對(duì)于請求/響應(yīng)通信，應(yīng)該針對(duì)普通的服務(wù)接口編寫消費(fèi)者。 該接口與服務(wù)端和傳輸層中使用的技術(shù)無關(guān)。 為了在運(yùn)行時(shí)獲得接口的顯式實(shí)現(xiàn)，使用者使用外部可配置的Factory。 該工廠將為Web服務(wù)使用JAX-WS ，為RESTful服務(wù)使用 JAX-RS ，為遠(yuǎn)程EJB（企業(yè)Java Bean）使用RMI或?yàn)檫M(jìn)程內(nèi)服務(wù)使用純對(duì)象（PO??JO）。

你還在嗎？ 然后，我們轉(zhuǎn)到服務(wù)端。 如果服務(wù)使用消息，則可以直接使用JMS或?qū)⑵渥鳛橄Ⅱ?qū)動(dòng)Bean（EJB風(fēng)格）來實(shí)現(xiàn)。 最后一個(gè)選項(xiàng)為您提供了來自Application Server（類似于IIS）的所有事務(wù)性和可伸縮性。 如果服務(wù)應(yīng)該提供響應(yīng)（包括失敗），則黃金法則是讓它們實(shí)現(xiàn)一個(gè)簡單的接口，即服務(wù)使用者將使用的接口。 然后，通過向接口實(shí)現(xiàn)代碼中添加注釋或通過在Application Server中使用外部配置，您的實(shí)現(xiàn)都可以作為Web Service或Session EJB進(jìn)行訪問。 實(shí)際上，如今，大多數(shù)服務(wù)器都能夠?qū)?huì)話EJB公開為Web服務(wù)。 如果使用代理模式，那么您還將擁有一個(gè)干凈，完好的接口實(shí)現(xiàn)，供進(jìn)程內(nèi)使用方使用。

這是一個(gè)很冗長的解釋。 “ 所有跨層實(shí)體都是WCF服務(wù) ”的簡短翻譯是：

“所有實(shí)體均由其接口定義，并針對(duì)其他實(shí)體的接口編寫。 實(shí)體的實(shí)現(xiàn)是普通的舊Java對(duì)象（PO??JO），可能由EJB代理包裝”

翻譯自: https://www.javacodegeeks.com/2014/04/attempt-to-map-wcf-to-java-terms.html

總結(jié)

以上是生活随笔為你收集整理的尝试将WCF映射到Java术语的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。