On Wed, 24 Jan 2001 14:18:03 +0000, Ian McCallion
<[EMAIL PROTECTED]> wrote:
>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;-)
Actually I meant session beans. I was responding to Richard
Monson-Haefel's post where he discussed using session beans to model
business concepts in much the same way that entity beans do.
>
>> 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.
Most of the actual business logic functionality will in fact occur
inside session beans, except that it will act on simple data objects
instead of entity beans. The "business rules", so to speak, will be
coded inside session beans. When one of these rules are executed,
however, it will be a quick transaction, using passed-in parameters.
There will be no conversational state built up in the EJB container
prior to a transaction being executed. (There will in some cases be
conversational state built up in the servlet container.)
We'll still have the benefit of declarative transaction management,
and in some cases distributed transactions, that EJB provides, and in
my estimation that benefit is nothing to sneeze at. One thing I like a
lot about EJB is how much you're able to configure your application at
deploy time -- things like transaction boundaries, or binding a
particular service to a JNDI name referenced in code, or selecting
which type of bean class you want to deploy with a particular
home/remote interface pair, etc.
Believe me, I'm not one to use a technology just because it seems to
be the hottest buzzword of the moment. I'll always ask myself, "what
does this get me?" first, and if I can't come up with a reasonable
answer, I won't use it. (Assuming the decision of whether to use it is
mine, of course. :) This whole thread started because I was asking
that very question about entity beans.
===========================================================================
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".
