圍繞著SOA（Service-OrIEnted Architecture，面向服務架構）有很多的誤解。本文揭開了SOA的各種謎團，並介紹了執行這個服務架構會對你的工作有哪些幫助。
1：SOA不僅僅是一種技術方法
成功實施的SOA不僅僅是一種技術架構，理解這一點非常重要。事實上，SOA是關於業務流程建模的，而且並不總是由技術組件直接支持的。從根本上來說，服務可以由技術組件提供，但是業務流程本身比支持它的服務更為重要。
SOA作為一項技術僅僅扮演推動者的角色，然而技術並不能直接提供價值。服務並不需要象EJB或.Net組件那樣從編寫代碼開始。SOA技術應當是其他效果的推動者，例如改進和擴大重復使用，對於業務流程變化的更好響應和業務流程的更好結合等等。
2：SOA並不意味著網絡服務
很多技術人員都不理解為什麼SOA並不一定意味著網絡服務。網絡服務可能是SOA策略中的一部分，但並不是必要條件。包含HTTP在內的其他標准協議都可以定義服務。更重要的是，應該把重點放在業務過程的需求及其服務上，而不是易於實施的技術上。通常情況下，服務的前後件關系能夠決定其執行條件。
例如，對於那些與核心業務處理相關的服務來說，采用網絡服務的方式可能是有害的，因為在SOAP/HTTP協議上確保業務處理安全非常困難。而且，很多服務可能會需要異步操作。在這種情況下，基於隊列和頻道的消息系統可能更適用於服務傳送的實施。當然，有效載荷和界面仍然可以使用XML。
3：利用現有架構實現SOA
很多企業都發現他們可以利用現有基礎架構實現SOA，這令他們非常吃驚。例如，.Net和J2EE平台都支持開發網絡服務，支持解析和生成XML以及包括MSMQ或JMS在內的消息系統通信。
關於SOA經常出現的一些誤解主要集中在流程管理和自動化層面。但是，很多公司都已經投資了企業應用集成（Enterprise Application Integration，EAI）技術。很多EAI工具都能夠在流程自動化和管理層上運行，他們可以從現有的或者建立在.Net/J2EE平台上的應用軟件訪問服務。
4：SOA是一種進化方法
SOA不是一種剛剛出現的、全新的解決方案。實際上，SOA是一種結構和技術上的自然進化過程。系統結構處於持續不斷的調整發展之中，以便能更好地和業務相適應。設計人員和企業很早就意識到將技術和業務流程相結合的價值，這樣做能夠充分利用技術資源，更好地支持業務。
SOA技術的一部分是由企業結構理論發展而來的，這個理論已經出現了很長時間了。企業結構可以衡量技術，而且更重要的是，它能夠透視整個企業中的業務和流程，分析其中的關系，為技術決策提供依據。SOA工具的進化來源多種多樣，包括互聯網技術（如HTTP和XML），集成技術（如Mbus、Translation TechnologIEs和Connectivity等）。
5：流程自動化是SOA的主要優勢
許多企業和技術人員都錯誤地將注意力集中在服務授權和服務提供方面。不幸的是，這並不是問題的重點。SOA真正的價值是作為一種業務自動化工具。最終，軟件和系統是用於提高業務和企業效率的，因此可以根據企業的業務和活動來定義。對SOA來說，我們的注意力不應當集中在服務上，而是應該更關注流程，以及如何改進流程。
當然，服務是支持流程所必須的。但是與提高工作效率、改進工作目標相比，服務是第二位的。為了服務而服務的想法是沒有價值的。
6：SOA架構非常復雜
從某種角度看，SOA架構可以非常簡單。例如，開發一個業務流程或者定義服務都是非常富有邏輯性的工作，而且比較簡單。然而，如果想更好地利用數據和服務，SOA就可能復雜得多。
例如，一個訂單服務，要求是用戶可以通過它在系統裡創建訂單，這非常簡單。但是如果你希望把訂單數據和其他服務的數據關聯起來，情況又會如何？如果所有的服務共享同一個數據源，也許你可以繞過服務層，生成報告。但是，如果一些數據在自用的服務中，另一些數據在以前遺留下來主機系統中，其他一些數據在商業應用（例如SAP）中，把這些數據關聯起來就會變成一項非常復雜的工作。
7：SOA需要對業務數據的深入理解
因為SOA專注於業務流程，所以理解與業務流程相關的數據就變得非常重要。例如，訂單流程就有一些關鍵性數據：訂單、客戶、運輸、FP、付款和收據等信息。其關鍵環節是用一種標准的方法來描述這些信息，讓每一個參與到這個流程裡的人都能夠理解數據所包含的信息內容。
對於已經有了信息結構的企業來說，這也許並不是大問題。但是對於目前還沒有信息結構或者信息結構有限的大型企業來說，這個問題就可能會是實施SOA的障礙。因為大型企業有大量的數據，所以通常建議采用漸進式的方法來定義這些信息結構，而不提倡一步到位。這就意味著你不需要花四年的時間來定義完整的數據模型，你只需要在服務開發過程中，花少量的時間定義相關的數據就可以了。隨著各項服務的實施，相關的信息結構就會被逐步完善起來。
