用這樣的題目有點嘩眾取寵的意味,不過相對于SOA(Service-Oriented Architecture)這個所謂“下一代軟件架構”,任何的修飾都顯得暗淡無光。早在1996年,Gartner Group就已經提出了SOA的預言,不過那個時候僅僅是一個“預言”,當時的軟件發展水平和信息化程度還不足以支撐這樣的概念走進實質性應用階段。
2002年12月,Gartner又提出了SOA是“現代應用開發領域最重要的課題”,并且預言到2008年, 75%的新的企業應用將使用SOA 的元素,從2003年的20%產生急劇的增長;到2006年,在全球銷售出的所有商業應用產品中,面向服務的將超過 80%;到2005年,試圖建立實時企業能力的企業中,80%將會嚴重的低估網絡的需求,他們將不得不做出最后的增加、升級或者修改,從而能夠開展實時企業應用和能力。2008年,SOA將成為占有絕對優勢的軟件工程實踐方法,主流企業現在就應該在理解和應用SOA開發技能方面進行投資,更好地支持商業流程。
于是此刻,這個“老調重彈”的概念一夜之間成為各大廠商的新寵。
縱觀軟件發展史,我們經歷了面向過程->面向對象->面向組件->面向集成的幾個時代:
面向過程:高度耦合、高效率,通常是針對一個具體的應用實現,因此無法適應快速業務變化,不適合做大型面向客戶應用的開發。
面向對象:OOP提供了封裝、繼承、多態和重載等等一系列的特性使應用軟件的架構可以被重用,開發人員可以不用關心其具體實現,而是專注于對象能夠提供怎樣的功能,因此提高了軟件重用性,從而使得整個IT的基礎架構能夠適應需求的快速變化。語言的單一性和源代碼級的共享決定了在跨應用系統重用的過程中必定會有各種各樣的困難。
面向組件:二進制級別的組件共享進一步加速了面向應用實現的步伐,繼承了OO的顯著的優點,使得IT基礎架構能夠更加快速適應業務變化,但是平臺單一性依然阻礙了其復用程度。
面向集成:這是一個完全面向業務的時代,所有的應用都是以業務應用為主題去組織的,但是集成高昂的成本讓許多企業望而卻步。
SOA正是在這樣的大背景之下應運而生的,在OOP相對成熟之后,軟件學術界出現了諸多的方法學用來解釋開發過程遇到的種種問題,比如AOP(面向方面編程)、MDA模型驅動架構),契約式設計及其極限編程(XP)等等,于是有人提出了“后OO時代已經到來”的論調,SOA正是這個新時代最重要的軟件方法論。簡單地說,SOA是“抽象、松散耦合和粗粒度”的軟件架構,它可以根據需求通過網絡對松散耦合的粗粒度應用組件進行分布式部署、組合和使用。服務層是SOA的基礎,可以直接被應用調用,從而有效控制系統中與軟件代理交互的人為依賴性。
那么我們再來看看各大廠商是怎樣宣傳和鼓吹他們對于SOA的支持?
IBM: 宣稱是第一個為構建、部署基于SOA的IT系統提供一系列全面的工具、培訓和服務線路的大型廠商,它涵蓋了SOA生命周期的所有方面,整個概念覆蓋了他們提供的五大產品線Websphere、Workplace、Tivoli、DB2及其Rational。
BEA:宣稱其旗艦產品WebLogic Platform 8.1是業界內最佳的SOA實現平臺,從WebLogic Server到WebLogic Portal再到WebLogic Integration,BEA的全線產品都是采用SOA的理念去設計的,而Workshop 8.1則是第一個完整的ISE(Integrated Services Environment,面向服務集成環境),它覆蓋了從設計、開發、測試再到部署的各個環節,并且宣稱通過其能夠快速為企業建立基于服務的應用。
Oracle: 宣稱其JDeveloper 10g是一種基于Java與Web服務環境的開發工具,具有網絡激活功能,并能夠支持SOA(面向服務的體系結構),并且提出在SOA工具方面,領先于IBM和Sun這樣的公司,通過其數據庫產品Oracle 10g和OAS(Oracle Application Server)的支持,同時加上APF(Application Platform Foundation)的支持,因此在SOA的支持方面,Oracle將領先于其他廠商。
Microsoft:雖然SOA的概念不是源自這家廠商,不過在后期推廣中卻占據了非常重要的位置,Biztalk Server 2004的推出,也終于讓這個軟件巨人理直氣壯的開始關于SOA的宣傳,相對于其他廠商而言,更加“明智”的選擇了從開發人員入手,引導開發人員進入SOA,從MBF(Microsoft Business Framework)來看,就是提供給開發人員的參考架構。
從目前的市場對峙來看,企業應用開發可以分解為三大陣營:
以IBM、BEA、Oracle、Sun為首的Java應用牢牢占據企業高端應用,除了具備跨平臺的特點之外,更加重要的是他們在Java標準之上形成了非常成熟的產品線,從開發工具到應用服務器再到企業應用實現,自始至終都有一套完善的解決方案,在這個世界里面他們成為領導者,他們著眼于中高端市場。
以微軟為首的基于Windows平臺的應用解決方案提供商,他們完全依賴于Windows體系架構所提供的功能,主要的開發工具早期為Visual Stuido 6.0和Borland的Delphi,現在逐漸遷移到.NET為主,在中低端市場,他們以開發效率和易用性見長,并且有逐步走向高端應用的趨勢。
以Perl、PHP、Python等等開源為主的應用則著眼于中低端市場,他們則以價格方面的優勢見長,并且有比較扎實的社區支持,關鍵的問題在于沒有強勢廠商的支持,因此更加適合做一些相對獨立的應用解決方案。
從某種意義上來說,SOA是“自頂向下”而產生的,正是因為企業應用復雜度的增強造成了目前很多應用無法完全是用不斷發展的業務需求,于是“整合(Integration)”就成為企業望而生畏卻不得不面對的問題,SOA在應對這樣的問題時則顯得理直氣壯,“面向服務、無需整合、標準化、松散耦合”等等一系列與生俱來的優勢讓睿智的廠商意識到這個新概念是刺激IT采購的最好入點,于是群擁而上造就了今日SOA的榮光無限。
一切不是如此完美,如果完美了就沒有我今天的文字,也沒有了那么多的牢騷,相信很多人都在問SOA是否等同于Web Services,從最初的定義到廠商的宣傳都在傳達一個主題:SOA!=Web Services,Web Services只是SOA的一種技術實現方式,并不足以構成SOA的全部,通過JMS、JDBC、.NET Remoting、IIOP乃至CORBA和TCP/IP都可以成為SOA的技術實現架構,而且也有廠商在私有協議上實現了SOA的模型,比如IBM WebSphere產品線,比如WebLogic Workshop,比如微軟的.NET 2.0類庫等等。
作為SOA的Java世界的SOA推動者他們認為SOA不等同于Web Services,因為他們可以理直氣壯地宣稱SOA的實現過程中可以使用IIOP、JMS、CORBA等等協議,在Java平臺上,這些協議能夠工作的比Web Services來的有效率,在Java世界里面實現大統一的軟件架構似乎已經近在咫尺,那么我們也有理由選擇SOA。
雖然到目前為止微軟還不足以成為這個概念的絕對領導者,但是有一點可以肯定,忽略微軟的團圓是不夠完美甚至是悲哀的,雖然可以不在乎,但是忽略如此之多的微軟開發人員去論述新一代的軟件架構似乎還是底氣不足。微軟選擇了圓滑的方式去推進SOA,雖然他的產品他的軟件架構不是最出色的,但是有一點無可置疑,在易用性方面讓其他廠商望塵莫及。微軟也知道SOA不是Web Services,但是同樣的也知道只有Web Services才能夠真正幫助其去實現SOA的夢想,于是就有意的淡化其中的區別,最終的結局就是大部分的微軟開發人員以為SOA就是Web Services,而VS.NET目前是開發Web Services的最佳工具,雖然一切不是那么令人滿意,不是讓微軟滿意,更加讓Java世界不滿意,但是有一點我們不要忘記了:微軟開發人員占據著開發人員的半壁江山。
從個人的角度而言,我贊同SOA是新一代的軟件架構,是“后OO時代”最耀眼的軟件方法論,但是理論歸理論,是不是能夠解決當前企業應用存在的種種問題?一切需要我們拭目以待。無意去否定或者攻擊廠商的做法,畢竟通過概念來刺激IT采購是他們的最終目的,我們對于我們開發人員或者企業而言呢,SOA是不是靈丹妙藥呢?
還是需要回到SOA!=Web Services的話題上來,雖然彰顯無聊的本質,但是在沒有探討出SOA等于什么或者完整包含什么之前,我們無法不去繼續這個百無聊賴的主題,既然SOA強調能夠跨越異構平臺整合業務,那么必然需要特定的技術手段去實現,就目前三大陣營的發展來看,Web Services似乎是唯一可以跨越異種開發平臺的標準,而就如SOA提倡因為標準化所以卷土重來,那么標準的起點在于何處?我們誰都明白只有Web Services能夠讓這個論調自圓其說。
那么今天的Web Services又如何呢?在跨越企業應用方面,的確逐漸成為主流的協議,但是在企業內部,在對于響應速度要求比較高的領域,我們都知道目前的Web Services依然難當大任,畢竟SOAP的序列化和反序列化在很多實際應用中會成為可怕的性能瓶頸。因此Web Services目前的應用中還是以集成為主,在實時應用中,還無法成為自己的舞臺。
SOA到底是一個怎樣的東西,它和Web Services是一個怎樣的關系,是軟件學的新衣裳還是廠商美麗的謊言,我們將拭目以待。
煤炭網版權與免責聲明:
凡本網注明"來源:煤炭網zxbline.com "的所有文字、圖片和音視頻稿件,版權均為"煤炭網zxbline.com "獨家所有,任何媒體、網站或個人在轉載使用時必須注明"來源:煤炭網zxbline.com ",違反者本網將依法追究責任。
本網轉載并注明其他來源的稿件,是本著為讀者傳遞更多信息的目的,并不意味著本網贊同其觀點或證實其內容的真實性。其他媒體、網站或個人從本網轉載使用時,必須保留本網注明的稿件來源,禁止擅自篡改稿件來源,并自負版權等法律責任。違反者本網也將依法追究責任。 如本網轉載稿件涉及版權等問題,請作者在兩周內盡快來電或來函聯系。
網站技術運營:北京真石數字科技股份有限公司、喀什中煤遠大供應鏈管理有限公司、喀什煤網數字科技有限公司
總部地址:北京市豐臺區總部基地航豐路中航榮豐1層
京ICP備18023690號-1 京公網安備 11010602010109號