另一个带来崭新思考空间的语法元素是服务(service)。一个服务的发布、运行、①这个功能基本上可以概括为：基于存储地址、用于限制访问边界、纯粹的线性计算(分配)的过程。②这可能是一个有150多个可选配置项的命令行程序，除了-help参数就再也没有其他任何称得上文档的东西。

③作为产品的用户，他还期望在个人需要与应用环境都发生变化时，仅支付少量的代价即可应对，而非重新购置。

④最简单而又直白的说法就是：隔行如隔山。⑤但凡一切可以抽象为可计算对象，并通过计算系统来解决问题的领域。

使用、受益、检测与维护等整个过程都可能由不同的用户/角色来参与。例如，表2-2比较了生活中的邮寄与软件开发中的会话这样两个“服务”。

会话管理 定时重启、转储、会话"开发包会话服务业务1业务1会话监视服务服务镜像服务等*这里假设会话服务提供过程中，所有的服务、业务等都有操作人员，即使部分可以作为自动化服务提供，我们也可以称之为干系人。

服务在操作系统及其应用软件中也有着重要的位置。以一个典型下载软件为例，它可能提供一个后台传输的服务(backTrans),那么该服务在Windows中的提供模式可能如表2-3所示。yipindushu.com

Windows 安装、卸载等后台传输下载软件backTrans桌面用户**这里假设这是一个桌面用户可选的服务，当不使用该服务时，基本的下载功能不受影响。

而当一个与此功能等价的服务通过网络来提供时(以Google账户同步功能在Gmail与Android通讯簿功能中的使用为参考),那么上述的模式可能改变为表2-4所示的结果。

GMail、Android通讯簿化等framework综观上述这样的一个软件需求与实现的模式①,是不可能仅仅以Unit以及更高的形式(库/套件)来提供支持的，因为其需求的本质在于“异地实现”。在这个需求下，由于“服务、功能部件，以及功能部件的操作者”这一系列行为完全不可预期，因此服务的调用方已经不能对实现者的语言与运行的环境作出任何限制。在这个级别上的问题，最终总是被归结为两个解决思路：①我们可以将能在产品最终用户的环境中实现的需求称为本地需求，将不能在该环境中实现的称为非本地需求。

(1)交互界面是否可以表达为可实现的规则集；(2)输出是否可以表达为可计算的数据项。

而简化该问题规模的方法也由这两个经验得出，即尽可能简单的界面规则与数据表示，例如REST和JSONI。

对于这类需求模式，我们将提供服务集成能力以支持非本地需求的应用称为系统(system),并将这一等级上的语言统称为“系统程序设计语言”(system programminglanguages)。服务的提供能力与其所支持的层次，成为这个级别的语言特性的主要发展方向。由于服务所在的用户领域有着种种差异，因此在这个级别上的语言也需要提供特定领域的部署、维护与交互界面等特性②,例如Java中的Beans、Annotations,或Erlang中的Node、Port等。

【六】

从计算机应用的历史来看，我们在语言中加入新的元素，其本质的原因正是旧的语言特性在应对规模(而非仅仅是计算)的时候显得力不从心，尤其是在应用与系统这两个规模级别中，(在语法与语义上的)语言特性体现出来的代码组织能力，相当大的程度上决定了这门语言所适用的开发规模。

最后，我们总结一下不同视角对这些规模的认识。

体，基本没有产品化 员过程语言类型计算语言Computing Languages编程语言ProgrammingLanguages开发行为编码编程规模例举排序算法shell脚本；脚本解释器；学术型操作系统① REST( Representational State Transfer,表述性状态转移)是一种面向远程服务提供的架构方法，JSON(JavaScript Object Notation,JavaScript对象表示法)是一种数据交换语言/规格。从这个角度来看，SOAP与XML并不是复杂的方案。

②这里讨论的是语言，因此限定这些特性是通过语法元素来实现的。尽管在开发包中，用第三方工具来提供支持也是解决这一问题的通常手段，但并不是我们主要讨论的话题。

③使用这个有争议的名字原因在于，(基于一些历史的、习惯性的因素地来看)程序、应用和系统被我们统称为软件，而“软件工程师”是其实现角色的基本要求。当然，在此前，他还必须是一个程序员。