無狀態EJB：在性能和安全性之間找到平衡點

我有一個JSF Web客戶端和一個Java客戶端，它們的應用程序邏輯都使用相同的無狀態EJB層。我不確定如何平衡性能需求（限制表示層和應用層之間傳輸的數據量）與安全性（從確保所有決策基於最新數據的角度來看）之間的平衡。無狀態EJB：在性能和安全性之間找到平衡點

我明白，這是一個主觀題，所以也許我可以使其更客觀結合具體實例：

不要只送上我的用戶名到EJB的，然後加載到每個用戶的實體，每個EJB調用，還是我從表示層發送用戶實體？
如果我需要更多的信息，而不僅僅是用戶實體（假設我需要在每個EJB調用中加載一個額外的實體），我會發送用戶名和其他實體的密鑰並加載應用層中的兩個實體，或者我是否從表示層發送兩個實體？
如果我需要更多關於某些EJB調用（> = 3個實體）的更多信息，那麼怎麼辦？

什麼時候發送實際的實體而不是隻發送它的密鑰，或者永遠不會回答，總是重新加載到應用層？我應該擔心表現嗎？我聽說Hibernate（我正在使用）使用智能緩存，這意味着用戶實體可能不會每次都從數據庫重新加載？如果我的EJB方法的粒度非常小，並且前端操作有時可能會導致調用3個或更多的EJB方法，那麼每個EJB方法都需要加載用戶實體呢？

最後的相關問題：我打算使用JAAS主體來存儲由EJB加載的用戶名。如果我的遠程外觀EJB調用一堆也需要用戶信息的本地無狀態EJB，那麼我仍然使用JAAS主體並在它們中的每一箇中加載用戶實體，或者有更好的方法嗎？

來源

2009-09-16 Zecrates

您應該考慮有狀態的EJB，因爲它聽起來像客戶端需要非平凡的狀態來回答關於來自一個用戶的相同狀態的一系列請求。也就是說，有狀態的EJB對於正確編寫和配置來說是一種忍耐。

就設計而言，我不會讓客戶端將用戶信息發送到業務邏輯層。一，它只是把問題拋給客戶，不是嗎？加載，存儲和發送此信息？也讓我從安全角度感到緊張，讓大概不那麼安全的客戶端層將敏感用戶數據提供給更安全的後端層，然後信任並使用該信息。

但是，真的，我想你已經提到了最好的方法：Hibernate的延遲加載。您只需與對象進行交互，並根據需要加載數據。爲了在這方面與Hibernate一起使用，User對象應該很小，以便加載它很快，並將所有大而重的信息推送到子對象或其他實體中。那麼，如果你不得不加載用戶很重要，它只是其他信息的'指針'。

我不認爲它會改變事情，如果你使用JAAS，沒有。儘管我可能會說，因爲我認爲你的目的是，JAAS可能會也可能不值得。在您整合，寫入權限，使用這些權限，處理SecurityManager的後果等等時，您可能只需爲自己寫一個簡單的權限框架。

來源

2009-09-16 08:06:26

我同意沒有客戶給我任何實體信息，但我擔心表現。我想使用JAAS，所以我可以檢索經過身份驗證的主體，我不知道如何在EJB端檢索用戶名（如果我只是將它作爲參數傳遞，我如何確保客戶端通過該用戶名進行身份驗證並不只是構建它）？另外，你是否建議我將我的用戶實體傳遞給所有非門面會話bean，還是應該獨立執行並從用戶名加載實體？ – Zecrates 2009-09-16 08:30:12

直到您知道這是一個問題時才需要擔心性能。通過Hibernate加載一個輕量級的用戶對象不會導致性能問題，所以如果這是一個問題，我會走這條路並稍後調整。我明白了，你正在使用容器認證，這就是爲什麼JAAS在玩的原因。這本身似乎是您自己管理身份驗證的一個很好的選擇。我會有每個對象加載用戶根據需要。序列化一個Hibernate管理的用戶對象可能不像你想象的那樣工作，或者至少強迫Hibernate完全實例化這個對象，這並不酷。 – 2009-09-16 12:38:43

如果您只製作一個EJB，則進行無狀態會話。我個人發現它騙子空接口

來源

2009-09-17 05:31:21