Question

另一个带来崭新思考空间的语法元素是服务（service）。一个服务的发布、运行、使用、受益、检测与维护等整个过程都可能由不同的用户/角色来参与。例如，表 2 比较了生活中的邮寄与软件开发中的会话这样两个“服务”。

表 2　服务：比较生活中的邮寄与软件开发中的会话

* 这里假设会话服务提供过程中，所有的服务、业务等都有操作人员；即使部分功能是由自动化服务提供的，我们也可以称之为干系人。

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

表 3　服务：后台传输服务在 Windows 中的提供模式

* 这里假设这是一个桌面用户可选的服务，当不使用该服务时，基本的下载功能不受影响。

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

表 4　服务：与上述服务等价的服务在网络环境下的提供模式

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

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

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

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