【IT168 评论】Joe McKendrick已发布一篇题为“经验总结：SOA和云面临的挑战和机会”的会议纪要，参会人员由Phil Wainewright，David Bressler，Ed Horst和Joe McKendrick等人组成。
讨论从Phil Wainewright的问题开始：
你们每个人是如果定义云的，如果它和SOA存在区别的话，那么最关键的区别又是什么?
Joe McKendrick认为:
……过去的一年太令人惊叹了，这些概念一齐汇聚到大家面前，这里我只谈SOA和云。SOA在90年代初就已经来到人们周围了，而且很过公司正进行着SOA……现在，我们更多地看到人们在强调向云的转型……我认为这二者的主要区别是：SOA是一种架构，是底层架构，是人们创建、管理、编排服务的方式。而云是一种技术，从一方和另一方之间交付这些服务是通过它实现的。但是我认为，目前正处于这样一个阶段，你不能只有其中之一，而应该二者兼备。
Phil Wainewright继续问道：
可否这么简单地说：云就是SOA，只不是过它是一种以面向Web方式实现的SOA?……我这么说的意思是，因为它是一个开放的环境，而且你不知道你正在和谁进行交互，因此不得不要做所有的服务层的工作，如定义合约(服务的合约)……还有安全需求，你必须做所有的那些在受控的企业环境中不一定非要做的事情，因为在受控的环境里，你了解正在发生的事情……我认为我们在SOA和云之间已经建立了很多的共性。云正在做的很多事情是当初SOA建好后要做的事情，因此，也许我们可以继续做出这样的前提假设：云可以学习SOA的经验。那么，SOA教给我们什么 ?有哪些经验教训可以让我们在实施云的过程中不再犯相同的错误。
为了回答这个问题，Ed Horst提到了SOA的三个主要经验教训：
……(1)从一个具体的项目开始，这个项目要有合理的边界，并将在完成是能够对日常业务有所影响……你得需要能够经常使用的东西。(2)另一个是……避免煮沸整个大海的做法，比如在还没做任何云的工作之前，就要将所有的东西变成云……但这也不是说在做第一个项目的时候就完全不考虑最终的方向。因此，我所看到的一种更为成功的策略是混合的做法，在考虑整体架构走向的同时采取更广阔的举措，最后我们可能会花2年、3年、4年甚至5年的时间才能完成，但是在启动项目之后要开展一些实际可行的工作。(3)然后……管理系统，要尽早、尽可能经常地对系统进行监管。做得早的话你一般不会后悔，相反你可能经常会因为没有这么做而后悔。
Phil Wainewright的观点是，一个包罗万象的面向Web的架构可以让我们统一SOA和云计算。他继续说到：
……面向Web的架构的一个特征是REST接口，它更加简单，因为他不需要做SOA相关的其他事情。这个特征也是云计算的特征，一个必要的特征，云计算追求更加“lowest common denominator”的接口(译注：在数学中，Lowest common denominator被称为最小公分母;在计算机中，最初的意思是计算机平台的指令选择技术，当对一个程序进行编译生成可执行程序并使之可移植到其他平台上时，由于每个处理器都有自己的补充指令，所以只有使用不同处理器所共有的那些指令编译出来的可执行程序才具有最好的移植性。在这里，指得是接口定义要更通用，更简单)。
Ed Horst认为REST和SOAP都有特定的应用场合，这取决于不同的交互类型：
如果交互本身就更加事务性，更谨慎，更业务敏感的功能，那么通常使用SOAP接口来进行交互。但如果是一个类似于查询和更新这种轻量级的操作，而且对业务的影响也较小，那么用户一般使用REST接口……这也不是说REST就不能用于具有事务性的场合，但是当你为了实现事务、安全、良结构的消息或者其他类似的要求而向REST增加一些元素进去的话，这时的REST看起来就很像SOAP了。
在今天的IT界“云”是一个热词，而SOA似乎渐渐失宠，最少在分析家的眼里是这样的。相应地，当前还有一个非常流行的假设，无论SOA曾有多大的缺点和困难，云计算都将改进之并能够解决这些困难。事实上，如Joe所说的SOA关心的是合理的系统架构，而云关心的是基础设施。总所周知，再好的基础设施也不能挽救糟糕的架构。所以我们应该停止对灵丹妙药的祈祷，而着手去关心最基本的工作：合理的服务架构。
