The previous two chapters discussed how Java's architecture deals with the two major challenges
presented to software developers by a networked computing environment. Platform independence deals with
the challenge that many different kinds of computers and devices are usually connected to the same network.
The security model deals with the challenge that networks represent a convenient way to transmit viruses
and other forms of malicious or buggy code. This chapter describes not how Java's architecture deals with a
challenge, but how it seizes an opportunity made possible by the network.

One of the fundamental reasons Java is a useful tool for networked software environments is that Java's
architecture enables the network mobility of software. In fact, it was primarily this aspect of Java technology
that was considered by many in the software industry to represent a paradigm shift. This chapter examines
the nature of this new paradigm of network-mobile software, and how Java's architecture makes it possible.

Why Network Mobility?

Prior to the advent of the personal computer, the dominant computing model was the large mainframe
computer serving multiple users. By time-sharing, a mainframe computer divided its attention among several
users, who logged onto the mainframe at dumb terminals. Software applications were stored on disks
attached to the mainframe computer, allowing multiple users to share the same applications while they
shared the same CPU. A drawback of this model was that if one user ran a CPU-intensive job, all other users
would experience degraded performance.

The appearance of the microprocessor led to the proliferation of the personal computer. This change in
the hardware status quo changed the software paradigm as well. Rather than sharing software applications
stored at a mainframe computer, individual users had individual copies of software applications stored at
each personal computer. Because each user ran software on a dedicated CPU, this new model of computing
addressed the difficulties of dividing CPU-time among many users attempting to share one mainframe CPU.

Initially, personal computers operated as unconnected islands of computing. The dominant software
model was of isolated executables running on isolated personal computers. But soon, personal computers
began to be connected to networks. Because a personal computer gave its user undivided attention, it
addressed the CPU-time sharing difficulties of mainframes. But unless personal computers were connected
to a network, they couldn't replicate the mainframe's ability to let multiple users view and manipulate a
central repository of data.

As personal computers connected to networks became the norm, another software model began to
increase in importance: client/server. The client/server model divided work between two processes running
on two different computers: a client process ran on the end-user's personal computer, and a server process
ran on some other computer hooked to the same network. The client and server processes communicated
with one another by sending data back and forth across the network. The server process often simply
accepted data query commands from clients across the network, retrieved the requested data from a central
database, and sent the retrieved data back across the network to the client. Upon receiving the data, the
client processed, displayed, and allowed the user to manipulate the data. This model allowed users of
personal computers to view and manipulate data stored at a central repository, while not forcing them to
share a central CPU for all of the processing of that data. Users did share the CPU running the server
process, but to the extent that data processing was performed by the clients, the burden on the central CPU
hosting the server process was lessened.

The client/server architecture was soon extended to include more than two processes. The original
client/server model began to be called 2-tier client/server, to indicate two processes: one client and one
server. More elaborate architectures were called 3-tier, to indicate three processes, 4-tier, to indicate four
processes, or N-tier, to indicate people were getting tired of counting processes. Eventually, as more
processes became involved, the distinction between client and server blurred, and people just started using
the term distributed processing to encompass all of these schemes.

The distributed processing model leveraged the network and the proliferation of processors by dividing
processing work loads among many processors while allowing those processors to share data. Although this
model had many advantages over the mainframe model, there was one notable disadvantage: distributed
processing systems were more difficult to administer than mainframe systems. On mainframe systems,
software applications were stored on a disk attached to the mainframe. Even though an application could
serve many users, it only needed to be installed and maintained in one place. When an application was
upgraded, all users got the new version the next time they logged on and started the application. By
contrast, the software executables for different components of a distributed processing system were usually
stored on many different disks. In a client/server architecture, for example, each computer that hosted a
client process usually had its own copy of the client software stored on its local disk. As a result, a system
administrator had to install and maintain the various components of a distributed software system in many
different places. When a software component was upgraded, the system administrator had to physically
upgrade each copy of the component on each computer that hosted it. As a result, system administration was
more difficult for the distributed processing model than for the mainframe model.

The arrival of Java, with an architecture that enabled the network-mobility of software, heralded yet
another model for computing. Building on the prevailing distributed processing model, the new model added
the automatic delivery of software across networks to computers that ran the software. This addressed the
difficulties involved in system administration of distributed processing systems. For example, in a
client/server system, client software could be stored at one central computer attached to the network.
Whenever an end-user needed to use the client software, the binary executable would be sent from the
central computer across the network to the end-user's computer, where the software would run.

So network-mobility of software represented another step in the evolution of the computing model. In
particular, it addressed the difficulty of administering a distributed processing system. It simplified the job of
distributing any software that was to be used on more than one CPU. It allowed data to be delivered
together with the software that knows how to manipulate or display the data. Because code was sent along
with data, end-users would always have the most up-to-date version of the code. Thus, because of network-
mobility, software can be administered from a central computer, reminiscent of the mainframe model, but
processing can still be distributed among many CPUs.