返回介绍

19.3 服务与结点:一组接口 在两种视角下的抽象概念

发布于 2024-12-15 23:01:53 字数 1554 浏览 0 评论 0 收藏 0

系统由领域组成,领域又由细分领域组成……由此我们最终所讨论的、具体的、作为组成部件的领域被表达为:

  • 包含了特定领域知识,
  • 提供了基于上述知识的处理能力,
  • 反馈了在领域间可理解信息的一组行为。

对于这样一组行为,我们称之为“(该子系统/领域的)接口”。请注意,我们讨论系统中的接口时,它是脱离具体语言的。我们需要这样一层抽象概念的根本原因在于:

  1. 将领域问题转义为一组逻辑的界面;
  2. 将领域间有无关系,转义为“领域对领域(调用者与被调用者)”的接口是否可达;
  3. 屏蔽领域内的数据性质 5 ,迫使开发者必须通过特定的设计来解决领域间的数据问题(例如数据类型、数据依赖等)。

在这三种原因(或可称为三类需求及其解决手段)中,第一种和第二种是显性的,它们由接口的抽象特性决定:其一,表达为一组方法;其二,能否使用这些方法,取决于能否获得接口。

第三种则是隐性的,并且也是决定系统稳定性的最主要因素。事实上在这样的背景之下,开发者能够选择的方案也相对有限,主要包括远程方法或远程对象、消息/状态、序列化、分布等。

最终,我们将提供一组接口的系统组成构件称为一个“服务”,或一个“结点”。前者是功能视角下的一个概念,后者则基于部署视角 6 。但总的来说,服务/结点都意味“非本地”的支持,这也可以理解为对“跨领域的需求”的支持。

  1. 事实上,业界现在又把这两个学术化的领域统一称为“云”,包括云计算、云存储等具体的解决方案。关于数据或运算的规模也存在许多其他细分的领域和混杂的概念,例如早期的网格(Grid)与现在的大数据(Big Data)。无论如何,这些都只是分布问题在业界的具体表现而已。
  2. 就目前来说,通用应用开发语言主要是指面向对象语言或结构化程序设计语言,例如 Java、C#,以及 C 语言等。
  3. 因此,在缺乏这样的需求——例如在一个小一些的、跨领域特性并不突出——的系统或应用中,要求实施“面向接口设计”是一件相当多余而又学术化的事情。
  4. 另外,我们也可能通过静态数据与增量数据、本地数据与远程数据等分类法来区别不同的数据。我在这里采用“结构化”这一分类法只是一种选择,仅为了说明常见的问题,而非一个强制设定。
  5. 这涉及数据的全部三种性质:标识、值与确定性,以及由确定性带来的分布、状态等性质。
  6. 两者除了抽象视角的不同,在实现上通常也有差异(这里的服务与结点主要分别基于 Java 和 Erlang 中的概念)。

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
    原文