雲！ 超越基本SOA應用

十年前，面向服務架構突然出現在IT舞臺上，而且許多公司已經在SOA應用上進行了大量的投資。 很明顯，雲計算的成功取決於它能夠給現有的SOA實現增加價值的能力。 調查顯示，花在基於SOA原則的應用上的企業IT美元比花在「單片」應用上的要多。 不甚清楚的是SOA可能是雲的理想夥伴，使之大於它的所有部分的總和。

SOA系統中的應用程式不同于基於模組化和編排組合而成的應用;他們建立于模組化元素，這些元素是根據使用者，甚至是個別工人的特殊的工作流需求組合而成的。 這通常是通過「工作流引擎」，有時稱為消息或服務匯流排完成的。

SOA應用設計託管在多工的作業系統上，而且現在的大部分服務或消息匯流排技術都將會支援服務集群。 因此，在企業SOA資料中心中，「雲計算」已經生效這是一個事實，每一個SOA系統元件都是「即服務」的元素。 促使SOA應用真正與雲相容，尤其是與混合雲，關係到SOA能做什麼與雲需要什麼之間的平衡關係。

預防基於SOA雲的失敗

在雲中創建SOA的最大問題，是大多數公司希望在混合雲應用中的動態負載均衡，尤其是對於核心的，要徑任務的SOA應用。 有兩個元素促使負載均衡工作：當需要時創建額外的元件實例，並隨著負載的改變或發生失敗，在這些元件中平衡應用流量。

如果負載均衡在資料中心的使用中已經改變，在這些改變之後它有可能創建雲實例，使它們看起來像是資料中的擴展。 這允許你繼續使用現有的負載均衡策略。 儘管如此，如果資料中心的能力消失，那麼負載均衡的改變也會消失，雲中的容錯移轉也會失效。 如果負載均衡做為雲或網路服務實施，那麼它就可以支援混合雲SOA的實現——即使資料中失敗。

有時候，SOA服務匯流排或「工作流引擎」將會在多個主機上動態產生應用元件的額外實例，從而提升性能或對失敗做出回應。 這種情況下，要與雲服務供應商協商，確保服務匯流排界面與公有雲服務相容。 如果不能把服務匯流排應用實例流程直接連接到雲管理介面上，並啟動雲元件的話，你可能不得不使用開發腳本或DevOps工具，來加速必要的公有雲資源，然後讓服務匯流排使用他們。

當使用任何一種雲服務來創建彈性擴展的私有SOA資源池時，評估供應商延遲應用的影響很重要。 無論公有雲資源是直接通過工作流引擎啟動的，還是通過DevOps的，都有一個啟動的階段，這時資源將不可用，這將會影響生產率。 延遲對工作負載溢出應用的影響較小，因為你可以簡單的調整新資源要求的需求水準。 然而，這種調整可能會導致加速那些因需求減少而不需要的公有雲資源。 準備備用的服務或有現成的服務水準協定(SLA)來減少雲資源的供應時間可能是最佳解決方案。

選擇與SOA相容的公有雲廠商

根據本地用於運行您的SOA應用程式的作業系統和中介軟體的不同，對於公共雲託管元件你可以有多種選擇。 你惠普、IBM、微軟和甲骨文這樣的公司有平臺即服務(PaaS)的選擇，這與他們的伺服器和中介軟體工具相相容。 所以如果你使用來自這些廠商的SOA軟體，那麼第一件事是評估使用來自同一個公司的雲服務的利益和成本。

如果那不可能或你希望探索更廣的選擇，那麼基礎設備即服務(IaaS)可能會是一個不錯的方向。 記住，對IaaS公共雲處理你當前的SOA元件，IaaS設備像必須包括你使用的作業系統和中介軟體。 確保你的IaaS雲供應商能夠支援你的作業系統和中介軟體，並確保與公有雲使用的相容的許可。

大體上說，管理員需要認識到SOA和「RESTful」或「Web介面」是不同的東西。 大部分的SOA應用包含編排和工作流、及在基本Web服務中缺席的安全和合規元素。 現在大多數雲應用更多是基於RESTful介面，而不是SOA，因此給後者假定前者的經驗教訓是有風險的。 認真探索此問題，而且在做出生產承諾之前一定要徹底試運行測試。