Concurrency, was Re: Doh! Stupid Programming Mistakes <humor>

Bryan Sant bryan.sant at
Fri Oct 27 14:10:10 MDT 2006

On 10/27/06, Levi Pearson <levi at> wrote:
> So there are really two levels of concurrency going on; there's node-
> local concurrency based on multi-core processors and multiple CPUs
> that have shared memory, and then there's the layer that connects
> many of those systems together with a message-passing model over a
> high-speed network.  There are two advantages to this: It takes
> advantage of the price/performance sweet spot of commodity hardware,
> and it logically separates near-calls from far-calls.  I'm not
> familiar enough with shared-memory supercomputers to know how they
> handled the latter issue, but they handled the first by being really,
> really expensive. :)
>                 --Levi

This is what J2EE set out to solve for the masses.  With the original
J2EE systems, things were complex, but the hope was to encapsulate a
uniform way to work with local and remote objects (among other
things).  I've always found this to be a worthy and interesting goal.
Enterprise Java Beans (EJBs) could be configured as a local or remote
resource, and their role could be easily switched.  Remote
communication could be done with a messaging protocol (which would
work similar to MPI), or with RMI (actually RMI-IIOP, which is
actually CORBA).

The new JEE 1.5 specification has really simplified things compared to
prior J2EE complexity evilness.  You just add one-liner annotations to
your plain-jane objects, which gives your JEE container clues about
what services you want that object surrounded with.

Whether you like or hate the implementation specifics of JEE, I still
think the concept is cool.  Distributed computing is neato.


More information about the PLUG mailing list