But Atong's point is well-taken; the iPlanet implementation wasn't Sun's
until the Sun/Netscape merger, and even before that Sun had ZERO
implementation, not even the reference impl.
Atong also raises a really good point later, as well--there's no real
indication
of how much "eating your own dog food" Sun is doing; we know that Oracle and
MS both use their own products internally (believe it or not, in the case of
MS, but I can verify this personally), and that sort of usage tends to give
one an added impetus to get the product right before release.
Ted Neward
{.NET || Java} Course Author & Instructor, DevelopMentor
(http://www.develop.com)
http://www.javageeks.com/tneward
----- Original Message -----
From: "Kevin Gaasch" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 15, 2002 10:26 AM
Subject: Re: [EJB-INT] As a Person Looking into EJB...
> I believe that Sun's production implementation is provided by iPlanet, the
> Sun-Netscape Alliance.
>
> Kevin E. Gaasch
> Enterprise Java Consultant
> Sun Certified Java Programmer
> Canyon, Texas
> Work: (806) 324-4100 x4215
> Cell: (806) 674-1523
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Atong Appa
> Sent: Tuesday, January 15, 2002 11:27 AM
> To: [EMAIL PROTECTED]
> Subject: Re: As a Person Looking into EJB...
>
> Thomas:
>
>
> >From: Thomas Groot <[EMAIL PROTECTED]>
> >Reply-To: Thomas Groot <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Re: As a Person Looking into EJB...
> >Date: Tue, 15 Jan 2002 08:44:16 -0800
> >
> >Interesting example. You're striking a compromise
> >between a small-object hierarchy (good OO design, from
> >a purist's perspective) and better performance.
> >You're considering the database layer's performance in
> >the design of your object model.
> >
> >This gets to the heart of EJB's value. EJB (and CMP
> >in particular) is an abstracting technology that takes
> >you out of the details of managing (and persisting)
> >your objects at runtime. You are free to align your
> >object model with your business logic, blissfully
> >ignorant of performance at runtime. Performance is
> >tuned at runtime, after the beans are deployed, in a
> >very similar way to an RDBMS. This is a very
> >attractive idea in many corporate IT settings.
> >
> >That's the theory, anyway. Both the spec and the
> >vendors add lots of features designed to give you more
> >control over performance *that gets built into the
> >beans*, which violates the underlying philosophy. But
> >we've been violating encapsulation since the early
> >days of OO, so why stop now? ;-)
> >
> >If you are comfortable ignoring most performance
> >issues in your business logic, EJB will support you in
> >that. You can build clean, readable, maintainable
> >object hierarchies, and let the app server worry about
> >performance. If you want to tweak and tune things, you
> >will find your hands tied in important ways with J2EE,
> >or you'll have to make the sorts of compromises you
> >discuss. But that's not uncommon in software projects
> >today, is it?
> >
>
> In my experience, performance and scalability considerations must be
> designed in at the early stage of the project. Runtime performance tuning
> and tuning after-the-fact have given only small gains in performance.
>
> If you look back at SQL, it sheds some light on this issue. When SQL was
> first developed at IBM, they wanted to stay pure. They claimed:
Everything
> should be a tuple. How data is retrieved and updated should never creep
> into the application. In fact, the early theory of relational model says
> that even indices should never be manually created by the user.
>
> When people did actual development against this, they soon found out this
> wasn't acceptable. Indices came in, access plan management came in,
> optimzers came in, optimizer hints came, etc. It is true small and simple
> apps could ignore all these, but enterprise-level apps must deal with
these
> optimization and tuning issue all the time. With the name like EJB (and
as
> 'E' stands for enterprise), EJB must address these scalability and
> performance issues for large scale apps.
>
> Hence, if indeed EJB's main focus is abstraction without little regards
for
> performance and scalability, I would be quite concerned (many
> implementations of Lisp failed for that reason, I think). It seems to me
> that they have given some considerations about scalability and
performance:
> stateless session beans, local entity beans in EJB 2.0.
>
> Two problems: EJB is learning these things as we speak. Last year, they
> introduced "design-patterns" to address some of these issue, but no
standard
> and no standard implementation yet of these patterns. So they are left to
> vendors to their own thing, which will cause problems later. I guess the
> bottom line is that EJB has some (if not a lot) maturing to do. When will
> it be mature enough for prime-time? Some would argue it is now. To me,
it
> feels it is's not quite ready yet.
>
> Second, at least to me, EJB seems very lax and cavalier about RDBMS level
> tuning. I was surprised to see them introduce all-encompassing and
> abstracting EQL which is supposed to perform abstract-SQL to concrete-SQL
> mapping. This is a big red flag for me. This not only shows that the
> designers of EJB may not have a good understanding of the amount of
> time/resources people spend to tune their databases for large apps, but
also
> that they decide to tie people's hands. I understand that the first draft
> of EQL didn't even have a provision for sorting the results. That seems
> pretty amazing.
>
>
> This industry is strewn with 'proposed standards' that grew up to be real
> standards (only a few) and those that died a painful death (many). SQL,
> Java, and PC architecutre belong to the first group. OpenDoc, CORBA,
OLE2,
> a lot of stuff out of OMG belong to the second.
>
> My main focus at the moment is trying to figure out whether EJB will be in
> the first or the second group 2 or 3 years down the road.
>
> If you look at successful standards, it seems to me that a strong
> implementation implemented by the leader of the standard that turns
> technology into a real solution for a real problem is a real plus. This
> gives the leader a chance to work with the standard firsthand and address
> problems quickly. It concerns me that while JavaSoft is defining EJB,
> implementations are coming from WebLogic, IBM, and open-source JBoss.
>
> Why isn't JavaSoft producing a credible and practical implementation of
this
> standard? If it is so good, shouldn't they be the first to implement and
> use it? I heard some noise some while ago about a "reference
> implementation" of EJB coming from JavaSoft, but haven't heard any more
> about it (they must do a real implementation, not just a reference ==
> example). After all, I hear that everyone at MS uses the latest version
of
> their OS, and Oracle uses their own ERP apps.
>
>
> Atong
>
>
> _________________________________________________________________
> Chat with friends online, try MSN Messenger: http://messenger.msn.com
>
>
===========================================================================
> 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".
