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

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

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: Tony Skjellum <[email-masked]>
Date: Wed, 29 Jul 1998 10:51:58 -0500 (CDT)

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)*

---

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