Saturday, October 31, 1998 4:17:14 PM Message From: dl@altair.cs.oswego.edu,.Internet Subject: Re: WISR'9 Position Paper To: Larry Latour Cc: Here's the latex. A couple of .bib entries are at the bottom. Please tell me if any problems! %%%%%% TEMPLATE.TEX for WISR'93, version 1.2, 4/22/93 %%%%%% %%%%%% Updated by Jeffrey S. Poulin, May 1993 %%%%%% %%%%%% Updated by Larry Latour, March, 1995 \documentstyle[11pt]{article} % Standard Spacing for WISR - do not change!! % % Page dimensions. % \oddsidemargin 0.26in % Leave enough for binding margin \evensidemargin 0.26in % \topmargin -1.00in % (adjusted for printer bias) \headheight .00in % (no headers) \headsep .75in % (top margin + headers + skip) \footheight 12.0pt % ??? (seems to work ok) \footskip 75.0pt % ??? ( " " ) \textheight 9.425in % (instructions: 9 1/8" min, 9 7/16" max) \textwidth 6.5in % % % Paragraph changes. % \parindent=0pt \parskip=10pt % % can make the title box even smaller % \def\@maketitle{\vbox to 2.6in{\hsize\textwidth \linewidth\hsize \vfil \centering {\large \@title \par} \vskip 2em {\normalsize \begin{tabular}[t]{c}\@author \end{tabular}\par} \vfil} } \begin{document} \bibliographystyle{alpha} \title{My Position Paper} \author{Doug Lea\\ \\ State University of New York at Oswego\\ Oswego, NY 13126\\ Tel: (315) 341-2688\\ Fax: (315) 341-5424\\ Email: dl@cs.oswego.edu\\ } \date{} \maketitle \begin{abstract} Attempted reuse across concurrent, distributed, persistent, and/or secure components and systems all seem to hit similar snags surrounding larger policy spaces, greater complexity, limitations of black-boxes, context dependence, compositionality failures, and reflective design. \vspace{0.2in} \noindent {\bf Keywords:} Reuse, concurrency, distribution, persistence, security \vspace{0.2in} \noindent {\bf Workshop Goals:} Learning; networking; \vspace{0.2in} \noindent {\bf Working Groups:} Designs for or with reuse \end{abstract} \newpage \section{Background} Java (and arguably other languages and platforms) ``solve'' some of the easy reuse problems: \begin{description} \item[Packaging] Objects, classes, components, packages \item[Portability] Bytecodes, unicode, transports \item[Extensibility] Subclassing, interfaces, class loaders \item[Safety] Virtual machine, GC, verifiers \end{description} But this seems not to make reuse in most projects much easier. One reason for this is that just about every Java project involves one or more {\em aspects\/} \cite{kiczales97} of software design that become widespread when developers no longer have to wrestle so hard with the easy stuff: \begin{description} \item[Concurrency] Use of threads, locks, and monitors to support multiprocessing, and/or to improve availability in reactive systems. \item[Distribution] Use of RMI, CORBA, etc., to support fault tolerance, resource sharing, mobility, and communication in open systems. \item[Persistence] Use of serialization, JDBC, etc., to support versioning, recovery, and transactionality in systems in which object lifetimes exceed program lifetimes. \item[Security] Use of security managers, protection domains, and encryption to support privacy and commerce in ubiquitous computing systems. \end{description} \section{Position} Reuse of concurrent, distributed, persistent, and/or secure components faces challenges not seen for example in most UI toolkits, data structure libaries or spell-checker plug-ins. Reasons include: \begin{description} \item [Extended senses of correctness] The need for safety, liveness, fault-tolerance, auditability, recovery, and so on make components more difficult to specify, test, and reason about. \item [Large policy spaces] Each of these aspects introduces specification and design choices in places where no such choice exists in simpler systems: Optimistic or pessimistic?, Local or remote? Synchronous or asynchronous? Persistent or transient? Clear or encrypted? Support infractructures that accommodate all of the associated mechanisms create an unwieldy policy jungle. Those that do not become unusable. \item [Architectural constraints] TO avoid policly clashes, components cannot be build in isolation, but must observe compatibility constraints that are often phrased as architectural rules; for example those concerning locking or flow. These rules are often sub-optimal, even arbitrary, but must be fervently believed in anyway by developers. \item[Infiltration] The imposition of architectural constraints generates a slew of programmer obligations when building or adapting even the simplest parts. Policies and constraints inevitably alter nearly every line of code, and resist factoring and layering\cite{lea97}. Nearly every successful concurrent, distributed, persistent, and/or secure system was designed that way from the outset. \item[Compositionality failures] Many components are safe, live, recoverable, secure, mobile, and so on, only within particular sets of contexts, and thus may be composed only within those contexts. These problems are compounded when more than one of these aspects is involved. For example, when serializing objects that may engage in multiple threads. \item[Need for abstraction without transparency] Interfaces and the like must be abstracted out enough to manage complexity. Yet implementations cannot afford to be treated as pure black boxes. Eventually, someone else will need to get behind an abstraction, often as a result of a policy change or customization. Open source helps. \item[Verticality] Systems increasingly entail reflective, multilevel design in which objects at each level manipulate, manage, and coordinate lower-level ground objects as resources. Thread-objects interpret passive objects. Distributed server-objects pass around informational resources. Database-objects manage states of ground objects. Builder-objects create functional objects for later deployment. \end{description} \section{Comparison} Kiczales et al\cite{kiczales97} have introduced {\em Aspect-Oriented Programming} as a way to help separate out concerns such as those discussed here. They have created ``aspect languages'' and associated tools that allow developers to isolate those parts of programs that deal with, for example, concurrency control, and then weave them back together via pre-processing to generate full programs. This approach has some chance of improving the management of complexity during development, but does not yet deal with broader issues of reuse. \subsection{References} \bibliography{template} \section{Biography} {\bf Doug Lea} is a professor of Computer Science at the State University of New York at Oswego. He is author of the book ``Concurrent Programming in Java'', and co-author of the text ``Object-Oriented System Development''. He is the author of several widely used software packages, as well as articles and reports on object oriented software development including those on specification, design and implementation techniques, distributed object systems, and software reusability. \end{document} %%%%%% DL.BIB %%%%%% @Inproceedings(lea98, Key="Lea", Author="D. Lea", Title="{Design for Open System in Java}", BookTitle="{Coordination 98}", Year="1998", Editors="D. Garlan and D. Le Metayer", Publisher="Springer-Verlag") @InProceedings(kiczales97, Key="Kiczales", Author="G. Kiczales and J. Lamping and A. Mendhekar and C. Maeda, and C. Lopes and J. Loingtier and J. Irwin", Title="{Aspect-Oriented Programming}", Year="1997", BookTitle="{ECOOP 97}", Publisher="Springer-Verlag") X-SMTP-From: dl@altair.cs.oswego.edu X-SMTP-To: larry_latour@umit.maine.edu Received: from altair.cs.oswego.edu (altair.cs.oswego.edu [129.3.20.253]) by voyager.umeres.maine.edu with SMTP id MSGFQILN; Sat, 31 Oct 1998 20:21:55 GMT Received: from gee.oswego.edu by cs.oswego.edu (SMI-8.6/SMI-SVR4) id PAA27427; Sat, 31 Oct 1998 15:17:15 -0500 Received: (from dl@localhost) by gee.oswego.edu (8.8.8+Sun/8.8.8) id PAA13212; Sat, 31 Oct 1998 15:17:14 -0500 (EST) From: Doug Lea