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

回想本教程之前的内容，重用始终是有代价的。从图 7 中可以看出，您的公开能力需要扩展到核心 SOA 需求以外。

图 7. 针对企业外的公开 API 的新能力

我们看看这些新挑战的两个主要方面：

合作伙伴管理：您现在拥有一个庞大的移动应用程序设计师团队，其中的设计师可能想要试验您的 Web API。如果不将它设计得非常容易使用而且具有吸引力，您的 Web API “产品” 很快就会被竞争对手赶超。您如何与这些新合作伙伴建立新关系？您如何持续跟踪谁在访问这些功能？您可能拥有外部相关方依靠您的 Web API 作为其业务的基础部分。您如何建立和监视他们需要何种服务水平？合作伙伴管理必须是 Web API 公开组件提供的一个一级功能。由于潜在合作伙伴的庞大数量，合作伙伴管理必须是自助式的，它还需要识别合作伙伴，依据达成一致的授权计划来监视和控制他们的使用情况。

安全性：显然，通过公共媒介（比如互联网）公开 Web API 意味着需要考虑全新的安全问题水平，从各种以有效负载为载体的攻击，比如 XML 威胁，到对吞吐量或连接的拒绝服务攻击。您还必须可靠地验证您合作伙伴的应用程序，以便有效地控制其服务水平。

这种增加的复杂性导致了现在所谓的 API 管理 的出现。Web API 管理是一种架构意图，而不是单个组件，尽管它们显然是 专为该意图而设计的产品。它使组织能够简单而又安全地公开和管理 Web API。它将一种更健全、更安全的网关与和合作伙伴管理相关的功能相结合。

图 8 显示了实现 API 管理所需的主要组件，以及所涉及的典型角色。

图 8. API 管理的一个典型模型的示例

所有这些角色都在 SOA 中以一种或另一种形式松散地呈现，但它们的实现通常不那么正式。Web API 面向公众的事实已迫使它们变得成熟。典型的角色集合为：

API 产品经理：此角色建立适合销售的 Web API，准备和管理其使用 “计划”，以及使用历史分析评估 Web API 的成功。

API 开发人员：此角色通过配置与提供实际数据和功能的后端系统的连接性和数据映射，提供 Web API 表面背后的实质。

应用程序开发人员：此角色通过 “API 门户” 在产品上利用 Web API，签署协议以通过 API 产品经理定义的一个计划使用它们。

运营：此角色每天监视和管理 Web API，确保它们满足该计划所定义的服务水平。

API 表面背后的架构 “实质” 是什么？

Web API 网关只是 Web API 的表面或暴露点。它没有提供 Web API 所提供的任何实际功能或数据。这让我们能够了解集成架构在企业内演化的全过程 - 从孤立的应用程序成长为点对点通信和中心辐射型中间件，进而潜在地实现 SOA。

诚然，在决定 Web API 的底层实现应来自何处时，高度依赖于企业的演变方式。图 9 显示了最常见的选项的例子：

重新公开一个现有的企业服务

公开一种通过集线器调节的新集成

公开一个已由提供商系统提供的接口

图 9. Web API 实现的选项示例

人们很容易认为重新公开现有服务（图 9 中的选项 A）是最常见的。毕竟，SOA 已存在 10 多年，肯定大部分公司都已拥有一套服务。公开这些服务将是从以前对集成的投资中获利的最高效方式。尽管肯定有一些组织在这么做，但由于以下原因，这可能没有您预料的那么常见：

集成成熟度：前面已经提到过，服务通常仅在业务中它们具有价值的特定部分中公开。对于业务的其他部分，其他集成模式（比如中心辐射型或者甚至点对点模式）可能仍然够用。

粒度：因为企业服务通常是根据已知的业务需求而创建的，所以它们通常具有很粗的粒度，带来一个相对较大的数据图，而且可能包含许多子对象。这些操作对移动设备上需要的响应迅速的应用程序而言负担太重，尤其是考虑到设备常常变化的带宽。

安全性：企业服务执行更新操作时，该操作常常以一种特定于企业的方式执行；例如，假设呼叫方的可信度，信道的安全性，或仅供内部使用的安全令牌机制。

相关性：在公司内值得关注的或可销售的数据和功能，通常是无关的或不适合外部公开。我们在 Web API 中寻找的通常是一种全新的市场机会；一个可能公开完全不同的数据的新概念。

因此，图 9 中的选项 B 可能很常见，而且 Web API 使用集成来实现。或许他们在集成集线器本身内重用组件和适配器，但未重用现有服务。

选项 C 目前很少见，因为想要的 Web API 几乎肯定不同于现有应用程序。Web API 网关通常拥有有限的数据转换功能。但是，一旦集成逻辑远远超越基本的数据映射和简单聚合，Web API 网关在架构上就不再适合此逻辑。

基于云的 API 管理

在当今时代，人们渴望减少内部基础设施占地空间，企业在寻找更容易从基于云的提供商获得的功能。API 管理是一个不错的例子。Web API 网关和 API 管理功能都拥有明确的责任，所以它们很容易与内部架构分开，如图 10 所示。因为目标是向外部相关方公开它们，所以托管来自基于云的提供商的 Web API 具有一定的合理性。

图 10. 基于云的 API 管理服务提供商

尽管与具体企业相关，但这种基于云的 API 管理特别适合 “诞生于网络” 的公司。举例而言，一家创业公司选择不建立内部基础设施，将所有功能托管在基于云的环境中。基于云的 API 管理使他们能够提供单个统一的公开点来供用户查找他们的 Web API，无论这些 API 托管在云中的何处。

使用此方法，您需要考虑以下因素：

访问控制：您如何向基于云的 API 管理服务安全地提供访问您的内部中间件或实际操作系统的能力？显然，需要某种形式的安全连接器，但您准备交给外部相关方多大的控制权？

（编辑：ASP站长网）