Trust in Cyberspace
Committee on Information Systems Trustworthiness, National Research Council (1999) 352 pages   6 x 9

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 developing any software system. NISs, which typically involve large and complex 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 leveraged 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 developed applications.

• The COTS software might hide lower-level system details, thereby enabling portability of applications across platforms that differ in configuration, operating system, or hardware.

Further leverage can be achieved by using software tools (sometimes called "Wizards") that allow developers to adapt and customize COTS

282 Appendix E

software without mastering the internals of that software. And scripting languages (Ousterhout, 1998), by being typeless and providing programming features such as high-level abstractions for programming graphical user interfaces (GUIs) and network input-output, assume increasing importance in this world where systems are built by "gluing together" existing 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 capabilities 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 interconnection of computing systems within a company, but also increasingly is fostering the interconnection of computing systems at different companies. 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 facilitated 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 distributed systems, databases, and spreadsheets tailored to the needs of some application at hand, and for window-based or forms-based user interfaces. 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 demands 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

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 developers 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 systems, like Microsoft's Windows NT, allow new types of objects and handlers 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 computers. When mobile code is supported, a program—unbidden—can arrive 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 restricted 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, carrying only some relevant subset of what has been processed.

Second, with mobile code, efficient and flexible server interfaces become 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.

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 attractive architecture for the distribution of software and for system configuration management. Today, for example, PC software is often installed 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 instigated by the producer of that software. Mobile code supports just that architecture. Push replaces pull, freeing users from a system management 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 configuration management changes. Cautious administrators have long refrained 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 Performance 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 Proceedings 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.