http://blog.csdn.net/WOOSHN/article/details/8036910
介紹：
???? IT體系結構已非常成熟，它是一種成功處理典型IT問題的方法。體系結構中一個受到很大重視且相對較新的分支是面向服務的體系結構(SOA)。SOA經常被吹捧為企業用于解決應用程序靈活性和高維護成本問題的萬能藥，常常被視為幫助企業提高其IT投資回報（Return On Investment，ROI）的方法。SOA是用于進行IT系統設計以確保業務目標與IT一致的主要體系結構樣式，允許構建具有彈性的IT系統來滿足新的和不斷變化的業務需求。
???? SOA是一個組件模型，它將應用程序的不同功能單元（稱為服務）通過這些服務之間定義良好的接口和契約聯系起來。接口是采用中立的方式進行定義的，它應該獨立于實現服務的硬件平臺、操作系統和編程語言。這使得構建在各種這樣的系統中的服務可以以一種統一和通用的方式進行交互。
???? 在企業傳統的系統開發中，企業往往在設計架構的時候都是采用了緊耦合形式，這是封閉的，自成一體的。這種架構下的的MRP、ERP、OA等產品很難適應或快速響應市場或客戶靈活多變的需求，以及后續的擴展。在這樣的市場、及客戶需求下，從而催生了軟件產品一種新的設計或架構的理念：面向服務架構。
???? SOA架構，是一種粗粒度、開放式、松耦合的服務結構，要求軟件產品在開發過程中，按照相關的標準或協議，進行分層開發。通過這種分層設計或架構體系可以使軟件產品變得更加彈性和靈活，且盡可能的與第三方軟件產品互補兼容，以達到快速擴展，滿足或響應市場或客戶需求的多樣化、多變性。
觀點：
????SOA架構帶來的主要觀點是業務驅動IT，即業務驅動和業務更加緊密地聯系在一起。以粗粒度的業務服務作為基礎來對公司業務進行建模，這樣就可以產生簡潔的業務和系統視圖;以業務服務為基礎來實現的IT系統更靈活、更易于重用、也更快地應對企業業務需求的變化;以業務服務為基礎，通過顯式地方式來定義、描述、實現和管理業務層次的粗粒度服務(包括業務流程)，提供了業務服務模型和相關IT業務之間提供了更好的"可追溯性"，縮小了它們之間的差距，使得業務服務的變化更容易傳遞到IT。另外，SOA的一條重要的基本原則是，它能跨各種異類功能和基礎設施環境提供服務互操作性。SOA 是基于業務需求定義的，他依賴于業務原則而不依賴于軟件設計，具有突出的互操作性和靈活的服務即插即用功能。
?
優點：
? 1、更易維護：業務服務提供者和業務服務使用者的松散耦合關系及對開放標準的采用確保了該特性的實現。建立在以 SOA基礎上的信息系統，當需求發生變化的時候，不需要修改提供業務服務的接口，只需要調整業務服務流程或者修改操作即可，整個應用系統也更容易被維護。
? 2、更高的可用性：該特點是在于服務提供者和服務使用者的松散耦合關系上得以發揮與體現。使用者無須了解提供者的具休實現細節。
3、更好的伸縮性：依靠業務服務設計、開發和部署等所采用的架構模型實現伸縮性。使得服務提供者可以互相彼此獨立地進行調整，以滿足新的服務需求。
?
缺點：
??? 1、安全問題：
??? （1）SOA做為一種基于服務的架構，其面向的是流程。這樣，當企業真正實施基于SOA的應用軟件以后，表面看來，企業的業務流程得到了梳理，內控的能力提高了，但SOA架構要求必須有一個類似于流程管理的程序，來統一管理這些流程。這就帶來一個問題，如果這個架構出現問題，那么將導致所有的業務癱瘓。而現在企業信息化的發展趨勢是IT和業務結合得越來越緊密，或者可以說業務對IT的依賴程度越來越高，相信如果SOA不能很好地解決安全問題，將會極大地限制其發展。
???? （2）SOA強調機器與機器的交互，而大多數IT安全性都是基于人與機器的交互：身份驗證和授權在這個環境中變得更加富于挑戰性。在未受保護的SOA中，想要阻止Web服務的未授權使用實際上是不可能的。未授權用戶可以非常輕松地訪問Web服務，而Web服務往往不具備跟蹤誰在使用它們或者誰被允許使用它們的固有功能。傳統的安全防御對象主要是針對人，而SOA更多地強調了機器與機器的交互，即所謂服務的互操作性，如何應對來自合作伙伴或第三方服務交互請求的威脅(大多數情況下，這些請求被人惡意利用和操縱)將是SOA安全防御的一項重要課題。
???? （3）XML通信協議消耗大量帶寬，引發安全問題：與傳統的二進制通信協議相比，XML最高可以消耗高達50倍的帶寬，這不僅會導致交互系統性能下降，而且會為分布式拒絕服務攻擊提供可趁之機。因此，未經優化的XML通信將導致嚴重的安全問題。由于SOA架構的開放性本質，您很難控制SOA中未知的第三方，比如您的合作伙伴，它們可以間接訪問未受保護的Web服務。因此，未受保護的Web服務很容易超負荷運轉，如果沒有訪問控制，未受保護的Web服務很容易被來自黑客的大量SOAP消息所“淹沒”，結果可能導致拒絕式攻擊從而損害系統的正常功能。（為了解決這類問題，市場上已出現了專門的XML加速器。利用基于64位平臺架構的語法分析器，該設備可以用來加速XML/SOAP的解析、XML模式的確認、XPath的處理以及 XSLT的功能轉換。據公開的產品測試報告稱，這種XML加速器能夠達到每秒處理1萬多條XML消息的能力。）
??? （4）基于XML的服務間通信易受到監聽和竊取：由于XML的純文本的本質，未經保護的XML在互聯網傳輸過程中很容易被監聽和竊取。為了保障基于XML的通信安全，我們需要從傳輸層和消息層兩個層面進行保護。通過傳輸安全，可以保證只允許授權用戶可以訪問基于XML的Web服務，目前可擴展訪問控制標記語言(Extensible Access Control Markup Language，XACML)和Web服務策略(WS-Policy)是專門用來解決這個問題的兩個標準;通過消息安全，可以保證Web服務環境中交換的XML消息的完整性和保密性，Web服務安全(Web Service Security，WSS)和安全聲明標記語言(Security Assertion Markup Language，SAML)則用來解決這方面的問題。
2、個性化問題。SOA通過所謂粗粒度服務接口和分級，確實提高了效率。實現流程化以后，也確實簡化了開發難度。如果這個流程不適合我這個企業的實際情況，我還是需要個性化開發。國內的中小企業占到了企業總量的70%，他們的需求很具個性化，而且比較在意價格的因素。實際上這和SOA高度集成的性質是不相符的。
?
使用： ??
?一些公司把SOA簡單地當作一種連接具體的應用程序和創建服務庫的技術，而不是使用SOA開發一個基于軟件的相關的業務能力組合。如果你把SOA本身當作一種具體的技術解決方案，而不是當作改善你的業務的一種方法，你就不會實現SOA的好處。
??? SOA的真正價值和實現是：流程。我們將那些隨著時間推移在不斷發生變化的業務放在BPM層中，使得核心業務流程的變更變得更加簡單。比如說，企業增加一條新產品線可能會導致公司定義銷售稅的改變，我們可以通過流程，將這樣的業務流程變更轉變為我們對流程的配置，這種架構能夠更好地支持業務變更，為IT帶來敏捷的價值。
??? 盡管大多數人認為SOA的賣點是重用，或在多個系統間重用服務的能力，但是隨著時間的推移我們會漸漸發現，SOA的真正價值是提供了無需一連串重新開發、測試和部署，就能改變核心業務流程的能力，我認為這一點才是最重要的，即SOA的價值定位應該是它促進架構敏捷的能力，或是支持架構變更的能力。
??? 敏捷的價值能夠帶來戰略上的優勢。SOA的最終價值來自于它在更大的前景目標中扮演的角色SOA 是從傳統的業務豎井向新的業務技術過渡的一個關鍵的部分。許多技術趨勢(從云計算和虛擬化到業務服務管理、商務智能和文件管理)都使用或者支持SOA，或者是與SOA的業務設計重點協調設計的。SOA應該是一個更大的前景目標的基礎，如Forrester公司的數字業務架構。這個數字業務架構包括你的所有的技術計劃，代表了你的業務能力并且指導你的架構和架構戰略的向前發展。
??? 另外， 在中間件領域，SOA架構日益成為中間件軟件供應商爭奪的新焦點。誰都希望自己能夠先于競爭對手提供最優的SOA技術實現平臺。從技術上來說，Web服務、組件技術的采用將有助于SOA的進一步普及，從業務上來說，企業用戶要求性價比更高的應用系統，SOA恰恰適應了這樣的趨勢。
?
誤區：
?? 1、忽略遺留系統的技術限制：
???? 大量?SOA?工作都非常依賴駐留在遺留系統內的現有數據和應用程序。遺留系統的某些功能通常并不能適應基于?SOA?的應用程序中的實時特性。這種問題的一個典型例子就是單線程遺留應用程序，在此類應用程序中，業務功能的實現僅允許進行單線程訪問。遺留系統限制的另一個例子是僅在固定時間運行的計劃批處理。
???? 決定將遺留應用程序或數據作為?SOA?系統的一部分時，務必理解這可能會給整個SOA帶來的限制。如剛剛提到的，遺留應用程序的單線程特性就是遺留系統技術限制的一個例子。現代企業的業務功能經常可保證提供遠遠超過現有系統的功能之外的基礎設施事務功能。在此類情況下，可以構建以現代基礎設施組合為基礎的基于?SOA?的解決方案來逐步淘汰遺留系統。為此，組織需要選擇對業務最重要的功能，并使用基于技術先進的基礎設施的解決方案來替換其現有遺留實現。完成此階段工作后，可以隨后對其他業務功能進行現代化。此方法提供了用于逐步淘汰遺留系統的可行選擇。
? 2、將SOA?與Web服務劃等號：
?? 將Web服務實現等同于SOA?是一個典型的SOA反模式，這種情況通常發生在企業希望快速實現SOA?但并未評估其IT系統（包括應用程序和基礎設施）的成熟度時。此類企業會將所有內容都作為Web服務實現。IDE的發展已確保進行Web服務創建的技術部分得到無縫支持，并不要求進行大量的學習，從而使得IT部門能非常方便地創Web服務，而不會過多考慮是否與企業的業務目標一致。Web?服務的大量增加帶來了管理困難，并為基礎設施操作帶來了不必要的成本。因此，如果企業的遠景僅是實現一組?Web?服務，然后嘗試獲得SOA所帶來的好處的話，最好后退一步，重新對此進行考慮。如果企業希望充分利用SOA，則需要徹底了解體系結構和實現之間的差異，并對這一事實加以尊重。Web?服務是用于實現?SOA?的最流行的實現，SOA?是一種體系結構樣式，允許?IT?服務與業務需求保持一致，從而確保IT的業務價值。為了獲得SOA的好處，企業IT團隊需要完全了解SOA和Web服務間的區別。即，IT團隊需要認識到，SOA是一個體系結構規程，而Web服務是目前最流行的SOA實現技術。
?? 建模和設計SOA時，強烈建議IT團隊采用標準方法。IBM?的面向服務的建模和體系結構（Service-Oriented?Modeling?and?Architecture，SOMA）提供了用于進行建模和設計的規定性詳細方法。從最高的抽象級別而言，SOMA?提供了包含三個步驟的流程，用于進行服務標識、規范制訂和實現，可幫助創建能用于?SOA?實現的輸出。另外，還建議在設計?SOA?前對各個領域（如業務角度、組織、應用程序、體系結構）的企業服務集成成熟度進行評估。通過評估這些領域的成熟度水平，可對企業的當前狀態進行評估；您可以隨后創建增量轉換路線圖，以達到更高的服務集成成熟度水平。為了幫助您完成此任務，IBM?提供了稱為服務集成成熟度模型（Service?Integration?Maturity?Model，SIMM）技術。
??3、細粒度服務：
? 甚至在開始?SOA?活動前，業務信息（數據）和應用程序功能也通常存在于當前的企業?IT?投資組合中。這些傳統的企業應用程序通常是基于API的。用于訪問客戶信息的典型API?的示例有getFirstName()、getLastName()?或?getCelPhone()。這些?API?本質上通常是非常細粒度的。???
??一個常見的?SOA?錯誤做法是，使用服務接口包裝這種細粒度API，并將其通過Web服務描述語言（Web?Services?Description?Language，WSDL）定義對外公開。這會導致錯誤地將服務概念看作不過是“使用昂貴的服務Facade包裝的漂亮API”。不僅得到的“服務”僅傳遞很少的業務數據，而且這種做法也會導致服務數量劇增。從而導致使用者要負責按照正確的順序聚合服務，以便實現任何高級業務功能。請記住，服務并不是免費的：對于調用每個服務，應用程序都將以損失一定性能為代價。剛剛提到的失誤將導致服務間頻繁通信，從而導致系統開銷增加，所帶來的性能損失將對SOA采用造成極大的阻礙。
?? 正如我們多次提到的，服務必須與業務保持一致，并能為企業提供真正的收益潛力（無論通過減少成本和節約，還是通過產生收入）。創建僅模擬API實現的細粒度服務將不能為SOA或企業提供任何幫助。?
?? 服務可以通過聚合多個低級細粒度?API?實現的功能來實現。不要將每個細粒度API都作為服務公開；應該從API抽象出粗粒度的、與業務一致的接口，然后將此接口作為服務公開。這不僅能減少網絡開銷和各個應用程序層次間的通信量，而且還向與業務保持一致的服務接口邁進了一大步。?
??? 4、點到點調用：
????? 服務提供者和服務使用者的概念對SOA非常重要。使用者對服務的使用可以通過多種方法實現。在此領域最常見的失誤是采用點到點調用。這種方法會導致公開SOA系統中服務使用者和提供者間的連接（糟糕的n*n）。或許您可以讓此類系統投入運行，但又如何長期對其進行維護，并同時跟蹤所有連接，而且在其中任意一個服務或應用程序被替換或重寫時進行必要的更改呢？?
???? 當企業在應用程序間采用復雜的緊密耦合時（特別在投資組合中存在大量應用程序時），需要配備恰當的服務調用體系結構。IT系統設計需要創建邏輯體系結構層，以封裝和執行（數據）轉換、（服務調用）路由和（可能的不同服務的異類實現間的）協議中介。通過這樣進行分解，可以在服務提供者和使用者間實現松散耦合。即，一個這樣的邏輯體系結構，其中的服務提供者和服務使用者通過邏輯總線進行通信。
???? 服務使用者通過中間層同服務提供者分離。使用者與邏輯總線進行通信，而后者跟蹤來自提供者的可用服務，并負責調用恰當的提供者。這就減少了具有大量服務的系統中的點到點通信導致的問題。在進行服務實現前，如果尚未定義，應該對服務總線的體系結構進行概念化。這個規則特別適用于包含大量需要面向服務和進行集成的應用程序和遺留系統的企業。?
?? 5、不遵循標準：
???? 采用SOA時，務必遵循開放標準，而不要嘗試忽略這些標準或自己創建替代解決方案。例如，最好創建企業基礎設施來使用統一描述、發現和集成（Universal?Description,?Discovery?and?Integration，UDDI）作為將來的聯合注冊中心生態系統，而不要使用服務發現標準或構建服務發現自定義解決方案（如使用服務名稱與URL數據庫）。?
??? 在?SOA?中的服務規范制訂期間，尤為重要的是，要遵循行業特定的標準XML規范。此類行業特定標準定義消息的格式和業務實體，必須將其作為定義構建服務時使用的消息格式和數據類型的基礎使用。?現在亟待針對整個行業提出XML規范來定義企業信息模型及用于與模型一起使用的一組標準服務操作。很多垂直行業正在朝著這個目標快速發展。例如，Agent-Company?Organization?for?Research?and?Development?(ACORD)?是針對保險行業的基XML的標準，Justice?XML?Data?Dictionary?(JXDD)?是針對美國國土安全部使用的事故管理規程的基XML的標準,Open?Network?Video?Interface?Forum(ONVIF)是視頻監控領域國際標準，而OpenTravel?Alliance?(OTA)?則是旅行和運輸行業的標準。這些標準均已作為穩定規范發布，越來越多的基于SOA的工作正在采用這些標準。?
??? 通過遵循公共消息格式詞匯進行消息交換來采用并遵循此類標準，可以使得SOA足夠靈活，能在生態系統中的合作伙伴之間進行共享。它還允許對符合并實現這些標準的供應商SOA產品進行即插即用。此靈活性是定義和結構設計良好的SOA的關鍵元素之一，可支持成功創建大型?SOA?生態系統。?
??? 在沒有此類意識且不進行專門的行業標準分析和采用工作的企業中，開發團隊需要考慮標準的重要性，并將其制度化。恰當的控制框架在向涉眾說明此消息時將非常有用，可幫助確保遵從性和成功采用。在對標準沒有足夠重視但仍然需要SOA的情況下，組織將不能得到SOA的很多主要好處。?
?????6、使用冗余數據存儲：
????? 在包含具有多年應用程序處理經驗的IT部門的典型大型企業中，經常會發現包含重復信息的多個數據存儲和數據庫系統。之所以這樣做的主要原因是采用了典型的豎井方法，在這種方法中，應用程序必須分離，各個應用程序的重點都是企業內的單個組織單位。?
???? 當企業開始向SOA過渡時，拋開所有現有系統并重新從頭構建所有內容的做法并不實際。不過，在此類環境中，針對不同數據源（即使這些數據源中包含完全相同的數據）構建IT服務的做法并不少見。?更為有效的方法是對數據進行整合，以便異類數據系統能形成單個數據視圖（例如，創建單個經過整合的數據庫來存儲客戶信息）。處理此問題的另一個方法是創建虛擬數據服務，以將數據冗余封裝在企業信息系統中，并通過高級服務或業務流程使用此數據服務。?為每個數據系統分別創建服務并不是使用SOA對企業信息系統的信息進行聚合的好方法，因此必須避免這樣做。?
?? 7、“大爆炸”式SOA：
?? SOA的定義并不完全相同，具體取決于您在組織中的角色。對于業務執行人員，SOA創建了企業希望向其客戶和合作伙伴或組織的其他部分公開的一組服務。對于架構師，SOA?是一種體系結構樣式，此樣式至少需要有服務提供者、請求者和服務描述。對于程序員，SOA?是一個由標準、工具和?Web?服務等技術加以補充的編程模型。要理解和認識SOA過渡是整個企業（涉及IT和業務部門一直到相關涉眾）的范式轉換并不難。此類范式轉換最好通過迭代模型實現，在此類模型中，將標識一組對業務非常關鍵且價值高的功能來進行服務支持工作。此模型可隨后供后續服務支持項目和活動使用。如果采用“大爆炸”方法，計劃一次性對整個企業投資組合全面啟用服務，將給整個組織帶來太多的業務風險。?
??SOA?與其他體系結構不同，因為它顯式地處理了企業很多的非技術約束。其中一個約束就是，大型組織往往采用增量方式逐步發展。組織的IT基礎設施應該支持類似的發展方式。這樣的迭代式發展路線可解決以下問題：?
? （1）故障風險：IT正逐漸被視為現代企業的心臟。任何大型的IT故障都可能給公司帶來嚴重的財務和操作后果。因此，開展和執行IT項目時必須非常小心。迭代式發展可通過允許組織逐步進行現代化工作，從而減少出現故障的風險。?
??（2）反對更改：任何組織接受和容納更改的能力都是有限的。更改將影響涉及手動和自動業務流程的企業日常操作。發展的方法可確保引入新的流程和系統帶來的更改非常適應企業的容量，且不會在其人員中引起大的混亂。?
??（3）可行性：?新功能的大小應該是影響其實現在整個企業內的可行性的一個因素。在?SOA?中，新功能并不一定總是僅受單個業務部門（Line?Of?Business，LOB）的約束，需要考慮很多跨組織的依賴關系。
?由于?SOA?具有兩個重要的特征，因此非常適合采用迭代方式逐步過渡到其最終狀態：?
?（1）.?SOA?允許將大型功能片段分解為更易于管理的、經過了大幅度分解的組件。在將SOA的原則應用到處理企業的特定功能領域的子項目時，可以很容易克服本身就有風險的“大爆炸”方法。這可確保平穩過渡到最終狀態，還能確保單個故障（如果出現了）并不會讓整個企業陷入崩潰狀態。?
?（2）.?SOA?在很大程度上與技術無關，因此可以將業務方面和技術方面分離，將其作為能夠以獨立方式進行修改的獨立實體。SOA能以靈活的方式將業務功能及需求與IT功能聯系起來，因此業務或為其提供支持的IT都不會受到另一方的影響。?
? 想進行“大爆炸”式過渡的企業可能并不適合使用SOA，更不用說實現?SOA?的真正好處了。
? 8、忽視服務所有關系：
?? 業務服務的需求在部門或組織級別標識，其中的每個業務部門都具有特定的業務功能需求。其中一些業務功能直接與企業的業務目標保持一致，而這意味著可能會將其作為通過外部化服務定義說明的服務接口公開。?沒有恰當地指明服務所有關系模型時，會出現一個問題。很多企業強調提供大量服務，將這些服務用于進行組合。而這些服務的所有關系需求通常卻被忽略了。?
?? 每個業務服務必須具有其所屬的、進行了恰當記錄并被一致認可的LOB。伴隨所有關系的是滿足服務的非功能要求（NonFunctional?Requirement，NFR）和負責處理不遵從情況的責任。孤立業務服務的一個典型結果是不遵從服務SLA，而這可能使得服務成為企業級服務組合中最弱的聯系。這個最弱的聯系甚至可能會破壞此孤立服務參與的業務流程的總體SLA?要求，從而造成企業級的負面影響。?
?? 雖然對給定服務的LOB所有者而言，此類要求可能很高，但LOB所有者可以提供服務來創建積極的影響。假定LOB所有者將向其他部門的服務使用者收取一小筆費用。反過來，她將嚴格遵循指定的服務水平?SLA和NFR。這可以幫助她所在的業務單位補償服務的開發成本。?
?? 業務域所有關系也同樣重要，因為企業服務投資組合不應該交給IT部門進行開發和維護工作。如果IT驅動企業的SOA開發，他們通常會首先以最方便開發服務為目標（這也是可以理解的），而不會太多注意服務的業務價值。這個方法將導致業務目標和所開發的服務間的不一致。在這種情況下，SOA?的好處就不能實現。?
??服務的業務單位所有關系對企業SOA活動的成功至關重要。當未實現業務所有關系模型時，SOA?可能成為企業SOA成功的拌腳石。?
??9、忽視SOA治理：
? 治理是一個決策權限和管理框架，可確保在正確時間由經過授權的正確人員進行正確處理。?
??企業進行SOA轉換時，由于服務所有關系通常分布在各個LOB中，因此需要認真對待治理問題。由于企業內外各個組織進行維護的移動部件正在快速地增加，這使得有必要進行相應的治理。當且僅當服務得到有效的治理，嚴格遵循SLA和NFR（如安全性、可靠性、性能等方面）時，業務服務的這種跨組織特性和潛在的跨組織邊界的服務組合才能正確而有效地發揮作用。?
?? 為了標識、指定、創建和部署企業服務，需要通過能夠監督企業的服務投資組合的整個服務生命周期的強大而有效的組織進行有效的面向服務的治理。為了保證策略規則和決策及其執行和組織良好的服務生命周期管理要求，需要將SOA治理的實現作為企業SOA轉換的策略和計劃階段的一部分，而不是一個事后再添加的東西。?
?? 在SOA的早期，治理僅是一個不錯的可選規程。但隨著在具有復雜、集成的價值鏈的實際企業中SOA實現的不斷成熟和復雜性的不斷提高，SOA治理如今在整個SOA過渡策略中扮演著不可或缺的角色。?
?? 未認識到有效治理結構的重要性的企業可能不會從SOA得到太多的好處。事實上，此類企業中的SOA實現會被證明實際上具有破壞性，而且缺乏正確的組織結構來有效地遵循恰當的SOA原則和獲得其好處。
?10、其他注意事項（轉SOA前三思）：
?? 企業應該避免為了創建軟件組件、基礎設施解決方案和服務來解決單個具體業務問題而購買中間件產品、數據庫系統和管理解決方案。此類具體的一對一的產品到解決方案映射可能會帶來冗余，或被證明成本太高，不適合SOA實現。相反，應該將重點放在確定問題間的共性，然后將這些共性反映到技術解決方案中。?
?? 不應強制要求在SOA開發的過程中進行問題域間的過度分離。細粒度問題空間之間的此類過度分離可能導致基于服務的總體解決方案過度零碎。這樣可能會導致解決方案非常低效，特別在延遲和性能非常關鍵的情況下更是如此。?
?? 如果沒有恰當的SOA遠景，SOA設計人員和實現人員將無法確定企業應該達到的最終狀態。服務必須能追溯到一個或多個業務目標，以證明其存在的必要性。如果無法根據某種業務度量標準測定?SOA?的好處，則SOA過渡的整個目的就值得商榷了。顯然，在沒有恰當標識、定義和記錄SOA遠景、業務目標和業務靈活性度量標準的情況下就著手進行SOA活動并不明智。?
?? 最后，企業需要了解自己對靈活性的需求。每個企業的業務靈活性需求并不相同。它們是由競爭和差異化策略、上市時間及各種其他因素驅動的。靈活性需要通過SOA實際實現；靈活性的總體工程工作可能會影響企業的IT系統性能。?
最后：
?? SOA無論如何都不是魔術，無法立即解決每個企業IT體系結構的問題。采用SOA時，企業應該充分了解各方面的信息，采取注重實效的方法，從而使得SOA的業務價值主張理論能與其實現的實際復雜性相符。不過，如果正確實現，且能避免此處討論的種種失誤，您將發現采用SOA的很多優勢。?
后記：跟web服務打交道也有一段時間了，一直沒有時間好好整理一下，故將之前的一些資料和自己的一些見解整合了一下，陸續更新中。。。
?
 動畫案例(二))
