David Linthicum的一本新书，《在企业中融合云计算和SOA：循序渐进指南》， 描述了如何让企业通过面向服务为进军云计算做好准备，包括周密地按面向服务的方式来建模企业数据，信息服务和处理，以便更容易地向提供或消费云计算服务转型。
\本书是关于把企业服务和业务流程迁移到云的一个高层规范性指南。 David以“为什么”要迁移到云上开始了他的讨论，接着他定义了云计算以及各种组成云解决方案的组件，如存储即服务、数据库即服务、信息即服务、应用程序即服务等，并检验了把这些服务迁移到云的商业驱动力。
\在书中，David建议使用自底向上的方式，从数据建模开始，接着讲述了由这些信息完成商业活动的服务，最后是把这些活动串联在一起流程。他主张对这些服务和流程的治理进行建模，并计划在云中测试这些过程。
\Addison-Wesley / Prentice Hall 为InfoQ的读者提供了描述对云的数据和服务建模技术的书摘。本书摘包含书中以下章节的浓缩.
\- 第五章： 将数据移入云\
- 第六章： 将服务移入云\
为了解这本书写作动机并且学习作者把面向服务的企业应用移植到云上的经验，InfoQ 采访了David Linthicum 。
\InfoQ：一年前的这个时候，有一篇文章在SOA社区掀起涟漪；特别是它提出的问题 ——“SOA已死？”。这个话题引发了关于SOA应用的大量讨论，它诠释并强调了一个成功的SOA如何才能实现。你都看到了哪些变化，从这些讨论中你得到了哪些经验教训？
\DL：SOA是一个让很多企业组织者头疼而复杂的分布式架构，这就是导致Anne提出那个说法（SOA已死）的原因。请记住，那篇文章的题目是实际上是“SOA已死……但服务永存” ，其观点是SOA太复杂而且难以实施，但是服务的使用，不论是在本地还是在云平台中，都将继续成为焦点。
\SOA并没有死，实际上，在涌现出来的云计算领域中，SOA作为使用实施云计算的手段，比以前更加流行了，就像我在书里说的那样。我们得到的教训包括：不要一次性把整个企业搭进去；采用增量的方式实施SOA。此外，简单地将各种技术（如企业服务总线ESB、设计时治理以及其他只简单地提供零碎的解决方案的技术）扔进SOA项目的做法不是最佳实践，也不是解决方案本身。 最后，使用基于云计算的系统作为你的第一代SOA，做好它，然后把这些模式渗透到你的内部架构中。
\InfoQ：“SOA已死……但服务永存” 反映了人们在如何判定一个成功的SOA实施时缺乏共识，并且大家都认为工具提供商并没有真正把该讨论限制在工具无关范围内。这对企业采用SOA和接下来的云计算如果有影响的话，影响是什么呢？
\DL：如我前面所说的，SOA是一个架构模式。 因此如何实现这些模式是有各种不同的方式的。你的问题其实是，SOA周围的问题是对于“SOA是什么”缺乏共识。很多人让他们的系统支持服务，然后就称之为SOA，他们以JBOWS（仅仅一组服务）而告终。而且，SOA技术提供商把这个问题弄得更玄乎，承诺整个世界而只交付适度的结果。他们应该做适度得承诺，然后交付适度的结果。
\在我的书里，我把SOA看作架构的一个解决途径，一个利用云计算资源的更好的方式。主要概念是在架构上下文中考虑云计算。其他做法是将云计算作为一种战术或一次性的解决方案，现在大多数人就是这么干的。事实上，要想给企业带来真正的高效，你需要一个更宏大的规划，而使用云计算就是规划的一部分。
\InfoQ：云平台本能地支持Web，而且， 云计算领域内的大多数活动都是在使用了Web特性或属性的RESTful系统上进行。你如何看待诸如WOA等概念与SOA间的关系以及它们在云平台中扮演的角色？
\DL：WOA是一个把云计算作为架构来用而产生的一个概念，它通常来自SaaS以及其他交付自云的企业应用程序。实际上，这些模式大多在我的书中有所描述。 正如多数人理解的，SOA加上云计算就是WOA。
\InfoQ：你的书是关于两个概念的融合，SOA和云计算技术。SOA在企业中享有信誉并被广泛采用，一方面是因为多年来实践的发展和在治理、工具等方面的能力与成熟。另一方面，Web/云就是通过混搭和社交网络，API等方式进行即时的整合；该领域中的工具和平台的成熟度存在很大差异。您认为SOA如何衔接企业和云这两个概念呢？
\SOA从来就不只是一个企业范围的概念。随着AWS（提供了很多传统数据中心能找到的能力）等主要的云计算玩家的出现，云计算远远超出了混搭和社会化网络的范围。SOA和云计算利用资源的优势把架构扩展到防火墙之外。然而，Web不断创新的本质将给云计算带来令人兴奋的机会，如混合和匹配非结构化Web数据，社交网络API等，Web是个活跃的、生动的、快速革新的事物，新兴的云计算供应商将充分利用这些优势。
\InfoQ：所有的云供应商都提供一定程度的治理功能。 在书里，当你提到云计算需要治理解决方案时你的意思是什么？你是想说在广泛设计时/运行时治理的庇护之下，云解决方案还需要不同级别的治理吗？
\云计算包含一组服务，使用这些服务时的确需要一个深思熟虑的治理计划和技术，才能确保这些服务在某种集中控制的形势下使用或更改。所以我们需要服务的治理。
\需要那种治理技术取决于具体的问题领域，你需要的治理级别也各不相同。比如，大多数使用云服务（比如API）的系统都应该实现服务治理的计划，然后选择正确的服务治理技术，比如(最近被Oracle收购的)AmberPoint 和 Layer 7。这项技术使你能创建控制服务访问的策略。治理的计划和建模在书里都有所提及，如确定合适的治理技术的几个步骤。在云计算里，这通常意味着运行时治理很好地集成了安全性。
\InfoQ：你在书中提到的治理的指导原则是要定义、设计和实现各种策略。现在云计算厂商们已经提供了一些策略及它们增强版。你认为企业应该如何定义创建各种域策略的治理战略呢？现在是否已经有解决方案/产品可供选择，以解决领域策略的工作？
\DL：云供应商提供了一些治理，但通常只针对他们自己的服务。因此，你需要一组跨越云技术供应商和本地服务的技术。它们通常由运行时治理供应商提供，而且集中存在于某个位置，通常是预置的，它们为云交付的服务和本地服务执行策略。
\我的建议是：
\首先，创建治理模型，它定义了企业治理战略的。它需要对问题域中的所有服务进行编目，考虑如何使用这些服务，同时还需考虑安全。
\第二，选择一个适合你的问题域的合适的运行时治理技术，我举过一些例子。 还是那句话，这是创建和加强服务策略的方法。
\最后，你还需监控服务的治理，并在必要时作出调整。
\进一步，我猜测云中将出现越来越多的服务治理的服务，也许由只提供治理服务的云厂商提供，或者以治理即服务（governance-as-a-service）的形式提供。
\InfoQ：定义信息模型这一章谈得非常深入，它谈到了如何使用的数据优先的方式进行服务建模，从而得到信息模型。对于数据目录中的特定数据模型在不同系统中可能有多种表现形式，你如何处理这类问题呢？比如，CRM系统的客户可能与SCM系统的客户完全不一样，如何统一并展现不同的“试图”，请给读者一些建议？
\DL：很好的问题，这也是为什么在构建服务之前得到正确的数据模型如此重要，只有这样服务才能与各种服务表现很好地工作。而且，如果需要的话，我还推荐使用抽象数据服务层来重新映射数据模式，这样他们就能最好地展现出特定服务所需的数据视图。通过这些途径和技术，不论现在还是将来，你的数据模型将支持任意数量的服务。
\InfoQ：就云技术解决方案中的各种组件（信息模型，服务模型，流程模型）的版本控制，你有何建议?
\DL：信息、服务和流程都属于同一包含数据使用和服务治理技术在内的治理框架。作为治理模型和解决方案的一部分，将由版本追踪组件在特定的时间点保存跨实例的信息、服务和过程模型。通过需要深思熟虑的发布管理办法（它可与治理技术很好地整合），你就能跟踪架构发生的变化。
\InfoQ：在你的书里你简要地谈到了将风险从企业移转移到云。尤其是供应商，他们总面临着遭受经济或自然的灾难的可能性。企业如何能保护他们的投资和降低向云移植的风险？比如，供应商由于帐务争议或其他原因关闭了服务，如Google从最近中国市场上撤离。
\DL：在使用云计算资源时，我建议你总是考虑最坏的情况并且采取合理的措施保护企业。你需要考虑：
\可能的情况下，确保本地有最新的数据拷贝。当情况不对劲的时候，在找到另一云供应商或可用的解决方案之前，你至少可以得到业务正常运转所需的信息。
\你要了解与你同一条船上的伙伴。审查云计算供应商。确保他们没有中断访问和断电的历史，并且有强大的经济保障。
\决不使用由私有数据库和编程方法建设的云计算系统。如果它们倒闭的话，留给你的只是那些无处可用的代码和数据。
\提前为这些事项作好计划，我告诉我的客户要为断电，供应商问题以及自然灾害等做好应急预案。这时需要做什么？你的应急A，B，C计划都是什么？
\InfoQ：最后，是“云计算使用SOA”还是\"SOA使用云计算\"？为什么？
\DL：是SOA使用云计算，SOA是架构的指导原则。云计算只是一种架构选择，它主张利用位于防火墙之外的系统。 SOA关注的是如何在整体上最有效地使用IT资源，以及支持架构敏捷可变性。云计算只是使用这些资源的一种方式而已。
\ \感谢马国耀对本文的审校。
\给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。
扫一扫
349
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
