%
%
%    $Source: /mit/pss2/doc/other/RCS/usenix.tex,v $
%    $Author: marcus $
%    $Header: usenix.tex,v 1.3 89/02/06 22:12:34 marcus Locked $
%    $Revision: 1.3 $
%
\documentstyle[11pt]{article}
\setlength{\oddsidemargin}{0in}
\setlength{\evensidemargin}{0in}
\setlength{\topmargin}{-2pc}
\setlength{\textwidth}{6.5in}
\setlength{\textheight}{8.5in}
\pagestyle{empty}
\begin{document}
\title{The Athena Palladium Print System}
\author{Brian Handspicker \\ Digital Equipment Corp. \\ bd\%vines.DEC@decwrl.dec.com \and
Richard Hart \\ Digital Equipment Corp. \\ hart@decvax.dec.com \and
Mark Roman \\ Open Software Foundation \thanks{Current address: Open Software Foundation, 11 Cambridge Center, Cambridge, MA  02142}
\\ marcus@osf.org}
\maketitle              
\begin{abstract}

Large-scale application of traditional print systems to distributed
computing environments and modern printing hardware have exposed the
limitations of those print systems.  {\em Palladium} is a distributed
printing system being developed at Project Athena \cite{Athena85} to
address the issues of supporting and maintaining a distributed printing
system within a distributed computing environment.
It will provide access to
print services and centralized management of those services as
required by Project Athena.  The interfaces to these {\em Palladium}
services are designed to conform with developing international
standards.  {\em Palladium} supports the features found on current and
recently developed printing devices, and provides, in a distributed
environment, the print job queuing and management that users have come
to expect.

\end{abstract}
\thispagestyle{empty}
\section*{Introduction}

Recent advances in document publishing products and printer technology
have outstripped the support provided by traditional print systems.
Users may create documents with complicated formats, multiple fonts,
and embedded graphics on single user workstations.  When these
advances in printing capabilities are combined with the new
distributed computing environments now in use, it becomes evident that
printing systems need to be redesigned.

Project Athena \cite{Athena85} is a distributed computing environment
for use by students, faculty and staff at MIT.  It currently consists
of about 800 hundred workstations and 53 file servers.  It is planned
that Athena will grow to over one thousand workstations in the near
future.  The Athena Palladium Print System has been designed to
provide equitable access to shared printing resources in this
environment, and to provide this service in a manner consistent with
the Athena distributed services model.

The Athena system is based on UNIX\footnote{UNIX is a trademark of
AT\&T.} 4.3 BSD.  It was originally developed for an environment
consisting of a central processor with a well defined collection of
user terminals and other devices attached.  To adopt 4.3 BSD to the
distributed Athena environment,  important
pieces of software were added to provide authentication
\cite{Kerberos88}, location of services \cite{Hesiod88}, and
notification \cite{Zephyr88}. 

Because the Berkeley Spooler \cite{Campbell83} was written for a
central processor environment, it has certain shortcomings that make
it difficult to use in a distributed environment:  

\begin{itemize}
\item The desirability of placing printers, users, and spool queues all on
different machines in a distributed network environment was initially unforeseen.
\item The Berkeley Spooler does not easily support the centralized management
and logging needed at Athena, nor does it easily support the network
services we wish to incorporate.
\item Authentication of users was provided via {\em /etc/passwd}.
\item Access controls were not necessary for printers and queued print jobs.
\item It was assumed that printers only read and they never write information.
\item Tradeoffs were made based on the assumption that very little processor
memory is available.
\end{itemize}

The goals of the Athena Palladium Print System were developed to
address these issues.  While the Berkeley spooler has served us well,
we favor redesign of the printing system over further extensions.
This paper first describes our design goals and how distributed
systems design concepts have been applied to meet them.  Then, we
describe the print system model and the function of the constituent
pieces.

\section*{Palladium Print System Goals}

The goals of the Palladium project at Athena can be split into the following
categories:

\begin{itemize}
\item {\bf Computing Environment}.
Palladium is being designed for use within the Athena \cite{Athena85}
distributed environment.  Within this environment, Palladium users,
print queues, and printers, may all exist on different systems.  A
user may submit a print job from one workstation, then make inquiries
about that job from a different workstation.  If a printer
malfunctions, jobs originally scheduled for that printer may be
rescheduled on some other printer on the network.

\item {\bf Printer Support}
Palladium must eventually support many types and brands of printing
devices.  Of particular importance are newer printers that both
receive text to be printed, and  return status and control
information.  Also, it must be possible to support any  page
description language.  At Athena, the page description language of
choice is Postscript\footnote{Postscript is a trademark of Adobe
Systems, Inc.} \cite{PostScript87}, but others will be
supported.

\item {\bf System Management}.
Centralized system management is an important feature of any
distributed system having hundreds (and eventually thousands) of
workstations.  The Athena system is no exception.  Palladium will make
all printer and print server state information available through
standard interfaces to those with appropriate privileges.  It must be
possible to manage  individual printers and print servers
remotely, without changing the availability of  other printing
services.  It must also be possible for operators to redirect print
jobs to different printers, and generally manage print jobs.
Finally, reliable performance and usage data must be available
to guide system configuration and tuning.

\item {\bf Authentication, Authorization and Accounting}.
Palladium will not allow access to print system services and
information without proper authorization.  This implies reliable
authentication of a user's identity.  Palladium  must also be able
to log securely all activity and printer usage so that accurate and
credible accounting information can be generated.  

\item {\bf Standards}
The Palladium print system will conform with the emerging European
Computer Manufacturers Association (ECMA) printing standard
\cite{ECMA88}.  Palladium is a reference implementation of that
standard.  It is hoped that this will allow future printing systems to
be more easily integrated into the Palladium system.

\end{itemize}

\section*{Distributed Systems Concepts}

The design of the Palladium Print System has been realized through the
application of the following distributed systems concepts:

\begin{itemize}
\item Client-Server Model
\item Name Service-based Server Advertisement
\item Remote Procedure Call based Server Access Protocols
\item Embedded Tasking Systems
\end{itemize}

The client-server model proves very useful for the relationship
between local user applications and shared resources in the Athena
environment.  This approach allows many clients to obtain central
services and facilitates centralized management.  The name service
allows the client to obtain easily the address and information
necessary to get print service.  Name service basing minimizes
problems with information skew and update, and maintains the notion of
a public, stateless workstation.

The Remote Procedure Call (RPC) paradigm can be used to provide a
simple interface to distributed services.  Using the RPC service, we
need only to provide an interface specification to one of the RPC
utilities (an RPC Stub Generator) to generate the access protocol
code.  The RPC approach was used to shorten development time and
reduce problems with data representation.

There are some diffculties, however.  RPC paradigms enforce a
synchronous relationship between client and server.  To equitably
handle all requests that may be submitted to the server in a short
period of time, and to supply reasonable response to each request, the
server must have some way of logically doing multiple tasks at the
same time.  A tasking system will be used to provide this capability
by either allocating time slices of a single process to different
tasks or by creating new processes for each task that must be
accomplished.  The current implementation plan calls for the 
``time-slice'' approach.

%\begin{figure}[tb]
%\setlength{\unitlength}{.07 in}
%\begin{picture}(45,30)(-22,0)
%\put(25,2.5){\framebox(15,5){SERVER}}
%\put(25,7.5){\framebox(15,2.5){TASKING}}
%\put(25,10){\framebox(15,2.5){RPC}}
%\put(25,17.5){\framebox(15,2.5){RPC}}
%\put(25,20){\framebox(15,5){CLIENT}}
%\put(5,12.5){\framebox(10,7.5){\shortstack{NAME\\SERVER}}}
%\put(10,20){\line(0,1){2.5}}
%\put(10,22.5){\vector(1,0){15}}
%\put(10,12.5){\line(0,-1){7.5}}
%\put(10,5){\vector(1,0){15}}
%\put(32.5,12.5){\vector(0,1){5}}
%\put(32.5,17.5){\vector(0,-1){5}}
%\end{picture}
%\caption{Client-Server Print System Model \label{smallguy}}
%\end{figure}

\section*{Palladium Print System Model}
The Palladium Print System Model uses these distributed systems
concepts to improve the managability of distributed print systems and
provide equitable access to shared printer resources in the Athena
distributed environment.  In Figure~\ref{bigguy}, the logical design
and communication is illustrated.  The model is broken up into three
distinct parts: client, server and supervisor.  Communication is
accomplished through the RPC facility.

The functionality is broken up as follows:
\begin{itemize}
\item The print client contacts the name server to find an appropriate print server.
\item The server advertises its location via the name server.
\item The name server tells the client where to find the print server
that matches the user's needs.
\item The Palladium server interface allows access to the services which it provides
through an RPC interface.
\item The server's tasking system allows multiple clients to make requests
at logically the same time.
\item The server database stores all queued print jobs and Palladium print system
configuration information.
\item The scheduler passes responsibility for a job off to a specialized
process called a `printer supervisor'.
\item The printer supervisor takes responsibility for printing a single job, using
a single print format on a single (type of) printer.  Note that a
printer may support more than one print format, but for any specific
job we presume that only one of those formats is exploited.
\end{itemize}

The separation of functionality exploited in this design allows for
greater flexibility in extensibility and management of the system.

\begin{figure}
\setlength{\unitlength}{.1 in}
\begin{picture}(55,80)
% First, the boxes . . .
\thicklines
%
% No name server... vectors commented out below
%\put(5,72.5){\framebox(10,5){\shortstack{NAME \\ SERVER}}}
%
\put(30,70){\framebox(15,2.5){RPC}}
\put(30,72.5){\framebox(15,5){CLIENT}}
\put(30,62.5){\framebox(15,2.5){RPC}}
\put(10,60){\framebox(35,2.5){TASKING}}

\put(10,28.0){\framebox(35,32)}  % enclosing dbases
% \put(17.5,28.125){\framebox(5,27.5)}
\put(12.5,31.25){\framebox(5,25){\shortstack{J\\O\\B\\[7 pt]\\S\\C\\H\\E\\D\\U\\L\\E\\R}}}
\put(20,31.25){\framebox(10,25){\shortstack{PRINTER\\DATABASE}}}
\put(32.5,31.25){\framebox(10,25){\shortstack{USER\\AND\\ADMIN\\FUNCTIONS}}}

\put(10,17.5){\framebox(15,5){\shortstack{PRINTER\\SUPERVISOR}}}
\put(10,7.5){\framebox(10,5){PRINTER}}

% Now, the lines
\thinlines
% Name Server Lines
%\put(15,75){\vector(1,0){15}}
%\put(7.5,72.5){\line(0,-1){52.5}}
%\put(7.5,72.5){\vector(0,-1){35}}
%\put(7.5,20.0){\vector(1,0){2.5}}
%\put(7.5,47.5){\vector(1,0){2.5}}

% Supervisor Lines
% to printer
\put(15,12.5){\vector(0,1){5}}
\put(15,17.5){\vector(0,-1){5}}
%    to scheduler
\put(15,31.25){\vector(0,-1){8.75}}
%    to server front end
\put(25,20){\line(1,0){25}}
\put(25,20){\vector(1,0){10}}
\put(50,20.0){\line(0,1){47.50}}
\put(50,20.0){\vector(0,1){25}}
\put(50,67.5){\line(-1,0){10}}
\put(40,67.5){\vector(0,-1){2.5}}

% internal to server
%   tasking to user/admin functions
\put(37.5,56.25){\vector(0,1){3.75}}
\put(37.5,60.0){\vector(0,-1){3.75}}
%   tasking to job scheduler
\put(15,56.25){\vector(0,1){3.75}}
\put(15,60.0){\vector(0,-1){3.75}}
%   job scheduler to db
\put(17.5,47.5){\vector(1,0){2.5}}
\put(20,47.5){\vector(-1,0){2.5}}
%   job scheduler to db (bottom)
\put(17.5,37.5){\vector(1,0){2.5}}
\put(20,37.5){\vector(-1,0){2.5}}
%   db to user/admin
\put(30,47.5){\vector(1,0){2.5}}
\put(32.5,47.5){\vector(-1,0){2.5}}
%   db to user/admin (bottom)
\put(30,37.5){\vector(1,0){2.5}}
\put(32.5,37.5){\vector(-1,0){2.5}}

% Between RPC's
\put(37.5,70){\vector(0,-1){5}}
\put(37.5,65){\vector(0,1){5}}
\end{picture}
\caption{Palladium Print System Model \label{bigguy}}
\end{figure}

\subsection*{Palladium Client}
The Palladium Client software uses the Hesiod name server
\cite{Hesiod88} to select the Palladium server(s) that satisfy the
requirements of the user and to locate the desired server in the
distributed environment.  Hesiod translates the logical printer name
supplied by the user into an address for the print server that
supports the desired printer.  As more that one server may support a
given logical printer, it is up to the client routines to chose the
best (i.e. shortest queue length, shortest walk, etc.) print server
from those offered by Hesiod.  The client finally submits the request to
this server.  The client may also provide some local job management in
the case of a print request.

\subsection*{Palladium Server}
The Palladium server handles requests submitted by the Palladium
Clients and processes those requests.  Most requests are processed as
they are submitted, returning the results immediately.  {\bf Print}
and {\bf ModifyPrintJob} requests are validated and, if accepted,
added to the Job Info Database.  The Job Scheduler locates the right
printer which satisfies the job requirements, schedules the job on the
printer and tracks the progress of the job.  The server collects
events reported to it by the supervisors in the Job Info Database and
reports status and significant events to the user.  The server also
logs accounting and status information reported to it by the supervisors.

The Server does not understand the syntax or the semantics of the file
content.  The Job Scheduler merely matches the job requirements with
the capabilities of the printers managed by this server.  In this way
the server handles a broad range of file types and printer types.

The server may be implemented as several processes or as several tasks
within a single process.  However, it must run off of  single job,
resource and printer databases and use a single centralized scheduling
or queuing mechanism for all the jobs and printers that it manages.
In doing so, it provides equitable shared access.

\subsubsection*{Service Interface and RPC}
The Palladium Server Interface is presented as a set of library
routines (PdLib).  These routines are accessed through the RPC
protocol described earlier.  Palladium Clients use RPC library
routines to obtain the following service from a Palladium Server:

\begin{enumerate}
\item Print
\item Modify Print Job (that was previously submitted)
\item Read Job Status
\item Cancel Job
\item List Jobs
\item Read Print Server Characteristics 
\item Read Print Server Status
\item Read Printer Characteristics 
\item Read Printer Status
\end{enumerate}
In addition to these user requests there are a series of administrative
requests used to manipulate jobs, servers and supervisors.  These
functions allow the administrator to:
\begin{enumerate}
\item start/stop queueing, printers and servers
\item pause and release jobs for printing
\item change the characteristics of the various server and printer instances.
\end{enumerate}
These operations will be implemented within a single administrative
client, although that is not mandatory.

For Palladium, the HRPC software from The University of Washington
\cite{HRPC88} was chosen.  HRPC is a common interface to a number of RPC
systems.  Although HRPC is a common subset of the supported RPC
systems, it provides the functionality necessary for Palladium and for
the ECMA services.  HRPC provides a generic interface for remote
procedure calls, and its use will help to keep Palladium independent
of underlying protocols and RPC definitions.

\subsubsection*{Authorization and Access Controls}
For each request made by a client, the server checks a well-known
access list to determine if the user is authorized to make the
request.  Access lists are maintained for each operation.  In a
network environment, secure authentication of the client's identity is
required; Palladium uses Kerberos for authentication.\cite{Kerberos88}.

\subsubsection*{File Transfer Paradigms}  
When a print job is submitted to a print server, the contents of the
file(s) to be printed must be made available to the server at some
point.  There are three paradigms for print job file transfer:
\begin{enumerate}
\item Pass with Request (as a Print Operation parameter)
\item Retrieve by Server
\item Copy by Client
\end{enumerate}                                               

Each of these paradigms has its own advantages and disadvantages when
used in the distributed Athena environment.  The Palladium print
system uses each of these paradigms where it is most appropriate.

The ``pass by request'' paradigm can be used for communications
between clients and servers and between the server and the supervisor.
This method will be used as a default when other, hopefully more
efficient, methods do not exist.

The ``retrieve by server'' method is used for communications between
Palladium supervisors (the ``server'') and Palladium servers (the
``client'').  Palladium servers will make a publically readable
directory available that can be mounted by supervisors to read files
to be printed.  The supervisor will then copy the file to the printer
when it wishes to do so.

The ``copy by client'' method is used for communications between the
Palladium client and the Palladium server.  Palladium servers will
make a writable space available where clients may copy files to be
printed.  Essentially, the server returns to the client a file handle
and permission to write that file.  Such permission is revoked after
the copy is complete.

\subsubsection*{Palladium Server Database}
The Print Server Database contains high-level definitions of logical
printer capabilities (e.g. names of media supported, finishing
features supported, etc.), definitions of resources (e.g.  sizes and
colors of media, location of stapling, etc.), and print job request
information.  The print job information consists of the text to be
printed and the parameters which will control the processing of the
print request.  The database also contains capability and location
information for the supervisors which the server controls.  

The information in the Palladium database is split into two sections.
The first section contains static, relatively slow to change,
information.  This information describes the Palladium configuration
as a set of definitions of printers, logical printers, servers, and
supervisors.  Each server and supervisor reads a configuration file
when it begins operation and whenever requested thereafter to get the
configuration information it needs.

The  examples show the kind of information that a server or a
supervisor might read from a configuration file.  These configuration
files may be edited by a system manager, or, more normally, they are
generated automatically from the SMS System Management database.
The first example shows an entry for a printer that will be used by its
supervisor.  It contains all the information necessary to configure
and run a particular printer.

\begin{verbatim}

!
! A Configuration entry for a printer and its supervisor
!
begin entity = printer(satchmo)
        Type = ln03r
        GeographicLoc = E40-358
        DeviceAddress = /dev/ttycp
        HostName = castor.mit.edu
        ProgramNumber # 10489
        PrintFileDirectory = /mit/pss2/spool/Pd
        SetupProgram = /mit/pss2/etc/Pd/Setup.sh
        BannerDir = /mit/pss2/etc/Pd/BannerDir
        begin info
                Speed # 9600
                AsciiFilter = /mit/pss2/etc/Pd/AsciiFilter
                DviFilter = /usr/lib/tex/dvi2ps
                LocalFlagsClear # 0
                LocalFlagsSet # 040040
                SgFlagsClear # 0376
                SgFlagsSet # 001
        end info
        begin DefaultChars
                LogicalPrinters = (branford, wynton)
                Media = (8.5x11-white)
                Server = dizzy
        end DefaultChars
end entity
\end{verbatim}

Each printer has a particular type.  The printer {\bf satchmo} has a
type of {\bf ln03r}.  Each printer type supports a specific set of of
Data Syntaxes, Fonts, Media, and Forms.  These are listed in the
configuration file entry for the ln03r type entry.  Individual
printers may restrict these features if they require operator
intervention, disk space, or something else that may not be locally
available.  For example, {\bf satchmo} restricts Media to be just 8.5
x 11 white paper.

Finally, logical printers group desired functional capabilities that
may be supplied by some set of physical printers.  The configuration
file entry for the logical printer {\bf branford} is shown below.  The
server {\bf dizzy} makes the logical printer {\bf branford} available
to the world.  When a client makes a request of {\bf dizzy} for
services on {\bf branford}, the printer {\bf satchmo} will be used
based on the configuration file entries shown here.
\begin{verbatim}
!
! A Configuration entry for the ln03r printer type.
!
begin entity = type(ln03r)
        DataSyntax = (PostScript, Ascii, Dvi)
        Fonts = (AvanteGarde-Book, AvanteGarde-BookOblique, \
                 AvanteGarde-Demi, AvanteGarde-DemiOblique, \
                 ....
                 Times-Italic, Times-BoldItalic)
        Media = (8.5x11-white, 8.5x11-green, 8.5x14-white, 8.5x14-green)
        Forms = (MIT-LetterHead, Athena-LetterHead)
end entity
!
! A sample configuration file entry for a logical printer
!
begin entity = logprinter(branford)
        begin LogPrinterChars
                DataSyntax = (PostScript)
                Media = (8.5x11-white, 8.5x14-white)
        end LogPrinterChars
        begin JobDefaults
                DocumentFormat = PostScript
                StartPage = Full
                SeparatorSheet = Brief
                Media = (8.5x11-white)
        end JobDefaults
end entity
!
! A sample server Configuration file entry
!
begin entity = server(dizzy)
        ServerHost = zippy.mit.edu
        SpoolDir = /usr/spool/Palladium
end entity
\end{verbatim}

Besides the static information found in the configuration files, print
job request information is also stored in the Palladium server
database.  This more dynamic information is stored by the server in
the spool directory specified in the configuration information for the
server.  The interface to the Palladium database is the same
regardless of whether static or dynamic information is requested.  A
considerable portion of the database information is cached in memory
so that disk accesses are kept to a minimum.


\subsection*{Palladium Printer Supervisor}
The Printer Supervisor provides a static process to drive a specific
printer (or set of related printers) for the printing of one print job
at a time.  The Printer Supervisor is entirely responsible for
interpreting the job request.  This includes interpreting the content
of the file(s) and reconciling the instructions provided in the print
request parameters with the contents of the file.  The supervisor has
complete control over the printing of the job, including the loading
of fonts, forms and other electronic resources into the printer, as
well as the transfer of the file(s) to the printer.  

\subsubsection*{Supervisor Interface}
The printer supervisor provides the same RPC-based interface that the
print server provides to clients.  this allows the printer supervisor
to be accessed by either a print server or by individual clients.  The
printer supervisor may be configured to either: allow exclusive access
by a single Print Server or allow access by `all comers'.  The latter
configuration allows a print supervisor to be installed on a
workstation to drive a personal printer attached to that workstation.
The same interface used by the client to access shared printers
through a print server can be used by the client to access a local
(potentially non-shared) printer.  The only difference to the client
is the address advertised in the name server.


\section*{Conclusions}
The Palladium distributed print system has been designed to use
existing software technology to construct a truly distributed
printing system that can support current and future printing devices.
We are currently implementing and testing the design.

The incorporation of centralized management into the system will allow
for easier and more effectively management of print services as
advancing technology and user requirements place greater demands on
them.  It is hoped that basing our development work on an emerging
standard will permit our work to be easily augmented and extended by
Project Athena and other members of the MIT network community.

\section*{Acknowledgments}
We would like to acknowledge the efforts of the Palladium design team,
Pradeep Chetal, Dave Gray, Jack Woychowski, and Gerhard Messmer, who
contributed significantly to the design of the print system.  We would
also like to thank George Champine and Dan Geer for their persistent
support of our efforts.

\begin{thebibliography}{123456789012345}

\bibitem[PostScript87]{PostScript87} Adobe Systems, Inc., ``PostScript
Language Reference Manual,'' Addison-Wesley, Reading, Massachusetts, 
(April 1987)

\bibitem[Athena85]{Athena85} E. Balkovich, S. R. Lerman, and R. P. Parmelee,
``Computing in Higher Education: The Athena Experience,'' {\em Communications
of the ACM}, 28(11) pp. 1214-1224, (November 1985)

\bibitem[Campbell83]{Campbell83} R. Campbell, ``4.2BSD Line Printer
Spooler Manual,'' Dept. of Electrical Engineering and Computer
Science, Univ. of Calif., Berkeley, (July 1983)

\bibitem[Nectar88]{Nectar88} E. C. Cooper, ``The Nectar Threads
Package,'' Computer Science Department, Carnegie Mellon University, (May 1988)

\bibitem[Hesiod88]{Hesiod88} S. P. Dyer, ``The Hesiod Name Server,'' in
{\em Usenix Conference Proceedings}, (Winter 1988)

\bibitem[ECMA88]{ECMA88} ``Standard ECMA - Document Print Service Description
and Print Access Protocol Specification,'' Preliminary Draft, European Computer
Manufacturers Association, Group TC35-TG5, (September 1988).

\bibitem[PdTeam88]{PdTeam88} Handspicker, et al. {\em The Athena Pd Design
Document} MIT Project Athena, (September 1988)

\bibitem[HRPC88]{HRPC88} J. Sanislo, ``An RPC/LWP System for Interconnecting
Heterogeneous Systems,'' in
{\em Usenix Conference Proceedings}, (Winter 1988)

\bibitem[SMS88]{SMS88} M. A. Rosenstein, D. E. Geer, Jr., P. J. Levine,
``The Athena Service Management System,'' in
{\em Usenix Conference Proceedings}, (Winter 1988)

\bibitem[Kerberos88]{Kerberos88} J. G. Steiner, C. Neuman, J. I. Schiller,
``Kerberos: An Authentication Service for Open Network Systems,'' in
{\em Usenix Conference Proceedings}, (Winter 1988)

\bibitem[Zephyr88]{Zephyr88} T. DellaFerra, {\em et al.}, ``The Zephyr
Notification System,'' in {\em Usenix Conference Proceedings}, (Winter 1988)

\bibitem[Apollo87]{Apollo87} T. H. Dineen, P. J. Leach, N. W. Mishkin,
 J. N. Pato, and G. L. Wyatt, ``The Network Computing Architecture and
System: An Environment for Developing Distributed Applications,'' in
{\em Usenix Conference Proceedings}, (June 1987)

\end{thebibliography}
\end{document}






