云计算几乎代表了IT变革。其中一个被大家公认的云变革驱动因素是，当客户需要或者有机会的时候应用程序需要变得更加敏捷或者对环境变化要更加迅速地响应。考虑到应用程序中SOA占据了主要地位，将SOA实践作为云计算敏捷化目标是非常重要的抉择。对于云计算和应用程序架构师来说，这就意味着：

　　理解敏捷究竟是什么意思 深入研究SOA能做什么，以及应该做什么 应用SOA敏捷性来解除体系架构的限制。

　　对于许多SOA架构师来说，“SOA敏捷设计”这一步骤看起来是多余的。起初，SOA其中一个目标是要鼓励敏捷。SOA敏捷设计所面临的主要问题是要重新定义敏捷，使之能追踪到SOA的体系结构和工作流程。

　　敏捷开发非常受Web欢迎，这意味着，在团队交互和迭代进行中，通过一系列网络活动的广泛协作可以创建一些应用程序。基于各组件间的重用和松耦合原则，设立了SOA敏捷目标，因此激发新应用程序中组件重用功能。

　　结合SOA组件化原则，调整现代敏捷设计理念 应用程序结构也许会成为协调SOA组件化与敏捷理念同步的关键要素。应用程序架构的业务功能基本上是应用程序中程序语言的声明部分。良好的应用影响架构应该区分出应用程序的所有功能模块，从而，恰当地了解重用机会。当然，对于新项目来说，可以借助应用程序敏捷化的传统的现代理念来设计功能架构，并以此作为组件化的基础。

　　这里的问题是，几乎所有的敏捷开发都是针对于SOA组件化环节而不是制作环节。架构师们努力保留下来目前的组件架够来节省交易成本，这样只能使问题越来越糟糕。SOA组件化中存在的最大一个问题并不是组件化没有用，而是并没有应用组件化。每一个架构师都知道，重用是一个重要的目标，但是，许多架构师没有在设计阶段强制的将重用环节加入到组件化中。

　　解决这个问题的唯一方法是，当敏捷设计开发识别出重用机会时，也就是说现有组件不能很好的支持敏捷开发时，应该使用授权指令，此时，为了适应敏捷开发，就要对组件进行更改。大多数企业会发现，这种方法会使他们组件从逻辑组件化程序的失败阴影中走出来。

　　只有一开始就逐层向下的使用功能架构，才能确保真正的实现迭代和不同团队之间的协作。首先，定义组件的界面设置，然后，通过协作关系来填充业务逻辑。哪里有需要，这些高等级组件可以被分解为较低等级的架构。然而，最好是保持原始功能的组件模式，以确保团队之间的敏捷化协作不会因为架构的改变而终止。

　　应用BPEL查找问题

　　一种查找本应在云计算环境中成功运行的组件问题的方法是，查看现有应用程序的业务流程执行语言(BPEL)中的工作流程编排。例如，当两个不同的功能被同一个BPEL调用时，或者当BPEL出于不同的原因在不同的工作流程中执行相同的任务时，都要使用BPEL。任何一种情况都会发出非结构化组件调整信号。

　　尽管，通过组件重用，SOA组件化可以对敏捷开发起到支持的作用，但是同时也会产生严格的流程相互关系，这种关系会阻碍云计算中的敏捷开发项目。BPEL或者工作流程也同样会发出异常信号。如果BPEL的编排很稀缺，这也许说明，组件中包含了太多的业务逻辑。根据用户的反馈，这就是SOA组件化和重用技术“脱轨”的主要原因。

　　BPEL编程增加了应用程序中自动化应用编程和整合流程编程的潜在影响。云环境中经常会应用 DevOps工具来部署和集成应用程序。恰当地支持DevOps，同时也可以使开发任务识别组件化和敏捷妥协。

　　如果组件重用成功的话，那么，新应用程序的许多组件也可以被应用到其他方面。当证实该结论并非正确时，它就可能暗示，目前的组件太过于特殊化了而不能满足之前SOA组件化标准。

　　重新回顾“敏捷” DevOps、SOA重用和敏捷设计之间的矛盾使开发人员意识到，敏捷开发与敏捷运行编程并不是一回事。重新成像或者普通成像都可以应用组件重用技术，然而后者符合了现代化妈服务设计原则。即使最先进的云设计也没有对组件的服务化调度进行授权，但是事情确实以这种方式发展。

　　可以说，服务化组件设计会使云计算敏捷性不同于应用程序敏捷性或者设计敏捷性。当具备服务功能后，组件实现了多租户操作、根据运行的实例数水平扩展、以及弹性负载均衡和状态管理的功能。大多数SOA设计还未被授权。展望未来，当考虑到云计算的敏捷SOA时，这将会是服务化领域最后的要求。同时也为以后的开发省去许多麻烦。