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".
