Guardians and Actions: Linguistic Support for Robust, Distributed Programs
Barbara Liskov and Robert Scheifler

Really Big idea:  Using programming language features and system features
to ease development of distributed programs.

Big Idea: Add abstractions of "Guardians" and "Actions" to programming
languages.

	* Guardians: a guardian is a set of data and processes running
           together on a machine.  It is the unit of data protection,
           synchronization, recovery and authorization.

	* Actions: actions are basically transactions (and subactions are
          nested transactions). They have the same commit/abort semantics.

ARGUS Application Domain:
-------------------------


Distibuted programs that need to manipulate and preserve long-lived,
on-line data (banking systems, airline reservation systems, databases,
etc).  Apps that do not require real-time response, but do need to be
reliable, available, and distributed.

Apps' Imposed requirements:
---------------------------

	* continuous service is important: failures should be localized

	* reconfiguration: must be possible to make logical/physical
	  changes without taking down the system.

	* Autonomy: nodes of system are owned/operated by different people

	* Distribution: Apps will be distributed. Changes in location of
	  a module should have only limited, localized effects on actual
	  code.

	* Concurrency: app should be able to do multiple things at a time

	* consistency: on-line data needs to be consistent

!! Found that consistency is the most difficult requirement to meet !!
Approach is to use atomicity has a fundemental concept in the language.

More about Guardians:
---------------------

Data protection:  Data is stored local to a guardian, and can not be
accessed except through function calls to the guardian.  Any data sent to
another guardian is sent by value (not reference).

Data synchronization: The guardian is responsible for synchronizing
access to data, and making sure rules of atomicity are obeyed.

Data recovery: It is up to a guardian to make sure that enough of the data
is on stable storage that the whole state of the guardian can be restored.

Data Authorization:  The guardian can check credentials of a caller when
its methods are invoked.


More about Actions:
-------------------

Atomic actions are indivisible (actions don't appear to overlap) and
recoverable (all or nothing at all).

Nested actions are good tools for decomposing activities in a modular
fashion.  Have to be careful with nesting unrecoverable actions! (e.g.,
printing a check).  If a parent action aborts, we need to recover the
previous state of the child action. One approach is to have unrecoverable
stuff be done in a second top-level action which is only attempted if the
first action commits.


Questions:
----------

How deeply could you practically nest transactions? At what point do you
have too much state stored? or too much data locked (e.g., concurrency)?
What do DB people say?

Today's languages don't have these features.  Why not?