|
看到SOA的一堆名詞，讀者可能會感到迷惑，有必要結合實際的應用環境進一步闡釋SOA的相關概念。
總體框架
圖1所示的就是一個SOA應用系統的大體框架結構。它大體上可以分為五個部分：
● 展現層（presentation）：圖1中5區，通過portal等技術建立展現平臺，方便用戶在這個界面上提出服務請求。
● 業務處理建模（business process modeling）：圖1中的4區，SOA元模型從MDA中繼承了平臺無關模型來對業務處理過程建模。這一部分獨立于服務設計和部署層。模型驅動架構MDA（Model Driven Architecture）的主要缺陷是在模型設計階段就對需求有完整的描述，而且沒有需求變更的反饋機制。SOA通過添加敏捷方法AM來應對需求變更的情況。
● 服務層(Services): 圖1中的3區，整個SOA的核心層，它承上啟下，對上響應業務模型，對下調用相關組件群完成業務需求,形成“業務驅動服務、服務驅動技術”的SOA事務處理格局。服務可以根據粒度分層。雖然細粒度提供了更多的靈活性，但同時也意味著交互的模式可能更為復雜。粗粒度降低了交互復雜性，但敏捷性卻下降。
● 企業組件層（enterprise components）：圖1中的2區，這里是相關組件發揮作用的場所。這些組件是平臺相關的。因為到了這一層，許多底層軟硬件平臺的特性已經不再透明了。
● 系統軟件層(Operational System):圖1中的1區，這一層包括操作系統、數據庫管理系統、CRM、ERP、商業智能(BI)等異構系統，是一個集成的平臺。
除此之外，諸如QoS、安全性等(圖1中7區)也是SOA架構的組成部分。
在上面的介紹中，自上而下有一條線，如圖2所示，由業務建模開始，通過定義業務過程，得到服務模型，它是平臺無關的，實現了模型與實現的分離。再通過設計組件群，得到平臺相關的組件模型。
實施原則
Jason Bloomberg在其《Principles of SOA》中指出，SOA的實踐必須遵循以下原則：
● 業務驅動服務，服務驅動技術。從本質上說，在抽象層次上，服務位于業務和技術中間。面向服務的架構設計師一方面必須理解在業務需求和可以提供的服務之間的動態關系;另一方面，同樣要理解服務與提供這些服務的底層技術之間的關系。
● 業務敏捷是基本的業務需求。SOA考慮的是下一個抽象層次：提供響應變化需求的能力是新的“元需求”，而不是處理一些業務上的固定不變的需求。從硬件系統以上的整個架構都必須滿足業務敏捷的需求，因為，在SOA中任何的瓶頸都會影響到整個IT環境的靈活性。
● 一個成功的SOA總在變化之中。SOA工作的場景，更像是一個活的生物體，而不是像傳統所說的“蓋一棟房子”。IT環境惟一不變的就是變化，因此面向服務架構設計師的工作永遠不會結束。對于習慣于蓋房子的設計師來說，要轉向設計一個活的生物體要求有嶄新的思維方式。SOA的基礎還是一些類似的架構準則。
與其他概念的關系
1. SOA與Web Services的關系
SOA構架是獨立于技術實現的。SOA并不必用Web Services來實現，相反，Web Services也并不一定遵循SOA標準。
不過，Web Services的特性十分適合用來實現SOA架構。Web Services 之間能夠交換帶結構的文檔（比如XML），這些文檔可能包含完全異構的數據信息。這些文檔可以同時附帶關于數據的數據：元數據（metadata）。換句話說，Web Services可以有較粗的粒度，這樣較粗的粒度正好可以構成SOA中服務的粒度。
說到底，兩者是相交的圓，SOA服務和Web Services之間的區別還在于設計。SOA概念并沒有確切地定義服務具體如何交互，而僅僅定義了服務如何相互理解。其中的區別也就是定義如何執行流程的戰略與如何執行流程的戰術之間的區別。而另一方面，Web Services在需要交互的服務之間如何傳遞消息有具體的指導原則；從戰術上實現SOA模型是通過 HTTP傳遞的SOAP消息中最常見的SOA模型。因而，從本質上講，Web Services是實現 SOA的具體方式之一。
2. SOA中的服務與組件對象（Components Objects）的關系
相似之處在于：都有一個或多個接口，并且，服務發布者和使用者都遵守這些接口。
不同之處在于：SOA是關于模式（schemas）的，組件對象是關于對象類型（object types）的；SOA通過像SOAP這樣的標準消息機制（messages）來實現通信，而組件對象通過方法調用（method calls）來交互。與CORBA 中的接口定義語言IDL (Interface Definition Language)相比，SOA 在WSDL (Web Services Definition Language) 中采用XML，會顯得更加普遍和通用。
聯系之處在于：服務最終還是通過類和組件對象來實現的。
SOA被認為是傳統緊耦合的、面向對象的模型的替代者。像通用對象代理架構CORBA (Common Object Request Broker Architecture)和分布式組件對象模型DCOM (Distributed Component Object Model)。在SOA 中，單個服務可以用面向對象方法來設計，但是，整個SOA的設計卻是面向服務的。下面的表格中給出了SOA與分布式組件架構的不同點。
3. SOA與網格計算（Grid Computing）的關系
網格計算（Grid Computing）是利用互聯網技術，把分散在不同地理位置的計算機組成一臺虛擬超級計算機。每一臺參與的計算機就是其中的一個“節點”，所有的計算機就組成了一張節點網——網格。從實質上來說“網格計算”是一種分布式應用，網格中的每一臺計算機只是完成工作的一個小部分，雖然單臺計算機的運算能力有限，但成千上萬臺計算機組合起來的計算能力就可以和超級計算機相比了。
網格計算基于因特網，提供了資源整合和共享的平臺。十分適合作為SOA架構的實施平臺。
我們來具體地看一下：
SOA 的構建策略：創建一個面向服務的計算SOC（service-based computing）環境；可以用類似于web services的技術來設計服務：使用SOAP通信機制；采用XML數據格式；強調服務的重用和互操作；最大化的應用現有資源；希望有一個類似于網格計算環境的基礎平臺。
網格作為平臺的基本特點：網格被視為一個由各種計算資源組成的統一環境，其管理軟件將網格整合成一個完整而協調的透明計算整體；網格是一個虛擬的應用服務器;是一個應用實現和數據處理的理想平臺；服務在網格中部署和調用執行；商業邏輯和服務調用被當成網格程序一樣在平臺上運行；網格為SOC計算的有效性、快速性、靈活性、伸縮性和計算環境的管理提供便利。
SOA帶給企業什么？
作為需要構建SOA應用的企業來說，究竟有些什么好處呢？我們來看一下：
● 集成現有系統，不必另起爐灶。面向服務的體系結構可以基于現有的系統投資來發展，而不需要徹底重新創建系統。通過使用適當的 SOA 框架并使其用于整個企業，可以將業務服務構造成現有組件的集合。使用這種新的服務只需要知道它的接口和名稱。服務的內部細節以及在組成服務的組件之間傳送的數據的復雜性都對外界隱藏了。這種組件的匿名性使組織能夠利用現有的投資，從而可以通過合并構建在不同的機器上、運行在不同的操作系統中、用不同的編程語言開發的組件來創建服務。遺留系統可以通過 Web 服務接口來封裝和訪問。
● 服務設計松耦合， 帶來多方面優點。服務是位置透明的，服務不必與特定的系統和特定的網絡相連接。服務是協議獨立的，服務間的通信框架使得服務重用成為可能。對于業務需求變化，SOA能夠方便組合松耦合的服務，以提供更為優質和快速的響應，允許服務使用者自動發現和連接可用的服務。松耦合系統架構使得服務更容易被應用所集成，或組成其他服務，同時提供了良好的應用開發、運行時服務部屬和服務管理能力。提供對服務使用者的驗證（authentication） 授權（authorization），來加強安全性保障，這一點也優于其他緊耦合架構。
● 統一了業務架構，可擴展性增強。在所有不同的企業應用程序之間，基礎架構的開發和部署將變得更加一致。現有的組件、新開發的組件和從廠商購買的組件可以合并在一個定義良好的 SOA 框架內。這樣的組件集合將被作為服務部署在現有的基礎構架中，從而使得可以更多地將基礎架構作為一種商品化元素來加以考慮，增強了可擴展性。又由于面向服務的敏捷設計，在應對業務變更時，有了更強的“容變性”。
● 加快了開發速度，減少了開發成本。組織的 Web 服務庫將成為采用 SOA 框架的組織的核心資產。使用這些 Web 服務庫來構建和部署服務將顯著地加快產品的上市速度，因為對現有服務和組件的新的創造性重用縮短了設計、開發、測試和部署產品的時間。 SOA 減少了開發成本，提高了開發人員的工作效率。
研究表明，一般系統的接口的開發費用占到整個開發費用的33%，最高的竟達到了70%。在SOA中，接口的重用會節省費用60%。而且節省的費用不是一次性的，而是每年。隨著業務需求的發展和新的需求的引入，通過采用 SOA 框架和服務庫，為現有的和新的應用程序增強和創建新的服務的成本大大地減少了。同樣，開發團隊的學習難度也降低了，因為他們可能已經熟悉了現有的組件。
● 持續改進業務過程，降低激變風險。SOA允許清晰地表示流程流，這些流程流通過在特定業務服務中使用的組件的順序來標識。這給商業用戶提供了監視業務操作的理想環境。業務建模反映在業務服務中。流程操縱是以一定的模式重組部件（構成業務服務的組件）來實現的。這將進一步允許更改流程流，而同時監視產生的結果，因此促進了持續改進。重用現有的組件降低了在增強或創建新的業務服務過程中帶來的風險，也減少了維護和管理支持服務基礎架構的風險。
|