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: Tony Skjellum <[email-masked]>
Date: Mon, 27 Jul 1998 08:43:55 -0500 (CDT)

George, you have written several times that sockets is your going in
position for HPC on Java.  I guess this is to stimulate significant
debate, but no one has taken you up on that yet.  

I will encourage that debate by say that sockets (probably implying TCP/IP
and UDP) is not the way to go.  There is a significant body of interesting
group-oriented communication in theory and practice that is ignored by the
sockets interface, being strictly point-to-point and generally implying
TCP/IP or UDP/IP.  The classes of programs under "Java for CSE" still must
include data parallel programs (hence group communication), coarse-grain
data flow (hence bi-partite group communication), and combinations thereof
to make parallel client/server and generally mixtures of task, data, and
dataflow like programs. 

MPI Software Technology (which participates in JavaGrande) is interested
to see really high performance solutions available for Java programmers;
we are working on product along these lines, but standards are good too,
and we like to see community adoption for good standards grow out of
your activities with G. Fox et al.

IMHO, the HPC classes and protocols and APIs should come from the
principles that groups of cooperating Java applets/servlets/programs work
together through appropriate middleware that abstracts specific networks
and hides internet/intranet issues from a correctness perspective.  That
way, for certain applications at least, quality-of-service requirements
plus the middleware classes provide portability to different intranets,
and to internet uses. 

We would like to see this discussion continue and be part of the results
of JavaGrande.  It may be that that is beyond what Sun may have
interfaces or documents of its own to build upon, but still useful and
worthwhile, such as RPC-type discussions going on there now.

Is JavaGrande going to pursue, should some of us write something up, or
what?  What do others think about high performance + java communication?

Thanks,
Tony
PS Here is a list of some of the issues we care about
a) linkage to schedulers across the enterprise (spawning, controlling)
b) hiding which kinds of networks (IP plus...)
c) what kind of data marshalling/unmarshalling (pure data, mementos, etc)
d) what kind of descriptors for groups
e) what kind of support for group operations
f) what kind of support for fault handling
g) what kind of support for local and global QOS
h) how the classes appear to the different type of Java program entities

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, 8 Jul 1998, George K. Thiruvathukal wrote:

  [NON-Text Body part not included]

---

From: Tony Skjellum <[email-masked]>
Date: Mon, 27 Jul 1998 08:43:55 -0500 (CDT)

Thanks,
Tony

---

From: "George K. Thiruvathukal" <[email-masked]>
Date: Mon, 27 Jul 1998 15:29:27 -0500

Hi Tony:

The comment on sockets was strictly to generate debate; however, if you
check my earlier postings, I have never in any way insinuated that 'sockets'
are my 'going position in HPC for Java'. My points about 'sockets' are
strictly in the context of RMI, which in its current form is not about
high-performance computing at all. In a paper I presented at Java '98, I
present a critique of RMI from the standpoints of object-oriented and
high-performance computing, where I mentioned many of the same points you
have stated very eloquently in your e-mail.

If given a choice between the current *implementation* of RMI or sockets, I
prefer the latter when it comes to performance; however, both are more
ideally suited for client/server only. RMI does allow custom socket types,
so it may be possible for alternative transports to be used, but there is
still a general feeling among various JGF participants that RMI has a number
of key performance problems (which I will not go into here). Dennis Gannon
also presented some interesting work on RMI at Java '98, where Nexus (from
the Globus project) was used as an alternative transport for RMI to achieve
interoperability with his HPC++ effort.

The Java Grande Forum (applications working group) is addressing the issue
of frameworks and RMI (as a subset of the overall discussion). Our charter
document addresses these issues at a high level and is open for comments:
	http://www.npac.syr.edu/javagrande/jgfcharter.html

-George

----------------------------------------------------------------
 George K. Thiruvathukal
 Loyola University of Chicago
 Department of Mathematical and Computer Sciences
 http://www.math.luc.edu

 Please visit http://www.jhpc.org/george for more information.
----------------------------------------------------------------

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Tony Skjellum
> Sent: Monday, July 27, 1998 8:44 AM
> To: George K. Thiruvathukal
> Cc: [email-masked]; [email-masked]
> Subject: Re: RMI Announcement from www.javasoft.com
>
>
>

---

From: "George K. Thiruvathukal" <[email-masked]>
Date: Mon, 27 Jul 1998 15:29:27 -0500

Hi Tony:

-George

---

From: Dennis Gannon <[email-masked]>
Date: Tue, 28 Jul 1998 18:06:27 -0500 (EST)

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: Dennis Gannon <[email-masked]>
Date: Tue, 28 Jul 1998 18:06:27 -0500 (EST)

Hi George and Tony;

---

From: Vladimir Getov <[email-masked]>
Date: Wed, 29 Jul 1998 19:28:22 +0100 (BST)

Hi all,

It looks like Java+MPI is a hot topic! We've been working in this
area since beginning of 1997. The current version of our JavaMPI
binding is available at http://perun.hscs.wmin.ac.uk/CSPE/software.html
There are also several publications and a short manual. We generate 
our bindings automatically which (I think) would be particularly
useful for tuning a suitable API from Java. Another point to
mention is that we've been running JavaMPI on real parallel machines
- mainly IBM SP2, but also Fujitsu AP3000, and we've seen some
good and encouraging results. For the development work we've been
using a cluster of Sun Ultras.

As far as I know there is a very serious effort at NPAC - MPIJava
as well as JMPI from MPI-Softtech. A positive step forward at this
stage would be to develop the MPI Java language binding specification
as one of the Java Grande outputs. Perhaps this would be an interesting 
area for discussion next week as Dennis suggested in his last e-mail.

Regards,
		-Vladimir

Dr Vladimir Getov                       e-mail: [email-masked]
School of Computer Science              tel.: +44-171-9115917
University of Westminster               fax.: +44-171-9115906
Watford Rd, Northwick Park
Harrow HA1 3TP, U.K.

---

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

Vladimir, this is nice to hear about.  I would only say that I view
the goal of JavaGrande not to build a language binding, but to build
an MPI-like language library that takes advantage of Java, while
avoiding legacy issues of MPI.  A language binding might not feel
free to do so.  Our experience is that for many issues, deviation
and augmentation make sense, particular as there is a more general
execution model for Java than the process group assumption of MPI,
but much other than that too, which I hope we can all converse about
further.

-Tony

---

From: Vladimir Getov <[email-masked]>
Date: Wed, 29 Jul 1998 20:46:36 +0100 (BST)

Tony,

Good to hear from you. My understanding however is slightly different.
I hope many of us would agree that instead of starting with negative
statements (like what JavaGrande should NOT do) we could try to
identify our joint interest. In my view one such area could be the MPI
Java language binding specification. Here I am using "language binding"
as an agreed term from the MPI document, which is basically the 
specification of the API from Java. After this is done anybody could
build their own library from scratch or based on legacy code as long
as it conforms to the agreed specification. 

		-Vladimir

---

From: David Forslund <[email-masked]>
Date: Wed, 29 Jul 1998 19:38:57 -0600

Certainly other protocols that IIOP are possible within the CORBA
standard and can be negotiated through GIOP or ESIOP mechanisms.  I
think that mechanisms of incorporating MPI requirements within existing
or future CORBA services should be considered.  These would be available
to Java and to other programs, too.

There is other work in this area including iBus and the distributed
InfoBus. How well do these meet the various requirements.

-- 
David Forslund				 Voice:(505) 665-1907
Advanced Computing Laboratory		 FAX: (505) 665-4939
MS B287					 EMAIL: [email-masked]
Los Alamos National Laboratory		 WWW: http://www.acl.lanl.gov/~dwf
Los Alamos, NM 87545

---

From: Tony Skjellum <[email-masked]>
Date: Wed, 29 Jul 1998 23:07:32 -0500 (CDT)

Dave, help me out here with some of the acronyms; I don't understand all
of the letters you used.  So maybe the questions that follow are covered
in your mail.  However, how is CORBA, which targets RPC, without specific
performance requirements, able to capture high performance group oriented
communication?  I am assuming that the purpose of JavaGrande is high
performance, so CORBA doesn't come to mind directly. 

I am also not necessarily interested in seeing IP in my distributed Java
environments.  

Finally, going to CORBA (or CORBA/RT) with such requirements is unlikely
to be a successful way to get a standard augmented.  There will be little
motivation to augment a standard that already supports its own community
with performance or QOS requirements more suitable for scalable group
communication.

Tony

---

From: "David W. Forslund" <[email-masked]>
Date: Thu, 30 Jul 1998 07:34:56 -0600

>performance, so CORBA doesn't come to mind directly. 

The OMG now has an asynchronous messaging specification now, too, so that
there are additional mechanisms available today  for communicating along
with EVent and Notification services.  With the IIOP as an underpinning for
RMI and CORBA and the ability to specify your own protocol with CORBA and
still be within the standards, I don't believe specifying CORBA means low
performance.  Kate Keahey has worked on parallel extensions to CORBA, for
example.  And there is a streaming protocol underway, too.  The value is
that one can have commercial leverage here, and not have HPC just be an
academic or niche exercise.  We have used CORBA over an OC-3 link with
paralel machines and gotten very good performance.  Doug Schmidt has done
wiork with high speed medical imaging in CORBA with reasonable success and
provided feedback on how to do high speed implementations.  CORBA is an
evolving standard which is moving very rapidly and is strongly embracing
Java (which is why RMI will use IIOP as at least an optional protocol).

>I am also not necessarily interested in seeing IP in my distributed Java

This should be invisible to you but would be necessary when those
applications are distributed over a wide area network.

>with performance or QOS requirements more suitable for scalable group

I disagree.  It is probably the most effective way to get the requirements
of high performance computing adopted by industry and thus get a much
larger market involved.  The OMG is interested in this area if there is a
case for a commercial market.  I think the HPC community needs to address
the commercial market place if it is ever going to be accepted on a wider
scale.   I would be happy to discuss these issues in more detail.  We have
an invited talk at the HPDC7 meeting this week because we believe CORBA is
highly relevant to high performance computing.  This does not mean that
every internal parallel link must use all of CORBA, but that the CORBA
requirements should be factored in to HPDC

Dave

---

From: Dennis Gannon <[email-masked]>
Date: Thu, 30 Jul 1998 09:34:21 -0500 (EST)

hi David,

re: GIOP, as you know, is the general inter orb protocol upon which IIOP
is based. i don't think it provides much to support for the collective
operations of MPI (just as it also fails to provide the required support
for distributed garbage collection needed by RMI.)

I think we should think about what MPI is good for:
  SPMD computation in relatively heterogeneous and co-scheduled systems.
that is what it was designed to do.  MPI-2 is really excellent.
there are lots of good reasons we may want to do the same for co-scheduled
java VM's running on fast, dedicated networks such as in a pc cluster
or SP-2 environment.  this could be a major win in the java server market.

however, this has little to do with InfoBus.
Actually, there are two InfoBuses.  one from stanford which is a system
for integrating heterogeneous information sources.  
the other is from lotus and a standard java api exists.  this is designed
to allow beans to exchange information using a bus metaphor.  handy for
making different apps share an updated sub-array of a spreadsheet.
this is the teritory of corba and rmi.  it would
be a bad model to base MPI upon because, as tony said, MPI programs are
written with the expectation of extremely low latency colletive ops.
You may be refering to the idea that the bus is like an mpi communicator,
but info bus is not really designed to implement fast recuctions, etc.

(it is interesting to note that infobus is yet-another-component-model
for java.  that make 4.  beans, enterprise-beans, infobus and 
the java studio model.)

Ibus is a java package to support groupware with reliable multicase,
message encryption, etc.  it is explicitly designed to run on top of IP
multicast.  Again, it is very interesting, but does not play the role
of MPI.  but, you may be correct in that there is something interesting
in the API that would make sense for MPI to use.

And i also think you are correct:  there is noting in the CORBA spec
that precludes high performance.

---

From: "David W. Forslund" <[email-masked]>
Date: Thu, 30 Jul 1998 21:02:01 -0600

>for distributed garbage collection needed by RMI.)

However, distributed garbage collection is being worked on by the OMG now.
After all if RMI is to run on top of IIOP, most of the deficiciencies will
be taken care of.

>or SP-2 environment.  this could be a major win in the java server market.

Certainly.  But I think it would be useful to indicate the value of
standards like this to create portable, scalable commercial applications,
such as various data mining and searching applications.
>but info bus is not really designed to implement fast recuctions, etc.
There is a distributed infoBus from IBM, also.

>that precludes high performance.  

That is what Doug Schmidt is doing with is TAO ORB.  However, this is not
in Java.

Dave

---

From: "TAKAGI, Hiromitsu" <[email-masked]>
Date: Thu, 06 Aug 1998 14:05:55 +0900

On Tue, 28 Jul 1998 18:06:27 -0500 (EST)
 > at ways to design a seperate serialization interface to RMI.

We are just building a yet another ORB for Java that is named as `xORB'.
It has an original transport layer and doesn't use any RMI classes.
However, it uses Java Serialization API and Reflection API and thus it
has a clean, simply structure. Its source code is available at
http://java-house.etl.go.jp/~takagi/java/bit-xorb/. We are sorry to say
that there are no documents yet in English, because it was originally
developed for educational purposes in a series of articles for a
computer science magazine in Japan. However we eventually realized its
potential as a practical platform for extensible implementation of
different ORBs (thus the name xORB, where x could stand for your
favorite letter), and are now redsigning it as both flexible, extensible
as well as fast communication substrate. 

xORB is based on Open Implementation techniques. `xorbc' compiler
generates Foo_Reifier class which translates method invocation to a
java.lang.reflect.Method instance and delegates it to the MetaObject.
The ORB is implemented as a subclass of MetaObject class. As a result,
extensible customization would be possible, including incorporating
different low-level transport layer, optimized serialization protocols,
one- or zero-copy buffering strategies, etc.

	:
 > not very natural in java?  or is it?)

It is our belief that we don't have to stick to the rigid use of RMI.
RMI's architecture can be divided into three parts: the serializer, the
transport, and the stub (reifier). We can provide original stub
architecture such as xORB's _Reifier. So the `natural' and `true object
oriented' distributed system that is different from MPI can be
implemented by its use. Clearly, the transport can be replaced with any
architecture. 

On the other hand, the serializer might depend on Sun's Serialization
API (not JRMP) because it has to support serialization of any classes,
including the system classes. The case of serializing simple structures
such as large sized array, the solutions to its performance problem may
be simply solved by using extended java.io.ObjectOutput/InputStream
which may include little native methods.

Hiromitsu Takagi (w/Satoshi Matsuoka)
Electrotechnical Laboratory, Tsukuba, Japan
http://www.etl.go.jp/~takagi/ (Underconstruction)

---

From: "TAKAGI, Hiromitsu" <[email-masked]>
Date: Thu, 06 Aug 1998 14:05:55 +0900

---

From: [email-masked] (Hiromitsu Takagi)
Date: Sat, 08 Aug 1998 21:56:17 +0900

---

From: [email-masked] (TAKAGI, Hiromitsu)
Date: Tue, 11 Aug 1998 02:03:46 +0900

etc.

---

From: "George K. Thiruvathukal" <[email-masked]>
Date: Mon, 10 Aug 1998 15:03:02 -0500

Hello Hiromitsu,

We seem to be getting a number of copies of this e-mail from you.

Please look into the problem at your earliest convenience. It appears you
are doing some form of 'automated' mailing.

George

*--------------------------------------------------------------------*
| George K. Thiruvathukal                                            |
| Loyola University Chicago          Tele: 773.508.3558              |
| Damen Hall, 3rd Floor              Fax: 773.508.2123               |
| 6525 North Sheridan Road           E-mail: [email-masked]        |
| Chicago, Illinois 60626            Web: http://www.jhpc.org/george |
*--------------------------------------------------------------------*

> [mailto:[email-masked]]On Behalf Of TAKAGI, Hiromitsu
> Sent: Monday, August 10, 1998 12:04 PM
> To: [email-masked]

---

From: Ian Foster <[email-masked]>
Date: Thu, 20 Aug 1998 20:02:18 -0500

There is some relevant work at Argonne ... in particular, the CIF
communication library which provides a [low-level] Java (and C++)
interface to a variety of reliable and unreliable unicast and
multicast protocols.  See http://www.mcs.anl.gov/cif for some
brief details.

Ian.

>> Watford Rd, Northwick Park
_______________________________________________________________
Ian Foster                                    Tel: 630 252 4619
Mathematics & Computer Science                Fax: 630 252 5986
Argonne National Laboratory                  Home: 773 493 7664
Argonne, IL 60439                       U.Chicago: 773 702 3487
U.S.A.                           http://www.mcs.anl.gov/~foster