无状态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