% File:    tsp-paper.tex
% Author:  RM, FM, JWS
% Date:    17-jul-1995
% Purpose: FIDE-2 Book
%
\documentstyle[xple_sl,epsf]{clmult01}

\pagestyle{myheadings}

\newcommand{\figwidth}{\textwidth}
\newcommand{\e}[1]{{\em #1\/}}
\newcommand{\p}[1]{{\sl{}#1}}
\newcommand{\k}[1]{{\bf{}#1}}

\title{Chapter 2.2.4\\
Towards a Unified Model of\\ Untyped Object Stores:\\
Experience with the Tycoon Store Protocol}

\author{Florian Matthes \and Rainer M\"uller \and Joachim W.\ Schmidt}

\institute{Technical University Hamburg-Harburg\\Harburger Schlo{\ss}stra{\ss}e 20\\D-21071 Hamburg, Germany}
 
\begin{document} 

\authorrunning{F.~Matthes, R. M\"uller \and J.W. Schmidt}
\titlerunning{Tycoon Store Protocol}

\maketitle

\abstract{This text is a synopsis of \cite{MMS96a}.}

\section{Introduction}

Systems that have to work with large-scale persistent data 
have a system architecture where there is a clean separation between a 
\e{frontend} performing data manipulation and visualization and a \e{back 
end} responsible for reliable persistent bulk data storage.  Since actions 
in the frontend trigger data access operations performed by the backend, 
this separation leads to a client-server architecture, where a 
\e{store protocol} defines possible interactions between a client program 
and a database server.

The Tycoon Store Protocol (TSP) specifies a clean interface between the
front\-end and the backend of fully integrated persistent environments.
TSP is designed to match
the flexibility requirements of persistent languages (see 
\cite{MMS92,Mue91b} for a more detailed discussion):

\begin{itemize} 
\item Full persistence abstraction requires 
uniform, efficient element-oriented access to persistent and 
non-persistent data, code and threads. 

\item Orthogonal persistence for polymorphic data structures,
higher-order (polymorphic) functions and 
user-defined abstract data types require an untyped persistent heap.

\item Incremental program construction and reflective programming 
techniques require schema modifications at runtime and dynamic binding 
techniques.  
\end{itemize}
%
Despite the fact that 
TSP has been implemented and evaluated in the context of the Tycoon 
project (see Chapter 2.1.4), TSP is fully independent of the Tycoon system.

%------------------------------------------------------------------------------

\section{On the Construction of Scalable Persistent Systems}

TSP has been designed to support the construction of 
\e{scalable} persistent systems, i.e., configurable systems where the 
complexity and size of the entire system is proportional to the 
operational support required by a particular client.

\begin{figure}
\begin{center} \leavevmode
\epsfxsize=\textwidth
\epsffile{Scal.ps}
\end{center}
\caption{The role of the Tycoon Store Protocol in scalable persistent 
systems}
\label{Fig:Scale}
\end{figure}

Figure~\ref{Fig:Scale} explains the role of TSP in such a persistent 
system scenario. 
The data access operations defined in TSP are issued by client 
programs and executed by database servers. 
In the full paper we report on our experience in implementing TSP backends 
including adaptors to existing object stores, e.g. ObjectStore.

\noindent
TSP defines a stable application programming interface for client programs 
(expressed by a standard C header file).
TSP is intended to be a stackable protocol. These 
optional system layers utilize TSP as their lower and upper interfaces and 
extend the semantics of individual TSP operations (e.g., store object 
update) and provide additional TSP operations (e.g., rollback to 
savepoint).
In the full paper we report on extending the TSP functionality 
systematically by TSP-compliant layers for persistent savepoints and access control.

TSP is complemented by a 
platform-independent external data representation (TXR) that can be 
generated and parsed by all TSP backends. 
The TXR makes it possible to 
transfer arbitrary complex, graph-structured persistent store objects via a 
linear data representation from one backend to another without exposing 
private implementation details of individual persistent stores.
 
A TSP client can choose dynamically between different backends 
and can access multiple stores (possibly of 
multiple architectures) concurrently. A multi-user database server like 
ObjectStore supports multiple TSP clients at a time which may run on 
different client nodes in a local area network accessing a shared
persistent store.


%--------------------------------------------------------------------------

\section{An Untyped Store Model}

A primary design goal behind TSP has been to provide efficient data storage 
as independent as possible from the data and language model supported by 
TSP store clients.  In particular, TSP should be capable of supporting 
polymorphically typed models where the components of store objects can 
contain values of multiple types that cannot be fixed in a separate schema 
definition phase.  TSP therefore uses an \e{untyped} low-level store model, 
i.e., there is no separate dictionary of type or schema information 
maintained by the backend.  Instead of this, store values are made 
self-descriptive by imposing a regular object layout and a uniform 
tagging scheme.  As a result, TSP achieves data model independence without 
sacrificing the advantages of self-descriptive statically-typed databases.
In the full paper the store model is described in detail.
  
%------------------------------------------------------------------------------
    
\section{Overview of the Tycoon Store Protocol}

Due to the simplicity of TSP's data model, it is possible to define concisely 
all its operations. The following clusters of operations are described in the full paper:
\begin{itemize}
\item operations on persistent stores,
\item failure handling and recovery,
\item operations on store objects,
\item main memory mapping of store objects,
\item management of object identifiers, and
\item lineraziation of store subgraphs.
\end{itemize}

%------------------------------------------------------------------------------

\section{Concluding Remarks}

The main contribution of this paper is the in-depth description of an 
object store protocol that we regard as an excellent starting point for a 
\e{standardized} interface between the frontend and the backend of fully 
integrated persistent environments.  In developing the TSP specification, its 
implementations and its adaptors to commercial object stores 
available to other research groups, we hope to establish TSP as a widely 
accepted protocol within persistent language implementations.  This would 
not only simplify the development of new persistent languages but also 
facilitate system measurements, comparative performance studies and 
interoperability experiments between multiple persistent languages.

\small
\bibliographystyle{plain}
\bibliography{../dbis-macros,../florian}

\end{document}

