|
這篇文章涉及到SOA、SCA、SDO、工作流、BPEL、ESB、消息中間件、WebService、EAI、分析設計方法、面向?qū)ο?、面向組件眾多技術(shù)，不仔細看，你仍然會混淆SOA=WebService=EAI。BPEL=工作流。ESB=消息中間件。但這些混淆全是錯誤的，你需要在以下的閱讀中體會他們的差異。如果你沒有耐心去理解這些技術(shù)的差異和來龍去脈，那么你可以直接閱讀最后一段，那里是總結(jié)。你可以無需了解過程，直接了解正確的結(jié)果。但可能會造成你只知道什么是正確的，但不明白為什么它是正確的。如果你正好想要這種結(jié)果，那么正合你的心意。
SOA很難，是因為領(lǐng)導SOA影響力和市場產(chǎn)品的公司把許多東西都裝進了SOA，以希望獲得一攬子解決方案。 這個解決方案從SOA項目的方案規(guī)劃咨詢方法到項目管理方法(如RUP，項目崗位角色職責流程評估)到業(yè)務描述方法(如UML)到中間件到業(yè)界標準(如WebService、SOAP、SCA、SDO)到系統(tǒng)整合診斷到系統(tǒng)整合接口設計(如如何設計面向服務的接口)到系統(tǒng)整合的業(yè)務流程整合(如BPEL)，而業(yè)務流程整合往往被業(yè)界的工作流和業(yè)務基礎(chǔ)平臺牽扯。而國外項目一牽扯到系統(tǒng)整合，就牽扯到遺留系統(tǒng)，什么Corba、COBOL、PL、SAP、JAVA，更是讓國內(nèi)的程序員茫然失措。 不僅僅是眾多領(lǐng)域的名詞、技術(shù)標準、產(chǎn)品名稱讓國內(nèi)程序員心慌，而且國內(nèi)的IT技術(shù)發(fā)展時間短，根本沒多少遺留系統(tǒng)，而且國內(nèi)的程序員也大多年輕，對過去的技術(shù)發(fā)展和遺留系統(tǒng)的產(chǎn)生和應用歷史，也不太清楚。所以把各種因素都綜合在一起，讓程序員望而卻步。而企業(yè)的CIO們，一看這么復雜，而且還搞不清楚有什么用，而且一定很貴，而且一定實施周期長風險大，就聽說業(yè)界鼓吹SOA有利于系統(tǒng)整合、SOA可以使你的IT和業(yè)務能靈活的隨需應變，但業(yè)界也始終沒有拿出讓人易懂和信服的案例說明怎么就能靈活的隨需應變和系統(tǒng)整合。于是，CIO們更是迷茫。 我就拿自己所感受所經(jīng)歷的，跟大家分享一下。 去年，做了一個中大的項目，項目周期耗時半年，中間當然還少不了經(jīng)常斗爭并合作著的IBM、SAP兩個老熟人。 項目是一個大型國企全國系統(tǒng)整合，從C/S的軟件到B/S的軟件都要整合在一個數(shù)據(jù)中心，并且在網(wǎng)絡門戶中可存取，還有專門的分析室使用數(shù)據(jù)中心數(shù)據(jù)進行商業(yè)智能分析。 當然，少不了Webservice、XML、消息中間件、BEPL、ESB。 過去局域網(wǎng)C/S管理軟件系統(tǒng)之間的整合，往往是通過互相讀取彼此的數(shù)據(jù)庫。但是在正規(guī)的項目中是不這樣做的。為什么。因為讀取和改寫哪個表的哪個字段，需要定義一個特殊的數(shù)據(jù)庫用戶，這還防不勝防，不知道是哪個系統(tǒng)把數(shù)據(jù)改亂了，誰來承擔責任。你如果只整合過兩個系統(tǒng)之間的數(shù)據(jù)交換，而且是寥寥幾個表的幾個字段的數(shù)據(jù)彼此讀寫，覺得這還沒什么，如果七八個系統(tǒng)都要整合在一起，互相讀寫，而且深度關(guān)聯(lián)，就天下大亂了。你往往會感嘆怎么CIO這么沒眼光，用了不同公司的不同產(chǎn)品，現(xiàn)在遭到報應了吧。其實，話不能這么說，很多時候的項目的上線由于天時、地利、人和，各種因素影響，就是形成了現(xiàn)在你所看到的現(xiàn)狀。如果你是CIO，這么多年下來，估計你的現(xiàn)狀不比現(xiàn)在好多少。企業(yè)就是這么發(fā)展的，雖然可能你在聚會吃飯的時候大發(fā)牢騷埋怨公司的管理和戰(zhàn)略和老板的決策，但真換你來做，你不見得會比你的老板強。就這個道理?，F(xiàn)狀已經(jīng)形成，歷史不能倒退，但未來還要前進，我們還不能把包袱扔掉，推倒重來。企業(yè)不是這么運作的。企業(yè)就是在不斷困境和限制中不斷前進，就看誰能把握好平衡和資源的調(diào)度，堅持執(zhí)行好決策。 過去我就遇見一個局域網(wǎng)C/S管理軟件系統(tǒng)整合的項目，人家不讓讀數(shù)據(jù)庫。人家給寫了一個DLL。可惜的是該死的PB寫的DLL。我們這方是DELPHI寫的DLL給他們。大家知道PB是偽編譯代碼，而且代碼是Script形式的，而DELPHI是二進制，而且是結(jié)構(gòu)化OO編程形式的。所以在數(shù)據(jù)內(nèi)存表示和格式和數(shù)據(jù)類型上都不匹配。最后都改成了字符串也不行。因為DELPHI的String，其實質(zhì)上也是指針型的。好不容易周折解決了數(shù)據(jù)類型問題，還有數(shù)據(jù)批量傳輸?shù)男阅軉栴}。一個DLL函數(shù)，我想把一條數(shù)據(jù)庫記錄傳給對方，怎么拼這個字符串。當時想定義N個參數(shù)，最后由于對方需要的字段不斷變動，最后接口老變，于是定義N個參數(shù)方案被廢棄，改為傳一條記錄。記錄的每個字段用特殊字符隔開，然后拼在一起，拼一個總的字符串，對方再拆出來處理。這還是一條記錄就這么麻煩，對于N條數(shù)據(jù)被數(shù)據(jù)集修改，就要調(diào)用N次接口函數(shù)，處理速度太慢。而且，還面臨雙方數(shù)據(jù)事務的阻礙。另外，由于我們不斷變動接口升級DLL，DLL版本黑洞也讓我們叫苦不迭。 這就是整合。這還不算雙方利益不統(tǒng)一引起的明爭暗斗，延遲給接口，提供錯誤信息和接口，提供很有限的信息。使項目整合周期異常的長，中間充滿了變數(shù)。所以，企業(yè)CIO一提到系統(tǒng)整合就頭疼，能躲就躲。 于是，WebService、XML、消息中間件、BEPL、ESB英明神武的上場了。 咱們也別定義N個參數(shù)了，也別拼字符串了，也別DLL互相硬編碼綁死了，也別費盡心思處理數(shù)據(jù)事務了。 有XML給咱們批量傳遞數(shù)據(jù)，數(shù)據(jù)是有格式的。接口也別你是PB的DLL，我是DELPHI的DLL了，咱們都是統(tǒng)一的數(shù)據(jù)類型和接口調(diào)用方式，都是WebService了。咱們倆也別綁死了，都發(fā)送到ESB中吧，讓ESB來處理事務、消息數(shù)據(jù)路由吧。咱們也別互相硬編碼，BEPL的XML格式描述的業(yè)務接口調(diào)用整合編排語言來幫忙，讓ESB引擎來驅(qū)動執(zhí)行BEPL。 ESB有點像消息中間件，用于消息數(shù)據(jù)的安全的、事務的路由。ESB也有點像組件中間件，提供了組件注冊，組件安全，組件版本、組件部署的功能(我懷疑很多功能是組件服務器功能增強后提供的，而不是ESB提供的)。但是ESB最獨特的是提供了BPEL的解析執(zhí)行監(jiān)控管理。BPEL設計器提供了BPEL的編排，而ESB提供了腳本的執(zhí)行。 整合省了不少的事。 但大家有沒有注意到一件事，我這個整合之事，我并沒有提到SOA。真是怪怪，滿篇案例講的洋洋灑灑，居然沒有SOA這個字眼出現(xiàn)。那怎么國際巨頭都拿這樣類似的整合項目來鼓吹他們的SOA呢。難道WebServvice+ESB+BPEL就等于SOA?那過去我們做的系統(tǒng)整合、EAI，豈不是我們N年前就SOA了?哈哈。 看來，這并不是SOA。我們需要從另一個角度分析SOA。
SOA，中文全寫是面向服務的體系結(jié)構(gòu)。這個名稱定義讓我們很是似曾相識。 面向服務?我們聽說過面向組件，面向?qū)ο?，面向函?shù)。是不是和這些有些淵源? 體系結(jié)構(gòu)?我們聽說過EJB、COM+、CORBA體系結(jié)構(gòu)，難道和這些體系結(jié)構(gòu)類似? 面向服務的體系結(jié)構(gòu)(Service-Oriented Architecture，SOA)是一個組件模型，它將應用程序的不同功能單元(稱為服務)通過這些服務之間定義良好的接口和契約聯(lián)系起來。 接口是采用中立的方式進行定義的，它應該獨立于實現(xiàn)服務的硬件平臺、操作系統(tǒng)和編程語言。這使得構(gòu)建在各種這樣的系統(tǒng)中的服務可以一種統(tǒng)一和通用的方式進行交互。 這是完整的定義： 1 是一個組件模型 2 不同功能單元，稱為服務 3 服務之間通過接口和約定聯(lián)系起來 4 接口是中立的 這個ㄒ迨嗆芐櫚摹?/P> (?? 這怎么和我多年前學習COM時說的一模一樣? 我找到別的網(wǎng)站上的一篇文章說的： SCA服務組件與傳統(tǒng)組件的主要區(qū)別在于： 1. 服務組件往往是粗粒度的，而傳統(tǒng)組件以細粒度居多。(不對，過去我們做COM，也有流程集合組件，是粗粒度的) 2. 服務組件的接口是標準的，主要是WSDL接口，而傳統(tǒng)組件常以具體API形式出現(xiàn)。(不對，只是接口實現(xiàn)技術(shù)不同而已，有這樣區(qū)別的么?) 3. 服務組件的實現(xiàn)與語言是無關(guān)的，而傳統(tǒng)組件常綁定某種特定的語言。(不對，很多語言都能實現(xiàn)COM) 4. 服務組件可以通過組件容器提供QoS的服務，而傳統(tǒng)組件完全由程序代碼直接控制。(不對，傳統(tǒng)組件也業(yè)由組件容器提供了若干服務) ) 雖然，一再聲稱WebService(XML\SOAP\UDDI\WSDL)不是SOA唯一的可接口中立的描述方法。但事實上，WebService是現(xiàn)在最成熟最有體系最獲得業(yè)界廠商支持的接口中立描述方法。所以，無論業(yè)界廠商怎么辟謠說WebService不是唯一方法，但大家都已經(jīng)默認。廠商的辟謠是因為有些遺留系統(tǒng)，現(xiàn)在沒有WebService的改造能力了，不支持WebService，不辟這個謠，就要丟單子。而國外很多老掉牙還不舍得扔的系統(tǒng)。所以國外非常羨慕中國，一上手就是最先進的技術(shù)和標準，沒有歷史包袱，不走彎路，整合花銷和風險和周期都會好很多。 SOA是一個組件模型。組件模型我們知道，COM+、EJB都是組件模型。組件有屬性、方法、事件。組件運行在組件容器中。組件容器來保證組件的創(chuàng)建、并發(fā)、池化、日志、銷毀。 而組件是脫胎于對象的?？纯锤鱾€語言實現(xiàn)的組件模型，其實現(xiàn)都是應用對象模型。對象具有數(shù)據(jù)和方法，沒有事件。而數(shù)據(jù)，也沒有什么讀寫限制。這是組件和對象非常明顯的區(qū)別。 我們曾經(jīng)面向函數(shù)編程，更早時候我們還寫過大流水沒有函數(shù)的程序代碼(現(xiàn)在想來甚是幼稚，簡直是一團漿糊，但我現(xiàn)在代碼復查的時候居然還能看見這類代碼，其跟蹤糾錯、質(zhì)量保證、變化裁減擴展、閱讀理解都不符合，如何能商業(yè)化開發(fā))。 但是函數(shù)無法表現(xiàn)函數(shù)間的關(guān)系。只好放到不同的源代碼文件中表示邏輯群集。但這種表示方法很是糟糕。數(shù)據(jù)和方法仍然沒有分離，也沒有屏蔽可見級別。于是，我們必須走向面向?qū)ο?。其實我們對OO，并不是像業(yè)界理論那樣分析業(yè)務、映射成對象，然后設計對象。其最開始就是為了解決代碼可視級別的事情，繼承和多態(tài)并不是我們所考慮的。也沒有很專業(yè)的去分析設計對象。但確實是人以群分物以類聚，實現(xiàn)出來的東西，等我們真正理解懂了OO的理論，回頭看我們的代碼，居然還真的很符合OO理論。讓我感嘆現(xiàn)在很多入道不幾年的程序員，為了OO而OO，為了實踐OO理論而強制自己寫OO代碼，最后是OO的表面形式，而思路卻是大流水，連函數(shù)流程都閱讀不出來，思路分叉判斷很多。建議先踏實把面向函數(shù)用起來，再自然過渡到面向?qū)ο蟆?/div>
面向?qū)ο笠灿薪鉀Q不了的問題。那就是沒有事件和屬性。于是面向組件產(chǎn)生。但是大家仔細分析源代碼，屬性和事件，都是通過面向?qū)ο蟮姆椒ㄗ龅降摹Ｈ缫粋€屬性，往往是Getxxx和Setxxx構(gòu)成，一個事件是一個特殊形式的屬性而已。
事情都是承接的，自然而然過渡的，就和面向大流水到了面向過程，然后是面向?qū)ο螅缓笫敲嫦蚪M件。 面向組件，我們又遇到了問題。而這些問題，都是由于我們順其自然理解習慣而引起的。 很多人分析完業(yè)務，不管你是用UML還是什么組織結(jié)構(gòu)-流程-考核的方法，你在軟件設計的時候，總是要有個艱難的映射。就是把現(xiàn)實要映射成類，要影射成組件。而這個映射是如此的不符合順其自然的思考習慣。你需要變換一種思路，而這分析和設計兩種思路，老是擰不在一起。 我們不想繼續(xù)擰巴了。我們就想很直白的說：我要完成這個事情。我現(xiàn)在有這么多信息，我輸入進去，你就給我產(chǎn)出我需要的計算結(jié)果。OK，就這么簡單。我不想再映射什么類，什么組件了。 這就是很自然的人類思考習慣。我們業(yè)界老前輩老專家兜兜轉(zhuǎn)轉(zhuǎn)，研究發(fā)表了N多理論和方法，但最終仍然科學理性擰不過人類順其自然的分析習慣。又回來了。但這個回歸已經(jīng)升華了，我們在簡單的接口之下再也不會有大流水的實現(xiàn)了。在我們的服務接口之下，我們自由的應用我們擅長的開發(fā)實現(xiàn)方法。我們再也不用和客戶講類映射，客戶再也不用和我們講業(yè)務流程了。我們統(tǒng)一了，我們就想這么做：我要完成這個事情。我現(xiàn)在有這么多信息，我輸入進去，你就給我產(chǎn)出我需要的計算結(jié)果。OK，就這么簡單。 讓客戶學會UML，不可能。過去讓我們和客戶，想拿RUP過程管理方法和UML事務描述方法來統(tǒng)一，只是個理論理想。 SOA，不是面向組件升級到面向服務這么簡單。是我們的軟件分析方法、軟件設計方法、軟件開發(fā)方法的變革。是業(yè)界對過去這些理論和產(chǎn)品的反思。業(yè)界對世界的抽象方法變了。 SOA需要將應用程序的不同功能單元(稱為服務)通過這些服務之間定義良好的接口和契約聯(lián)系起來。但怎么聯(lián)系起來。高內(nèi)聚，低耦合是我們一貫的原則。像過去我們互相開放DLL的方式根本不合適，都是硬編碼進自己的系統(tǒng)中。一旦接口改變，都需要修改。幸好，業(yè)界發(fā)現(xiàn)了有個工作流的東西，聽說可以驅(qū)動業(yè)務流程。于是，滿心歡喜的奔了過去。 真正一用才發(fā)現(xiàn)不對。工作流的規(guī)范世界早已固定。工作流產(chǎn)生的時候，還沒有SOA呢。SOA需要的業(yè)務流程連接，工作流的原理類似，但并不是最適合軟件服務的連接。于是，業(yè)界又集體聯(lián)合起來研發(fā)了BPEL，業(yè)務流程處理語言。但有些工作流廠商也唯恐被稱為落后時代腳步，于是強嘴說自己已經(jīng)是SOA了。于是，業(yè)界李鬼李逵一堆。各有各的利益，各唱各的調(diào)。 SOA這種世界觀也需要落地到一個可實現(xiàn)的框架。于是SCA和SDO出現(xiàn)。SCA是SOA的落地架構(gòu)框架規(guī)范，SDO是數(shù)據(jù)結(jié)構(gòu)規(guī)范和數(shù)據(jù)存取原理規(guī)范。而這些規(guī)范，用現(xiàn)有的開發(fā)語言和技術(shù)框架都可以實現(xiàn)。所以，對于現(xiàn)有系統(tǒng)，無須認為現(xiàn)有的系統(tǒng)落后了，不符合SOA了，需要重新上一套SOA軟件了。 但是，我粗略閱讀SCA規(guī)范，特別類似于我過去熟悉的組件模型體系。只不過SCA在組件模型基礎(chǔ)上又提供了服務定義和服務Wire。組件模型是提供了個體的規(guī)范，而SCA不僅提供了個體，更提供了個體之間連接的規(guī)范。組件模型讓我熟悉了接口與實現(xiàn)的分離，讓我熟悉了容器運行保護，讓我熟悉了元數(shù)據(jù)管理。沒有經(jīng)過面向組件時代的人，不會感受到SOA到來的必要性。 我們曾經(jīng)用組件模型開發(fā)應用軟件，其目的就是想像這些組件都是獨立的個體，然后我們用一種腳本把這些組件穿在一起(過去我想到是VBA腳本，然后是Javascript腳本，然后是ASP腳本，然后又關(guān)注了工作流，均不滿意，最后才落眼到BEPL)。而如今，SCA、SDO、BEPL、ESB給我們多年的設想提供了可落實的體系模型。我們需要這樣靈活組合的應用軟件，我們不需要一個上千個參數(shù)配置的航母軟件(如SAP R/3)。 只有了解了SOA、BPEL、ESB的前生后世，我們才能平和的看待這些技術(shù)，看待和這些技術(shù)相關(guān)的技術(shù)，我們才能有的放矢的去學習它、利用它，為我們更快速的適應客戶需求變化而有益。 最后一句話： 對于我個人從業(yè)經(jīng)驗，我經(jīng)歷過面向過程、面向?qū)ο蠛兔嫦蚪M件三個架構(gòu)思想的產(chǎn)品開發(fā)歷史，我們一直試圖解決軟件組件粒度靈活組合的問題，我學習技術(shù)也一直是抱著解決問題而研究，而不是怕趕不上潮流而學習。我個人片面的認為SOA的架構(gòu)思想就是我們過去應用的面向組件思想的延伸，然后再套上WebService的外殼，我們過去開發(fā)COM+，為了跨防火墻為了異構(gòu)連接CORBA可費死了勁。SOA還結(jié)合了業(yè)務靈活的BPEL思想，整合了中間件消息總線WebService治理的技術(shù)思路。SOA整合了這么多架構(gòu)思想和企業(yè)產(chǎn)品技術(shù)，根本目標就是使我們的IT更加靈活。我們過去做面向組件也是為了這個根本目標。SOA就是通過面向業(yè)務的分析方法+WebService中立技術(shù)+BPEL腳本業(yè)務編排+ESB服務治理總線中間件來達到IT靈活的。 SOA是面向服務，OO是面向?qū)ο?。就這么簡單，一個問題領(lǐng)域。SOA不是EAI，不是系統(tǒng)集成的一種方式。那是業(yè)界某些公司為了達到自己的利益目的做的宣傳，混淆大家的視聽。怎么學習面向的時候，沒有人提這些系統(tǒng)集成。到了面向服務，就牽扯到系統(tǒng)集成了?被人忽悠了?過去我做企業(yè)集成，用的是讀取數(shù)據(jù)庫，然后是DLL，然后是WEBSERVICE，但沒有使用SOA。 過去業(yè)務設計使用的是一種思路，軟件設計使用的是另一種思路，老對接不上去，SOA統(tǒng)一了。都必須從業(yè)務角度看問題，而不能一方是流程，一方卻是類圖和時序圖。 給大家舉一個例子。 有一個業(yè)務，是用戶在網(wǎng)站上選擇自己想買的車型，然后點一下計算，就顯示自己購這臺車的總費用。 那這個功能就是一個軟件服務。SAAS，軟件即服務。 業(yè)務設計員設計好這個業(yè)務。功能設計員就定義了一個軟件服務接口，可能叫CalcTotalFee(CarType:XML)。 用戶輸入的數(shù)據(jù)，被程序員程序處理成SDO傳入，調(diào)用服務接口，返回總費用。但接口里面是怎么計算的，用了哪些OO技術(shù)或組件技術(shù)，或干脆就是大流水帳代碼，那是你程序員自己的事情。而業(yè)務設計員和功能設計員是統(tǒng)一認識的。 這就是業(yè)務設計、功能設計、功能開發(fā)三者的關(guān)系。 有了SCA和SDO，SOA概念踏實多了，否則和過去的面向組件和現(xiàn)在微軟鼓吹的webservice式的SOA很容易迷惑。
小結(jié)：
SCA是SOA的落地規(guī)范，否則SOA就是個概念。 BPEL是為了編排連接各個服務的，BPEL不是為了工作流審核審批的。根本就是兩個目的兩碼事，不要混淆。用BPEL實現(xiàn)工作流，或者用工作流想實現(xiàn)BPEL，都是錯誤思路。 ESB是運行服務，并且驅(qū)動BPEL的。 SDO是為了規(guī)范接口間的傳輸數(shù)據(jù)的格式和數(shù)據(jù)操作的規(guī).否則，你傳輸?shù)腦ML就自己瞎編格式了 SCA和SDO是OSOA組織制定的 但微軟也鼓吹自己的SOA，但沒有具體理論(微軟一向不愛宣稱自己的理論，雖然微軟做了很多專利和論文)，微軟有具體的WCF和微軟的webservice實現(xiàn)模型作為SCA的對照，也有也有LINQ和ADO.NET作為SDO的對照。 因為微軟的SOA服務組件，不遵守SCA/SDO規(guī)范，所以在微軟的體系里很自在，和IBM陣營整合，就有些困難。因為大家往往用Visual studio工具開發(fā)webservice，而自動生成的這個框架，并不符合SCA/SDO標準。 如果你非要讓我用什么誰加誰等于誰來說明SOA。我只能暴力的用SOA=WebService+SCA+SDO+BEPL+ESB來表達。如果你覺得SCA+SDO只是IBM、SUN、BEA之類制定的標準而不是業(yè)界SOA的標準，如果你覺得BEPL屬于業(yè)務流程整編的范疇不是SOA模型的范疇，你可以執(zhí)著的人為SOA=WebService。這種認識就類似于把WINDOWS、OFFICE、Visual Studio、SQLSERVER都從微軟去掉一樣。那樣的微軟仍然是微軟公司。但那真的還是微軟嗎?就如同人是一個完整的概念，你非要把人=頭+手+腳+...就等于人，這樣粗暴而簡單的定義和認識，顯然是不對的。 |
|
|
