Benoit Lheureux在其博文中写道，云计算不仅仅是

\u0026#xD;\n

……激增且混乱的云服务、创新、混搭和云资源的消费……

\u0026#xD;\n

在他看来：

\u0026#xD;\n

云服务消费对于业务来说仍然非常技术化，其中存在大量管理和合规问题。到最后，至少有一些公司需要帮助，来解决这些问题（想一想服务就知道了）。

\u0026#xD;\n

所以，

\u0026#xD;\n

治理、整合、安全。这些只是企业在消费云服务（这里的云服务不是那些相对容易的基于浏览器的服务，而是基于API的较为复杂的云服务）时必须解决的几个问题。

\u0026#xD;\n

Daryl C. Plummer认为，解决云服务整合的问题需要云服务的代理，这：

\u0026#xD;\n

……是云计算中最大的利润增长点，总市场价值约为1万亿。

\u0026#xD;\n

为更好地描述这些整合问题，Plummer引入了一个新词汇——Cloudstreams，它：

\u0026#xD;\n

……关注整合、治理和安全影响点……云服务产生了（云）服务间整合的需要……前所未有的需要。企业希望将本地应用与云服务连接起来，也希望实现云服务间的连接。并且，所有这些连接都应该安全地进行，其性能也应被管理起来。简言之，他们需要的是灵活的、良好定义的、API层的服务整合，使用策略对数据、消息以及服务调用进行编排。这就是Cloudstream。

\u0026#xD;\n

Plummer认为，SOA供应商：

\u0026#xD;\n

……为一些基本相同的事情建立了一套很绚的词汇。他们说SOA网关和XML设备提供SOA的安全与管理，现在其保护的对象则是云。这些产品通过本地设备、软件、甚至云服务的方式交付……这些不同的词汇之所以会出现，是因为这些公司服务的客户使用不同的方式谈论他们的问题，尽管这些问题几乎相同。客户需要内部系统与外部服务（SOA或云）之间的交互，他们需要管理、安全加固、整合、以及加强这些服务的访问。问题是，他们在描述需求时都站在纯技术层面；所以，供应商也随之带回了解决这些需求的相关技术语言……因此，除非具体到细节，不然就很难理解为什么选择这个供应商而非那个。

\u0026#xD;\n

Plummer认为，新名词使得我们站在一个较高的层次探讨云与SOA中服务整合问题。它不考虑具体的API/技术层面的事情，相反，它考虑的是云服务之间或云服务与企业之间的信息流（以及策略和关键指标）：

\u0026#xD;\n

这是使我们能一致地描述云服务间的整合的唯一途径。它描述的互操作性是面向所有人的，而非只是那些天才工程师们……将云间的整合（CI ）的打包成Cloudstreams的想法为（提供这类仲裁服务的）提供商们敞开了机会的大门。既然人们还记得，云（以及SOA）应该封装与服务交互的技术细节，让人们把这些交互作为业务的一部分来思考解决方案，Cloudstreams也应该有其相应的生存空间。让我们应关注解决方案中的其他整合需求，而非只是那些设备或具体技术。

\u0026#xD;\n

在对Plummer博文的回复中，K. Scott Morrison说：

\u0026#xD;\n

Daryl所描述的问题是太多公司……使用技术去解决根本的业务问题。技术是关于细节的游戏……但是，当面临几乎举不胜举的功能列表时，大多数客户很难在供应商之间做出选择。某供应商使用对应于WS-Security Kerberos Token Profile的Kerberos令牌，而另一供应商则使用另一套SSL加密套件。若单纯地比较产品的特性，会不自觉地迷失事实，也许业务要解决的问题是与Salesforce.com进行简单地整合。Daryl的目标是用Cloudstream归纳云服务整合有关的讨论，而不是以牺牲技术上最终需要的配置细节为代价。

\u0026#xD;\n

SOA之所以消失，原因之一是它试图通过（由供应商驱动的）技术解决业务问题。但愿一个围绕Cloudstream的更全面的方法能够避开这个陷阱。

\u0026#xD;\n

查看英文原文：Cloudstreams: The Next Cloud Integration Challenge