通過寫這篇文章，我冒著被.NET和Java社區拒絕的巨大風險。 試圖解釋Java術語WCF （代表Windows Communication Foundation）是什么。

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

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

每當我們談論服務時，我們都會擁有實際的服務及其消費者。

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

你還在嗎？ 然后，我們轉到服務端。 如果服務使用消息，則可以直接使用JMS或將其作為消息驅動Bean（EJB風格）來實現。 最后一個選項為您提供了來自Application Server（類似于IIS）的所有事務性和可伸縮性。 如果服務應該提供響應（包括失敗），則黃金法則是讓它們實現一個簡單的接口，即服務使用者將使用的接口。 然后，通過向接口實現代碼中添加注釋或通過在Application Server中使用外部配置，您的實現都可以作為Web Service或Session EJB進行訪問。 實際上，如今，大多數服務器都能夠將會話EJB公開為Web服務。 如果使用代理模式，那么您還將擁有一個干凈，完好的接口實現，供進程內使用方使用。

這是一個很冗長的解釋。 “ 所有跨層實體都是WCF服務 ”的簡短翻譯是：

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。