Path: utzoo!utgpu!cunews!bnrgate!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: pae@athena.mit.edu (Philip Earnhardt)
Newsgroups: comp.sys.sun
Subject: RPC Technologies
Keywords: No Digest Subjects in Unmoderated Mode
Message-ID: <3250@brchh104.bnr.ca>
Date: 4 Jun 91 18:40:00 GMT
Sender: news@brchh104.bnr.ca
Organization: Sunspots, Psuedo-Unmoderated
Lines: 43
Approved: sun-spots@rice.edu
X-Original-Date:    Mon, 13 Aug 1990 23:16:46 GMT

There have been three ideas about RPC, asynchronous processing, and
multi-threaded systems that have been somewhat lost in the recent discussion:

1. Asynchronous processing is a separate issue from RPC.  Non-distributed
   applications have and will continue to use asynchronous processing.

2. One very powerful way to use RPC technology is to take an existing
   non-distributed application and use an RPC Toolkit to make it a distributed
   application.

If you want to take an existing standalone application that uses asynchronous
processing and make your asynchronous call be a remote procedure call, we feel
the most straightforward thing to do is an Asynchronous RPC call. Our
asynchronous customization provides the three things you need to do that: a
routine to invoke the remote procedure, a routine to check the status of the
procedure, and a routine to get the results of the remote procedure. There
will be existing analogues to these routines in your non-distributed
application.

Alternatively, if you want to create a multi-threaded application for doing
the remote procedure call, fine. The Netwise RPC Tool will work correctly in
multi-threaded environments. My personal opinion is that multi-threading is
the wrong tool for the job (for a variety of reasons--see below). However, it
shouldn't matter what I think--the decision should be left to the designer:

3. Asynchronous processing and multiple threads are both tools that are
   available to the developer of distributed application. Whenever possible,
   both of these methods should be available to the designer of the
   distributed application. Give the designer the choice.

My main objection to the NCS philosophy is demonstrated in Mishkin's last
message <4bc8788d.20b6d@apollo.HP.COM> :

> Asynchrony is hard to understand.  All the more reason to have a single
> abstraction -- the process/thread -- to deal with it.  

Mishkin thinks Asynchrony is hard to understand; it is not available in NCS.
Why not give the designer the choice?

The July 9, 1990 issue of UNIX Today! contains the OSF DCE Rationale and
Netwise's response to it. Hopefully, these discussions about Asynchronous RPC
will give some insight into the customization issue discussed there.