虽然围绕着SOA有数以千计的出版物、提供商和分析师的吹嘘，以及SOA曾被宣布死亡然后又在SOA宣言中重生的事实，但是该话题周围仍然存在许多疑团。McKendrick在他最新的一篇博文对此进行了讨论。
\u0026#xD;\nSOA与云计算之间的区别？David Linthicum就二者之间的关系做了很好的定义：
\u0026#xD;\nSOA关注的是定义IT解决方案和架构的过程，而云计算是另一架构选择。所以SOA可以被云计算替换。事实上，大多数云计算解决方案都是通过SOA定义的。它们不是互相排斥，而是互相补充。\u0026#xD;\n
McKendrick对此做了进一步补充：
\u0026#xD;\n一旦你有了彻底的了解，云计算其实是跨越企业防火墙获取或供应可重用的服务。类似地，Enterprise 2.0就是通过访问服务更好地协作，利用终端用户的信息进行混搭。它们是面向服务的架构，并且依赖SOA的原理工作。\u0026#xD;\n
在人们还没有真正完全地实施SOA之前何来SOA的失败？我们参照最简单的SOA定义：
\u0026#xD;\n……面向服务的架构（SOA）是一组用在系统开发和整合阶段的灵活的设计原则。\u0026#xD;\n
这意味着SOA是对系统进行架构的方法——即，它关心的是“怎么做”而非“是什么”。McKendrick认为：
\u0026#xD;\nSOA是一个演化的方法，而且还没有人真正完全地实施过SOA……大多数企业仍处在计划和考虑他们的第一个SOA项目的阶段。事实上，这段时间我不断听到的SOA的主要挑战是它过于成功，在开展SOA的企业中，不是新建了太多的服务，就是服务被无端（或者按需要）地开启了。\u0026#xD;\n
人们如何度量SOA项目的成功或失败？这里的问题是，对通用的企业架构，特别是SOA的成功与否的评判标准未被很好地被定义。Todd Biske认为：
\u0026#xD;\n……企业评判成功与失败之间的主要差异可归结为期望和目标。如果期望和目标是清晰的，那么对成功与失败的评判也是清晰的……这应是你的试金石。如果你采纳SOA，你能回答这个问题吗“如何判断是否成功呢？”如果你不能回答此问题，你猜会怎么着，你可能会臆测自己是失败了。\u0026#xD;\n
Ugo Corda对此做了补充:
\u0026#xD;\n……合理地检验SOA在其特定的优势领域里是否成功需要很长时间（譬如若干年），而且那些成功的故事应与成功的验证相隔很远。\u0026#xD;\n
McKendrick认为：
\u0026#xD;\n这对开始实施SOA提出了一个刻薄的挑战——成功是长期积累的，它表现在跨业务单元的服务被共享，使得服务开发时间明显缩减，或者，业务可以方便地进行服务的重配置从而让产品和服务更快地进入市场，这些都要归功于IT基础设施的灵活性……在市场上衡量长期成功的唯一正确的方法不是利润的增加就是股价的增长，而除SOA之外，还有许多其他因素作出了贡献。\u0026#xD;\n
有多少功能完备的，真正的SOA实现，确切的数字是多少？同样，问题是如何度量该数字？通过服务的数量和粒度？通过服务的消费者？借用 McKendrick的话：
\u0026#xD;\n一组Web服务在何时能转变成SOA呢？有没有这样的阈值，它定义了当Web服务得到更好的关注和维护、治理、注册、管理及其它好的事物时就更像是SOA了？\u0026#xD;\n
Herbjörn Wilhelmsen做了进一步解释并提出，功能完备的SOA需要：
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n
- 清晰的战略领导力\u0026#xD;\n
- 区分业务价值的优先顺序\u0026#xD;\n
- 企业文化\u0026#xD;\n
- 合理的动机\u0026#xD;\n
- 服务发现\u0026#xD;\n
- 互操作性\u0026#xD;\n
- 重用的机会\u0026#xD;\n
- 促进服务的发展\u0026#xD;\n
- 服务级别协议（SLA）\u0026#xD;\n
- 测试面向服务的架构\u0026#xD;\n
- 监控服务\u0026#xD;\n
如果SOA“与技术无关”，那为何我们这些技术人员要驱动它呢？McKendrick认为：
\u0026#xD;\n虽然在每次技术大会、每个分析师的标注中、每篇文章中，你都会不断听到该说法，但是，SOA并非绝对地、确定地、无疑地“与技术无关”。它由技术提供商推行，而且通常划归到IT部门的支持范围之内。\u0026#xD;\n
McKendrick指出，SOA是一个不断发展的架构方法，而且不管人们怎么说，许多关于它言论更多是出于情感，而非出于实际行动。
\u0026#xD;\n查看英文原文：Unsolved SOA Mysteries
)
