Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!aero-c!abbott
From: abbott@aero.org (Russell J. Abbott)
Newsgroups: comp.sys.isis
Subject: Process groups as network-level objects
Message-ID: <1991Apr29.205624.17754@aero.org>
Date: 29 Apr 91 20:56:24 GMT
Sender: news@aero.org
Organization: The Aerospace Corporation, El Segundo, CA
Lines: 51

In developing a mental model for myself of what ISIS provides, I came up
with the following.  I haven't seen this in any of the ISIS literature,
although that may simply mean that I haven't read enough of it.

A nice conceptual model for a process group would seem to be
network-level object.  ("Distributed object" is an alternative term, but
I prefer "network-level object" or perhaps just "network object.")

The term "object" seems appropriate since process groups include
processes that define responses to messages.  In addition, each process
group has (or may be built so that it has) a single internal state.

The term "network-level" also seems appropriate since process groups are
not defined in terms of their residence on any particular processor.
Instead they (are able to) use the resources of whichever processors are
available.

Network-level objects differ from traditional objects in another way
also.  They are capable of internal concurrency.  Notwithstanding their
internal concurrency, however, they (are able to) maintain a consistent
state.

It seems to me that the notion of a network-level object would be quite
attractive to anyone interested in implementing network level services.
Most network resource servers (as distinct from something like an X
server on a particular display) can probably be conceptualized quite
nicely as a network object.  The ISIS claim that virtual synchrony is
central to much of what goes on in distributed computing would be made
very concrete in this way.

Since I have done nothing to help in the conceptualization or
development of ISIS, I suppose it is gratutious of me make the following
suggestion, but here it is anyway.  (I guess "gratuitous" applies in
both senses.)

It seems to me that the term "process group" is misleading and
unsuggestive for potential ISIS users.  It would be better to present
ISIS as providing a network-level object capability as suggested above.
Process groups may then be seen as the (internal) mechanism that allows
for this capability.

With the preceding in mind, I would also recommend that ISIS do more to
enforce (or at least strongly recommend) consistency among processes
within process groups so that a process group will (unless explicitly
defined otherwise by a user) consist of processes that implement
network-level objects.  I imagine, though, that the issue of
intra-process group consistency is one that the ISIS group must have
debated.  I wonder why you made the decision not to go in that
direction.

-- Russ Abbott@itro3.aero.org