深入理解SOA概念及其潛在優點

1：SOA并非純粹的技術性方法

如果得以成功執行，服務導向架構(SOA)并非只是一個技術性架構，理解這一點是非常重要。SOA范例旨在于對商業流程進行建模，這些商業流程并不能總是得到技術組件的直接支持。最終，服務可能由技術組件執行，但是商業流程本身要比支持它們的這些服務重要得多。

作為一種技術，SOA是一個工具，雖然這種技術本身沒有提供直接的價值，但是與EJB或者.NET組件相比，SOA是一種更為廉價的代碼行服務開發方式。另外，SOA應被當作是其它利益的實現者，比如改進更廣泛的再利用，提高對商業流程的響應性以及與使商業流程保持更好協調性。

2：SOA不一定意味著網絡服務

很多技術人員對SOA存在這樣一種誤解，認為SOA意味著必需使用網絡服務。雖然網絡服務可作為SOA策略的一部分，但它并不是必需的部分。服務的定義可以基于除HTTP以外的其它標準。和具體的實現技術相比，關注商業流程和服務的需求更為重要。通常，服務的環境將有助于決定其執行方式。

例如，對于包含了關鍵商業事務的服務而言，使用網絡服務是不利的，因為我們無法通過SOAP/HTTP協議來保證交易。而且，很多服務可能需要異步操作，在這種情況下，基于隊列和通道的消息系統可能是進行提供服務的最佳方式。當然，有效負載和界面依然可以使用XML來定義。

3：可以使用現有架構建立SOA

很多組織對于SOA可以使用現行架構來建立感到非常驚訝，例如，.NET和J2EE平臺都可為網絡服務開發、XML解析與生成，以及與MSMQ和JMS這類消息系統進行通信提供支持。

SOA堆棧常常缺乏流程管理層或自動化層面。不過，許多公司現在已經在企業應用集成 (EAI)工具上進行了投資，很多EAI工具能夠提供流程自動化和管理層功能，它們可以從現有的應用程序或在.NET和J2EE平臺上建立的應用程序中對服務進行訪問。

4：SOA是一種(從組件、對象等)進化而來的方法

服務導向架構并不是一種全新的解決方案；相反，SOA是技術與架構的自然進化。系統架構一直在不斷進步，與商業保持高度一致。系統設計師與商家很早就認識到將技術與商業流程相協調的重要性，包括充分應用并合理化技術資源，以及為商業提供更好的支持。

SOA也在一定程度上源于早已有之的企業架構理論。企業架構對技術進行評估，但是更重要的是，它關注整個企業和全部的商業流程并提供了做出技術決策的背景信息。SOA工具則融合了互聯網技術，如HTTP和XML，以及綜合技術，如消息總線、轉譯技術和連接技術。

5：流程自動化是SOA的關鍵優勢

許多組織和技術專家錯誤地關注服務架構內的服務實現與交付，不幸的是，他們沒有抓住重點，SOA的真正價值體現在它是一個商業自動化工具。最終，軟件和系統將會提高商業或組織的效率，這可以根據組織執行的活動或者流程來定義。因此SOA不應將焦點放在服務上，而應放在流程以及流程的改進上。

當然，我們也需要服務為流程提供支持。但是對于提高效率和改進流程的目標而言，它們是次要的，服務本身的價值有限。

6：SOA架構可能高度復雜

從某一角度看，SOA架構可以相當簡單。例如，開發一個商業流程并確定所需的服務，這種要求就合理而直接。但是，要在數據和服務之間進行平衡，并實現有意義的目標則要復雜得多。

例如，假設有這樣一種情況：用戶使用訂單服務在系統中下訂單。這是相當簡單的操作。但是如果您希望將訂單上的數據和來自其它服務的數據關聯起來呢？如果所有的服務共享同一個數據源，這時您可以跳過服務層，并生成報告。但是，如果一些數據屬于本地服務，一些數據屬于原有的主機系統，并且另外一些數據屬于商業應用程序(比如SAP)，將這些數據集成在一起將會特別復雜。

7：SOA需要深入了解商業數據

因為SOA關注于商業流程，因此理解這些與流程密切相關的數據至關重要。例如，一個訂單流程會包含很多重要的數據項，比如訂單、客戶、運輸信息、發票、付款和收據；更重要的是必須以一種標準的方式來記錄這些數據，從而使流程中的每項服務都能以同樣的方式理解這些數據。

對于現在擁有信息架構的組織而言，這并不是一個大問題。但如果大型組織沒有信息架構或者信息架構支持有限，這一問題會導致實施過程中的長時間中斷。因為大型企業通常擁有的數據多種多樣，所以一般建議他們采用進化的方式來定義信息架構，即與“大爆炸”方式相反的方法。這意味著不必花費四年的時間來定義數據模型，而只需要在開發服務過程中花費少量時間來定義與那些服務相關的數據。這樣，在執行每項服務或者流程時，就可以發展相關的信息架構來包含必需的數據項。

8：服務可簡單可復合

定義服務可能是一個艱巨的任務。在某些情況下，我們很清楚需要哪些服務；很多時候，服務相當簡單。例如一個查找客戶的服務，可能需要使用一些標準來查找用戶并為服務的使用者提供標準化的客戶記錄。

然而，服務也可以復合形式存在。這意味著“超級服務”可以提供一個標準的界面，就像我們剛才查找客戶的服務所提供的那樣。在前面的例子中，暗指所有的客戶信息都存儲在同一個資料庫中，所以很容易進行查找。但如果一些客戶資料存放在大型主機中，一部分存放在SAP中，一部分存放在其它應用程序中，而另外一部分存放在Oracle數據庫中呢？讓我們假定在每一種系統上已經建立了查找服務的界面。換句話說，我們擁有在大型主機、SAP、其他的應用程序和Oracle數據庫上查找客戶的服務。我們新的查找客戶的服務可以使用所有這些現有的服務來查找客戶?，F在，因為我們的服務要調用其它服務，它變成一個復合式的服務。當一個自動化流程模型自己成為一項服務時，也會建立復合式服務。

9：SOA的自動化可能有很多層面

自動化可以發生在不同的層面，這是服務架構經常被忽視的一個特點。很多SOA架構的錯誤在于只看到某一個層面的自動化，然而，在一個SOA解決方案中，自動化至少可以應用到兩個關鍵領域。

第一個也是最明顯領域的是商業流程層，在設計流程的時候，其中的步驟已經進行了連接并形成自動化。因為這些流程通常是基于日常商業活動，往往與人類的交互活動有關。在人類交互流程中實現自動化是一個重要的自動化層面。

另外一個重要的自動化層面是沒有人參與的系統交互層，過去幾年來，集成工具已經應用到這一領域。通過對系統間任務進行自動化，往往可以提高流程的總體效率。

在這些層面上使用不同的工具也是很重要，應該對人類交互、程序或系統間的交互區別考慮，從而采取不同的策略。

10：服務應當遵循相同的界面標準(包括協議和數據)

使用標準化的方法進行通訊對于服務而言非常重要。在SOA世界中，通訊由兩個組件構成。一個是服務進行通信的網絡協議，就好比是人們每天使用的通訊媒介一樣，例如，如果您想和老板通訊，最好搞清楚老板喜歡接電話還是電子郵件。

第二個組件是通訊的數據或者語言，一旦您同意將HTTP或者JMS作為通訊機制，就等于確定了您交流的語言，例如，您的老板說法語而您說英語，可能就會造成通訊困難。在服務領域，通常使用XML作為語言，但這并沒有提供足夠的信息。必需對服務需要的數據進行清晰定義并達成一致，這樣服務提供商與服務用戶就能進行有效的通訊。

11：可以將服務外包

服務的另外一個優點就是它們不必作為整體組件購買，不必在內部進行管理，也不必從頭進行開發。相反，可以將服務外包。這意味著在您需要一項服務向政府部門提交法規遵從文件時，您不必自己建立這項服務。各類公司為幾乎每個產業部門提供各種服務。利用服務外包，您可以將主要精力放在與最重要的SOA策略——流程——上面。

外包方式的一個不足之處在于，如果您的競爭對手使用了同樣的服務，您可能會喪失一些競爭優勢。

另外一個需要考慮的問題是性能，這依賴于很多因素，主要包括網絡連接性、可用性和反應時間。采用外部網絡的服務可能會使您商業流程的性能降級。

12 服務可以在現有的系統和軟件基礎上建立

許多組織誤認為SOA方式沒有考慮到原有系統，如大型主機應用程序。實際上，SOA的一個最強大的價值就在于它允許組織重新利用大型主機和其它原有資產，這一點尤其重要，因為核心商業邏輯和核心商業數據通常保存在私有的原有系統中。通過服務來訪問核心商業邏輯和數據，可以立即在自動化流程模型中重新利用這些資產。

當然，大型主機并不是唯一的原有數據源。微型計算機系統，如AS/400、VAX和HP3000等等，都可以以各種方式提供服務。很多工具都可以幫助與這些所有權系統進行通訊，并將它們的信息作為標準化的服務來傳遞。

13：性能是SOA系統的關鍵

盡管SOA為一個組織提供了很多利益，包括協調技術與商業，增強靈活性等；它與性能有著密切的關系。因為在典型的SOA環境中，應用程序往往被高度細分，而程序之間的數據關聯也很緩慢，在決策支持和報告系統中特別需要考慮這一點，以往這些系統只依賴少量數據源。

性能最大化的關鍵在于了解應用程序和系統性能在何處對于商業最重要。構建一個高性能的系統來支持一個并不需要它的商業流程是無益的。一旦確定關鍵流程，您只需要在有必要的地方改進并提升性能就行了。

14：SOA以四個組件為基礎

一個成功的SOA交付計劃有四個組件。第一個組件是定義商業流程，需要哪些服務來支持它們，以及哪些數據與它們相關。這是關于SOA的商業分析。

第二個組件是SOA的架構和模式，這是一組描述如何定義與實現服務的規則，指定通用的交付與使用模式，并制訂開發服務需要遵循的原則與標準。

第三個組件是SOA的基礎結構，這包括網絡、服務器、存儲設備、消息工具、整合工具以及流程自動化工具等等，它們支持服務與商業流程的開發與交付。

第四個組件是SOA的開發計劃。該計劃確定了服務開發與流程實現的先后次序，并且指導形成新服務與新流程項目。

15：建立SOA可能相當麻煩

盡管SOA是一個進化性技術，盡管在SOA領域已經具備相當豐富的知識儲備，但由于各種原因，建立SOA仍然相當麻煩。最主要的原因在于SOA和其它變革一樣：它需要大量的溝通與社會化，使組織為變革做好準備。

在克服了變革的困難之后，還可能有其它技術性問題。這些問題包括建立適當的服務交付和使用模式、培訓技術開發團隊、以及為支持SOA開發模式對組織進行的可能的結構變化。盡管SOA的技術組件可以在隔離的環境下進行測試和驗證，SOA依然是一個全企業參與的方法，因而需要付出更多的努力來規劃服務架構的控制與管理。

(責任編輯：銘銘 mingming_ky#126.com TEL：（010）－68476636)