了解云计算与SOA之间的差异,以及他们可能产生的问题是能否成功的关键。

在SOA和云计算环境中，我们假定应用程序组件化后都能达到最高工作效率，并且通过组件化处理，按照逻辑标准，SOA和云计算会变得非常协调。

为了避免出现问题，我们最好是充分了解云计算与SOA之间的差异。对工作流效率、安全性和应用程序生命周期管理（ALM）这三个方面要尤其的关注。当设计到应用程序时，要尽可能采用合理的步骤实现组件化目标。

SOA促使架构师和开发人员开始思考关于软件重用服务的设计，并且可以通过软件组件清单的形式展现出来。这些组件通过依据企业规则而安排工作任务的服务总线被融合到一款应用程序中，通常情况下是通过业务流程执行语言表达出来的。因此，有了旨在提高开发效率和软件敏捷性的组件后，应用程序就如同变成了工作流程运行的政策标准。

云计划的首要目标是降低资源成本，尤其是资金设备成本。应用程序组件化后很可能会改善资源配置，并且也可以通过提升或者降低组件的拷贝数量使应用程序的横向规模变得更具有弹性。

实践中，根据组件化设定的目标不同而建立了两种不同的应用程序整合及工作流模型。在SOA中，各组件之间相似度非常高，大多数托管在同一个数据中心或者是高度的关联设备中。在云应用程序中，Web前端组件通常会促使在应用程序中完成交易，而这些应用程序或许并非是本地前端，亦或许其本身也并非是高度组件化。

云计算和SOA组件化问题

用户反映，从SOA组件化过渡到云计算最大的问题就是由于大型工作流项目的延迟而导致反映时间过长的问题。用户对云计算中网络路径的进入或者流出性能并没有太多的控制权。结果，用户们所感受到的就是延迟时间更长了，他们也经常认为延迟时间的长短与云服务图像存储在哪个托管中心有关。

最大的问题似乎与是否存储在云环境中有关。将SOA应用程序完全托管在云服务或者数据中心中，并采用应用程序能够正常工作的方式来通过Web前端来引导项目工作，就可以缓解性能问题。

第二大问题危及到安全和管理。由于云服务经常会被用于扩大信息的访问，同时我们又期望SOA可以运行在一个高安全性的网络中，因此会引起第二个问题。通常情况下，仅仅在前端使用云服务以及将SOA组件托管于数据中心中就会解决这个问题，但是，云破裂以及云故障修复都需要将其转移到云环境中。即使是这样，如果在Web前端进行访问安全设置那么，只要加密工作流，维持现有阶段的应用程序和组件安全性还是有可能的。

也许是最棘手的最后一个问题与ALM有关。大多数将SOA应用程序转移到云环境中的用户都未对ALM进行较大的改动，他们认为测试和部署模型同样也会照常运转。结果他们发现，云计算和SOA组合必须经过严格的测试后才能成为ALM试点应用和认证流程的一部分。这是因为，在云服务和SOA组合中影响性能、安全或者管理的变量数量要与单独SOA环境中的数量更多。

尽管我们很想要马上就使用现有的ALM程序，并云化这些应用程序，但是用户体验建议我们最好是在满足云计算和SOA测试和管理需要的情况下开始开发ALM程序。

通过ALM来完成云计算和SOA组件化可以确定应用程序变化的位置以及辨别在哪处应该实施现代化处理才能转化组件模型。特别要说明的是，它还有助于定位哪些SOA组件未能详细描述云最优化利用情况，或者确定哪些流程对云工作流效率描述的过于详细。

从分辨重用组件和对应用程序生命周期的影响角度来重新审视ALM程序也许可以看出，有些组件并没有重新被使用，也就是说SOA组件并没有带来任何的效益。如果真是这样的话，那么分离出来的组件就会面临应用程序性能方面的威胁。此时，我们最好是能够将这些组件整合成一个单独的组件从而使工作流程实现本地化。仔细观察被重新利用的组件你会发现，这些组件几乎都是组合在一起使用的。

与新的应用程序一起使用

对于新的应用程序来说，组件化选择非常开放。最好的方式是首先根据云计算在故障转移和云爆发中的优势，然后确定优化组件模型。通过复审后，看看组件是否还可以进一步细分，从而能充分展现出真正的敏捷优势。

大多数架构师们都会意识到，当考虑SOA组件化处理时，团队成员更容易高估灵活性的优势，这样就容易造成过度组件化的现象。要记住，由于在云环境中，过度组件化会增加性能和安全风险，同样也会使ALM测试和认证变得更加困难。在接受组件模型之前，一定要有充足可靠的理由让人相信这么做是有盈利价值的，因为，他们要考虑成本问题。

利用敏捷性解决业务变化和机遇问题时，针对软件重用潜能以及资源最优化这两个问题要采用不同的解决方案。没有任何一种方法能解决所有问题，但是，至少智能模型可以明确知道哪处需要权衡利弊。