是過去需要、現在需要，還是將來需要？以及電子政務的SOA如何開始等問題，以闡述“從SOA開始，從面向構件的SOA開始，是電子政務保持可持續發展的最佳實踐”這一論斷。

        電子政務需要SOA嗎？

        我國的電子政務建設格局像一個縱橫交錯的大棋盤，在剛剛過去的“九五”和“十五”期間，我國各級政府部門紛紛規劃和建設起各自的電子政務系統工程，在很多方面都取得了顯著的階段性成果?？v向電子政務建設以“金稅”、“金關”等工程的成功實施為代表，目的就是利用信息化的手段，達成自上而下的業務標準和業務資源的統一，實現數據自底向上的快速準確匯集和業務自上而下的高度協同。從某種程度上講，能夠自上而下的推進涵蓋“部、省、市、縣、鄉”等五個層次的縱向綜合業務系統，本身就是SOA的一種體現，只不過此時SOA的設計僅僅是面向內部的、面向具體業務功能的，因此也是局部的SOA。

        局部SOA的后果就是，局部的統一不能帶來全局的統一，如果跳出局部看整體，在更寬廣的范圍內來看，比如站在國家電子政務全局來看，或站在公眾的角度去看，滿眼盡是一個個劃地而治的信息孤島，需要為整體去做集成。而這恰恰成為了橫向電子政務所需面臨和解決的信息共享和資源整合的挑戰。

        橫向電子政務正在逐步實現由“政績導向”向“服務導向”的轉變。以服務為中心，使老百姓能得到更廣泛、更便捷的政府信息和服務，使政府真正轉變為服務型政府，黨和政府為此都做出了重要決定。黨的十六屆四中全會做出了加強執政能力建設的重要決定，提出轉變政府職能，創新政府管理模式，是提高政府執政水平的重要措施。溫家寶總理在主持召開國家信息化領導小組第三次會議上提出要從全面和戰略的高度加快推進信息化建設，抓緊推進電子政務，提高政府的經濟調節、市場監管、社會管理和公共服務能力，促進政務公開。

        因此，以公眾服務為中心，服務公眾就成為電子政務建設的出發點和落腳點。過去的經驗是功能性的、局部的，現在要求以公眾服務的角度去看電子政務全局，電子政務建設必須 [page]

        面對以下幾個挑戰：

        1、如何做好電子政務的頂層設計？尤其是在跨部門電子政務項目中，如何加強牽頭單位、協作單位、信息主管、決策領導之間的聯系？

        2、如何克服以部門為中心的思維方式，設計出既滿足局部功能，又符合發展要求（如快速適應變化），同時又能參與全局協同的服務？

        3、如何有效評價服務的質量和更好的理解各部門的互相關系？

        4、如何把以單個部門為核心的不兼容的信息系統升級為以服務為中心的、可集成的統一的服務或服務組合？

        這些挑戰正是使電子政務能夠持續發展的前提。以服務為中心，使老百姓能得到更廣泛、更便捷的政府信息和服務；以服務為中心，梳理和重組業務流程，使各個業務系統能夠互聯互通和資源共享，有效降低實施和運行成本；以服務為中心，加強評價和績效體系，提高監管能力和公共服務水平。因此，電子政務的發展需要以服務為中心的設計和方法指導，需要給出服務的業務模型和服務的評價模型，業務模型描述服務業務的可持續發展，不僅包括它的創建態，還可以包括其變化態和協作態，評價模型描述服務的評估態。這就是SOA提倡的方法論，這就充分說明了電子政務和電子政務的可持續發展需要SOA。

        是過去需要、現在需要，還是將來需要？

        現在，電子政務需要SOA已毋庸置疑，但隨之而來的問題就是，電子政務是什么時候需要SOA？是過去、現在還是將來？其實，人們在考慮這個問題的時候，往往會想到我過去已經建了哪些系統，現在還需要建設哪些系統，哪些系統需要整合，至于將來，有個規劃就可以了。實際上這是走入了一個誤區，即將建設與整合孤立看待。這一誤區的主要表征就是以孤立的、靜態的、割裂的，而不是發展的眼光看待電子政務的應用建設和應用整合，將業務需求和業務發展割裂開來，以致建設出來的電子政務系統需要整合，整合的電子政務應用仍是按靜態需求建設起來，如果需要則再次整合。

        而走出此誤區的方法就是將建設和整合有機統一起來。要樹立沒有從頭建起的系統的觀念，要從設計上就能夠充分意識到系統總是在整合一切可以利用的資源（內部的、外部的）的基礎上發展起來的，是為了滿足新的業務變化需求。新系統就是舊系統的利用整合，同時它又是將來能夠被新業務整合的資源。這正是SOA倡導的設計理念。因此可以這么說，電子政務是時時刻刻都需要SOA的，過去需要，現在需要，將來也需要。尤其以服務為中心和導向的電子政務建設需要SOA，在它的指導下，我們才能夠避免走進誤區。[page]

        實際上，面向服務的架構已經存在很多年了！因為面向服務是一種設計理念和基于一系列設計原則的，而這些都是與技術無關的。在過去，可用于實現SOA的技術是多種多樣的，它們包括CORBA、J2EE、COM/DCOM、MQ、ebXML、EAI、ESB等。在這些技術中，有的適于構建SOA，有的則不然。比如，EAI與SOA同樣解決企業集成的問題，但SOA解決的問題遠比EAI解決的IT問題多得多，產生的影響要深遠得多。EAI解決集成的問題往往是在事后，碰到了集成問題，才去想辦法通過 EAI來解決，這正是走進了我們前面所說的誤區。與之相反，SOA架構解決集成的問題是事先的，也就是說，在一開始搭建SOA這一IT架構的時候，就已經考慮了集成的問題。這是SOA區別于EAI的一個重大不同，也是SOA能夠幫助我們走出“割裂建設和整合”誤區的佐證。

        電子政務的SOA如何開始？

        前面我們已經論證了電子政務要可持續發展，就需要SOA?，F在的問題是，在電子政務的建設過程中，如何才能發揮SOA的最大功效？SOA該如何做起？面對我們所涉及到的眾多重要概念，如面向服務、頂層設計、業務模型、流程重組、服務構件等，我們該如何入手呢？

        首先，要把SOA看成方法論，要根據電子政務的業務需要，通盤考慮所需要的業務模型和數據模型。每一條業務線和數據線都要從服務的特征、管理的特征和適應變化的特征去審視，并且每次審視都要圍繞上下左右中等多重視角，還要加上一個時間維度?？赡苄枰⑿碌拿嫦蚍赵u價模型，要打破單個業務使用獨立IT系統的模式，特別是那些可以重復使用的服務，必須要求服從一個統一的SOA架構，開發出有層次的、可重用的體系。其次，要把SOA看成架構平臺，或者說要根據業務模型建立支撐重用軟件的運行和管理平臺。在可重用的層次模型支持下，平臺要做到技術無關性，就要以統一的標準去運行和管理重用軟件。

        再次，要把SOA看作是軟件工廠里的產品裝配線。它是一筆對將來業務運營的投入，所以在這筆投入發揮效益之前，需要做相關的計劃、設計和開發工作。正如生產線上制造的第一輛車的花費要比第一千輛高出很多一樣，用SOA部署的第一個服務所需的花費要比部署第一百個多出很多。SOA的主要優勢是逐漸體現出來的，不能一蹴而就。最后，必須投入足夠的精力和人員進行技術和業務流程的培訓，才能確保所開發的服務是可重用的。任何服務的開發，不能只顧及眼前利益，也要考慮長期利益（或許是更重要的）。換句話說，各個服務的單獨存在并無太大價值，除非這些服務能與其他服務一起被使用，并能根據業務的變化，快速組合成各種新的應用。 如何使上面所述的SOA方法落地呢？讓我們從面向構件去說明電子政務的SOA應該如何開始。

        SOA的方法論就是電子政務的領域構件庫，它們在業務模型的支持下呈現出層次結構，構件粒度可大可小，大構件是小構件的組合，上層構件是對下層構件的抽象，在一定的層次上，構件表現出一定功能的服務特征。[page]

        SOA的架構平臺就是一個標準的構件容器，它負責解釋、運行、監控實例化的構件。這個構件容器是能夠跨技術平臺的，允許不同服務之間交互數據、參與協同流程，無論它們各自背后使用的是何種操系統或采用了何種編程語言。

        SOA的裝配線就是構件的圖形化集成環境(IDE)。可以在這里創建構件、復用構件、嵌套構件、組裝構件，可以在這里通過構件的組裝生成一個個服務。而服務因為具有了內部的構件化特征，使得服務成為一個柔性的結構，而一個柔性結構在適應變化方面要遠遠優于一個鋼性結構的服務，從而延長了這個服務的生命周期。所以說，SOA可從面向構件開始。

        SOA從面向構件開始

        從面向構件開始，電子政務的SOA就建立在了可被管理的業務單元基礎之上，而不是建立在不可被管理的代碼之上，構件成為業務的技術無關性基本單元；

        從面向構件開始，電子政務的SOA可以從一個局部做起，以漸進的方式向SOA架構演進，因為構件的標準統一使得這個局部不會給全局帶來新的集成問題，這樣可以最大程度地規避

        項目風險，降低初期投入

        從面向構件開始，電子政務建設將最終達成我們夢寐以求的標準統一，架構統一，建設統一，管理統一；

        從面向構件開始，電子政務將實現一個同構的世界。

        因此說，從SOA開始，SOA從面向構件開始，是可持續發展電子政務的最佳實踐。