% File:    kiev90-1.tex
% Author:  F. Matthes, J.W. Schmidt
% Date:    11.2.1991
%
\section{Introduction and Motivation}

During the past decade, substantial theoretical and technological
progress was made towards expressive, efficient, wide and safe
interfaces between application programs and database systems. Central to
this development is the idea of \e{database programming languages}
\cite{Schm77,ACC81a,CoMa84,LeRi89,SEM88,MaSc89,OBBT89},
offering an integrated language framework for the implementation of a
wide range of data-intensive applications.

Recent advances in type systems for programming languages (like ML,
Modula-3, Quest, Napier or TRPL \cite{HMT88,Card88,Card89,NapierRep})
and extensible database systems (like Exodus, Genesis, Postgres,
Starburst or Iris \cite{Ston90}) lead us to the understanding that the
technology is there to address another fundamental \e{interface problem}
in integrated database enviroments.

Currently, database application programs run against an environment
which has its functionality strictly divided into two distinct
partitions:  
\begin{itemize} 
\item The database management system constitutes that part of the
environment wich provides the specific functionality required for bulk
data management, access path utilization, persistence, concurrency,
recovery etc. This \e{Database Environment} is sealed and secured up to
rather narrow interfaces for data, query and transaction definition and
hides its internal functionality completely.

\item The rest of the  environment consists of application-specific
modules and libraries that solve relevant subtasks of the problem at
hand (e.g. statistics packages or some routines for display handling).
In contrast to the closed DBMS world much progress has been made in
recent years in opening such \e{Application Environments} and making
them easily extensible without compromising on the side of reliability.
\end{itemize}

Of course, any piece of functionality required by a user program
either has to pre-exist in the environment or has to be provided by a
newly developed software component. Note that the two partitions
differ substantially in their ability (or willingness) to contribute
to \e{functionality extension}: 
\begin{itemize} 
\item Application Environments are designed with the primary goal of
extensibility. They support the extraction of repeating patterns of
implementations and protocols from individual user programs, the
integration of such services into environments, and the re-import into
the programs of an entire user community, thus encouraging sharing and
re-use of ``standardized'' functionality.  In recent years substantial
progress was made in understanding the linguistic and architectural
support required to ``factor out'' and ``multiply in'' a wide variety of
functionality. Modern programming languages provide mechanisms based on
typing, parameterization and instantiation to extract \e{abstract
functionality} from sufficiently different contexts and to utilize it
for reliable, robust, extensible and economic system construction.

\item In contrast, traditional DBMS Environments disallow any
substantial modifications of their functionality and disencourage any
utilization of their internal functionality.  However, it is commonly
agreed that next-generation DBMSs have to cope with novel application
areas \cite{ABW*90} and unpredictable demands. Therefore, future DBMSs
have to be prepared for functionality extension on all levels: new data
structures, new operations over them, novel transaction mechanisms etc.\
and this can be achieved only by \e{controlled modifications} of DBMS
functionality.
\end{itemize} 
In this paper we argue that the degree of extensibility required for
next-generation Database Environments can not be achieved by
implementations based on traditional system programming languages such
as C or Modula-2.  Such implementations can not be opened sufficiently
because of
\begin{itemize}
\item \e{safety deficiencies}: they do not exploit state-of-the-art
techniques for system genericity and control by mechanisms like
polymorphism, higher-order functions and subtyping; 

\item \e{complexity problems}:  there is no suitable support for
system abstraction and organization, e.g. by taxonomies of collection
types or transaction protocols;  

\item \e{conceptual mismatches}: traditional system programming
languages do not support crucial DBMS demands, such as the need for data
independence, query optimization, persistence, or any kind of data
distribution control.
\end{itemize}

We argue that the \e{same abstraction mechanisms} be used for the
construction of the entire environment of a database application
program consisting of both, the Database Management System and the
Application Environment. As an initial step towards this goal we even
want to go one step further and exploit the \e{same linguistic
platform} for the application program and its environment. For the
resulting integrated \e{Database Application System} we expect
improvements in the following essentials: 
\begin{itemize} 
\item improved DB system implementations in terms of correctness,
robustness, efficiency; 

\item adequate language support for database system extensions; 

\item  higher productivity for application programmers by
factoring out more re-usable code from user programs into the
Application Environment;

\item evolution of standards based on functionality and  protocols
rather than on ad-hoc query languages. 

\item support for DB interoperability (multi-databases), e.g. by
access to the protocols of the transaction manager. 

\end{itemize}

In the next section, we identify key requirements of Database
Application Systems. Section~\ref{Quest} outlines which of these
requirements are already met in an existing language (Quest
\cite{Card89}). To illustrate the improvements to be expected from a
single programming language for Database Application Systems,
section~\ref{Streams} investigates the definition of iterators and
generic collection types in such a generic and extensible language
framework. Section~\ref{Architecture} sketches the overall architecture
we expect from open database application environments. The paper
concludes with a list of language issues that still have to be solved in
order to make database system programming languages competitive with
well-developed database languages, topics that are also subject of our
current research.
