Subject: Re: RMI Announcement from www.javasoft.com

From: George Crawford <[email-masked]>
Date: Wed, 29 Jul 1998 11:04:20 -0500 (CDT)

I'd also like to mention that we have designed a preliminary
object-oriented MPI framework for Java (called JMPI) that can serve as a
basis for further discussion. Our design philosophy was to restructure
MPI for Java (eliminate unessential functionality, redundancies,
etc.); we did not try to include all of MPI in Java (an effort which
often tends to result in a convoluted Java interface). 

->George

On Wed, 29 Jul 1998, Tony Skjellum wrote:

> Dennis, George : we are interested in helping with or leading the 
> effort to specify an MPI-type interface for Java.  George Crawford
> may not be able to make the next meeting, but that is not an indication
> of interest level, just combination of family emergencies between him
> and me.  We are trying to identify an alternative attendee who can
> hopefully participate in the discussion of MPI-type programming API
> and specification for Java.
> 
> I want to say that I strongly encourage that we not try to be precise
> to MPI, but do what is write for Java.
> 
> Tony
> 
> 
> Anthony Skjellum, PhD, President ([email-masked]) 
> MPI Software Technology, Inc., Ste 201, 1 Research Blvd., Starkville, MS 39759
> +1-(601)320-4300; FAX: +1-(601)320-4301; http://www.mpi-softtech.com
> *The source for MPI, MPI-2, MPI/RT, Embedded & High Performance Middleware(tm)*
> 
> 
> On Wed, 29 Jul 1998, George K. Thiruvathukal wrote:
> 
> > Dennis/Tony:
> > 
> > Yes, I tend to agree the two concerns are completely separate but somewhat
> > related (peripherally) when it comes to RMI and MPI. I also think your idea
> > of MPI being done by an RFP is a proper course of action. There seem to be
> > many opportunities for MPI work:
> >     - bindings only
> >     - an object-oriented MPI (intended for Java-to-Java MPI)
> >     - MPI-2 issues
> > 
> > Regarding RMI, I am not sure how well our mailing list is working, because I
> > had posted some information about the forthcoming improvements to RMI. Two
> > of the major issues I raised in my paper at Java '98 appear to be well on
> > their way to being addressed at JavaSoft:
> >     - a "registry service provider" to allow interfaces to open directory
> > services (a la LDAP)
> >     - abstract transports (which you mentioned re: "socket factories")
> > 
> > One of the lone outstanding issues from the paper has not been addressed,
> > which is the clumsiness of RMI's object model. This continues to be an issue
> > open for discussion, although I think there is agreement in the forum among
> > those who have used RMI that it is, indeed, a real issue. Even in the
> > presence of IIOP, I contend it remains an issue.
> > 
> > All said, I agree with Dennis that the RMI effort is not getting smaller,
> > and this has the potential to push the development effort (now at two
> > companies) to the breaking point. Additionally, I am somewhat skeptical
> > about the prospects for RMI being able to support high-performance computing
> > adequately, but I am reasonably certain this is not the intended focus of
> > the RMI design anyway. (I'm not sure I want to go into all of the reasons
> > now, but I will hint that layering of protocols and the use of abstract
> > factories poses key performance issues. Perhaps lightweight classes could
> > help fix some problems here in addition to the use we've already identified
> > for numerics handling.)
> > 
> > Another key issue for RMI discussion, I believe, is the openness of the
> > implementation. One of the key reasons my research group has undertaken the
> > effort to build a version of RMI that does not depend on the JDK from
> > JavaSoft is to FULLY support the spirit of RMI on alternative VM
> > implementations, in particular that of Microsoft. From a business
> > perspective, it is going to be increasingly important that RMI support the
> > MS platform, even in the scientific and engineering community, where Windows
> > NT machines are multiplying like rabbits.
> > 
> > As an aside, Microsoft recently released the SDK 3.0 for Java. It does not
> > include RMI, as expected. We really need to be concerned about this. (We =
> > the forum, Sun, and others who support Java.)
> > 
> > Well, from the sound of it, I think we'll have an invigorating discussion at
> > the next JGF meeting. Thanks to both of you for your excellent words.
> > 
> > George
> > 
> > 
> > 
> > -----Original Message-----
> > From: Dennis Gannon <[email-masked]>
> > To: George K. Thiruvathukal <[email-masked]>
> > Cc: Tony Skjellum <[email-masked]>; [email-masked]
> > <[email-masked]>; [email-masked]
> > <[email-masked]>
> > Date: Wednesday, July 29, 1998 5:59 AM
> > Subject: RE: RMI Announcement from www.javasoft.com
> > 
> > 
> > >Hi George and Tony;
> > >
> > >glad to hear this discusssion getting started.  two big things
> > >seem to be on the table:  rmi improvements and MPI for java.
> > >first for RMI.
> > >
> > >we need to come to some collective agreement about what we want
> > >to propose to sun et.al. about RMI.  there have been changes
> > >and i think Michael may be writing something for us to consider.
> > >in the new 1.2 versions RMI does now support a socket factory
> > >interface.  this certainly does not imply tcp or even udp for that
> > >matter.  it only implies a reliable stream.  it can even be
> > >multi-cast.  however, it is hard to cast all communication into
> > >byte streams.  Nexus doesn't fit this, nor do active messages, pm
> > >or fm, etc.  Also, one of the biggest performance problems lies
> > >with serialization which is a seperate issue.  we have been looking
> > >at ways to design a seperate serialization interface to RMI.
> > >modulo the problem with serialization of some system classes, it
> > >can be done.  that way we can provide specialized, custom serialization.
> > >the idea needs more work, but it may be an approach to consider.
> > >
> > >also, i fear that the sun-ibm iiop agreement is going to put
> > >lots of stress on the already-over-stressed rmi implementors.
> > >i like it, but there are some technical problems that have to
> > >be solved.  for example, iiop is really a serialization protocol
> > >for corba rmi.  the transport is tcp.  so should we think of
> > >iiop as a custom serialization?  or as part of a special stream socket?
> > >(opinions welcome!)  how do we seperate the concept of
> > >serialization from transport?
> > >
> > >re: MPI.  I think it may be a good idea for Java Grande to
> > >issue an "RFP" for a java binding for MPI.  This is clearly orthogonal
> > >to the RMI issues.  And it is one where we can define an API
> > >that will not conflict with anything else.  this issue came up
> > >at the last meeting, but we didn't follow up on it.
> > >
> > >In addition to tony's list there are some other items for
> > >us to consider for a java MPI.  for example should java serialization
> > >replace the MPI explicit serialization for data structures?
> > >should it be extended? How do you do it in a true object oriented,
> > >multithreaded model? (for example, MPI-2 onesided comm. is
> > >not very natural in java?  or is it?) i guess
> > >there are a lot of technical
> > >issues we need to sort out!
> > >
> > >I hope you are all going to be at the meeting in Aug!
> > >regards,
> > >dennis
> > >
> > >
> > >
> > 
> > 
> 
>

---

From: "George K. Thiruvathukal" <[email-masked]>
Date: Wed, 29 Jul 1998 09:06:19 -0500

Dennis/Tony:

George

---

From: Tony Skjellum <[email-masked]>
Date: Wed, 29 Jul 1998 10:51:58 -0500 (CDT)

Tony

---

From: George Crawford <[email-masked]>
Date: Wed, 29 Jul 1998 11:04:20 -0500 (CDT)

->George