Tornado Framework Design

			   Work in Progress

Created 1994 03 15 by DBL

* Syntax definition for Representation.
* Primitive message definitions.

* Mechanism for unique identity across multiple nodes.
Define `client' as service requester, `server' as service provider.  A
`session' is a connection between a client and a server, during which
the client may make requests (see transactions) of the server.  Upon
client's request for a session, the server assigns a `session ID'
which is unique to all sessions on the server.  The session ID may not
repeat any IDs already used by the server for past sessions, up to
some point in the past which can reasonably be expected to be earlier
than the duration of a ``long'' session (this requirement is necessary
to avoid duplicate session IDs that could occur if a server crashes.
One good way to guarantee this uniqueness is to start session IDs
based upon some encoding of clock time.)

The session ID must not be assumed to be unique across multiple
servers.  Each server creates its own session IDs without knowledge of
other servers.  A session ID can only be unique between a particular
pairing of client and server.  A client that creates concurrent
sessions on multiple servers must be prepared to deal with the case
that session IDs are not unique across servers, and provide a means to
disambiguate sessions by server.

* Mechanisms for transactions.
* Mechanisms for recovery.

* Mechanisms for attributes, containment, and revision control.
* Mechanism for qualification or validation.
* Mechanism for procedural execution.
* Mechanisms for inheritance (proc/data) & delegation.
* Mechanism for service & data acquisition.
* Mechanisms for negotiation.
* API definition for Communication.
* More detail on Storage primitives.
* Extended example, including Interaction effects.

---- grabbed from arch.text ----
A centralized system would not benefit from descriptive data in the
sense defined for Tornado.  But users of a centralized system will
copy operational data onto their desktop and portable computers and
process the data locally (using terminal emulators, spreadsheets, and
databases).  These copies become incomplete, unauditable extractions
spread over tens, hundreds, or thousands of personal systems.  It's
reasonable to assume that the copies were extracted from the corporate
database according to some business need.  However, these extracts
expose the corporation to risk because of the absence of guarantees
for the currency and traceability of the data, and the lack of
verification of the techniques used to manipulate the data on the
desktop.  Tornado avoids this risk by keeping the descriptive data in
an active database and interpreting the descriptive data to access the
operational data; all users automatically get the latest information
when the business rules or data change.

One point which has not been addressed is the need for change control.
Obviously, any changes to the Tornado Software Architecture
Requirements must propagate through to the Tornado Software
Architecture (this document), subsequent design documents, and the
system software and hardware.  The impact of changes rippling through
the system will be greater as the system progresses toward completion,
so it is imperative that we establish impact analysis as well as
change control procedures.

Once the system is deployed, however, it is reasonable to expect (and
quickly respond to) operational changes as the system evolves.  This
strongly suggests the need for change control as an integrated part of
the deployed system; thus the final requirement of the TSA is that an
operational Tornado system be able to cope with changes over time.
Version control (of data and metadata); effectivity and expiration
dates; ownership information, access controls, and update privileges
for data objects; a registry of system services and resources;
prioritization of service requests against available resources; the
ability to process computations with missing data and automatically
update results upon data availability; and similar items must be part
of the Tornado system design.


Cache semantics are more than just an efficiency concern in the TSA.
We allow a subsystem to extend the cache right into documents created
by the user.  Cached values in documents can be updated from the
reference source as needed, ensuring that the presentation of
information in the document always reflects the latest value.  Cached
values in a user's document file are saved in a way that allows them
to be updated when a document is used later, even if it is copied to
another machine or network.  The use of this technique will depend
upon the needs of the system --- whereas a catalog document would
always use current values, a price quotation to a customer would have
its data values frozen when sent to the customer.


* System Builder's Guide

The builder must do the following to create a Tornado system design:

    1. Define the Representation syntax that the system will use.

    2. Define the name space for data.

    3. Map the primitive API onto the implementation language(s).

    4. Construct the functions used to implement the API.

    5. Build higher-level APIs on top of the primitives, if desired.

    6. Construct agents which map system Representation and primitive
       functions onto existing DBMSs, processing systems, and HI

    7. Define new subsystems, and construct them in terms of the
       extended API.


---- end of grab from arch.text ----