Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!ncar!gatech!udel!rochester!cornell!ken
From: ken@gvax.cs.cornell.edu (Ken Birman)
Newsgroups: comp.sys.isis
Subject: Re: ISIS features
Message-ID: <53097@cornell.UUCP>
Date: 13 Mar 91 14:16:49 GMT
References: <1991Mar8.163555.1321@aero.org>
Sender: nobody@cornell.UUCP
Reply-To: ken@gvax.cs.cornell.edu (Ken Birman)
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 57

In article <1991Mar8.163555.1321@aero.org> abbott@aero.org (Russell J. Abbott) writes:
>I just read that the Carnot project at MCC plans to offer virtual
>synchrony (plus a whole lot more).  If virtual synchrony becomes one of
>the more-or-less "standard" features that distributed systems begin to
>provide, where will ISIS focus its future efforts?

With a lead-in like this, I couldn't resist getting in touch with
the Carnot people....

It turns out that Carnot is more along the lines of Tuxedo or the system
that Transarc is building: a "database integration" environment.  The idea
is to build one big database system out of lots of pre-existing,
heterogeneous components.  ISIS, on the other hand, uses a non-
transactional approach and although our system is usable for database
integration (especially now that standard external "commit" modules
have become more common), most ISIS users are concerned with building
fault-tolerant services, or with a general problem of distributed systems
architecture, or with controlling/managing subsystems of some sort.

Of course, ISIS is about gluing components together to make a big system
and so is Carnot, so the projects do seem to share some aspects of their
architecture.  This is why their project summary sounds like it could
be a system directly aimed at typical ISIS applications.  In fact, however,
what they are doing is very much in a transactional model and not particularly
aimed at process group programming, whereas ISIS is aimed at process group
programming and has "token" support for transactions, at least so far.

Virtual synchrony in Carnot is also a little different than in ISIS.
For us, this is very much a process-group property, combining synchronization,
fault-tolerance and causality properties, and with an emphasis on asynchronous
interactions.

Carnot doesn't seem to have a process group model per-se, although it 
apparently can support several aspects of what ISIS does.  From what they
sent me, it appears that the system doesn't have anything comparable to
virtually synchronous addressing, and the model is not fault-tolerant
in the sense of the ISIS model.  What they do provide is more of an
ordered multicast primitive, like abcast, and in fact while they call
the system "virtually" synchronous, I would have used the term
"closely" synchronous.

They implement this model over the network Linda system: a broadcast is
done by creating a tuple containing the data, and a recipient uses "rd"
to pull messages in in the order they were issued.  The scheme was
developed by Chris Tomlinson (tomlic@mcc.com).  The head of the project is
Phil Cannata: 512-338-3376 (cannata@mcc.com).

I hope I haven't gotten all this wrong -- I'm substantially compressing
the information they were able to send me, and I may have missed a key
point.  If you really need to learn about this, please contact them
and take anything written above with a grain of salt.
  
-- Ken
Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
Cornell University                                      607 257-6195 (home)
Ithaca, New York 14853 (USA)                   FAX:     607 255-4428