·.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.
圖1為2002年Merrill Lynch對全球100個CIO關于Web Service在兩種平臺的應用分布數據。對100個CIO的問卷調查顯示出他們的公司缺乏清晰的Web Service應用戰略。
圖2顯示了2002年.Net和J2EE平臺在美國最大的100家銀行的應用分布。
Net 15%
J2EE 36%
不確定 24%
都沒有 5%
都有 20%
圖2 美國最大的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)將進入高端處理市場，尤其是網絡計算機的出現，使得大量的單機分布式處理能力足以勝任目前大型機的工作負荷。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
