帳號:
密碼:
最新動態
 
產業快訊
CTIMES / 文章 /
新一代的Web應用標準競爭(三)
微軟.NET vs. 昇陽J2EE

【作者: 葉建華】   2001年09月01日 星期六

瀏覽人次:【6465】

前言

在上期中,筆者針對J2EE與.NET的基礎架構支援技術,做了全面性的介紹,同時也將這二大架構的技術做了簡要的比較。在本期中,我們將再深入探討其中重要的運作架構模型,以期能夠達到深會探究的目的,也希望讀者可以藉由本文的比較,找出您心目中所謂的“贏家”,以利各位在未來軟體研發或決策上,能有更正確的決定。


本文中,將先以元件架構以及客戶端架構部份的討論為開端,接著討論二大架構下最重要的兩大議題:資料/目錄存取,以及對XML的支援,由檢討二者開發的架構性,讓讀者能夠更了解二者所採取的市場策略。接下來,我們就開始這系列的探討旅程。


回顧元件架構

由於J2EE是由昇陽公司所提出的運作架構,因此在這運作架構中的主角自然是所謂的JavaBeans 以及EJB(Enterprise JavaBeans)元件模型。JavaBeans是所有Java元件的基礎精華,其文件中定義了物件屬性(attribute)、事件處理程序(event-handling)、物件永續性質(persistence)、物件自省功能(introspection),伴隨著Java執行所提供的各項特色,如記憶體管理、安全管理,以及JavaBeans架構,所定義出來的分散式運算版本,其中包含遠端存取與運作元件,分散或安全管理,分散或交易處理支援,更強大的物件永續性管理,物件運作週期管理(life-cycle management),以及資源運作管理(resource pooling)等等。


反觀微軟的.NET架構,是由微軟最初的物件運作模型所演變而來,包括COM(Component Object Model)以及COM+所組成,這兩種元件運作模型,將隨著.NET架構的出現,而逐一被新的元件架構所取代。在新的.NET架構下,共用語言執行環境(Common Language Runtime, CLR)肩負起提供基礎服務的重責大任,包括安全管理以及記憶體管理等等,而這些有如Java虛擬機器的功能,是以前COM或COM+模型中所未見到的。同時.NET也延伸了既有的微軟元件架構,包括擴充多重介面繼承(multiple interface inheritance)、具有彈性的物件詮釋資料(meta-data),以及新的連接模型(delegate model)。總而言之,CLR擴充了COM以及COM+的元件架構,加入了新且豐富的特色,徹底地區隔出與傳統COM架構的不同。


微軟在元件架構開發的歷史由來已久,部分原因乃是因為微軟對平台開發者提供了主要的整合性開發環境(包括Visual Studio及其前身),而微軟的元件架構,隨著微軟作業系統的演進,也進行了多次的進化與改版。反觀Java的元件架構,雖未經多次改版的洗禮(也就是說,不具有傳統常見的相容性負擔),但以其與Java語言本身的密切關係,很可能會對架構本身的演進,帶來一定程度的阻礙。


對各類型客戶端的支援比較

筆者在此粗略地將客戶端分為兩大類型:一為應用程式類,也就是所謂的“胖”客戶端(fat clients);另一則為動態產生的網頁類,也就是所謂的“瘦”客戶端(thin client,或稱精簡型客戶端)。


昇陽陣營

視覺化對fat client來說,J2EE提供了Java的Swing介面,也就是一組由標準的JavaBean元件所形成的集合,透過視覺化開發環境適當的組合(如WebGain的Visual Cafe,Borland的JBuilder,IBM的VisualAge for Java等等),構成與使用者互動的視覺化介面。


而對thin client的開發而言,J2EE則提供了Servlet以及JSP(Java ServerPages)技術來建立以HTML、WML,或XML為基礎的動態網頁客戶端。目前支援Java Servlet以及JSP技術的應用伺服器甚多,其中包括商業性質的(如BEA的WebLogic , iPlanet ,IBM WebSphere以及SilverStream等等)以及非商業性質的(如Apache的Jarkata開發計畫,Enhydra,以及Resin等等)。


微軟陣營

反觀微軟陣營,針對fat client部分,傳統上都是透過提供微軟的基礎物件MFC(Microsoft Foundation Classes)來進行建構工作。但是從新的.NET架構開始,微軟轉為提供新一類的基礎建構元件集,稱之為Windows Forms。基本上,Windows Forms的功能與角色,和原先的MFC相同,但是微軟為了新的.NET架構執行環境,不得不將MFC以Windows Forms來取代。


而針對thin client部分,微軟則發展出新版本的ASP(Active Server Pages)來因應,稱為ASP.NET。基本上,ASP.NET的功能與ASP並無不同,但是為了因應新的.NET架構執行環境,也就是要在新的共同語言執行環境(CLR)下運作,因此才對ASP做了一定幅度的進化。同時以ASP.NET所撰寫的程式片斷不再是利用解譯(Interpret)的形式來執行,而是轉為由編譯(Compile)成CLR下的執行IL位元碼來取代。


對資料存取與目錄服務的比較

J2EE與.NET平台在資料存取以及目錄服務方面,均提供了不同形式但類似功能的程式開發介面。


昇陽陣營

在J2EE環境中,存取資料來源的方式,主要是透過JDBC介面來完成。JDBC是一個可以涵蓋不同關聯式資料庫的共通介面,將各種不同關聯式資料庫的存取方法,改為統一的存取方式。由於JDBC是一種較為低階的程式開發介面,由幾種最基本的存取單位來進行運作(Connections, Statements, ResultSets)。因此在新的JDBC 2.0之後,便開始延伸這些基本功能,包括連接資源管理(Connection Pooling)、支援分散式的交易模型(Open XA)。


這些延伸都是由新的Java 2平台來提供,而J2EE使用了這樣的平台後,自然令涵蓋這些功能,而更高階的資料存取途徑,則是由J2EE中的entity bean以及資料永續化服務來共同完成。在此類商業性的產品上,有許多協力廠商提供商品與服務,如昇陽的Java Blend,WebGain的TopLink,但是這些都沒有涵蓋在J2EE所定義的範圍之中。


接著提到的是目錄服務,在Java環境中,目錄服務是由JNDI(Java Naming and Directory Interface)來完成。JNDI是一種介面定義,其下可以涵括許多不同的資料對應形式。包括名稱、本文內容,以及屬性值等等。JNDI所能涵蓋的目錄服務實作目前約有LDAP、Novell NDS、NIS、DNS,以及DSML(Directory Service Markup Language)來源等。


微軟陣營

反觀微軟的資料來源存取形式,是源自於微軟自行發展的OLE以及ODBC介面,後來演化形成的DAO(Data Access Object),以及最後所形成的ADO(ActiveX Data Object)介面。ADO目前的角色,就如同Java世界中的JDBC以及JNDI的混合體,也就是說,所有的資料與目錄的存取動作,都被定義成為幾個基本的存取動作(Connections, Commands, 以及RecordSets),共同對資料來源與目錄服務進行運作。ADO有著某些比JDBC 2.0更為強大的功能,包括資料記錄的瀏覽以及離線的資料存取。可是ADO也有其缺點,在於ADO是會仰賴以COM模型為基礎的OLE DB以及ODBC介面,間接地嚴重影響其擴充性以及互動性。


由於ADO有以上的缺點,微軟便在.NET架構中重新定義ADO.NET,用來取代既有的ADO介面。ADO.NET捨棄了原有的COM-based基礎,而改以開放性的XML資料傳輸為其核心能力。因此,ADO.NET在開放性方面大幅的改變了以往ADO介面的不足。由於XML在存取以及可移植性方面表現優越,因此在.NET架構的觀點中,資料來源以及目錄服務是可以變成虛擬的,開啟了更多可能性。但是XML的缺失,也是其優點,便是較高的可讀性,也就是較為龐雜的資料描述,而這間接影響了資料處理的效率。


對一般性XML資料處理的支援

就XML資料處理而言,J2EE與.NET平台都提供了最基本的支援,其中包括了最重要的文件物件模型(Document Object Model, DOM)呼叫介面API的定義,可以用來產生DOM的解釋與結構。


昇陽陣營

Java在XML資料處理方面,主要是提供了JAXP(Java API for XML Processing),來支援DOM以及SAX(Simple API for XML)模式的處理,同時也提供了一個運作架構,可以讓不同的解譯模組(parsing engine)嵌入執行。在此筆者必須強調,目前在J2EE架構中,並沒有強調XML API的存在,因為對XML的處理支援,是在Java2基本工具中就已經存在。但是從J2EE 1.3開始,將會陸續加入對XML處理更進階的支援,這不但具有象徵性的意義,同時也表示出J2EE走向開放標準的努力。


在Java環境中對XML資料處理的支援並非不足,相反地,Java對XML的支援是廣泛且多樣的:我們可以發現,與XML相關的新標準,大都是用Java先實作出來的。而昇陽公司近來更發表了在訊息傳遞方面的標準JAXM(Java API for XML Messaging),其中使用了ebXML來提供訊息服務。此外也發表了資料繫結方面的標準JAXB(Java API for XML Data Binding),其中使用XML Schema以及XML Binding來定義XML資料與Java物之間的建構與解構關係。目前這些標準正在討論加入J2EE的相關議題,相信會在未來的J2EE版本中見到這些對XML處理豐富的技術支援。


微軟陣營

反觀微軟陣營,對XML資料處理的支援,也是不遺餘力的。在最基礎層次的技術方面,微軟提供了MSXML程式介面來支援DOM以及SAX模式的處理。更重要的是,XML在.NET架構中,是擔任多處的基本資料格式,就如上一節中,我們已經討論到ADO.NET是使用XML來當做底層的資料傳輸協定與格式。一般來說,.NET元件在各種不同形態的資料呈現上,都是以XML為其預設的選擇。更有趣的是,在.NET架構下的各項Web服務(.NET Web Service)可以很輕易地輸出XML介面,而以SOAP協定在網路上流通。關於SOAP協定的介紹與各方面的優劣,筆者將在未來幾期中予以介紹。


而由於是使用SOAP協定,.NET架構下的Web服務開啟了許多有趣且實用的應用可能:因為是使用XML當做資料傳輸格式,因此只要是使用SOAP協定的客戶端,無論是Web瀏覽器,甚或是行動式的設備,都可以輕易地使用這些Web服務。


主要的開發架構差異

筆者在前幾節中,已經重點式的就兩大架構功能性的異同,為讀者做分析。但是.NET架構與J2EE架構之間的比較,是個涵蓋許多不同層次的問題。筆者在七月號中曾經就特色上的差異做了介紹與比較,而在八月號中則是針對架構中的各項支援技術做比較。而在本期中,主要是針對一些不同層次的比較進行探討。而在本節中,筆者要討論的是一個根本上的差異,也就是開發模式上的不同,在上期中,我們已經對這方面的討論埋下了伏筆,請參考(表一)與(圖一),在本節中,我們就是要針對這樣的層面,為各位做較為詳細的探討。



《表一  兩大架構實作哲學的差異》
《表一  兩大架構實作哲學的差異》

《圖一  兩大架構開發流程的比較》
《圖一  兩大架構開發流程的比較》

無論是微軟的.NET架構,抑或是昇陽的J2EE架構,都是以最主要的三項基礎做為比較標準:程式開發語言、物件模型、以及虛擬機器平台,而這三項基礎的構成的最主要差異,就是在於執行平台環境的設計目標,以及其上所支援的開發與佈署模式,觀察家與評論家是最容易給出的結論就是:


“J2EE是一種特定語言但不限定平台的架構,而.NET則是一種不限定語言,但是卻有特定平台限制的架構。”


這樣的結論並沒有真正的謬誤,但是似乎過於簡化,原因如下:


  • 1.有多數的J2EE平台實作,仍無法完全保有跨平台的特色。


  • 2.微軟在.NET架構上跨平台的努力未曾終止,微軟已將CLR的格規以及C#語言送交歐洲電腦製造協會(European Computer Manufacturers Association),希望能形成公開的標準。同時微軟也開發出了Linux版本的CLR。



但無論如何,J2EE在規格上仍是跨平台的,而.NET仍是以Windows平台為其主要基礎。


J2EE是一個由核心Java環境中所演化產生的產品,其基礎是放在Java程式語言、Java虛擬機器(JVM)、以及Java核心程式介面(core API)三者上。Java的程式開發模型,是先以Java語言撰寫物件類別,然後被編譯成跨平台的程式位元碼(byte-code)。而這樣的位元碼,必須要符合JVM的規格標準。這些編譯好的位元碼,可以在各式平台上的JVM環境中被解譯與執行,如Solaris、Windows、Linux、AIX等等。在JVM規格中,定義了具有記憶體管理以及安全管理特色的執行期環境。


此外,Java程式碼以及編譯過後的位元碼,更可以再進一步的被編譯成特定平台的機器碼以供執行,或是即時地透過JIT(Just-In-Time)編譯器來進行機器碼的轉換產生。因此,以J2EE來開發,就意味著程式一旦以Java撰寫完成,便可以在跨平台的環境中運作;而對於使用其他程式語言的開發的物件或元件,則可以透過JNI(Java Native Interface)或是CORBA介面來進行處理。整個J2EE的開發模型,可以由(圖二)來表示。



《圖二  J2EE的開發模型資料來源 SD Magazine》
《圖二  J2EE的開發模型資料來源 SD Magazine》

微軟的.NET架構主要是以共同語言執行環境(CLR)為基礎。所謂的CLR環境,主要是由一個與程式語言無關的中介語言程式碼(Intermediate Language code, IL code),以及一個提供記憶體管理與安全管理等等特色的執行期環境所組成。這樣的架構,看上去似乎可以和Java的運作環境形成類比,但兩者之中最主要的差異,是在.NET平台可以用多種支援CLR元件模型的程式語言來進行開發,也就是說,針對這些程式語言,必須開發出相對應編譯器,來將該種程式語言編譯成IL程式碼。這樣的模式,將可以讓各種不同程式語言所開發的元件都轉換到CLR環境中共同合作。請注意,所有IL程式碼都是透過JIT方式轉成Windows平台的機器碼,或是原始的元件程式也可以直接編譯成Windows的DLL或EXE模組,如(圖三)所示。



《圖三  微軟.NET的開發模型 資料來源 SD Magazine》
《圖三  微軟.NET的開發模型 資料來源 SD Magazine》

這兩大架構之間的異同比較,其實會呈現出相當有趣的現象:當我們針對較為基礎性的設計概念比較時,會發現其中每一種比較,都觸及了各自架構中重要的發展概念與策略。舉例來說,Java在設計上是偏向於單一程式設計模型,但是強調與平台無關的特性。昇陽在Java策略上所要強調的,是一旦系統是以Java開發完成,使用者將會有極大的彈性與自由來決定多樣性的支援工具與元件,更可以任意選擇標的運作平台環境。


而反觀.NET架構,微軟所欲強調的,是一個單一的運作平台環境(Windows),這樣的平台環境不但具有與程式語言無關的特性,同時也大量使用XML來支援各式的資料處理特性。微軟強調,一旦系統是在Windows的CLR環境中運作,使用者將會有極大的彈性與自由來決定多樣性的程式開發語言,更可以連結多種元件與Web服務來進行合作,而在合作模式方面則有物件層級的CLR元件連結以及較具彈性的SOAP與XML連結。總而言之,在系統規劃上的各種決策,都會因為整合在同一個Windows環境中而明顯地得到簡化。


策略上的選擇與規劃

在做完上述的討論之後,對決策者規劃企業系統上,又具有什麼樣的意義呢?就概念層次來看,我們都將會得到更好的架構與技術,因為微軟正努力地修正其Web應用環境,以期能與J2EE相抗衡。由此看來,我們將會會有兩種優良的架構平台可供開發選擇;更重要的是,有了這兩個架構的競爭,微軟與昇陽將會更加速致力於改善各自平台中較為不足的地方。例如微軟會努力改善CLR環境在各種不同平台上的運作可能,而昇陽則會加速致力於改善J2EE中XML支援不足的情形。這樣競爭下的成長,對兩大陣營在企業伺服架構的設計哲學上,都將形成正面的影響。


討論至此,您仍須面對架構選擇的決策問題。如果我們將這些技術性的探討做一歸結,我們將會發現決策的路是相當單純的。為什麼單純呢?原因就在於架構設計哲學所造成的影響。如果您所擁有的狀態,是豐富的Windows平台依存性的話(如內部開發,以及客戶的使用上),您將會認為微軟的解決方案是較為合適的作法。反過來看,如果您擁有的是許許多多Web上的應用與元件的話,或許在系統上,一個單一程式語言的開發與整合會較為有利。簡單地說,如果您需要支援許多Unix或非Windows平台的話,J2EE架構將會是項首選;而如果您偏向於使用多種程式語言共同開發系統的話,.NET架構將會是您的最愛。


後記

筆者探討至此,已經涵蓋到這兩大架構的各項議題,同時也就設計哲學與選擇決策上,為讀者做了說明與分析。至於使用者該如何做選擇,則可以依據系統以及環境的特性來進行評估。但筆者要再度強調的是,在技術市場變化快速的前提下,要如何慎選開發彈性與支援廣度,終究會是最重要的考量;而朝向開放式的標準與架構,則應當是決策者在做決策時,必須時時牢記在心的原則與重點。


相關文章
線下服務應用與HTML規範發展
伺服器系統大吹多心風
多核心伺服器處理器架構介紹(下)
多核心伺服器處理器架構介紹(上)
多核風潮下的作業系統
comments powered by Disqus
相關討論
  相關新聞
» 工研院通訊大賽獲獎名單出爐 AI創新應用助2025年通訊業產值破兆
» 宜鼎推出 iCAP Air 智慧物聯空氣品質管理解決方案 透過即時空品數據自主驅動決策
» AI浪潮來襲!伺服器面臨高熱密度挑戰 Vertiv協助矽谷主機代管商在既有機房突破散熱瓶頸
» 英業達捐贈台大高效伺服器 引領學術研究高算力大未來
» 數位部辦理5G專網國際論壇 機械業看好提升短鏈勞動力


刊登廣告 新聞信箱 讀者信箱 著作權聲明 隱私權聲明 本站介紹

Copyright ©1999-2024 遠播資訊股份有限公司版權所有 Powered by O3  v3.20.2048.18.207.160.209
地址:台北數位產業園區(digiBlock Taipei) 103台北市大同區承德路三段287-2號A棟204室
電話 (02)2585-5526 #0 轉接至總機 /  E-Mail: webmaster@ctimes.com.tw