254 lines
54 KiB
TeX
Executable File
254 lines
54 KiB
TeX
Executable File
% !TEX root = main.tex
|
||
|
||
\section{系统软件概述}
|
||
系统软件是驱动下层计算资源有效运转、为上层应用提供共性支撑的软件，主要包括操作系统、编译系统、中间件和数据库管理系统。其中，操作系统负责管理计算系统软硬件资源、操纵程序运行，为应用软件提供公用支撑；编译系统（又称编译器）负责将源语言编写的源程序翻译为等价的可运行目标程序；中间件将系统软件的概念扩展到网络环境，为分布式应用软件部署、运行和管理提供支撑；数据库管理系统旨在统一管理和维护数据库中的数据，是组织、存储、存取、控制和维护数据的软件。
|
||
|
||
与面向特定领域、解决特定问题的应用软件不同，系统软件是运行于计算“系统”层面上的软件。此处的“系统”有两层含义：
|
||
|
||
\begin{itemize}
|
||
\item 系统软件将计算系统的概念从硬件扩展到了软件层面。通过将底层硬件资源进行适当地抽象和封装，系统软件为上层应用提供了一个软件平台（也可以称为“虚拟机”），使得上层应用软件可以方便使用各类资源能力，无需关注底层细节。这一平台承担了共性的资源管理功能，屏蔽了异构性和细节，使得计算系统易于使用、易于编程。系统软件作为平台化基础设施，同时也封装了许多共性问题的解决方案，以避免应用软件去“重复发明轮子”。
|
||
\item 系统软件是驱动计算系统有效运转的控制器/协调者。系统软件一方面与计算系统中各类硬件资源直接交互，管理、调度和使用这些资源，使得之可以高效协同；另一方面系统软件也直接操纵管控上层应用的运行，从而达到提高程序装载和调度的自动化程度、提高资源利用率等目标。例如，操作系统可以通过批处理、分时共享等方法来实现计算系统作业任务切换，因此早期也被称为“监督例程”（Supervisory Program）或“控制程序”[1]。
|
||
\end{itemize}
|
||
|
||
系统软件并不是与计算机一起诞生的，它的出现有内因和外因两个方面。早期的计算机（如ENIAC）编程采用接线和开关等手工操作方式，并没有系统软件的概念。即使在存储程序计算机出现之后，系统软件也并未马上出现，应用直接在裸机上运行。但是，将应用与硬件祼机直接绑定，无论是编程难度、应用管理/切换效率还是底层资源利用率都十分低下。特别是早期CPU速度和I/O速度之间的巨大差异，基于时分复用的“虚拟化”成为客观需求，推动了系统软件、尤其是操作系统的快速发展。系统软件出现的外因则是软件复杂性增长所导致的分工细化，特别是上个世纪50-60年代，面向底层硬件资源的系统程序设计（System Programming）和面向领域的应用程序设计（Application Programming）的分化，以及系统程序员和应用程序员的分工，直接推动了系统软件这一概念的广泛接受。
|
||
|
||
\section{操作系统}
|
||
从功能定位的角度而言，操作系统是负责管理硬件资源、控制程序运行、改善人机界面和为应用提供支持的系统软件，是计算机软件生态链的基础核心。在一个计算系统中，操作系统向下是最靠近硬件的一层软件，它通过调用硬件驱动程序、固件等方式实现对硬件的管理；向上屏蔽硬件细节，为应用软件提供功能更为完善、灵活可编程的“虚拟机”，并通过事件循环等实现对各类应用软件的运行管理。因此，操作系统兼具“承上启下”和“管家”两类作用。由于操作系统的特殊地位，其发展与上层应用需求和底层硬件形态的演化都有着密切联系。从最初与硬件和应用场景高度绑定，到之后逐渐独立于硬件，操作系统向上提供的服务越来越多、向下针对硬件的抽象程度越来越高，其内涵和外延不断拓宽，并在积累一段时间后产生质变，呈现出主机计算、个人计算、互联网和移动计算等明显阶段性特点（图\ref{fig:3-1}）。
|
||
|
||
\begin{figure}[htbp]
|
||
\centering
|
||
\includegraphics[width=0.80\textwidth]{fig1-3/3-1.png}
|
||
\caption{操作系统发展历程
|
||
\label{fig:3-1}}
|
||
\end{figure}
|
||
|
||
\subsection{操作系统的出现（20世纪50年代）}
|
||
早期的存储程序计算机并没有操作系统，需由用户或专门操作人员（Operator）管理计算任务，包括装入打孔卡片或纸带、通过包含开关和指示灯的控制面板来了解状态、在出错时进行必要干预等。这一方式可以满足早期少量科学计算的需要。但是随着计算机应用领域从传统科学计算领域向国防、政府、商业等通用领域拓展，计算任务及相关的数据量迅速增长，手工管理成为了制约计算机利用效率的瓶颈问题。用软件来代替操作人员实现计算任务自动管理（包括载入和执行），这是操作系统最早出现的动因之一，并直接催生了第一代的批处理操作系统。由于其强调替代人进行监管，这一时期的操作系统雏形多被冠以“控制程序/例程”（Control Program/Routine）、“管程”（Monitor）、“监督例程”（Supervisory Routine）等名称。典型实例是通用汽车与北美航空于1956年基于IBM 704所开发的GM-NAA IO系统[3]，其核心的管程可以从磁带上自动顺序读入和批量执行应用程序。该系统通常被认为是第一个成熟的商用操作系统，在20世纪50年代末被移植到多个巨型机上。
|
||
|
||
操作系统出现的另一个背景是20世纪 50年代计算机技术的革新，特别是磁芯内存、磁带等大容量高速存储技术的应用，以及从早期打孔卡片发展而来的“文件”等抽象的出现，使得专业化的大型软件成为可能，软件开发作为一个独立行业开始从硬件设计制造中分离出来。人们针对“如何提高软件开发的效率”这一问题进行初步探索，催生了Fortran等高级语言的出现，也在这一过程中积累了大量工具、编译器、可重用例程和库等。由于软件开发与运行密切相关，因此在这一时期，许多操作系统与编程系统并未严格区分，典型实例包括MIT的CSSR（Comprehensive System of Service Routines）[4]、ERA 1103（UNIVAC 1103A）计算机所配备的“集成计算系统”[5]等。这类系统通常具备运行时批处理功能，但更强调对开发的支持，其核心是一系列可重用库和辅助工具（Utility Tool）。这也是今天操作系统“沉淀共性问题解决方案”能力的来源。
|
||
|
||
虽然第一代操作系统以批处理模式为主，但由于指挥控制、工业自动化等领域对计算机的迫切需求，早期人们即在实时（或者至少能够在线处理的）操作系统方面开展了实践。典型案例是上个世纪50年代美国军方半自动地面防空系统（Semi Automatic Ground Environment，SAGE）项目，这一系统通过多个主机实现了雷达数据的实时汇聚、处理和态势生成，其操作系统能够实现计算和I/O操作过程的交叠，在部份文献中被认为是首个实时操作系统。
|
||
|
||
\subsection{主机计算时代的操作系统（50年代-70年代）}
|
||
在大型主机时代，操作系统的发展主要围绕提高计算资源的利用率和提高操作系统的抽象能力两条主线展开：
|
||
|
||
\begin{enumerate}[(1)]
|
||
\item 提高计算资源的利用率
|
||
|
||
早期的操作系统采用单道批处理作业模型，此处的“单道”是指能够批量运行任务、减少了手工切换开销，但是在执行过程中只有单个程序在排他运行。由于CPU时间被大量浪费在等待I/O数据的过程中，资源利用率仍然相当低。1956年，UNIVAC 1103A计算机引入了硬件中断（Interrupt）的概念，为多个应用分时运行奠定了基础。此后，软件技术（如任务调度技术）和硬件技术（如内存保护机制）的协同发展，使得多道批处理、分时系统等支持多道程序设计（Multiprogramming）的操作系统开始出现。
|
||
|
||
\begin{itemize}
|
||
\item 多道批处理是对单道批处理的扩展，允许单一计算机同时载入多个作业，使之可以以恰当的调度策略交替占用CPU，从而提高资源利用率，其典型案例是20世纪60年代由荷兰计算机科学家Dijkstra所领导研发、基于层次化架构的THE操作系统[6]。
|
||
\item 分时系统的思想则几乎与操作系统同时出现，其目标是“通过分时共享，使得一台大的计算机能够像多台小型计算机一样使用” [7]。从1961年的首个MIT CTSS分时操作系统[8]开始，此类系统均通过CPU时间片的划分来支持多个终端用户
|
||
\end{itemize}
|
||
|
||
\item 提高操作系统的抽象能力
|
||
|
||
在这一阶段，一系列重要的、今天所熟知的操作系统抽象（及其实现机理）被确立。其中，20世纪50年代“文件”已经被用于描述存储于外部存储器（如磁鼓）中的数据单元，60年代初文件系统已经成为许多操作系统的基本组件，并在Unix操作系统中扩展为对所有I/O设备能力的抽象；内存分页（段）和虚拟内存于1959年在英国曼彻斯特大学Atlas计算机原型系统中首先实现，并很快出现在60年代的商用计算机中，成为对内存资源的基本使用方式；多道程序、特别是分时共享理念的发展，推动了进程和线程的概念被提出，二者今天仍是CPU资源调度和使用的基本单位。上述抽象奠定了现代操作系统内核设计与实现的基础，也逐渐在软件领域形成了对“操作系统应当如何抽象计算机硬件能力”这一问题的共识。
|
||
|
||
与操作抽象能力提升相关的一个里程碑事件是“兼容”概念的提出。早期操作系统往往绑定到特定机型甚至特定应用场景，许多操作系统是计算机最终用户所开发或定制的。进入20世纪60年代，集成电路的发明促使计算技术迅速向工业、商业、教育等各个领域渗透，与硬件和场景高度绑定的操作系统已经无法满足日益增长的需求。在这一背景下，IBM于1961年启动OS/360研制计划[11]，旨在为System/360系列计算机开发了统一的批处理操作系统，为应用软件提供标准化、与特定机型和应用场景解耦的运行环境。其后，1968年发布的CP-67操作系统和1972年发布VM/370操作系统扩展了分时共享的思想，首次提供了成熟的虚拟化能力[12]，并率先使用了今天被广泛接受的Hypervisor（虚拟机监视器）一词。“兼容”概念自此开始深入人心：操作系统与硬件和应用场景解耦，使得上层应用在任何时候都看到是一个标准化的、具有通用图灵机能力的“虚拟机”，而不同型号的硬件也通过操作系统的抽象封装，以一致的方式向上层应用提供其能力，这一思路直接推动了整个计算机软硬件生态链的快速发展。
|
||
|
||
\end{enumerate}
|
||
|
||
\subsection{计算机普及时代的操作系统（70年代-21世纪初）}
|
||
20世纪70年代集成电路技术的高速发展推动了微处理器的出现，使得计算技术由“旧时王谢堂前燕，飞入寻常百姓家”，具体表现为：一方面，个人计算机迅速普及，产品和技术快速发展，使得能“兼容”多种软硬件的操作系统成为主流，而且用户的非专业化使得图形用户界面成为主流操作系统的内嵌能力；另一方面，由于工业控制、航空航天、武器装备等领域微处理器的应用，嵌入和实时操作系统作为操作系统的一个分支开始登上历史舞台。此外，这一时期的开源操作系统对本领域后续发展产生了深远影响。
|
||
|
||
\begin{enumerate}[(1)]
|
||
\item 个人计算机操作系统
|
||
|
||
70年代中期Intel发布8080 CPU以后，Digital Research发布了最早的微型计算机操作系统CP/M-80，它由基本输入输出系统（Basic Input/Output System，BIOS）、基本磁盘操作系统和控制台命令处理程序组成。其中，基本输入输出系统的引入，实现了操作系统其它模块与低层具体硬件的解耦，显著提高了操作系统的适用性和上层应用的可移植性。这种操作系统与具体硬件解耦的思想拓展了System/360大型机时代所提出的“兼容”概念，被后来的微软MS-DOS（Microsoft Disk Operating System）等操作系统所延续，直接为个人计算机软硬件生态链的快速发展奠定了基础。
|
||
|
||
在个人计算时代，操作系统的另一个重要进展是图形用户界面的加入。早在1973年，Xerox即推出了支持可视化操作的Alto计算机，并于1981年发布了集成完整图形化桌面的操作系统Xerox 8010 Star；1984年Apple发布了具有图形用户界面的个人计算机Lisa；1985年微软公司发布了Windows系列操作系统。图形用户界面是计算技术普及的必然结果：由于个人计算机面对的不是专业用户，易用性成为了操作系统的瓶颈问题，因此基于窗口和鼠标的直观操作取代了繁琐晦涩的命令行界面。
|
||
|
||
此外，90年代初Linux操作系统以开源软件形式出现，对操作系统技术、产品、产业乃至于相关法律政策、社会文化等都产生了重大影响。开源作为一种群智汇聚、群体协作的有效方式，一方面可以有效推动操作系统产品的发展，应对操作系统自身的复杂性；另一方面一个操作系统能否被广泛接受也取决于其生态链的完善程度，而开源则为生态链构建提供了一种基于众包的新模式。
|
||
|
||
\item 嵌入实时操作系统
|
||
|
||
20世纪70年代单片机出现是计算机发展史上的重要事件之一，它使得在各类设备中“嵌入”计算机成为可能，可被视为最早的“信息物理融合”（Cyber-Physical）尝试。针对嵌入式设备，80年代现代意义上强调轻量级、具有实时处理能力的嵌入实时操作系统开始出现，此类操作系统需要在资源受限环境下运行，并且由于其与物理世界直接交互，往往需要提供对实时性（时间可预测性）的保证。首个商业嵌入式实时操作系统内核VTRX32于1981年发布，后续涌现出了vxWorks、uCOS、QNX等一系列被广泛应用的嵌入实时操作系统产品。
|
||
|
||
\end{enumerate}
|
||
|
||
\subsection{互联网和移动计算时代的操作系统（21世纪初-）}
|
||
进入21世纪，新型计算模式不断出现，计算技术表现出向两极发展的趋势：一方面以“云”为核心，强调通过资源集约化和按需服务方式，推动信息技术实现社会化和专业化；另一方面以“端”为核心，强调信息技术的普适化，使得计算服务如同水、电、空气一样随时随地可以获取而又不可见。需要指出的是，“云”和“端”二者并非割裂的，而是优势互补，正在通过“云+端”等形式共同推动着计算技术的新一轮革命。
|
||
|
||
\begin{enumerate}[(1)]
|
||
\item 云计算操作系统
|
||
|
||
近年来，作为服务化思想的集大成者，云计算模式被广泛接受，云计算操作系统的概念开始出现。云计算操作系统是指架构于云计算数据中心各类硬件资源之上，实现“基础设施即服务”、“平台即服务”[13]等目标的系统软件，其典型代表包括Google AppEngine、Microsoft Azure等。此类操作系统具有如下一些特征：
|
||
|
||
\begin{itemize}
|
||
\item 在资源的管控方面，此类操作系统的核心是大型主机时代即已出现的虚拟化技术，但将其应用场景拓展到了数据中心甚至多数据中心级别的，通过虚拟化实现海量计算、网络、存储资源的细粒度管理，进而实现资源的有效聚合和弹性扩展。例如，互联网虚拟计算环境 iVCE[14]通过资源的“自主协同、按需聚合”，将静态统一视图的资源组织模式扩展为相对稳定视图、按需可伸缩的资源组织模式，从而实现面向互联网计算的高效管控。
|
||
\item 在应用软件的执行管控维度上，此类操作系统面向云服务这类大规模分布计算软件，提供了任务调度与执行、负载均衡、安全管控、在线监控和升级演化、分布式数据存储访问等一系列基础设施和相应能力。这些能力以的服务化方式提供，用户无需像传统系统软件那样自行安装、部署和维护。部分“平台即服务”基础设施还内建了编译系统和调测试环境，支持云端开发和编译构建。
|
||
\item 在自身生命周期方面，此类操作系统需要 7×24小时持续提供基础服务，是支撑整个信息空间持续运行的核心基础设施。其突出表现为一旦发生故障，会产生较大的社会经济影响。例如，文献[15]指出如果一个主要的云平台宕机3－6天，美国经济会产生 30亿－150亿美元的损失。
|
||
\end{itemize}
|
||
|
||
\item 智能终端操作系统
|
||
|
||
移动操作系统是“端”操作系统的典型代表。近年来，移动计算、特别是智能手机的出现，推动了移动操作系统的快速发展，典型实例包括Google的Android和Apple的iOS。此类操作系统在架构上与个人计算机操作系统并无本质区别，但更强调对移动和手持环境的支持，包括移动网络接入、各类传感器数据获取、电池管理、触摸屏交互等。与个人计算时代类似，操作系统在移动计算软硬件生态链中同样具有核心基础地位，特别是操作系统内置应用商店的出现和广泛接受，在降低用户查找、获取和安装应用程序难度的同时，也形成了较完善的商业模型，极大推动了以操作系统为核心的软件生态链的成长。移动操作系统当前还表现出了与桌面系统一体化的发展趋势，通过统一桌面和移动操作系统及其生态，将有利于操作系统更好地发展与维护。例如，谷歌继移动操作系统Android和轻量级桌面操作系统ChromeOS之后，正在研制跨平台的Fuchsia操作系统。
|
||
|
||
近年来，以Android Things、Ubuntu Core、Mbed和华为“鸿蒙”等为代表的物联网操作系统正在成为操作系统领域新的热点。此类操作系统在嵌入式操作系统基础上，一方面强调对“连接”、以及建立在连接基础上的分布计算甚至“云-端”融合的支持，从而有力支撑“万物互联”的目标；另一方面强调对异构物理网设备能力的统一抽象，从而屏蔽物联网设备的碎片化特征，为提升物联网的可管理性和可维护性、构建物联网良好生态环境奠定基础
|
||
|
||
\end{enumerate}
|
||
|
||
\section{编译系统}
|
||
编译系统是将源语言（例如高级程序设计语言）编写的代码翻译为等价的、高效的、能被计算机或虚拟机执行的目标代码（例如机器语言）的系统软件。编译系统的诞生早于操作系统，但如前节所述，由于软件开发与运行的密切相关性，在计算机发展早期，通常并不严格区分操作系统（Operating System）和编程系统（Programming System），仅仅是后者更强调其对开发的支持，内置了编译能力、开发辅助工具和可重用例程/库等。随着程序设计语言的变迁、特别是高级语言的出现，编译系统逐渐成为系统软件的一个主要分支，其内涵和外延随语言和计算机体系结构的发展而不断扩展（图\ref{fig:3-2}）。
|
||
|
||
\begin{figure}[htbp]
|
||
\centering
|
||
\includegraphics[width=0.80\textwidth]{fig1-3/3-2.png}
|
||
\caption{编译系统发展历程
|
||
\label{fig:3-2}}
|
||
\end{figure}
|
||
作为机器体系结构抽象的符号化语言，汇编语言的目标是提高编程效率和质量。然而，计算机能读懂的只有机器指令，此时需要一个能够将汇编指令转换成机器指令的翻译程序。1947年伦敦大学伯贝克学院的Kathleen Booth为ARC2计算机开发了第一个汇编语言及其机器汇编器。之后不久，开始出现带有支持代码“库”的计算机，预先记录在打孔卡片和磁带上的支持代码库能够在装载器（Loader）的支持下与用户程序进行连接，从而支持输入输出等操作。这就是编译系统这种系统软件类型最早的雏形。
|
||
|
||
虽然汇编语言相对于机器语言提高了程序的可读性，但编写、阅读和理解汇编语言的难度依然较高。20世纪50年代初，葛丽丝·霍普在UNIVAC I上首次使用了“编译器”（Compiler）一词。在她所实现的编译器雏形中，磁带上的每段例程由一个数字代码标识，用户输入一组数字代码，来使得计算机依次加载这些例程。葛丽丝·霍普工作证明了高级语言（数字代码）向机器语言（磁带上例程中所包含机器指令序列）映射的可行性。在此基础上，更为激进的“自动编程”（Automatic Programming）的概念[16, 17]被提出，希望能够采用接近于人类自然语言的语言编写程序，依据这些程序自动生成可执行的机器代码，从而显著提高程序开发效率和质量、便于程序的理解阅读和维护。在这一思想的驱动下，上个世纪50年代出现了第一个高级程序设计语言——为IBM 704大型机设计的Fortran语言[18]。1957年发布的Fortran编译器则是第一个功能比较完备的高级程序语言编译器。它也是第一个具备优化能力的编译器，引入了循环优化、寄存器分配等技术，使编译器翻译的机器代码能够与当时人工编写的汇编程序性能相当。
|
||
|
||
\subsection{程序设计语言驱动的编译系统发展（60年代-90年代）}
|
||
在高级程序设计语言出现以后，程序设计方法学和程序设计语言飞速发展，诸如结构化程序设计、面向对象程序设计、函数式程序设计、逻辑程序设计等方法和语言百花齐放，直接推动了编译技术和编译系统的发展。
|
||
|
||
20世纪50年代末，COBOL（Common Business-Oriented Language）语言诞生[19]。与Fortran主要面向科学计算不同，COBOL是用于商务数据处理的语言，也是第一个跨平台的高级程序设计语言。1960年，由不同编译器编译的同一COBOL程序成功在UNIVAC II和RCA 501机上运行，表明了。70年代初，美国Bell实验室以开发了B语言和B语言编译器，并用B语言编写了第一个UNIX操作系统内核。在B语言基础上，Bell实验室经过进一步改进完善后发布了C语言及其编译器。
|
||
|
||
相对于Fortran和 C等命令式高级语言，面向对象语言也在这一时期得到发展。20世纪 60年代的SIMULA67语言[20]引入了类和对象的概念，被认为是世界上第一个面向对象语言。70年代出现的Smalltalk语言支持类的动态创建和修改。受到C和SIMULA67语言的影响，Bell实验室在八十年代开发了C++，随后开发了支持C++的Cfront编译器。20世纪90年代，随着C++等语言的流行，面向对象语言成为主流的编程语言，重要标志是GCC编译器（GNU Compiler Collection）走向成熟，以及Java面向对象语言和编译器的发布。这一时期互联网的发展也促进了编程语言及其编译/解释执行系统的发展，例如出现了互联网开发、在运行时检查类型甚至改变程序结构的动态语言（如PHP、Ruby等）。
|
||
|
||
60-70年代，编译系统的基础理论和相关技术也开始成熟。20世纪50年代，Noam Chomsky通过研究自然语言结构提出Chomsky文法类型，其中上下文无关文法成为现今几乎所有程序设计语言的语法[21]。60年代至80年代，用于上下文无关文法识别的有效算法逐步发展为编译原理的标准部分，同时科学家们着眼研究编译器的自动构造，典型实例包括为UNIX操作系统研制的词法分析器生成工具Lex和语法分析器生成工具Yacc。编译系统中的代码优化研究也起步于这一阶段，包括与处理器体系结构无关的优化（如循环变换、常量传播、公共表达式删除）以及与处理器体系结构相关的优化（如寄存器分配、指令调度），后者与当时精简指令集、超标量、超长指令字等体系结构技术的发展密不可分。
|
||
|
||
\subsection{多核/众核架构驱动的编译系统发展（21世纪-）}
|
||
提高处理器性能是计算机领域长期追求的目标。随着处理器功耗、散热和设计复杂度等原因，在单核处理器上提高时钟频率的方法已无法继续提高处理器性能。因此，学术界和工业界开始改变策略，通过增加处理器核心数目来扩展性能。2001年，第一款商用非嵌入式多核处理器IBM POWER4发布，计算机体系结构发展进入多核时代。然而，增加处理器核数并不必然带来应用性能的提升，需要充分挖掘应用中的并行性以利用处理器的多核特性[22]。在编译系统中挖掘并行性，具有对程序员透明、有可能在机器指令层面发挥硬件潜力等特点，因此当前的主流编译器（如GNU GCC、Intel ICC、IBM XLC和Oracle compiler）均提供了对多核心的支持和优化。
|
||
|
||
与多核处理器通常仅集成几个处理单元不同，众核处理器在同一处理器内部集成了大量同构处理单元。例如，GPU（Graphics Processing Unit）在一个芯片上集成数百甚至数千个“小而简单”的核心，通过使用大量线程并发提高性能，特别适合用于加速大规模并行应用。近年来，众核处理器在高性能计算、人工智能等领域发展迅速，其编译优化技术也随着体系结构的不断升级而进步，包括针对GPU不同存储层次的优化、程序并行度的自动调优、通信优化、针对宽向量的自动向量化等。
|
||
|
||
多核和众核处理器都在不断向前发展，聚合两类处理器的异构计算平台获得了工业界和学术界的重视。2007年首个针对异构计算平台的通用编程模型OpenCL出现，各硬件厂商纷纷提供了OpenCL编译、运行时和驱动支持，使OpenCL代码能够运行在不同类型和不同厂商的硬件平台上。此外，OpenMP 4.0标准也引入了异构计算支持。目前，异构计算平台已成功运用到从超级计算机到移动设备的不同层次计算机系统中。
|
||
|
||
\section{中间件}
|
||
“中间件（Middleware）”本义是指位于操作系统之上、应用软件之下的一层中间软件，提供操作系统所不具备、但上层应用又迫切需要的系统软件功能。由于在过去很长一段时间内，经典操作系统并未充分考虑分布式应用支撑问题，因此狭义的、或者说现代意义上的“中间件”往往特指网络计算中间件，也即支持分布式应用的部署、运行和管理的软件[23]。今天，随着应用软件和操作系统的发展，中间件一词含义也在不断演化（图\ref{fig:3-3}），并表现出沉淀和融入到操作系统中的趋势。
|
||
|
||
\begin{figure}[htbp]
|
||
\centering
|
||
\includegraphics[width=0.80\textwidth]{fig1-3/3-3.png}
|
||
\caption{中间件发展历程
|
||
\label{fig:3-3}}
|
||
\end{figure}
|
||
|
||
\subsection{中间件的出现（20世纪60年代中后期-80年代）}
|
||
中间件的出现是软件系统应用场景快速拓展的结果。随着计算技术的发展，上层应用在适应新场景过程中对系统软件不断提出新的要求，而作为底层支撑的经典操作系统能力相对稳定固化，很难快速跟上这些变化，二者之间的差距决定了中间件存在的合理性。在1968年北大西洋公约组织的软件工程报告中，“中间件”一词被首次使用[24]，代指弥补底层操作系统（当时称“服务例程/控制程序”）通用能力和上层应用特化需求之间鸿沟的中间层软件（图\ref{fig:3-4}）。1972年Jenkin等撰文指出，“随着一些系统变得空前复杂，标准的操作系统需要扩展或修改，推动了‘中间件’这一名词出现”[25]。
|
||
|
||
\begin{figure}[htbp]
|
||
\centering
|
||
\includegraphics[width=0.40\textwidth]{fig1-3/3-4.png}
|
||
\caption{NATO软件工程报告中的倒金字塔软件结构[24]
|
||
\label{fig:3-4}}
|
||
\end{figure}
|
||
|
||
虽然“中间件”这一名词在60年代中后期即已出现，但早期计算机厂商通常提供从操作系统到应用软件的一揽子解决方案，使得二者之间的鸿沟并不凸显。20世纪80年代初，网络技术走向成熟，如何高效构造跨越多个计算结点的分布式应用成为焦点。在传统操作系统之上，开发人员只能通过操作系统的Socket API原生接口，以完全手工方式实现分布式应用中的网络消息传递，其过程繁琐、复杂且低效。同时，除了通信支持外，相对于单机软件，分布式系统还有很多特有的理论和技术问题（如并发支持、事务管理、访问控制等），而传统操作系统并未提供相应的支撑能力。
|
||
|
||
为了应对上述挑战，人们早期围绕两种思路展开了探索。一是以Amobea[26]等分布式操作系统为代表的方法，核心是将单机操作系统的概念放大到网络环境，实现对网络软硬件资源的严格管控，例如文献[27]指出“分布式操作系统对用户而言与单机操作系统无二，只是运行在多个独立处理器上。它的核心概念是透明性”。但是，网络资源具有分布自治、高度异构、持续演化等特点，其软件很难通过严格的以自顶向下的方法精确设计出来，而更多的是通过互联互通方式成长式构造出来的。后一种思路在1976年的ARPANET RFC707中即以“允许调用远程进程所实现的任意命令或函数”的“请求-响应”协议形式出现[28]。Birrel和Nelson等于1984年实现了首个远程过程调用（Remote Procedure Call，RPC）框架[29]，标志着现代意义中间件的诞生。
|
||
|
||
\subsection{企业计算时代的中间件（80年代-21世纪初）}
|
||
如前所述，最早出现的中间件是面向过程的中间件。早期的Sun RPC、开源软件基金会的DCE（Distrbuted Computing Environment）等都是具有代表性的此类中间件，聚焦于尽量实现“调用远程过程像调用本地过程一样简单”。相对于过程，“对象”提供了更贴近现实世界的抽象。面向对象中间件出现于上个世纪80年代初，例如华盛顿大学1980年启动的Eden项目[30]即以在网络计算环境中应用面向对象技术为目标，提出了分布式Ejects（Eden objects）的概念、编程模型和相应支撑平台。OMG于1990年发布CORBA 1.0是具有里程碑意义的面向对象中间件标准，直接推动了面向对象中间件的成熟和高速发展，对后续SUN公司的Java/RMI、微软公司的DCOM等技术体系有着直接和深远的影响。
|
||
|
||
分别发布于1998年和2000年的EJB（Enterprise JavaBean）和CCM（CORBA Component Model）推动了面向构件中间件的出现。面向构件中间件又被称构件容器或构件化应用服务器，它是以构件为基本单元的分布式软件的运行平台。构件技术一方面强调通过大粒度、具有规范接口的软件单元来组装软件系统，另一方面由于构件具有规范的功能和管理接口，因此运行时可以对分布式系统进行灵活管理操纵，包括生命周期管理、交互关系管理甚至动态更新演化等。
|
||
|
||
除了上述支撑不同应用程序模型的通用中间件外，部份中间件关注的是分布式软件的一些特化场景，其典型代表是消息中间件和事务处理中间件：（1）在分布计算实践的初期，人们就已发现紧耦合、同步的过程调用并不能满足所有应用场合，支持异步交互和松耦合通信的分布式应用消息机制的研究和实践开始被重视，诸如Field、InformationBus等消息中间件平台开始出现。上个世纪90年代，IBM MQSeries等消息中间件产品被大量使用，消息中间件技术走向成熟。（2）在大型主机时代，IBM的CICS（Customer Information Control System）系统就已提供了跨计算结点事务支持。针对美国电话公司需要的联机事务处理能力，AT\&T贝尔实验室于上个世纪80年代初发布了跨平台的Tuxedo事务处理中间件，相关研究与实践对后续X/Open组织的分布式事务处理规范、OMG组织的对象事务服务规范等产生了较大影响[31]。
|
||
|
||
\subsection{互联网计算时代的中间件（90年代末-）}
|
||
20世纪90年代中后期， 互联网进入高速发展阶段。互联网资源具有开放动态、成长自治的特点，但人们同时又希望软件能够持续在线、高度可用，二者之间的矛盾催生了“服务”的概念。从2000年左右W3C组织所制定一系列Web Service标准开始，“服务”一词即被用来抽象可通过网络按需访问、无需关心实现细节的能力[32]。以此为核心，面向服务体系结构通过服务化封装和“服务提供者-消费者”之间的动态发现，解决开放动态与持续在线之间的矛盾。
|
||
|
||
作为互联网时代的产物，服务化思想首先推动了中间件技术外延的拓展。Apache Tomcat、IBM WebSphere等Web服务中间件以支撑面向服务体系结构为目标，封装了服务注册、服务发现、服务访问等共性基础设施；以企业服务总线（Enterprise Service Bus，ESB）为代表的服务集成中间件通过服务封装、服务组合、服务协同等技术实现自治子系统之间的通信，进而实现复杂业务系统跨域集成；微服务则聚焦单个业务系统内部，通过系统内部组件的彻底服务化，实现开发阶段“分而治之”和运行阶段的灵活应变，这一思路催生了Spring Cloud等微服务框架。
|
||
|
||
互联网软件按需提供服务的特点也促使了中间件本身向持续运行的平台形式的转型，其典型代表是网格计算中间件、P2P中间件以及云计算“平台即服务”（PaaS）基础设施等。“平台即服务”在“基础设施即服务”（IaaS）的基础上提供包括中间件和数据库在内的一系列软件栈，为云端分布式应用提供服务化的、可按需使用的运行托管环境。在某种程度上，“平台即服务”可视为中间件技术在云计算环境下的集成和延续。
|
||
|
||
\subsection{信息物理融合时代的中间件发展（21世纪初-）}
|
||
计算技术的网络化和普适化推动了信息与物理空间的持续融合，出现了各类可以感知/作用于物理世界的大规模网络软件，中间件技术随之在不断发展。自上个世纪末以来，随着相关硬件技术的逐渐成型，中间件领域针对嵌入式传感器和移动设备等载体，开始关注对物理空间情境（Context）数据的处理，出现了普适计算中间件、传感器网络中间件、情境感知中间件等一系列新型中间件[33]。近年来快速发展的物联网中间件（IoT Middleware）在上述中间件概念的基础上，进一步针对“万物互联”的大规模异构环境进行了拓展，其核心关注点是在资源受限、高度异构、规模庞大、网络动态变化条件下，如何实现互联互通互操作，并且不违反各种时空约束特性，满足物联网应用对海量传感器数据或事件实时处理的需求。
|
||
|
||
除了感知物理世界外，随着信息物理融合系统的成熟，近年来中间件领域开始关注如何联接能够直接“作用”于物理世界的计算设备，其突出代表是无人系统/机器人中间件。针对无人系统计算环境高度异构、资源受限、常态失效、实时性要求高等特点，从2000年左右的Player等中间件开始，包括Miro、CLARAty、OpenRTM-aist、Pyra、Orca、MARIE等在内的一系列实践推动了无人系统中间件技术的发展，并直接为今天广泛使用的机器人“元级操作系统”ROS（Robot Operating System）奠定了理论和技术基础[34]。
|
||
|
||
\section{数据库管理系统}
|
||
数据库是长期存储在计算机内有组织、可共享的大量数据的集合，数据库管理系统旨在统一管理和维护数据库中的数据，是组织、存储、存取、控制和维护数据的软件。从本质上而言，数据库管理系统把逻辑数据转换成为计算机中具体的物理数据，从而使得用户可以访问、检索和维护数据，而不必顾及这些数据在计算机中的布局和物理位置。
|
||
|
||
数据库管理系统的发展历史可以按照其支撑的应用特征来划分（图\ref{fig:3-5}）[35]。第一代系统主要是支持数据的存储与访问，数据的组织以层次和网状模型为代表。第二代系统主要围绕联机事务处理（Online Transaction Processing，OLTP）应用展开，在关系模型和存储技术的基础上，重点发展了事务处理、查询优化等能力。第三代系统主要围绕联机分析处理（Online Analysis Processing，OLAP）应用展开，重点在于提出高效支持联机分析处理复杂查询的新型数据组织技术。第四代系统主要围绕大数据应用展开，重点在分布式可扩展、异地多备份高可用架构、多数据模型支持、以及多应用负载类型支持等特性。
|
||
|
||
\begin{figure}[htbp]
|
||
\centering
|
||
\includegraphics[width=0.80\textwidth]{fig1-3/3-5.png}
|
||
\caption{数据库管理系统发展历程
|
||
\label{fig:3-5}}
|
||
\end{figure}
|
||
|
||
\subsection{数据库管理系统的出现（20世纪60年代-70年代初）}
|
||
20世纪50年代前期，计算机被主要用于科学计算，数据仅被认为是“计算”的产品或附属品，通常存储在被称为“文件”的打孔卡片（早期）或外设数据单元上。随着计算机应用领域向商业、金融、政府等通用领域扩展，文件作为数据存储的主要设施，已经无法满足对各类应用中数据项之间的复杂关系进行管理的需求，主要表现在以下几个方面：文件内部数据组织往往是面向单一应用的，不同应用共享同一个文件结构效率较低；文件之间的数据是独立的，无法表达两个文件的数据所存在内在逻辑关系；文件的组织方式单一，难以满足不同的访问模式对数据高效率访问的需求。
|
||
|
||
在上述背景下，为了提供系统化、高效的数据组织与访问功能，专门的数据库管理系统开始出现。60年代初通用电气在其生产信息和控制系统（MIACS）中设计了“集成数据存储”（Integrated Data Store），被认为是首个支持直接访问的数据库管理系统，并直接为CODASYL组织后续制定的网状数据库标准奠定了基础。1968年，IBM发布了运行于System/360主机的层次数据库管理系统IMS（Information Management System）。上述两个具有里程碑意义的产品分别代表了数据库管理系统的两种早期数据模型，也即数据是按照网状的“图”还是层次化的“树”来组织。其中，层次模型由于其每一个节点最多只有一个父节点，因此可以采用有效的手段（例如按照树遍历的顺序）来存储数据，而网状模型可以将图分解为一组“基本层次联系”的集合，其本质上可以用“树”结构来表达和存储数据。
|
||
|
||
\subsection{关系数据库的高速发展（70年代-90年代）}
|
||
220世纪70年代是关系数据库形成并实现产品化的年代，主要的代表人物就是IBM的埃德加·科德（Edgar F. Codd）。1970年，科德发表题为“大型共享数据库的关系模型”的论文[36]，文中提出了数据库的关系模型。由于关系模型简单明了、具有坚实的数学理论基础，操作语言是描述性的，无需像层次网状模型那样，需要描述存取路径（既先访问哪个数据再访问哪个数据）这样的细节，给提高信息系统开发的生产率提供了极大的空间，所以一经提出就受到了学术界和产业界的高度重视和广泛响应。尽管一开始产业界还充斥了对关系数据库系统性能的怀疑，但科德所开发的System R系统证明其性能可以有保障。这一结论极大地推动了关系数据库技术的发展，关系数据库产品开始涌现，包括IBM公司在System R系统基础上推出的DB2产品、ORACLE公司的同名数据库产品，以及80年代初出现的、针对个人电脑设计的dBase等。由于科德杰出的贡献，1981年的图灵奖授予了这位“关系数据库之父”
|
||
|
||
20世纪80年代，关系数据库迅速取代层次和网状数据库占领市场，描述型的关系库数据语言（SQL语言）、完善数据正确性确保的机制、逐渐发展的开发工具和软件生态在实践中显著提高了生产率。数据库研究工作重心也围绕关系数据库展开，包括查询优化和事务管理等方面：（1）查询优化。关系数据库语言是基于集合的描述性语言（如70年代初出现的SQL语言），其查询的结果也是一个集合。如何将一个SQL语句转换为可以执行的程序（类似程序自动生成器），而且要在所有可能的执行计划（程序）中选择出一个效率足够好的加以执行，是这一阶段工作重点之一。（2）事务管理。事务管理提供对并发事务的调度控制和故障恢复，确保数据库系统的正确运行。詹姆斯·尼古拉·格雷（James Gray）在相关研究方面发挥了十分关键的作用，为数据库管理系统成熟并顺利进入市场做出了重要的贡献。他的成就汇聚成一部厚厚的专著《Transaction Processing: Concepts and Techniques》[37]，他个人也众望所归获得了1998年度的图灵奖。
|
||
|
||
在这一时代，对于数据库管理系统做出重要贡献的还有迈克尔·斯通布雷克（Michael Stonebraker）。他在加州大学伯克利分校计算机科学系任教的29 年中，领导开发了关系数据库系统Ingres、对象–关系数据库系统Postgres、联邦数据库系统Mariposa等，同时创立了多家数据库公司。他在“One size does not fit all”的思想指导下，开发了一系列的“专用”关系数据库产品，例如流数据管理系统、内存数据库管理系统、列存储关系数据库系统、科学数据库管理系统等。因“对现代数据库系统底层的概念与实践所做出的基础性贡献”，他于2015年获得了图灵奖。
|
||
|
||
\subsection{数据仓库系统的出现和发展（90年代-）}
|
||
数据仓库可看作是关系数据库的一个自然延伸。随着数据库技术的普及应用，越来越多的数据被存储在数据库中，除了支持业务处理以外，如何让这些数据发挥更大的作用，就是一个亟待解决的问题。特别是对于联机分析处理类应用，如何让复杂分析能高效地执行，需要有特殊的数据组织模式，推动了数据仓库系统的出现。
|
||
|
||
星型模型是最常用的数据仓库的数据组织模型。所谓星型模型也称多维模型，就是选定一些属性作为分析的维度，另一些属性作为分析的对象。维属性通常根据值的包含关系会形成一个层次，例如时间属性可以根据年月周日形成一个层次，地区属性也可以形成街道-区-市这样的层次。为了实现快速分析，可以预先计算出不同层次上的统计结果，从而获得快速联机分析的性能。在实现方式上，数据仓库可以用关系数据库实现（Relational OLAP），分别用事实表和维表来存储统计结果和维度结构，也可以用特别的数据模型（CUBE）来实现，列存储的技术也在这个过程中被提出和应用。同时，支持联机分析处理的前端工具的发展，也使得普通用户可以方便地使用数据仓库
|
||
|
||
\subsection{大数据时代数据库管理系统的发展（21世纪初-）}
|
||
关系数据库成熟并广泛应用后，数据库领域一度走入一段迷茫期，被关系模型的“完美”所陶醉。进入21世纪，互联网的高速发展使得数据规模越来越庞大，传统关系数据库的弊端开始凸显：在搜索引擎、流媒体等拥有海量非结构化数据的领域，传统的关系数据模型并不完全适用，而关系型数据库所承诺的原子性、一致性、隔离性、持久性等ACID特性在这些领域有可能不需要严苛保证，不必要的开销和有限的可扩展性导致数据存储和管理效率低下。在这一背景下，NoSQL数据库开始出现，其重要的里程碑事件是Google所发布的Bigtable[40]及根据其理念所开发的开源HBase数据库。与关系数据库不同，NoSQL数据库不再采用严苛的关系模型，转而使用更为灵活的键值对结构、文档模型、图模型等。同时，NoSQL数据库可能不提供严格的一致性保证，并且通常在设计时即考虑了水平可扩展能力（即通过增加计算节点来扩充处理能力），因此可以达到比关系型数据库更高容量和性能。
|
||
|
||
随着实践的深入，人们发现NoSQL并非解决大数据时代数据管理问题的“银弹”。一方面，无论从应用程序继承的角度还是提高生产率的角度，SQL语言都是不可或缺的工具，因此继承和汲取SQL的优点（如在上层提供SQL查询引擎）逐渐成为NoSQL数据库的共识，NoSQL一词的含义也从“非SQL”被修正为“不仅仅是SQL”（Not Only SQL）。另一方面，许多联机事务处理业务在应对海量数据同时仍需要采用关系模型，并保证原子性、一致性、隔离性、持久性等特性。因此，能够提供与NoSQL数据库类似的扩展性能、但仍具备关系数据库能力的NewSQL数据库近年来得到了快速发展，其典型代表包括Google全球级分布数据库Spanner和开源领域的CockroachDB、TiDB等。
|
||
|
||
\section{总结}
|
||
系统软件将计算系统的概念从硬件扩展到了软件层面上，它为上层应用提供了一个可以使用各类资源能力、但又无需关注底层细节的软件平台。历经六十余年的发展，系统软件已经形成操作系统、编译系统、中间件和数据库管理系统等典型形态，已经成为了计算机软硬件生态链的核心，对信息产业乃至人类社会产生了较大影响，在促进经济发展和文明进步中发挥了重要作用。在这一过程中，系统软件表现出了如下一些发展规律：
|
||
|
||
\begin{itemize}
|
||
\item 硬件技术和应用场景变迁是发展的核心动力。系统软件具有“承上启下”的特点，无论是形态还是机理的发展都受到硬件和应用两方面的驱动。例如，在贝尔定律支持下，计算设备约每10年一次换代，设备和用户增加10倍，成为新的蓝海、催生新型应用，间次推动操作系统换代并形成新的生态，使得操作系统每隔20年左右迎来一次跨越式发展的机遇期（参见图\ref{fig:3-1}）。另一个典型案例是编译系统：近年来高性能计算、智能计算方面的应用需求，以及GPU等新型硬件的出现，成为了编译系统近年来发展的主要动力。
|
||
\item 构建“抽象”和实现平台化是重要主题。本质而言，系统软件负责向应用提供运行支撑、网络交互、数据管理等不同维度上的“抽象”（或者说虚拟机），并将这一“抽象”以尽可能高效方式绑定到硬件祼机，充分发挥硬件潜力。例如，过去数十年中，操作系统形成了一系列诸如文件、进程/线程、内存页、Socket等的概念，并由这些概念实体共同组成了应用可见的“抽象”（或者说虚拟机）。同时，沉淀共性、进而实现平台化也是系统软件发展的重要主题，一方面可以避免应用去重新“造每一个轮子”，另一方面也为软件生态奠定基础。
|
||
\item 技术螺旋上升与交叉融合是发展的主要特征。与应用软件的快速更新不同，系统软件具有相对稳定性，很多核心技术表现出了螺旋上升的接入点。例如，虚拟化技术早在60年代IBM实验性操作系统CP-40和其后商用化的CP-67、VM/370中得到完整实现，而云计算时代虚拟化技术“复兴”过程中的挑战则主要来自于数据中心环境资源集约化的需求。另一方面，系统软件发展经历了从无到有、进而形成多个分支的过程。“分久必合”，近年来分支之间表现出相互融合趋势，中间件与操作系统就是一个典型案例（参见§3.4节）。
|
||
\end{itemize}
|
||
|
||
今天，“软件定义一切”、“软件成为社会基础设施”正在成为软件学科发展的主流方向，这一趋势推动着系统软件的进一步发展，通过支撑软件系统与社会/物理系统协同演化、联接人机物多个维度、成为泛在基础设施等形式获得新的活力。
|
||
|
||
\section{参考文献}
|
||
|
||
\begin{itemize}
|
||
\item [] [1]. M. Bullynck, "What is an operating system? A historical investigation (1954–1964)," in Reflections on Programming Systems: Springer, 2018, pp. 49-79.
|
||
\item [] [2]. A. M. Turing, "On computable numbers, with an application to the Entscheidungsproblem," Proceeding of the London Mathematic Society, 2, pp. 230-265, (1937).
|
||
\item [] [3]. R. L. Patrick, "General motors/North American monitor for the IBM 704 computer," in AFIPS Conference, 1987.
|
||
\item [] [4]. H. D. Bennington and C. H. Gaudette, "Lincoln laboratory utility program system," in Joint ACM-AIEE-IRE western computer conference: ACM, 1956, p. 21-21.
|
||
\item [] [5]. W. F. Bauer, "An integrated computation system for the ERA-1103," Journal of the ACM (JACM), 3, pp. 181-185, (1956).
|
||
\item [] [6]. E. W. Dijkstra, "The structure of the “THE” multiprogramming system," in The origin of concurrent programming: Springer, 1968, pp. 139-152.
|
||
\item [] [7]. W. F. Bauer, "Computer design from the programmer's viewpoint," in Eastern joint computer conference: Modern computers: objectives, designs, applications, 1958, pp. 46-51.
|
||
\item [] [8]. J. Lee, "Time-sharing at MIT: Introduction," IEEE Annals of History of Computer, pp. 13-15, (1992).
|
||
\item [] [9]. F. J. Corbató and V. A. Vyssotsky, "Introduction and overview of the Multics system," in Proceedings of the November 30--December 1, 1965, fall joint computer conference, part I, 1965, pp. 185-196.
|
||
\item [] [10]. M. J. Bach, The design of the UNIX operating system vol. 5: Prentice-Hall Englewood Cliffs, NJ, 1986.
|
||
\item [] [11]. G. H. Mealy, "The functional structure of OS/360, Part I: Introductory survey," IBM Systems Journal, 5, pp. 3-11, (1966).
|
||
\item [] [12]. R. J. Creasy, "The origin of the VM/370 time-sharing system," IBM Journal of Research and Development, 25, pp. 483-490, (1981).
|
||
\item [] [13]. A. D. JoSEP, R. KAtz, A. KonWinSKi, L. Gunho, D. PAttERSon, and A. RABKin, "A view of cloud computing," Communications of the ACM, 53, (2010).
|
||
\item [] [14]. X. Lu, H. Wang and J. Wang, "Internet-based virtual computing environment (iVCE): Concepts and architecture," Science in China Series F: Information Sciences, 49, pp. 681-701, (2006).
|
||
\item [] [15]. LLyod'S, "Cloud Down: Impacts on the US economy," Technical Report, 2018, https://www.lloyds. com/~/media/files/news-and-insight/risk-insight/2018/cloud-down/aircyberlloydspublic2018final.pdf.
|
||
\item [] [16]. G. M. Hopper and J. W. Mauchly, "Influence of programming techniques on the design of computers," Proceedings of the IRE, 41, pp. 1250-1254, (1953).
|
||
\item [] [17]. J. W. Backus, "Automatic programming: properties and performance of FORTRAN systems I and II," in Proceedings of the Symposium on the Mechanisation of Thought Processes, 1958, pp. 165-180.
|
||
\item [] [18]. J. Backus, "The history of Fortran I, II, and III," ACM SIGPLAN Notices, 13, pp. 165-180, (1978).
|
||
\item [] [19]. J. E. Sammet, "The early history of COBOL," in History of programming languages I: ACM, 1978, pp. 199-243.
|
||
\item [] [20]. O. Dahl, B. Myhrhaug and K. Nygaard, "Some features of the SIMULA 67 language," in Conference on Applications of Simulations, 1968, pp. 29-31.
|
||
\item [] [21]. N. Chomsky, "Three models for the description of language," IRE Transactions on information theory, 2, pp. 113-124, (1956).
|
||
\item [] [22]. M. Mehrara, T. Jablin, D. Upton, D. August, K. Hazelwood, and S. Mahlke, "Multicore compilation strategies and challenges," IEEE Signal Processing Magazine, 26, pp. 55-63, (2009).
|
||
\item [] [23]. 梅宏, 王怀民, "软件中间件技术现状及发展," 中国计算机学会通讯, 1, pp. 2-14, (2015).
|
||
\item [] [24]. J. N. Buxton and B. Randell, Software Engineering Techniques: Report on a Conference Sponsored by the NATO Science Committee: NATO Science Committee; available from Scientific Affairs Division, NATO, 1970.
|
||
\item [] [25]. B. Jenkins, "Developments in computer auditing," Accountant, (1972).
|
||
\item [] [26]. A. S. Tanenbaum, R. Van Renesse, H. Van Staveren, G. J. Sharp, and S. J. Mullender, "Experiences with the Amoeba distributed operating system," Communications of the ACM, 33, pp. 46-63, (1990).
|
||
\item [] [27]. A. S. Tanenbaum and R. Van Renesse, "Distributed operating systems," ACM Computing Surveys (CSUR), 17, pp. 419-470, (1985).
|
||
\item [] [28]. IETF, "RFC 707 - High-level framework for network-based resource sharing," 1977.
|
||
\item [] [29]. A. D. Birrell and B. J. Nelson, "Implementing remote procedure calls," ACM Transactions on Computer Systems (TOCS), 2, pp. 39-59, (1984).
|
||
\item [] [30]. A. P. Black, "Supporting distributed applications: Experience with Eden," in ACM SIGOPS Operating Systems Review. vol. 19: Citeseer, 1985, pp. 181-193.
|
||
\item [] [31]. W. Emmerich, M. Aoyama and J. Sventek, "The impact of research on the development of middleware technology," ACM Transactions on Software Engineering and Methodology (TOSEM), 17, p. 19, (2008).
|
||
\item [] [32]. C. Ferris and J. Farrell, "What are web services?" COMMUNICATIONS OF THE ACM, 46, p. 31, (2003).
|
||
\item [] [33]. 丁博, 王怀民, 史殿习, "普适计算中间件技术," 计算机科学与探索, 1, pp. 241-254, (2007).
|
||
\item [] [34]. A. Elkady and T. Sobh, "Robotics middleware: A comprehensive literature survey and attribute-based bibliography," Journal of Robotics, 2012, (2012).
|
||
\item [] [35]. 杜小勇, 卢卫, 张峰, "大数据管理系统的历史, 现状与未来," 软件学报, 30, pp. 127-141, (2019).
|
||
\item [] [36]. E. F. Codd, "A relational model of data for large shared data banks," COMMUNICATIONS OF THE ACM, 13, pp. 377-387, (1970).
|
||
\item [] [37]. J. Gray and A. Reuter, Transaction processing: concepts and techniques: Elsevier, 1992.
|
||
\item [] [38]. S. Ghemawat, H. Gobioff and S. Leung, "The Google file system," in ACM Symposium on Operating Systems Principles, 2003.
|
||
\item [] [39]. J. Dean and S. Ghemawat, "MapReduce: a flexible data processing tool," Communications of the ACM, 53, pp. 72-77, (2010).
|
||
\item [] [40]. F. Chang, J. Dean, S. Ghemawat, W. C. Hsieh, D. A. Wallach, M. Burrows, T. Chandra, A. Fikes, and R. E. Gruber, "Bigtable: A distributed storage system for structured data," ACM Transactions on Computer Systems (TOCS), 26, p. 4, (2008).
|
||
|
||
\end{itemize} |