SOA治理：企业视图-InfoQ

“… SOA 治理之间的显著区别就在于理解企业协作的本性以及对于促进共同目标的信赖。” - SOA 参考架构 [1]

SOA 治理是目前 SOA 里面最热门又最微妙的话题。大约两年前开始，许多企业刚刚转向 SOA，因此可以从所谓的“绿地”开始。为什么却没有对 SOA 治理给予适当的关注呢？这也许可以有各种不同的解释，但这个情况提醒了我软件开发者的一条“金科玉律”——先试试，不行的话再查看有关说明。

那个时候，组织都相信 SOA 是一种用于集成和重用现有资产的 IT 新技术。集成与重用（神奇地）简化与加快了业务需要的实现。有的组织构建了数以百计的 Web 服务，最后在面对管理如此多集成点的难关时被生生地困住了。其它的组织也无从获得所期许的投资回报与市场投放速度（当你给卡车加上更多的轮子而使用的还是同样的引擎时，它就能跑得更快了吗？）。只有很少取得成功并向前迈进的案例。为什么会发生这一切？

依我看来，这些困难中的主要原因之一就在于，在面向服务的设计、实现及利用中，要么是根本没有治理，要么是还是按传统软件开发的方式治理的。例如，不理解面向服务的细节。这篇文章从企业的视角观察了 SOA 治理的细节，并通过几个 SOA 治理策略的实例进行了阐释。

何谓 SOA 标准中的“SOA”？

首先，我需要铺垫好共通的背景并定义好我们将谈到的一些事物。人们可以从 W3C、IBM、维基百科等等地方找到许多 SOA 的定义。我会使用另外一个定义，它来自于 2006 年年末 OASIS 发布的第一个专注于 SOA 的标准——SOA 参考模型（RM）[2]。这一标准将 SOA 定位于一个以业务为中心的架构范型。即是说，在 SOA 中，我们首先并仅仅谈到业务，其次才是技术——作为主要的面向服务环境。

SOA RM:
面向服务架构的关注中心是任务或者业务功能——完成实事

这篇文章使用了 SOA RM 标准和 SOA 参考架构，来自 OASIS 的 SOA-RA v1.0 公众评阅草案，(SOA RA PRD 1) [1]。这两者都强调了 SOA 以业务为中心的天性以及其适应业务变化的灵活性。

SOA RM:
… 在 SOA 中，服务是将需要和能力结合在一起的机制。

毫无疑问，OASIS SOA 是关于服务的。然而，SOA 里服务是一个不关实现的抽象定义，这可以帮助消费者获得真实世界效果（RWE）从而满足他们的需求。为了向消费者提供 RWE，一个 SOA 服务利用了其与独立的现有资源相关的能力。

SOA RM:
将执行上下文定义为：…一系列技术与业务元素的集合，从而在拥有需要的部分和拥有能力的部分之间形成一条通路。

一个 SOA 服务在一个由业务和技术上下文组成的“执行上下文”中进行操作。业务上下文包括业务模型、条例、以及能使 RWE 得到具体解释的规定。技术上下文是一个技术环境，使服务的技术部分得以执行。

不幸的是，就像我们在主流企业里所看到的那样，业务和技术上下文并存且分别演化着。这种分离是根源于业务与 IT 长期以来的传统关系，而其中隐藏着一个 SOA 的严重危机。举个例子，假设我们拥有一个服务，它的功能只是执行在英国数建筑的楼层这样一个简单任务，一个业务，即所谓“拥有需要的部分”，决定应用该服务在美国的技术实现，即所谓“拥有能力的部分”，并期待着同样的 RWE。当发现该服务在美国和英国提供的结果不一样时，你可以想像该业务最终是不满意的。这原因倒是很微不足道：该服务执行在不同的业务上下文，在另一环境里建筑物没有第一层并且紧接着 12 层的是 14 层。

近几年以来，SOA 变得与一些市场的陈词滥调联系起来，比如：“SOA 的目标是更好地整合 IT 资产”，或者“SOA 讲究的是服务重用”，甚至是“一个遗留应用通过 Web 服务包装就成了 SOA 服务”。我只能问——“真的吗？”[3] 所有这些陈词滥调都只是过于简化的技术理解罢了，而 SOA 是通过业务架构、技术架构和解决方案来对业务建模的。就像 Burton Group 的 Anne Thomas Manes 所说，“SOA 是一种系统架构风格，而不是架构集成。它是关于重构能力于服务，而不是关于集成应用竖井。” 我更可以说，就算是神乎其技的服务重用也不会是 SOA 市场的最佳候选，因为琐碎的 Web 服务重用若不是让企业成为市场的领袖，带来的就会是一场恶梦。这取决于 SOA 治理是如何定义和调节服务重用的 [4]。我们谈论服务重用也有二三个年头了，但服务治理呢——才刚刚开始；这就是 SOA 采纳如此困难的根源了。

SOA 治理

基于标准的治理原则

在 SOA RA PRD 1 中承认了企业的社会性结构在 SOA 中的地位。的确，服务交互参与者——服务消费者和提供者——的行为，只有对人，以及那些“拥有需要”的和“拥有能力” 的组织单元才有业务或技术意义。作为结果，我们可以说，如果一个社会性结构变化了，同样的行为也许会得到跟之前不一样的意义。甚至，如果一个消费者期望一个服务在不同的社会性结构中表现同样的意义，要满足这样的期望，那么只能是在不同的社会性结构中，服务将拥有不同的行为，并将产生不同的结果（或 RWE）。

**SOA RA PRD 1:
参与者所产生的行为… 通常是在一个社会性的上下文中执行的，而这一上下文正定义了这些行为本身的意义。 SOA RA PRD 1:

社会性结构：某种特定社会性上下文的体现 **

社会性结构这一观念跨越了组织内业务与 IT 部分的界限。这为 SOA 治理作为企业范围的治理模型并同时覆盖业务和 IT 打了下基础。这是一种非常自然的方式，因为 SOA 当中技术的主要目的是帮助组织达到 RWE 以获得业务利益。换句话说，SOA 及其治理的“本”是业务，“末”才是技术。

SOA RA PRD 1:
… 对于打算参与到服务交互的组织来说，很重要的一点是采取足够的治理策略和过程，以确保跨组织内部和外部边界的标准化，从而促进有效的创建和使用基于 SOA 的服务

正如 SOA RM 所述，一个企业范围的服务导向概念可能导致向不同的所属域分发业务和技术能力。这是一个特别的论题，我们将在以后谈到。现在，我们只需指出所属域的结构以及企业本身都会在 SOA 治理的层次结构中得以反映。因此，我们确定了以下的 SOA 治理结构：

企业 SOA 治理，作为企业治理的一部分
企业 SOA 治理包括：
- 业务 SOA 治理
- IT SOA 治理
  - IT 开发 SOA 治理

SOA 治理牵涉到根据策略与规定作出决定。而正是管理层才牵涉到执行策略和掌控权。这解释了为什么通过治理在一个企业内，SOA 能得以拥有跨管理域的独特能力，而没有其它任何根植于技术的架构在此之前能做到这点。SOA 治理在企业内部所影响的范围如图 1 所示。

SOA RA PRD 1:
既然 SOA 调节着人们关系中重要的一方面，就必然需要有参与者输入要求被社区执行的承诺，而 SOA 本身必须反映社区本身的需求。这两者都是面向服务架构治理所涉及到的方面。我们模型 [M.P. - SOA RA] 关于治理的关键元素就是，社会性结构的体质、社会性结构的策略、社会性结构中的权威、以及相关的执行机制。

然而，SOA 治理无法取代企业治理，或是业务治理，或是 IT 治理。我们必须记得 SOA 之外的世界。

SOA 治理和所有权

所属域在治理结构中扮演着极为重要的角色。在一个单一的所属域中治理通常是层次性的，包括公司、业务线（LOB）、业务单元（BU）、技术、IT 以及架构治理。在一个拥有多个所属域的环境下，治理无法以在单一所属域下同样的方式执行了，而是必须基于所接受的治理权威。举例来说，在一个基金管理公司，某个零售业务线开发了一个基金交易业务服务；该零售业务线既是服务的所有者，同时可能是服务的提供者。该组织的工业业务线可以在工业客户的 Web 站点上重用该服务，而只需与服务的所有者建立合约关系并承认零售业务线对该服务的治理权威。

所属域所强加的约束对 IT 来说是无人不知了。这种对资源获取的约束会导致 IT 开发的重复建设，IT 产品发布的失衡，给企业架构与技术路线图的稳定带来麻烦，还会加倍点对点的杂乱集成。只有垂直地治理业务和 IT，两手抓两手都要硬，设置好策略并定义好能为这些策略提供可操作的上下文的规则，才能同时对业务和 IT 的管理产生积极的影响。举例来说，一个业务治理主体可以设定策略规定所有业务客户都有拥有相关业务数据的权利。IT 治理主体声明了这一规则，赋予权利的第一步就是基于 PKI 技术的用户认证服务。现在，IT 管理部门就可以指明谁是可以被相信并确认的 PKI 发放主体，以及实际的认证过程当如何进行了。

图 1. SOA 治理的影响领域

设定条例和规定并不能确保有效的治理，除非其遵循程度可以被衡量。根据这些量化指标，条例和规定能得以推行。矩阵，就是那些能被衡量的条件和数量，通过它可以表示服务行为跟策略和契约的契合程度。条例和规则必须以所收集的矩阵为依据，否则管理层就没有办法来评估其一致性。对于服务交互的参与者和治理主体，矩阵应当是都能获得的，以保证其衡量的结果每个人都清楚。

要引起重视的是，有效地处理不同的所属域，即使在同一企业内部，也是对治理最严峻的挑战之一。SOA 治理，在这一点上，要求在服务的开发与维护过程中采用面向服务的风格，这有别于传统的应用治理。面向服务的策略要求业务 / 技术团队、个人、消费者和开发者更多地考虑到同时与每个服务有限的所有权结合在一起的那些关系和依赖。这是为了 SOA 的灵活性和对市场需求的适应所付出的代价。

在有效的 SOA 治理中，策略和规定必须平衡。为了能跨越不同所属域，可以通过以一种更像是提建议的方式来表达策略从而取得这种平衡，建议可分为几个等级，如强制的、强烈推荐的、推荐的、受限的、禁止的等等。平衡的过程要求有一定的流程和执行适当的纪律；这同样也包括对策略遵从的验证，看是否有异常。这种平衡的主要要求，是要考虑到现在的和将来的业务需求，它们由所治理的服务和整个 SOA 生态系统的灵活性来处理。

IT SOA 治理的考量

在企业内利用 SOA 原则的一个重要好处，就在于快速地征用和重新分配资源以应对业务和 IT 方面的突发及演变着的情况的能力。它还要求对这些资源的利用方式应具有相当的灵活性，以及对服务能力的要有足够的信心。

图 2. 业务应用和服务组织

图 2 说明了一个符合前述要求的并可以通过 IT 实现的业务服务的概念。这一概念与其它概念的根本不同在于，它将模型驱动架构原则和基于组件的设计结合到了一个垂直专注结构（VDS）里。这样一个 VDS 聚集了一个对某个业务任务进行端到端处理的内聚的功能集合。

一个 VDS 代表了一个业务服务，或业务功能，或业务特性，或者它能够被应用于更加复杂的聚合中以形成业务流程。每个 VDS 的层次化组织支持了对资源的重组和重用，另外，出于业务应用集成的目的，有些层次还可以直接由外部组件或服务访问（例如，服务接口和流程连接器）。通过这种途径，一个业务应用由一个或几个业务服务经业务流程连接器层编配而成，将编程工作降到最低（最小的市场投放速度）。虽然对这一业务服务模型的更深入探究暂且不表，我们仍可从中看出几个 SOA 治理的主题，比如层次之间分而治之，内部及外部的接口访问性，在技术服务与资源层之间共享实体等等一系列的策略。

因此，SOA 治理被应用于四个服务结构和服务使用的主要方面：

服务结构 ── 组成一个服务的最小元素集合，以及元素关系和操作模型（开发，集成，部署策略）
SOA 基础设施 ── 配给那些基本公用功能，以支持对服务的使用 (部署和运行时策略)。
服务清单 ── 对一个服务的需求，以便可以在基础设施内通过公开接口手动或自动访问它（管理策略）。
参与者交互 – 所有服务交互的参与者都需要遵从的一贯预期（可达性和运行时策略）。

**SOA RA PRD 1:… 服务功能性…描述了与一个服务交互时什么是可以预期的。

服务功能性，是对服务功能以及现实世界调用该功能的效果的无歧义表达。这些功能很可能是代表着一定领域里的业务活动并能产生出期望的现实效果。

服务功能性又可能受到技术假设的约束，而正是这些假设构成其能产生的结果的基础。技术假设可能与服务所访问的底层能力相关。

服务功能性的元素可以被表达成自然语言的文本，引用现有的功能分类学，或引用更形式化的知识获取，以提供更丰富的描述和上下文。**

尽管服务部署的 SOA 治理超出了这篇文章的范畴，接下来的小节对所提及的部分将更深入的进行讨论。

服务结构对于外界而言是透明的，尽管一些专注于客户的结构元素不得不可见以外。特别地，可见的服务结构是：

服务功能性
服务接口
服务可达性
服务通讯 / 调用策略（可供参考）
对于客户而言很重要并可能影响服务 RWE 的服务执行策略，服务行为特征和相关矩阵。

服务功能性，如 SOA RA PRD 1 中所定义，是 SOA 服务的主要元素之一。服务的消费者将功能性用于决定这一服务是否满足消费者的需求（需要）。这一类的元素还包括行为特征和相关矩阵。

所有可见的服务结构元素都在服务描述文件里作了描述以供公开使用。SOA 治理定义了相应的策略以规定服务描述的生命周期，它们所公告和存储的场所，使用的规则，以及它们的内容。

服务提供者使用服务描述公告可用的服务，同时服务消费者使用它们来进行服务发现。取决于特定的服务，发现可以是手动的，也可以是自动的。大家都寄希望于将来语义 SOA 互操作性能够对在服务消费者和提供者之间建立起关于服务描述里服务功能和 RWE 的表达的共同理解起到帮助。

图 3 说明了一个服务描述文件的模型。我们可以看到，

服务可达性定义了服务访问的物理点
服务接口将服务提供的逻辑接口进行了分组
服务功能表达了 RWE
策略定义了服务执行上下文（EC）

就这个模型而论，我们可以概述如下

一个服务描述可以识别一组功能的集合（例，功能性）
一个服务描述可以识别一些功能接口
服务行为由具体指定的 EC 来允诺；如果一个服务要在这一具体的 EC 之外的另一个 EC 里重用，该服务需要被重新测试以验证它能否提供同样的 RWE
服务契约来源于服务描述

图3. 服务描述文件的元素

服务功能可以由服务接口操作来反映，但这并不是必需的。举例来说，一个服务（服务描述）可以允诺对服务的每次调用执行审计日志记录，而消费者可以依赖于这一特性。日志记录并未通过服务接口来代表，但通过消费者自己的审计支持，它可以减少消费者的工作。在这个最简单的例子里，一个功能与一个接口操作相对应，而接口也仅只包含一个操作，行为模型，以及信息模型和可达性（协议和端点）。拥有多个接口的一个简单例子是一个构建于EJB 之上，包含RMI、CORBA 和Web 服务接口的基础设施服务。

SOA 基础结构

从 SOA 治理的视角来看，SOA 基础设施必须，或者说至少要包括三个部分－一个服务执行或运行时平台，一个可用服务的服务描述存储仓库，一个适用于服务公告和运行时的服务策略存储仓库。也许还有一些像服务注册（如 UDDI），ESB 服务仲裁，服务运行时监控系统等等其它的基础性元素，但这些都是可选项。一个服务描述存储仓库包括了 SOA RA PRD 1 中所提到的服务描述文档，并能跟服务注册相结合。

SOA 服务的用途受到高度推荐的方面之一就是服务契约。很重要的一点是要认识到服务契约是来源于服务描述。服务契约的主要不同之处是它服从于服务提供者和一个或几个服务消费者之间的共同协定，而服务描述仅是服务提供者对服务的公告。一个服务契约代表了服务描述元素的一个子集。同时，服务契约被认定于应当包括 / 参考到与某个特定消费者的服务水平协议（SLA）。不同的消费者可能对于同一服务达成不同的 SLA 协定，这依赖于不同的通信协议。

SOA 治理策略应当规定服务契约是否应成为服务描述的一部分，因为服务契约是与个体消费者之间的私有协定。这一私有特性的另一结果是继承或服务契约之间的交叉引用会是一件非常麻烦的事，或者干脆被禁止（一个消费者不会依赖于与另一消费者之间的未透露契约）。与此同时，继承和交叉引用对于策略来说却再普通不过了。

在某些情况下，与所有的消费者都保有同样的服务契约是明智的。同样，一个服务描述也可被用作拥有特别策略的单一共享服务契约，其中定义了服务使用的权威性条例。例如，一个安全服务对所有消费者都可能是平等适用的，并且不要求与个体消费者之间的协定。同时，一个服务契约的存储仓库也是 SOA 基础设施的一个推荐可选项。

服务清单

一些治理模型着力于处理如何避免服务重复，或者更精确一点，服务的功能性重复，这在一个严格环境里是一个首要的考虑。其它的治理模型提出了服务市场的建议，消费者可以有更广泛的选择。对于后者，它预期更好的服务可以通过市场的共识得以涌现，而由于替代者的可用性，将促使革新。

与此同时，如果一个重要的（就算不是任务关键的）功能只能通过一个服务来得到，这对企业来说是一个显而易见的严峻危机。不谈关于 IT 的冗余资源，在 SOA 里，我们必须关心服务的可达性，比如，有多种不同的方法在 SOA 中达到同一功能（虽然服务能力也许不尽相同）是有道理的。功能性，就此成为了服务清单里的一个重要的信息元素－只列出服务 ID，接口和名字不再够用了。

一个 SOA 清单可能是基于已经提到的服务描述存储仓库。在治理清单策略里可能详尽描述例如服务版本模型，新版本公告准则，服务下线流程以及 EOL 事件。

SOA 中的参与者交互

SOA 中的参与者交互是与 SOA 治理所设定的策略相一致的。每个服务提供者可能拥有其个人的本地策略，在服务描述中公告出来。为支持消费者可达到跨本地边界的服务，我们需要提供一个全局治理的形式。然而，就仅一个企业而言，能跨越所属域而达到共享语义和本体的策略，依我看都是一个巨大的挑战。

SOA RA PRD 1: …其目的是在于避免全局治理所指定的标准因为缺少对本地需要的深入理解而过于局限或过于松散。

SOA 当中的全局治理也许与我们在一个受规约的金融市场所看到的方式是一样的－可能有一个最小化的集中式标准化策略集，比如用于 Web 服务交互性的 WS- I 基本概要 [6]。然而，期望治理策略应当无处不在并能得到同等强制保证是不现实的。因此。一个有效的全局 SOA 治理方式看起来或许是这样：想要进行交互的参与者，必须遵守本地协定的治理策略。这突显了服务契约在 SOA 交互中的角色。

我们可以看到，服务治理由所有交互的参与者所聚集的治理策略所构成。这带来了根源于聚合服务而产生的有趣结果。在 SOA RA RPD 1 中声明服务交互至少需要两方的参与者并可以多于两个。让我们假设我们的案例中有一个服务消费者和一个聚合服务，即某个服务通过牵涉另一服务来实现其功能。这样，我们就有了几个服务参与者。每个牵涉的服务都有其自己的治理策略并对该聚合服务所承诺的 RWE 造成影响。这使得如何让治理能在服务描述中辨别出一条去选择和代表所有策略并能影响最终服务结果的规则，同时还保证服务契约的质量（完整性）成为了一个不可忽视的任务。

SOA 治理策略实例

我们之前提到 IT 中的 SOA 治理对服务的开发和生产阶段都有着影响。治理可以由小处入手并从专注于开发阶段开始。然而，它必须能为以后服务运行时提升灵活性和伸展性的 SOA 治理策略打下基础。下面是几个有用的 SOA 治理策略的实例：

适用范围

策略实例

治理过程

服务治理角色包括：服务所有者，服务提供者，服务消费者，服务看管人，服务登记员，等等
服务治理委员会包括来自业务，架构，交付以及系统运营等各小组的代表。治理小组的责任是：
- 定义和维护治理措施和策略
- 可能的情况下准予设计和实现的例外
- 服从并向管理层报告
治理策略和控制当由服务登记员，以及相应的评审委员会和架构主体一起监控并推行

开发阶段

服务的设计与开发必须要有强有力的理由才能允许有对策略遵守的例外
服务设计必须基于并考虑到所需求的业务任务的业务执行上下文。业务执行上下文应当能够概括在将来这些服务元素可能发生何种变化
服务设计必须为那些服务潜在的使用者考虑到业务运作的推荐场景。如果这样的场景能得以确定，业务批准和终止就是需要的
服务内部约束对于消费者应当是最小化或者完全隐藏的
一个服务对于内部问题处理的弥补应当对消费者透明并绝不能将其内部执行约束暴露给消费者
服务接口和服务主体（实现）必须遵循公司的安全策略
服务所有者必须为每个发布的服务提供服务分类（业务，基础设施等等）以及范围定义（业务单元，企业，外部等等）
““避免去搭建那种对于三个服务可以工作得很好的示例流程，而不去考虑当有三百个时该如何去做”（SOA RA PRD 1）。

生产阶段

所有的业务服务都被要求与它们所支持的每个消费者保持一份服务契约
所有服务都被要求发布服务描述
如果服务不需要服务契约，它的服务水平协议必须要在服务描述里发布
所有的服务都被要求符合版本策略，给所有的消费者提供迁移到服务最新支持版本的机会。
所有的服务描述必须在服务描述存储仓库里发布
所有的运行时服务策略必须在服务策略存储仓库里发布
运行时服务策略应参考其它的策略。策略应由策略执行点（PEP）拦截器来施行并由策略决策点（PDP）机制来保证
“…“… 考虑一下，显示少量的服务状态和活动，对于面对数打的服务并且每个服务还有着许多重叠或不同的活动这种危机情形下的操作员是否还会有效”（SOA RA PRD 1）

总结

SOA RA PRD 1:
没有所谓能一刀切的治理，而只有理解治理在 SOA 目标的上下文中所处理的事物类型的需求。有些社区一开始时可能会渴望和要求十分严厉的治理策略和过程，而其它的却对此需求很少。随着时间推移，最佳实践将会演化，可能会产生一个合理的最小集的共识，除了在一些极端情况下需要严格治理以外，在其他情况下，放松严格治理是有意义的。

SOA 治理是一个包括了对以消费者为中心的业务和技术服务治理的集成领域。SOA 治理并未显式地标准化，但 OASIS SOA RM 标准，连同 SOA RA PRD 1，在 SOA 的这一方面给予了重大的关注。

SOA RM 和 SOA RA PRD 1 确认了 SOA 的社会性影响并据此标定了 SOA 治理。在这方面，SOA 治理被看作是企业治理的一部分，同时覆盖了业务和跨 IT 归属边界两方面的相关问题。

这篇文章从治理的视角观察了基本的 SOA 服务结构元素，SOA 基础设施和服务交互。

SOA 治理必须要鼓励服务消费者依赖于它，鼓励服务提供者提供能在现代动态业务市场中满足业务需求的服务能力。为达到此目的，SOA 治理由企业自顶向下，从业务到技术二者兼顾，增进提升灵活性与可适应性的概念。

参考资料

Reference Architecture for Service-Oriented Architecture , Public Review of SOA-RA v1.0, Draft 1, OASIS
Reference Model for Service-Oriented Architecture , OASIS
M. Poulin. “ Does a Web Service Make a Service for SOA? ” , SOA & WebServices Journal, May, 2006
M. Poulin. “ Service Reuse and Entitlement ”, SOA World Magazine, March, 2008
Dmitri Ilkaev. “ Recent Trends in Semantic SOA ”, StickyMinds.com
Web Services Interoperability Organization (WS-I)

关于作者

Michael Poulin 是一名为 UK 和 USA 的不同金融机构工作的企业级解决方案架构师。他是 SUN 公司 Java 技术认证架构师，认证的 TOGAF 执业者，和 ZapThink 许可的 SOA 架构师。过去十年中，Michael 专攻于分布式计算，SOA 和应用安全。他的近作可以于 Sys-Con 媒体找到。

志愿参与 InfoQ 中文站内容建设，请邮件至 editors@cn.infoq.com 。也欢迎大家到 InfoQ 中文站用户讨论组参与我们的线上讨论。