SOA有兩個目標：組件化和暴露一致性。SOA構建功能元素，通過應用程序接口（API）作為“服務”暴露出來。這些元素隨后組成應用，這也是創建SOA重用組件改善應用效率的雙重好處。

　　為了創建一個應用，一套組件“串連”到工作流中，通常使用工作流“引擎”或者服務總線軟件元素。這個工作流對于一個既定的應用能夠通過一個目錄功能直接抵達正確的組件，在大多數SOA標準中，這個目錄功能通常稱之為統一描述、發現和集成（UDDI）。應用組件安裝好后，UDDI進入允許應用工作流查找一個組件。這樣就是云和SOA的交匯處所在。

　　任何時間一個應用或者應用組件被指派為任何資源池的一種靈活的資源，包括云，它都要和一個地址相關聯。而且這個地址必須對于其它組件已經發布，以便這個軟件整合到公司整個的IT流程中。因為SOA提供了一種查找組件的方法，這種機制可用于記錄什么時候一個應用運行在云端發生了什么。在大多數案例中，這種機制允許公司在云中部署應用，并注冊其位置，讓用戶可以訪問應用。解決其他地址問題，包括URL也需要DNS更新。
 

　　短期混合云和SOA關注點
 

　　SOA和混合云環境之間的關系有其好處，但是也有壞處。問題之一就是應用工作流在跨公共-私有云邊界時潛在的性能問題。在運行在數據中心中的常規SOA應用中，數據中心網絡可以相當有效低維護跨組件邊界的工作流。將這些工作流數據通過WAN轉移到云端，云引入了延遲、包丟失，在一些案例中，暴露了安全問題。

　　混合云中SOA應用的組件注冊流程也有利弊。有利的一方面是你可以使用公共云托管一個組件，不再因為一個系統失敗需要在本地運行它。這為應用創造了一種故障恢復選擇。如果應用和工作流或者系統總線流程支持多種組件實例的使用，你也可以通過SOA注冊庫管理。

　　然而，在公共云上托管一個組件對于用戶和IT來說是透明的，除非UDDI檢查過，但是這樣做如果這個組件湖綜合應用在系統修復時不能回到本地，就會將終端用戶暴露給公共云使用指令。對于混合云應用來說，任何SOA管理的部分應該包含確保公共托管在必要時唯一使用。

　　此外，由于SOA軟件的“服務”屬性，應用可以通過圖形用戶界面（GUI）或API以及第三方GUI工具進行訪問。在云端使用SOA的時候，重要的是 GUI支持處理應用所使用的機制。在大多數案例中，可能是UDDI、DNS或者二者都是。確保相關的目錄正確的升級是云用戶的責任，這意味著這個目錄必須能夠為數據中心和公共云所訪問。
 

　　長期目標：SOA和云計算相匹配
 

　　高度組件化的應用元素自動更具負載注冊，完美符合用戶的彈性云資源池的愿景。他們也能促進負載均衡以及私有云元素之間或者私有云和標準數據中心之間的故障恢復。實際上，很多人認為為了實現云架構的所有好處，即插即用、完全的彈性、自服務、應用執行框架——你需要SOA軟件。

　　產業趨勢傾向于復雜軟件產品使用SOA，未來應用可能成為更加的順應SOA。而且這也使得這些應用成為靈活彈性混合云的完美候選者。

　　服務提供商已經看到了云和SOA鏈接的價值。一個重要的歐洲載體，提供的云服務將SOA經驗作為首席技術官的要求。企業贊同，隨著他們開始擁抱私有云模型，更關注于創建靈活的框架，允許你混合私有IT和托管的公共云服務。在其發布后的十年，SOA可能注定會在云端成功。