了解云計算與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測試和認證變得更加困難。在接受組件模型之前，一定要有充足可靠的理由讓人相信這么做是有盈利價值的，因為，他們要考慮成本問題。
利用敏捷性解決業務變化和機遇問題時，針對軟件重用潛能以及資源***化這兩個問題要采用不同的解決方案。沒有任何一種方法能解決所有問題，但是，至少智能模型可以明確知道哪處需要權衡利弊。
