Hey
Ashwath Narayan wrote:
> This has been a very interesting and important thread. We are missing you.
> Can we have your views?
Sorry for not participating. I've been out of town and have been
generally busy.
Mostly I don't take Arkins arguments that seriously because he cares
about one thing only: performance. And his rhethoric is similar to the
age-old "if I do it in assembler it will work much faster". In one sense
he is correct; going to JDBC will produce faster results in some
scenarios, however, using EntityBeans may be much faster in some cases
since one can use caching heavily. Look at Javlin. Look at TOPLink. They
perform very optimized database access, and it is all transparent to the
bean developer if one uses EntityBeans. In almost all computing the best
software is based on the restrictions that are imposed. If you say "hey,
here's a technology that let's you do anything" I usually think "wow,
yet another programming language..great..". Once you start imposing
restrictions it lets you do optimizations, because the whole philosophy
of optimization relies on the ability to make restrictions in what can
be done. This applies on EntityBeans as well as other technologies. Now,
since we have imposed some restrictions by using EntityBeans we may not
be able to solve all scenarios, but we will be able to solve many of
them quite well. And it also depends heavily on how clever your
particular implementation is.
Last week I attended the BEA Users Conference. Interesting stuff for
many reasons, but two issues that kept coming back when I talked to
different companies was: "we need more people" and "we need to go live
tomorrow" (aka "we need to lower our time to market"). The first point
is very important for the whole Java thing in general: not enough people
know it. It is growing by the day, but not in the same rate as the need
for expert programmers. Hence, we need to lower the need of knowledge
required to program in Java. Using EntityBeans is one way to do that, as
they are much easier to use than going through JDBC all the time.
The second point is also met by using EntityBeans. Two weeks ago I was
in a programming contest (reusecafe.hk-r.se) in which we had 24 hours to
implement a call-center application. We (3 people) were finished after
21 hours. All database access was made through EntityBeans using CMP,
and the tables and finders were created automatically for us. We didn't
write one line of JDBC code, which was crucial, since JDBC code is
inherently buggy. So, in 21 hours we had created a J2EE app (running on
OrionServer) with EntityBeans accessing a SQL-database (Hypersonic SQL)
that had both a Swing GUI for the operators, and a JSP interface for
statistical operations (the whole thing is downloadable from
http://www.dreambean.com/download/final.zip). The standard
anti-EntityBean argument "well, what if you do a finder that returns
10.000 Entities" did not apply since we would never want to list that
many incoming messages in the GUI. It would be silly from a GUI point of
view. During the demo it all worked quite well and it never crashed.
Ah, and here's a killer. What do you need most: performance or uptime?
Ask any online e-business and they would reply "both!", but in the end
it is uptime that counts. Performance can always be addressed by
clustering. And how do you get good up-time?
1) Don't write code. nr of bugs rises linearly (exponentially?) with nr
of lines. KISS. Always.
2) If you have to code, don't write complex code, as it tends to be more
buggy.
JDBC coding breaks both 1 and 2. Which breaks uptime, no matter how many
cluster-nodes you have: they will all break on buggy code.
And that's all I have to say on this issue. Notice the lack of technical
arguments. It is surely possible to argue in all eternity about this
issue based on technical arguments alone, but once you try to see the
whole picture it becomes much easier to do the right thing.
IMHO of course.
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.dreambean.com
Question reality
===========================================================================
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".
