Clever Geek Handbook

Stateless EJBs: Finding the Balance Between Performance and Security

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

I understand this is a subjective topic, so maybe I can make it more objective with specific examples:

  • Am I only posting the username to the EJB and then loading the User object on every EJB call or posting the custom object from the presentation layers?
  • If I need more information than just a custom object (say I need to load an additional object for each EJB call), would I send the username and another object key and load both the objects at the application layer, or send both sides from the presentation layers?
  • How about if I need even more information for certain EJB calls (> = 3 objects)?

When does it make sense to send an actual entity instead of your key, or does the response never reload on the application layer side? Should I be worried about performance? I heard that Hibernate (which I am using) uses smart caching, meaning the custom object probably won't reload from the database every time? What if my EJB methods have very little granularity and interface action, sometimes 3 or more EJB methods might be called, each of which must load a User object?

Last related question: I intend to use a JAAS principal to store the username that is loaded by the EJB. What if my remote EJB facades are calling a bunch of local stateless Ecls that also require user information, am I still using the JAAS principle and loading a User object in each one, or is there a better way?

+2


source to share


2 answers


You should consider EJB states as it looks like clients need non-trivial state to respond to multiple requests for the same state from the same user. However, stateful EJBs are kind of a bear that writes and configures correctly.

-. -, , ? , ? , , -, .



But really, I think you already mentioned a better approach: Hibernate 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 needs to be small so that loading is pretty fast and pushing all the big, heavy information into child objects or other objects. Then it doesn't matter if you need to download a lot of the User; it is just a "pointer" to other information.

I don't think this changes things if you are using JAAS, no. While I can say that, as I understand your goals, JAAS may or may not be appropriate. In the time it takes to integrate, write permissions, use those permissions, troubleshoot the SecurityManager, etc., you could probably just write a simple permission structure for yourself anyway.

+1


source


if you only make one EJB do session without saving. personally i found these are humbug empty interfaces



0


source






More articles:


All Articles