企业针对云计算的扩张计划，无论是公共云，还是私有云或者混合云，在云和soa的交汇处开始变得越来越有趣。为了让软件在云端起作用，soa（面向服务架构）和云需要能够兼容。尽管云被看做是soa的驱动者，随着业务数量不断增加，实际上，soa是支撑企业扩展云的使用的关键点。

soa有两个目标：组件化和暴露一致性。soa构建功能元素，通过应用程序接口（api）作为“服务”暴露出来。这些元素随后组成应用，这也是创建soa重用组件改善应用效率的双重好处。

为了创建一个应用，一套组件“串连”到工作流中，通常使用工作流“引擎”或者服务总线软件元素。这个工作流对于一个既定的应用能够通过一个目录功能直接抵达正确的组件，在大多数soa标准中，这个目录功能通常称之为统一描述、发现和集成（uddi）。应用组件安装好后，uddi进入允许应用工作流查找一个组件。这样就是云和soa的交汇处所在。

任何时间一个应用或者应用组件被指派为任何资源池的一种灵活的资源，包括云，它都要和一个地址相关联。而且这个地址必须对于其它组件已经发布，以便这个软件整合到公司整个的it流程中。因为soa提供了一种查找组件的方法，这种机制可用于记录什么时候一个应用运行在云端发生了什么。在大多数案例中，这种机制允许公司在云中部署应用，并注册其位置，让用户可以访问应用。解决其他地址问题，包括url也需要dns更新。

短期混合云和soa关注点

soa和混合云环境之间的关系有其好处，但是也有坏处。问题之一就是应用工作流在跨公共-私有云边界时潜在的性能问题。在运行在数据中心中的常规soa应用中，数据中心网络可以相当有效低维护跨组件边界的工作流。将这些工作流数据通过wan转移到云端，云引入了延迟、包丢失，在一些案例中，暴露了安全问题。

混合云中soa应用的组件注册流程也有利弊。有利的一方面是你可以使用公共云托管一个组件，不再因为一个系统失败需要在本地运行它。这为应用创造了一种故障恢复选择。如果应用和工作流或者系统总线流程支持多种组件实例的使用，你也可以通过soa注册库管理。

然而，在公共云上托管一个组件对于用户和it来说是透明的，除非uddi检查过，但是这样做如果这个组件湖综合应用在系统修复时不能回到本地，就会将终端用户暴露给公共云使用指令。对于混合云应用来说，任何soa管理的部分应该包含确保公共托管在必要时唯一使用。

此外，由于soa软件的“服务”属性，应用可以通过图形用户界面（gui）或api以及第三方gui工具进行访问。在云端使用soa的时候，重要的是 gui支持处理应用所使用的机制。在大多数案例中，可能是uddi、dns或者二者都是。确保相关的目录正确的升级是云用户的责任，这意味着这个目录必须能够为数据中心和公共云所访问。

长期目标：soa和云计算相匹配

高度组件化的应用元素自动更具负载注册，完美符合用户的弹性云资源池的愿景。他们也能促进负载均衡以及私有云元素之间或者私有云和标准数据中心之间的故障恢复。实际上，很多人认为为了实现云架构的所有好处，即插即用、完全的弹性、自服务、应用执行框架——你需要soa软件。

产业趋势倾向于复杂软件产品使用soa，未来应用可能成为更加的顺应soa。而且这也使得这些应用成为灵活弹性混合云的完美候选者。

服务提供商已经看到了云和soa链接的价值。一个重要的欧洲载体，提供的云服务将soa经验作为首席技术官的要求。企业赞同，随着他们开始拥抱私有云模型，更关注于创建灵活的框架，允许你混合私有it和托管的公共云服务。在其发布后的十年，soa可能注定会在云端成功。