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