集成架构：面向服务与Web API集成

简介

几乎所有企业都有多个应用程序作为其关键数据的记录系统，而且还拥有它们赖以创业的业务功能。因此，一些组织想要不断向其企业内外更广泛的受众揭示这些操作系统中的宝贵资产，我们对此已司空见惯。但是，这需要时间。在本教程中，我们将介绍这项评估的关键阶段，帮助您评估您的企业在此旅程中的位置，分析您可能想要采取哪些行动来让您的集成架构朝着或超越 API 公开的方向发展。

首先，让我们简要介绍一下业务功能公开的历史，然后更详细地分析以下两个最新的概念之间的区别：面向服务的架构 (SOA) 和 Web API。

过去几十年来，整个行业在集成架构上的进化显而易见，业务功能的公开程度不断加大，如图 1 所示。

图 1. 业务功能的渐进式公开

我们的目的是了解 SOA 与现代业务 Web API 之间的区别。为了有效地理解此区别，我们需要明确了解 SOA 带来了什么。

让我们简单看看前 3 个阶段（一直到 SOA）发生了哪些变化，然后分析 Web API 增添了哪些变化。

使用 “低级 API” 的点对点连接

自从企业拥有应用程序，就需要在应用程序之间移动和共享数据。让用户在不同系统中反复输入信息（“转椅” 集成）在大多数情况下无助于持续发展。这带来了在孤立的应用程序之间建立直接（点对点）低级连接的需求。获得实时的响应常常是不可能的，所以数据通常是通过文件或单向消息异步发送的。每个接口的每一端都需要新的序列化和解析代码，如图 2 所示。

图 2. 点对点集成

应用程序之间的不同连线表明，通常需要多个不同的协议来实现不同的接口，这使集成任务变得更加复杂。

为此，我们引入了应用编程接口 (API) ，包括传输、协议和用于实时交互的数据格式，使直接从被调用的系统获得响应成为现实。当然，这是缩写词 API 的起源，API 现在已拥有称为 “Web API” 的新用途。本教程将明确区分这两种 API，将原始类型称为 “低级 API”，将新类型称为 “Web API”。在日常用语中，Web API 通常被简称为 “API”。

集成的成熟度通常是使用 服务集成成熟度模型 (SIMM) 来度量的。点对点集成的 SIMM 级别通常为 2。SIMM 是一种成熟度模型，但我们应谨慎地理解 “成熟度” 的含义。在您进入下一个级别时，模型中的每个级别上采用的技术不会过时，它们只是被更有选择性地使用。例如，即使在实现了 SIMM 级别为 4 的服务的公司中，仍然可能对偶尔的点对点或中心辐射型集成具有充分合理的需求。

这些低级 API 在不同平台上具有明显的区别，这就需要向每种集成两端的应用程序中写入复杂的特定于应用程序的连接代码。

企业应用程序集成

在上世纪 90 年代，集成工具和运行时变得越来越常见。它们知道如何执行连接，并提供了一个中央集线器来执行所有集成。

这实现了一种更加类似 “中心辐射型” 的架构，并显著减少了编写的专用集成代码量，如图 3 所示。这通常具有 SIMM 级别 3，被称为企业应用程序集成 (EAI)。

图 3. 中心辐射型架构

这些新工具和技术意味着，您可以在集成集线器范围内重用连接，您只需要确定如何连接到一个应用程序一次。总是使用同样的工具和运行时来完成此工作，而不是在多种语言和多个平台上使用集成代码。

由于应用程序之间根本不同的交互风格，它们通常没有实时连接。更常见的是，一个入站适配器从系统获取数据并存储在基于文件或消息的存储器中，然后一个集成流处理该数据并将其传递给目标系统。在数据仅需要用于引用用途时，这不可避免地会导致在系统间复制大量数据。与原始系统连接的实时接口（real-time interfaces）可减少这种重复。

渐渐地，与操作系统连接的实时接口变得更加普遍，它们减轻了对跨系统复制数据的需求。但是，一个新系统要使用这些实时接口之一，仍然需要一些工作来将它连接到集线器。诚然，在中心辐射型架构上所做的许多尝试仅仅稍微减轻了点对点问题，向一个运行时和一个工具中引入了点对点编码。除非集成是针对重用而小心设计的，否则创建一个新接口仍然需要大量新代码。

我们需要一种更加标准化的方式来从集线器公开功能，以便无需额外的工作即可重用它。

面向服务的架构

在 2000 年代初，随着传输、协议和数据格式标准得到更广泛的采用，比如 SOAP/HTTP（通常称为 “Web 服务”），以标准化方式公开服务成为可能。这意味着请求者（他们理解这些现代标准）通过最小的努力就可以使用这些服务。这些公开的业务功能的直接重用现在已变为可能。一个经过良好控制的公开服务套件应该具有 SIMM 级别 4。

任何重用机会都会带来新的收益，同时也会带来新的挑战。使用 SOAP/HTTP 简单地公开业务功能，不足以确保服务的健全性。它会带来许多挑战，从系统间难以管理的依赖性到安全暴露。

从服务公开的角度讲，SOA 比协议和数据格式的标准化复杂得多。要有效地公开服务，还需要标准化以下方面：

虚拟化：用户必须调用一个隐藏了其最终的实现方式和位置的复杂性的虚拟 服务端点。向标准化的协议和传输的转换是虚拟化的一部分，但服务还需要提供标准的可配置方面，比如路由和数据转换，同时继续向用户提供同样的虚拟 服务来最小化变更的影响。

可视性：如果公开核心业务功能，您需要管理和监视它们。要大规模地实现有效的监视，需要在所有服务上以一种标准化方式来执行。

安全性：要让服务容易使用且更容易管理，您需要标准化访问控制、身份管理和其他关键的安全性 方面。安全性是复杂的，而您需要您的服务容易使用。您需要减少向用户公开的安全模型的变化。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!