canonical

http://www.xml.com/pub/a/ws/2003/09/30/soa.html
http://canonical.blogdriver.com/canonical/809426.html

   隨著IBM, Microsoft這些世界級大廠商不遺余力的推銷，SOA(Service Oriented Architecture)已經成為企業應用中的核心概念之一。我的一個同學在IBM做SOA架構咨詢，前兩天也和他聊到這個話題。從他們IBM的態度來 看，SOA無非是后EJB時代一個profitable enabled的概念而已。現在軟件廠商的日子變得愈加艱難了，很多廠商都希望向服務轉型，成為所謂IT service provider. 這是某種商業架構上的service oriented, 與技術上的SOA似乎有一些相互映襯的關系。IBM極力希望把SOA中的service概念提升到business layer, 希望在超越BPM(Business Process Management)的層次上提供一站式的打包服務。但是很顯然，此service非彼service, 這種SOA的宣傳中頗有一些偷換概念之嫌。把所有可以讓用戶買單的理由用MDA(Model Driven Architecture)做包裝，打包到一個獨立概念的package中在目前確實是一種可行的商業策略，只不過相對于用戶脆弱的技術理解力而言，這種 SOA實在是不可承受之重。大多數用戶所能理解的SOA不過是Integration的代名詞，與EAI(Enterprise  Application Integration)沒有什么可區分性。目前java技術的普及已經使得各個廠商的區別變得很小了，IBM這些巨型廠商鼓吹它們在異構系統集成方面的 優勢當然是勢所難免，在此過程中加點料也是可以理解的。


   雖然SOA這一概念中混雜了太多的商業因素，它也并不是一種單純的fantasy. 從技術角度上說，SOA存在著如下關鍵性特征：
1. 獨立運行(standalone)。所謂的service, 它與組件(component)的根本不同，首先在于service是獨立于調用者自行運轉的。訪問service的接口相對狹窄，我們只需要知道 service如何滿足我們的功能需求，而不需要管理它的生命周期，不需要理會那些維持service運行所需要考慮的種種細節。即我們對于 service的了解只需要局限于功能接口即可，不需要理會它的那些管理接口，配置接口等。各種service在功能接口這一層面發生交互，整個圖景得到 簡化。最常見的一個例子就是數據庫服務器，調用程序只要知道如何通過sql語言進行數據訪問即可，另有數據庫管理員去對付各種配置管理問題。從技術上說， 這可以看作是singleton模式的一種擴展。實際上spring容器中管理的bean在某種程度上就可以看作是獨立于bean的調用者的，因而 spring這樣的容器可以成為SOA架構的自然接入點。

2. 異步調用(asynchronous)。內稟的異步特性是SOA包容真正的商業智能的關鍵所在。想象一下我們現在需要評估用戶的信用度,它對應于函數 evaluateCustomerCredit(customer). 最簡單的情況下，我們只需要根據用戶的某些指標直接進行算術運算即可。如果評估規則非常復雜，我們可能放棄硬編碼，而引入規則引擎（Rule Engine)這種人工智能的解決方案。在更加復雜的情況下，我們可能無法抽象出以數學方式表達的規則，而必須依賴于業務人員的人工處理（真正的智能）。 此時，系統可能需要彈出一個頁面，等待業務人員作出判斷，部分情況下還需要經過審批流程才能決定對于用戶信用度的最終評定。對于計算機系統而言，這些都是 漫長的過程，是同步調用方式所無法容納的。同樣是一個函數調用，只有異步特性才能夠包容真正的商業智能，才能在函數這種最小的程序結構單元中引入最復雜的 處理過程。現在SOA的宣傳往往集中于機器之間的互相調用，強調異構系統之間的一種包容性，但事實上異步特性所能承載的內容要遠遠超越機器世界本身。當 然，同步調用方式也是SOA架構的自然組成部分，就像我們既需要email， 也需要手機一樣。

3. 基于消息(message based)。基于消息的調用方式是分布式系統的一種內在要求。消息是一種數據，它并不是遠程對象指針。distributed object這種基于proxy-stub的方案其內稟要求是遠程狀態同步（狀態的一致性）,而分布式系統是由眾多獨立的狀態空間（進程空間）所構成的， 這種內在的不協調是造成分布式對象方案難以實現可擴展性的關鍵原因。
  SOA與EBI(event-based integration)的區別主要在于EBI往往是push模式的，消息源向注冊的消息consumer推送消息，而SOA往往還是一種pull的調 用。這兩種方式各有千秋，在大的scale情況下，pull模式的可擴展性要更好一些。但是兩種模式在企業應用中都是必不可少的，可能這些概念很快就會出 現融合。


4. 純文本協議+元數據(Plaintext Meta)。SOA架構中基于純文本協議是一個非常關鍵的技術抉擇。當需要跨越眾多硬件平臺和軟件系統的時候，各種二進制的RPC方案總是存在著難以徹底 解決的可理解性的問題。憑借純文本的結構透明性加上元數據的自描述特性，我們希望實現一種語義透明性，使得各種中間層都能夠以通用的方式傳遞經過的消息， 并理解其中需要理解的部分。與OOP(Object Oriented Programming)中的傳統模式不同的是，SOA架構中強調的是結構(structure)與內容(content)的分離，而不是數據與行為的耦 合與封裝. 表面上看起來，SOA中的調用方式似乎是對procedure（過程）化調用的回歸，但實際上其中有著深刻的不同。在與元數據結合之后，在系統之間傳遞的 消息（信息）并不是完全被動的，而是具有某種smart特性。當數據這一方面可以包容更多的變化的時候，處理函數這一方面的結構可以得到簡化。實際上，在 SOA架構中，我們推崇一種uniform interface, 也只有通過一種通用的接口，信息才能以比較低的代價穿越各種狀態空間邊界。基于通用接口，我們又重新發現了世界的簡單性，而pipe-and- filter這種在unix系統中久經考驗的設計模式也得到了新的發揮空間。
    說到純文本的元語言，xml無疑是這一概念最強勢的候選者。作為一種半結構化的文本表述，xml天然就是人機共享的信道。但是，隨著應用的深入，當越來越 多的xml設計變得無法讓人直觀理解的時候，我們也感覺到了一些對于xml濫用的痕跡。W3C的Web Service協議棧提供了非常關鍵性的思想，并作為標準化的實現方式存在了很長的時間了，但是其實現和調用的繁瑣和冗長逐漸引起了開發者的不滿。 SOAP雖然號稱Simple Object Access Protocol，但是今天已經很難把它和simple這個詞拉上什么關系。也許Web Service的未來就如同EJB一樣, 漸漸被更加pragmatic的方案所取代。

    在SOA架構中，松散耦合(loose couple)是late binding(discovery), standalone和message based等多種技術策略綜合作用之后所達到的一種效果，這為外部靈活的流程配置做好了鋪墊。