云計算幾乎代表了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時，這將會是服務化領域最后的要求。同時也為以后的開發省去許多麻煩。

原文鏈接：http://cloud.chinabyte.com/134/13115634.shtml