|
Items in cart [0] |
Questions? Call 888-624-8373 |
| Copyright © 2009. 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 282
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 283
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 284
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.
Representative terms from entire chapter:
software developers
