淺析SOA面向服務架構

首先來看看什麼是服務？咱們常談到的業務組件，業務方法或操做是否都是服務？而真正的服務必須知足兩個條件，一個服務自己是能力供給，必須有外界的需求；一個是服務自己是可複用或重用。因此簡單的講服務應該是可重用的任務。這種任務能夠是業務方面的操做組合，也能夠是一種技術能力。

面向服務則重點就是一切以服務爲中心，從服務識別，服務分析，服務設計，服務開發和服務上線使用一切都是以服務爲中心。可是要注意到面向服務自己不是在傳統面向結構或面向對象基礎上的一個新方法，而是對傳統面向對象和組件化思想的提高。

面向服務架構很容易將SOA理解爲一種技術架構，而SOA自己更多的是一種架構風格，這種架構風格和傳統軟件開發最大的不一樣則是更加體現了業務和流程驅動IT的思想，體現了IT系統組件化和服務化構建思想，體現了因爲服務自己能夠重用，能夠經過服務的組合和編排來知足業務的實現。SOA做爲一種架構風格，使需求方和供給方有了共同的語言和價值約定；SOA做爲一種架構風格，使服務不在單純的是一種技術能力，而更多的是一種業務能力和IT資產。



再來看SOA的完整定義，通常說SOA是一種架構方法，將傳統的單片式應用打破，分解爲離散的、自治的業務服務，利用標準提高他們的互操做性，從而能夠更好地共享、重用和組裝，快速構建複合的應用從而知足業務需求的變化。在這裏面能夠看到兩個重點，一個是要找到可重用的服務，同時這些服務知足離散，自治和無狀態等基本條件；其次是服務自己能夠組合和編排，以知足流程整合的須要。

第一步找服務的過程，是系統分析和建模從頂向下得過程，要充分體現流程驅動IT的實現，經過流程的分解，業務建模和數據建模，識別業務組件和業務能力，經過跨系統或組件的流程交互識別可重用的服務。最終造成可重用的服務資產庫。第二步服務的組裝和編排則更可能是從底向下得過程，對於原子服務咱們能夠組合爲組合服務，對於業務服務咱們能夠經過組合和編排造成流程子服務和流程服務；最終使可重用的服務知足流程交互的須要。

在跨系統的流程集成和SOA應用集成過程當中，高端建模重點則是EA企業架構或TOGAF方法論，從業務架構，數據架構和應用架構入手，逐層分解和展開分析來得出整體的跨業務系統流程交互和集成架構。而對於系統內的SOA應用，則重點仍然是業務組件識別，經過組件間交互獲得的服務組件和服務識別，可重用的服務組件單元的提取。

那麼對於應用系統自己基於SOA架構又如何理解？若是說一個應用系統基於SOA架構，咱們至少須要看到該應用系統有明確的業務組件和服務組件定義，並且組件之間知足高內聚鬆耦合的要求；其次對於組件間的交互都經過服務的方式進行，或者至少預留了服務接口；其次內部這些服務能夠靈活的重用或組合。至因而否有內部的ESB總線反而不是重點，可是咱們看到如Java開發內部的IOC機制基本也基於內部的軟總線思路，實現良好的互操做性和位置透明。

SOA另一個核心是實現兩個層面的解耦，一個是業務和技術的解耦，業務實現再也不依賴於某種特定的技術或語言，只要知足業務標準均可以來實現SOA和服務，正是由於業務和技術鬆耦合，技術的變化對業務影響越小。另一個方面則是操做方法和業務數據實體的解耦，對於操做方法咱們後續能夠經過WSDL文件定義，而傳輸的數據實體又能夠經過XSD定義，對於傳統RUP開發方法中，相似於控制類和實體類的分離。

SOA有一些基本特性，在這裏再作一下簡單解釋：

• 粗粒度：僅僅暴露須要暴露的東西，方法和傳輸都簡單，可是實現方法的內部過程則很複雜，業務規則或邏輯所有隱含在業務組件內部，不須要暴露。

• 無狀態：每次服務調用完成即完成，不會存儲任何全局狀態信息，這也是WebService的特性。

• 互操做：包括位置透明，經過ESB和UDDI，只須要關心服務目錄，而不須要關心具體提供服務的源系統。

• 標準化：有精確的服務契約和服務接口，這也是在SOA方法論中在服務識別和服務分析階段重要輸出。

若是再舉了簡單的例子來講明SOA，能夠用傳統的活字印刷術來講明，用於印刷的3000-4000個字便是最基礎的原子服務，有了這些原子服務咱們很容易經過這些活字去排版整篇文章。文章內容有調整咱們也只是須要調整這些原子服務的順序。可是若是全是單個漢字咱們其實排版工做量仍是很大，因此再向上咱們會出現詞組或經常使用短句，這些便是組合服務，這樣咱們排版速度能夠增長。可是能夠看到詞組或短語的可重用程度下降了。因此越到組合服務或流程服務，複用越困難，可是要是可以複用卻能大大提高效率。