I've got an answer: Clustering
Multiple VM's or clients that don't know about each other is enough to trash
smart keys; these keys
are as smart as they're informed by the server about their state.
EJB, as well as (in a minor scale) COM & CORBA, make possible separating
three things that make up
all components: state, behavior and behavior contract. Tough it's possible
to model any service to be completely
stateless and multi-host inmune, that implies modelling each and every
possible use-case; MTS/COM+ programmers may
know what I'm talking about. By allowing the server to enforce the
contract(perhaps by maintaining communication across
a logical cluster or island), modelling of a service or solution can be done
in a more OOP manner.
However, this is the dawn of EJB technologies. Not only the spec is
maturing, also are the providers. It seems somehow
futile to speak about EJB 2.0, while it is in a draft stage; even when it
becomes a public standard it will not be implemented
for several months(tough WebLogic and Orion are coming very close). However,
you may find interesting that EJB 2.0 requires every app server to allow for
persistance managers to be plugged in, so in fact, you may be able to code
that instead of a generation tool (as a sidenote, almost everywhere I go, I
find one of these, and they're irremediable tied up to a relational model
that is VERY database dependant, which is one thing EJB has been able to
avoid so far). You may even purchase a persistance manager of your choice,
with cache or maybe stateless, which enforces transactions (and tx
isolation) independant of the database(or, why not, connectable persistence
like SAP,ERP,CRM or punch cards).
A historical review of EJB, it's motivations and its challenges, may justify
many of EJB features. It is targeted towards a very broad spectrum of uses;
many of its features may not have been thought for your *current* situation,
but for the worst of the situations (which, if you succeed in business, will
eventually have to face). I'm sure more illustrated members of the list,
like Mr. Wolf, Mr. Marinescu or Mr. Monson-Haefel can point out these
historical sources, so I'll leave them the explanation.
My 2c,
JP
-----Original Message-----
From: Ben Strulo [mailto:[EMAIL PROTECTED]]
Sent: Jueves, 18 de Enero de 2001 10:18
To: [EMAIL PROTECTED]
Subject: Re: Why use entity beans?
Hi Richard
Thanks for your helpful post. However can I request even more clarification?
You say:
[snip lots of good stuff including description of smart keys on the
client]
> Doesn't the above code look much better? Of course we had to build an
> entire
> infrastructure of smart keys which implement the remote interface,
> maintain
> their own identity (primary key), lookup the proper stateless session, and
> delegate requests to the stateless session bean. Hmmm .... this all looks
> very
> familiar. Don't entity beans accomplish basically the same thing? They
> maintain an assocation between a remote reference used by the client and a
> primary key. Of course they do it automatically on the sever and hide the
> details from the developer. If we had just used entity beans in the first
> place, we would have obtained exactly the same benefits with at least the
> same
> performance if not better.
>
However, it is not clear to me that these two solutions [smartkeys vs entity
beans] are really comparable from a performance point of view. In the smart
key case the references are held on the client. Thus the storage demand on
the server is constant as the number of clients increases. In the entity
bean case the server is maintaining some kind of entity-bean instance table
(mapping references) and this will use storage linear in the number of
concurrent clients and hence damage scalability (certainly in extreme
cases). Essentially, in the smartkey case, there need not be any bottle-neck
on the server until you get to the database whereas, in the entity bean
case, there also has to be this lookup as a bottle-neck.
Under what circumstances can the entity bean model outperform the smartkeys?
The scope for optimisations within the server seems to be quite restricted
by the EJB semantics. (However I'm probably missing some obvious point...)
Ben Strulo
===========================================================================
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".
