扩展 SOA - 在大型组织中实现 SOA 的模式

引言

SOA，面向服务的架构，是一个众所周知的时髦词，它在 IT 市场已经流行了大约两年，并且从一开始就赢得了业务所有者和项目经理的心。如今，由于技术支持不断进步，SOA 也开始改变软件架构师的观点。现在似乎终于有可能构建一个由可重用、可扩展的组件组成的应用程序，这些组件能够以简单有效的方式进行通信。似乎有可能将业务流程耦合起来，将技术解耦，并赋能基础设施。但是，要实现这一目标，SOA 必须由业务驱动。实现 SOA 方法的关键在于分析和记录组织内的所有业务流程，从而精确而全面地定义业务领域、边界、服务和消息。

这种基于服务的、跨越组织、部门和企业领域边界的方法对构建解决方案是有意义的。因此，SOA 对大型组织来说是一个非常有趣的概念。但这类组织在 SOA 的实施方面尤其困难，因为业务流程定义不一致、使用的技术不同以及基础设施分散且异构。对许多软件架构师来说，这些问题使得在大型组织中实现 SOA 几乎不可能。

本文旨在介绍一种在大型组织中，利用现有业务流程和现有基础设施实现 SOA 的可能方法。

1 挑战

标准的 SOA 实现方法要求此过程必须由业务驱动。业务代表应与软件架构师一起分析和记录组织内的所有业务流程，如有必要进行优化，然后开始 SOA 的实现。但是，如果我们有可能构建或重写全球解决方案的一部分，但我们无法完全分析流程，我们对使用的技术影响有限，并且我们必须使用固定的基础设施（请记住：SOA 的目标是将业务耦合起来，将技术解耦，并赋能基础设施），那么我们应该遵循什么样的方法？我们能否保持 SOA 合规性？

1.1 定义

让我们回顾一下 SOA 最简单但非常好的定义之一：

“SOA 是一个基于松散耦合的组件（服务）进行消息交换的架构” [HJ00]。

1.2 业务

在一个大型组织中，业务常常跨越不同的部门、内部组织和国家，这使得为 SOA 目的对其进行描述非常困难。即使组织已经创建了良好、一致且全面的业务流程文档，相关方也可能以略有不同的方式理解它们。同一个全球性业务流程因例如不同的法律法规、市场上的特定情况等存在许多子版本，这并不少见。另一方面，我们将要实现的内部业务流程没有这类问题。我们已经全面分析并记录了我们的流程，并且能够轻松地定义我们的业务领域并为我们的应用程序需求描述服务。

1.3 技术

在大型组织中，我们发现的技术环境大多是异构的。我们无法轻易识别或假设我们的系统将需要使用或与之交换数据的系统和技术的类型。另一方面，我们的架构定义明确，我们将使用的技术构建了一个同构的环境。

1.4 基础设施

大型组织通常拥有不止一个软件开发团队、不止一个关键业务应用程序和不止一个应用程序中心。通常在这些系统之间会有一个中间件系统，负责它们之间的通信。这些系统提供了我们的应用程序也必须使用的功能。另一方面，我们的应用程序必须以一种明确定义的方式在此现有基础设施内为其他系统提供服务。

2 解决方案：扩展 SOA

前面主题中描述的所有问题和要求使得使用单一 SOA 解决方案实现 SOA 变得相当困难。尽管如此，我们能够将每个问题归类到架构的两个领域之一：内部和外部。因此，解决方案是使用两个 SOA 实现：内部和外部。它们共同构建了扩展 SOA。

2.1 架构

扩展 SOA 由两个 SOA 实现组成：内部和外部。通过这种方式，我们可以将来自业务、技术和基础设施方面的不同需求分散到两个实现上，而不会失去 SOA 的优势。

每个 SOA 解决方案都需要服务消费者，它们发送请求，以及服务提供者，它们发送响应请求。

在扩展 SOA 的实现中，我们可以识别以下服务：

• 外部服务
  它们代表由外部 SOA 的其他系统提供的服务。这些服务仅与中间件通信，并且不在我们实现的处理范围内。
• 中间件
  它充当外部 SOA 实现的服务消费者部分。中间件负责所有外部服务与我们的外部应用程序服务之间的通信，并且不在我们实现的处理范围内。
• 外部应用程序服务
  它们充当中间件的服务提供者，以及内部应用程序服务的服务消费者。这些服务结合并连接了两个 SOA 实现。
• 内部应用程序服务
  它们提供应用程序的核心功能，充当外部应用程序服务的服务提供者，以及基本应用程序服务的服务消费者。
• 基本应用程序服务
  它们提供应用程序的基本功能，简化了内部应用程序服务的构建过程（添加、更新、删除等）。它们充当内部应用程序服务的服务提供者。

2.2 范围内的服务

2.2.1 外部应用程序服务

外部应用程序服务（EAS）连接了两个 SOA 实现，因此是整个扩展 SOA 架构的核心元素。它们使用为该实现选择的消息和通信类型作为中间件的服务提供者。通过这种方式，我们能够提供符合公司全球指导方针和 IT 组合策略的服务，而不会影响基于内部 SOA 实现的内部架构。关键在于，我们不必构建尽可能通用的服务，支持尽可能多的使用场景。相反，我们可以遵循“价值提升范式”[GS00] 来构建现代软件，以敏捷的方式交付变更，从而能够支持不断变化的业务需求。构建 EAS 的推荐行为模式是中介者模式[CJ00]，它促进了组件之间更松散的耦合。

2.2.2 内部应用程序服务

内部应用程序服务（IAS）构建了我们应用程序提供的核心业务功能。它们允许定义明确的业务工作流运行和交换内部消息。但这些服务最关键的特点是能够改变服务的逻辑而不影响现有架构。通过这种方式，应用程序开箱即用，易于扩展，因此已准备好支持由例如法律法规或同一业务流程的市场情况引起的不同业务场景。实现这一目标的最佳方法是支持 COP（面向组件的编程），它允许轻松地分离接口和实现[LJ00]。构建 IAS 的推荐行为模式是策略模式[CJ00]，它由一系列依赖于特定上下文的相关算法组成。

2.2.3 基本应用程序服务

基本应用程序服务（BAS）提供基本功能，涵盖添加、更新、删除和过滤业务实体等流程。这些服务应基于具有明确接口的定义良好的应用程序框架。

2.3 消息

消息由参与 SOA 的服务进行交换。消息定义的关键问题是保持其简单、一致、可扩展且强类型。在外部 SOA 实现的情况下，我们的服务仅充当服务提供者（服务消费者是中间件），因此我们的消息应具有已知且确定的语法。外部 SOA 消息应包含一个定义所有涉及流程的上下文，以及这些流程所需的数据。此外，它还应包含对预期返回值和在发生异常时的行为的定义。内部 SOA 消息不必遵循此模式，并且允许其更加面向流程和技术。分析和描述业务流程，从而识别消息类型的最常见方法是使用 Pet​​ri 网。Pet​​ri 网是一种正式且图形吸引人的语言，适用于对具有并发和资源共享的系统进行建模[UH00]。

3. 结论

扩展 SOA 是一种在大型组织中，在现有业务流程、技术和基础设施内实现支持 SOA 的应用程序的模式。为了保持想法的简单性，我没有提及任何特殊的技术或平台（如 Web 服务），因为它们只是实现目标的工具。扩展 SOA 模式的关键概念是拥有“二合一”的 SOA 实现，即内部和外部 SOA 组合在一起，从而能够实现松散耦合的服务之间的通信及其更广泛范围内的可扩展性，而不是仅有一个。

关于作者

Adam Boczek 在企业架构和软件开发项目方面拥有超过 10 年的经验。他拥有波兰什切青理工大学的硕士学位，并且是使用 Microsoft .NET Framework 的 Microsoft 认证应用程序开发人员 (MCAD)。他是 LogicaCMG 的高级顾问，目前在德国汉堡的壳牌公司担任新架构技术主管。

尾注

• [CJ00] Cooper, J.: C# Design Patterns, USA 2003, Addison-Wesley
• [GS00] Guckenheimer, S.: Software Engineering with Microsoft Visual Studio Team System, USA 2006, Addison-Wesley
• [HJ00] Hasan J.: Expert Service-Oriented Architecture in C#2005 Second Edition, USA 2006, APress
• [LJ00] Lövy, J.: Programming .NET Components Second Edition, USA 2005, O’Reilly
• [UH00] On-line Resources: Petri Nets World, University of Hamburg, 2006
  http://www.informatik.uni-hamburg.de/TGI/PetriNets/