On 10/27/06, Levi Pearson <[EMAIL PROTECTED]> 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. -Bryan /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
