This week's book giveaway is in the Jobs Discussion forum.
We're giving away four copies of Java Interview Guide and have Anthony DePalma on-line!
See this thread for details.
The moose likes EJB and other Java EE Technologies and the fly likes if from client code we directly access entity beans then what Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "if from client code we directly access entity beans then what " Watch "if from client code we directly access entity beans then what " New topic

if from client code we directly access entity beans then what

kenji kunoichi
Ranch Hand

Joined: Jun 02, 2007
Posts: 46
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 ?

Jeanne Boyarsky
author & internet detective

Joined: May 26, 2003
Posts: 33132

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.

[OCA 8 book] [Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
aleem khan
Ranch Hand

Joined: Aug 07, 2008
Posts: 94
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

SCJP(1.4), SCWCD, Oracle 9i SQL certified, Oracle PLSQL Developer Certified Associate
Zenikko Sugiarto
Ranch Hand

Joined: Jan 09, 2005
Posts: 58
"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:
subject: if from client code we directly access entity beans then what
It's not a secret anymore!