.NET vs J2EE——面對SOA的荒謬與誤解

來源:互聯網
上載者:User

·.Net與J2EE在金融行業愈來愈呈勢均力敵之勢,二者均宣稱提供了不同於對方的、聽起來很迷人的個人化應用服務。

·理性的IT執行官們已經深刻的認識到這樣的一個事實:無論是.Net還是J2EE,將來必將在SOA理念的應用中佔有各自的一席之地。

·Microsoft的.Net技術在今天的金融市場面前,顯得商機無限。

·從前,荒誕與誤解依然在.Net與J2EE平台之間縈繞著:似乎沒有一個IT決策者能夠看透了這層迷霧,繼而在兩個平台之間做出理性的決擇。

·今天,技術執行官們已經能夠很好的把握需求動機,進而在這兩種平台架構上做出正確的選擇。

涉及主題

SOA(Service-Oriented Architecture,面向服務的架構)已經在全球業界日益成為核心的技術議題,那麼實現SOA的技術標準問題則成為了嚴格關注的核心問題。在這個領域中,所有的IT經理們將不得不面對一個古老的問題:J2EE和.Net,我們選擇誰?

我並不願意試圖去回答“Yes or No”,在特定企業的特定應用環境下的選擇,也不在討論範圍之內;但是本文的確廣泛搜集了當今金融領域內IT專家們的普遍性思維以及他們選擇技術架構的方法論。IT經理和軟體供應商將能從本文關於技術架構的討論中發現一些令人詫異的結論,並且瞭解金融IT專家們在這場關於J2EE和.Net技術架構爭議中的思維方法。因此,自從J2EE和.Net誕生以來,那些瀰漫在你腦海中關於這兩個平台的“荒謬論點和神話故事”很可能從此銷聲匿跡。

背景

上個世紀90年代,物件導向的編程(OOP)引發了諸多的軟體開發標準。首當其衝的是Microsoft的元件物件模型(COM),這是一個模組(組件)化的技術開發架構,它源自於微軟早期的對象連結與嵌入技術(OLE)。稍微資深一點的技術人員應該知道,今天互連網應用中最常見的ActiveX技術就是構建在COM架構之上。

2002年微軟全面的用.Net從邏輯層上置換了COM,作為新的軟體開發架構(COM仍然被支援)。.Net技術的全面推進,統一了微軟的不同技術理念和平台。作為一個戰略品牌,.Net為Web Service提供了原生的解決方案,並且成為提升不同應用和系統之間互通性的標準。

在1993年微軟引入COM之後,Sun公司於1995年推出了Java平台。Java平台由一套應用開發語言(Java)、API和Java虛擬機器(JVM)構成,JVM允許用Java編寫的程式運行在不同的作業系統上。事實上,Sun引入Java的初衷是使得程式員能夠開發可移植的應用程式,而不關心硬體和作業系統。在1999年末,Sun提出了Java平台企業版(J2EE---Java to Enterprise Edition),該規範被應用在主要的IT供應商以構建穩健的應用系統架構,如IBM、Oracle和BEA,等等。

2003年Sun公司發布了J2EE 1.4版,除了增強更加穩固的企業級應用之外,還增加了Web Services支援。Sun把這個最為流行的版本稱為Java EE。

由於.Net和J2EE各自的初衷,使得二者之間的競爭常常摻雜著一些莫名其妙的荒誕。但是最近IT專家及IT決策者們關於這個問題的爭論卻更加註重於從業務實踐的客觀角度考察二者技術上的優劣,因為這將有助於他們的正確選擇。

一些資料

幾乎每一個IT技術經理都聽說過“.Net應用的延展性匱乏或者J2EE架構不易開發”的故事,的確,對這兩個平台認知上的誤解在業界普遍存在。

就在最近的兩年以前,許多的IT經理們常常帶著個人偏見對其中某個平台情有獨鐘,而刻意的排斥另一平台。他們僅僅因為一個毫無依據的個人預想而拒絕部署某個平台,或者其依據甚至是來源於雜誌上的某篇技術文章。這種情況非常的普遍,因此圍繞著.Net和J2EE誰優誰劣的討論相當多。

我們承認.Net平台的延展性會因為其特殊的基於Intel的硬體平台而受到約束,但是我們也不應該忽視.Net平台誕生的那一天起,就有著比J2EE平台更強的互通性,並且允許開發人員利用現有的.Net組件構建更加複雜的解決方案,而不用花費太多的成本。

J2EE得到了大部分供應商的支援,包括Sun,IBM等,所以J2EE的最大靈活性和可移植性不用置疑。另一方面,.Net平台被微軟獨家全面支援,因此有著更為一致性的行為方式和可預見性。

令人遺憾的是,兩種技術平台的第一手測試資料的匱乏總是使得人們的主觀臆想常常淩駕於技術本身的發展之上。 對.Net和J2EE認識的模糊也導致了IT執行官們在關鍵時刻的優柔寡斷,甚至又回到了本世紀最初幾年的狀態,那個時候的平台分布如下所示。

Net 22%

J2EE 26%

不確定 15%

都沒有 30%

都有 7%

全球.NET and J2EE技術的跨行業調查(2002)

資料來源:Merrill Lynch & Co.

上表為2002年Merrill Lynch對全球100個CIO關於Web Service在兩種平台的應用分布資料。對100個CIO的問卷調查顯示出他們的公司缺乏清晰的Web Service應用戰略。

下表顯示了2002年.Net和J2EE平台在美國最大的100家銀行的應用分布。

Net 15%

J2EE 36%

不確定 24%

都沒有 5%

都有 20%

上表為美國最大的100家銀行2002年的平台分布

資料來源:全球金融諮詢及顧問公司TowerGroup的評估報告

幾年之後的今天,IT經理們的決策漸漸層得更加理性,他們開始更多的基於業務需求和技術因素做出選擇。我們終於發現,在同一家銀行常常同時存在著.Net和J2EE兩種技術架構,更為重要的是,Web services已經成為這兩種平台整合的共同橋樑。

回到本來

哪個平台更加適合新的應用?或者我們應該升級到那個平台?必須做出決定。在過去的6年中,.Net和J2EE平台在全球範圍裡都未能保持著對對方的絕對優勢,他們各自有著自己的特色。

2006年,全球著名的金融顧問諮詢公司TowerGroup在與金融行業CIO和IT架構師們的一次研討中,發現他們對於這兩個平台的選擇有著更為清晰的目標和期望值,這的確是一個消除誤解的好機會。

這次討論中至少有兩點值得我們注意:企業似乎並沒有固有的傾向性;也沒有明確的跡象表明那一個平台更加具有延展性和可靠性。

(1)對於.Net和J2EE並沒有特別的偏好

經過廣泛的調查,TowerGroup公司發現,企業從前對某一個技術平台的偏好完全是基於個人的愛好和浮躁的“一窩蜂”心態。這種態勢目前漸漸層得理性,當然不排除仍然有某些IT經理存在著個人的嗜好。

但是企業對於Web Service和SOA的強烈關注,則意味著對於某種平台的個人嗜好不再成為平台選型的可接受的依據。

(2)沒有證據表明那一個平台更具延展性和可靠性

雖然有許多關於.Net和J2EE平台效能的研究報告,但是這些報告大部分要麼來自於Microsoft,要麼來自於J2EE的廠商,使得他們的公平性令人懷疑。也許他們的研究結果是真實的,但是這種供應商自身的效能測試本身就沖淡了研究結果的價值。另外,設計好的Test Case具有很大的複雜性,至多隻能有一到兩個比較全面的測試案例,其他的用例則顯得十分的蒼白與簡單,極大地限制了測試範圍的適應性,從而與實際應用情境距離甚遠。

差異的必然性

雖然對於.Net和J2EE平台的個人偏好顯得毫無理由,但是IT經理們承認這樣的一個事實:兩個平台的差異性常常成為他們在開發、選型和維護升級時的重要參考依據。

(1)在硬體和作業系統之間的可移植性

.Net和J2EE之間最大的差異性成為金融企業做技術選型的重要依據:在資料中心的數百台伺服器之間移植應用的能力。由於J2EE原本就是一套跨平台應用的規範,所以對於那些需要部署到不同伺服器上的應用,J2EE似乎是更好的選擇。

但是,J2EE的上述優勢卻遭到兩個因素的嚴重挑戰。

首先,沒有兩個廠家的J2EE規範是完全一致的。這種在部署、儲存和安全性規範上的微妙差別意味著在兩個平台之間的應用移植需要因為這種差異性的存在而付出代價。因為對於很多應用而言,應用的可移植性遠比可維護性還要重要。

其次,銀行從前為了克服應用能力的瓶頸,總是存在著升級到具備高端處理能力伺服器的需求。但是隨著基於Windows-Intel的機器處理能力越來越強大,這種需求被最小化。Unisys公司在6年前就推出了基於windows的主機(Mainframe),IBM也推出了64位的windows相容的系統,而CPU層疊技術也允許基於SMP(對稱式多處理)的Windows 伺服器系統擁有四個CPU。進一步,.Net作業系統(Vista和Longhorn)將進入高端處理市場,尤其是網路電腦的出現,使得大量的單機分散式處理能力足以勝任目前大型主機的工作負載。

(2)易開發性和可拆卸性

.NET的易用性、效率和成本均領先於J2EE。使用.Net,IT專家們比使用J2EE更加不用關心底層細節。因此能快速捕捉商機,成本也更低。

.Net比J2EE靈活得多,它允許開發人員使用多種語言在同一個平台上開發,因而能夠利用廣泛的開發資源。總而言之,使得Team Dev的運作更加高效。

重要的是,.Net的可用資源相對較多。對於金融行業而言,Windows平台佔據絕對數量,而且幾乎所有的ISV(獨立軟體廠商)都支援Windows平台。

另外,IT執行官們大多數只關心解決方案,而並不關心平台本身。他們並不要求ISV協助他們從.Net平台移植到J2EE平台,因此金融行業常常維護著不同的應用環境。

兩個因素也嚴重挑戰了.Net平台易用、高效和低成本的優勢(雖然.Net程式員相對於Java程式員而言,總是更快更高效)。

參與TowerGroup公司調查的IT執行官們透露了這樣的資訊,對於一個大型的項目而言,J2EE和.Net之間的TCO(總的擁有成本:包括資源、時間和財力)僅僅相差不到10%。同時,很多IT經理認為J2EE更適合效能調優,這兩個因素嚴重削弱了.Net的優勢。

(3)企業內部可用的資源

影響.Net和J2EE選型的最大因素來自企業內部的可用資源。

如果大部分的程式員擅長J2EE,那麼企業會很自然的選擇J2EE平台,而免除了再次培訓的開銷;相反,企業會選擇.Net平台。

TowerGroup公司的調查認為,將來純程式碼開發人員將會漸漸的轉向Windows平台,因為.Net支援多語言開發,並且遠離系統底層。但是,J2EE將在那些關注效能調節和特定領域的定製開發的企業裡繼續發展。

基於這樣的發現,TowerGroup對今天的.Net和J2EE的市場作了評估,結果如圖3所示。

Net 11%

J2EE 17%

不確定 15%

都沒有 2%

都有 55%

上表為美國金融企業的平台分布

資料來源:TowerGroup評估報告

雖然前100家銀行中很多繼續支援其中一種平台,但是大部分的銀行開始實施SOA架構,同時維護兩個平台。

(4)更遠的商機

無論銀行的IT機構對這兩個平台的看法如何,但是接受TowerGroup調查的IT執行官們一致認為,J2EE平台已經大範圍的被廣泛採納。在這場賽跑中,J2EE領先於.Net,而這種領先的優勢會隨著時間的推移而不斷的弱化。好幾個IT經理同時也認為,J2EE比.Net的生命週期更長,平台更加成熟,技術專家更多。

在TowerGroup公司最近的一次對歐洲銀行IT經理的調查中,參與者被問到“是否大量部署.Net平台”時,居然沒有一個人抬頭或者舉手;但是所有人都證實了他們部署了J2EE平台。無論如何,看來這種領先的趨勢很難改變。

不過,在與他們的討論過程中,有一點共識很明顯:微軟的確有機會提升.Net在銀行業的應用市場,填補太多的空白。

(5)案頭應用和企業級應用之間的差異

大多數人認為,在.Net和J2EE之間最為顯著的區別之一,就是.Net平台常常被部署在用戶端,而J2EE平台(如WebLogic/WebSphere/JBoss/TomCat)則更多的被部署在伺服器端。事實上這是一個不倫不類的誤解,.Net是一種技術架構,不是一種產品,更不是Windows用戶端;而J2EE只是一種協議,或者說是遵從J2EE協議的應用架構。

從某種程度上講,人們對.Net平台的認知誤解也誕生了一個笑話:因為微軟把自己的產品觸角延伸到了公司專屬應用程式的每個角落,從低端的案頭應用到高端的公司專屬應用程式,幾乎都看到了.Net平台的身影;那麼那些IT執行官們免不了會把他們在低端產品上的感受推而廣之到其他的微軟高端平台上。當一個IT經理在忙碌了一天之後回答家裡,開啟電腦卻還要耗費好幾個小時去面對PC機上的病毒幹擾,那麼Windows平台將會給他們留下“深刻的印象”。事實上微軟的高端和低端產品(如Win2k Pro/windows XP/Win2K Server與 Vista/Windows Server 2003/Longhorn)不可同日而語,但是這種主觀上的聯絡則很難避免。

也許微軟需要有不同的產品以分別面對家庭應用環境和強健的、基於關鍵業務的商業平台。

(6)強力宣傳與培訓

許多銀行對.Net平台在公司專屬應用程式上的技術一概無知,這種對.Net平台認知的匱乏延伸到了培訓領域。一些金融機構抱怨微軟從來沒有提供過如何利用.Net架構滿足業務需求的培訓。如果這種抱怨是真實的,那麼微軟也許只剩下對金融應用說“拜拜”的機會了。

鑒於這種來自使用者的抱怨,微軟需要在金融行業提供與其他競爭者同樣的培訓。

(7)不要單純的只提.Net技術

總之,微軟應該認識到那些試圖購買.Net平台的技術專家都是些老謀深算的高手,如果微軟一味的單純化.Net技術,則會讓這些“高手”們感覺這簡直就是一個別具一格的玩具,從而對.Net技術構建強大解決方案的能力表示懷疑。

每當那些滿腦子都是SOA的架構師們在回答關於.Net平台是否適合他們的應用需求時,總是這麼回答:“哦,用到了,因為.Net已經被嵌入在微軟的產品中了”。

在較早的調查中,我們看到J2EE受歡迎的一個原因就是它的彈性。如果.Net需要在金融領域取得同樣的成功,勢必需要和它的競爭者一樣的增強彈性和可配置特性。

(8)J2EE需要簡化

當.Net這匹黑馬開始活躍在企業級應用,並且愈來愈讓決策者們刮目相看的時候,迫使J2EE平台必須在既有的高端應用上有所作為。

Sun公司正在努力的簡化J2EE開發規範,使得Java開發人員們也享有.Net開發人員的快捷和愉悅。一個典型的例子是Java Studio Creator的出現,它允許開發人員們採用Drag & Drop的方式拖放組件以產生一個Web應用系統。開源組織也在極力的考慮如何簡化J2EE的開發,使得採用J2EE的開發能夠更加快速和廉價。

另外,被移植到Java虛擬機器上的程式語言的數量也在增加,現在不僅僅是Java語言才能運行在JVM上了。所以.Net在這方面的優勢開始削弱。

總結

.Net vs. J2EE不再顯得那麼不可琢磨,今天的IT執行官們已經能夠使用更客觀的標準來決定使用那一種平台,以及在什麼時候使用它。尤其在SOA的時代,技術架構師們常常樂於接受這兩個平台的並存,並且採用Web Service互聯互連。

今天,.Net技術愈來愈佔據了顯著的地位。雖然在成熟度等級等優勢上與J2EE還有一段距離,不過微軟可以採取策略迅速彌補這個鴻溝。

J2EE也有機會“跟上”.Net平台易用和高效的步伐,J2EE的信徒們正在努力。

微軟在高端市場的受挫,不是因為技術,而是因為其一貫的市場策略,因為.Net本身就是企業級的平台技術。

最終,.Net和J2EE技術都在朝著相互融合的態勢發展,Web Service、SOA、開發速度、更低的成本和柔性是它們必然的選擇。

將來,在這場競爭中倖免遇難的唯一途徑是:基於SOA的“.Net 與 J2EE”————而不是“.Net vs. J2EE”。



相關文章

Beyond APAC's No.1 Cloud

19.6% IaaS Market Share in Asia Pacific - Gartner IT Service report, 2018

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。