面向服务架构（SOA）最终进入主流的讯号——虽不足为奇但耐人寻味——是越来越多的认为SOA实施失败的诉讼。情况是这样的：企业雇用大型咨询公司实施SOA，大型咨询公司派出他们的几个SOA专家达成交易，但实际上，SOA的设计及实施是由他们庞大而毫无经验的大学毕业生团队完成。企业对结果很不满意，因此控告咨询公司，声称他们已经支付了费用，却没有得到SOA。
　
　　Zapthink咨询公司要适应这个趋势，其原因其实是相当有趣的：毫无疑问，原告律师需要有人作为法庭的专家证人，可以明确指出什么是SOA，而更重要的是，能够明确指出什么不是SOA。那么还有哪家公司比Zapthink更适合寻求帮助？不管你相信与否，这是我们的业务成长的一部分。

　　因此，我们花了一些时间思考该在哪里划定SOA与非SOA的分界线。现在，如果没有这种悬而未决的诉讼，那么正在建立的架构是否是真正的SOA，倒有点无所谓；毕竟，建立的架构能否真正的解决某个商业问题。而把它称为SOA或非SOA则并不重要。但可能就是因为这个原因，关于SOA需要具备什么条件，市场上普遍的误解仍然存在，错误的信息仍在传播。所以，这个问题或许比其更有意义。下面是我们如何确定SOA与非SOA间的界限。 

　　判别SOA的最低标准

　　第一点要记住的是，SOA是架构，换言之，就是一套适合公司并使用IT满足其业务要求的最佳做法。不过，这一标准相当低，因为事实上所有的实施情况都遵循某种形式的组织原则。而这些原则是否是最佳做法，还需要进一步的分析。 

　　接下来，第二点要记住这样一个事实，SOA是一种面向服务的架构。因此，“服务”的定义，以及实施的架构是否面向这类服务才是关键问题。但问题是，即便是在IT领域，“服务”两个字也有好几种不同的含义；而且对SOA必须面向的服务种类——即SOA中的服务——进行标准界定，本是就一种循环的重复。我们还需要更具体的了解服务的含义。

　　第三个问题可能是Web服务是否与SOA的定义有关。SOA是否需要Web服务？显然不是。事实上，SOA既是一项技术，也是协定中立性的架构。如果喜欢的话，我们可以使用CORBA实施SOA，而且我们甚至可以创建一个完全的专有环境——专有的网络协议，专有的通讯协议，专有的基础设施，以及所有的东西——而且我们可以利用这个环境实施SOA，如果我们确实这样想的话。 

　　事实上，我们所称的服务，不仅是指Web服务，或是任何形式的服务界面。SOA中服务的本质是商业的抽象概念——即在松散耦合业务中对功能和/或数据的表述。那么，对SOA来说，实施一项抽象的业务服务是必要条件还是充分条件呢？

　　Zapthink的观点是，SOA的实施必须至少包含一项抽象的业务服务。不过，这项服务应该是怎样的松耦合，仍然需要进一步的解释。毕竟，耦合是一个复杂的领域，而且具有经济成本。如果该业务需要最小程度的松耦合，那么只要商业的抽象概念满足业务需要，SOA的实施仍可以服务为本。但是，我们说，任何商业服务都应该有某种程度的松耦合，从而具备业务服务的资格。如果所有的服务都是紧耦合，那么，任何服务的实施都不具备SOA的资格。这样看来，SOA实施的一个充分必要条件是它至少包含一个抽象的、松耦合的业务服务。

　　SOA的三条主线

　　但是，标准就是我们要说的全部吗？如果找到一个合格的服务，我们就可以从容地保证该实施就是SOA，然后放心不管吗？同样，如果没有这种服务——也就是说，如果确实存在一些不具备松耦合或抽象资格的服务，难道我们就可以肯定无法找到SOA吗？有这么多与SOA有关的问题， 作为SOA，需要具备的资格比看起来要更为复杂。事实上，需要考虑以下三个相关问题： 

　　1. 一直以来，我们只在考虑这一个问题：是否有一套最低限度的SOA必要标准？如果有，那么是什么呢？这样一套标准，要求从该名单中删除任何一项，都将使架构实施无法成为SOA。或者是否有一套另外一种最低标准，要求满足其中的任何一项，架构实施都应该被视为SOA？ 

　　2. 我们也可能要问，如何界定目标实施是“不好”的SOA还是“好”的SOA呢？不好的SOA也具备SOA的资格吗？目标实施要如何不好，我们才不应该称之为SOA？换言之，如果实施构成只有紧耦合的服务，那么是否可以说，它尽管确实是不好的SOA，但还是SOA呢？

　　3. 此外，目标实施是“不成熟”的SOA还是“成熟”的SOA呢？如果实施已经步入正轨，但根本不成熟，是否仍然具备SOA的资格？目标实施要如何不成熟，我们才不应该称之为SOA？

　　让我们先从问题1开始 。我们为SOA实施制定的最低标准是服务必须是（一）服务，（二）抽象的，（三）松耦合，及（四）业务服务。（一）我们可以这样说，需要有合同为服务指定接口。（二）要求服务在商业环境下能够为消费而掩饰软件的复杂性。标准（三）要求服务能够对一定程度的要求变化做出回应，无论是消费者的要求还是时间发生变化。标准（四），意味着是有业务背景的服务。此外，我们想补充第（五）点，架构必须支持服务组成。 

　　关于问题2，我们说，只要满足问题1中的四项标准，那么实施无论如何不好，或怎样的低质量都不重要，也就是说，不管怎样不符合实施要求都不重要。另外要注意，根据问题1的标准，如果没有找到松耦合服务，那么就不是SOA。现在很有可能，这个官司判决为实施的质量不高，但是这个问题应当与是否在技术上有资格作为SOA独立开来。 

　　问题3的解决可以举一个事实说明，例如我们只需要一个业务服务。大规模的实施其实会相当有限；而一个小的SOA试点项目，将很好的具备SOA资格。但如果这个成熟模型的最低水平未能符合（一）至（五）项所述，那将不承认在这一水平上的实施具备SOA资格。 

　　Zapthink的反应

　　我们为SOA制定的最低标准其实更注重该名单中缺少什么，而不是包含什么。举例来说，我们不包括下列各项：

　　是否有ESB，或其他应用于此的特别的基础设施或技术。

　　是否有XML在使用。如果你想使用FTP和CSV文件实施SOA，你可以这样做而且它仍然是SOA——或许不是很好的SOA，但仍然是SOA。

　　实施的服务是否支持组合。诚然，构建业务服务的首要目标之一是支持组合，而且我们要求的体系结构也要支持组合，但我们不想设置这一条款，因为它与我们定义的目标相去较远。但是如果你不将服务组合来支持业务流程，你仍然能出色的实施“好”的SOA。又或者，业务要求中可能根本就不包括组合，比如说，业务仅需要以数据为中心的服务。但如果该架构防止所有的未来服务组合，那么它就不是SOA。

　　任何有关设计或规划工作要与实施的服务分开的提法。法院会问咨询公司是否实施了SOA，并要求提供图纸。而不管图纸如何准确，都不符合任何实施过程的条件。这个缺失，正是符合文献管理工作软件中“敏捷”的原则。

　　任何有关整合的提法。如果你无须整合任何东西，就能构建一个业务服务的话，很好。如果你不是在解决整合的问题，也很好。在许多方面，整合和SOA密切相关，这可能是因为SOA的空间中其实有许多的供应商是整合供应商。显然，你可以不需SOA实现整合，而且，你可以不需整合构建SOA。

　　然而，最重要的是，如果你不打算在法庭上争论正在建立的架构是否是真正的SOA这件事，那么，它远不及建立的架构能否真正解决商业问题重要。但是，当公司认为他们正在构建SOA，而事实上他们并没有做任何这类事情时，讨论SOA的资格就是一个重要的问题。这种情况仍然相当普遍，而当这种实施失败时，他们就可以不公平的说SOA不好。