Stateless EJBs: Finding the balance between performance and security

Question

I have a JSF web client and a Java client that both use the same stateless EJB layer for their application logic. I'm unsure of how to balance the need for performance (limiting the amount of data that is transported between the presentation and application layers) with security (in the sense of ensuring all decisions are made based on up to date data).

I understand that this is a subjective topic, so perhaps I can make it more objective with concrete examples:

• Do I only send the username to the EJBs, and then load the User entity on each and every EJB call, or do I send the User entity from the presentation layers?
• If I need more information than just the User entity (let's say I need to load an additional entity on each EJB call), do I send the username and the other entity's key and load both the entities in the application layer, or do I send both entites from the presentation layers?
• What about if I need even more information for certain EJB calls (>= 3 entities)?

When does it make sense to send the actual entity instead of just its key, or is the answer never, always reload on the application layer side? Should I be worried about performance? I've heard that Hibernate (which I'm using) employs intelligent caching meaning the User entity probably won't be reloaded from the DB every time? What if my EJB methods have a very small granularity and frontend actions might sometimes cause 3 or more EJB methods to be called, with each needing to load the User entity?

A final related question: I intend on using the JAAS principal to store the username which is loaded by the EJBs. What if my Remote facade EJBs call a bunch of Local stateless EJBs that also require the user information, do I still use the JAAS principal and load the User entity in each of them as well or is there a better way?

Answer 1

You should consider stateful EJBs, since it sounds like the clients need non-trivial state to answer a series of requests concerning the same state from one user. That said, stateful EJBs are kind of a bear to write and configure properly.

As a matter of design, I would not have the clients send user information to the business logic layer. One, it just punts the problem over to the client, no? to load, store and send this info? also it makes me nervous from a security perspective, to let a presumably less-secure client tier feed sensitive user data to a more-secure backend-tier which then trusts and uses that info.

But, really, I think you mentioned the best approach already: Hibernate's lazy loading. You just interact with the object and let it load data on demand. To work well with Hibernate in this regard, the User object should be small, so that loading it is fairly quick, and push all the big, heavy info into child objects or other entities. Then it doesn't matter if you have to load User a lot; it's just a bit of a 'pointer' to other info.

I don't think it changes things if you use JAAS, no. Although I might say, for what I imagine your purposes are, JAAS may or may not be worthwhile. In the time it takes you to integrate, write permissions, use those permissions, deal with consequences of the SecurityManager, etc. you probably could have just written a simple permissions framework for yourself anyhow.

Answer 2

if you make just one EJB, make stateless session. personally i found it humbug empty interfaces