前言

在上期中，筆者針對J2EE與.NET的運作架構，做了概略性的探討，同時也針對運作架構中的各項組成分子，做了簡要的比較（如程式語言、執行環境、基礎元件集、以及資料存取技術等），請參考(表一)。在本期中，筆者將針對J2EE以及.NET的基礎架構支援技術，做一個全面性的介紹。

《表一　.NET以及J2EE的特點比較》

藉著這些支援技術的對應與比較，可以讓使用者更清楚兩大門派的技術源流，同時也可以藉著一對一的比較，讓使用者更清楚對應技術之間的優劣以及使用場合與時機。

接下來在本文中，筆者將先簡介目前相關業界中使用昇陽與微軟技術狀態概要，以利讀者對業界狀況有最基礎的了解。接著我們便會深入J2EE與.NET的各項基礎架構支援技術，為讀者做一番解釋。而在本文的後半部，我們照例會來一次“捉對廝殺”，將這群技術做對應與比較，並探討各項技術的使用場合與優缺點。接下來，就讓筆者引領各位開始本次的探討之旅。

相關業界所採用的開發技術概況

在了解了業界的探用的開發技術之後，我們便可以開始針對這兩大陣營的基礎架構支援技術，做一個全面性的介紹。除了讓讀者了解的採用技術內涵之外，同時也可以提供開發者在未來採用各項技術的參考。而由於微軟的. NET 架構目前仍處於推展初期，因此尚無法取得市場方面的相關統計。因此本節將就Java應用伺服市場，也就是所謂J2EE應用伺服軟體市場的各項統計資料為開端，進行廣泛的介紹。

根據美國 IDC 公司的統計，北美的套裝應用軟體市場在西元2004年時將會成長為具有1600億美元的規模，這樣的規模是西元1999年的兩倍有餘。同時 IDC 也指出，對於產業的需求來說， ERM（ Enterprise Resource Management ）以及 CRM （ Customer Relationship Management ）的應用將會日益重要，其次則分別為辦公室文件生產以及企業協同運作（ Collaboration ）等兩項應用。就這樣的發展看來，企業應用伺服市場的成長將會逐步擴大（這是由於有 ERM/CRM以及Collaboration 的關係）。因此，企業應用伺服市場實為軟體大廠的兵家必爭之地。

而就企業應用伺服軟體市場層面來看，根據 Giga Information Group的調查指出，企業應用伺服軟體的市場，將於西元2003年到達90億美元的規模（西元1999年時僅為5億8千萬美元，西元2000年為16億4千萬美元），請參見(圖一)。由（圖一）中我們可以知道，如此劇烈成長的市場，將會引來眾多軟體大廠的覬覦。在西元1999年時，應用伺服軟體市場的第一大品牌為BEA Systems，佔有率達32%，其次為IBM的16%以及Sybase的15%，參見(表二)。

《表二　西元1999年應用伺服軟體市場佔有率分布》

《圖一　應用伺服軟體市場成長概況 單位：百萬美元》

而到西元2000年時，由於這個市場引來眾多競爭者的競食，並且在佔有率方面出現了洗牌效應，互有消長。其中BEA Systems的佔有率滑落至24%，而IBM則成長至24%，呈現出兩強鼎立的情形。其後則有ATG（10%）、iPlanet（9%）、Allaire（8%）、SilverStream（5%-7%）以及Sybase（5%-7%），請參考(表三)。

《表三　西元2000年應用伺服軟體市場佔有率分布》

到目前為止，伺服軟體市場的佔有率競賽尚未停止，甚至有許多軟體界的大老正在努力追趕之中（如Oracle等）。因此，在這樣的市場中，競爭熱絡自然可以預見，而技術方面的快速變化與成長，也將會是預料中事。接下來筆者就開始針對J2EE以及.NET的基礎架構支援技術，為各位做廣泛的介紹。

J2EE的基礎架構支援技術

J2EE（ Java2 Enterprise Edition ）是由昇陽公司定義出來的開放性運作架構，這項發明其實部分是源自於某些未經預期的風雲際會：首先，昇陽公司本來想要開發出一個開放式、解譯的、具可移植性的程式語言－Java，而在Java以開放性的姿態推廣散布之後，引來了許多具有高度興趣的開發者參與。伴隨著90年代軟體界對於伺服端運作的元件架構標準化需求漸殷，昇陽公司便決定為這樣的需求，定義出一套以Java為基礎的標準架構，而這樣的生產規劃結果便是我們所熟知的J2EE。

J2EE是由幾項重要支援技術所組成，這些技術涵蓋了數種層面，其中包括Web處理技術、基本元件架構、分散式物件通訊、企業元件架構、交易處理、訊息傳遞、名稱與目錄服務、以及資料庫存取等等，如(圖二)所示。

《圖二　Java元件模型所包含的各項支援技術 資料來源：Middleware》

至於這幾項技術層面各涵蓋了哪些實質的技術呢？以下我們就來探討這個重要的議題。

1.Web處理技術

以往的Web處理技術，都會透過所謂的 CGI （Common Gateway Interface）介面來進行處理，以達到網頁動態產生的目的。這樣的技術，為Web上的資料互動開啟了寬敞的大門，同時也開啟了Web商業運算的無限可能。但隨著軟體技術的進步，以及企業界對於開發速度需求的增加，這樣的支援技術必須不斷的發展成長，才能在應付未來的發展需要。昇陽公司有鑑於此，便以Java平台為基礎，推出了所謂的 JSP ( Java SeverPages )標準，藉由網頁與商業邏輯分離的概念與技術，創造Java世界中的伺服端網頁運算標準。在JSP的運作架構下，所有相關於網頁呈現的處理，都是用Server Page來完成，而後端需要資料存取以及其他商業運算的部分，則是交由 JavaBeans 元件來負責。這樣的分離概念，正符合了所謂 MVC （Model-View-Controller）的運作概念。

2.基本元件架構

在Java的世界中，元件基本上所指的就是所謂的 JavaBeans 。 JavaBeans是一種軟體的組件，用以在軟體開發中扮演“積木”的角色，藉由堆積木的開發方式，可以達到軟體快速成形的目標（fast prototyping）。JavaBeans不但可以加速開發，同時也提供了元件架構的黑盒子特性，讓開發者可以在不需要了解元件細部運作內容的情形下，達到建構大型且複雜軟體的目的。

3.分散式物件通訊

昇陽公司有鑑於物件之間的分散式通訊需求，定義出了所謂的遠端物件方法呼叫（RMI , Remote Method Invocation），提供了分散式物件透過網路進行資料通訊的途徑。後來更根據OMG（Object Management Group）所定義出來的使用物件需求代理架構（CORBA，Common Object Request Broker Architecture）架構，延伸既有的RMI標準，成為所謂的RMI-IIOP（Internet Inter-Orb Protocol），將RMI推向世界標準。

4.企業元件架構

在Java的世界中，所謂的企業元件架構是以企業JavaBeans（Enterprise JavaBeans，EJB）來對應。EJB是一種伺服端的運作架構，其特色包含了網路、物件，以及分散式運算，這樣的技術可以支援企業應用程式的商業邏輯元件開發，同時也支援這些元件在這種伺服架構上的佈設。而物件通訊的特性，則是建立在以RMI與CORBA的架構之上。EJB提供了企業元件執行的基礎架構，使這些元件都能在受到制約的安全環境下運作。

5.交易處理

所謂的交易，就是試圖將應用程式的處理程序，切割成許多細小且連續的工作單元，這樣的工作單元，不會受到外界的其他干擾，且執行結果只有完成（committed）或未執行（roll back）兩種。在Java的世界中，交易處理部份是由JTA/JTS來予以定義。一個JTA（Java Transaction API）交易，就是一個可以透過J2EE平台管理與協調的處理單位。這樣的處理單位，將有能力存取系統中多個元件與資料來源。而所謂的JTS（Java Transaction Service），就是提供JTA服務的交易管理者，它主要就是以OMG的OTS（Object Transaction Service）實作為主要目的，且在其下的交易傳遞部分（transaction propagation）是由IIOP所完成。概括來說，J2EE在交易處理的部分，是定義了一種運作方式，可以大幅簡化在分散式多人使用的企業應用程式裡的開發負擔。

5.訊息傳遞

所謂的訊息傳遞技術，目的是在提供一個非同步的訊息收發機制。在Java的世界中，這樣的工作是JMS（Java Message Service）來完成。在JMS中，一個特定的商業活動訊息，可以得到完整的描述與定義，而透過訊息的交換，應用程式將可以追縱企業運作的過程。JMS的支援的訊息位遞方式，主要有點對點（point-to-point style）以及公佈/訂閱（publish-subscribe style）兩種方式。

6.名稱與目錄服務

J2EE中對名稱與目錄支援主要是透過定義JNDI（Java Naming and Directory Interface）介面來完成。一個實作JNDI介面的軟體，將有能力提供企業應用程式標準的目錄運作，如物件屬性的關聯、以及透過物件屬性的搜尋等等。使用JNDI之後，企業的應用程式將可以存取任何型態Java所命名的物件，同時JNDI也可以用來整合各種知名的目錄服務（如LDAP、NDS、DNS、NIS...等），達到與傳統應用程式或系統共存的目的。

7.資料庫存取

在 Java 的世界中，所謂的資料庫存取是透過所謂的 JDBC （Java DataBase Connectivity）介面來完成。JDBC提供了與資料庫無關的連結方式，讓應用程式可以使用各種不同類型的資料來源，同時透過J2EE的整合，新的JDBC可以與JNDI通力合作，同時也可以與交易處理密切配合，更可以透過J2EE內部的資源管理（connection pooling）來提升資料存取方面的效能。

在了解了J2EE各項基礎架構支援技術之後，接下來我們就來檢視一下，在.NET架構中，會有哪些相對應或是類似的支援技術。

.NET的基礎架構支援術

.NET 是由微軟公司定義出來的分散式運作架構。由於.NET架構的出現，讓大家對微軟與昇陽的競爭關係上，又增加了一分聯想。有許多觀察家與評論家認為，如果當初微軟的分散式網路架構（DNA, Distributed interNet Application architecture）技術夠成熟穩定的話，今天就應該不會有.NET架構的出現。但是可以理解的是，.NET絕對不會只是那些DNA元件的重新包裝而已，相反地，微軟對.NET的期許，應該是一個全新的開始。但無論如何，在.NET平台架構下，也有許多Windows DNA的影子，如(圖三)所示。(圖三)所說明的是Windows DNA的物件架構。

《圖三　Windows DNA元件模型所包含的各項支援技術 資料來源：Middleware》

至於.NET中的幾項技術層面，是由以下幾項實體技術所共用建構而成。以下我們就來探討這些基礎技術：

1.ASP+

這是新一代的ASP技術，主要的用途是增強原ASP既有的功能。ASP+讓軟體開發者有能力在伺服端去撰寫敘述式的程式，並具有編譯成為位元程式碼的特性。而其後端是使用微軟的ISAPI介面來與伺服器溝通，進而產生動態的網頁輸出。

2.ActiveX

所謂的ActiveX元件，就如同JavaBeans一般，是可以在客戶端環境運作的元件單位。基本上來說，一個ActiveX控制元件，就是由COM元件所延伸進化而來的。

3.DCOM

這就是微軟所定義出來的分散式物件架構。在這樣的架構下，軟體元件將有能力可以在不同的實體平台上移動。同時藉著定義遠端物件溝通的協定，軟體系統將可以以類似Java中遠端物件方法呼叫（RMI）的形式，來啟動遠端物件的程序。在DCOM技術的引導下，物件的介面與實作部分將會以分離的形式存在，並且具有與程式語言無關的特性。

4.MTS/COM+

微軟的 MTS 技術（Microsoft Transaction Server）主要是要合併兩項重要的功能：一是交易處理監看機制，另一則是物件需求代理機制，這兩大部分都是為了處理伺服端的軟體元件而設計。而COM+則是DCOM與MTS的下一步進化，允許更快速且方便地建立具高度可重複利用屬性的伺服端軟體元件。

5.DTC

這是微軟開發出來用在分散式交易環境下的協調伺服器。就如何Java的交易服務定義一般，DTC（Distributed Transaction Coordinator）可以用來支援應用服務所需的交易特性，針對這些需求而形成一個提供交易服務的基礎構。這樣的功能，正好與OMG的OTS以及昇陽的JTS形成強烈的對應。

6.MSMQ

這是微軟用來解決訊息處理需求的方案。MSMQ（MicroSoft Message Queue）實作了元件之間的非同步訊息傳送機制，並以佇列（queue）的方式來安排處理順序。這部分的功能，正好類比於CORBA架構中的動態程序啟動介面（DII , Dynamic Invocation Interface）。

7.ADSI

微軟的 ADSI （Active Directory Services Interface）是一種目錄與名稱服務的介面定義，可以用來針對網路上的特定資訊進行存取，如使用者、電腦，以及其他相關的資源。在這樣的介面定義下，應用程式將可以運用一個統一化的運作介面來操作如企業中多項的名稱與目錄資料。在CORBA架構下，這樣的服務則是以COS Naming （CORBA Object Services Naming）服務來完成。

ADO+

這是微軟在.NET平台下用來關聯式資料庫進行存取的部分。這部分的功能，主要是源自於早期的ODBC（Open DataBase Connectivity）介面，進而演化為OLE/DB（Object Linking and Embedding for DataBase），最後才形成ADO（Active Data Object）介面。

在了解了.NET中各項基礎架構支援技術之後，各位讀者所感興趣的比較即將開始。筆者將會針對以上所提的各項技術，做一個適當的對應，以期使用者可以清楚了解技術之間的對應關係。

支援技術大比較：J2EE vs. .NET

在開始以下的比較探討之前，讓我們再回顧一下會形成這些比較的大環境。由這樣的背景環境中，我們就可以知道，競爭為何而來，以及技術演進的動力。

微軟以及其Windows產品一直是桌面軟體產品市場上的常勝軍。在Java出現之際，有許多觀察家認為昇陽將有能力撼動微軟的大片江山。但是在微軟的競爭策略上，認為與其浪費資源在建立Windows的模擬環境，以期能與Java的跨平台特性相較，不如針對Windows平台做重要的進步與演化，可能要來得更具影響力與號召力，同時也可以減少建立不相容性的可能。但是就昇陽的Java陣營來看，以Java具有優良的分散式特性來說，配合上跨平台特色，將可以在伺服端軟體市場受到強烈的歡迎。因此，在市場的區隔上，微軟的確比較長於桌面軟體，而昇陽也的確比較長於伺服端軟體。

但是這一陣子以來，情況逐漸有了變化，微軟在伺服端軟體市場上逐漸開始著力，由原先發表但未見看好的DNA架構，逐漸演化成為即將大展身手的.NET架構。對於伺服端技術的整合，微軟用盡心思，以期能在伺服市場中佔有一席之地。在這山雨欲來之際，正好給了我們一個機會，好好地檢視這兩大陣營的伺服軟體架構。同時也藉由這個比較，體會一下兩大軟體巨人的用心。昇陽將其整合過後的JPE（Java Platform for the Enterprise）正式更名為J2EE，而微軟也將其整合並提升過後的DNA（Distributed interNet Application architecture）正式更名為.NET架構，以下就是各項支援技術的比較。

後記

.NET與J2EE 在技術架構的相似度上似乎蠻符合觀察家與評論家的預期，是具有同質性、市場重疊性的伺服產品。在實作的哲學上，儘管兩大陣營的看法不同，請見(表四)與(表五)。但在對伺服器市場的雄心上，卻是沒有二致的。因此，就讓看倌們繼續保持注意，看市場大餅旁落誰家吧。

《表四　　.NET架構與J2EE架構支援技術比較表》

《表五　兩大陣營的實作哲學》