标签：
几乎所有企业都有多个应用程序作为其关键数据的记录系统，而且还拥有它们赖以创业的业务功能。因此，一些组织想要不断向其企业内外更广泛的受众揭示这些操作系统中的宝贵资产，我们对此已司空见惯。但是，这需要时间。在本教程中，我们将介绍这项评估的关键阶段，帮助您评估您的企业在此旅程中的位置，分析您可能想要采取哪些行动来让您的集成架构朝着或超越 API 公开的方向发展。
首先，让我们简要介绍一下业务功能公开的历史，然后更详细地分析以下两个最新的概念之间的区别：面向服务的架构 (SOA) 和 Web API。
过去几十年来，整个行业在集成架构上的进化显而易见，业务功能的公开程度不断加大，如图 1 所示。
我们的目的是了解 SOA 与现代业务 Web API 之间的区别。为了有效地理解此区别，我们需要明确了解 SOA 带来了什么。
让我们简单看看前 3 个阶段（一直到 SOA）发生了哪些变化，然后分析 Web API 增添了哪些变化。
自从企业拥有应用程序，就需要在应用程序之间移动和共享数据。让用户在不同系统中反复输入信息（“转椅” 集成）在大多数情况下无助于持续发展。这带来了在孤立的应用程序之间建立直接（点对点）低级连接的需求。获得实时的响应常常是不可能的，所以数据通常是通过文件或单向消息异步发送的。每个接口的每一端都需要新的序列化和解析代码，如图 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)。
这些新工具和技术意味着，您可以在集成集线器范围内重用连接，您只需要确定如何连接到一个应用程序一次。总是使用同样的工具和运行时来完成此工作，而不是在多种语言和多个平台上使用集成代码。
由于应用程序之间根本不同的交互风格，它们通常没有实时连接。更常见的是，一个入站适配器从系统获取数据并存储在基于文件或消息的存储器中，然后一个集成流处理该数据并将其传递给目标系统。在数据仅需要用于引用用途时，这不可避免地会导致在系统间复制大量数据。与原始系统连接的实时接口（real-time interfaces）可减少这种重复。
渐渐地，与操作系统连接的实时接口变得更加普遍，它们减轻了对跨系统复制数据的需求。但是，一个新系统要使用这些实时接口之一，仍然需要一些工作来将它连接到集线器。诚然，在中心辐射型架构上所做的许多尝试仅仅稍微减轻了点对点问题，向一个运行时和一个工具中引入了点对点编码。除非集成是针对重用而小心设计的，否则创建一个新接口仍然需要大量新代码。
我们需要一种更加标准化的方式来从集线器公开功能，以便无需额外的工作即可重用它。
在 2000 年代初，随着传输、协议和数据格式标准得到更广泛的采用，比如 SOAP/HTTP（通常称为 “Web 服务”），以标准化方式公开服务成为可能。这意味着请求者（他们理解这些现代标准）通过最小的努力就可以使用这些服务。这些公开的业务功能的直接重用现在已变为可能。一个经过良好控制的公开服务套件应该具有 SIMM 级别 4。
任何重用机会都会带来新的收益，同时也会带来新的挑战。使用 SOAP/HTTP 简单地公开业务功能，不足以确保服务的健全性。它会带来许多挑战，从系统间难以管理的依赖性到安全暴露。
从服务公开的角度讲，SOA 比协议和数据格式的标准化复杂得多。要有效地公开服务，还需要标准化以下方面：
这篇教程的开头已经更详细地描述了这些方面：WebSphere Process Server 和 WebSphere ESB中的解决方案设计。
要实现上述所有标准化，您需要正式地分离架构中的服务公开功能，如图 4 中的服务公开网关所示。它可能不是最终的物理架构中的一个单独的运行时组件，但至少需要在设计中明确地描绘它。必须可以以一流的方式满足虚拟化、可视性、安全和流量管理需求。
您将注意到，我们在图 4 中所示图表中特意未 使用常见的 SOA 相关术语，企业服务总线 (ESB)。这是因为人们对 ESB 的准确界线存在很大的分歧。毕竟，ESB 是一种架构模式，而不是组件描述。有人说，它只是服务公开网关，而其他人认为它包含集成集线器。有人认为它也包含适配器，在这些观点之间还有许多变体。有大量文献描述了 ESB 模式的细节，但我们最终发现，清楚地描述各个具体的组件和它们的职责会更好。
除了 SOA 的运行时组件之外，还有治理方面。如果有大量服务，您如何决定要公开哪些功能和它们的优先级？人们将如何发现所公开的功能？您如何控制所使用的数据模型中的变化？必须保留候选和当前服务的某种形式的目录，以实现服务生命周期的治理。
所有这些担忧最终可归结为，公开服务不是小事。如果只是简单地将功能公开为通用的 Web 服务，则会在可管理性和安全性上带来大量失败机会。简言之，重用具有代价，而且随之而来的是如何找到 SOA 的问题。任何具有紧张的最后期限和预算限制的项目，都不希望成为首次构建某个服务的项目 - 至少不太合适。
除此之外，事实上，人们实现 SOA 概念所需的标准是在 SOA 举措实施过程中不断开发的，因此它们还不够成熟。在企业尝试实现它们的过程中，它们也在不断改变。很容易看到为什么一些 SOA 难以获得发展动力。在许多公司，SOA 被局限在业务的一个特定领域，或者实际上只有少量核心服务在起作用。
基于浏览器的应用程序变得更加复杂，而且引入了一些机制来编写功能更丰富、响应更迅速的网页。这些机制利用了浏览器愈加成熟的客户端脚本功能，以及它们使用 AJAX 等技术执行后台 HTTP 请求来检索数据的能力，而且用户体验不会被页面预加载中断。
网页通常通过页面关联的 Web 服务器来请求特定于网页的数据。SOA 中常见的 SOAP/HTTP 请求在 JavaScript 中很难处理，而且请求的发送常常使带宽很低的 Internet 连接变得不堪重负。执行更细粒度的数据请求正快速变得流行起来，如果可能的话，可以更改为使用 JavaScript 原生的 JSON 数据格式，如图 5 中的红色区域所示。
由于不受 SOAP 标准的限制，这些接口可被视为简化在要表示的数据上执行 “动作” 或 “操作” 的方式的备用方式。在一次对 Web 早期根源的有趣的回溯中，HTTP 背后最初的意图被揭示了出来。HTTP 标准的许多方面是围绕 Roy Fielding 在 2000 年 提交的具象状态传输 (REST) 的架构原则而设计的。由此衍生出了一种基于实体的更加简单化的交互风格。该交互风格推荐以一种与常见数据库交互洞察（创建、请求、更新、删除）类似的方式，使用常见的 HTTP 洞察（POST、GET、PUT、DELETE）。全球网络以一流的方式识别这些洞察，以提供隐含的好处，比如缓存。它还使用 URL 路径来导航数据实体之间的关系。
在一个更加简化的示例中，可以想象向一个订单添加一个商品的过程，可通过向一个 URL 发出 HTTP “POST” 来执行此操作，这个 URL 类似于下面这个 URL：
https://www.mycompany.com/orders/123456/item
HTTP 请求正文中的 JSON 格式数据类似于如下形式：
{ "title" : "Romeo and Juliet",
"note" " "Special Edition",
"quantity : 1,
"price" : 9.99 }
其中 URL 描述了特定的数据实体（通常称为 “资源”），HTTP 动词 “POST” 的使用意味着它是一个新订单项的 “创建” 操作。要在 SOAP 中承载同样的信息，代码更类似于如下形式：
http://www.example.org/ordermanagement HTTP/1.1
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://..." soap:encodingStyle="http://...">
...SOAP headers...
<soap:Body xmlns:m="http://www.example.org/ordermanagement">
<m:AddOrderItem>
<m:order orderid="123456"
<m:item>
<m:title>Romeo and Juliet</m:title>
<m:note>Special Edition</m:note>
<m:quantity>1</m:quantity>
<m:price>9.99</m:price>
</m:item>
</m:order>
</m:AddOrderItem>
</soap:Body>
</soap:Envelope>
与之前出现的越来越复杂的 SOAP 标准相比，这些基于 JSON/HTTP 的接口提供了一些有用的简化。但是，SOAP 拥有更庞大的 标准集合，它们可完成这些接口做不到的许多事情。它们被不同的受众使用，而且不是所有这些标准在该领域都是必要的。
至少在最初，这些新接口的可重用性上存在一些限制。由于浏览器实现的 同源策略，基于网页的应用程序很难（但不是不可能）向其他公司提供的接口发出 HTTP 请求。这意味着，这些基于 JSON/HTTP 的接口最常见的初始用途，是用在公司的网页与其自己的企业数据之间。但是，一些技术（比如代理、JSONP）和标准（比如 CORS）减轻了这些限制，使这些接口能够得到更广泛的重用，使 “Web API” 变成了现实。
对于 “Web API” 的准确含义，没有正式的定义，就像在它之前的 “Web 服务” 一样，但我们会尽量明确它的含义。
大体上讲，“Web API” 通常指通过以下方式公开的功能和数据：
对于如今任何创建新 Web API 的人，这可能是您的起点。但是，从某些层面上讲，此定义过于简单：
所以出现了一种新的、更加轻型的协议和交互风格，但单单此协议和交互风格无法为向实时数据集成的演化保驾护航。
在 2007 年左右拥有容易访问的 “应用程序” 商店的智能电话成为主流时，业界发生了重大变化。移动应用程序（“app”）开发得以普及，而且庞大的开发人员群体都可以参与开发。除了一些明显的例外，应用程序很少能单独运行。它们需要与周围世界交互。开发人员如果拥有简单的途径来整合对其他公司提供的数据和功能的访问，他们就能够编写强大得多的应用程序。
这不仅是来自移动应用程序开发人员的要求，功能更丰富的网站的开发人员也需要更广泛、更轻松地访问数据。但是，移动通常会带来大量新的 Web API 用户。他们没有安全限制方面的阻碍，这些阻碍给基于浏览器的应用程序中的 API 使用带来了一些挑战。所以，您可以认为，Web API 的引入有两种重要影响：需求和能力。
正是在新需求及其关联的融资模型中，大数据发挥着重要作用。公开的业务功能的受众位于企业外。如图 6 所示，SOA 服务更常见的是在企业内 公开，一般基于一个项目漏洞和它们各自已知的需求。Web API 通常在外部 向常常未知且可能庞大的用户群公开，通常用于高度创新性和无法预料的用途。
如果一个 Web API 可提供对一个应用程序有用的数据，那么它对其他应用程序可能也有用。将这些服务（或 API）放在网络上，而且 Web API 突然会获得整个互联网的潜在用户，甚至可到达许多以前无法接触到的细分客户群。这离不开新的融资模型。我们有机会从这些公开的业务功能中牟利。Web API 变成了组织提供的一种新 “产品”。
投资回报可能具有许多不同的形式：
可以肯定的是，通过将应用程序设计师的创新众包到企业外，可获得新的市场。
您如何迎合对您的集成架构的需求的这一重大变化？
基于 Web API 的早期定义，您可以看到，与企业服务相比，在公开外部 Web API 时有 3 个重要方面将发生根本性改变：
这些关键的不同会导致您架构和设计 Web API 的方式发生大量的修正。在本教程中，我们主要关注架构的区别。在架构上，您显然仍然需要某种形式的公开网关，但对该网关的需求拥有一些新元素。
回想本教程之前的内容，重用始终是有代价的。从图 7 中可以看出，您的公开能力需要扩展到核心 SOA 需求以外。
我们看看这些新挑战的两个主要方面：
这种增加的复杂性导致了现在所谓的 API 管理 的出现。Web API 管理是一种架构意图，而不是单个组件，尽管它们显然是 专为该意图而设计的产品。它使组织能够简单而又安全地公开和管理 Web API。它将一种更健全、更安全的网关与和合作伙伴管理相关的功能相结合。
图 8 显示了实现 API 管理所需的主要组件，以及所涉及的典型角色。
所有这些角色都在 SOA 中以一种或另一种形式松散地呈现，但它们的实现通常不那么正式。Web API 面向公众的事实已迫使它们变得成熟。典型的角色集合为：
Web API 网关只是 Web API 的表面或暴露点。它没有提供 Web API 所提供的任何实际功能或数据。这让我们能够了解集成架构在企业内演化的全过程 - 从孤立的应用程序成长为点对点通信和中心辐射型中间件，进而潜在地实现 SOA。
诚然，在决定 Web API 的底层实现应来自何处时，高度依赖于企业的演变方式。图 9 显示了最常见的选项的例子：
人们很容易认为重新公开现有服务（图 9 中的选项 A）是最常见的。毕竟，SOA 已存在 10 多年，肯定大部分公司都已拥有一套服务。公开这些服务将是从以前对集成的投资中获利的最高效方式。尽管肯定有一些组织在这么做，但由于以下原因，这可能没有您预料的那么常见：
因此，图 9 中的选项 B 可能很常见，而且 Web API 使用集成来实现。或许他们在集成集线器本身内重用组件和适配器，但未重用现有服务。
选项 C 目前很少见，因为想要的 Web API 几乎肯定不同于现有应用程序。Web API 网关通常拥有有限的数据转换功能。但是，一旦集成逻辑远远超越基本的数据映射和简单聚合，Web API 网关在架构上就不再适合此逻辑。
在当今时代，人们渴望减少内部基础设施占地空间，企业在寻找更容易从基于云的提供商获得的功能。API 管理是一个不错的例子。Web API 网关和 API 管理功能都拥有明确的责任，所以它们很容易与内部架构分开，如图 10 所示。因为目标是向外部相关方公开它们，所以托管来自基于云的提供商的 Web API 具有一定的合理性。
尽管与具体企业相关，但这种基于云的 API 管理特别适合 “诞生于网络” 的公司。举例而言，一家创业公司选择不建立内部基础设施，将所有功能托管在基于云的环境中。基于云的 API 管理使他们能够提供单个统一的公开点来供用户查找他们的 Web API，无论这些 API 托管在云中的何处。
使用此方法，您需要考虑以下因素：
新的 “REST” 风格的 JSON/HTTP 接口更加轻量型，适合且受现代编程语言和框架支持。API 管理网关产品越来越成熟。为什么还要在企业内利用所有这些优点？许多人现在将内部 API 管理层视为一种替代方案，而且在一些情况下，是一种在企业内公开数据和功能的更有效方式 - 图 4 中所示的服务公开网关的扩展。
图 11 显示了实现内部和外部 API 的单一管理点所需的最低限度的架构配置。这带来的附加优势是，内部用户可直接使用外部公开的 API，而无需路由到互联网。事实上，企业常常仍然更喜欢拥有单独的内部和外部 API 网关，以实现更可靠的关注分离。
所以对一些人而言，API 已成为其公司内朝面向服务的架构发展的旅程中的下一个阶段，以及它们实现外部公开的机会。
另一个值得考虑的案例是，不断成熟的 Web API 技术和实践被用于提供业务间 (B2B) 通信。B2B 接口从任何角度讲都不再新颖。几十年来，企业已使用了各种标准来交换数据，比如与电子数据交换 (EDI) 相关的标准。由于针对特定行业需求的专门化，用于实现它们的标准和工具必然非常深入和复杂。许多企业需要一种更加轻量型的备用方案来交换数据，但它们仍然需要满足一些核心需求，比如安全功能和合作伙伴自助管理。即使公司未计划向一般大众提供 API，对 API 管理的安全性和合作伙伴管理方面的利用可能对实现与特定业务合作伙伴的简单的私有接口很有价值。
尝试猜测由于最近几年此领域的技术进步，集成架构会如何发展，会很困难且可能很愚蠢。但是，这似乎涉及到进一步认识移动用户近期的现状。一个重要因素是，对于更庞大的社区，人们对 “始终在线” 的渴望仍转变为 “间歇性连接”。
这意味着基于消息的事件驱动的交互的复兴。我们已看到更多基于事件订阅的交互模型。例如，所有主要移动供应商都拥有向设备推送事件的机制。传感器现在能够在得到更广泛认可的协议中发出事件，比如传感器与事件订阅者之间不那么专门的耦合。“物联网” 正在一切事物中都引入传感器，从可穿戴技术到互联汽车，再到一种不同类型的应用程序。这些可能不太关注从操作系统中获取的特定数据，而更重视密切注意所关注的主题，智能地解释所收到的事件。
回头看看 图 1，您可以看到集成架构如何实现向更多的公众渐进地公开业务功能，还可看到用于实现这一公开的功能的不断成熟。API 管理是这一领域的最新技术，认识到不断开发的模式、技术和概念（比如中心辐射型架构和 SOA）在正确的情况下仍有用且合适，这很重要。
本教程是在集成主题上与 Brian Petrini 定期和持续协调的结果。
(转)集成架构：对比 Web API 与面向服务的架构和企业应用程序集成
标签：
原文地址：http://www.cnblogs.com/ywcz060/p/5449169.html
