The Process Group Approach to Reliable Distributed Computing
Birman

What I like best about ISIS system described in this paper is that it
is an attempt to build a system to allow not-so-experts to build at
least some kinds of distributed systems without needing the skills to
analyze the full complexity of the system.  Perhaps the effort is
futile, but this is the sort of area where I tend to feel its worth
exploring even likely futile directions, because the value of a simple
interface is often great enough to outweigh the problems behind it.
The great thing about virtual synchrony is that it can be described by
derivation from close synchrony, which itself is a reasonable model to
understand above the basic "can't assume anything" distributed system
model.

In a preview of my complaints about the other paper, I would point out
that not understanding application semantics is not always a bad
thing.  Lots of really useful bits of infrastructure are widely used
primarily because they don't try to understand what the application is
doing, and instead just try to provide a well-described hammer of a
service that programmers so that programmers will be able to see how
their problems can be viewed as nails.  My canonical example of this
has long been the combination of Unix sockets and TCP: simple
interface, probably does at least twice what most applications want,
and therefore at a substantial cost in performance, but it makes
writing applications easier because it is easy to describe what it
does and the interface is simple and doesn't tend to spread throughout
your code.

In the end, this paper leaves me with the feeling that ISIS/process
groups are best suited as a way to build a simple locally replicated
system.  They claim, and I believe, that wide-area latency is too
large to allow a system without better understanding of
application-level semantics.  I seems to me, though, that if this is
really all that this sort of system does well, it likely could be
better specialized, or at least better described in that context.  I
had difficulty, from the description in this paper, really
understanding what I could do with the system.

Finally, a pure rant: Correct me if I'm wrong, but were they totally
on drugs when describing figure 4?  They keep talking about all the
cases where message reordering happens, and I understand that such
reorderings are possible, but the figure shows everything happening
hunky-dory.  I wonder if some editor decided the supplied picture was
ugly with all those crossing lines and "fixed" it.