J2EE與NET平臺之間的差別

1、J2EE與.NET平臺之間的差別你可以看到在J2EE與.NET平臺技術(shù)之間由很大的重疊。但是，如何在它們之間進行選擇呢？在本節(jié)中，筆者將討論我所看到的主要差別。 開發(fā)商中立性許多公司購買J2EE，他們相信這可以給他們開發(fā)商中立地位。而實際上，這是Sun公司計劃的一個確定目標：配置和實施各種滿足J2EE規(guī)范需求的產(chǎn)品是可能的。一個可移植的J2EE應用程序在這些產(chǎn)品1中的任何一個產(chǎn)品中被成功部署后，都可以正確地運行。 實際上，除了Sun J2EE的擁護者，很少有人相信這是可以實現(xiàn)的。Paul Harmon是最重要的獨立J2EE發(fā)言人之一，他是Cutter Consortium的首席顧問，廣泛發(fā)行的

2、Architecture/e-Business E-Mail Advisory的作者。雖然Harmon總是反對J2EE，但他最近對J2EE的開發(fā)商可移植性寫了這樣不同尋常的坦誠的評價。EJB模型是否已經(jīng)達到了我可以將EJB組件從一個EJB應用服務器移動到另一個服務器的程度？在大多數(shù)情況下不能。EJB規(guī)范不夠全面。通過提供專有的解決方案來完善這個模型，確保他們的客戶可以創(chuàng)建生產(chǎn)系統(tǒng)，EJB應用服務器開發(fā)商彌補了這一點。2Harmon總結(jié)了當今開發(fā)商中立的情況， 他的評論如下：此刻，現(xiàn)實情況是如果你想開發(fā)一個EJB應用程序，你應當忠心于一個開發(fā)商。3今天的現(xiàn)實是，沒有像開發(fā)商中立這樣的情況。當然，

3、.NET平臺不是開發(fā)商中立的，它與微軟公司的操作系統(tǒng)捆綁到了一起。但是兩者都不是J2EE的實現(xiàn)。筆者可以給的最佳建議是，選擇某一開發(fā)商，計劃與其始終站在一起，這樣可以充分利用該開發(fā)商所提供的平臺優(yōu)勢。整體成熟性第一個J2EE規(guī)范，EJB規(guī)范在1998年提出，而第一個版本出現(xiàn)于1999年。而這則是在與之相當?shù)?NET平臺技術(shù)，MTS，COM+的前身第一次實現(xiàn)的3年之后了。筆者在最近的一篇文章4中討論了從MTS到COM+的發(fā)展過程。在.NET平臺比J2EE早出現(xiàn)兩年的情況下，了解.NET平臺比J2EE平臺更成熟就不足為怪了。雖然我們有大量的使用.NET技術(shù)的高度可靠的網(wǎng)站（NASDAQ和戴爾就是眾

4、多例子中的兩個），但我們不知道有哪個網(wǎng)站使用了J2EE平臺。Paul Harmon又作了如下評論：今天，任何一個正在嘗試基于J2EE的公司范圍的企業(yè)級系統(tǒng)的公司，都在盡力工作，更好的方法是讓一個真正優(yōu)秀的開發(fā)團隊來幫助他們擺脫困境。更重要的是，它可能應當重新考慮一個綜合的項目，并滿足于初始近似。5互用性與網(wǎng)絡服務諸如筆者詳細討論的，.NET平臺電子協(xié)作模型是以UDDI和SOAP標準為基礎(chǔ)的。這些標準被100多家公司廣泛支持。微軟公司，IBM和Ariba是這個領(lǐng)域的領(lǐng)導者。Sun公司是UDDI協(xié)會的會員，并且認識到了UDDI標準的重要性。在最近的新聞發(fā)布會上，Sun公司負責Java群體開發(fā)的副總

5、裁George Paolini說：“Sun公司一直在工作，以幫助建立和支持開放的、基于標準的技術(shù)，來促進基于網(wǎng)絡的應用的增長，并且我們認為UDDI是一個重要的、為B2B電子商務建立一個注冊架構(gòu)的項目。”6但是雖然Sun公司公開說相信UDDI標準，但實際上，Sun公司沒有采取任何措施將任何一種UDDI標準合并到J2EE中。這包括最基本的、已經(jīng)有一年多的UDDI標準，SOAP。正如IBM公司的Rod Smith（Emerging Technologies公司副總裁，該公司是Sun公司最強大的合作伙伴之一）所說： 迄今為止，Sun公司還沒有對UDDI網(wǎng)絡服務發(fā)表過得評論。但是我認為這樣是有原因的。我

6、認為他們正在考慮Java。當我們考慮網(wǎng)絡服務的時候，我們正在傾聽客戶的聲音和他們的需求，但事實是，客戶已經(jīng)有了不基于Java的系統(tǒng)和Java應用程序。因此，Sun公司仍然在堅持Java，但是在這個問題上非常平靜。7實際上，Smith對Sun公司的互用性策略的分析一語中的。Sun公司將重點主要集中在了J2EE開發(fā)商與CORBA開發(fā)商的互用性上。Sun公司的互用性想法是，應當以所謂的IIOP通信協(xié)議為基礎(chǔ)。 利用基于IIOP的互用性，有三個主要缺陷。第一，它需要全世界都運行J2EE或CORBA，這是一個連Sun公司的合作伙伴都反對的假定。IBM公司的Rod Smith解釋了IBM支持SOAP，而不

7、是支持IIOP作為互用性開放標準的原因：當發(fā)布聲明，并說我們IBM將把SOAP作為開放標準，并將其相應提前時，響應是令人無法置信的和積極的，因為人們希望進行這樣的集成工作。他們擁有基于微軟的解決方案。他們同時擁有基于Java的解決方案。他們還擁有基于Windows NT的解決方案和基于Linux的解決方案。8第二個缺陷是，像所有通信協(xié)議一樣，IIOP 應當服從在Internet上進行傳輸。這使得它不可能作為普遍的電子協(xié)作機制。 第三個缺陷是，即使全世界都同意使用IIOP和J2EE，即使在J2EE開發(fā)商中，對于確?；ビ眯援斍暗腎IOP規(guī)范也是不適當?shù)?。正如Paul Harmon所說的那樣：來自不

8、同開發(fā)商的EJB應用服務器是否以能在更大的系統(tǒng)中咬接的方式實行了標準化？盡管使用Internet InterORB Protocol (IIOP)來支持EJB間的應用程序通訊，但仍不能隨便地在一個網(wǎng)絡中將多個EJB產(chǎn)品結(jié)合在一起。 將每個都依賴幾個非標準工具進行平穩(wěn)通信的兩個EJB應用服務器仍然需要進行一些重要的程序設計工作。9今天的現(xiàn)實情況是，與J2EE相比，.NET平臺有一個更加強大的技術(shù)中性的電子協(xié)作策略。IBM公司深信不已，UDDI，而不是IIOP才是正確的互用性方法，在這個問題上，這已經(jīng)與Sun公司決裂了。在這一點上，令人痛苦但卻很明顯的是，盡管在UDDI上已經(jīng)領(lǐng)先了10年，但卻是一

9、個完全的失敗?？缮炜s性可伸縮性是指添加更多工作量的能力。一般來說，附加的工作量是客戶的增加引起的?？缮炜s性是一個復雜的問題，筆者已經(jīng)在幾篇已經(jīng)可以得到的文章中對此進行了深入探討10。未來簡化這個討論，筆者將在MoneyBroker可能會在接下來的3年中遇到的問題的上下文中討論可伸縮性。筆者將進一步簡化這個討論，而只考慮運行商務層和數(shù)據(jù)庫層的成本，盡管對表示層進行類似的分析可能會得出類似的結(jié)果。讓我們假定，MoneyBroker的商務模型要求它今年每天處理10萬筆支付，明年為100萬，而后年則為1000萬。選擇J2EE/Unix解決方案或.NET平臺/Windows解決方案的相關(guān)成本有哪些呢？為

10、了判斷MoneryBroker在接下來的3年中所需的機器規(guī)模，我們需要一個事務處理性能的標準的基準。事務處理吞吐量的工業(yè)標準基準是由所謂的Transaction Performance Council (TPC)協(xié)會規(guī)定的，該基準被稱為TPC-C基準。TPC會員包括Sun、IBM、Oracle、BEA、微軟和其他大部分銷售中間層/數(shù)據(jù)庫層產(chǎn)品的公司。TPC-C基準評定了一個系統(tǒng)可以獲得的最高工作量的等級。TPC-C基準定義的測量單位為tpmC，代表每分鐘交易處理數(shù)（transactions per minute）。除了說該基準考慮的是在分布式訂單輸入系統(tǒng)環(huán)境中的交易處理外筆者將不對其進行討論。

11、該基準的說明可以在TPC網(wǎng)站11得到。(/tpcc/results/tpcc_perf_results.asp?resulttype=all)在MoneyBroker使用TPC-C數(shù)使其平臺成為用戶選擇方面，正在面臨兩個問題。第一個問題是TPC-C規(guī)定的交易處理與MoneyBroker交易處理完全不同。這需要MoneyBroker徹底審核TPC-C規(guī)范，猜測在工作量中多少TPC-C交易才能與一個MoneyBroker交易相當。我們假定MoneyBroker計算得出它的一個交易與10個TPC-C交易相當，從而有大量的富余用于處理錯誤。第二個問題是，沒有一個J2E

12、E開發(fā)商已公開發(fā)布自己的TPC-C數(shù)。這使得MoneyBroker很難計算J2EE實施的吞吐量，即AIX。有趣的是，雖然所有重要的J2EE開發(fā)商已經(jīng)提交了TPC-C基準，但沒有一個開發(fā)商已經(jīng)提交了基于他們的J2EE技術(shù)的TPC-C數(shù)。例如，對于IBM公司的WebSphere技術(shù)（包含在J2EE技術(shù)中的IBM公司的一個品牌）有6個基準。但是，如果有人研究WebSphere的結(jié)果，就會發(fā)現(xiàn)沒有一個基準的代碼是使用Java編寫的，并且沒有一個基準使用了任何的WebSphere J2EE性能。實際上，這些基準使用了IBM公司傳統(tǒng)的Encina事務處理監(jiān)控技術(shù)，該產(chǎn)品是同時包含在總的WebSphere品

13、牌下。類似地，BEA公司使用了其傳統(tǒng)的Tuxedo技術(shù)來運行他們的基準，Tuxedo技術(shù)是其WebLogic品牌的一部分，但是卻沒有包含在J2EE中。由于我們沒有J2EE性能數(shù)字，我們得必須估計J2EE實現(xiàn)的相關(guān)性能。由于J2EE 基于傳統(tǒng)的事務處理監(jiān)控程序（開發(fā)商已經(jīng)確定了基準），但是仍然會增加Java程序設計語言。Java虛擬機和EJB（中間層）的開銷，比較合理的推測是J2EE將可以完成與之相當?shù)姆荍2EE系統(tǒng)（如Tuxedo性能）50%的性能。因此，筆者將使用一個50%調(diào)節(jié)系數(shù)來估計J2EE的吞吐能力。下面我們使用TPC-C 信息對MoneyBroker行為進行分析。MoneyBroke

14、r正在試圖確定購買何種系統(tǒng)。顯然，MoneyBroker希望花費盡可能少的資金，但仍確信可以獲得在客戶使用量達到峰值時所需的吞吐量，還確信它的系統(tǒng)可以進行伸縮以滿足接下來的三年內(nèi)的需求。今年MoneyBroker每天需要處理10萬筆交易。這相當于每分鐘處理70筆交易，峰值時大約為每分鐘處理700筆。由于一個MoneyBroker交易處理等于10 tpmC交易，這等于工作量達到峰值時大約為7000。明年，這個數(shù)目增加10倍達到70000 tpmC，而后年，這個數(shù)目再增加10倍，達到700000 tpmC。那么，在接下來的三年中，這些系統(tǒng)需要哪些支出(包括硬件和軟件在內(nèi))？讓我們從J2EE/Uni

15、x的可能支出開始，因此筆者將考慮在IBM公司的AIX操作系統(tǒng)、WebSphere和Oracle 8i系統(tǒng)中，哪一個最能代表J2EE/Unix系統(tǒng)。對于這種配置，有6個基準。按tpmC從最低到最高的次序排列，以及J2EE調(diào)整（前面已經(jīng)討論），結(jié)果如下：公司 系統(tǒng) tpmC 總系統(tǒng)成本Bull Escala T610 c/s 16,785 $1,980,179IBM RS/6000 Enterprise Server F80 16,785 $2,026,681Bull Escala EPC810 c/s 33,375 $3,037,499IBM RS/6000 Enterprise Server

16、M80 33,375 $3,097,055Bull Escala EPC2450 110,403 $9,563,263IBM IBM eServer pSeries 680 Model 110,403 $9,560,5947017-S85 如果我們考慮某些有代表性的.NET平臺系統(tǒng)（這些系統(tǒng)太多，不可能全部考慮，但數(shù)字非常一致），結(jié)果如下：公司 系統(tǒng) tpmC 總系統(tǒng)成本Dell PowerEdge 4400 16,263 $273,487 Compaq ProLiant ML-570-6/700-3P 20,207 $201,717Dell PowerEdge 6400 30,231 $33

17、4,626IBM Netfinity 7600 c/s 32,377 $443,463Compaq ProLiant 8500-X550-64P 161,720 $3,534,272 Compaq ProLiant 8500-X700-64P 179,658 $3,546,582Compaq ProLiant 8500-X550-96P 229,914 $5,305,571Compaq ProLiant 8500-X700-96P 262,244 $5,305,571Compaq ProLiant 8500-700-192P 505,303 $10,003,826你可以理解MoneyBroke

18、r 面臨的選擇。今年它只需一個7000 tpmC系統(tǒng)。在Unix市場這將大約花費200萬美元，而在.NET平臺市場則需要花費27.3萬美元。明年MoneyBroker將需要一個70000 tpmC系統(tǒng)，在J2EE/Unix市場需要花費950萬美元，而在.NET平臺市場則需要花費350萬美元。后年，MoneyBroker則需要一個700000 tpmC系統(tǒng)。這些系統(tǒng)中，沒有一個被評定為700,000 tpmC，但到面前為止最靠近的系統(tǒng)是1000萬美元的.NET平臺系統(tǒng)。如果一個與之相當?shù)腏2EE/Unix機器存在的話，估計需要花費4750萬美元。很明顯，如果系統(tǒng)的成本是一個重要的考慮事項，與J2

19、EE相比，.NET平臺有很大的優(yōu)勢。可以預計要獲得相同的功能，需要花的費用是在.NET平臺上所花的費用的5到10倍。如果一個工作單位在.NET平臺上花10美分，同一個工作單位則可能需要在J2EE/Unix上花50美分到1美元。筆者需要再次指出，雖然這些.NET平臺基準是實際機器的實際基準，但在這些J2EE基準中，沒有一個真正存在。這些基準是外推基準結(jié)果，實際的系統(tǒng)不一定能真正獲得這些結(jié)果。在J2EE開發(fā)商發(fā)布他們的基準數(shù)之前，我們必須記住，沒有一個J2EE平臺已經(jīng)被證明可以任何代價的情況下處理這些高工作量。架構(gòu)支持當創(chuàng)建一個大型的電子商務解決方案時，不用說沒有人希望從頭開始。而是希望在已經(jīng)完整

20、定義的、結(jié)果測試的電子商務架構(gòu)基礎(chǔ)上創(chuàng)建解決方案。使用這樣的架構(gòu)可以極大地降低開發(fā)成本，可能至少降低10倍。.NET平臺包括一個所謂的Commerce Server電子商務架構(gòu)。在這一點上，在J2EE空間內(nèi)沒有與之相當?shù)拈_發(fā)商中立的架構(gòu)。利用J2EE，你應當假定你需要從頭創(chuàng)建你的新的電子商務解決方案。Paul Harmon看來同意這種評價，說：選擇哪一個J2EE開發(fā)商，如果你期望一個允許你很快實施的完善的電子商務應用程序，你將會有令人沮喪不已的體驗。12如果使用MS Commerce Server作為你的電子商務基礎(chǔ)，那么很可能會對開發(fā)系統(tǒng)的成本有很大的影響。Commerce Server尤其

21、適合零售業(yè)務。這樣的電子商務系統(tǒng)應當仔細考慮這項技術(shù)。語言在語言方面，選擇很簡單。J2EE支持Java，并且只支持Java。在可預見的將來，它將不會支持其他任何種語言。.NET平臺支持出Java以外的其他任何種語言（盡管它支持一種在語法和功能上與Java相當?shù)恼Z言，C#）。實際上，倘若.NET平臺像一輛語言獨立的車輛一樣重要，在不遠的將來，很可能任何一種出現(xiàn)的語言都支持.NET平臺。 某些公司對J2EE支持其他語言所打動。盡管IBM公司的WebSphere和BEA公司的WebLogic支持其他語言，但是他們都不是通過J2EE技術(shù)實現(xiàn)的。在J2EE平臺種，只有兩種正式的方法來訪問其他語言，一種是

22、通過Java Native Interface，另一種方法是通過CORBA互用。Sun公司推薦采用后一種方法。正如Sun公司著名的科學家和Java設計師Rick Cattell在一次采訪種所說：你可以通過Java Native Interface功能和通過CORBA調(diào)用C+。CORBA可能是推薦的方法，因為它通過了更大的靈活性，并且我們已經(jīng)設計了在認可的環(huán)境中能夠很好地與CORBA一起工作的J2EE13。在CORBA體系結(jié)構(gòu)中創(chuàng)建任何新代碼都是一個很有問題地策略。CORBA是20世紀90年代受人喜愛地體系結(jié)構(gòu)，但現(xiàn)在已經(jīng)不再使用了。據(jù)筆者所了解，沒有一個CORBA開發(fā)商（除IONA外）在COR

23、BA上盈利，并且沒有一個開發(fā)商（包括IONA在內(nèi)）在繼續(xù)向該技術(shù)投資。底線是如果有人希望以Java以外的任何一種語言進行開發(fā)，那么J2EE是不正確的平臺選擇。當前某些非Java公司正在考慮在Java上進行重新標準化的可能性。要實現(xiàn)這一點，有三種可能的方法： 對現(xiàn)有職員進行再培訓 雇傭新職員，并盡可能地替換現(xiàn)有職員 外包 再培訓可能是最昂貴的選擇。以我的經(jīng)驗，有很大的管理費用與將傳統(tǒng)的程序員培訓成精通面向?qū)ο蟮腏ava程序員有關(guān)。這是Gartner集團最近的研究的結(jié)果，得出得結(jié)論是將一個COBOL程序員培訓成Java程序員，每人大約需花費6萬美元14。 筆者相信，對于Visual Basic程序

24、員，費用大體相當。并且在訓練結(jié)束，你在生產(chǎn)力方面一無所得。你可以簡單地雇傭一個現(xiàn)在可以編寫與花費6萬美元進行培訓后編寫的代碼相同，但現(xiàn)在就可以使用Java編寫該代碼的程序員。在許多公司中，筆者曾經(jīng)看到由于采用面向?qū)ο蟮募夹g(shù)損害生產(chǎn)力的情況，工作時間通常會浪費在了無休止的和沒有成果的關(guān)于“正確的”面向?qū)ο蟮脑O計與分析的理論討論上。雇傭和/或替換職員同樣代價昂貴。當前，Java程序員所要求的薪水比傳統(tǒng)的Visual Basic/COBOL程序員高30%。在筆者的經(jīng)驗中，他們還有更高的新雇人員比率。對于希望轉(zhuǎn)向Java的公司來說，外包可能是唯一可行的選擇。但是，假定外包可以完全使你擺脫上面提到的問題

25、是不現(xiàn)實的，很顯然，尤其是額外的程序員成本被轉(zhuǎn)移給你的情況下，更是這樣。那么你應當使用什么語言呢？底線是，如果你有經(jīng)過Java培訓的職員， 并且已經(jīng)有了合適的策略來確保對程序設計過程的有效管理，那么盡一切辦法堅持下去。筆者個人喜歡使用Java作為程序設計語言，盡管筆者認為至少有其他好的語言。另一方面，如果你的店鋪主要是由Visual Basic和COBOL組成，那么轉(zhuǎn)向Java差不多肯定會是代價昂貴的、令人沮喪的一次體驗你的語言選擇并不會必定決定你在J2EE和.NET平臺之間的選擇。當然，如果你希望使用Java以外的某些東西，那么你就處于J2EE空間之外了。但是，Java的吸引力并不需要剝奪你

26、使用.NET平臺的權(quán)利 。.NET平臺包括對C#（發(fā)音為C Sharp）支持，該語言是一種與Java很類似的語言，以至于許多人第一眼還不能將它們分辨開來。一個有經(jīng)驗的Java程序員可以在幾小時內(nèi)學會C#語法。但是，如果你選擇Java不是因為J2EE所聲稱的可移植性策略，那么C#或任何其他可以在.NET平臺上運行的語言不大可能會讓你愉快的。如果這樣，很明顯J2EE是你的選擇。但是，在做出選擇之前，一定要閱讀有關(guān)可移植性的章節(jié)。.可移植性J2EE的許多吸引力在于可移植性方面的承諾。有兩種可移植性。的一種是開發(fā)商可移植性。筆者將這種可移植性稱為開發(fā)商中立（vendor neutrality），前面已

27、經(jīng)討論（并拒絕）了這種想法。第二種可移植性是操作系統(tǒng)可移植性（operating system portability）。這指的是在不對代碼做任何改動的情況下，將代碼基從一個操作系統(tǒng)轉(zhuǎn)移到另一個操作系統(tǒng)的能力。與開發(fā)商中立不同，大多數(shù)J2EE實施最可能采取操作系統(tǒng)可移植性。J2EE最可能會采取操作系統(tǒng)可移植性的原因是，在很大程度上并不是由于J2EE任何固有的可移植性，而是大多數(shù)J2EE開發(fā)商支持多種操作系統(tǒng)。因此，只要一個公司忠誠于一個既定的J2EE開發(fā)商和一個既定的數(shù)據(jù)庫開發(fā)商，從一個操作系統(tǒng)轉(zhuǎn)向另一個操作系統(tǒng)是可能的。這可能是唯一一個最重要的J2EE平臺超過.NET平臺的益處，而.NET平

28、臺僅限于Windows操作系統(tǒng)。但是，微軟公司向ECMA（對JavaScript進行標準化的團體）提交C#規(guī)范和.NET Framework的一個子集（稱為Common Language Infrastructure）毫無價值。為什么開發(fā)商可移植性/中立令人滿意很明顯，但是操作系統(tǒng)可移植性有什么好處呢？我們認認為，一般有兩種類型的公司需要操作系統(tǒng)可移植性：獨立軟件開發(fā)商（ISV，Independent Software Vendor）和尋求可收縮性解決方案的公司。獨立軟件開發(fā)商（ISV）在有大量的非Windows平臺客戶群時需要操作系統(tǒng)可移植性。一個開發(fā)商不可能向依賴于.NET平臺的Unix客

29、戶銷售一件產(chǎn)品。如果.NET平臺比J2EE好還是不好無關(guān)緊要。它并不在Unix上運行。 如果獨立軟件開發(fā)商的產(chǎn)品必須銷售給非Windows客戶，尤其是當J2EE平臺本身需要與獨立軟件開發(fā)商的產(chǎn)品捆綁在一起作為集成產(chǎn)品提供時，J2EE提供了一個可接受的解決方案。 如果獨立軟件開發(fā)商的主要客戶群是Windows客戶，那么應當選擇.NET平臺。它可以在成本低得多的情況下提供好得多的產(chǎn)品。許多需要操作系統(tǒng)可移植性的公司并不是獨立軟件開發(fā)商。這些公司的大多數(shù)公司認為可移植性是通向可收縮性的道路。這些公司相信他們，隨著吞吐量需求的擴大，他們可以通過將應用程序移植到更高端硬件平臺來獲得更高的可收縮性。如果你

30、相信操作系統(tǒng)可收縮性能夠以任何方式幫助你獲得可收縮性，你正在犯一個嚴重錯誤?？墒湛s性不是一個硬件問題；它是一個軟件問題。最高的可收縮性可以通過尋求高度可收縮的平臺，然后盡可能地發(fā)揮該平臺的優(yōu)勢獲得。尋求在多個平臺上運行的J2EE實施，在可獲得的可收縮性方面還需很長的時間。到目前為止，在獲得高可收縮性的能力方面，最好的被證明的平臺是.NET平臺。 使用筆者在關(guān)于可收縮性的一節(jié)中給出的數(shù)字，.NET平臺可以從每分鐘處理16,000筆交易增加到超過每分鐘處理500,000筆交易。IBM WebSphere J2EE/Unix技術(shù)，是J2EE種類最好的代表之一，可能不會好于每分鐘處理17,000到11

31、0,000筆交易，而每筆交易的成本則更高。因此，可移植性并不是像看起來那么簡單。如果你真的需要可收縮性，很明顯，在.NET平臺和J2EE中，.NET平臺是勝者。如果你必須支持非Windows平臺，那么很明顯，J2EE是勝者。如果你需要可移植性，不依賴于一時的念頭或某一特定獨立軟件開發(fā)商的財富，那么忘掉它吧。這種 可移植性根本不存在。因此你要認真地選擇開發(fā)商。確信你了解，并且對該開發(fā)商的技術(shù)指導感覺滿意。確信你的開發(fā)商對該平臺有一個長期的承諾。最后，確信你的開發(fā)商有財政資源以在這個高度競爭的舞臺上生存。客戶端設備獨立性筆者討論了Java和.NET平臺表示層程序設計模型之間的差別。主要差別是，利用Java，決定傳輸給客戶端的最終HTML的是表示層程序員，而使用.NET，則是Visual Studio .NET控件。 這種Java方法有三個問題。第一個問題，它需要很多位于表示層的代碼，因為每個可能