Click for next page ( 282

The National Academies of Sciences, Engineering, and Medicine
500 Fifth St. N.W. | Washington, D.C. 20001

Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement

Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 281
E Trends in Software Software is critical for harnessing processing and communication technology. But producing software is difficult, labor-intensive, and time- consuming. Because of this, the trend in industry which is expected to continue has been to develop and embrace technologies that reduce the amount of new programming, hence reduce the costs, involved in devel- oping any software system. NISs, which typically involve large and com- plex software, are acutely affected by this trend. Perhaps the most visible example of the trend to avoid programming functionality from scratch is the increased use of commercial off-the-shelf (COTS) software (systems, subsystems, and libraries of components). Through the implementation of higher-level abstractions and services, specialized skills and knowledge of a few expert developers are lever- aged across a large number of systems, with the following results: The COTS software might encapsulate complicated services that would be difficult, costly, or risky to build, thereby freeing programmers to work on other, perhaps easier, tasks. The COTS software might implement a user interface, thereby ensuring a consistent "look and feel" over sets of independently devel- oped applications. The COTS software might hide lower-level system details, thereby enabling portability of applications across platforms that differ in con- figuration, operating system, or hardware. Further leverage can be achieved by using software tools (sometimes called "Wizards") that allow developers to adapt and customize COTS 281

OCR for page 281
282 APPENDIX E software without mastering the internals of that software. And scripting languages (Ousterhout, 1998), by being typeless and providing program- ming features such as high-level abstractions for programming graphical user interfaces (GUIs) and network input-output, assume increasing im- portance in this world where systems are built by "gluing together" exist- ing software. Middleware, infrastructure for creating client-server applications, has made significant inroads into the commercial and enterprise software sectors. Leading vendors such as SAP, Oracle, Baan, and PeopleSoft- are now aggressively directing their efforts toward exploiting the capa- bilities of global computer networks, like the Internet, while at the same time shielding users of their systems from the complexity of distributed systems. An emphasis on interoperability not only enables the intercon- nection of computing systems within a company, but also increasingly is fostering the interconnection of computing systems at different compa- nies. Once business partners link their computing systems, messages on networks can replace paper as the means by which business is transacted, and new operating modes, such as just-in-time manufacturing, are facili- tated because transactions can be initiated automatically and completed virtually instantaneously. Another way that software developers can avoid writing code from scratch is to exploit the growing collection of tools for transforming high- level descriptions into actual code. Tools along these lines exist today to implement network communications software for client-server distrib- uted systems, databases, and spreadsheets tailored to the needs of some application at hand, and for window-based or forms-based user inter- faces. In some cases, the tools output program skeletons, which are then decorated with programmer-provided application-specific routines. In other cases, the tools output self-contained modules or subsystems, which are then integrated into the application being developed. Software systems in general, and NISs in particular, once fielded, invariably come under pressure to evolve. Needs change, bringing de- mands for new functionality, and technology changes, rendering obsolete hardware and software platforms. Until recently, the sole solution had been for software developers to periodically issue new releases of their systems. Evolution of a software system was limited to whatever changes a developer implemented in each new release. The result was far from ideal. Users had little control over whether and when their new needs would be addressed; software developers, having limited resources, had difficulty keeping their systems attractive in an expanding market. Extensible software system architectures allow program code to be incorporated into a system after it has been deployed and often even after it is executing. With extensible architectures, new functionality that can

OCR for page 281
APPENDIX E 283 be coded as extensions need not await a new release. Users clearly benefit from the approach, because extensibility empowers them to evolve a system's functionality in directions they desire. And the system's devel- opers benefit by leveraging others' programming efforts: the market for an extensible system now expands with every extension that anyone implements. There is thus a strong incentive to design and deploy systems that are broadly extensible. Today, Web browsers support extensibility through their "helper applications," which enable the browser to display new forms of content (e.g., video, audio, graphics); extensible operating sys- tems, like Microsoft's Windows NT, allow new types of objects and han- dlers for those objects to be installed in a running system. The next logical step, a topic of current research (e.g., Bershad et al., 1995; Ford et al., 1997; Hawblitzel et al., 1998; Kaashoek et al., 1997; Seltzer et al., 1996), is placing support for extensibility at the very lowest levels of the operating system, as this would give the largest scope for extension. Much of that work is concerned with trade-offs between efficiency and protection, revisiting problems studied by the operating systems community in the 1970s. The ultimate form of software system extensibility is mobile code- programs that move from one processor to another in a network of com- puters. When mobile code is supported, a program unbidden can ar- rive at a host processor and start executing, thereby extending or altering the functionality of that host's software. Although the idea dates back to the early days of the ARPANET (Rulifson, 1969), only recently has it been attracting serious attention as a general-purpose programming paradigm. The now widely available Java programming notation supports a re- stricted form of code mobility, as do Microsoft's ActiveX controls. Two technical reasons are usually offered to argue that mobile code is attractive for programming distributed systems. First, the use of mobile code allows communications bandwidth to be conserved and specialized computing engines to be efficiently exploited: a computation can move to a site where data are stored or where specialized computing hardware exists, process raw data there, and finally move on to another site, carry- ing only some relevant subset of what has been processed. Second, with mobile code, efficient and flexible server interfaces be- come practical. Instead of invoking a high-level server operation across a network, a computation can move to the processor where that server is executing and invoke server operations using (local) procedure calls. Since the overhead of local calls is low, there is less overhead to amortize Viruses and the Postscript document description language are both instances of mobile code developed for more specialized applications.

OCR for page 281
284 APPENDIX E per server-operation invocation. It therefore becomes feasible for server interfaces to offer shorter, more primitive operations and for sequences of these operations to be invoked to accomplish a task. Thus, the mobile code dynamically defines its own high-level server operations high-level operations that can be both efficient and well suited for the task at hand. Besides these technical arguments, mobile code also provides an at- tractive architecture for the distribution of software and for system con- figuration management. Today, for example, PC software is often in- stalled and upgraded by customers downloading files over the Internet. The logical next step is an architecture where performing an upgrade does not require an overt action by the customer but instead can be insti- gated by the producer of that software. Mobile code supports just that architecture. Push replaces pull, freeing users from a system manage- ment task. But using mobile code in this manner relinquishes control in a way that affects trustworthiness. The approach also deprives the system administrator of control over the timing of software upgrades and con- figuration management changes. Cautious administrators have long re- frained from making system changes during crucial projects; a system that changes itself might be less stable at such times. REFERENCES Bershad, Brian N., Stefan Savage, Przemslaw Pardyak, Emin Sirer, Craig Chambers, Marc E. Fiuczynski, David Becker, and Susan Eggers. 1995. "Extensibility, Safety and Per- formance in the SPIN Operating System," pp. 267-284 in Proceeedings of the 15th ACM Symposium on Operating Systems Principles. New York: ACM Press. Ford, Bryan, Godmar Back, Greg Benson, Jay Lepreau, Albert Lin, and Olin Shivers. 1997. "The Flux OSKit: A Substrate for Kernel and Language Research," pp. 31-51 in Pro- ceedings of the 16th ACM Symposium on Operating Systems Principles. New York: ACM Press. Hawblitzel, Chris, Chi-Chao Chang, Grzegorz Czajkowski, Deyu Hu, and Thorsten von Eicken. 1998. "Implementing Multiple Protection Domains in Java," pp. 259-290 in Proceedings of the USENIX 1998 Annual Technical Conference, New Orleans, Louisiana. Berkeley, CA: USENIX Association. Kaashoek, M. Frans, Dawson R. Engler, Gregory R. Ganger, Hector M. Briceno, Russell Hunt, David Mazieres, Thomas Pinckney, Robert Grimm, John Jannotti, and Kenneth Mackenzie. 1997. "Application Performance and Flexibility on Exokernel Systems," pp. 52-65 in Proceedings of the 16th ACM Symposium on Operating Systems Principles. New York: ACM Press. Ousterhout, John K. 1998. "Scripting: Higher-level Programming for the 21st Century," IEEE Computer, 31~3~:23-30. Rulifson,J. 1969. Decode-Encode Language (DEL). RFC 5. June 2. Seltzer, Margo I., Yasuhiro Endo, Christopher Small, and Keith A. Smith. 1996. "Dealing with Disaster: Surviving Misbehaved Kernel Extensions," pp.213-228 in Proceedings of the Second Symposium on Operating Systems Design and Implementation (OSDI '96), Seattle, Washington. Berkeley, CA: USENIX Association.