向基于语义模型的操作集成的演变

在过去的许多年里，已经定义了许多架构方法，用于系统集成以及其信息和流程的表示。这些方法包括面向数据、面向消息、面向服务和面向信息的方法。需要探讨的问题是：

• 这些不同的方法有何不同和联系？
• 从实时运营整合架构的角度来看，语义模型究竟适合在用哪里？
• 语义模型作为实时操作集成架构的一个关键组成部分，能提供什么价值？

1. 集中式应用的数据

从 1950 年到 1980 年，单体应用程序要求应用程序拥有所有数据。所有对数据的访问都是本地的；所有定义、关系和知识都包含在应用程序中。企业中的部门化用户拥有直接的领域知识，因此无需集成。

随着计算机变得更加经济实惠并在整个工业运营中激增，并且在终端设备中包含可编程逻辑控制器 (PLC) 和嵌入式计算功能，复合应用程序和系统的复杂性稳步增加。从 1990 年到现在，数据库和客户端-服务器架构曾经并且仍然用于允许多个并发客户端与集中式数据存储进行交互。

对于集中式数据存储，集中式应用程序拥有其部分数据，其他应用程序直接调用以获取信息或请求被调用应用程序执行某些操作。从历史上看，这涉及通过应用程序接口 (API) 或远程函数调用 (RFCs) 直接调用另一个应用程序。API 和 RFCs 包含在客户端库中，调用应用程序链接到该客户端库。在这种情况下，调用应用程序负责理解被调用应用程序的语义并负责所有数据转换等。虽然从性能角度来看速度很快，但从维护角度来看，这种方法已被证明是昂贵的（而且很脆弱，因为一个应用程序中的故障会对所有直接相互连接的应用程序产生连锁反应）。此外，在大多数情况下，数据验证方法的记录不充分。因此，基本数据的新消费者的新要求导致部署并行系统以捕获附加数据，同时引入替代数据验证规则。这种做法会产生多个“真实的版本”，因此数据的所有用户都会花费 50-75% 的时间来对账和验证数据，然后才能充分信任数据以进行分析。随着系统复杂性和点对点集成的增加，这种准备时间也在增加。语义计算的另一个好处是减少这种浪费的时间。

1. 以数据为中心的架构

拥有数据的集中式应用程序的替代方案是以数据为中心的架构。这显然比直接连接的方法向前迈进了一步，因为应用程序不会直接相互连接以交换信息。以数据为中心的架构以相关业务和运营数据的单一定义为基础，围绕这些数据集成系统并开发应用程序。简而言之，以数据为中心的架构为集中式数据存储和使用该集中式数据存储的规则和要求进行互操作的客户端应用程序建立了一个通用数据模型。不幸的是，数据是从它们在各种 SORs 的端点复制的，其中应用了独特的验证规则。这也导致了多个“真实的版本”。

这种方法的一个早期例子是 SAP 的早期版本。这些 SAP 版本是（或至少看起来是）基本上是 40 多个应用程序套件，开发围绕中央数据模型进行交互。尽管 SAP 支持外部应用程序的其他集成方法，但 SAP 已采用以数据为中心的方法进行应用程序内部通信，从而导致数据重复。

XML 之前的集成方法虽然本质上很简单，但却是用固定的数据结构实现的，这导致了一个相当紧密耦合的系统，其中所有系统组件都受到数据和数据结构变化的影响。这种架构方法通常会导致共享数据存储中出现单点故障。从历史上看，它在业务系统中不是关键的，但在运营中的实时工作流程应用中，这种方法破坏了运营系统。并造成巨大的效率和质量损失以及额外的成本。

1. 分布式应用的数据

随着 1990 年至今网络的进步，应用程序的复杂性发展为由多个通信（集成）应用程序构建的分布式系统。虽然早期的实现主要是试图打破单体架构，但它们仍然基于单一应用程序模型并为特定领域设计。

最终，这导致了一类新的系统，其中集成了多个应用程序以创建新功能并使用每个应用程序中包含的数据来实现最初应用程序设计者最初不打算的功能。在这种情况下，每个应用程序都是一个 SOR—一个信息系统，它是给定数据元素或信息片段的权威数据源。

这些系统的分布式特性引起的问题很快导致人们意识到分布式架构是硬而脆弱的。需要一种更好的系统间通信方式来处理通信故障和应用程序可用性问题。这导致了松散耦合的面向消息架构的想法。

1. 面向消息的架构 (MOA)

面向消息的架构 (MOA) 用于交换信息（文档），其中没有关于应该对接收的文档做什么的隐含语义。

这个定义是什么意思？这基本上意味着 MOA 用于广泛的信息共享。一个例子是股票报价，其中金融服务公司有一个 MOA 主干（例如，TIBCO、MQ 或 MSMQ）来将股票价值的变化分发给任何感兴趣的应用程序。MOA 不会规定某人在知道股票价值发生变化后会做什么；MOA 只是通知他们这已经发生了。根据这个定义，MOA 主要用于数据同步和事件通知。因此，MOA 通常是基于发布/订阅的。

就其本身而言，MOA 不涉及交换信息的任何数据模型。它以请求的服务质量将数据从 A 点移动到 B 点。它不定义内容，也不捕获系统的语义。

当 MOA 期望响应时，MOA 可以扩展为包括结构化数据。在这种情况下，要交换的信息的数据模型通常基于行业标准。示例包括 EDI（Electronic Data Interchange）、BEMML（ISA-95 标准的 XML 实现）和 BatchML（ISA-88 标准的 XML 实现）。所使用的数据模型也可用于我们在上面“以数据为中心的架构”部分中讨论的数据模型。

1. 面向服务的架构（SOA）

虽然 MOA 有助于缓解分布式系统中应用程序之间的通信复杂性，但典型的系统是通过点对点集成构建的，信息语义被隐藏、隐藏在实现中并且在运行时根本不可用。

SOA 为应用程序或应用程序组件之间的互操作添加了一种标准化方法。SOA 添加了在运行时可发现的接口契约的独立于平台的描述。这使得临时客户端能够访问公开的信息，如果不深入了解正在交换的数据和消息传递主干的结构, 这在 MOA 中有时是不可能的。不幸的是，并非所有信息都被公开，但该概念确实提供了一定程度的改进。有了严格的设计和治理监督，改进的程度是非常大的。

在 SOA 中，消费者（客户端）为了一些明确定义的目的（例如，处理订单）与提供者进行交互。信息是针对特定任务的，不会经常更改。当信息确实发生变化时，会添加一项新服务以保持与现有系统的“向后兼容性”。单个服务定义捕获服务及其数据的语义，但无法提供有关系统的任何知识。

1. 面向信息的架构（IOA）

由于基础设施的多样性，前面的架构方法可以说是相辅相成的，并且在实际中一起使用是有意义的。事实上，任何不断发展的架构都必须提供一种与现有系统有效共存和/或集成的方法。系统需要进化，重构根本负担不起，也不现实。IOA 扩展了 SOA 以包括对被集成系统中信息的规范视图和访问，作为业务和运营智能和分析的基础，支持流程优化和增强的决策制定。IOA 为市场提供了组合业务和运营流程的基础，这些流程和运营流程围绕单个信息模型共同创建复合应用程序。该模型定义了数据交换的规范形式并定义了数据中介的规范。这与上面的以数据为中心的方法不同，规范模型是交换模型，不一定是任何给定服务的模型。挑战在于数据模型是为一组给定