面向服务体系和遗留系统

这篇文章首次出现在 IEEE__ 软件杂志上。 IEEE__ 软件对当前战略性技术问题提供可靠的、业内同行的评述信息。为了应对可靠、灵活地运行企业的挑战，IT 管理者和技术领导者需要依靠 IT 专家来获得最先进的解决方案信息。

企业系统已经从单片孤岛（monolithic silos）快速发展为使用机制灵活、面向服务的分布式应用系统。为了跟上这一趋势，IT 组织必须近乎实时地调整他们的遗留系统，以面对商业变化的挑战，这一机会稍纵即逝。面向服务的体系（SOAs）已经演进成可灵活进行操作，并能连接业务进程和底层系统。Nicolas Serrano、Josune Hernantes 和 Gorka Gallardo 提供了当前 SOA 技术的概述以及如何在遗留环境中去演进。我很期待听到来自读者和这个领域具有前瞻性的专栏作家的见解，以及你们更多想知道的东西。— Christof Ebert

今天的业务必须能够灵活、快速地适应市场需求，但是即使很小的处理变化也会引起多个 IT 系统的重新返工，因为它们原本是设计成应用孤岛（application silos）的。为了保持它的竞争力，维护性的开发工作必须减少，然而 IT 系统却必须持续地演进。面向服务的体系（SOA）可以使基于孤岛（silo-based）的系统演进到面向服务的系统。它的设计思想包括松耦合、底层逻辑抽象、灵活性、重用和可发现性（discoverability）。1,2 在 SOA Manifesto 中还描述了其它一些指导原则。

SOA 初级知识中，最新奇之处在于它的基础框架设计是基于服务的，而不是聚焦在整个应用上。服务是小的、离散的软件单元，能提供特定的功能并在多个应用间被重用。SOA 应用了松耦合的设计理念，这意味每个服务都是分割的实体，它们对其它共享资源的依赖是有限的，如数据库、遗留应用或者 API。它在生产者和消费者之间帮助提供一个抽象层，从而有利于在不影响消费者的情况下来灵活改变服务的实现。SOA 对业务提供了许多益处，但它也不是灵丹妙药，可以包治百病。SOA 的优势在于：

• 使用自然地方法来对复杂系统建模，即不依赖于技术和平台、可以对来自不同提供商的服务进行集成；
• 推动使用松耦合，这对其与遗留系统的接口设计有帮助；
• 通过应用重用来提高效率，以减少成本和开发时间；
• 提高灵活性和扩展性，这样通过将现有应用集成，可以比较容易地开发出多种业务；
• 可以减少维护成本；
• 使系统间使用基于标准的互操作；
• 提供位置无关的数据访问，这可以通过任何通道，如智能手机、平板或笔记本；并且
• 允许使用增量的方法来快速满足客户需求，即通过增加一个新的服务来满足特定的商业需求。然而，SOA 不足之处在于：
• 在应用间很难实现异步通信；
• SOA 实现实时响应和高数据传输时会非常有挑战，这是因为 XML 强调地是健壮而非速度（尽管还可以选择其它方案，如 JSON）；
• SOA 有很多安全性缺陷，这是由于应用和系统使用了进程共享；并且
• 在逻辑上分离的系统间交互时，SOA 会涉及到复杂的事务管理。

向 SOA 迈进并不容易，有此意愿的企业必须意识到困难和固有的那些问题。无需多言，每个 IT 组织在 SOA 实现时都会经历许多权衡和折中，而且每条道路的距离也不尽相同。为了效率和灵活性，我们推荐在遗留环境中用增量方法来迁移到 SOA。

Web 服务（Web Services）

对于大多数组织来说，Web 服务是实现松耦合体系最简单的方式。通过一组基于 XML 的公开标准，如 WSDL、SOAP 和 UDDI，就可以具有互操作的能力，这些标准提供了定义、发布和使用 Web 服务的通用方法。

Web 服务是从 Web 应用演进而来的，实际上，它们是简化版的 Web 应用。Web 服务不再提供用户接口及其数据，而仅仅提供数据接口；呈现信息给用户的任务转而由客户端的应用程序来负责。因此，Web 服务是实现 SOA 最通用的方法，实际上，许多系统使用了 Web 服务但并没有把自己定义成 SOA。

SOA（和 Web 服务）的主要优势在于相同的服务可以被不同的客户端来使用。原先为 Web 应用设计的数据仍会被任何类型的客户端使用而无需更改。这其中的例子包括从服务器获取数据而无需提供显示 SQL 数据库查询的桌面应用，或者是那些从 SOA 服务获取数据的付费或公众的信息客户端。

遗留系统可以封装成 SOA 服务并对 HTTP 协议直接做出响应，或者它工作在代理服务器的后面，代理服务器负责将请求翻译成遗留系统的语言。最终，HTTP 中的消息是明文的，它可以来自任何系统或编程语言。

技术（Technologies）

当需要创建灵活的应用时 SOA 是一个好的选项，但如何去选择正确的技术来实现则依赖于你的需求和环境。为了那些愿意在自己的业务处理中选择 SOA 的组织，让我们一起来回顾那些最相关的技术考量。

SOAP 和 REST 的对比

当设计 Web 服务时，我们需要定义一组规则用来交换信息。当前最适合完成这个任务的工具是 SOAP 和 REST。3SOAP 是个老一点的协议，它是类似 CORBA 这样已有技术在互联网环境下的实现。SOAP 可以利用多种传输协议（HTTP、SMTP 等等），这给了它更多的灵活性。由于数据是在 XML 中交换的，所以当信息量和传输的消息较大时会有性能问题。SOAP 可以和 Web 服务安全（Web Services Security）一起使用，后者是个签名和加密消息的协议，它为消息交换提供了更多的安全性。4

REST 是新的协议，它也用 HTTP 作为传输协议，但它可以处理更多的数据格式，如 XML、JSON 等等，它依赖于特定的 URL 而不是 XML。REST 是 SOAP 轻量级的替代者。REST 在实现上没有那么多约束，所以他的灵活性更高，也更轻，对文档的依赖更少。与 SOAP 只能使用 POST 方法不同，REST 可以使用 Get 方法，所以缓存不仅可以在业务设计中去实现，也可以通过基础框架来完成。

具体选择 REST 或 SOAP 取决于组织需求和限制条件。一些时候，我们会选择企业应用能力更强的 SOAP，另一些时候，我们则选择更好性能和更轻量的替代者，如 REST。因为 SOAP 有更好的安全和故障处理能力，大多数企业级的 IT 商家都会把它作为优选的 Web 服务实现。而 REST 则具有简易、性能好以及实现上不那么严格的特性，这些使它成为 Internet 业务中实现协同工作 API 的优选。

遗留系统的更新改造（Legacy Modernization）

尽管 SOA 体系是无缝连接企业系统并减少协议 5 和平台阵痛的最好选项，但大多数人仍需要同现存的框架来打交道。当你试图采纳 SOA 体系来改造遗留系统时，并不存在一个完美方案，这是因为涉及到方方面面的因素。你需要对当前的技术堆栈进行考量，然后基于全局性的成本风险分析进行最优的系统迁移。

因为遗留系统通常都在支持关键性的业务处理，所以必须采取 step-by-step 方式的改造计划，并设计可行的演进方案使现有系统通过混合方法（hybrid approach）变为完全的 SOA 体系。这里有几种策略可以使遗留系统转化为 SOA 体系。

第一个方法是将当前遗留系统用另一个或一组系统替换。通常，如果当前商用现货系统（COTS）能够满足遗留系统的需求和功能，那么这种替换就是个好办法。这个方案减少了维护但增加了未来修改的成本。第二种选项是用中间件来封装现有遗留系统并通过 Web 服务来提供遗留系统的接口。用这种方法，遗留系统功能被封装在服务层里面并插接在 SOA 环境里面。这可能解决不了一些问题：遗留应用可以集成不同的几种服务，这时就不能象期望的那样对它们解耦。然而，当重写遗留系统代价太大、遗留系统可以重用，并需要性价比好的解决方案时，这也是个好办法。最后，也是第三个选项是重写开发和编码现有的遗留系统。这是个非常好的办法，因为你可以对应用的架构施加作用并得到最优的解耦层级。但是，遗留应用通常是关键性的，而且因为涉及到之前的技术以及缺乏文档，有些时候修改它们会非常困难或代价很高，这种修改可能会引起一些问题并增加项目风险。这种情况下，正确的评估涉及的所有风险是必不可少的。

企业应用集成（Enterprise Application Integration）

当在任何 SOA 行动中计划应用集成时，许多供应商的产品可以帮助你来简化这种迁移。然而，不同的产品在能力和复杂性上有所不同，所以选择正确的方案对于成功至关重要。你可以将这些选项基于集成的复杂性级别划分为三个不同的组（看图 1）

图 1 三种企业应用集成的框架

• 集成框架（Integration frameworks）是所有选项中最轻的，它基本由不同开发环境中的 API 实现库组成。集成框架的例子有 Apache Camel、JAVA 环境下的 Spring Integration 以及.NET 下的 NServiceBus。
• 企业服务总线（Enterprise Service Bus）产品提供集成框架的能力以及部署、管理和运行时监控的工具。ESP 支持在服务生产者和消费者之间的连接，因此在提供工具上具有优势，它可以显著减少成本和复杂性并且能在更高的抽象层来解决集成的问题。ESB 产品的例子包括 Oracle Service Bus 和 Mule ESB。
• 集成套件（Integration suites）提供全套的软件栈，它不仅提供 ESB 的能力，而且提供更多特定业务的工具，比如业务过程管理、业务活动监控、主数据管理和一个知识库。所有这些特性可以帮助你快速响应变化。一层层去理解这些竞争性的方案是比较困难的，所以表 1 对这三种集成方案做了一个对比。

表 1: 三种集成方案的对比

做出选择

很明显，做出最好的选项依赖于特定的需求和复杂性。首先，你先得决定框架是否已足够满足需求。例如，当你只有两个应用要连接或者你可以只用单个技术（如 REST）就能满足需求时，你就可选择最简单的方法（集成框架）而不用考虑它对工具和支持的缺乏；如果不是，那么 ESB 是一个不错的选择。但是，如果需要更多的特性，你就最好用一个更多能力和更复杂的栈，比如集成套件。

继续向前，下一个演进的步骤将是如何使 SOA 汇聚和使云计算变得容易。云的出现给企业带来的益处包括：云计算可以按需来提供资源，以容纳数据、服务和进程。

如此，在云上进行集成就成为企业今天要面对的一项主要挑战。在这样的场景下，iPaaS（integration platform as a service）作为可以满足广泛集成需求的适合选项就应运而生了。iPaaS 作为云服务套件，可以使户创建、管理并治理连接广泛应用和数据源的集成流（integration flows），而无需安装或管理任何的硬件或中间件。

展望未来，调研咨询公司 Gartner 预测到 2016 年，全世界至少 35% 的大中型组织将会使用一个或多个某种形式的 iPaaS 产品。然而，专家们以为 iPaaS 并不能取代 SOA，对于复杂集成场景传统的 SOA 仍然是需要的，比如企业内部或企业间的低延迟消息系统和数据密集交易系统。

参考

1. N. Gold et al., “Understanding ServiceOriented Software,” IEEE Software, vol. 21, no. 2, 2004, pp. 71–77.
2. S. Jones, “Toward an Acceptable Definition of Service,” IEEE Software, vol. 22, no. 3, 2005, pp. 87–93.
3. S. Mumbaikar and P. Padiya, “Web Services Based on SOAP and REST Principles,” Int’l J. Scientific and Research Publications, vol. 3, no. 5, 2013, pp. 1–4.
4. P. Louridas, “SOAP and Web Services,” IEEE Software, vol. 23, no. 6, 2006, pp. 62– 67.
5. S. Vinoski, “REST Eye for SOA Guy,” IEEE Internet Computing, vol. 11, no. 1, 2007, pp. 82–84.

关于作者

Nicolas Serrano是 Navarra 大学工程学院的计算机科学和软件工程教授 。他的研究方向包括信息技术及其在个人和职业发展上的应用。可以通过 nserrano@tecnun.es 来联系他。

Josune Hernantes是 Navarra 大学工程学院的计算机科学和软件工程教授 。她的研究方向包括软件工程和信息系统。Hernantes 从 Navarra 大学工程学院得到了计算机科学博士学位。可以通过 jhernantes@tecnun.es 来联系他。

Gorka Gallardo是 Navarra 大学工程学院的信息系统教授 。他的研究方向主要是信息技术。可以通过 ggallardo@tecnun.es 来联系他。

这篇文章首次出现在 IEEE__ 软件杂志上。 IEEE__ 软件对当前战略性技术问题提供可靠的、业内同行的评述信息。为了应对可靠、灵活地运行企业的挑战，IT 管理者和技术领导者需要依靠 IT 专家来获得最先进的解决方案信息。

查看英文原文： Service-Oriented Architecture and Legacy Systems