> William
>
> PS: I am not advocating that we should try to use entity beans always for
> example in some major overnight batching operation would not be ideal, but I
> do feel we should really give it more thought than is currently happening.
> Also regarding performance tuning I believe that we should put less weight
> on the coding part and more on the design. To me the coding part is the
> icing on the cake but you first have to get the layering and structure
> correct.
If you ask me what's wrong with EJB (and I'm very bullish about EJB and
tend to design applications based on it), two of the points that come to
mind are:
* The use of serialization all over the place and the decision to do
RMI-IIOP and not IIOP (and farewell to RMI)
* The confusion between entity beans (one of the best designs I've seen
in years) and object persistence
The first one is a Sun design decision that we have to live with. And
sadly (I didn't make that design choice), code around it. If I was asked
what is the first thing I would change in EJB, that would probably be
it. That would allow me to use EJB in more places.
The second one is more of a developer shortsightness. Developers learn
entity beans, find a way to get object persistence, and start using it
all over the place. We both know it doesn't make sense in some cases,
but still they use it, since there's no other API that is widely
available.
The entity bean API is just not cut out for that. Sun says it, several
of the vendors here say it, and they know it because they wrote the
implementation.
Once the JDO comes to life, giving you most of what entity beans does +
fine grain objects - RMI-IIOP overhead, that perception will change.
Hopefully JDO will use the same semantics as CMP so you can reuse your
objects/tables.
arkin
>
> > -----Original Message-----
> > From: Assaf Arkin [SMTP:[EMAIL PROTECTED]]
> > Sent: Wednesday, March 01, 2000 2:01 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: When to Use EJB? (was: Session EJBs vs. JavaObjects)
> >
> > The first rule in the pragmatic progammer book is get the damn thing
> > working as best as it can.
> >
> > Reusing code is one way to do it, you get less bugs, easier
> > maintainability, etc.
> >
> > But at the same time, code reuse tends to conflict with performance
> > issues.
> >
> > The J2EE model is filled with such contradictions. Entity beans are
> > simply not optimized compared to what JDBC can offer in terms of
> > performance, especially when it comes down to the GUI side doning a lot
> > of queries, with only so much updates.
> >
> > And no, the overhead is not 10%. 10% is the overhead of entity beans on
> > top of JDBC if you wrote the same code using JDBC. But you won't, with
> > JDBC you will write different code which is leaner and meaner, so the
> > overhead is substantially larger.
> >
> > Also, if you cut the EJB server altogether and go directly to JDBC, the
> > difference is not 10%.
> >
> > arkin
> >
> >
> >
> > "Louth, William (Exchange)" wrote:
> > >
> > > So what your proposing is that we embed the database structure in 2
> > places.
> > > One in the servlet or servlet/session bean and the other in the entity
> > bean
> > > persistence descriptor. Is there not some rule in the Pragmatic
> > Programmer
> > > book about not duplicating such things. I have not got the book with me
> > at
> > > the moment but I am sure its there anyway let common sense prevail for
> > the
> > > time being.
> > >
> > > I have already posted a summary of a report which showed that using IAS
> > 4.0
> > > that the overhead of using session bean talking to CMP entity beans
> > (large
> > > collection) was small, less than 10%. I can trade that 10% against
> > future
> > > maintenance and the all rest that comes with this approach. But I
> > suspose If
> > > you are not using IAS 4.0 you better start writing SQL considering that
> > > using this method with other servers resulted in a 1800% overhead.
> > >
> > > William Louth
> > >
> > > > -----Original Message-----
> > > > From: Richard Monson-Haefel [SMTP:[EMAIL PROTECTED]]
> > > > Sent: Sunday, February 27, 2000 12:56 PM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Re: When to Use EJB? (was: Session EJBs vs. Java
> > Objects)
> > > >
> > > > Doug has hit the nail on the head. EJB is appropriate for high volume
> > > > transactional sites like an electronic trading site, but for sites
> > that
> > > > provide
> > > > read-only access to product catalogs or primarly textual material
> > > > (documents,
> > > > articles, etc..) with no transactional requirements, Servlets and JSP
> > is a
> > > > better option. You should use EJB to handle purchases and
> > transactions on
> > > > these
> > > > types of sites, but not for perusing the content.
> > > >
> > > > --
> > > > Author of Enterprise JavaBeans
> > > > Published by O'Reilly & Associates
> > > > http://www.EjbNow.com
> > > >
> > > > EJB FAQ
> > > > http://www.jguru.com/faq/EJB
> > > >
> > > >
> > > > "Bechtold, Douglas" wrote:
> > > >
> > > > > I hate to speak for Richard, but I think his point is that for
> > read-only
> > > > > queries that are basically transaction-free that EJB is perhaps more
> > > > > overhead than is needed. I am working on exactly such a system
> > where we
> > > > are
> > > > > considering using Servlets for queries that are for read-only
> > purposes
> > > > and
> > > > > EJB for updates. If the query is for reading / writing, then the
> > > > "overhead"
> > > > > that EJB comes with is not an issue because of all of the other
> > benefits
> > > > > that come with EJB.
> > > > >
> > > > > DB
> > > > >
> > > > > -----Original Message-----
> > > > > From: Frank D. Greco [mailto:[EMAIL PROTECTED]]
> > > > > Sent: Thursday, February 24, 2000 9:26 AM
> > > > > To: [EMAIL PROTECTED]
> > > > > Subject: When to Use EJB? (was: Session EJBs vs. Java Objects)
> > > > >
> > > > > >Ahi Satapathy wrote:
> > > > > >> So when EJB should be used ? what should be the factor one
> > should
> > > > > consider
> > > > > >> before going to implement something with EJB ? If the site is
> > not
> > > > > >> transactional, has no authorization security needs, and is read
> > > > only,
> > > > > should
> > > > > >> one go for simple Java Objects and use Servlets with direct JDBC
> > > > access
> > > > > ??
> > > > >
> > > > > At 05:13 PM 2/20/00 -0600, Richard Monson-Haefel wrote:
> > > > > >In a word, "maybe". You need an experienced architect (consult
> > your
> > > > > >physician) to review your system and make a recommendation. Most
> > > > > >high volume sites (Amazon, eToys, et.) that have a lot of read
> > only
> > > > >
> > > > > High volume as in number of concurrent visitors or number of
> > > > > transactions? Or high volume as in page throughput or http
> > (or
> > > > > socket) throughput?
> > > > >
> > > > > >navigation and no transaction needs for the reads, should be
> > > > implemented
> > > > > >with something other then EJB - I like servlets. BUT, the
> > purchasing
> > > > >
> > > > > Theoretically EJB can be used for high-volume sites like an
> > > > > electronic
> > > > > trading system. Architecturally, as part of an App Server
> > > > product,
> > > > > EJB
> > > > > should not be fundamentally slower than
> > > > Servlet/JDBC/JavaClasses.
> > > > > The
> > > > > vendor app server product should be able to scale much
> > better
> > > > than a
> > > > > home-grown solution. If the home-grown solution is
> > superior...
> > > > then
> > > > > I
> > > > > want to get in on the IPO... ;)
> > > > >
> > > > > >of goods and services on these sites should be implemented with
> > EJB
> > > > via
> > > > > Servlets.
> > > > >
> > > > > Actually, are there 'rules of the road' for this stuff?
> > What
> > > > are
> > > > > the
> > > > > heuristics for choosing a AppServer/EJB(et al) over a
> > > > > WebServer/Servlets?
> > > > >
> > > > > Frank G.
> > > > >
> > +======================================================================+
> > > > > | Crossroads Technologies Inc, 55 Broad Street, 28th Fl, NYC, NY
> > 10004 |
> > > > > | Dot-com Engineering
> > |
> > > > > | Email: [EMAIL PROTECTED] Web:
> > www.CrossroadsTech.com |
> > > > > | Voice: 212-482-5280 x229 Fax: 212-482-5281
> > |
> > > > >
> > +======================================================================+
> > > > >
> > > > >
> > > >
> > ==========================================================================
> > > > =
> > > > > 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".
> > > >
> > > >
> > ==========================================================================
> > > > =
> > > > 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".
> > >
> > > ***********************************************************************
> > > Bear Stearns is not responsible for any recommendation, solicitation,
> > > offer or agreement or any information about any transaction, customer
> > > account or account activity contained in this communication.
> > > ***********************************************************************
> > >
> > >
> > ==========================================================================
> > =
> > > 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".
> >
> > --
> > ----------------------------------------------------------------------
> > Assaf Arkin www.exoffice.com
> > CTO, Exoffice Technologies, Inc. www.exolab.org
> >
> > ==========================================================================
> > =
> > 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".
>
> ***********************************************************************
> Bear Stearns is not responsible for any recommendation, solicitation,
> offer or agreement or any information about any transaction, customer
> account or account activity contained in this communication.
> ***********************************************************************
>
> ===========================================================================
> 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".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
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".
