對于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對分布式管理的要求。