将面向服务架构（SOA）应用迁移到包括云在内的虚拟资源池中是有一些棘手的。也许在SOA应用中处理弹性资源池最大的问题是，错误地认为SOA发布/登记流程完全掌握了资源的发放，但实际上这会在相当程度上把事情复杂化。

　　许多情况下，SOA应用针对虚拟资源进行优化所需的变化被局限在publication/syndication及编排流程，应用架构师很容易就能对其进行规划，并推动这些更好地为未来准备。在云爆发或组件变更会引发状态保持的特殊情况下，特定流程必须按照次序进行。这要由应用架构师来决定何时需要进行虚拟资源调节以及如何优化它们。

　　SOA应用在高层将应用用户/服务用户与服务及其组件通过登记流程进行绑定。其目标是让应用组件松耦合，甚至到允许应用利用web服务描述语言（WDSL）动态“购买”组件的地步。组件被托管时“发布”到注册流程—比方说，如果它是通过虚拟机器（VM）移动功能迁移的话。

　　随着资源分配变得越来越动态，注册功能的性能变得重要起来，其主要原因并非因为它有可能影响到应用性能，而是由于对行动缓慢的注册流程的快速变更会出现在重新注册期间要处理服务请求的风险。这会导致应用的一部分与工作流失联，造成应用的不稳定。重新注册的风险问题可通过确保注册流程迅速处理请求，以及在停掉（以及撤销注册）旧位置的组件之前，一旦组件出现在新的位置时就首先注册该组件来降低。　　

性能工作流以及动态资源

　　并非所有动态资源都是生而平等的；在VM移动应用中，通常是在数据中心之内对机器进行迁移，而在云端，组件可能被托管在千里之外。此类弹性问题在于其对应用工作流未来性能进行优化的影响。

　　在许多牵涉到服务总线协调和集成的应用中，如果应用组件托管在相互“网络距离”遥远的地方，消息流延迟的累积会影响到应用性能，这意味着由于地理距离及网络跳转很可能会经历显著的传输延迟。而WDSL几乎从来就没有考虑过这一点，因此订购组件的应用有可能选到了一个距离太遥远的组件来支撑体验质量目标。

　　解决方案之一是让WDSL适应至少包括地理“区域”参考在内的因素来进行托管，以便运行在特定地方的应用会选择复制于相同地理位置的组件。另一种办法则是适应订购方对注册流程的处理，返回匹配请求方地理位置的组件。

　　这些方法哪一个最好，将取决于应用架构师能够控制注册流程的程度；开源工具很容易修改，但是专利工具可能就不允许修改，只能尝试“给WDSL添加位置”的办法。如果所有其他办法都失效了，应用用户可以被定向到特定位置的注册点，确保不会选到地方太远的组件。当然，所有这一切，都依赖于至少对组件托管时的存放位置有一些了解。要看一下云供应商的管理能力，看看可以做哪些事情。　　

SOA协调及云爆发

　　在SOA/虚拟资源应用中，协调本身会是一个复杂的因素。因为消息流在服务总线上合并，如果中间件采用的是真正集中化的总线架构的话，协调点的位置会是性能的一个重要因素。允许直接将消息传递给后继组件的更为分布式的消息管理，对于许多SOA应用来说并不实际，因为它们通过业务流程执行语言（BPEL）或别的工作流语言强加一种消息操纵逻辑。对于这些情况，选择在哪里对应用进行协调对于让SOA与动态资源适配来说至关重要。

　　对于企业来说，云内的负载均衡或数据中心资源以及溢出云资源之间的云爆发正成为越来越有价值的应用，但是这往往意味着未来工作共享需要复制多个组件出来。在设计心得SOA组件时，考虑这一未来需要是明智的，因为许多组件会维持状态或在多步事务中维持工作的上下文，因此无法在事务中被替换，否则的话状态就会丢失。

　　Web或RESTful应用设计学校一直倡导有客户端来维持状态，但是在SOA中，甚至在某些中间件里，组件也会如此。当应用是通过BPEL在中间件/协调级创建时，中间件状态控制尤其常见，且尽管这种做法被SOA架构师诋毁，在云爆发或负载均衡应用中它有可能比由组件维持状态更加灵活。如果不能确定的话，客户端状态管理是最好的！

　　如果为了利用资源的动态性而加入容错设施，哪怕在云和虚拟应用没有负载均衡的情况下状态也会成为问题。许多架构师忘记了如果状态是由组件自身维护的话，它会在失败时丢失，从而令追求快速动态故障切换的目标无法实现。在致力于包含有动态故障切换的SOA应用之前，应该先检查看看状态是如何维持的，否则的话你有可能浪费宝贵的时间，为某事准备的ALM周期将无法正常工作。

　　注册的控制、协调以及状态是SOA动态资源优化的三大问题。开始考虑这三点的应用架构师可能很快就能找到所有重要的问题并正确处置。这是确保SOA应用响应云和虚拟化趋势以及在未来应用设计中正确地将其作为基石的最好方式。