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)" 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. 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. In addtion, RMI has its own problems, which cause serious development headaches (read: versioning). Rob
