Subject: RMI Announcement from www.javasoft.com

From: "George K. Thiruvathukal" <[email-masked]>
Date: Wed, 8 Jul 1998 17:30:53 -0500

Hello Everyone:

It never seemed like a question of "if" but rather of "when". The
following URL discusses how JavaSoft and IBM (Hursley) are teaming up to
develop a version of RMI that uses IIOP.
	http://www.javasoft.com/pr/1998/07/pr980708.html

The article does make it clear that Sun is planning ton continue their
work on the RMI protocol, JRMP, but it also mentions that the
CORBA-enabled RMI will appear as an update to JDK 1.1.6 and the
long-anticipated JDK 1.2.

For enterprise computing, I am certain this will be met with applause. For
high-performance computing... (?) Sockets, anyone? :)

Enjoy,
George

************************************************************************
George K. Thiruvathukal, Ph.D.      * Illinois Institute of Technology
Lecturer                            * Unix/C/C++/Java Certificate Program
URL: http://www.jhpc.org/george     * c/o Institute of Design
Tele: 312.595.2210                  * Chicago, IL 60610-4726
************************************************************************
Principal, Tools of Computing LLC, http://toc-press.com
Director, Java and High Performance Computing Research, http://jhpc.org

---

From: "George K. Thiruvathukal" <[email-masked]>
Date: Wed, 29 Jul 1998 12:24:51 -0500

Hi George,

First, I am sorry to hear about the family emergencies. We are grateful for
your participation under these circumstances.

I seem to recall discussing JMPI with you at a previous meeting and think
this work could be very interesting to the JGF.

At some point, it may also be worthwhile for me to discuss some of the work
going on in "my" jhpc.org research group. We support an "MPI" personality in
our ActiveJava (formerly, JavaNow) framework, which is an Actors-derived
framework that directly supports data-parallel/dataflow computing.

Just FYI, two of the sub-areas we have discussed in the working group on
applications/frameworks (chaired by Dennis Gannon) are the
"experimental/research" environments and "interfaces to existing services".
These issues will be part of an ongoing discussion in the working group.
(i.e. plans beyond SC '98, where we are making our preliminary report).
Dennis may be able to comment on this further, if necessary.

George

-----Original Message-----
From: George Crawford <[email-masked]>
To: Tony Skjellum <[email-masked]>
Cc: George K. Thiruvathukal <[email-masked]>; Dennis Gannon
<[email-masked]>; [email-masked]
<[email-masked]>; [email-masked]
<[email-masked]>
Date: Wednesday, July 29, 1998 11:19 AM
Subject: Re: RMI Announcement from www.javasoft.com

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