在任何领域中，语义都非常重要，而在面向服务的体系结构（Service-oriented architecture，SOA）中更是如此。由于 SOA 涉及多个团队和组织，因此就相关术语达成一致至关重要。本系列将带着您开始 SOA 之旅，为您定义基础术语和主要概念。您将了解 SOA 领域中所使用的各个词汇。对于每个术语，将说明其为何对 SOA 重要、其在这种情况下的含义、相关的标准有哪些以及与其他术语的区别如何。
以下列出的术语并不是按照字母顺序排列的，也不是按照其重要性进行排列。我们将按照构建块的方式对其进行排列。首先讨论的是“服务”，因为这个术语可能是理解 SOA 框架的最基本概念。我们将以服务为基础形成“体系结构”、“治理”和“业务”概念的定义。在很多情况下，我们都将较大的术语分解为较小的组成部分进行讨论。
服务显然是面向服务的体系结构的核心，术语服务 的使用非常广泛。不过，这个术语对于不同的人有不同的含义，“什么是服务？”这个问题经常会引发激烈的争论。我听到过人们讨论业务任务、业务服务、应用程序功能、技术服务或基础设施服务。我将基于 IBM Rational® Method Composer Plug-in for SOA Governance 和 IBM Rational® Unified Process for Service-Oriented Architecture 给出一个定义。
“服务是执行可重复任务的可发现资源，由外部化的服务规范进行描述。”
由于存在多种不同的定义，通过定义“服务”来开始本文的讨论比较困难。例如，您可能会认为上述定义过于偏重于技术。请记住，一定不要过于依赖于服务的正式定义，而要将重点放在服务背后的主要概念上，包括：
- 业务一致性：服务并不基于 IT 功能，而是基于业务的需求。服务业务一致性由服务分析和设计技术提供支持。
- 规范：服务是自包含的，采用接口、操作、语义、动态行为、策略和服务质量进行描述。
- 可重用性：服务可重用性由服务粒度设计决策予以支持。
- 协议：服务协议是实体（即服务提供者和使用者）之间就相关事项达成的一致意见。这些协议基于服务规范，而不是实现。
- 承载和可发现性：随着生命周期的进展，将承载服务，并可以对其进行发现；这由服务元数据、注册中心和存储库提供支持。
- 聚合：松散耦合的服务聚合为企业内部或企业间的业务流程或组合应用程序。
这些组合特征表明 SOA 并不仅与“技术”相关，而且也与业务要求和需求相关。
还要务必注意，并非所有东西都是服务。例如，有些 IT 功能不应该作为服务公开。可以使用 IBM 的面向服务的建模和体系结构（Service-Oriented Modeling and Architecture，SOMA）等分析技术基于上面列出的概念标识恰当的服务列表。我们将在本文中详细讨论这些方面的内容（包括本部分中所有以粗体显示的术语）。
和服务类似，很难得到一个大家一致认可的体系结构的定义。不过，与服务不同的是，人们在谈论 SOA 时有时候会忘记体系结构，而显然不应将其忘记！事实上，企业体系结构和面向服务的体系结构具有相同的目标，即通过集成的 IT 策略支持业务。例如，企业架构师是 SOA 成功的关键，因为他们将根据不断发展的业务需求和要求确定企业的 IT 系统的策略发展方向。
Open Group Architecture Forum (TOGAF) 根据上下文提供了两个体系结构定义：
- “系统的正式描述，或用于指导其实现的组件级别的系统详细计划。
- 组件的结构、它们相互间的关系以及控制其设计及将来发展的原则和指导方针。”
这两个定义都与理解 SOA 中的“A”相关。对其进行进一步细分，我们会发现体系结构对于进行以下工作必不可少：
- 在不同的抽象级别进行设计和建模
- 将规范与实现分离
- 构建灵活的系统
- 确保满足业务需求
- 分析需求更改的影响
- 确保遵循相关原则
以下是维基百科 (Wikipedia) 中的定义：
“企业体系结构是这样一种做法，即应用描述组织的流程、信息系统、个人和组织子单元的全面而严格的方法，从而使其与组织的核心目标和策略方向保持一致。
创建企业体系结构的主要目的是为了确保业务策略与 IT 投资保持一致。通过这样，企业体系结构可支持从业务策略一直到基础技术的可跟踪性。”
可以将项目级别的“体系结构”和组织级别的“企业体系结构”与此进行比对。请注意对流程、信息系统、人员、目标、策略和业务 IT 一致性的参考信息。
