On Sun, 2002-02-24 at 19:07, Rob Nagler wrote: > Gunther Birznieks writes: > > How much slower is EJB then than RMI? We use RMI fairly regularly and it > > seems relatively fast. I would have thought most of the beans put into an > > EJB server are basically just RMI-like RPC calls. > > RMI (or RPC in general) isn't the problem. The following quote from > http://www.mail-archive.com/general@jakarta.apache.org/msg03773.html > sums it up nicely: > > "EJBs are for newbies. (If you need middleware (very rare) use SOAP)"
I agree with this if the only thing you're using EJB for is web applications (as the email discusses). But if you're doing web applications and Swing applications and providing an interface for existing apps to a legacy datastore and (...), then using SOAP by itself doesn't make a whole lot of sense. (And doesn't burn up the speed charts, either.) Relegating a whole section of the development community -- many of whom are really smart and actually know what they're doing in the Real World -- with something like this seems needlessly inflammatory to me. > The system I was involved with took the naive approach of mapping > entity beans to database rows. The architect bought into EJBs as a > transparent access mechanism to the DB. This is plain wrong. > *Every* system I have heard of which used entity beans was dog slow. It can be if you use it in this manner. The specification doesn't provide a whole lot of guidance with the granularity entity beans should be. Of course not -- otherwise they'd have nothing to write about in the endless J2EE patterns and J2EE implementation books! :-) But if you create beans that map to more than one table to form a logical business unit many of the speed issues go away. And you're left with a distributed, caching, serialization scheme for objects that is portable from one application sever to another, from one database to another, from one operating system to another -- that seems pretty useful to me. Even if you have to navigate some tricky shoals to achieve the portability, even if you wander down way too many blind alleys. That said, most of the time I think the pain that comes with EJB development is not worth the benefits you get. Of course, Sun and the J2EE lobby won't mention this... People who use them for web-only applications of a standard size are making their lives needlessly complicated. (But this is also true of most database systems -- how many apps *really* need Oracle?) > If you want to use J2EE as a transaction container, you'll do fine. > However, the question is: Why use an immature protocol and > implementation for a concept which has been around for 30+ years? > Moreover, you're pretty much locked into writing all your code in > Java. There are much more efficient and mature transaction containers > than WebLogic, WebSphere, etc. For example, the combination on > Apache/mod_perl/DBI/Oracle is incredibly hard to beat by any measure. Umm.. so you'll be locked into writing all your code in Perl? While I think writing all such code in Perl would actually be a good thing, bringing up the "it's only Java" argument is a straw man, particularly since CORBA is standard in J2EE application servers. > In addtion, RMI has its own problems, which cause serious development > headaches (read: versioning). This depends on how you're deploying, IMO. Java has some pretty nifty tricks you can play with classloaders and grabbing the right versioned classes from over the network. (IIRC, there was a Java-in-POS-terminal article on the ORA Java site a few months ago that touched on this... ah: http://www.onjava.com/pub/a/onjava/2001/09/20/javapos.html) RMI certainly comes with a brand new set of headaches, though. And again, most of the time the tradeoffs aren't worth it. Just another opinion... Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
