SOA進(jìn)化之SOA的根源(3)

　　除了一些罕見(jiàn)的應用以專(zhuān)有擴展的方式嵌入到瀏覽器中以外，分布式互聯(lián)網(wǎng)應用將其所有應用邏輯放在了服務(wù)器端。甚至客戶(hù)端腳本想要執行在網(wǎng)頁(yè)上的一個(gè)事件響應，都要從Web服務(wù)器基于初始的HTTP請求來(lái)下載。沒(méi)有客戶(hù)工作站上保存的邏輯，整個(gè)解決方案都是集中式的。

　　從而強調了：

　　﹡　應用邏輯應當如何被分割
　　﹡　被分割的處理邏輯應當駐留在何處
　　﹡　處理邏輯應當如何交互

　　應從一個(gè)物理的角度來(lái)看，面向服務(wù)架構與分布式互聯(lián)網(wǎng)架構非常相似。提供者邏輯駐留于服務(wù)器端而被分割成單獨的單元。其中差異由剛剛所列三個(gè)主要設計原則所決定。

　　傳統的分布式應用包含了駐留于一個(gè)或多個(gè)應用服務(wù)器上的一系列的構件。構件設計為不同粒度的功能，依賴(lài)于所執行的任務(wù)，以及它們被其他任務(wù)或應用的復用范圍。駐留于相同服務(wù)器的構件通過(guò)專(zhuān)有API通信，按照它們暴露的公共接口來(lái)調用。RPC協(xié)議被用于實(shí)現跨越服務(wù)器邊界的通信。這有可能通過(guò)使用代表遠程構件的本地代理存根來(lái)實(shí)現(圖6)。

圖6 構件通信依賴(lài)于代理存根

　　在設計時(shí)，預期的交互構件將與其他一起考慮---如此強烈以致實(shí)際對其他物理構件的引用可嵌入到程序代碼內。這個(gè)設計時(shí)水平的依賴(lài)是緊耦合的形式。這樣的稍許處理相對于試圖在運行時(shí)定位所需構件的浪費而言是有效的。然而，嵌入式耦合導致綁定構件網(wǎng)絡(luò )，一旦實(shí)現，不易更改。

　　當代SOA依然使用并依賴(lài)于構件。然而，整個(gè)建模方法現在會(huì )考慮創(chuàng )建封裝一些或所有構件的服務(wù)。這些服務(wù)根據面向服務(wù)原則而設計，并且策略性地定位及暴露特定的功能集。同時(shí)這個(gè)功能可由構件提供，也可源自遺留系統及其他資源，象來(lái)自其它套裝軟件產(chǎn)品的適配器接口，或者甚至是數據庫。

　　在服務(wù)內包裝功能的目標是經(jīng)由一個(gè)開(kāi)放的、標準化的接口暴露功能---而不用關(guān)心用于實(shí)現底層邏輯的技術(shù)。標準化的接口支持置于SOA核心的開(kāi)放通信框架。而且，使用Web服務(wù)建立了松散耦合的環(huán)境，其中也運行著(zhù)相對設計的分布式應用。如果設計得當，松散耦合的服務(wù)支持組合模型，允許單個(gè)的服務(wù)參與集合的設計。這引入了持續的復用與擴展機會(huì )。

　　有關(guān)分布式應用邏輯的設計與行為的另一個(gè)重要轉變在于服務(wù)如何交換信息。當傳統構件提供方法時(shí)，一旦被激活，就發(fā)送與接受參數數據，而Web服務(wù)通過(guò)SOAP消息通信。即使SOAP支持RPC風(fēng)格的消息結構，大多數面向服務(wù)的Web服務(wù)設計卻依賴(lài)于文檔風(fēng)格的消息。(這一重要差別在后面探究。)

　　消息也是結構化的并盡可能是自足的。通過(guò)使用SOAP報頭，消息內容可以伴隨闃寬泛的元信息、處理指導以及策略規則。與純粹構件世界內的數據交換相比較，SOA所用的通訊框架更加復雜、更加龐大，并且更易導致少數的個(gè)別傳輸。

　　最后，盡管也普遍強調復用傳統的分布式設計方法，SOA可通過(guò)促進(jìn)解決方案未知服務(wù)的創(chuàng )建鼓勵復用以及深層次的跨應用協(xié)同。

　　應用處理

　　不管什么平臺、構件都代表了最大部分的應用邏輯并因此負責大多數的處理。然而，因為用于構件間通信的技術(shù)不同于完成服務(wù)間通信的技術(shù)，處理需求也是如此。

　　分布式互聯(lián)網(wǎng)架構促進(jìn)專(zhuān)有通信協(xié)議的使用，象用于遠程數據交換的DCOM和廠(chǎng)商實(shí)現的CORBA。當這些技術(shù)遭遇歷史性挑戰時(shí)，它們相對是有效可靠的，特別是一旦有主動(dòng)連接時(shí)。它們能夠支持有狀態(tài)和無(wú)狀態(tài)構件的創(chuàng )建，主要影響同步數據交換(一些平臺支持異步通信，但并未普遍使用)。

　　另一方面，SOA依賴(lài)基于消息的通信。包括負載有XML文檔的SOAP消息序列化、傳輸及去序列化。處理步驟會(huì )包括將關(guān)系數據轉換成XML兼容結構、XML文檔預校驗以及隨后的傳輸、以及對所接收文檔進(jìn)行解析和抽取。盡管已有所進(jìn)步，譬如企業(yè)解析器及硬件的持續加速，大部分還是抱怨SOAP比RPC通信明顯要慢一些。

　　在面向服務(wù)應用環(huán)境中，因為SOAP服務(wù)器的網(wǎng)絡(luò )能夠有效代替RPC風(fēng)格的通信通道，導致系統開(kāi)銷(xiāo)成為一個(gè)重要的設計問(wèn)題。文檔與消息建模規約及校驗邏輯的布置策略是重要因素，形成了面向服務(wù)架構的傳輸層。

　　這個(gè)通訊框架促進(jìn)了自治服務(wù)的創(chuàng )建，支持寬泛的消息交換模式。盡管完全支持同步通信，但還是鼓勵異步模式，因為它們提供了由通信最小化而帶來(lái)的進(jìn)一步優(yōu)化的機會(huì )。深入支持無(wú)狀態(tài)服務(wù)是不同語(yǔ)境的管理可采取的措施，包括使用WS-*規范，如WS-協(xié)調與WS-BPEL，還有定制解決方案。