是過去需要、現在需要，還是將來需要？
現在，電子政務需要SOA已毋庸置疑，但隨之而來的問題就是，電子政務是什么時候需要SOA？是過去、現在還是將來？其實，人們在考慮這個問題的時候，往往會想到我過去已經建了哪些系統，現在還需要建設哪些系統，哪些系統需要整合，至于將來，有個規劃就可以了。實際上這是走入了一個誤區，即將建設與整合孤立看待。這一誤區的主要表征就是以孤立的、靜態的、割裂的，而不是發展的眼光看待電子政務的應用建設和應用整合，將業務需求和業務發展割裂開來，以致建設出來的電子政務系統需要整合，整合的電子政務應用仍是按靜態需求建設起來，如果需要則再次整合。
而走出此誤區的方法就是將建設和整合有機統一起來。要樹立沒有從頭建起的系統的觀念，要從設計上就能夠充分意識到系統總是在整合一切可以利用的資源(內部的、外部的)的基礎上發展起來的，是為了滿足新的業務變化需求。新系統就是舊系統的利用整合，同時它又是將來能夠被新業務整合的資源。這正是SOA倡導的設計理念。因此可以這么說，電子政務是時時刻刻都需要SOA的，過去需要，現在需要，將來也需要。尤其以服務為中心和導向的電子政務建設需要SOA，在它的指導下，我們才能夠避免走進誤區。
實際上，面向服務的架構已經存在很多年了！因為面向服務是一種設計理念和基于一系列設計原則的，而這些都是與技術無關的。在過去，可用于實現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的方法論就是電子政務的領域構件庫，它們在業務模型的支持下呈現出層次結構，構件粒度可大可小，大構件是小構件的組合，上層構件是對下層構件的抽象，在一定的層次上，構件表現出一定功能的服務特征。
SOA的架構平臺就是一個標準的構件容器，它負責解釋、運行、監控實例化的構件。這個構件容器是能夠跨技術平臺的，允許不同服務之間交互數據、參與協同流程，無論它們各自背后使用的是何種操系統或采用了何種編程語言。
SOA的裝配線就是構件的圖形化集成環境(IDE)�？梢栽谶@里創建構件、復用構件、嵌套構件、組裝構件，可以在這里通過構件的組裝生成一個個服務。而服務因為具有了內部的構件化特征，使得服務成為一個柔性的結構，而一個柔性結構在適應變化方面要遠遠優于一個鋼性結構的服務，從而延長了這個服務的生命周期。所以說，SOA可從面向構件開始。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
