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之外的世界。