對於SOA，尤其是像開發人員和CIO等仍有若干關鍵問題需要回答。
Web 服務以及越來越多的面向服務架構（Service Oriented Architecture，SOA）已經在市場上投放了大量廣告。兩者都可以給企業帶來廣泛的短期和長期利益。但對於SOA，尤其是像開發人員和CIO等仍有若干關鍵問題需要回答。
問：SOA的前提是能夠使應用程序像服務那樣工作。軟件如何像服務一樣工作呢？
答：沒有SOA，軟件包是被編寫爲獨立的（self-contained）軟件，即在一個完整的軟件包中將許多應用程序功能整合在一起。實現整合應用程序功能的代碼通常與功能本身的代碼混合在一起。我們將這種方式稱作軟件設計"單一應用程序"。與此密切相關的是，更改一部分代碼將對使用該代碼的代碼具有重大影響，這會造成系統的複雜性，並增加維護系統的成本。而且還使重新使用應用程序功能變得較困難，因爲這些功能不是爲了重新使用而打的包。
SOA旨在將單個應用程序功能彼此分開，以便這些功能可以單獨用作單個的應用程序功能或"組件"。這些組件可以用於在企業內部創建各種其他的應用程序，或者如有需要，對外向合作伙伴公開，以便用於合作伙伴的應用程序。
"服務"的概念是要使用與實施細節無關的標準化接口來構建這些"組件"。針對一套應用程序服務的Web服務描述語言文檔，描述需要作爲請求特殊服務（例如，"檢查庫存"功能可能需要零件數）輸入來傳輸的數據名稱和類型，並描述服務響應的細節（它可能返回表示庫存中零件數量的一個整數）。
這些詳細信息看上去好像與 Java、C++、COBOL 等中實施的功能相同，因此，服務的請求程序無需知道使用的何種語言，而且可以使用任何語言來編寫請求程序。這就使一個平臺上的服務可以和爲另一個平臺編寫的應用程序集成。互操作性的關鍵是請求和響應消息，例如，使用SOAP消息發送，其消息使用 XML 編寫代碼。
問：請舉例說明 SOA 如何使企業受益。
答：關鍵的優勢是互操作性，可以使用任何平臺之間的功能，而與編程的語言、操作系統和計算機類型等等無關。在上述示例中，"檢查庫存"功能可能已經編寫爲一個應用程序要求的服務，例如，監控庫存並在需要時自動重新定購的服務，但我們後來發現，同樣的服務無需修改即可用於支持由員工使用的基於 Web 的庫存監控工具。
就內部而言，應用程序的重複使用是一項關鍵優勢，因爲它可以降低開發成本。服務的重複使用，其長期作用在於減少企業中冗餘的功能，簡化基礎架構，從而降低維護代碼的成本。通過按服務的使用者來組織應用程序，與傳統的編程技術相比，我們獲得一個要靈活敏捷得多的集成模型，使我們可以迅速修改業務流程模型。
就外部而言，爲服務交互而詳細定義的"合同"使業務合作伙伴之間的交互"自由聯合"，提供集成所必需的穩定性，並提供更改基層軟件（underlying software）問題的一個解決方案。當保留了相同的消息格式時，支持該格式的軟件只要仍然支持消息合同，則可以按需進行更改。只要它支持相同的消息格式，甚至可以使用另一種編程語言的實施來完全替換系統，請求程序無需更改。當消息合同不斷髮展而必須更改時，與相當困難的任務，即支持多個版本的程序 API 和文件格式相比，它使用版本控制（versioning），更容易作爲過渡策略支持多個版本的應用程序。
這些是部分關鍵益處，還有許多其他益處。
問：SOA與Web服務以及SOA和網格計算之間是何關係。
答：SOA是一種面向業務應用程序系統的體系架構設計風格，但可以應用於其他系統，包括中間件技術，例如網格計算。
Web服務是可以用於創建SOA的一套標準。儘管沒有Web服務標準也可能創建SOA（例如，在SOAP之前，人們已經在HTTP或JMS上使用XML來實現相似的結果），但運用Web服務標準卻是我們目前針對與外部軟件交互的最佳方法。
網格計算是一種系統管理策略，其目標是最大限度地減少硬件資源的使用。例如，當突然的需求溢出指定的服務器時，它可能臨時將一些請求轉向相對沒那麼繁忙的服務器。網格計算設計爲一種面向服務架構（用於調整網格計算的服務叫做網格服務）。
隨着我們轉向SOA，我們將看到該方法用於支持各種其他新的系統功能。另外一個示例是自主計算夥子管理系統。事實上，SOA是Web服務高級功能的基礎，例如WS-Trust和聯合身份識別管理規範。
問：因爲還沒有通用互操作性標準，SOA最大的問題不仍然是供應商中心性（vendor-centricity）嗎？
答：有一些基本標準正好適用於Web服務，它們可以用於實施面向服務架構。XML和XML方案分別自1998年和2001年就已成爲標準。SOAP 1.2自2003年6月成爲標準。UDDI在2003年夏天標準化。WS-Security在2004年4月成爲標準。
除了著名標準機構（例如W3C和OASIS）支持的這些正式標準以外，許多"技術建議書規範"也被廣泛接受，並作爲事實標準得到充分支持。例如，直到 W3C完成WSDL 2.0爲止，要求在其產品中支持Web服務的大多數供應商都支持WSDL 1.1規範。
事實上，目前大部分軟件供應商對Web服務標準的支持，已導致使用Web服務來廣泛實施SOA。
問：SOA如何影響SLA？而您如何讓SLA適合您的SOA？
答：當前企業之間的SOA實施通常側重於改善合作伙伴之間現有業務的效率。同樣，性能保證的概念並不是像方便的互操作性和自由聯合集成那樣的問題，它們可以藉助Web服務標準來實現。
當服務成爲企業付費的產品時，對特定水平的性能或可用性的保證，以及其它服務質量注意事項具有更爲重要的作用。我們可以想象這在將來會成爲一個常見要求，正在進行這方面的工作以支持該模型。
問：我如何着手構建 SOA？
答：最佳的方法時開始構建較小的SOA，側重於提高當前缺乏效率的交互性。例如，假設使用一個系統上需要重新鍵入到另一個系統的打印報告，將兩個計算機系統緊密聯繫在一起，這會消耗時間、浪費成本，導致出錯，而且數據無法保持罪行。可以設計一個簡單的基於Web服務SOA項目，直接鏈接信息，將含更新的SOAP消息發送到合作伙伴系統，而不是打印報告。
開始簡單的SOA使企業可以在作出大投資之前先衡量ROI，並在出現大的問題之前獲得小改善的經驗。
CIO在購買軟件時應該詢問供應商關於對Web服務和SOA的支持，作爲一個重要的注意事項。應該檢查新應用程序的開發，以便考慮是否某些應用程序功能可能需要用於其他目的，以及可以嵌入對Web服務標準的支持以支持重複使用。
最終要完成大規模的企業轉型，可能需要通過建立企業服務總線（形成SOA的骨幹網或神經系統）來開始該工作。然後以企業合理的節奏，將服務提供商何服務請求程序逐漸添加到ESB。隨着IT的SOA的增長，ESB成爲在服務水平上連接應用程序，並調節消息流量以提高效率和可靠性的一種有力方式。
問：管理SOA需要哪些新的服務管理技能？
答：在運用Web服務之前，因缺乏標準和自由聯合的策略，合作伙伴整合受到嚴重限制。隨着我們開始使用Web服務和SOA來整合合作伙伴，我們可以發現，使用業務合作伙伴所提供的功能的IT系統已經開始依賴於這些功能的可用性。我們從內部管理我們自己服務的可用性轉向要求監視和管理（可能有許多）企業之間的可用性。這明顯大大增加了管理IT系統的複雜性，但它也帶來了巨大的價值，這就是爲什麼許多企業要轉到這個方向的原因。
Web應用程序系統正在不斷髮展以支持Web服務標準。"Web服務分佈式管理"或WSDM標準正在由OASIS開發，對Web服務管理提供標準化的支持，通過使用Web服務來實現對不同平臺的管理，滿足涉及獨立業務實體的大規模SOA對分佈式管理的要求。