I like session bean wrappers because I really like the MVC pattern -- the
client represents the view, the entity beans represent the model, and the
session beans represent the controller.
NOTE: I'm not recommending one session bean wrapper per entity bean. There's
no value to session bean wrappers unless you are using the session bean as a
concentrator.
In many applications the view uses multiple model instances. If the client
works directly with the entity beans, then the client has to get a reference
for each entity bean instance. If you wrap the entities with a session bean,
then the client only needs one reference. The session bean manages all of
the references to the entity instances. This approach definitely reduces
resource requirements (one OUT reference versus many OUT references).
You could implement the controller function using an entity bean (using a
session ID as the primary key). This approach has some significant
advantages -- the session data could be persistent, so you could easily
recover a lost session.
Anne
-----Original Message-----
From: Imre Kifor [mailto:[EMAIL PROTECTED]]
Sent: Saturday, May 15, 1999 11:12 PM
Subject: Real advantage of session bean wrappers?
Considering recent postings, I must ask the question:
"Is there any real advantage to wrap entity beans with session beans?"
Here are the reasons for my question:
- some posters have questioned the validity of encapsulating conceptually
related data inside two or more beans. I strongly agree with them.
- some posters have questioned the much publicized performance gains when
calling session beans as opposed to entity beans. I strongly agree with
them; a remote call is a remote call.
- some posters have questioned the "special capabilities" attributed to
session beans (as opposed to entity beans) "when it comes to accessing ejb's
of any type", returning custom data or dealing with transactions. I strongly
agree with them.
- some posters have complained about having to wrap all client calls to
session objects in try/catch blocks to deal with session object expirations
thus making client logic convoluted and client code brittle. See my previous
posting.
- some posters have complained that ad-hoc data already resident on the
server cannot be cached and shared among different clients. We avoid using
session beans for sharable or not client related data.
- I stated that session beans are conceptually more expensive on the server
than entity beans (the server has to manage timeouts).
- I raised the issue that some platforms cannot conceptually reclaim
unreferenced entity objects thus leading to resource exhaustion.
I certainly hope, based on the above, that some posters of this list are not
simply glorifying a platform shortcoming (i.e. not being able to release
entity objects thus forcing the use of session objects) into full fledged
paradigms of EJB usage.
VERY IMPORTANT NOTE: Since wrapping of entity beans into session beans is a
usage paradigm and the above conceptual flaw is a platform characteristic,
the EJB architecture (and spec) is not questioned. Furthermore, session
beans are complementary to entity beans and both are necessary for
implementing feature complete solutions.
Imre Kifor
Valto Systems
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
