canonical

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

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


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

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

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


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

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