23,404
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
alexzhou 2002-03-23
- 打赏
- 举报
如果WindowsXP的安全性和稳定性大大提高的话,
.net绝对有前途
.net绝对有前途
baozhen 2002-03-23
- 打赏
- 举报
http://www.csdn.net/expert/cxy/net_j2ee.shtm
hexiaofeng 2002-03-23
- 打赏
- 举报
[技術短文]
比較 Microsoft .NET 和 J2EE 的構成技術
即使你不在微軟的平台上寫程式，你可能也聽過 Microsoft 推出的「.NET」平台，此技術是用來對付非微軟陣營的兵器。如果你讀過微軟的新聞稿，或者你瀏覽過 MSDN 的內容，還是你出席了微軟的專業程式員會議（也就是「.NET」平台現身的地方），你可能仍有兩個疑問：
「.NET」平台到底是什麼？
「.NET」架構和 J2EE 有哪些差異？
如果你想得更遠一點，你還會有第三個問題：
我們能從「.NET」架構中學到一些哪些有助於推展企業軟體開發的思維？
目前，「.NET」架構尚嫩，許多細節仍有待微軟的「.NET」小組釐清。雖然如此，我們仍然能夠從現有的資訊中得到上述問題的解答。
「.NET」平台到底是什麼？
現今大家對於「.NET」平台的看法有點類似寓言「瞎子摸象」，觀點不同，自有不同的想法。有些人說「.NET」是微軟的下一代 Visual Studio 開發環境；有些人說它是一個新的程式語言（C#）；還有些人說它是以 XML 和 SOAP 為基礎的資料交換與傳遞訊息的機制。其實，上述三者都是「.NET」想扮演的角色，而且還不止於此。
讓我們先得到一些較具體的觀念。下面列出「.NET」平台內部的組成：
C# 是一個「新程式語言」，用來撰寫類別和元件。C# 融合了 C/C++ 和 Java 的特色，還多了一些其它的特色，比方說 metadata tag。
一個「通用語言的執行時期系統（common language runtime）」，用來執行 IL 格式的程式碼。任何語言的原始程式只要被編譯成 IL 格式之後，就可在「.NET」平台執行。
一組「基礎元件」，提供多樣的功能（例如：網路），以供執行時期系統使用。
「ASP+」，是新版的 ASP，能讓 ASP 被編譯成 IL 的格式。
「Win Form」和「Web Form」，是一組新的 UI 元件骨架，供 Visual Studio 使用。
「ADO+」，是新版的 ADO，使用 XML 和 SOAP 來進行資料存取和資料交換。
「.NET」和 J2EE 有哪些差異？
如你所見，「.NET」平台是一堆技術的組合。微軟把這些技術當作現有技術（例如：J2EE 和 CORBA）的另一種選擇，但實際上比較起來又是如何呢？下面是我們的一些分析比較：
Microsoft.NET
J2EE
主要差異
C# 程式語言
Java 程式語言
C# 和 Java 都源自 C/C++。兩者有相當多共同的主要特色（包括：自動記憶體管理、階層式名字空間）。C# 從J avaBeans 學來一些元件觀念（propertie/attribute、event），還新增了一些特色（比方說 metadata tag），但是使用不同的語法。
Java 可以在任何有 Java 虛擬機器的平台上執行。C# 目前只能在 Windows 上執行。
C# 使用IL的執行時期系統。透過 just-in-time (JIT) 的編譯方式或原生碼編譯方式來執行。Java 程式是透過 Java 虛擬機器來執行，但是也可以編譯成原生碼。
「.NET」通用元件
Java core API
高階的「.NET」元件將支援透過 XML 和 SOAP 來存取。（請看下面 ADO+ 的介紹）
Active Server Pages+ (ASP+)
Java ServerPages (JSP)
ASP+ 將可以使用 Visual Basic、C#、和其它語言來撰寫程式片斷，然後被編譯成IL的格式（不像以前的 ASP 每次都需要直譯）。JSP 使用 Java 的程式碼，編譯成 Java 的 bytecode（可以需要時才編譯，也可以預先編譯好）。
IL 執行時期系統
Java 虛擬機器、CORBA IDL、CORBA ORB
「.NET」允許不同的程式語言使用 Windows 上的同一套元件。
Java 允許 Java bytecode 在相容的虛擬機器上都可以執行。
CORBA 允許不同語言和不同平台的物件互相溝通（必須有適合的 ORB）。J2EE 中可以使用CORBA，但兩者的整合度不算是很緊密。
Win Form 和 Web Form
Java Swing
類似的 Web 元件在標準的 Java 平台中付之闕如，有些其它廠商在 Java IDE 中提供一些元件。
MS Visual Studio IDE 提供 Win Form 和 Web Form 的 RAD 工具，目前尚未有其它廠商宣稱要支援 Win Form 和 Web Form。許多 Java IDE 工具都支援 Swing。
ADO+ 和 SOAP 的Web 服務
JDBC、EJB、JMS 和 Java XML 程式庫（XML4J、JAXP）
ADO+ 允許透過 HTTP 進行 XML 資料交換（在遠端資料物件和多層的程式之間），也就是SOAP。「.NET」的 Web 服務使用 SOAP 的訊息模型。EJB、JDBC 等則是把資料交換的通訊協定交由程式員自行決定，用 HTTP、RMI/JRMP 或 IIOP 都可以。
上面是各項技術的比較，下面是兩者的整體比較：
特色：「.NET」和 J2EE 都提供許多相似的特色，雖然方法不見得完全一樣。
可移植性：「.NET」只能在 Windows 上運作，但是理論上可以支援許多語言。而且，「.Net」支援 SOAP，使得不同平台的元件可以和「.NET」的元件交換訊息。雖然「.NET」中有些技術（比方說 SOAP 和其 discovery 與 lookup 機制）是公開的規格，核心的技術（比方說 IL 執行時期系統、ASP+、Win Form 與 Web Form）都還是由微軟所把持，而且微軟將會是「.NET」完整開發工具和平台的唯一提供廠商。
J2EE 則可以在任何有 JVM 的平台上執行，只要有相容的服務（比方說：EJB 容器、JMS 等）即可。J2EE 的一切標準都是公開的，許多廠商都提供相容的產品和開發工具。但是 J2EE 是一個單一語言的平台，如果要和其它語言平台溝通必須透過 CORBA（目前 J2EE 平台上不見得有支援 CORBA）。
整體來看
上面的各項分析指出「.NET」和 J2EE 的主要差異。微軟正在「.NET」上做兩件值得注意的事：開放「.NET」給其它程式語言的使用者，並開放「.NET」給非「.NET」元件的使用者（透過 XML 和 SOAP）。
因為「.NET」允許其它語言的元件整合進來，「.NET」賦予 Perl、Eiffel、Cobol 和其它語言的程式員在微軟的平台上做事。各種語言的愛好者尤其喜歡這點，因為他們中多數人才不在乎微軟和 Sun 以及開放陣營之間的戰火。
大家的反應如何？
對微軟的程式員來說：
如果你一直守著微軟的架構，那麼「.NET」的出現是一件好事。ASP+ 比 ASP 好；ADO+ 比 ADO 好；C# 比 C/C++ 好。「.NET」平台差不多要到 2001 才會現身，所以你還有時間準備。毫無疑問地，它將會變成微軟預設的開發環境。如果你現在正在使用微軟的開發工具，未來移轉到「.NET」之後，你也會享受到這種種好處。
然而，「.NET」平台的一些目的太過崇高，不保證能達得到（至少短期內是如此）。比方說，IL 執行系統有一些很明顯的難題待克服，想整合進此系統的每個語言必須清楚地定義如何對應到 IL，以及 IL 所需的 metadata。某語言要相容於 IL 來必須提供編譯器（x 語言轉 IL，和 IL 轉 x 語言）。
這有前例可尋。有許多編譯器可將非 Java 語言轉成 JVM 可執行的程式，這些語言包括了 JPython、PERCobol、the Tcl/Java project，有趣的是，連 Bertrand Meyer 和一些 Eiffel 語言的傢伙也早在幾年前就做出 Eiffel-to-JavaVM 的工具。其中只有 JPython 是成功的，其它的工具好像都沒人在用，甚至連這些語言本身的族群都不用，雖然這些工具的出現使得他們能使用最愛的語言來寫 Java 程式。為什麼就是無法引起大家的熱誠？我相信這是因為人們懷疑混合兩種異質的語言環境會水土不服。如果他們想寫在 JVM 上執行的程式，他們寧可花時間去學 Java 語言。我想，同樣的情況也會出現在「.NET」平台上，人們寧可花時間去學 C# 來寫「.NET」程式，而非使用其它語言。
還有一點要注意的：「.NET」使用的 SOAP 架構的性能值得觀察。SOAP 使用 HTTP 來傳遞 XML。HTTP 不是有效率的通訊協定，而且 XML 還需要額外的文件剖析（parse），這又是計算上的負擔。兩者的結合會使得交易的速度大大低於其它方案。XML 是一個用途廣、健全、又具涵義的訊息機制，而 HTTP 是一個廣泛又能避免許多關於防火牆的問題，但是如果效率對你來說很重要，那麼你應該多瞧瞧其它的方式，而不要用 SOAP。
對 Java 和 Open Source 族群來說：
「.NET」很容易被視為微軟基於市場需求所推出的解決方案。其實，「.NET」是微軟開始策略改變的徵兆。以往微軟在面對其它架構和平台有不錯的戰果，現在他們面對了來自 Java 和 open source 的壓力，開始有了「開放」的跡象，也試著直接去滿足程式員的需求，這可是和以往的老大作風大不相同。如果你是 Java 或 open source 的愛好者，請注意：這場戰爭的本質已經有所改變了。
而且，微軟的 IL 執行時期系統有一點值得注意的目標：消弭程式語言和 API 之間的藩籬。Java 消弭了平台間的藩籬，但是如果你想使用 J2EE，你就必須搭配 Java 語言。「.NET」想讓你使用你喜愛的語言來開發「.NET」程式，這點是很了不起的（但結果是否會成真仍是個大問號）。從這點來看，J2EE 就比不上「.NET」，但是這點應該不算太重要。
J2EE 如果想迎戰「.NET」，有幾個議題應該立刻被注意到。首先，J2EE 應該將 XML 好好地整合進來。我不是指制定 XML SAX/DOM 的 API，也不是指拿 XML 當作設定檔格式，我說的是 XML 的訊息交換和處理應該被加進 J2EE。當然，目前你可以用 XML 格式當作 JMS 訊息內容，但整個 J2EE 卻不會因此受益。XML 是一堆標準的集合，包括業界標準的 API 和 DTD，這應該都是資料交換時可以享受到的好處才是。
但是微軟把賭注下在 SOAP 上，而且正積極地將 SOAP 的相關資訊傳送給程式員。J2EE 也應該如此，我想到的方法之一是在 JMS 上加一層 XML messaging provider，並整合進 Java Naming and Directory Interface（JNDI）和 LDAP、NIS、COS Naming 等技術。這樣就等於是結合了 SOAP/BizTalk provider、ebXML provider 等技術。
本文作者：Jim Farley，著有 Java Distributed Computing、Java Enterprise in a Nutshell（合著）
本文譯者：蔡學鏞
張貼日期：9/7/00
比較 Microsoft .NET 和 J2EE 的構成技術
即使你不在微軟的平台上寫程式，你可能也聽過 Microsoft 推出的「.NET」平台，此技術是用來對付非微軟陣營的兵器。如果你讀過微軟的新聞稿，或者你瀏覽過 MSDN 的內容，還是你出席了微軟的專業程式員會議（也就是「.NET」平台現身的地方），你可能仍有兩個疑問：
「.NET」平台到底是什麼？
「.NET」架構和 J2EE 有哪些差異？
如果你想得更遠一點，你還會有第三個問題：
我們能從「.NET」架構中學到一些哪些有助於推展企業軟體開發的思維？
目前，「.NET」架構尚嫩，許多細節仍有待微軟的「.NET」小組釐清。雖然如此，我們仍然能夠從現有的資訊中得到上述問題的解答。
「.NET」平台到底是什麼？
現今大家對於「.NET」平台的看法有點類似寓言「瞎子摸象」，觀點不同，自有不同的想法。有些人說「.NET」是微軟的下一代 Visual Studio 開發環境；有些人說它是一個新的程式語言（C#）；還有些人說它是以 XML 和 SOAP 為基礎的資料交換與傳遞訊息的機制。其實，上述三者都是「.NET」想扮演的角色，而且還不止於此。
讓我們先得到一些較具體的觀念。下面列出「.NET」平台內部的組成：
C# 是一個「新程式語言」，用來撰寫類別和元件。C# 融合了 C/C++ 和 Java 的特色，還多了一些其它的特色，比方說 metadata tag。
一個「通用語言的執行時期系統（common language runtime）」，用來執行 IL 格式的程式碼。任何語言的原始程式只要被編譯成 IL 格式之後，就可在「.NET」平台執行。
一組「基礎元件」，提供多樣的功能（例如：網路），以供執行時期系統使用。
「ASP+」，是新版的 ASP，能讓 ASP 被編譯成 IL 的格式。
「Win Form」和「Web Form」，是一組新的 UI 元件骨架，供 Visual Studio 使用。
「ADO+」，是新版的 ADO，使用 XML 和 SOAP 來進行資料存取和資料交換。
「.NET」和 J2EE 有哪些差異？
如你所見，「.NET」平台是一堆技術的組合。微軟把這些技術當作現有技術（例如：J2EE 和 CORBA）的另一種選擇，但實際上比較起來又是如何呢？下面是我們的一些分析比較：
Microsoft.NET
J2EE
主要差異
C# 程式語言
Java 程式語言
C# 和 Java 都源自 C/C++。兩者有相當多共同的主要特色（包括：自動記憶體管理、階層式名字空間）。C# 從J avaBeans 學來一些元件觀念（propertie/attribute、event），還新增了一些特色（比方說 metadata tag），但是使用不同的語法。
Java 可以在任何有 Java 虛擬機器的平台上執行。C# 目前只能在 Windows 上執行。
C# 使用IL的執行時期系統。透過 just-in-time (JIT) 的編譯方式或原生碼編譯方式來執行。Java 程式是透過 Java 虛擬機器來執行，但是也可以編譯成原生碼。
「.NET」通用元件
Java core API
高階的「.NET」元件將支援透過 XML 和 SOAP 來存取。（請看下面 ADO+ 的介紹）
Active Server Pages+ (ASP+)
Java ServerPages (JSP)
ASP+ 將可以使用 Visual Basic、C#、和其它語言來撰寫程式片斷，然後被編譯成IL的格式（不像以前的 ASP 每次都需要直譯）。JSP 使用 Java 的程式碼，編譯成 Java 的 bytecode（可以需要時才編譯，也可以預先編譯好）。
IL 執行時期系統
Java 虛擬機器、CORBA IDL、CORBA ORB
「.NET」允許不同的程式語言使用 Windows 上的同一套元件。
Java 允許 Java bytecode 在相容的虛擬機器上都可以執行。
CORBA 允許不同語言和不同平台的物件互相溝通（必須有適合的 ORB）。J2EE 中可以使用CORBA，但兩者的整合度不算是很緊密。
Win Form 和 Web Form
Java Swing
類似的 Web 元件在標準的 Java 平台中付之闕如，有些其它廠商在 Java IDE 中提供一些元件。
MS Visual Studio IDE 提供 Win Form 和 Web Form 的 RAD 工具，目前尚未有其它廠商宣稱要支援 Win Form 和 Web Form。許多 Java IDE 工具都支援 Swing。
ADO+ 和 SOAP 的Web 服務
JDBC、EJB、JMS 和 Java XML 程式庫（XML4J、JAXP）
ADO+ 允許透過 HTTP 進行 XML 資料交換（在遠端資料物件和多層的程式之間），也就是SOAP。「.NET」的 Web 服務使用 SOAP 的訊息模型。EJB、JDBC 等則是把資料交換的通訊協定交由程式員自行決定，用 HTTP、RMI/JRMP 或 IIOP 都可以。
上面是各項技術的比較，下面是兩者的整體比較：
特色：「.NET」和 J2EE 都提供許多相似的特色，雖然方法不見得完全一樣。
可移植性：「.NET」只能在 Windows 上運作，但是理論上可以支援許多語言。而且，「.Net」支援 SOAP，使得不同平台的元件可以和「.NET」的元件交換訊息。雖然「.NET」中有些技術（比方說 SOAP 和其 discovery 與 lookup 機制）是公開的規格，核心的技術（比方說 IL 執行時期系統、ASP+、Win Form 與 Web Form）都還是由微軟所把持，而且微軟將會是「.NET」完整開發工具和平台的唯一提供廠商。
J2EE 則可以在任何有 JVM 的平台上執行，只要有相容的服務（比方說：EJB 容器、JMS 等）即可。J2EE 的一切標準都是公開的，許多廠商都提供相容的產品和開發工具。但是 J2EE 是一個單一語言的平台，如果要和其它語言平台溝通必須透過 CORBA（目前 J2EE 平台上不見得有支援 CORBA）。
整體來看
上面的各項分析指出「.NET」和 J2EE 的主要差異。微軟正在「.NET」上做兩件值得注意的事：開放「.NET」給其它程式語言的使用者，並開放「.NET」給非「.NET」元件的使用者（透過 XML 和 SOAP）。
因為「.NET」允許其它語言的元件整合進來，「.NET」賦予 Perl、Eiffel、Cobol 和其它語言的程式員在微軟的平台上做事。各種語言的愛好者尤其喜歡這點，因為他們中多數人才不在乎微軟和 Sun 以及開放陣營之間的戰火。
大家的反應如何？
對微軟的程式員來說：
如果你一直守著微軟的架構，那麼「.NET」的出現是一件好事。ASP+ 比 ASP 好；ADO+ 比 ADO 好；C# 比 C/C++ 好。「.NET」平台差不多要到 2001 才會現身，所以你還有時間準備。毫無疑問地，它將會變成微軟預設的開發環境。如果你現在正在使用微軟的開發工具，未來移轉到「.NET」之後，你也會享受到這種種好處。
然而，「.NET」平台的一些目的太過崇高，不保證能達得到（至少短期內是如此）。比方說，IL 執行系統有一些很明顯的難題待克服，想整合進此系統的每個語言必須清楚地定義如何對應到 IL，以及 IL 所需的 metadata。某語言要相容於 IL 來必須提供編譯器（x 語言轉 IL，和 IL 轉 x 語言）。
這有前例可尋。有許多編譯器可將非 Java 語言轉成 JVM 可執行的程式，這些語言包括了 JPython、PERCobol、the Tcl/Java project，有趣的是，連 Bertrand Meyer 和一些 Eiffel 語言的傢伙也早在幾年前就做出 Eiffel-to-JavaVM 的工具。其中只有 JPython 是成功的，其它的工具好像都沒人在用，甚至連這些語言本身的族群都不用，雖然這些工具的出現使得他們能使用最愛的語言來寫 Java 程式。為什麼就是無法引起大家的熱誠？我相信這是因為人們懷疑混合兩種異質的語言環境會水土不服。如果他們想寫在 JVM 上執行的程式，他們寧可花時間去學 Java 語言。我想，同樣的情況也會出現在「.NET」平台上，人們寧可花時間去學 C# 來寫「.NET」程式，而非使用其它語言。
還有一點要注意的：「.NET」使用的 SOAP 架構的性能值得觀察。SOAP 使用 HTTP 來傳遞 XML。HTTP 不是有效率的通訊協定，而且 XML 還需要額外的文件剖析（parse），這又是計算上的負擔。兩者的結合會使得交易的速度大大低於其它方案。XML 是一個用途廣、健全、又具涵義的訊息機制，而 HTTP 是一個廣泛又能避免許多關於防火牆的問題，但是如果效率對你來說很重要，那麼你應該多瞧瞧其它的方式，而不要用 SOAP。
對 Java 和 Open Source 族群來說：
「.NET」很容易被視為微軟基於市場需求所推出的解決方案。其實，「.NET」是微軟開始策略改變的徵兆。以往微軟在面對其它架構和平台有不錯的戰果，現在他們面對了來自 Java 和 open source 的壓力，開始有了「開放」的跡象，也試著直接去滿足程式員的需求，這可是和以往的老大作風大不相同。如果你是 Java 或 open source 的愛好者，請注意：這場戰爭的本質已經有所改變了。
而且，微軟的 IL 執行時期系統有一點值得注意的目標：消弭程式語言和 API 之間的藩籬。Java 消弭了平台間的藩籬，但是如果你想使用 J2EE，你就必須搭配 Java 語言。「.NET」想讓你使用你喜愛的語言來開發「.NET」程式，這點是很了不起的（但結果是否會成真仍是個大問號）。從這點來看，J2EE 就比不上「.NET」，但是這點應該不算太重要。
J2EE 如果想迎戰「.NET」，有幾個議題應該立刻被注意到。首先，J2EE 應該將 XML 好好地整合進來。我不是指制定 XML SAX/DOM 的 API，也不是指拿 XML 當作設定檔格式，我說的是 XML 的訊息交換和處理應該被加進 J2EE。當然，目前你可以用 XML 格式當作 JMS 訊息內容，但整個 J2EE 卻不會因此受益。XML 是一堆標準的集合，包括業界標準的 API 和 DTD，這應該都是資料交換時可以享受到的好處才是。
但是微軟把賭注下在 SOAP 上，而且正積極地將 SOAP 的相關資訊傳送給程式員。J2EE 也應該如此，我想到的方法之一是在 JMS 上加一層 XML messaging provider，並整合進 Java Naming and Directory Interface（JNDI）和 LDAP、NIS、COS Naming 等技術。這樣就等於是結合了 SOAP/BizTalk provider、ebXML provider 等技術。
本文作者：Jim Farley，著有 Java Distributed Computing、Java Enterprise in a Nutshell（合著）
本文譯者：蔡學鏞
張貼日期：9/7/00
maleangel 2002-03-23
- 打赏
- 举报
ｔｏ GJA106(中文字符)
这个网页是ｔｗ的繁码，连MAGICWIN也翻不过来
有没有简体中文的
谢谢了
这个网页是ｔｗ的繁码，连MAGICWIN也翻不过来
有没有简体中文的
谢谢了
GJA106 2002-03-23
- 打赏
- 举报
看看http://www.oreilly.com.tw/sleepless/net_j2ee.htm
Patrick_DK 2002-03-23
- 打赏
- 举报
没意思
hello_wyq 2002-03-23
- 打赏
- 举报
变态的题目。
一点价值都没有！
一点价值都没有！
