爲什麼我們需要單獨的EJB 3.0會話bean的遠程和本地接口

Question

我想知道爲什麼我們需要單獨的EJB 3.0會話Bean的遠程和本地接口。我想大多數時候他們都會定義同樣的合同。爲什麼我不能有一個通用的接口，並且在我的Bean中，我應該可以說我想讓這個bean遠程和/或本地訪問。

感謝 維卡斯

Answer 1

，我不同意，在設計時遠程和本地應平凡的，多變的內部處理。

首先，在遠程調用中會有開銷，所以在設計遠程接口時，您需要仔細考慮是否正確設置了粒度和參數大小。所以提醒這將是比較昂貴的作爲設計師是有幫助的。

另外，鑑於遠程接口參數通過值傳遞，本地接口參數通過引用傳遞，這兩種情況之間存在基本的語義差異，因此您可以選擇以不同方式設計這兩個接口。

Answer 2

「位置透明度」的概念是一種危險的反模式。您的設計絕對需要知道是否進行本地呼叫或遠程調用，原因很多（錯誤處理和性能最明顯）。

遠程EJB接口不同於其本地對應方，因爲異常簽名需要不同以容納只能發生在遠程調用上的與網絡有關的錯誤。將遠程處理行李託運到Local接口（如EJB 1中的情況）使代碼變得可怕。 EJB 2引入了單獨的本地接口，以簡化對始終本地EJB的編程。

Answer 3

這是EJB規範說什麼：

本地和遠程編程模型之間的選擇是一個設計決策，發展企業Bean時，Bean提供使。
儘管可以爲企業bean提供遠程客戶端視圖和本地客戶端視圖，但更典型的是只有一個或另一個將被提供。

JSR220 Chapter 3

所以寫一個bean想想誰是客戶端時，這是非常不可能的本地客戶端都需要同樣的方法，甚至同一個bean是遠程的。

Answer 4

一個很好的理由是因爲您通過其接口訪問EJB。這樣，在使用遠程接口時通過值傳遞參數，並在使用本地接口時通過引用傳遞參數。你知道爲什麼會這樣嗎？它是有道理的：也許你希望遠程應用程序訪問你的業務對象，並且因爲通過引用減少了網絡延遲。請記住：遠程訪問涉及將對象轉換爲字節流的過程 - 編組 - 將字節流轉換爲對象的過程 - 解組。這個額外的步驟 - 封送和解組 - 會降低應用程序的性能。

Answer 5

我相信，當您的企業需要在當地所有的方法也需要暴露在遠程客戶端，然後

1. 與方法定義你的本地接口。
2. 有你的遠程接口與空，但延長的本地接口
3. 都在本地
4. 具有遠程bean實現實際的業務邏輯和其他實現只是委託給當地的bean實現

這方法可能是爲了實現@Local & @Remote到相同的接口。如果需要，可以在本地訪問相同的方法，如果需要，可以遠程訪問，無需任何性能開銷

這是我的想法。有人請讓我知道你的想法來驗證這一點。

Answer 6

客戶端通過bean的接口訪問會話或實體bean。 EJB容器生成接口實現來執行和管理這種行爲，充當客戶端和bean之間通信的通道。在EJB 2.0規範之前的版本中，所有bean都是作爲分佈式遠程組件定義和實現的。因此，bean所需的兩個接口被稱爲home接口（通常定義生命週期方法）和遠程接口（通常定義功能性業務方法）。

Internally, J2EE uses the Java Remote Method Invocation over Internet Inter-ORB Protocol (RMI-IIOP) to enable remote, distributed method calls and applications. While this approach provides many benefits, it also generates a large amount of overhead, with a corresponding performance hit as stubs are referenced, parameters go through the marshaling process, and objects are tossed around the network. 

Considerations of performance, practicality, and typical usage in the field resulted in the introduction of local interfaces in the EJB 2.0 specification. As noted, prior terminology referred to the home interface and the remote interface; at this point, depending on which approach is used, local interface and local home interface or remote interface and remote home interface are better terms. Either of the local home or remote home interfaces is referred to as the home interface; either of the local or remote interfaces is referred to as the component interface. This tutorial refers to the interfaces in these terms and uses these conventions for names. 

When using J2EE technologies, it is normal to focus on distributed, or remote, beans, but you should keep the local option in mind, when applicable. It may be surprising to learn that a bean can have local interfaces, remote interfaces, or both. However, the client must write to a specific (that is, local or remote) interface. There are some issues to keep in mind when using local interfaces: 

bean必須運行在同一個虛擬機 - 它們畢竟是本地的。 參數通過引用發送而不是被複制，遠程接口和對象就是如此。如果您忽略這種區別並且沒有相應的編碼，可能會導致意外的副作用。 通常，使用本地或遠程訪問的決定會受到以下影響：

客戶端類型 - 除非您始終期望客戶端是Web組件或另一個Bean，否則請選擇遠程訪問。

bean是緊密耦合還是鬆散耦合 - 如果bean相互依賴並且頻繁交互，請考慮本地訪問。

可伸縮性 - 遠程訪問具有固有的可擴展性，如果可伸縮性是一個重要因素，則應該使用。 隨着EJB 2.0規範中本地接口的出現，大多數資源建議實體bean幾乎總是基於本地訪問。使用本地接口，關於非常細粒度的數據訪問的大多數性能問題都會消失。如果客戶端是遠程的，則標準設計模式使客戶端使用遠程接口來訪問會話bean，然後該會話bean充當與實體bean的聯繫人。會話bean通過本地接口與實體bean進行通信（從模式的角度來看，這種技術稱爲會話外觀，實際上它可以在遠程或本地環境中使用）。