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".
