This week's book giveaway is in the Clojure forum.
We're giving away four copies of Clojure in Action and have Amit Rathore and Francis Avila on-line!
See this thread for details.
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

if from client code we directly access entity beans then what

 
kenji kunoichi
Ranch Hand
Posts: 46
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
why remote entity beans are a bad idea ? why dont we directly access entity beans from the client code ? why we put session beans in between ?


kenji
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 33697
316
Eclipse IDE Java VI Editor
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kenji,
I can think of two reasons.
1) Performance - the network traffic would be a killer. There would be way too many round trips which would make the performance really slow.
2) Encapsulation - the client would know to much about your implementation details. Which means you could never change them. Whereas a session bean lets you hide this logic from the client and have them request things on a higher level. That way the client can get "account data" without caring how many tables it is called in.
 
aleem khan
Ranch Hand
Posts: 94
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you don't use session beans then where would you put your business logic? Entity beans are mere representation of data which is in object form. And as per EJB 3.0 speicification an EntityBean will now be managed by separate API called JPA(JAVA PERSISTANCE API)... We dont require EJB container anymore to run Entity Beans, it is like plain old java object now.
The other issue could be performance. Imagine if 2000 users are using
the application. It has to make 2000 remote calls to Entity beans i,e indirectly to database which could be costly affair and very slow in performance or the server may even crash. If we session beans in between
EJB 3.0 container would take care of Multithreading, security, transaction and would easily handle 2000 users . Then local call from entity beans to database would be fast. Hope it is clear now
 
Z Sugiarto
Ranch Hand
Posts: 58
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"why the hassle of having a layer of session beans if I can just use those entity beans directly?"

having more layers (if designed correctly) will make the system to be more 'expandable': - better maintainability, better support for future modification and so on.

Think of the design as a foundation for growth, so if the foundational design and implementation is good, it can evolve quite far in the future.

But if the system will not have such a need in the future, and only used by very few people (i.e not 'enterprise' in any significant way) then you probably don't have to worry that much into having such elaborate foundation structure in your system.

However in such a scenario, you should probably evaluate as to whether or not you REALLY want to choose EJB to build your solution.

If you wanted to access your 'persistance-aware' objects directly from the client, there's stuff like Hibernate or Toplink that you can use too...

[ August 30, 2008: Message edited by: Zenikko Sugiarto ]
[ August 30, 2008: Message edited by: Zenikko Sugiarto ]
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic