集成架构：对比 Web API 与面向服务的架构和企业应用程序集成.pdf

集成架构：对比 WebAPI 与面向服务的架构和企业应用程序集成 简介 几乎所有企业都有多个应用程序作为其关键数据的记录系统，而且还拥有它们赖以创业的业务功 能。因此，一些组织想要不断向其企业内外更广泛的受众揭示这些操作系统中的宝贵资产，我们对此 已司空见惯。但是，这需要时间。在本教程中，我们将介绍这项评估的关键阶段，帮助您评估您的企 业在此旅程中的位置，分析您可能想要采取哪些行动来让您的集成架构朝着或超越 API 公开的方向 发展。 首先，让我们简要介绍一下业务功能公开的历史，然后更详细地分析以下两个最新的概念之间的 区别：面向服务的架构 (SOA)和 Web API。 过去几十年来，整个行业在集成架构上的进化显而易见，业务功能的公开程度不断加大，如图 1 所示。 图 1. 业务功能的渐进式公开业务功能的渐进式公开 我们的目的是了解 SOA 与现代业务 WebAPI 之间的区别。为了有效地理解此区别，我们需要明 确了解 SOA 带来了什么。 让我们简单看看前 3 个阶段 （一直到 SOA）发生了哪些变化，然后分析 WebAPI 增添了哪些变 化。 使用 “低级 API” 的点对点连接 自从企业拥有应用程序，就需要在应用程序之间移动和共享数据。让用户在不同系统中反复输入 信息（ “转椅” 集成）在大多数情况下无助于持续发展。这带来了在孤立的应用程序之间建立直接 （点对点）低级连接的需求。获得实时的响应常常是不可能的，所以数据通常是通过文件或单向消息 异步发送的。每个接口的每一端都需要新的序列化和解析代码，如图 2 所示。 图 2. 点对点集成点对点集成 应用程序之间的不同连线表明，通常需要多个不同的协议来实现不同的接口，这使集成任务变得 更加复杂。 为此，我们引入了应用编程接口 (API) ，包括传输、协议和用于实时交互的数据格式，使直接 从被调用的系统获得响应成为现实。当然，这是缩写词 API 的起源，API 现在已拥有称为 “WebAPI” 的新用途。本教程将明确区分这两种 API，将原始类型称为 “低级 API”，将新类型称为 “WebAPI”。 在日常用语中，Web API 通常被简称为 “API”。 集成的成熟度通常是使用 服务集成成熟度模型 (SIMM) 来度量的。点对点集成的 SIMM 级别通 常为 2。SIMM 是一种成熟度模型，但我们应谨慎地理解 “成熟度” 的含义。在您进入下一个级别 时，模型中的每个级别上采用的技术不会过时，它们只是被更有选择性地使用。例如，即使在实现了 SIMM 级别为 4 的服务的公司中，仍然可能对偶尔的点对点或中心辐射型集成具有充分合理的需求。 这些低级 API 在不同平台上具有明显的区别，这就需要向每种集成两端的应用程序中写入复杂 的特定于应用程序的连接代码。 企业应用程序集成 在上世纪 90 年代，集成工具和运行时变得越来越常见。它们知道如何执行连接，并提供了一个 中央集线器来执行所有集成。 这实现了一种更加类似 “中心辐射型” 的架构，并显著减少了编写的专用集成代码量，如图 3 所示。这通常具有 SIMM 级别 3，被称为企业应用程序集成 (EAI)。 图 3. 中心辐射型架构中心辐射型架构 这些新工具和技术意味着，您可以在集成集线器范围内重用连接，您只需要确定如何连接到一个 应用程序一次。总是使用同样的工具和运行时来完成此工作，而不是在多种语言和多个平台上使用集 成代码。 由于应用程序之间根本不同的交互风格，它们通常没有实时连接。更常见的是，一个入站适配器 从系统获取数据并存储在基于文件或消息的存储器中，然后一个集成流处理该数据并将其传递给目标 系统。在数据仅需要用于引用用途时，这不可避免地会导致在系统间复制大量数据。与原始系统连接 的实时接口（real-time interfaces）可减少这种重复。 渐渐地，与操作系统连接的实时接口变得更加普遍，它们减轻了对跨系统复制数据的需求。但是， 一个新系统要使用这些实时接口之一，仍然需要一些工作来将它连接到集线器。诚然，在中心辐射型 架构上所做的许多尝试仅仅稍微减轻了点对点问题，向一个运行时和一个工具中引入了点对点编码。 除非集成是针对重用而小心设计的，否则创建一个新接口仍然需要大量新代码。 我们需要一种更加标准化的方式来从集线器