% File:    support.tex
% Author:  Florian Matthes
% Date:    11-AUG-1995
% Purpose: F2 Book: Introduction to Section II, Persistent Support Systems
%
\documentstyle[epsf]{clmult01}

\pagestyle{myheadings}

\newcommand{\e}[1]{{\em #1\/}}
\newcommand{\p}[1]{{\sl{}#1}}
\newcommand{\k}[1]{{\bf{}#1}}
\def\descriptionlabel#1{\hspace\labelsep \bf #1\hfil}

\title{Part 2\\Persistent Support Systems:\\Introduction and Overview}

\author{Florian Matthes}

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

\begin{document}

\authorrunning{Florian Matthes}
\titlerunning{Part 2: Persistent Support Systems: Introduction and Overview}

\maketitle

\noindent
The goal of the persistent support systems developed in FIDE is to
improve the construction, maintenance and operation of \e{persistent
application systems} (PAS). A PAS is a software system that gives its
users a flexible, problem-oriented and safe access to large sets of
long-lived objects of application-specific types.

Due to technological and commercial developments there is an
ever-increasing demand for persistent application systems that have to
handle \e{non-standard} object types, such as texts (electronic mail, text
retrieval, ``intelligent'' text manipulation), two- and
three-dimensional graphics (CAD and geographic information systems),
digitized raster images (picture and font databases, fax manager,
character recognition software), voice data, or even image sequences
(presentation software, scene analysis). Moreover, persistent
application systems have to be implemented also in PC-based,
interactive, networked, distributed, or semi-autonomous system
environments. As a consequence of their longevity, PAS have to survive
even under drastic changes of their underlying hardware and software
platforms.  As it is widely recognised today
\cite{Catt91,Mano92,ZdMa89,ABW*90,Manifesto90}, 
classical database technology provides insufficient system support for
these new object types and changing system environments.

In addition to the classical problems of large-scale application
development, developers of a PAS are faced with three PAS-specific requirements:
\begin{description} 

\item[Generic Programming and Data Modelling:] Persistent application
systems are characterised by highly repetitive algorithmic and
structural patterns (set-oriented queries, integrity constraints,
generic data structures, etc.). Therefore, many commercial tools utilise
generator techniques to derive automatically stereotyped program
fragments (form definitions, format conversions, sorting routines,
iterators, etc.) from parameterised, high-level descriptions. But by no means all of their operations fit these regular patterns, and therefore, it is necessary to facilitate their use from general purpose languages, such as those presented in Part 1 of this book, as well.

\item[Persistent Storage:] The primary task in a persistent application system 
is the manipulation of the state of long-lived data objects shared by
multiple, possibly concurrently executing applications. In advanced
persistent application systems it is advantageous to be able to store,
share and modify also program objects (``methods'', ``scripts'') and
programs in the process of being executed (``workflows'',
``activities'', ``processes'') as first-class data objects.

\item[External Server Integration:] The buzzword ``open architectures'' is 
of particular relevance for persistent application systems since it is
often necessary to interact with external devices (screens, printers,
keyboards, pointing devices, scanners, CD-ROMs, modems, fax machines,
etc.) and external servers (window libraries, RPC libraries, directory
services, etc.) for data acquisition, data presentation, data transfer
and data integration purposes.

\end{description}
%
In the following, we first sketch how these requirements are met
partially in third- and fourth-generation languages, and we then outline
FIDE's contributions to PAS construction in comparison with these more
traditional approaches.

\section*{Low-Level Server Access from Third-Generation Languages}

The majority of today's information systems are implemented in 
third-gener\-ation languages (COBOL, FORTRAN, C, Pascal). A severe limitation 
of these languages is their inability to capture correctly the genericity 
inherent even in simple persistent object models. For example, the 
relational data model supports the definition of unary, binary, ternary, 
\ldots\ relations over various domains and it includes generic operations 
over relation variables. These operations cannot be captured adequately
by any of the commercial programming languages mentioned above \cite{BHR82}.

\begin{figure}
\begin{center}\leavevmode
\epsfxsize=0.8\textwidth
\epsfbox{3GL-Interfaces.ps}
%\caption{Narrow and unsafe server interfaces in third-generation languages}   
\vskip 3pt
\hbox to\hsize{\leftlegendglue{\bf Fig. 1.} Narrow and unsafe server interfaces in third-generation languages\hfil}%
\end{center}
\end{figure}

As a consequence of this conceptual limitation, developers of database 
programming interfaces like Embedded SQL \cite{ESQL90} restrict themselves 
to the least common denominator of all 3GLs and handle any information 
interchange via strings, addresses and untyped byte arrays that are 
transferred at the smallest possible granularity (attribute-wise) between 
application programs and the database systems. A similar situation can be 
observed at the interface between programming languages and (graphical) 
user interfaces. 

The resulting POS scenario using 3GLs is depicted in 
Fig.~1: The overall functionality of a particular 
POS is provided by a coordinated manipulation of numerous heterogeneous 
objects on different media (D: database objects, P: program objects, S: 
screen objects, etc.). Objects on different servers are subject to 
server-specific naming, typing, lifetime, and binding rules (indicated by 
different line styles in Fig.~1) while 
inter-server communication takes place at a low level of abstraction using 
simple, machine-oriented protocols.

A crucial advantage of such a loose server coupling is the \e{openness}
of the application development environment. If required, new servers can
be integrated freely as libraries into existing persistent object
systems.  Furthermore, call interfaces provide a minimal common ground
for data exchange between independently developed services and they
also constitute a starting point for data abstraction and component
exchangeability.

\section*{Server Integration in Fourth-Generation Languages}

Fourth-generation languages recognise the need for a uniform, safe and
application-oriented development environment across a variety of servers
and above the minimal interoperation level of strings and cursors.  As
depicted in Fig.~2, a well-designed 4GL provides
high-level naming, typing and binding mechanisms for objects on
different media (on disk, in memory, and on screen) and thereby
eliminates a substantial amount of the low-level, repetitive data-conversion and data-transfer code found in 3GL applications.  4GLs are
tailored to the specific requirements of traditional, commercial
database applications:

\begin{figure}
\begin{center}\leavevmode
\epsfxsize=0.8\textwidth
\epsfbox{4GL-Integration.ps}
%\caption{Server integration in proprietary fourth-generation languages}   
\vskip 3pt
\hbox to\hsize{\leftlegendglue{\bf Fig. 2.} Server integration in proprietary fourth-generation languages\hfil}%
\end{center}
\end{figure}


\begin{description} 

\item[Functional requirements:] record- and set-oriented data 
modeling, data manipulation, data storage and data display; generic 
operations (search, iterate, insert, delete, update, format, display, 
validate, \ldots) applicable uniformly to record and set objects of 
different component structures. 

\item[Operational requirements:] persistent storage of data, application 
code, integrity constraints and user-interface definitions; efficient 
manipulation of data on secondary storage; integration into transactional 
multi-user systems. 

\item[Modal requirements:] interactive user-interfaces, access to
precompiled queries and update transactions; support for incremental system 
evolution (e.g.\ schema changes); provision for \e{ad-hoc} queries. 

\end{description}
%
Examples of relational 4GLs include Ingres-4GL \cite{Ingb90}, PL-SQL
\cite{Orac90}, Visual Basic for Microsoft Access and Informix-4GL \cite{Infor86}. Furthermore, several
object-oriented database systems are shipped with 4GL languages to
simplify application development (e.g., $O_2$SQL and $CO_2$ for $O_2$
\cite{BDK92}). Several client-server programming languages like
Visual Basic or Power Builder can also be classified as 4GLs. Practical
experience shows that 4GL constitute a significant advance towards
achieving faster software development, improved long-term software
maintainability, better software portability, and even enhanced
execution efficiency for specialised applications (e.g., queries) when
compared with hand-coded third-generation language solutions such as written in C or
COBOL \cite{MaJa89}.

There are, however, some severe limitations to current 4GL languages
that hamper their success in today's open, continually evolving system
environments: 4GLs are deeply integrated into proprietary DBMSs and it
is therefore impossible to move 4GL applications from one DBMS to
another.  This situation is in sharp contrast to 3GL applications using
standardised programming and database languages (e.g., C and OpenSQL).
Moreover, applications developed in 4GLs do not scale well due to a lack
of appropriate typing and modularisation support such as that found
in Ada, C++, Modula-2 or Eiffel.  On the system level, 4GL often incur an
unnecessary system overhead since it is impossible to ``downscale'' the
extensive 4GL runtime support (form management, event management, query
support, report generation, transaction management, \ldots) to just the
functionality needed by a particular application. When a problem does not match the patterns of computation captured by the 4GL models, the cost of coding the solution can rise very rapidly.


\section*{Support Systems for Persistent Higher-Order Languages}

Most of the above 4GL limitations reflect the deficiencies of the
commercially available persistent system technology. This technology
simply does not support the abstractions required for a more flexible,
systematic 4GL service integration.

To overcome these limitations and to achieve 4GL openness and
extensibility, FIDE undertook the integrated effort of not only
developing higher-order languages with appropriate abstraction
capabilities (see Part 1), but also of designing persistent system
architectures (Chapter 2.1), realising object store managers (Chapter
2.2) and experimenting with novel implementation techniques (Chapter
2.3).

The FIDE system support architectures and their implementation
techniques are influenced heavily by \e{language concepts} which are
described in more detail in Part 1. For example, orthogonal persistence
requires a uniform and highly efficient management of volatile and
persistent data, higher-orderness requires a uniform persistent storage
of data, code and threads, genericity calls for polymorphic value
representations, and reflection leads to a tight integration of the PAS
development and execution environment.

Fig.~3 sketches the architecture of a PAS
implemented in a persistent higher-order language. Similar to a 4GL,
the relevant application objects (persistent database objects, volatile
program objects, virtual screen objects, etc.)  are subject to uniform
naming, typing and binding rules, indicated by uniform line styles
connecting the corresponding symbols in
Fig.~3. In contrast to a 4GL, most of
these object types are not built into the base language but are provided
by an open set of libraries that are an integral part of the programming
environment. Some of the libraries are simply interfaces to external
services (database systems, language compilers, GUI toolkits), other
libraries provide functionality that is implemented in the persistent
higher-order language itself (see Chapter 3.1.4). Furthermore,
Fig.~3 indicates that access to some of
the libraries may be supported by tailored syntactic forms provided by
the persistent languages or by application-specific syntax extensions.

\begin{figure}
\begin{center}\leavevmode
\epsfxsize=0.8\textwidth
\epsfbox{Application-Framework.ps}
%\caption{Scalable application frameworks in persistent higher-order languages}
\vskip 3pt
\hbox to\hsize{\leftlegendglue{\bf Fig. 3.} Scalable application frameworks in persistent higher-order languages\hfil}%
\end{center}
\end{figure}

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

\end{document}

