程序原本(二十八):语言及其面临的系统——从功能到系统(方向 2:程序组织的结构化(服务化与系统构建))

阅读数:25 2019 年 9 月 28 日 18:10

程序原本(二十八):语言及其面临的系统——从功能到系统(方向2:程序组织的结构化(服务化与系统构建))

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

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

程序原本(二十八):语言及其面临的系统——从功能到系统(方向2:程序组织的结构化(服务化与系统构建))

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

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

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

程序原本(二十八):语言及其面临的系统——从功能到系统(方向2:程序组织的结构化(服务化与系统构建))

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

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

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

程序原本(二十八):语言及其面临的系统——从功能到系统(方向2:程序组织的结构化(服务化与系统构建))

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

17 我们可以将能在产品最终用户的环境中实现的需求称为本地需求,将不能在该环境中实现的称为非本地需求

(1) 交互界面是否可以表达为可实现的规则集

(2) 输出是否可以表达为可计算的数据项

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

18 REST(Representational State Transfer,表述性状态转移)是一种面向远程服务提供的架构方法,JSON(JavaScript Object Notation,JavaScript 对象表示法)是一种数据交换语言 / 规格。从这个角度来看,SOAP 与 XML 并不是复杂的方案。

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

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

评论

发布