摘要軟件開發(fā)又一次走到了十字路口。分布而相互連接的系統(tǒng)已成為了開發(fā)中的常態(tài)， 以至于“應(yīng)用”這個(gè)詞匯都得重新定義。松耦合（loosely coupled）結(jié)構(gòu)， 如面向服務(wù)的架構(gòu)（Service-oriented Architectures －SOA）使得相互連接 的系統(tǒng)獨(dú)立進(jìn)行變化和演進(jìn)成為可能。同時(shí)，模型驅(qū)動(dòng)架構(gòu)（Model-driven Architectures－MDA）致力于對(duì)系統(tǒng)進(jìn)一步的抽象和大面積地代碼自動(dòng)生成 以簡(jiǎn)化軟件開發(fā)。這讓我們想探究這些因素對(duì)于在面向服務(wù)的世界里開發(fā)軟件 意味著什么。難道這意味著業(yè)務(wù)分析師可以用圖形工具把相關(guān)的軟件部件連到 一起就了事嗎？這意味著開發(fā)人員是用元－元－模型（meta-meta-model） 加上某個(gè)特定應(yīng)用域的語(yǔ)言來編程嗎？開發(fā)人員需要一些嶄新的編程思路與 范式嗎？我們?nèi)绾螠?zhǔn)備好以迎接挑戰(zhàn)？ 目錄
1 右擊，生成Web Service毫無疑問，Web Services 標(biāo)準(zhǔn)的出現(xiàn)使得原來很枯燥的編程變得非常容易并且 更有效率。例如，我最近開發(fā)了一個(gè)小應(yīng)用程序，用來檢索Amazon上面我的著作 的銷售排行榜并把這個(gè)信息電郵到我的手機(jī)上。自然，這個(gè)應(yīng)用程序需要通過 Internet到外面一個(gè)組織里去檢索數(shù)據(jù)。開發(fā)這樣一個(gè)程序卻是再容易不過了， 我只需把我的IDE對(duì)準(zhǔn)Amazon提供的WSDL，客戶端的代理類代碼就會(huì)自動(dòng)生成。 我只要在代碼中加入幾行，我的程序就能啟動(dòng)運(yùn)行了。這個(gè)應(yīng)用不僅含有所有 的時(shí)髦的名詞 － Web Services, XML, WSDL, SOAP,你還可以加上一些 － 并且它還是能做一些有用的事情（提升一個(gè)作者的虛榮心）。 同樣地，把一個(gè)系統(tǒng)中存在的功能暴露成Web Services也已經(jīng)變得簡(jiǎn)單。例如，讓開發(fā) 人員指定一個(gè)功能調(diào)用（method），然后從彈出的菜單中選擇“生成Web Service”， 許多開發(fā)工具離這個(gè)要求大致都不遠(yuǎn)了。另外，設(shè)想把我的這個(gè)小程序改進(jìn)一下， 升級(jí)成一個(gè)公共的Web Service，讓用戶提交書號(hào)（ISBN）和電郵地址，這個(gè)服務(wù) 就會(huì)讓用戶定期收到銷售排行數(shù)據(jù)。這個(gè)改進(jìn)只需一些瑣碎的工作，并不困難。 2 Web或是服務(wù)或是架構(gòu)？不過，就象一只燕子并不能創(chuàng)造夏天一樣，建立一個(gè)服務(wù)并不意味著建立面向服務(wù)的架構(gòu)。 我的簡(jiǎn)單應(yīng)用程序是建立在統(tǒng)稱之為Web Services的一套技術(shù)上，但是卻幾乎不能說這是 一個(gè)面向服務(wù)架構(gòu)的例子。在我之前許多人已經(jīng)討論過Web Services（一組相關(guān)的技術(shù)的 集合）和面向服務(wù)的架構(gòu)（一種架構(gòu)風(fēng)格）[1]，所以我在此不重復(fù)。可是，讓我們仔細(xì) 看看到底是什么讓一個(gè)架構(gòu)是面向服務(wù)的。 許多流行的架構(gòu)風(fēng)格似乎都是在克服其前任的缺點(diǎn)基礎(chǔ)上而形成的。說到底，系統(tǒng)開發(fā)的風(fēng)格 總是會(huì)演進(jìn)的，今天的系統(tǒng)會(huì)是明天遺產(chǎn)。這同樣適合于SOA。SOA后面一些最主要的 驅(qū)動(dòng)因素是解決開發(fā)人員和架構(gòu)師在前一個(gè)架構(gòu)，即分布式部件架構(gòu)（Distributed Component - DC）中遇到的問題。特別是如下問題：
面向服務(wù)的途徑是如何來解決這些問題的呢？它是使用了簡(jiǎn)化的、面向文檔的交互模型， 該模型是基于技術(shù)中立（technology-neutral）和標(biāo)準(zhǔn)化的協(xié)議。在面向服務(wù)的架構(gòu)下， 靈活的文檔格式、明確的契約、服務(wù)注冊(cè)（service registries）、和異步交互風(fēng)格使得 服務(wù)（部件）間交互的耦合被減至最小。 甚至于我的那個(gè)簡(jiǎn)單的程序都能受益于這些SOA的特性。例如，我的程序是用C#寫的，它去 造訪Amazon的Web Service卻毫無問題，盡管服務(wù)端不太可能是用同一種語(yǔ)言寫的。另外， 我也不需要用一個(gè)“遠(yuǎn)程工廠”（remote factory）去創(chuàng)建一個(gè)遠(yuǎn)程對(duì)象（remote object） 來執(zhí)行我的查詢請(qǐng)求。其實(shí)，我只要把一份XML文檔（由stub產(chǎn)生）傳遞給遠(yuǎn)程的服務(wù)就行了。 但另一個(gè)微妙卻很重要的方面在我的例子中還沒有顯現(xiàn)出來。例如，在 遠(yuǎn)程服務(wù)處理請(qǐng)求的時(shí)候，客戶端程序一直把持著一個(gè)與遠(yuǎn)程服務(wù)的TCP連接。而代理對(duì)象 （proxy object）也是在同步地（synchronously）等待著結(jié)果，在此期間，客戶端程序 不能去做其他任何事情。這個(gè)簡(jiǎn)單的程序模型絕對(duì)是“遠(yuǎn)程過程調(diào)用”（remote-procedural call）。 盡管這種模型是很方便的，但它并不適合遠(yuǎn)程面向服務(wù)的交互。 那么，到底是什么能讓我們從建立一個(gè)Web service的演示程序這種瑣碎事務(wù)中更進(jìn)一步 成為一個(gè)能夠開發(fā)松耦合的面向服務(wù)架構(gòu)系統(tǒng)的真正的開發(fā)人員呢？ 3 架構(gòu)師的美夢(mèng) － 開發(fā)者的惡夢(mèng)？在“企業(yè)應(yīng)用架構(gòu)模式”（Patters of Enterprise Application Architecture） 一書中 [2], Martin Fowler 警告說，松耦合的分布式系統(tǒng)架構(gòu)在白板上看上去 很漂亮，卻很容易成為“架構(gòu)師的美夢(mèng) － 開發(fā)者的惡夢(mèng)”。讓一個(gè)系統(tǒng)成為分布式 是增添了整個(gè)一層的復(fù)雜性，這點(diǎn)是沒什么疑問的。例如，配置和部署（configuration and deployment）變得更困難了，你還得來對(duì)付響應(yīng)時(shí)間、一些新的失敗情形如網(wǎng)絡(luò) 中斷或部件間的版本號(hào)失配。 如上所述，松耦合架構(gòu)的出發(fā)點(diǎn)是減少部件間交互的復(fù)雜性和減少它們之間的耦合。 耦合可以粗略地用一個(gè)部件對(duì)交流方的假設(shè)條件數(shù)目來測(cè)量。例如，松耦合架構(gòu) 一般對(duì)各部件的實(shí)現(xiàn)技術(shù)不做假設(shè)。同樣地，當(dāng)數(shù)據(jù)格式有小變化時(shí)，如 增加一些新的數(shù)據(jù)項(xiàng)，這種架構(gòu)也不失其穩(wěn)固性。正是減少了假設(shè)條件數(shù)使得 交流各方能夠獨(dú)立演變 － 這是松散耦合后面的關(guān)鍵驅(qū)動(dòng)因素之一。 但是，假設(shè)條件的減少又意味著開發(fā)人員的安全毯變薄了。強(qiáng)耦合使得編譯器能夠 捕捉到交流部件間的許多失配情況。如功能方法（method）名的誤拼、缺失的參數(shù)、 不匹配的數(shù)據(jù)類型都可以在編譯時(shí)發(fā)現(xiàn)。在松散耦合架構(gòu)中，這些都不存在了。結(jié)果是， 對(duì)一個(gè)緊耦合并具備調(diào)用堆棧（call stack）和共享存儲(chǔ)空間的應(yīng)用系統(tǒng)的查錯(cuò)調(diào)試 比在一個(gè)異型的（heterogeneous）、異步的（asynchronous）、分布式的環(huán)境中 查錯(cuò)調(diào)試要容易得多。 4 面向服務(wù)的世界里人的因素許多人認(rèn)為Web Services 是過度炒作，因?yàn)槲覀兛梢杂肅ORBA或類似技術(shù)來建造很好 的面向服務(wù)的應(yīng)用系統(tǒng)。當(dāng)然這種觀點(diǎn)有一定的道理，不過卻有些偏離了要點(diǎn)。 要知道在開發(fā)人員的頭腦中，除了要清楚知道可使用的技術(shù)與API方面的變化，也要了然架構(gòu)風(fēng)格 方面的變化。架構(gòu)風(fēng)格是基于共同的“意向”（intention），正確的平衡，以及觀念上的 一致。選擇一個(gè)合適的技術(shù)可以幫助實(shí)現(xiàn)需要的架構(gòu)風(fēng)格，但這還遠(yuǎn)遠(yuǎn)不夠。 好在歷史會(huì)時(shí)常地重復(fù)，特別是在系統(tǒng)架構(gòu)方面。我們可以作如下的類比：從分布式 部件結(jié)構(gòu)到面向服務(wù)架構(gòu)的演進(jìn)，可以比之于從過程式程序設(shè)計(jì)到面向?qū)ο蟮难葸M(jìn)，可以比之于 從文字用戶接口到圖形用戶接口的演進(jìn)。最初對(duì)新技術(shù)的采用是在新技術(shù)或新的API中使用 老的架構(gòu)風(fēng)格，這通常稱之為“豬鼻子插蔥－－裝象”。例如，用Web Services 替代RPC （remote procedure call）實(shí)際上是在視窗環(huán)境下使用文字接口的應(yīng)用系統(tǒng)的 翻版。當(dāng)然，你可以說這個(gè)系統(tǒng)是使用了新的GUI（圖形用戶接口）技術(shù)，你可以改變 窗口的大小，還可以把它移來移去。但應(yīng)用本身卻很難說是使用了新環(huán)境中真正的新 特性。學(xué)習(xí)如何建造真正GUI應(yīng)用需要使用新的工具、新的思維方式、新的設(shè)計(jì)模式以及 一套新的設(shè)計(jì)指引。有意思的是，新的API在這種用戶接口的轉(zhuǎn)型中其實(shí)只占了很小的比重。 同樣，我相信在向面向服務(wù)的轉(zhuǎn)型中，SOAP只會(huì)占相對(duì)較小的比重。特別是在近期， 面向服務(wù)系統(tǒng)的設(shè)計(jì)中會(huì)更多地依賴于慣例/約定（convention），而不是技術(shù)。例如， 在功能調(diào)用中，傳遞的參數(shù)不使用私屬（proprietary）數(shù)據(jù)類型便是這樣一個(gè)約定。 不去假設(shè)一個(gè)服務(wù)在什么地方也是一個(gè)約定。還有，我們?nèi)绾蝸肀苊庖粋€(gè)服務(wù)是過“粗” （too coarse grained）或過“細(xì)”（too fine grained）呢？如何來確定把多少業(yè)務(wù)邏輯 放在服務(wù)中，多少邏輯放在編排部分（orchestration layer）？目前，還沒有工具能 幫助我們決定或?qū)嵭羞@些指引。它們只不過是開發(fā)組內(nèi)大家對(duì)某一特定的架構(gòu) 風(fēng)格和意向的共同理解和約定。 對(duì)約定和慣例的依賴在松耦合的分布式系統(tǒng)中似乎顯得特別突出。松耦合意味著減少 部件間的假設(shè)條件。假設(shè)條件的減少意味著編譯時(shí)檢查和驗(yàn)證的弱化。因此，充分的驗(yàn)證 必須通過人與人之間的交流與約定來實(shí)現(xiàn)。 那么，對(duì)于開發(fā)松耦合的、面向服務(wù)架構(gòu)的應(yīng)用系統(tǒng)的開發(fā)人員來說，這意味著什么呢？ 這意味著人與人之間的交流顯得比以往更加關(guān)鍵。在文檔中記錄下全局圖像和設(shè)計(jì)意向?qū)τ? 保持架構(gòu)的完整性和一致性是至關(guān)重要的。近期來看，這意味著開發(fā)人員的工作會(huì)更加 辛苦，而非更輕松一些。這意味著，近期來看，在面向服務(wù)的架構(gòu)中最有用的工具會(huì)是 Word或PowerPoint（或是OpenOffice Writer 和 Impress）。 5 新工具新工具在面向服務(wù)的應(yīng)用開發(fā)轉(zhuǎn)型中是非常有用的。有趣的是在每次程序設(shè)計(jì)機(jī)制或技術(shù)轉(zhuǎn)型時(shí)， 新工具的出現(xiàn)似乎都是分成幾個(gè)特定的階段。我大致觀察到有三代工具支持新的技術(shù)： 第一代：后溯（Retrofit，向后看齊）。第一代工具一般來講是讓老的應(yīng)用看上去象新的。 這些工具把大型主機(jī)（mainframe）的綠色屏幕接口轉(zhuǎn)化成GUI，或是把一些老的COBOL程序 轉(zhuǎn)化成Web service。這當(dāng)然是很有用的，但需指出的是，這些工具只是簡(jiǎn)單地轉(zhuǎn)換了技術(shù)， 而非架構(gòu)風(fēng)格和意向上（intent）的轉(zhuǎn)換。 第二代：簡(jiǎn)單工具對(duì)付簡(jiǎn)單問題。這代工具讓開發(fā)人員能使用新技術(shù)和新風(fēng)格快速地 建立一些解決方案?？墒牵@代工具瞄準(zhǔn)的是一些簡(jiǎn)單的問題，這些問題可以用 （過分）簡(jiǎn)單化（或片面化）的途徑來解決。例如，許多早期的GUI工具可以從數(shù)據(jù) 庫(kù)的數(shù)據(jù)結(jié)構(gòu)定義（database schema）中直接生成結(jié)構(gòu)圖。這種途徑只適合于簡(jiǎn)單的 應(yīng)用系統(tǒng)（如CRUD型的應(yīng)用），卻不適合具有復(fù)雜業(yè)務(wù)邏輯的應(yīng)用。 第三代：有效的工具對(duì)付復(fù)雜的問題。這一代工具已超越了簡(jiǎn)單的問題。盡管它們不能 將復(fù)雜問題魔法般的瑣碎化，它們卻提供了有效的工具來幫助開發(fā)人員應(yīng)付復(fù)雜的問題。 Java IDE， 如 Eclipse 和 IntelliJ IDEA 就是這代工具的典型代表。 第三代工具在市場(chǎng)上出現(xiàn)需要相當(dāng)?shù)臅r(shí)間。原因有多種。首先，建造復(fù)雜的工具自然需要 花費(fèi)長(zhǎng)一些的時(shí)間。更重要的是，要想建造有效的工具來對(duì)付復(fù)雜的問題，你得花時(shí)間 去觀察開發(fā)人員是如何處理復(fù)雜問題的。這需要時(shí)間和經(jīng)驗(yàn)，同時(shí)也需要一批鐵桿的開發(fā) 人員，他們?cè)敢獠捎米钋把氐募夹g(shù)，使用不是那么完備的工具來解決復(fù)雜問題。 今天許多 Web Service 的工具都還是第一或第二代的。我們可以找到很多Web Service的“門面” （facade）工具，或是可以讓簡(jiǎn)單的應(yīng)用開發(fā)變得容易的工具，如象，“右擊，生成Web Service”。 那么，第三代工具會(huì)是什么樣的呢？我相信，我們會(huì)看到復(fù)雜完善的測(cè)試和查錯(cuò)工具， 象SOAPScope。我們也會(huì)看到監(jiān)控和管理工具的迅速演進(jìn)。這些工具能夠在系統(tǒng)運(yùn)行時(shí)（run-time） 發(fā)掘出服務(wù)和服務(wù)之間的交流，然后生成服務(wù)間的動(dòng)態(tài)依賴關(guān)系圖。它們也能讓我們把規(guī)則 （policy）即時(shí)地、同時(shí)地實(shí)施到多個(gè)分布式的服務(wù)中去。 我相信這些發(fā)掘和視像化的工具會(huì)在第三代SOA工具中扮演重要的角色。松耦合的一個(gè)基本 著眼點(diǎn)是要允許各個(gè)部件可以獨(dú)立地變化演進(jìn)。這意味著我們不能（我們也不想）事先對(duì)系統(tǒng) 預(yù)設(shè)一套自頂向下的條條框框，我們應(yīng)該允許系統(tǒng)以事先不能預(yù)測(cè)的方式演變。為了跟蹤 系統(tǒng)的變化，我們需要有工具來檢測(cè)系統(tǒng)當(dāng)前和以前的狀態(tài)，并以直觀的、易讀的方式顯示 出來（如圖形）。這些工具目前已在市場(chǎng)上出現(xiàn)，我認(rèn)為我們會(huì)看到更高級(jí)完備的工具會(huì) 在今后一兩年出現(xiàn)。 6 新的程序設(shè)計(jì)范式（New Programming Paradigms）學(xué)習(xí)新工具只是在向面向服務(wù)架構(gòu)的應(yīng)用的開發(fā)中的一小部分。我們已經(jīng)討論了采用SOA 是需要對(duì)系統(tǒng)部件間交互方式具備一種新的思路。它同時(shí)也需要開發(fā)人員去適應(yīng)新的 程序設(shè)計(jì)模型和范式（思維方式）。這里，我想著重介紹幾個(gè)主要的模型，當(dāng)然下面所列絕非完全。 6.1 對(duì)象與文檔間的映射（Object-Document Mapping）首先，以文檔為中心的途徑和面向?qū)ο蟮耐緩接兄⒚疃匾膮^(qū)別。面向?qū)ο蟮南到y(tǒng) 的一個(gè)特征是細(xì)粒的（fine-grained）的對(duì)象、對(duì)象間是用對(duì)象指稱（reference）或 指針（pointer）來高度連接和交互的。以文檔為中心的接口則是用來表達(dá)文檔，而非行為。其 表達(dá)方式通常是樹型結(jié)構(gòu)。因?yàn)槲臋n需要在多個(gè)系統(tǒng)間傳送，要管理對(duì)象指稱（reference） 會(huì)是非常困難、又很不方便的。文檔一般是粗粒的（coarse-grained），這樣可以很好 地支持部件間的封裝（encapsulation），減少網(wǎng)絡(luò)“聊天”（chattiness）。它們也 沒有繼承（inheritance）和多態(tài)性（polymorphism）的概念。 這些差別很微妙，但對(duì)于要成功地開發(fā)可維護(hù)的SOA卻很重要。它們?cè)谀撤N意義上 象是重現(xiàn)了OO系統(tǒng)與關(guān)系數(shù)據(jù)庫(kù)的“阻抗失配”（impedance mismatch）。O－R 映射是很微妙的，雖然這個(gè)問題已經(jīng)出現(xiàn)很長(zhǎng)時(shí)間了，但是新的映射工具卻仍然以 可觀的速度出現(xiàn)。許多當(dāng)前的Web Service工具可以比之于兩梯次（2－tier）的 數(shù)據(jù)開發(fā)工具，它們可以從數(shù)據(jù)庫(kù)的結(jié)構(gòu)定義（database schema）中生成GUI。如果 應(yīng)用模型與后面的數(shù)據(jù)模型很接近的話，這些工具可以工作得非常之好，但它們 通常不能支持開發(fā)那些有復(fù)雜的業(yè)務(wù)邏輯的應(yīng)用。同樣的，許多目前把OO系統(tǒng)中 的一個(gè)功能方法（method）暴露成Web Service的工具也有這個(gè)問題。當(dāng)你想在 大尺度上把具有復(fù)雜應(yīng)用邏輯的部件暴露成良好定義的服務(wù)的時(shí)候，這些工具 很快就會(huì)現(xiàn)出它們的局限性。其結(jié)果是，開發(fā)人員需要建造他們自己的映射層 來實(shí)現(xiàn)對(duì)象－文檔間的映射，或是等待更高級(jí)完備的工具的出現(xiàn)。 6.2 宣示型程序設(shè)計(jì)（Declarative Programming）有兩個(gè)常見于服務(wù)架構(gòu)或Enterprise Service Bus （ESB）中的核心功能，一個(gè)是變換 （transformation），另一個(gè)規(guī)則引擎（rule engine）。描述這些功能的程序設(shè)計(jì)模型一般 是宣示型的（declarative），這與大多數(shù)開發(fā)人員所熟悉的順序過程型（sequential-procedural） 風(fēng)格相反。例如，許多轉(zhuǎn)換工具是基于XSLT的，它是一種模式匹配（pattern match）的途徑。 XSLT處理是用一組規(guī)則去比對(duì)輸入的文檔，并選擇最特定（而非寬泛）匹配的規(guī)則執(zhí)行之。 有些工具會(huì)用“拖－扔”（drag-drop）接口把XSLT隱藏起來，但程序模型是基本一樣的。如果 你是從OO程序設(shè)計(jì)轉(zhuǎn)到XSLT，你大概會(huì)注意到這兩種情況：你的第一個(gè)XSLT文本在執(zhí)行時(shí)， 要么可能生成文檔的全部，要么什么都沒有，這是因?yàn)槟愕哪Ｊ狡ヅ淙e(cuò)了。另外，你的下意識(shí) 會(huì)誘惑你使用許多 <xsl:call-template>，因?yàn)檫@個(gè)構(gòu)造子是最接近于傳統(tǒng)的功能調(diào)用的 語(yǔ)義的。但它也是讓你的XSLT文本成為最糟的罪魁。 宣示型的程序設(shè)計(jì)系統(tǒng)可以導(dǎo)致一個(gè)很緊湊的解決方案。但這也需要不同的思維模式，另外， 查錯(cuò)也較困難，因?yàn)閳?zhí)行路徑（execution path）是在運(yùn)行時(shí)（runtime）確定的，而非在設(shè)計(jì) 時(shí)決定的。隨著轉(zhuǎn)換和規(guī)則引擎變得越來越普遍，開發(fā)人員需要學(xué)習(xí)如何設(shè)計(jì)與查錯(cuò)這樣的 宣示型子系統(tǒng)。 6.3 基于事件的程序設(shè)計(jì)（Event-based Programming）許多業(yè)務(wù)過程都是對(duì)事件作響應(yīng)，例如發(fā)來的訂單、付款或用戶來的電話。這意味著一個(gè) 功能的執(zhí)行，再也不是線性、順序的，而是需要在某個(gè)事件發(fā)生時(shí)作出反應(yīng)。這種風(fēng)格非常 不同于傳統(tǒng)的應(yīng)用開發(fā)，那里，開發(fā)者可決定什么事情可以以什么順序發(fā)生。 因此，事件驅(qū)動(dòng)的心理模式對(duì)多數(shù)開發(fā)人員來說需要一定時(shí)間來形成。從根本上說，事件驅(qū)動(dòng) 意味著拋棄“調(diào)用堆?！保╟all stack）。沒有了堆棧，執(zhí)行流（execution flow） 再也不是由“壓入－彈出”、同步（synchronous）調(diào)用、和局域變量來控制了。取而代之的 是，當(dāng)事件發(fā)生時(shí)，程序員需要顯式地（explicitly）來管理運(yùn)行的連續(xù)性和狀態(tài)。許多 過程和編排（orchestration）工具都提供了一些諸如“關(guān)聯(lián)數(shù)據(jù)集”（correlation sets） 和“使者”（convoy）的機(jī)制來幫助開發(fā)人員應(yīng)付這些問題。但是，開發(fā)人員仍然需要改變 心理模式以便能更有效地使用這些構(gòu)造子。 6.4 異乎尋常的異常處理（Exceptional Exception Handling）如果說，開發(fā)對(duì)事件響應(yīng)的軟件已是有足夠的挑戰(zhàn)性，那么系統(tǒng)中出錯(cuò)時(shí)又該如何處理呢？ 傳統(tǒng)的兩階段認(rèn)可事務(wù)處理（two-phase commit transaction）適合于可預(yù)見的、 相對(duì)緊耦合的模型，這是不言而喻、自然而然的。這種事務(wù)處理方式也需要在事務(wù) 發(fā)起者（initiator）、各個(gè)事務(wù)資源（resource）和事務(wù)協(xié)調(diào)者（coordinator）之間 有一套復(fù)雜完備的兩階段的交互模型。在面向服務(wù)的松耦合的環(huán)境里，這種風(fēng)格的交互是 不存在或不需要的。 在面向服務(wù)的世界里，更為普遍的錯(cuò)誤處理策略是重試（retry）補(bǔ)償（compensation）。 這些都不是新概念（例如，我們知道 Sagas 已經(jīng)超過15年），許多工具如BPEL引擎就支持 長(zhǎng)時(shí)運(yùn)行的事務(wù)和補(bǔ)償行動(dòng)?？墒?，如何有效地使用這些新的異常處理，包括模式和最佳 實(shí)踐指引，還沒有廣泛地為開發(fā)社群所知。就象基于模式的設(shè)計(jì)在OO中的傳播一樣，（面向 服務(wù)系統(tǒng)的）開發(fā)社群可能還要花上許多年才能采用這些新的交互模型。 6 圖件（Doodleware）分布式系統(tǒng)開發(fā)中，另一個(gè)前沿的程序設(shè)計(jì)風(fēng)格是圖形（視像）化的編程環(huán)境，有時(shí)被 稱之為“圖件”（doodleware）。用圖像來表達(dá)時(shí)間上并行的活動(dòng)，或是依賴關(guān)系是非常 非常有用的，這也廣泛地被用于過程和編排（orchestration）模型中，不過這也需要一些 時(shí)間來適應(yīng)。例如，要把系統(tǒng)擴(kuò)放到一個(gè)大的尺度就有些困難。有些開發(fā)人員已經(jīng)建議，銷售 圖形過程建模工具（軟件）時(shí)應(yīng)該帶一個(gè)顯示器作為必要的實(shí)物（為大尺度的應(yīng)用編程提供方便）。 另外，常用的文字處理工具如“diff”或“find-replace”（尋找－替換）基本上都不存在于 圖形世界中。查錯(cuò)會(huì)更加困難，盡管最近我已看到一些很不錯(cuò)的圖形調(diào)試工具出現(xiàn)。我想， 要在圖形世界里出現(xiàn)象文字世界中的Eclipse或IntelliJ那樣的成熟的開發(fā)環(huán)境，還需要相當(dāng) 的時(shí)日。 7 結(jié)語(yǔ)在面向服務(wù)的世界里的軟件開發(fā)在相當(dāng)長(zhǎng)的一段時(shí)間內(nèi)都會(huì)是一個(gè)很有意思的課題。Web service 的出現(xiàn)的確是消除了“EAI”中的一些苦澀成份，并且使分布式系統(tǒng)開發(fā)成為一項(xiàng)主流活動(dòng)。 但是，對(duì)于新的架構(gòu)風(fēng)格的普遍理解和相關(guān)工具的演進(jìn)只能在今后幾年中逐步實(shí)現(xiàn)。 許多第一代的SOA工具都有些欺騙性。開發(fā)一個(gè)成功的SOA并非是把一些小圖標(biāo)（icon）拖 過來扔下去那么簡(jiǎn)單。對(duì)開發(fā)人員來說，面向服務(wù)意味著學(xué)習(xí)新的程序設(shè)計(jì)模型和技術(shù)。 改變思維方式以有效地利用這些新模型可能是成功采用SOA的最大障礙。 About the Author Gregor Hohpe leads the Enterprise Integration practice at ThoughtWorks, Inc., a specialized provider of application development and integration services. Gregor is a widely recognized thought leader on asynchronous messaging architectures and co-author of the seminal book "Enterprise Integration Patterns". Gregor speaks regularly at technical conferences around the world and maintains the Web site www.. 關(guān)于作者Gregor Hohpe在ThoughtWorks領(lǐng)導(dǎo)Enterprise Intergration部門，ThoughtWorks是應(yīng)用開發(fā)與集成的 專業(yè)服務(wù)公司。Gregor被廣泛地認(rèn)為是異步消息架構(gòu)中的思想領(lǐng)導(dǎo)者，他是廣受好評(píng)的 “Enterprise Integration Patterns”一書的作者之一。Gregor經(jīng)常在世界各地的技術(shù)大會(huì)上作 演講，他也維護(hù)他的網(wǎng)站 www.。 參考資料
|
|
|
