[NTLUG:Discuss] Transport tool - opinions

Tue Mar 25 03:02:53 CST 2003

Hi Stephen/Greg,

   Java dosen't deliver mission critical performance. It is okay for Web Based applications. But when you are talking about parallel computing over several machines, forget Java. Thats the only thing I can say.

Harshal

-----Original Message-----
From: Stephen Davidson [mailto:gorky at freenet.carleton.ca]
Sent: Monday, March 24, 2003 9:23 PM
To: NTLUG Discussion List
Subject: Re: [NTLUG:Discuss] Transport tool - opinions

Greg Edwards wrote:
> I'm working on a project where I want to do concurrent processing over a 
> server farm.  I'm looking to do concurrency literally down to the 
> function level (using C) by passing the processing duties off to the 
> most responsive server available.  I've mentioned this idea here before.
> 
> What I'm looking for are experiences and opinions about the current 
> tools available for Linux to do the data passing between systems.  I'm 
> not looking to reinvent the wheel but I need to have something that is 
> fast and will not require jumping through a whole bunch of hoops to 
> code.  The application needs to be the focus, not the transport tools.
> 
> Currently I'm leaning toward either RPC or Corba.  I would like to use 
> off the shelf solutions for the data passing if possible.  If the 
> current solutions prove to be lacking in performance I can go back and 
> resolve that later.
> 
> I've looked at PVM and MPI but as with most high speed processing 
> solutions the models are parallel and clusters.  I need more of a 
> touring machine solution where the processing duties can start on box A, 
> get passed to whomever is available, and eventually return to the 
> originating function on box A when complete.
> 
> The concept of doing concurrency across a bank of computers does not 
> seem to have made any headway in the last 15 years.  Threads provided a 
> major breakthrough but I don't know of any extensions that take threads 
> beyond on a single box.  But, then again I may have missed something in 
> this area of R&D.
> 
Hi Greg.

In JavaLand, this is generally done using "Stateless Session EJBs", or SLSBs for short.  EJB (Enterprise Java Bean) communication is generallyh done over RMI-IIOP, and is now very quick.  I have had 
calls start at a client layer, lookup up an SLSB in a JNDI tree(JavaNamingDirectoryInterface, often implemented using LDAP), go through an SLSB to an Entity EJB (with its additional overhead) lookup 
some data out a HastTable, serialize the result and return it, in under 20ms.  Java has been doing this for several years, now.  This particular technology, as well as several related technologies, 
are part of the J2EE, or Java2 Enterprise Edition, Java package.  There are a variety of Java Technologies that can do this, with varying degress of complexity, sophistication, and intelligence.  We 
have the ability to include loadbalancing, failover, redundancy, as well as other assorted features.  And for convenience, if you already have code written on a specific platform, we can call it 
directly as well,  so long as there is a Java Virtual Machine for the platform in question.

Some of the more well known packages that implement this technology are JBoss, BEA's Weblogic, IBM's WebSphere, Sun's iPlanet.  This list is actually much longer, and I did not include messaging 
servers in this sample.

For more details, check out http://java.sun.com

If you have more questions, feel free to email me, on or off list.

-Steve

-- 
Java/J2EE Developer/Integrator
214-724-7741
Looking for a new job opportunity.

_______________________________________________
https://ntlug.org/mailman/listinfo/discuss
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: InterScan_Disclaimer.txt
Url: http://ntlug.org/pipermail/discuss/attachments/20030325/2443a453/InterScan_Disclaimer.txt