前言

在上期中，筆者針對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則是一種不限定語言，但是卻有特定平台限制的架構。”

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

但無論如何，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》

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

《圖三　　微軟.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架構將會是您的最愛。

後記

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