Hi Assaf
Tip 1: Care about your craft
Why spend your life developing software unless you care about doing it well?
Tip 2: Think! About your work
Turn off the autopilot and take control. Constantly critique and appraise
your work
Tip 9: Crtically analyse what you read and hear
Don't be swayed by vendors, media hype, or dogma. Analyse information in
terms of you and your project
My View: Some of the advice being given on this list is reflective of the
failings of current offerings from vendors who penetrated this market early
and which will be hampered by their existing architecture to secure any
future. The future success of application server vendors depends on them
adopting a more mature foundation i.e. CORBA than there current RMI
implementations. This biased advice can be clearly seen in discussion
regarding Session Beans versus Entity Beans and Large Grain and Fine Grain.
Tip 11: DRY - Don't Repeat Yourself
Every piece of knowledge must have a single unambiguous authoritative
representation wihtin a system.
The 10% overhead is form test we have conducted comparing Session Beans +
SQL versus Session Beans versus Entity Beans. I can well believe that you
might not believe these figures since nothing out there comes close to IAS
4.0.
Now regarding your lean and mean machine....I cannot see how your JDBC and
SQL code repeated both in a session bean and entity bean is lean and mean. I
think I can turn out an application quicker by just using CMP and not
writing any JDBC calls, not writing any SQL and not duplicating this effort
in 2 places. With this I also get tuned writes giving me great performance
while still keeping my code clean and to the point ... business stuff. Now I
am an advocate of refactoring but I try to only refactor things which I
could not have seen at the time. I try not to create refactoring work for
myself, this just seems pure laziness. This brings me ontop my favourite tip
and one which I have been praticising since the start of my career:
Tip 38: Put abstraction in code, details in metadata
Program for the general case, and put the specifics outisde the compiled
code base.
I am abit taken back by your response since I have valued your other
contributions to this list. But I suspose we cannot always agree on some
points, this being one.
Kind regards
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.
> -----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".
