I agree that people tend to use entity beans when they want to use one of
the following features provided by entity beans.
1. CMP - apps where OR mapping is pretty simple
2. Locking model -
a. pessimistic
b. optimistic - involves creating copies and synchronizing
with server cache.
- this is a powerful feature for several apps which most ejb containers will
give you.
3. Server caching
4.Declarative transactions- some entity objects require seperate transaction
semantics - other than those passed in by session beans.
I feel that for some projects , this is a lot of work to do in-house so we
shouldn't just give up on entity beans. I do agree that often people want to
use one or 2 of the features above but get all the entity bean features as a
package. often people don't want the overhead of features they don't want.
At times the features interfere with the way the architects want the those
features to work. So it's a difficult choice for some.
Also, as far as passing the entity java objects to the client is concerned I
wanted to point out that it might be better to use copy objects instead of
serializing the java entity objects residing on the server. The reason being
that for some apps the java entity objects have references to other entity
objects and if one's not careful could end up sending huge object graphs
back and forth. So it might be better to use hashtables or light copy
objects to communicate between client and server.
Sachin
> -----Original Message-----
> From: Ian McCallion [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 24, 2001 6:18 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Why use entity beans?
>
>
> Dave Glasser wrote:
> >
> > I want to thank everyone for their well-thought-out responses to my
> > question about entity beans, particularly Richard, who basically
> > banged out a magazine article on the subject within a few
> hours of my
> > original post.
> >
> > I think I should clarify that the architecture we've
> decided upon does
> > not use session beans to model business concepts, We're using simple
>
> I'm assuming you mean you decided not to use ENTITY beans to
> model business
> concepts;-)
>
> > data objects, with fields, setters and getters, much like entity
> > beans, except that these objects are serialized and sent to the
> > client. We use optimistic locking based on a timestamp and
> num_updates
> > field to keep users' updates from conflicting with each other. The
> > client can manipulate a data object to its heart's content,
> then pass
> > it back to a someSessionBean.update(someDataObject) method
> to save the
> > changes to the database. This strikes me as a much more scalable
> > solution; there's virtually no client data being kept in the EJB
> > container, and little if any conversational state. The main function
> > of the container is to provide services like DB connection pooling,
> > transaction management, and some security services. There's a data
> > access layer where the tables are mapped to data object classes, and
> > where all of the DB I/O occurs, and these methods (all static) are
> > called by session beans which are in turn called by the clients.
> >
> > For our current project, the "clients" are going to be servlet
> > containers, but they could just as easily be Swing apps or applets.
> > When you have a GUI client, it makes even more sense, IMO,
> to have the
> > data objects on the client instead of a remote server. If, for a
> > JTable, you had a TableModel that made a remote call for each table
> > cell it had to paint on the screen, you can imagine how much network
> > traffic it could generate.
>
> I'm sure that can be made to work, but given that all the
> functionality of the
> application resides (multiple times) in the clients, what are
> you gaining by
> using a RDBMS and an app server compared to using an OODB
> accessed directly by
> the clients, or even, compared to remote SQL? It seems to me
> that the whole
> point of an app server is to manage Applications.
>
>
> Ian McCallion
> Alexis Systems Limited
> Romsey, UK
>
> ==============================================================
> =============
> 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".
>
>
===========================================================================
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".
