第四章网络移动性（Chapter Four: Network Mobility）
一、网络移动性的必然
在PC时代来临之前，计算机界被大型机统治着。那时大型机通过分时系统来给多个终端提供服务。但是随着微处理器的发展，PC逐渐走上历史舞台。早期，PC 总是工作在一个封闭的孤岛上，软件也是工作在独立的PC上。但是很快，PC开始连接上了网络，并随之诞生了客户/服务器（client/server）软 件工作模式。客户/服务器模式最终发展为多层服务模型（N-tier），也就是所谓的分布式处理（distributed processing）。分布式处理推动了网络的发展，也让不同用户可以共享数据和信息。
虽然分布式计算模型要比大型机时代的集中计算模型要先进，但是它也带来了许多问题。最突出的就算是发布程序比较困难。在集中计算模型中，你只需要更新大型 机中的程序，那么所有终端用户都更新了；但是分布式计算模型中，你可能要同步所有PC中的程序的版本。虽然浏览器/服务器模型改进了这个缺点，可是缺乏表 现的网页，很难达到客户的要求。
而Java的到来带了一种全新的计算模型（网络移动性），在这种计算模型中程序通过网络自动发布。当用户需要运行程序时，网络服务器会将程序发给最终用户。
二、一个新的软件范式
PC功能的日益强大和花费的日益减少推动由大型机的集中计算模型向分布式计算模型转换，而随着网络带宽的日益强大和化肥的日益减少有将推动分布式计算模型 向网络计算模型转换。在新的计算模型中，当用户执行程序时，发给最终用户的是程序本身和数据，这就结合被称为“内容”（content）。
在分布式计算模型中，如果新版本的程序中存在一个严重的错误，最终用户可以拒绝更新程序，继续使用旧的版本。但是在网络计算模型中就不可以，因为所有程序 的发布自动完成，用户不能够控制程序的版本。解决方法是：提供多个版本的“content services”。至少提供两个版本的程序，一个稳定版（released branch）、一个测试版（beta branch），让最终用户只有选择自己的程序版本，这样可以使自己程序更健壮。
当提供多种“content services”，最终用户就要担心程序的版本。最终用户必须要了解各个版本的信息，已决定是否要更新版本。如果最终用户不能自己控制程序的版本，他们 可能会觉得自己变成了“程序的奴隶”。很多自动更新的“content services”会表现两种特性：强大的功能和简单的用户界面。就像烤面包机，当你碰到一个全新的烤面包机的时候不去想去读他的使用手册，而是期待直接 将面包从顶部放入然后打开开关，等待面包烤好。同样，很多“content services”也提供了强大的功能和简单的用户界面。
一个“content services”的好例子就是网页。如果你看Html的源文件，你会发现他和其他的程序没有什么区别，而当你通过浏览器来看却发现了美丽的网页。这样程 序和数据的界限开始模糊，当他浏览网页时，他们不会考虑网页是否更新，而仅仅和浏览相同的网站地址。
在软件领域中新的网络计算模型，不可能完全替代旧的计算模型，他只能接管其中的一部分。软件表现的越来越像工具，最终用户不用再去安装、更新，程序将会和数据一起通过网络传输，软件的发布将自动化。
三、Java技术体系对网络计算的支持
Java技术体系对平台独立性和安全性的执行都是对网络计算模型的支持，虽然他们不是网络计算必须的，但是平台独立性和安全性帮助网络计算更具可用性。Java技术体系对网络计算的直接支持就是尽量缩短程序的下载时间。
类文件的紧凑的排列，它使得程序的传输时间更短。类文件中每一个操作码仅占用一个字节。Java类文件的紧凑性还表现在，所有的类文件都不会被优化，所有的优化都交给了Java虚拟机。
动 态连接（dynamic linking），使得Java程序在运行时只加载需要使用的类，这就减轻了程序网络传输的负担，不加载的类可以不用下载。动态扩展（dynamic extension），使得程序可以在运行的时候再去加载新的类，可以建起用户等待程序下在的时间。
在Java技术体系之外，Java还提供了JAR（Java ARchive）来压缩和集中传输类文件。
