SOA治理和所有权

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

　　所属域所强加的约束对IT来说是无人不知了。这种对资源获取的约束会导致IT开发的重复建设，IT产品发布的失衡，给企业架构与技术路线图的稳定带来麻烦，还会加倍点对点的杂乱集成。只有垂直地治理业务和IT，两手抓两手都要硬，设置好策略并定义好能为这些策略提供可操作的上下文的规则，才能同时对业务和IT的管理产生积极的影响。举例来说，一个业务治理主体可以设定策略规定所有业务客户都有拥有相关业务数据的权利。IT治理主体声明了这一规则，赋予权利的第一步就是基于PKI技术的用户认证服务。现在，IT管理部门就可以指明谁是可以被相信并确认的PKI发放主体，以及实际的认证过程当如何进行了。设定条例和规定并不能确保有效的治理，除非其遵循程度可以被衡量。根据这些量化指标，条例和规定能得以推行。矩阵，就是那些能被衡量的条件和数量，通过它可以表示服务行为跟策略和契约的契合程度。条例和规则必须以所收集的矩阵为依据，否则管理层就没有办法来评估其一致性。对于服务交互的参与者和治理主体，矩阵应当是都能获得的，以保证其衡量的结果每个人都清楚。

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

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

　　IT SOA治理的考量

　　在企业内利用SOA原则的一个重要好处，就在于快速地征用和重新分配资源以应对业务和IT方面的突发及演变着的情况的能力。它还要求对这些资源的利用方式应具有相当的灵活性，以及对服务能力的要有足够的信心。一个符合前述要求的并可以通过IT实现的业务服务的概念。这一概念与其它概念的根本不同在于，它将模型驱动架构原则和基于组件的设计结合到了一个垂直专注结构(VDS)里。这样一个VDS聚集了一个对某个业务任务进行端到端处理的内聚的功能集合。

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

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

　　服务结构 ── 组成一个服务的最小元素集合，以及元素关系和操作模型(开发，集成，部署策略)

　　SOA基础设施 ── 配给那些基本公用功能，以支持对服务的使用(部署和运行时策略)。

　　服务清单 ── 对一个服务的需求，以便可以在基础设施内通过公开接口手动或自动访问它(管理策略)。

　　参与者交互 – 所有服务交互的参与者都需要遵从的一贯预期(可达性和运行时策略)。

　　SOA RA PRD 1:

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

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

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

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

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

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

　　服务功能性

　　服务接口

　　服务可达性

　　服务通讯/调用策略(可供参考)

　　对于客户而言很重要并可能影响服务RWE的服务执行策略，服务行为特征和相关矩阵。

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

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

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

　　一个服务描述文件的模型。我们可以看到，

　　服务可达性定义了服务访问的物理点

　　服务接口将服务提供的逻辑接口进行了分组

　　服务功能表达了RWE

　　策略定义了服务执行上下文(EC)

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

　　一个服务描述可以识别一组功能的集合(例，功能性)

　　一个服务描述可以识别一些功能接口

　　服务行为由具体指定的EC来允诺;如果一个服务要在这一具体的EC之外的另一个EC里重用，该服务需要被重新测试以验证它能否提供同样的RWE。

　　服务契约来源于服务描述

　　服务功能可以由服务接口操作来反映，但这并不是必需的。举例来说，一个服务(服务描述)可以允诺对服务的每次调用执行审计日志记录，而消费者可以依赖于这一特性。日志记录并未通过服务接口来代表，但通过消费者自己的审计支持，它可以减少消费者的工作。在这个最简单的例子里，一个功能与一个接口操作相对应，而接口也仅只包含一个操作，行为模型，以及信息模型和可达性(协议和端点)。拥有多个接口的一个简单例子是一个构建于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 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治理由企业自顶向下，从业务到技术二者兼顾，增进提升灵活性与可适应性的概念。