develooper Front page | perl.p5ee | Postings from February 2002

Re: bivio online transaction processing system

Thread Previous | Thread Next
Chris Winters
February 24, 2002 21:04
Re: bivio online transaction processing system
Message ID:
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
> 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...

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 Winters (
Building enterprise-capable snack solutions since 1988.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About