Crista Lopes is one of the early contributors to AOP
technology. Here is what she wrote to Andrew Black in 1993:


From crista Wed Oct 27 11:45:40 1993
Subject: forwarded message from Cristina Isabel Videira Lopes <crista>

Here is the mail that I sent to Black.

------- Start of forwarded message -------
From: Cristina Isabel Videira Lopes <crista>
To: black@crl.dec.com
Cc: crista
Subject: Distributed applications
Date: Thu, 7 Oct 93 14:48:55 EDT


Hi Andy,

I hope you have a few minutes to read this mail and reply back your
comments.  I know you have a LARGE experience in this field, and
somehow, after our conversation at Northeastern U., I felt my ideas are
not very far from yours.  Basically, I am going to expose them in a more
formal way than our conversation, so you can give me pointers to where
to go from here and where to look for more.

Distributed Computation
- ----------------------- 
My definition of distributed system is "a set of independent processors,
connected by some unreliable media, which collaborate to achieve some
global functionality". As a consequence of this definition, the two main
characteristics that distinguish distrib. systems from centralized ones
are failures and concurrency. Here's what I think about them:

1 - we should explore them, instead of hidding them.  
2 - it should be up to the application programmers to decide what to do
    in the different situations of *their* application [this conviction
    comes from my past experience in the COMANDOS project (IK), where we
    did exactly the opposite :)].
3 - developing distributed applications should be easy, understandable
    and should follow some systematic approach (what else is new?!?)

Let me just say a few words about 1 and 2. "Transparency" is a word that
I've encountered a zilion times in several papers, including mine.
However, this word tends to get more importance than it should: the aim
for "location transparent invocations" or "transparent atomicity" or
"transparent replication" usually results in the programmer having less
control over the basis of distributed systems, i.e., several processors,
concurrency and what to do when things fail. Transaction systems are
certainly a good example of this: they assume that there will always be
failures or conflicts, therefore avoid them by default, whether it is
convenient or not. As long as my definition of distributed system holds,
the optimal solution to distributed computation is application
dependent, and any attempt to disguise a distributed system into a
centralized one, in order to make programs easy, is pure waste of time.

Anyway, these are just prelimiary considerations to the real issue.
Thanks to all the previous work in this area, now we have technology for
almost everything concerning distributed object oriented systems, even
complex things as objects' migration. What we don't have (and what I
think the "real issue" is) is methodology - the systematic analysis of
the principles related to distributed applications. Although everybody
has *an idea* about what those principles are, there is still no system
that achieves their orthogonalization. Systems that we see today, like
CORBA systems, for example, make confusing compromises between language
independence, transparent invocations, concurrency control, etc, that
eventually fall over... the code or the structure of the applications.
What I mean is that, in spite of those nice interface definitions, the
programmers still mix the distribution issues with the code. This is
also true for Emerald, for example. (Let me know me if I'm wrong)

What I see today is that questions like "What shall we do when there is
a communication failure?" are solved at the same level of "How do we
find the names of all red-haired students in the College?". Here are
examples of what I'm talking about:
;;
     IF ((rhs = College.GetRedHairedStudents ())) FAILS WITH:
         noredhairedstudents) DoOneThing;
         timeout, noserver) doAnotherThing;
;;
     Lock (someObj);
     someObj.DoSomething();
     Unlock (someObj);
;;
      me.fixed_at := xpto_node;
      x = (-b + SQRT (b*b - 4*a*c)) / 2*a;
;;
      class Student : public SYS_REPLICATION {
         String *name;
      };
;;

My point is that what we call "code" of the application should only be
concerned about the global functionality of the problem AND what we call
"structure" of the application should only be concerned about the global
structure of the problem. Of course we need remote invocation support,
locking mechanisms, replication mechanisms, etc, etc, BUT - we should
not mix any of this with the "code", BECAUSE - it makes distributed
applications complex to control, almost impossible to understand (except
for the person who wrote them) and adverse to changes.

SO - Here's want I'd like to do:

First step: identify the dimensions of the space in which distributed
apps exist. I'd say: data, functionality, multiprocessing, concurrency,
failures, whatelse?

Second step: prove that those variables are, in fact, independent,
non-redundant and total. If they're not, think again. From a first
glance, I *feel* that those that I mentioned are "independent" and
non-redundant, but there may be more, and *feelings* is not what I want.

Third step: come out with a good idea of how programmers can control
each of them without modifying the others (that is, with minimum
dependency on the others (I don't think total independence will ever be
possible - after all, interaction is what makes things work!)).

By the way, the Demeter system has already proved that data and
functionality can be separated, not only in the database systems view.
In fact, you can have the same functionality (i.e., the same block of
"code"), say, print the names of all red-haired students in the College,
for an infinite number of different class structures involving
"Students" and "College" - this is what Karl calls "adaptive software",
and I think it is excellent. What I want to do fits 100% on this
adaptive approach, which stands on a higher level than object
orientation. The way I see it, problems introduced by distribution
should also be solved in a higher level than the programming language
used to express the application itself.

Thanks very much,
- -Crista


------- End of forwarded message -------