SOA与云计算

2011-11-30 09:39 无名365 阅读(434) 评论(0) 编辑收藏举报

From http://www.infoq.com/cn/articles/SOACloudPanel

在过去很长一段时间里，SOA受到了软件行业的广泛关注。接着它被宣布死亡，然后它又（在一定程度上）以云计算的形式重生了。当今的云计算就像几年前的SOA一样被疯狂地炒作着。它们有很多相似之处？二者之间有何关系？根据该行业的传统，答案取决于你问的是谁。VMWare的Rod Johnson说：

“我认为SOA时代的确已经过去。从架构层面上看，它的确是个好东西，但是从产品销售的角度看，它却是个市场中孕育出来虚构概念……但云计算却不同，它背后有更多实际的东西。但是，这些实际的东西已经模糊了，因为几乎任何事物都是云计算。”

另一方面，Oracle的Jürgen Kress则谈到了在企业层面上需要使用面向服务的架构（SOA）来支撑云计算。他在国际SOA与云计算会议上的演讲中说：“必须合理地构建架构”，即云计算需要SOA的支撑。

本次虚拟研讨会中，InfoQ与几位SOA和云计算专家探讨了SOA与云计算之间的关系，二者通用的原则，怎样的应用能够有机结合SOA和云计算的优势，决定云计算成败的最关键因素。

参会者：

Rob High——IBM Fellow及首席SOA架构师
Miko Matsumura——Products Kii副总裁，Sun公司前首席Java布道，SoftwareAG副总裁
William Vambenepe——Oracle架构师
David Linthicum——Blue Mountain Labs创始人兼CTO，《云计算与SOA》及另外12本书的作者。
JP Morgenthal——云计算、企业架构和SOA/BPM方面的风云博主、权威。

问题列表：

云计算的哪些方面可以看到SOA的广泛使用——将云计算资源定义成服务时？将应用移植到云平台时？或者二方面都有？
哪些SOA的原则/经验与云计算的关系最密切？云计算对SOA的影响有哪些？
哪些方面能够帮助云计算避免像SOA那样失去开发者和分析师的宠爱？
越来越多的云计算API正面临着Web Service几年前所面临和解决的相同需求/问题，如异步消息传输、元数据交换、事件等。是否仍然需要那些WS*标准回来才能解决这些问题呢？
怎样使SOA与云计算最好地结合起来？
列举云用户可改进现行工作的三件最重要的事情。

1.云计算的哪些方面能够看到SOA的广泛使用——将云技术资源定义成服务时？将应用移植到云平台时？或者是二方面都有？

Miko Matsumura：如果我们只是将现有应用当作服务，那我们得不到任何好处，因为粒度、语义和重用性都存在问题。另一问题是，有些服务运行在古老的DOS上，如果过度使用，它们很可能会当机。这意味着扩展性已经成为“逐底竞争”或“最弱环节”。幸亏云计算为我们提供了更加灵活的基础，使许多服务至少不至于在物理上奔溃。而现在，它们只是逻辑上失败，虽然同样很可怕，但是处理这样的问题却更加有趣。

William Vambenepe：大多是后者。当将业务应用转移到云环境中，不论从交互的角度（它们之间如何交互，这是SOA关注的内容）还是运维的角度（云计算为此带来了更多的规范化和自动化）你都需要能够将它们拆解成可管理的单元。如果你已经在SOA项目中完成了此项工作，那么你就是在感知SOA的基础设施上完成的，之后，运维层面上的拆解就能处于良好状态。

而相反，如果你不能有效地控制应用组件之间的交互与依赖关系，那么现在你就需要这么做了，不然向云的迁移只是向虚拟化的迁移。虽然能够得到一些实际的益处，但这不是真正的云计算环境。

David Linthicum：SOA和云计算的融合实际上表现在如何定义IT资产，包括应用、基础设施（比如存储）、平台等。一旦我们完成这一步，不论是重新移动现有服务还是创建新服务，其流程都会更简单、更有逻辑性。所以，我的回答是二方面都有。

事实上，我们可将云计算看作SOA延伸到基于云交付的资源，比如存储即服务、数据即服务、平台即服务，仅此而已。这里的技巧在于如何找出哪些服务、信息、和流程是转移到云平台的最佳候选，以及选择应该从已有或发展的SOA中抽象出哪些云服务。

此外，SOA对于云计算非常重要，重点体现在几个方面：

首先，它是一个很好的架构方法，通过一些机制建成企业内外的信息系统，使它们能更好地运行与协作。

其次，为了获得云计算的优势，你需要通过接口和架构延展出去并连接到云计算资源。虽然很多人认为他们可以在核心企业信息系统和云计算资源之间简单快速地建立一些脏链接（dirty link），但事实上，为了尽可能地享用云计算，企业内部却一定需要架构，譬如SOA。

最后，你还需要通过一定的架构方法论和指导原则来组织并记录架构。过去大多数人关注那些热点方面却忽略了这一方面。我们需要回到正确的道路上，重新寻找解决问题的最佳方法，而如果按照正确的步骤做，SOA就是一个好的方法。

JP Morgenthal：从业界对SOA的理解而言，SOA最广泛使用的地方是PaaS平台的中间件组件。然而，SOA的特性决定了它可用于任何云服务（包括基础设施服务和软件服务）的创建与交付中。

Rob High：总体而言，云计算与SOA的关系源于SOA的松耦合特征。从实践的角度，松耦合是SOA的重点，因为人们希望位于信息系统中的服务与其依赖的底层技术、拓扑和组织无关。这是过去30年里，IT行业中广大分布式计算项目的终极目标。XML、WSDL、IDL、CDR，各种分布式计算领域中出现的格式和协议，它们无一不是为封装技术差异、进一步通过支持组件间的差异性而解决计算问题的。

快速转换到云计算，在运维和采购角度之上，你也会看到相同的目标——为了创建并利用解决终端用户需求的能力，而无需关心其位置和实现技术。SOA是在云计算中实现这种透明性的自然之选。

再者，对于业务人员而言，从服务的角度思考他们为其用户和业务伙伴所提供的东西是很常见的，这里的服务不是指IT或SOA中的服务，而是指它们向市场提供的业务能力。同样，他们也愿意从服务的角度去思考他们从其伙伴处消费的能力。一个公司可能提供财务服务，另一个公司可能提供制造服务，而第三个公司则可能提供人力资源服务。在企业与终端消费者之间的全球价值链网络中，通过互联网和计算机获得并消费业务服务是自然并且显然的发展方向。

当把这些力量聚集一起时，云计算的一切就是服务——它是面向服务的。云基础设施本身就是一种服务，一些人希望将自己编写的软件程序运行在它上面，然后通过面向服务的API向其消费者供应该程序的功能。基础设施服务也可能被软件开发者暴露出来，用于提供自动化管理的能力——注册及部署新服务、设置QoS策略、获得运维感知等。而在云上运行的程序本身可能是使用SOA技术实现的；云中提供的服务也可能通过企业内的服务和公有云中的服务的组合从而形成SOA复合应用。

所以，我们已经看到SOA在云计算多个层面的广泛应用。

2.哪些SOA的原则/经验与云计算的关系最密切？云计算对SOA的影响有哪些？

Miko Matsumura：应用Provisioning就是推陈出新……过去，你往往只能说“不”，因为你还无法做到这一点。现在，你只需要问自己“这么做有商业价值吗？”

相比而言，更难的是业务价值判断的部分。财务人员可能会说，只要赚得比花的多，那就能做。不幸的是，你还得遵循平台的生态系统规律，你不得不考虑诸如此类的事情——“我们的销售会卖它吗?”，“它会不会导致我们的平台API频繁变更？”

这将产生一种新型的平台领导力，我们必须要能对平台用户说“不”，不是因为平台能力不够，也不是因为其业务价值不够，却要根据应用是否符合某个特定平台生态系统的“风格”。

William Vambenepe：IT服务管理和SOA治理，二者远远地注视对方（或有意地忽视对方）已经很久了。配置管理是困难的，云在云计算供应商与消费者之间划了一条线。你或者相信这条线有魔术般的隔离效果，或者想出某种办法来管理并组织（译注：应用或组件间的）依赖关系和变更策略，使之在保证消费者服务的同时，允许云供应商执行必要的维护。这里有更多有关云和SOA治理相关的思考。

David Linthicum：我想到两点：其一，通过良定义的服务和资源（应用及基础设施资源）交互。其二，提供和管理敏捷的能力。

服务的使用是相关的。因为，我们不再面对数百，甚至上千的不兼容的服务接口，而面向一组通用服务，它们提供应用行为、数据服务和工具服务。通过通用服务与那些资源和以及广泛而位置独立的服务打交道，将云计算用户与资源隔离开。

我们对这些服务进行编目，掌握它们的用途，我们还可以通过它们混搭成新的解决方案，甚至将他们与流程和复合应用绑定起来，而不需关心这些服务位于私有云还是公有云，甚至在现有传统系统中。

敏捷的概念来自于服务的使用以及SOA。你可通过混搭服务快速生成（再生成）解决方案。这使得IT人员可以快速调整并更改业务流程，比如，通过复合服务或改变业务流程来创建新应用，不论服务位于云中与否。

至于云计算对SOA的影响，SOA为云计算带来了一条非常逻辑的路线图，这些原因我在很早之前就提到过，因此可以这么说，因为云计算的原因，SOA获得了重生。这是我的书《云计算与SOA》中的内容。SOA一直是设计、架构和处理IT资产的有效方法。云计算影响已经为SOA带来了无限光明的前景。

正如我最近在InfoQ.com的一篇文章说过，SOA的治理和松耦合原则对于云计算极为重要。从治理的角度，为了跟踪资源的使用和了解（在云计算中创建的）虚拟世界中部署的东西，对服务编目的维护极为重要。松耦合为云计算带来的好处是，它是避免（由特定云服务供应商造成的）厂商锁定、新服务产生或变更时保持敏捷的最佳方法。

云计算为SOA带来的好处是能够更好的理解运维的职责。SOA主要专注于开发，它的重点是创造性解决问题的流程。云计算通过拥有强大运维流程的成熟的运维组织向终端用户交付服务，使之以一致的、可重复的方式进行。

回到先前我谈到的松耦合在异构的分布式计算系统中的角色，这些年来我们一直努力争取的是对底层技术的真正的封装与隔离。即便是现在，我们拥有强壮的诸如WSDL、XML、REST和JSON等技术，我们仍然能够看到底层实现技术在它不该出现的地方显露出来。这种现象常常出现，一方面，隐藏这些细节需要一定的工作，程序员的大多数时间不用于设计与实现优良的封装之上。这样的疏忽，注意到时已经为时已晚，因为任何项目的早期所面对的环境并不是那么异构，所以就不会经历完全异构的系统表现出来的差异性。另一方面，云计算无法容忍劣质的封装。如果对资源位置的是僵硬的，那么虚拟化和弹性就变得非常脆弱。具体技术的数据类型也会限制或完全破坏消费者。无法隔离线程执行可能会将一个用户的信息泄露给另一用户。云要求良好的封装，在缺乏封装的部署周期中问题会很早暴露出来。这些都是SOA的基本信条，却也是云计算的关键成功因素。

3.如何能让云计算不会像SOA那样失去开发者和分析师的宠爱？

Miko Matsumura：对于这个问题，只能说“骏马已出厩”（译注：这是一个谚语，指马已经出了马厩，此时再关门已经晚了）。云已经提供了极度简单的底层API并博得了开发者的喜爱，比如S3。谁不喜欢面前有个可直接扔东西的桶呢？它就像云中声明的核心设计模式一样，开发者已经将他们的应用与其交织在一起了。

云计算的落幕将与SOA一样。只要是机器接口就是漂亮的，看着也舒服，而企业集成则是地狱。沙特（Sartre）说得好，“他人即地狱”。当人们不得不与每个酷似来自于呆伯特卡通里的秃头老板交谈时，他们的生命能量条就开始消退（译注：这里通过呆伯特卡通里的秃头老板说明，当这些秃头老板执意云计算时，即表明它开始走向衰败）。

William Vambenepe：这是自然界的规律，过度喧嚣之后就是相对的沉静。SOA经历过，云计算也将经历。若无法阻止过度喧嚣（对于云计算已经太晚了），则无法阻止它走向沉静。这一点我不觉得有问题，因为我们已经得到了益处。这意味着我们在应用云计算时，应该关注业务收益最大化，而不是循序那些炒作的标准。这才是喧嚣过后留下的东西，这才是许多企业架构实施的SOA，我相信他们会同样地实施云计算。

David Linthicum：脑海中浮现的是成功。随着云计算能够证明其在企业里的价值，IT就会使用私有云、公有云和混合云。云计算变得更容易理解，而现在也已经走向主流。然而，我们的电视广告中说的是“迈向云计算！”而不是“迈向SOA！”

云计算和SOA非常不同。云计算是一种计算方法，它使我们可以使用到本地或远程的资产，而且它们可根据需要供应或回收。SOA是某种你要去做的事情，或某种复杂的架构模式，他使我们创建出来的架构便于改变。

许多SOA相关的PR问题都根源于这一事实，大多数IT人并不真正懂得SOA。我不认为云计算作为计算方法已经成熟，在迈向云计算的道路SOA将是最好的架构方法。

JP Morgenthal：非常有趣，我把SOA看作服务的设计和开发，而将云计算看作是服务的交付和运维，但是显然二者的定义是多种多样的，这也是SOA一直挣扎和云计算将面临挣扎的原因。明确云计算的定义有助于让企业更好地针对一组目标度量云计算的价值——比如，云计算是x，所以它将交付y——也使得开发者和分析师能够量化分析它的价值。

Rob High：纵观过去30年的行业发展，每一种技术创新都可归结为三类：1）具有明确的价值定位，技术本身有魅力，而且还为对它感兴趣并愿意买单的用户明确标识了它的真正价值。2）能够扫清技术采购和使用方面的障碍，也就是说，它们便于使用和消费，而且容易获得其承诺的价值。3）获得社区的青睐，从而可以形成一个生态系统。人们对SOA诋毁大多数并不是在否认它满足以上原则的能力，它的根本问题是，SOA实施者是能否在真正理解其价值定位之后才开始实施它。我们常常发现SOA实施者的视野很局限，他们认为SOA是能够理清信息系统的另一种技术——它是更漂亮的EAI，或更糟的说法，它只是基本的系统整合。他们从不知晓SOA有其主要的业务价值定位，即通过快速对应用（服务）组件的重新组装以满足市场去求，让业务更敏捷，获得更好的产出。而那些真正理解SoA的架构的人却实实在在地取得了SOA的巨大成功，因为对SOA的正确理解可以有助于他们合理安排投资优先级，选择正确的设计及管理方法。

云计算也一样。云的价值不仅仅在于如何降低IT运维的成本，而在于是业务人员更专注于业务创新。在投资决策中正确理解和应用云的价值能够确保云计算的成功。

**4. 越来越多的云计算API正面临着Web Service在几年前所面临和解决的相同需求/问题，如异步消息传输、元数据交换、事件等。是否仍然需要那些WS*标准回来才能解决这些问题呢？**

Miko Matsumura：Web Service里面装的都是垃圾。但是，请不要误读这句话，我不是说Web Service“是”垃圾，我说的是它里面“装”的是垃圾。实际上它本身是好东西。厕所里装着大便，但厕所本身却不是。

那么，如果你是一个iPhone开发者，你调用了一个Amazon S3服务。很好，你永远不需要了解什么是Web Service。你的生活会像麦片广告一样充满阳光，每天呼吸着新鲜空气醒来。但是，很多开发者面对的是企业级应用。

Web Service标准是人们在处理标准和策略标准化问题上唯一任何并可实施的方式。所以，如果你的网站中存在一些垃圾，那么你就必须把它们装起来。因此，在这些情况下考虑使用Web Service，否则，继续过你的阳光生活。

William Vambenepe：我曾就过去十年间应用WS-*标准解决IT自动化管理（“云”之前的叫法）问题写过一篇博客。这篇博客写于2年前，很明显，从协议的角度，WS-*技术现在已经不可能再用于云API了。这里不是讨论SOAP和REST孰优孰劣的地方，但是在IT管理上从一种技术转到另一种技术的过程中，人们吸取了一些教训（比如专注于API使用的简单性），同时有重新发明了一些特性（如，通知[notification]和部分资源操纵[partial resource manipulation]等）。为避免在同一段落中过于频繁地引用我的博客，这里有对使用REST实施云管理的实施方法分析。

David Linthicum：我希望如此。2000年到2009年间，我们在WS-*上花了太多精力。大多数标准都定义得很好，也为新兴的云计算世界带来了价值。当今的一些云计算标准组织似乎在重新制造轮子，他们应该思考过去创建的很多标准。人们似乎倾向于在新技术（如云计算）诞生时发明新标准。我总是在会议中提醒人们回过头考虑WS-*标准的那个人。

JP Morgenthal：许多云计算供应商好像都采用“REST”作为API的暴露方法。实际上这是一个不公正的界定，它混淆了基于HTTP的API实现的许多方面。从本质上说，他们选择的是使用HTTP的POST和GET动词，使用URL格式作为服务交互的方法，与此对应的是更为健壮的消息机制，它提供可靠信息传输的功能。我要声明的是，我非常赞同REST使用URL标识作为资操纵的方法。它意味相同的资源地址应该总能返回相同的资源。如果响应消息中基于URL的查询结果总在变化，那么它就应该是RPC机制，而不是REST。

Rob High：SOA绝不依赖于任何技术（包括WS-*）才能取得成功。然而，标准的存在的确能有助于社区的建立，采纳技术的目的是建立生态系统。WS-*技术的显著特征是，它们不仅仅是一个标准，促进了社区发展，而且还能更好地支持服务质量，并将其作为技术的天然属性。其他技术提供了非常基础的（通常是“够好的”）服务质量。但是，如果你要求更多，那么WS-*就非常有价值了。在此基础上，我一直提倡为不同的任务选择正确的标准。如果REST和JSON提供的基本QoS已经够用，那就用它们。如果你需要更多，则使用WS-*。我不相信哪一种技术标准能够应用于其本质特性之外的其他需求上。SOA之美在于，作为一种架构风格，它不关心装配复合应用时选择哪种具体的技术标准。

5. 怎样使SOA与云计算最好地结合起来？

Miko Matsumura：SOA和云看上去像巧克力和坚果奶油。当巧克力碰上坚果奶油时，他们都很恼火。但是，当二者意识到二者结合之后的味道是那么好时，它们就成了朋友。

我的回答看上去很傻吧？首先，我们将云的好处想象成巧克力，当你的应用有难以满足的特性，需要弹性扩展的能力时，云计算就找到了它的舞台，这是一类应用。现在我们来描述坚果奶油这一边——SOA，这里有一些难以解决的应用，需要通过整合将它们连接起来。

老实说，大多数仍有希望的企业应用都具备这两方面的特点。所以，我来考你一个问题，你能在企业内找到一个即不适合SOA又不适合云的应用吗？离开了企业应用，就不要再去打扰SOA了。

William Vambenepe：二者联姻的最佳应用是对各种应用服务选择最佳的部署方式，同时保持他们之间的整合关系，最重要的是，将它们当作一个服务去管理。例如，在一些业务应用中使用了某个第三方SaaS服务，该服务可能要与运行在某个PaaS环境中的某个定制应用进行协作（比如，作为客户化/扩展SaaS服务的方法，或者作为向外部客户交付服务的方式），同时保持某些核心的、独特的应用在企业本地运行。一方面，需要使用SOA设计这一整合的架构，另一方面，SOA和云计算的结合有助于执行有效的管理。上述场景所依赖的IT管理基础设既要以应用为中心，又要拥有云的能力。

David Linthicum：杀手级应用（Killer Application）应该具备使用复合应用或流程中的服务的能力，它们即便是通过开放互联网提供的，但是使用起来却像本地服务。Google API是一种，但是还有成千上万的别的API，它们提供各种服务，从地图服务到销售税计算服务。或者是基础设施API，比如公有云供应商（如AWS）提供的存储和计算服务。看看这类网站，想想如何将这些API用作你的SOA服务，它们非常强大。

JP Morgenthal：正如我上面所说的，它们协同工作以交付完整的服务生命周期。

Rob High：我不得不对这一问题再老生常谈一次。SOA是一种通过松耦合的系统组装复合应用的很好的架构方法。云计算带来服务弹性和透明交付。只要有通过云的密集、透明服务交互能够带来规模效益时，你就应该使用云计算——私有云、公有云和混合云。

6. 列举云用户可改进现行工作的三件最重要的事情

Miko Matsumura：我向大家推荐吃好、运动好、休息好（译注：作者诙谐地回避了正面回答此问题，转向回答另一问题）。当然这样的回答还是比较傻。我更愿意回答下面这个问题：你不愿看到却看到的云用户做的最傻的事情是什么？我的回答是他们忽视了依赖性。依靠别人是很糟糕的事情，这些开发者依赖于其他企业，比如Amazon EC2。一旦你依赖于其他企业，而这些企业可能倒闭，或者开始了恐怖的吸金过程。所以，要实施安全的云计算，并相应地去架构你的系统，这样你才能够在两个或以上的云供应商之间实现“负载均衡”。这是独立性的首要模式，也就是选择。这是我们要注意的地方。.

William Vambenepe：

从应用的视角进行管理。仅仅监控基础设施或基本的应用指标（如一些请求的响应时间）是不够的。你要非常细致地检测应用、跟踪请求、深入应用运行的各个层次。黑盒监控（局限于从应用外部能看到的视图）能够得到漂亮的仪表板，但不可能进行优化和检测。更通俗地说，就是要架构可支撑性（并使用技术设施提供商提供的这一能力）。云导致了职责领域的划分，这种划分一般而言是强大的、大规模的，但是一旦问题出现时，它就可能产生支撑上的障碍。许多角色都可能会牵扯进来，比如终端用户、终端用户所在组织的支持人员、应用程序管理员、基础设施管理员、云环境或应用运行时供应商等。确保应用基础设施能够产生全面的、可共享的时间报告，它们可能与基础设施管理工具相关。此外，在共享支持信息的同时，还需要确保尊重应用的私密性规则以及及其边界。
不仅仅要好的架构，还要满足业务用户的需求。确保你够生成资源消耗报表、管理各种指标、管理退款、提供报告、监控SLA、计划未来用量、在企业的子实体间分发配置。换言之，要能够管理应用部署的各个业务方面。
了解哪里需要标准（标准很重要），哪里不需要标准（标准不重要）。不要使那些专有需求和不标准的框架溜进你的业务应用。另一方面，在生命周期管理端（如云API）还需要一些粘合代码，对它们不要过于担心。这一端暂时尚无标准，所以无需担心。只要你使用了好的架构管理平台，运行管理就不至于失控。而应用的业务逻辑则是重点保护对象，它们应该使用标准来保护。

David Linthicum：首先，一定要有好的架构流程去定义、开发、测试和部署解决方案。许多IT组织似乎缺少这一过程，而只是没有计划地扎进云计算。要用SOA方法来进行这一过程，你可以从我和其他人写的书中学习如何正确使用SOA。

其次，解决方案中一定要考虑治理和安全。当管理数百个服务和新的安全隐患时，这些概念在你的云架构中应该全面。多数人都是事后做的。

最后，一定要考虑性能和稳定性。使用来自数百个位置的数百个服务，听起来是个好主意。但是，它很容易导致性能和稳定性方面的问题，除非你非常了解这个系统，并密接监控它的运行。你必须在解决方案中设计性能和稳定性，不论是云或非云。

JP Morgenthal：

建立强大的成功度量规则。
建立合适的治理框架。
考虑你的云服务供应商消失的情况、提供超越你预期客户数的扩展能力、不要预支明年的预算。本质上说就是计划不确定性。

Rob High：云用户包括云消费者和服务提供者。云消费者是指直接从服务本身获取使用价值，或将服务与其他事物结合起来产生更大价值的人；而服务提供者则是指那些寻找更好的进行规模运维和交付方法的人。不论是哪一方，它们都需要关注的是：

遵循松耦合原则，特别是封装和透明化。
意识到云交付形成了市场经济的基础；那么云服务的透明性就意味着消费者可以容易地从不同的服务供应商间选择服务——服务的质量和价值在服务实现中变得越来越重要。
云经济的一个重要驱动因素是运维成本的降低，它只能在服务的实现支持虚拟化、弹性和高稠度的基础上才能实现，这些都是云基础设施提供的。所以，在许多情况下，你将不得不明确地构建你的服务，以实现某种程度的细粒度、多租户和隔离。

总结

令人惊讶的是，虽然是从不同的角度看待问题，但是多数专家在以下几个方面的看法是一致的：

没有合适的架构，云实施不可能成功。这意味着两个方面都要运用SOA，应用——合适的分解；基础设施——基于服务的访问。
与云计算最相关的SOA原则是松耦合、治理和可管理性。
正如标准在SOA发展过程中所起到的辅助作用一样，它对于云计算的成熟一样重要。
从长期来看，过度炒作会损害云计算。云计算若要赢得持久的拥戴，就需要足够多的成功案例。

关于研讨会专家

David S. Linthicum是Blue Mountain Labs的创始人兼CTO，也是国际知名的行业专家和思想领袖，也是13本计算科学著作的作者或合著者，其中包括最畅销图书《企业应用集成》（Addison-Wesley出版社出版）。Dave在云计算、SOA、Web2.0和企业架构等方面的多场领先的技术大会上发表过专题演讲，还频频作为计算专家出现在电视与广播节目中。在其职业生涯中，Dave已经在分布式计算的诸多方面，如企业应用集成、B2B应用集成、和SOA，形成并加强了的许多理念，所有这些理念都至今都得到了广泛的应用。最近十年，Dave集中于云计算相关的技术与战略的研究以及如何使云计算为当今企业所用，此经历中包含了与好几个云计算新兴企业的合作。Dave的行业经历丰富，曾是多个成功的软件公司的CTO和CEO，也曾在财富100强企业中担任过高层管理职位。此外，他已有8年的计算机科学的副教授经历，并且继续在主要的技术学院和大学中做演讲，其中包括弗吉尼亚大学、亚利桑那州立大学、和威斯康辛大学。

Dave最近的著作是《云计算与SOA》,你也可以在Twitter上跟踪Dave。

JP Morgenthal是Smartronix的云计算布道师。他有20多年信息技术的多个技术及业务需求领域的经验，拥有丰富的完整系统设计、业务价值分析和风险/回报分析的能力。Morgenthal 先生能够与总裁级别的非技术人员和工程师级别的人有效地进行书面及口头形式的沟通，也是云计算、企业架构、SOA/BPM等领域备受尊敬的权威。他还编著了三本书。

Miko Matsumura目前是Servo Software和Synclore合并后的Kii公司的产品部副总裁。在此工作之前，他曾担任Software AG的副总裁及首席战略家，在Software AG收购webMethods之前，它在webMethods担任SOA产品市场部的副总裁，而在webMethods收购了Infravio之前，他是Infravio全球市场部的副总裁。在此之前，他是Sun公司的Java平台部的首席Java布道师。他在许多软件创业公司里工作过，为硅谷和海外的创业公司募资超过1200万美元。他也与投资银行、风头公司和创业者有紧密联系。Matsumura获得了San Francisco州立大学的MBA和耶鲁大学的神经科学系的硕士学位。

Matsumura在2009年云展会上被提名为全球前30位最有影响力的虚拟化博主。它也是《SOA Adoption for Dummies》一书的作者。

Rob High是SOA基础部的首席架构师、IBM董事、副总裁、IBM科学院成员。他负责确保使用SOA原则和业务流程优化（Business Process Optimization）实现业务和IT对齐的开放的行业架构定义，他还负责确保使用IBM软件和服务来支撑架构以产生有效的SOA解决方案。这一职责还延伸到其它IBM软件品牌，如使用WebSphere、Rational、Tivoli、Lotus和IM的相关产品实现SOA。