且看微软的.Net和Sun公司的J2EE如何对垒
生活随笔
收集整理的這篇文章主要介紹了
且看微软的.Net和Sun公司的J2EE如何对垒
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
且看微軟的.Net和Sun公司的J2EE如何對壘[url]http://tech.163.com[/url]
2006-03-21 20:21:05 來源: sun
網友評論0 條論壇導讀:面對微軟推出的.Net FRAMEWORK,你可能會有以下疑問:
¨準確地講.Net平臺是什么?
¨如何將.Net的體系結構和J2EE對比?
¨從.Net的體系結構演繹出的一整套關于企業軟件開發方案中我們能學到此什么?
在本文中作者將為你解開這些疑問。
廖永康原文出處:[url]http://java.sun.com/features/2000/11/dotnetvsms.html[/url]
即使你沒有專門針對微軟平臺寫過程序,你可能也會聽到過微軟的.Net。這是微軟對最近一連串和
非視窗事件競爭的回答。如果你讀到過有關新聞、來自微軟的撰稿、或者通過在MSDN端瀏覽得到的
不完整的技術資料、或者你注意到了微軟專家開發者會議(會上已經演示了.Net平臺)的話,你可能
至少還有兩大疑問:
¨準確地講.Net平臺是什么?
¨如何將.Net的體系結構和J2EE對比?
如果你再深入一步的話,你可能還有第三個疑問活躍在你的腦海里:
¨從.Net的體系結構演繹出的一整套關于企業軟件開發方案中我們能學到此什么?
.Net框架是其生命周期的十分早期階段的產品,微軟.Net部門還會不斷地更深入和仔細地開發它,
但是無論怎樣,我們已經能夠從已有的資料對這些問題作出公正的正確的回答。
它是什么?(.Net是什么?)
現在在眾多的論壇中對.Net的反思,使人不禁聯想起三個瞎子摸象的寓言;根據你的洞察力,可能
得到非常不同的結論:有人認為.Net是微軟下一代Visual Studio的開發環境;有人認為它只是一種
新的編程語言(C#);還有人為它是基于XML和SOAP的一種新的數據交換和報文的工作框架。實際
上,.Net包含了這幾部份內容,而且還會更多。
首先,讓我們看一些具體的細節,瀏覽一下組成.Net平臺的一系列技術構件:
¨C#:是一種新寫的描述(書)構件的語言,它將C、C++和Java的元素集成起來,并增加一些特點如:
元數據標記、相關元素的開發。
¨“公共語言運行時”:它以中間語言(IL)格式,運行字節代碼,用一種語言寫的代碼和對象只要編
譯器是針對這種語言開發的,顯然能夠編譯成IL運行時。
¨一組基本的可從“公共語言運行時”訪問的構件(元件),它可提供各種功能(如:連網功能、包容
器功能等等)。
¨ASP.NET:是新的ASP版本,支持將ASP編譯成公共語言運行時功能(所以用任何語言寫的ASP腳本,
都能和IL捆綁在一起)。
¨視窗格式和Web格式:一種新的可從Visual Studio訪問的UI構件框架。(用戶接口=UI)。
¨ADO:將XML和SLAP用于數據交換的新一代ADO數據訪問構件(元件)。
.Net和J2EE如何比較?
正如我們所能看見的.Net平臺,在其傘型結構下有一個技術矩陣(寶塔)。顯然微軟為了抓住視窗平
臺的開發商,正在將這些技術變成現有平臺如J2EE和CORBA的代用品。但是怎樣對它們進行逐項比較
呢?一種方法就是將.Net和J2EE作成以下對比列表:
.Net J2EE 關鍵差異
C#編程語言Java編程語言C#和Java均來自C和C++,最顯著的特點(如垃圾收集層次結構的名字空
間)在兩個方面。C#借用了JavaBeans的某些構件概念(特性屬性、事件等),并增加了某些自己的概
念(如元數據標志),但將這些特點合并成不同的語法。Java以Java虛擬機方式運行在任何平臺上,
而C#在可預見的將來,僅運行在視窗環境內。C#隱含地結合到IL公共語言運行時中,(見后),然
后按合理的順序(JIT)運行。編譯成的字節編碼或者整個編譯成的自然編碼。Java代碼按照Java 虛
擬機字節代碼方式運行,它由VM解析或JIT編譯,或者整個編譯成自然代碼。
.Net公共元件(填補“.Net 框架結構的SDK”) Java核心API 高層的.Net元件,包括支持用XML和SOAP 的
分布式訪問(見ADO.NET)。
ASP.NET頁面(ASP.NET) Java服務器頁面(JSP) ASP.NET使用Visual Basic、C# 可能還有一別的語
言作為代碼段。通過公共語言運行時全部編譯成自然代碼(與此相對應<相反> 是象APS那樣,每次
都解析執行)。JSP使用Java代碼(段或者JavaBeans參考),或者編譯成Java字節代碼(按需或批編
譯要根據JSP實現系統來決定)。.Net公共語言運行時允許以多種語言的代碼(程序)在視窗環境下
使用一組共享的元件。優先于.Net框架的所有元件(公共元件、ASP.NET等)。
IL公共語言運行時Java虛擬機和CORBA IDL和ORB Java的虛擬機規程,允許Java字節代碼,在任何
平臺上按JVM方式運行。CORBA允許多種語言的代碼使用一組共享的對象,在任何帶有ORB的平臺上
運行,并不是緊密地集成到J2EE框架內。同樣的Web元件(如基于JSP的文件)在標準的Java平臺上
是沒有的,某些專有的元件只能通過Java IDE等得到。
視窗格式和Web格式Java的飄移通過MS Visual Studio的IDE而不是在本文所說的IDE,支持視窗格
式和Web格式的RAD開發,在許多Java的IDE和工具中都支持“飄移”(Swing)。
ADO.NET和基于SOAP的Web服務JDBC、EJB、JMS和Java XML庫(XML4J、JA-XP) ADO.NET建立在位于HTTP
協議頂部的XML數據交換的基礎上(指在遠程數據對象和多個應用程序捆綁之間的數據交換)。一般
說來,.Net的Web服務假定了SOAP發信模型。而EJB、JDBC等將數據交換協議和開發者處理權分離,
不工作在HTTP、KMI/JRMP或IIOP頂層。
該表的比較只抓住了表面現象,這里再總結一下.Net和J2EE的比較:
¨特點:.Net和J2EE都提供同樣優秀的特點,盡管提供的方法不同。
¨可移植性(Portability):.Net的核心只工作Windows環境下,但從理論上講可以支持以多種語言
開發(只要這些語言的子集/超集已經定義好,并為他們建立了IL編譯器)。也就是說:SOAP的能力
允許在其它平臺上的元件(部件)和.Net元件進行數據報文交換。而.Net中的一些元素:象SOAP,其
恢復和查找協議,作為公共部份提供構架的核心部件(IL運行時環境、ASP.NET內部的視窗格式和Web
格式元件“合同”等)仍由微軟掌握,微軟只扮演整個.Net開發環境和運行時環境提供者的角色。其實
早就有了來自開發者協會要求微軟公開這些規程,但是這和微軟的標準經驗相違背。
另一方面,J2EE只要遵循Java VM(規則)和一組平臺需要的服務就可以在任何平臺上工作(EJB包容
器、JMS服務等等)。所有這些定義了J2EE平臺的規程,都已經公開發表,并提供公眾閱讀。因此,
許多供應商也提供兼容產品和開發環境。但是J2EE是單語言平臺,若用其它語言調用或訪問對象,
可能需要通過CORBA,但是CORBA支持并不是平臺普遍存在的部分。
巨大的前景:
上述最后的幾點勾畫出.Net和J2EE的某些關鍵性的差異,以及微軟在這些方面所扮演的角色。微軟
現在正在為.Net做兩件值得注意的事:通過將XML和SOAP集成到他們的信息傳輸方案中,從而為以其
它編程語言開發商和非.Net部件打開通向.Net的道路。
通過讓語言元件交叉互動,.Net正在釋放Perl、Eiffel、Cobol和其它編程器,允許它們扮演微軟“沙
盤”的角色。這些語言的愛好者應該特別遵守規則,因為他們中大部分人在微軟/SUN/OpenSource競
爭中感受到約束和定界。因此,只要在他的元件發信層使用XML和SOAP,微軟就能支持他們將開放性
部件加到他們的平臺上,從而擺脫對專用性的依賴。
2006-03-21 20:21:05 來源: sun
網友評論0 條論壇導讀:面對微軟推出的.Net FRAMEWORK,你可能會有以下疑問:
¨準確地講.Net平臺是什么?
¨如何將.Net的體系結構和J2EE對比?
¨從.Net的體系結構演繹出的一整套關于企業軟件開發方案中我們能學到此什么?
在本文中作者將為你解開這些疑問。
廖永康原文出處:[url]http://java.sun.com/features/2000/11/dotnetvsms.html[/url]
即使你沒有專門針對微軟平臺寫過程序,你可能也會聽到過微軟的.Net。這是微軟對最近一連串和
非視窗事件競爭的回答。如果你讀到過有關新聞、來自微軟的撰稿、或者通過在MSDN端瀏覽得到的
不完整的技術資料、或者你注意到了微軟專家開發者會議(會上已經演示了.Net平臺)的話,你可能
至少還有兩大疑問:
¨準確地講.Net平臺是什么?
¨如何將.Net的體系結構和J2EE對比?
如果你再深入一步的話,你可能還有第三個疑問活躍在你的腦海里:
¨從.Net的體系結構演繹出的一整套關于企業軟件開發方案中我們能學到此什么?
.Net框架是其生命周期的十分早期階段的產品,微軟.Net部門還會不斷地更深入和仔細地開發它,
但是無論怎樣,我們已經能夠從已有的資料對這些問題作出公正的正確的回答。
它是什么?(.Net是什么?)
現在在眾多的論壇中對.Net的反思,使人不禁聯想起三個瞎子摸象的寓言;根據你的洞察力,可能
得到非常不同的結論:有人認為.Net是微軟下一代Visual Studio的開發環境;有人認為它只是一種
新的編程語言(C#);還有人為它是基于XML和SOAP的一種新的數據交換和報文的工作框架。實際
上,.Net包含了這幾部份內容,而且還會更多。
首先,讓我們看一些具體的細節,瀏覽一下組成.Net平臺的一系列技術構件:
¨C#:是一種新寫的描述(書)構件的語言,它將C、C++和Java的元素集成起來,并增加一些特點如:
元數據標記、相關元素的開發。
¨“公共語言運行時”:它以中間語言(IL)格式,運行字節代碼,用一種語言寫的代碼和對象只要編
譯器是針對這種語言開發的,顯然能夠編譯成IL運行時。
¨一組基本的可從“公共語言運行時”訪問的構件(元件),它可提供各種功能(如:連網功能、包容
器功能等等)。
¨ASP.NET:是新的ASP版本,支持將ASP編譯成公共語言運行時功能(所以用任何語言寫的ASP腳本,
都能和IL捆綁在一起)。
¨視窗格式和Web格式:一種新的可從Visual Studio訪問的UI構件框架。(用戶接口=UI)。
¨ADO:將XML和SLAP用于數據交換的新一代ADO數據訪問構件(元件)。
.Net和J2EE如何比較?
正如我們所能看見的.Net平臺,在其傘型結構下有一個技術矩陣(寶塔)。顯然微軟為了抓住視窗平
臺的開發商,正在將這些技術變成現有平臺如J2EE和CORBA的代用品。但是怎樣對它們進行逐項比較
呢?一種方法就是將.Net和J2EE作成以下對比列表:
.Net J2EE 關鍵差異
C#編程語言Java編程語言C#和Java均來自C和C++,最顯著的特點(如垃圾收集層次結構的名字空
間)在兩個方面。C#借用了JavaBeans的某些構件概念(特性屬性、事件等),并增加了某些自己的概
念(如元數據標志),但將這些特點合并成不同的語法。Java以Java虛擬機方式運行在任何平臺上,
而C#在可預見的將來,僅運行在視窗環境內。C#隱含地結合到IL公共語言運行時中,(見后),然
后按合理的順序(JIT)運行。編譯成的字節編碼或者整個編譯成的自然編碼。Java代碼按照Java 虛
擬機字節代碼方式運行,它由VM解析或JIT編譯,或者整個編譯成自然代碼。
.Net公共元件(填補“.Net 框架結構的SDK”) Java核心API 高層的.Net元件,包括支持用XML和SOAP 的
分布式訪問(見ADO.NET)。
ASP.NET頁面(ASP.NET) Java服務器頁面(JSP) ASP.NET使用Visual Basic、C# 可能還有一別的語
言作為代碼段。通過公共語言運行時全部編譯成自然代碼(與此相對應<相反> 是象APS那樣,每次
都解析執行)。JSP使用Java代碼(段或者JavaBeans參考),或者編譯成Java字節代碼(按需或批編
譯要根據JSP實現系統來決定)。.Net公共語言運行時允許以多種語言的代碼(程序)在視窗環境下
使用一組共享的元件。優先于.Net框架的所有元件(公共元件、ASP.NET等)。
IL公共語言運行時Java虛擬機和CORBA IDL和ORB Java的虛擬機規程,允許Java字節代碼,在任何
平臺上按JVM方式運行。CORBA允許多種語言的代碼使用一組共享的對象,在任何帶有ORB的平臺上
運行,并不是緊密地集成到J2EE框架內。同樣的Web元件(如基于JSP的文件)在標準的Java平臺上
是沒有的,某些專有的元件只能通過Java IDE等得到。
視窗格式和Web格式Java的飄移通過MS Visual Studio的IDE而不是在本文所說的IDE,支持視窗格
式和Web格式的RAD開發,在許多Java的IDE和工具中都支持“飄移”(Swing)。
ADO.NET和基于SOAP的Web服務JDBC、EJB、JMS和Java XML庫(XML4J、JA-XP) ADO.NET建立在位于HTTP
協議頂部的XML數據交換的基礎上(指在遠程數據對象和多個應用程序捆綁之間的數據交換)。一般
說來,.Net的Web服務假定了SOAP發信模型。而EJB、JDBC等將數據交換協議和開發者處理權分離,
不工作在HTTP、KMI/JRMP或IIOP頂層。
該表的比較只抓住了表面現象,這里再總結一下.Net和J2EE的比較:
¨特點:.Net和J2EE都提供同樣優秀的特點,盡管提供的方法不同。
¨可移植性(Portability):.Net的核心只工作Windows環境下,但從理論上講可以支持以多種語言
開發(只要這些語言的子集/超集已經定義好,并為他們建立了IL編譯器)。也就是說:SOAP的能力
允許在其它平臺上的元件(部件)和.Net元件進行數據報文交換。而.Net中的一些元素:象SOAP,其
恢復和查找協議,作為公共部份提供構架的核心部件(IL運行時環境、ASP.NET內部的視窗格式和Web
格式元件“合同”等)仍由微軟掌握,微軟只扮演整個.Net開發環境和運行時環境提供者的角色。其實
早就有了來自開發者協會要求微軟公開這些規程,但是這和微軟的標準經驗相違背。
另一方面,J2EE只要遵循Java VM(規則)和一組平臺需要的服務就可以在任何平臺上工作(EJB包容
器、JMS服務等等)。所有這些定義了J2EE平臺的規程,都已經公開發表,并提供公眾閱讀。因此,
許多供應商也提供兼容產品和開發環境。但是J2EE是單語言平臺,若用其它語言調用或訪問對象,
可能需要通過CORBA,但是CORBA支持并不是平臺普遍存在的部分。
巨大的前景:
上述最后的幾點勾畫出.Net和J2EE的某些關鍵性的差異,以及微軟在這些方面所扮演的角色。微軟
現在正在為.Net做兩件值得注意的事:通過將XML和SOAP集成到他們的信息傳輸方案中,從而為以其
它編程語言開發商和非.Net部件打開通向.Net的道路。
通過讓語言元件交叉互動,.Net正在釋放Perl、Eiffel、Cobol和其它編程器,允許它們扮演微軟“沙
盤”的角色。這些語言的愛好者應該特別遵守規則,因為他們中大部分人在微軟/SUN/OpenSource競
爭中感受到約束和定界。因此,只要在他的元件發信層使用XML和SOAP,微軟就能支持他們將開放性
部件加到他們的平臺上,從而擺脫對專用性的依賴。
轉載于:https://blog.51cto.com/itboy/109029
總結
以上是生活随笔為你收集整理的且看微软的.Net和Sun公司的J2EE如何对垒的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 波形捕捉:(7)“捕捉缓冲区”特效
- 下一篇: MSSQL2000 数据库文件迁移到 M