理解企業平臺

Microsoft Corporation

摘要：包括兩部分。第一部分是介紹在有經驗的 J2EE 開發人員看來 .NET 是什麼樣子的。它把 .NET 概念與您已經理解的原理結合起來，說明了兩個平臺的不同與相似之處。本章的第二部分是鏡像，提供的信息是相同的，但只針對有經驗的 .NET 開發人員。爲您介紹了 J2EE 的企業特性，並解釋了 Java 應用程序是如何在分佈式環境中工作的。

簡介

本章爲有某種平臺開發經驗但沒有接觸過這種替代技術的開發人員簡要介紹了背景情況。這不是一本培訓手冊，但結合您已瞭解的其他環境，可以幫助您理解某種環境的基本概念。

Microsoft 平臺和 Sun 平臺之間的競爭就如 Apple 用戶界面的擁護者和 Windows 的支持者之間的競爭一樣根深蒂固。但是，公司業務不斷增長的現實情況是：公司執行組件使用的是最能滿足他們要求的平臺，而不是固守這種或那種特殊的意識形態。

作爲一個 J2EE 開發人員，在其職業生涯中根本不接觸 Microsoft .NET 的機會越來越少了。實際上，對於僱主來說，同時精通 .NET 和 J2EE 是一件非常有吸引力的事情。同樣，如果您是一位 .NET 開發人員，但沒用過 Java，則本章的第二部分可以幫助您理解 J2EE 平臺的功能。此外，這並不是一本參考書，而是試圖把 J2EE 領域的概念與您已有所瞭解的 .NET 概念關聯起來。

注如果您是一位有經驗的 Microsoft .NET 開發人員，請轉到“J2EE 基本原理（針對 .NET 開發人員）”一節。

本章末的彙總表列出了 .NET 和 J2EE 的等效組件。

Microsoft .NET 基本原理（針對 J2EE 開發人員）

Microsoft .NET 的名稱反映了 Microsoft 將重心重新調整爲 Internet 上的操作和分佈式應用。Microsoft .NET 由三個主要部分組成：

•	一種與語言無關的應用環境，可以優化分佈式操作.NET Framework。
•	一種可以使用幾種 Microsoft 語言編程的開發環境Visual Studio .NET。
•	支持分佈式環境和 .NET Framework的操作系統Windows Server System。

最初是想將 .NET 實現爲有如下特點的一種統一體：

•	與語言無關的編程。
•	企業級可擴展性和可靠性。
•	集成安全性。
•	易於實現。
•	分佈式操作。
•	支持開放標準。
•	可靠的操作和可管理性。
•	強大的調試工具。

.NET 與 J2EE 對比

在經驗豐富的 Java 開發人員看來，.NET 可能與 Java 平臺很相似，它們都提供了一種創建應用程序的結構化方法，都有編譯爲中間代碼的語言，都爲應用程序開發提供了一個大型 API 庫。的確，許多 Java 領域評論員已經指出，從 J2EE 到 .NET 的概念跳躍似乎要比從 Windows DNA 到 .NET 的概念跳躍幅度小一些。但實際上，.NET 的核心有一套與 Java 平臺不同的目標。

Java 包括 Java 平臺（運行庫與 API）和 Java 語言。Java 平臺的用途是支持用 Java 語言編寫並被編譯爲 Java 字節碼的應用程序。儘管進行了許多試圖將其他語言編譯爲 Java 字節碼的工作，但是這些工作大部分都是學術活動。Java 的一貫思想就是在多種操作系統上使用一種語言。

.NET 包括 .NET Framework（運行庫間與 API）和支持的多種編程語言。.NET Framework 的目標就是支持用任何語言編寫並且被編譯成 Microsoft 中間語言 (MSIL) 的應用程序。.NET 的目標是“多種語言共享一種平臺”。

研究 .NET Framework

瞭解 .NET Framework 以及它爲基於 .NET 的應用程序提供的服務非常重要。

注 .NET 的應用或者基於 .NET Framework 的應用都指的是使用 .NET Framework 的應用。爲簡單起見，本書使用了一些基於 .NET 的應用。

.NET Framework 包括的類庫爲數據訪問、安全性、文件 I/O、XML 操作、消息傳遞、類反射、XML Web 服務、ASP.NET 和 Microsoft Windows 服務在內的各種任務提供了支持。

注有時會對比 .NET Framework 和 Java 2 SDK，但二者卻不是完全對等的。

.NET Framework 的核心部分就是支持 XML 網絡服務。這項技術既是一種方法，也是在不同計算機、不同網絡及不同操作系統的組件之間傳遞信息的傳輸層。

圖 2.1 說明了 .NET Framework 的主要組成部分。

圖 2.1依賴 CLR 的 .NET Framework 組件

.NET Framework 作爲組件可以自由重新發布，它包括工具、類以及 API 支持以運行基於 .NET 的應用程序。希望運行基於 .NET 的應用程序的計算機上必須要安裝有 .NET Framework。

Windows XP Service Pack 1 包含有 .NET Framework 1.0 版，Windows?Server 2003 帶有 .NET Framework 1.1，它們是操作系統的一部分。對於較早的 Windows 版本，您可以從 MSDN Web 站點下載 .NET Framework 您也可以從 Windows 更新服務安裝 .NET Framework。

注 .NET Framework SDK 中包含有可重新發布的 .NET Framework 包。

有多種方法可以將 .NET Framework 安裝到客戶端計算機上。可以把可重新發布的 .NET Framework 包解壓爲 .msi 文件，這樣您（或者您的網絡管理員）隨之就可以利用 Active Directory 組策略將其分發。較大的企業也可以利用系統管理服務器來分發此包。較小的公司可以選擇軟件更新服務 (SUS) 來將 .NET Framework部署到 Windows 2000 客戶端上。開發人員可以將可重新發布的包包含到 Visual Studio .NET 的編譯輸出中，添加可以檢測客戶端上是否有 .NET Framework 的例程，如果需要還可以安裝或更新 .NET Framework。

公共語言運行庫

公共語言運行庫 (CLR) 是 .NET Framework 的核心組件。CLR 爲承載和運行基於 .NET 的應用程序提供核心功能。 CLR 的主要功能如下：

•	實時 (JIT) 編譯成本機代碼。
•	跨語言集成。
•	內存管理與垃圾回收。
•	託管代碼操作。
•	實時調試。
•	異常處理。
•	安全性。
•	運行時類型安全檢查。
•	線程管理。

注儘管有一些不同之處，但仍可將 CLR 看作是實現 Java 虛擬機 (JVM) 的作用。

實時 (JIT) 編譯成本機代碼

當部署並運行應用程序時，JIT 編譯器要快速檢查平臺的規格。例如，編譯器將要檢查的方面包括處理器的類型與數量、內存等。然後 JIT 編譯器編譯應用程序，生成 執行環境 下的機器代碼。這就是 JIT 編譯過程。

注 .NET Framework 中的 JIT 過程類似於 JVM 的運行時編譯器。

Windows NT 4.0 之後的 Windows 版本僅支持 x86 環境，這經常會使人們感到困惑：他們爲何要爲在 x86 平臺上直接編譯 MSIL 的正確步驟而煩惱。但是，基於 x86 的計算機並不都一樣，MSIL 的使用爲將來的操作系統開發提供了最大限度的靈活性。

JIT 編譯考慮了這樣的事實：一個應用程序在執行期間可能不會調用所有的程序代碼。執行期間，不是使用處理器時間和內存來將可移植可執行文件 (PE) 中所有的 MSIL 轉換爲本機代碼，而是在需要時才轉換 MSIL，並存儲得到的本機代碼以備隨後的調用可以訪問它。當加載某類型時，加載程序爲該類型的每個方法創建與附加一個 stub。最初調用該方法時，stub 將控制權傳遞給 JIT 編譯器，它將該方法的 MSIL 轉換成本機代碼，並將該 stub 更改爲直接在本機代碼的位置執行。隨後調用 JIT 編譯的方法時就直接調用先前生成的本機代碼，減少了花在 JIT 編譯和運行代碼上的時間。

JIT 操作的效果就是，首次執行應用程序時啓動應用程序花費的時間稍微長一點。但是，執行對該 JIT 方法的第二次和以後的調用時的速度就會比預編譯的應用程序快，這是因爲 JIT 組件返回了先前生成的本機代碼，對該計算機進行了適當的優化。

運行庫提供了另外一種編譯模式，稱爲安裝時代碼生成。與常規的 JIT 編譯器一樣，安裝時代碼生成模式將 MSIL 轉換成本機代碼，但每次轉換的代碼單元較大，並存儲得到的本機代碼以備隨後加載和運行程序集時使用。利用安裝時代碼生成模式，安裝應用程序將完整的程序集轉換成本機代碼時，考慮了關於當前已安裝的所有程序集已知的信息。得到的文件其加載與啓動速度比用標準 JIT 選項轉換得到的本機代碼的速度要快。

跨語言集成

當得知 CLR 只支持一種類型的代碼時，您也許會感到奇怪。您也許會說，上一頁宣稱的與語言無關是什麼意思呢？答案是，CLR 只支持 MSIL。靈活之處在於任何支持 .NET 的編程語言都能夠產生 MSIL 輸出。這就是與語言無關的緣由。您可以用下面的一種或多種語言創建基於 .NET 的應用程序：

•	託管 C++（這裏不足爲奇）
•	C# （類似於 Java 和 C++ 的 C Sharp 鈥_）
•	Visual Basic .NET
•	J# （允許爲 .NET 平臺編寫 Java 代碼的 J Sharp）
•	FORTRAN
•	Pascal
•	COBOL
•	PERL
•	Python
•	Eiffel

事實證明，C# 已經成爲經驗豐富的 Java 開發人員和那些 .NET 平臺新手的普遍選擇，因爲它與 Java 編程語言有許多相似點。J# 提供了一個 Java 語言子集，它可以編譯成 MSIL 並在 CLR 上運行。但是，不管使用哪一種語言，編寫完代碼後，編譯器都將其轉成 MSIL。

注如果您是一個受虐狂（或者僅樂於用機器代碼編程），您可以直接用 MSIL 編寫。但是，因爲 MSIL 是一種僞機器代碼，所以這不是一種完全直觀的方法。

內存管理與垃圾回收

CLR 的內存管理的核心是垃圾回收進程，它類似於 Java 中對應的進程。垃圾回收是一種後臺操作，它對提交給內存的對象進行審查，並恢復那些不再需要的對象。垃圾回收分三代，可以恢復短期、中期、長期對象，分別稱爲 Gen 0、Gen 1 和 Gen 2。

所有的新對象都在 Gen 0 堆中開始。垃圾回收算法通過檢查堆中是否有應用程序不使用的任何對象而起作用。

注許多類爲其返回值、臨時字符串以及各種其他實用工具類（如枚舉器等）創建臨時對象。

如果堆中沒有足夠的空閒內存分配給新對象，垃圾回收循環就從 Gen 0 對象開始。如果內存仍然不夠，垃圾回收循環就回收 Gen 1 對象，然後是 Gen 2 對象。當垃圾回收處理了所有代的對象時，就是一個完整的垃圾回收循環。

當垃圾回收循環在運行時，它將所有幸存的對象都提升到下一代。之所以說垃圾回收循環後倖存對象是因爲這些對象仍然在使用（可以訪問）或者在等待結束。倖存的 Gen 0 對象提升爲 Gen 1，而倖存的 Gen 1 對象則提升爲 Gen 2。然後垃圾回收處理壓縮並移動任何空閒的內存，以保存鄰近的空間，將內存碎片的數量降到最低。與下一代相比，每代的垃圾回收循環發生的比例一般是 1:10，例如，進行 10 次 Gen 0 回收就進行一次 Gen 1 回收，進行 10 次 Gen 1 回收就進行一次 Gen 2 回收。

注就係統資源來說，較高等級的垃圾回收，花費的開銷越高 — 垃圾回收器期望得到更高的小費（開個玩笑）。

託管代碼操作

.NET Framework 的第四大功能是託管代碼操作。託管代碼的定義非常簡單 — 託管代碼使用 CLR，而非託管代碼不用。爲了使該定義更嚴密，應這麼說：託管代碼完全在 CLR 內部執行。對非託管組件的調用（服務組件、COM 或 DCOM 對象）超出了 CLR 的範圍。因此，CLR 垃圾回收和其他功能不對非託管代碼或非託管代碼組件進行操作。

實時調試

實時調試 (JIT) 是一種調試在 Visual Studio 外部啓動的程序的技術。如果已經啓用 JIT 調試，當發生故障時程序就會彈出一個對話框。該對話框會詢問是否想調試該程序並且要使用哪一種調試器。

在發生異常時，JIT 調試可以靈活選擇調試器。還可以在工作計算機的複製品計算機上調試，這有助於更快地找出編程問題。

異常處理

CLR 處理 .NET Framework 應用程序中的異常，但還提供一些異常管理函數。這其中的主要一個就是 Try/Catch/__Finally，使用這些塊可以捕獲託管異常和非託管異常。基本的方法就是，在要進行危險操作時使用一個 Try 子句，如果 Try 語句中的函數引起一個異常，就要配對使用一個 Catch 子句。不管異常是否發生都要運行 __Finally 子句。

安全性

CLR 通過使用 XML 格式的配置文件或者 .NET Framework 1.1 配置工具 (Mscorcfg.msc) 的運行庫安全策略節點來執行應用程序，從而實現安全性。安全配置文件包含有有關代碼組層次和與策略級別相關的權限集的信息。

.NET Framework 配置工具顯示有三種主要的安全配置級別：企業、機器或用戶。這些級別對應三個安全配置文件（Enterprisesec.config，以及計算機和用戶級別的兩個獨立的 Security.config）。

.NET Framework 配置工具使您可以管理權限集（例如，FullTrust，LocalIntranet，Everything 等等）和代碼組，例如，My_Computer_Zone，LocalIntranet_Zone，Trusted_Zone，等等。每個代碼組都有一個相關的權限集，例如，Trusted_Zone 會映射到 Internet 權限集。

滿足代碼組成員條件的程序集接收權限集中相關的權限。權限集可能會包括應用程序是否可以訪問 File Open 對話框，是否能夠打印，或者可以顯示什麼樣的用戶界面。

雖然可以直接編輯安全配置文件，但強烈建議您使用 .NET Framework 配置工具或者代碼訪問安全策略工具 (Caspol.exe) 來修改安全策略。這樣可以確保更改策略時不會破壞安全配置文件。

運行時類型安全檢查

.NET Framework 還通過運行時類型安全檢查實現安全性。利用類型安全代碼，公共語言運行庫可以完全將程序集相互分離開來。這樣的分離有助於確保程序集相互之間不會有不利的影響，提高了應用程序的可靠性。即使類型安全組件的信任級別不同，它們仍可以在同一個進程中安全地執行。

類型安全代碼只能訪問授權其訪問的位置的內存。例如，類型安全代碼不能從另一個對象的私有字段讀取數值。它只能以明確定義的、允許的方式訪問類型。

雖然類型安全驗證沒有要求必須運行託管代碼，但是類型安全在程序集隔離和安全實現方面起着非常重要的作用。如果代碼類型不安全，則會產生不希望的副作用。例如，運行時不能防止不安全代碼調用本機（非託管）代碼並進行一些惡意的操作。當代碼類型安全時，運行時的安全實現機制確保了它只有擁有權限訪問本機代碼時才能訪問。

在進行 JIT 編譯期間，一個可選的驗證進程對被實時編譯爲本機代碼的方法的元數據與 MSIL 進行檢查，以驗證它們是否是類型安全的。

線程管理

公共語言運行庫主要通過 ThreadPool 類支持多線程應用程序。ThreadPool 可以爲大多數任務提供自動的線程創建和管理機制。

公共類型系統

公共類型系統 (CTS) 定義了運行庫中應用程序和 .NET Framework 如何聲明、使用和管理類型，同時也是運行庫支持跨語言集成的一個重要部分。正是有了 CTS 才使得大型開發人員團隊可以致力於同一個應用，團隊中的每個人可以使用 .NET Framework 支持的多種語言中的任何一種進行編程。

CTS 可執行下面的功能：

•	建立一個框架，可以進行跨語言集成、類型安全並可執行高性能代碼。
•	提供一個面向對象的模型，完全支持多種編程語言。
•	定義語言必須遵循的規則，這有助於確保以不同語言編寫的對象可以彼此進行交互。

託管代碼操作通過 CTS 實現類型安全，因此 CTS 確保了所有的基於 .NET 的應用組件可以進行自我說明。然後，.NET Framework 處理託管代碼組件間的引用。

全局程序集緩存

安裝 .NET Framework 創建一個機器範圍的代碼緩存，稱爲全局程序集緩存。全局程序集緩存存儲特別指定爲計算機上幾個應用程序所共享的程序集（可執行文件或庫文件）。結合強名稱工具，它還能夠允許運行具有相同名稱的兩個或更多個版本的程序集。這樣運行時對程序集的選擇控制權就比使用 CLASSPATH 語句時大得多。

有兩種版本的全局程序集緩存 — MSCORWKS 是工作站版本，它運行在 Windows XP 與任何可以安裝 .NET Framework 的桌面操作系統上。MSCORSVR 是 Windows 2003 Server 系列必備的一部分，而它是作爲 Microsoft 的其他服務器操作系統上的 .NET Framework 的一個組件安裝的。MSCORWKS 對於單用戶的基於 .NET 的應用程序運行得最好，但 MSCORSVR 適用於大型、多處理器、多用戶的環境。

通常情況下，可以將應用程序的程序集放置在該應用程序的安裝目錄中。但是，也許會希望多個應用程序使用同一個程序集，這時可以將程序集放置在全局程序集緩存中，而不是將其複製到兩個不同的目錄中。

注在將程序集放置到全局程序集緩存之前，必須利用強名稱工具對程序集進行簽名。

有幾種方法可以將程序集部署到全局程序集緩存中：

•	利用爲全局程序集緩存設計的安裝程序。這是推薦使用的方法。
•	利用稱爲全局程序集緩存工具 (Gacutil.exe) 的開發人員工具，它是 .NET Framework SDK 的一部分。
•	利用 Windows 資源管理器將程序集拖入緩存中。

有關將程序集部署到全局程序集緩存中的最佳實踐的更多信息，請參閱 MSDN Deploying .NET Framework-based Applications。

強名稱

通過利用強名稱工具 (SN.exe) 對每個代碼組件進行數字簽名，.NET Framework 提高了安全性。強名稱程序集包括程序集的標識 — 其簡單的文字名稱、版本號和區域信息（如果有的話）— 連同一個公鑰與一個數字簽名。

通過創建強名稱程序集，可以支持全局程序集緩存中的多個具有相同名稱的 DLL。而後應用程序只使用其安裝的 DLL 版本，解決了普遍存在的 DLL 衝突問題。利用強名稱程序集使得同時安裝新版本的程序集和舊版本的程序集成爲可能，而不會發生衝突。

注爲了避免對沒有強名稱程序集的依賴，強名稱程序集只能引用其他強名稱程序集。

.NET Remoting

.NET Remoting 是 Microsoft 分佈式應用程序的新型通信機制，這些分佈式應用程序構建於 .NET Framework 之上。.NET Remoting 的功能類似於 J2EE 中的遠程方法調用 (RMI)。

.NET Remoting 使得可以輕鬆構建大範圍的分佈式應用程序，而不管應用組件是都位於一臺計算機上還是分佈在全球不同的地方。利用 .NET Remoting，就可以構建使用同一臺計算機或者其網絡上可訪問的任何其他計算機上的其他進程的對象的客戶端應用程序。利用 .NET Remoting 還可以與同一進程的其他應用程序域進行通信。

.NET Remoting 提供了一種進程間通信的抽象方法，它將遠程對象從特定的客戶端或服務器應用程序域和特定的通信機制中分離出來。因此，可以進行輕鬆、靈活的自定義。可以用另一種通信協議替代某種通信協議，用另一種序列化格式替代某種序列化格式，而無需重新編譯客戶端或者服務器。另外，遠程系統並不採用特定的應用模型。可以從 Web 應用程序、控制檯應用程序、Windows 服務程序 — 從幾乎任何您想使用的應用程序進行通信。遠程服務器也可以是任何類型的應用程序域。任何應用程序可以承載遠程對象，並可以將其服務提供給計算機上或者網絡上的任何客戶端。

爲了利用 .NET Remoting 來構建這樣的應用程序：其中的兩個組件可以跨應用程序域邊界進行直接通信，您只需要構建如下幾項：

•	一個遠程對象。
•	一個偵聽該對象請求的宿主應用程序域。
•	一個請求該對象的客戶端應用程序域。

即使在複雜的多客戶端/多服務器應用中，您也可以這樣看待 .NET Remoting。您還必須配置宿主和客戶端應用程序以連接到遠程的基礎結構中，您必須瞭解遠程基礎結構帶來的生命週期與激活問題。

構建基於 .NET 的應用程序

有幾種方法可以編寫和構建基於 .NET 的應用程序。最主要的幾種方法如下：

•	利用 Visual Studio .NET 編寫和構建應用程序。
•	利用您喜愛的開發環境和命令行編譯器。
•	利用文本編輯器和命令行編譯器。

使用 Visual Studio .NET 2003

Visual Studio .NET 2003 是 Microsoft 的應用開發環境的最新版本，它與 MSDN Library for Visual Studio .NET 一起安裝。Visual Studio .NET 完全符合語言中性的方法，使得用不同語言創建互用性項目變得非常輕鬆。它爲不同項目提供內置的模板，這取決於您希望使用的語言。項目類型包括如下的類型：

•	基於 Windows 窗體的應用程序。
•	ASP.NET Web 應用程序。
•	ASP.NET Web 服務。
•	類庫。
•	控制檯應用程序。
•	Windows 服務。

另外，Visual Studio 還可以將應用程序打包以進行分發，創建 Windows 安裝程序包，CAB 文件，以及安裝例程。

利用命令行編譯器

利用 Visual Studio .NET 創建基於 .NET 的應用程序沒有什麼要求條件，瞭解這一點後您也許會非常高興。另一種方法是利用 .NET Framework SDK 中的命令行編譯器，該方法與使用 JAVAC 和 J2SE SDK 創建的方法類似。

您可以從 SDK Web 站點下載英文版的 .NET Framework SDK v1.1。

安裝 .NET Framework SDK 時，將會創建 %WINDIR%/Microsoft.NET/Framework/versionnumber 目錄，這裏versionnumber 等於：.NET Framework 1.0 版時爲 v1.0.3705，.NET Framework 1.1 版時爲 v1.1.4322。在該目錄中，可以找到下面的命令行編譯器：

•	用於 C# 應用程序的 CSC.EXE。
•	用於 Visual Basic 的 VBC.EXE。
•	用於 J# 的 JSC.EXE。

利用正確的命令行開關運行編譯器生成一個或多個程序集，而後 CLR 可以執行這些程序集。通常，程序集是 .exe 或者 .dll 文件。

注利用包含在 .NET Framework (SDK) 中的 Ildasm.exe 反彙編程序工具，可以檢查 .exe 或者 .dll 文件的內容。

.NET 程序集包含有描述性元數據，例如 Windows 可移植可執行文件頭、程序集依賴項以及版本信息。但是，Java 中沒有可直接與程序集進行比擬的東西。最貼近的可比擬對象就是 JAR 文件，它包含存儲元數據的類，並且可以與其他 JAR 文件進行交叉引用信息而不需要 CLASSPATH 值。

利用全局程序集緩存查找程序集

.NET Framework 不使用類似 CLASSPATH 的變量，而是使用先前提到的全局程序集緩存。每臺計算機上都有全局程序集緩存，它既是一個文件夾又是一個註冊組件數據庫。該文件夾位於 %WINDIR%/ASSEMBLY 下面，並可以用 Gacutil.exe 註冊一個程序集。

注當在 Visual Studio .NET 中創建安裝包時，要包含註冊處理並作爲安裝的一部分。

要查看全局程序集緩存，請完成下面的步驟。

要檢查全局程序集緩存

1.	單擊 Start，指向 All Programs，指向 Administrative Tools，然後單擊 Microsoft .NET Framework 1.1 Configuration（或者 1.0）。就會出現 .NET Configuration 1.1（或者 1.0）管理控制檯。
2.	雙擊左邊窗格中的 Assembly Cache 節點。
3.	在右邊的窗格中，單擊 View List of Assemblies in the Assembly Cache 鏈接。就會出現已註冊程序集列表。
4.	右鍵單擊某個程序集，然後單擊 Properties。將顯示 Assemblyname Properties 對話框。

Version 值允許同時有多個版本存在，並允許組件，例如可執行文件，調用某特定的 DLL。版本號的格式如下：

MajorVersion.MinorVersion.BuildNumber.Revision

例如，7.0.5000.0 是一個 Microsoft.VSDesigner 程序集的公用版本號。

Public key token 是進行代碼簽名後獲得的結果，它唯一標識每個程序集。這就確保了應用程序只能加載正確的程序集，防止惡意或者無意替代應用程序的組件。

理解特性

特性是大多數 Microsoft 軟件組件的一個特點，例如 COM 中的界面定義語言 (IDL) 界面，因此這些出現在 .NET Framework 中也就不足爲奇了。Java 2 SDK 的當前版本不支持特性，儘管擬議中的 Java 2 SDK 1.5 聲稱支持類似特性的結構。有關詳細信息，請參閱：

•	JSR 175: A Metadata Facility for the Java Programming Language
•	New Language Features for Ease of Development in the Java 2 Platform, Standard Edition 1.5: A Conversation with Joshua Bloch

.NET Framework 中的特性既有關鍵字，還有類似標記的元素。在設計時，利用標記來記錄類型、字段、文檔類和方法。程序集的元數據包含有特性信息。 .NET Framework 中的許多標準命名空間都包含有特性，如果需要，開發人員可以實現他們自己的自定義特性。

特性的一個實例就是 WebMethod。該特性指出，可以將類內的方法作爲一項 XML Web 服務調用。如果將 WebMethod 標記放置在方法的開頭，然後編譯器就會生成額外的信息，以將該方法公開爲一項 XML Web 服務。

下面的幾行代碼簡單地說明了這一點。

[WebMethod] 
public String HelloWorld() 
{ 
    ... 
}

特性可以接受參數，參數是作爲標記的一部分。這類似於構造函數類。

[WebMethod(Namespace="http://www.microsoft.com/Interoperability")]

這將 WebMethod 特性的命名空間屬性指定爲指定的 URL。

注 CLR 支持任何語言的特性，但是開發語言格式決定了標記的前綴。

創建 Web 應用程序

在 Java 中，可以利用 JSP 頁和 servlet 創建 Web 應用程序。在 .NET 中，可以利用最新的 Active Server Pages (ASP) 成果即 ASP.NET 來創建。通常情況下，ASP.NET 應用程序將運行在Internet 信息服務 (IIS) 之上，但是這一點並不是一條非常嚴格的要求。例如，也可以在諸如基於 Apache 2.0 的 Enterprise Ready Server 的平臺上運行 ASP.NET 應用程序。

ASP.NET 比 JSP 的功能有所改善，具有諸如代碼隱藏和事件驅動 Web 控件的功能。爲在 JSP 中實現等同的功能，需要腳本語言和一套額外的工具。根據既熟悉 Java 又熟悉 .NET 的開發人員的體驗，ASP.NET 比 JSP 更強大，它比早期的 ASP 更好。JavaServer Faces 的引入只是爲了彌補 JSP 的不足。

ASP.NET 應用程序往往有圖形化前端，因此開發人員往往偏愛使用 Visual Studio .NET 來創建和編輯 ASP.NET 頁。另外一種免費的集成開發環境 (IDE) 是 Web Matrix，可以從 ASP.NET Web 站點下載。

可以用 .NET Framework CLR 支持的任何語言創建 ASP.NET Web 應用程序。這就爲用任何語言編程提供了靈活性，甚至可以通過組合團隊開發人員用不同語言構建的元素來創建Web 站點。

承載組件

.NET Framework中沒有直接與 EJB 對等的工具。但是，有三種主要的技術可用來爲企業應用程序提供寄宿的組件：

•	作爲一項 Windows 服務而運行。
•	通過 IIS 承載。
•	利用組件服務。

作爲一項 Windows 服務而運行

Windows 服務（或者叫 NT 服務）是運行在計算機上的系統級進程，它與登錄的用戶無關。典型的服務包括操縱系統的功能、計劃程序、病毒掃描程序、數據庫引擎和網絡組件。

可以利用 Visual Studio .NET 中的模板來獲取 .NET 程序集，並作爲一項服務來運行。這樣就生成一個應用程序，只要計算機在運行，該應用程序就也在運行。

注作爲服務運行的應用程序需要處理其自身的網絡配置。特別是，這些應用程序應當在域帳戶下運行，而不是在本地機器帳戶上運行。這是因爲本地機器帳戶只擁有本地計算機的權利。

通過 IIS 承載

Internet 信息服務提供了一個可以承載表示層和業務層組件的框架。利用一個與程序集相關的配置文件，可以在 IIS 內爲如下的幾項配置支持：

•	部署程序集。
•	處理輸入連接。
•	支持協議。
•	實現連接池。
•	配置安全性。

另一種方法是構建自己自定義的框架來承載程序集。但是，這是一項非常耗時與麻煩的工作。

利用組件服務

在 IIS 上承載程序集非常簡單方便，但是它不能提供 EJB 所具有的全部功能。組件服務（或者稱作 COM+）提供了另外的功能，例如：

•	回收
•	狀態管理
•	事務支持
•	方法級安全性
•	記錄日誌
•	模擬
•	消息隊列支持

.NET 開發人員可以通過組件服務管理工具或者利用可編程特性來設置 COM+ 屬性。

注雖然有許多第三方實現的方法，但是在 .NET 中沒有與容器託管持久性 (CMP)、容器託管關係或者 EJB-QL 對等的工具。Visual Studio .NET 具有自動生成 SQL 語句以及將數據庫表拖放到 IDE 中的工具。

支持 Web 服務

Microsoft 在支持 Web 服務方面已經花費了相當多的精力。ASP.NET Web 服務是實現基於 .NET Framework 的 Web 服務的首選技術。

在 HTTP 中，ASP.NET Web 服務利用 SOAP 支持服務請求。ASP.NET Web 服務爲 Web 服務自動生成 WSDL 和發現文件 (.disco)。可以利用 ASP.NET Web 服務來實現一個 Web 服務偵聽器，它可以訪問作爲 COM 組件或者託管類而實現的業務外觀。 .NET Framework SDK 還提供生成代理類的工具，客戶端應用程序可以利用代理類訪問 Web 服務。

與數據庫連接

.NET Framework提供 ADO.NET (以前稱作 ActiveX Data Object)，作爲與數據庫連接的框架。從架構師的角度來看，ADO.NET 表示的是可以在 .NET Framework 中用來構建數據訪問類的抽象設計概念。從開發人員的角度來看，ADO.NET 表示的是在 .NET Framework 內實現的具體類，.NET Framework 隨後可以用這些類進行數據訪問。

注 ADO.NET 提供的功能類似於 JDBC 和 JDO 中實現的功能。

對於 ADO.NET 來說，有幾項主要的設計目標：

•	明確、分解的對象模型— ADO.NET 是一種簡單易用的對象模型，開發人員完全有權決定如何控制數據源的連接、命令的執行和數據的操作。
•	斷開數據緩存模型N 層編程與 XML Web 服務體系結構要求應用程序可以以一種斷開的、鬆耦合的方式來參與。ADO.NET 提供了一種綜合的緩存數據模型，以在應用程序或服務之間封送處理數據，然後優化更新原來的數據源。
•	XML 支持 — XML 是構建可互操作應用程序與可靠數據處理模型的關鍵。XML 支持直接包含在 .NET Framework 中，ADO.NET 通過關係的方式或者本機 XML 的方式與 XML 進行無縫交互來使用該實現。

可以將 ADO.NET 體系結構分成兩個邏輯片段：命令執行與緩存。命令執行需要的功能包括連接、執行和讀取結果等，.NET 數據提供程序支持這些功能。DataSet 功能是處理結果的緩存。

實現集合

集合是一組可以歸類在一起的相似類型對象。這對等於 J2EE 平臺上的java.util.collections。

可以將任何類型的對象分到同一個類型爲 Object 集合中，以利用編程語言中固有的結構。例如，C# foreach 語句期望集合中所有的對象都是同一種類型。

但是，在類型 Object 集合中，裝箱和取消裝箱或轉化這樣的額外處理會影響集合的性能。一般情況下，當存儲或恢復類型爲 Object 的集合中的一個值類型時會發生裝箱和取消裝箱。

強類型集合，例如 StringCollection，如果元素的類型就是集合預期的類型（例如從 StringCollection 存儲或恢復字符串），那麼就可以避免這些影響性能的因素。另外，強類型集合會自動驗證每一個添加到集合中的元素的類型。

可以將 collections 類分成三種類型：

•	一般集合— 常見的數據集合變量，例如哈希表、隊列、堆棧、目錄和列表。
•	位集合 — 其元素是位標誌的集合。它們與其他集合略有不同。
•	專用集合 — 具有特殊目的的集合，通常處理特定類型的元素，例如 StringDictionary。

訪問目錄服務

.NET 中的訪問目錄服務的通常含義是：利用輕量級目錄訪問協議 (LDAP) 或者 Active Directory 服務接口 (ADSI)，即 JNDI 的對等物，連接到Active Directory。

Microsoft 在 Wldap32.dll — 也稱作“LDAP?C”或“C-binding LDAP”中實現 LDAP API。 LDAP 編寫的應用程序只與 LDAP 目錄服務是兼容的，儘管 Active Directory 也完全支持 LDAP API 進行目錄訪問。

爲 Active Directory 主要推薦的 API 是 ADSI。ADSI 位於 LDAP 的頂端，還可以通過 LDAP 提供最簡單的訪問 Active Directory 的方式。通過公開以 COM 對象的形式存儲在目錄中的對象，本機 ADSI 允許訪問 Active Directory。然後就可以利用 COM 接口中的方法操作目錄中的對象。

ADSI 提供程序包含特定命名空間的 ADSI 對象實現，最重要的一個就是 ADSI LDAP 提供程序。通過實現所需的接口，ADSI 提供程序將這些接口轉換爲特定目錄服務的 API 調用。

ADSI LDAP 提供程序在 ADSI 客戶端運行，訪問 Active Directory 或者其他的 LDAP 目錄服務。ADSI LDAP 提供程序可以與支持 LDAPv2 或更新版本的任何 LDAP 服務器協同工作。

有關 LDAP API 和 LDAP 編程的更多信息，請參閱 Web 資源頁上的鏈接 Microsoft Platform SDK。

反射

反射允許編寫代碼以在運行時動態檢查數據類型或者對象。可以獲得它的一系列方法、接口甚至是類級變量。反射甚至可以允許通過調用動態發現的方法或者給動態發現的變量賦值來與對象進行交互。

利用反射，可以創建對象瀏覽器、列舉與記錄方法的應用程序，甚至是高度可配置的、元數據驅動的應用程序，這些應用程序根據表或者 XML 文件中的指令創建對象與調用方法。這些都是在基於 .NET 的應用中可以使用的強大功能。

要注意，反射還會進行具有潛在危險的操作。可以利用反射來調用在作用域中是 Private 的方法。還可以直接給對象的變量賦值，而並不調用任何業務邏輯。反射提供了以非常危險的方式誤用對象的工具。但是，可以利用這些功能來創建非常強大的代碼，例如根據將對象的變量名稱與表中的列名匹配的元數據，創建從 DataSet 將數據加載到對象中的代碼。

J2EE 基本原理（針對 .NET 開發人員）

如果您是一位 .NET 開發人員並想了解 J2EE 平臺的組件和功能，那麼您可以從這裏着手。

Sun Microsystems 開發的 Java 既是一個平臺，又是一種編程語言。目前 Java 平臺有三個版本：

•	J2SE (Java 2 Standard Edition)
•	J2EE (Java 2 Enterprise Edition)
•	J2ME (Java 2 Micro Edition)

注 “Java”這個術語通常指的是 J2SE 具有的功能。需要企業版功能的領域要包含 J2EE。

Java 2 Platform, Enterprise Edition 或者 J2EE 是一套相互聯繫的規範，它允許開發人員創建基於服務器的多層應用程序。因此，與 Microsoft 的 .NET 不同，J2EE 是一個標準而不是一個產品。J2EE 規範包括一系列可以下載的 Adobe PDF 文件，用來說明應用程序協議與應用程序運行所在的容器結構。

和 .NET一樣，J2EE 使您可以只關注編寫業務邏輯而不是企業框架自身，使得編寫分佈式企業應用程序變得更輕鬆。J2EE 提供允許運行應用程序的“基礎結構”，否則編寫這些會很乏味與耗時。

注發佈時，J2EE v1.3 是最新的發佈版本，而 v1.4 還處於最終的草案階段。

因此，J2EE 平臺與 Microsoft .NET 的觀點類似，兩種平臺所貫穿的主題是相同的。但是理解二者的本質區別非常重要。Java 與 Microsoft .NET 主要在三個方面不同，它們是：

•	操作系統支持
•	語言支持
•	執行方法

從一開始，設計 Java 時就儘可能使它工作在各種操作系統上。因此，Java 代碼可以運行在多種環境中，例如：

•	Windows
•	UNIX
•	Linux
•	MacOS
•	BeOS

但是，Microsoft .NET 只能在 Windows 上運行。

注 Rotor 是運行在 FreeBSD 上的 .NET Framework 版本。但是，這更多的是進行學術研究，而不是一個實用的實現方案。

語言支持包括語言、格式以及創建程序使用的語法。編寫 Java 應用程序只能用 Java 編程語言。對於 .NET，則可以選擇任何支持 .NET Framework 的語言。

兩種平臺在運行應用程序時也有重要的不同點。當基於 .NET 語言構建項目時，輸出是 MSIL 代碼，它是運行時 JIT 編譯器編譯的代碼。

爲了部署一個 Java 程序，要編譯應用程序以創建 Java字節碼。運行在目標操作系統之上的 JVM 對這些字節碼進行解釋，生成相關的指令。

注同時，Java JIT 編譯器的工作方式與 .NET Framework 組件的類似。

理解 Java 平臺

Java 平臺有兩個主要組件。它們是：

•	Java 運行時環境 (JRE)
•	Java 語言與格式 (API)

JRE 的主要組件是 Java 虛擬機，或者叫 JVM。JVM 的作用是爲操作系統將 Java 字節碼解釋成本機指令。但是，JVM 還提供許多類似於 .NET CLR 的功能。JRE 也包括 Java 類庫。

J2EE 框架內還有過去十年中發展的其他組件。它們是：

•	Java Server Pages (JSP)
•	Server side API 或者 servlet
•	Enterprise Java Beans (EJB)
•	Java Naming and Directory Interface (JNDI)
•	Java Message Service (JMS)
•	Java API for XML-based RPC (JAX-RPC)
•	J2EE Connector Architecture
•	J2EE Management Model
•	J2EE Deployment API
•	Java Management Extensions (JMX)
•	J2EE Authorization Contract for Containers
•	Java API for XML Registries (JAXR)
•	Java Transaction API (JTA)
•	Common Object Request Broker Architecture (CORBA)
•	JDBC data access API

這些組件大部分在 .NET Framework 或 Windows 中都有與之對應的組件。例如，JMS 提供基於消息的事務的支持，它映射到 System.Messaging 命名空間。

由於 J2EE 是一種規範，而非一種產品，許多供應商在 Sun 的許可下創建了他們自己的實現，這些供應商包括：

•	Sun (Sun ONE Application Server)
•	IBM (WebSphere)
•	BEA (WebLogic)

還有幾種開放源代碼實現，最著名的是 JBoss。有關更多信息，請參閱 JBoss Web 站點 http://www.jboss.org/

實現 Java SDK

和 .NET Framework 一樣，Java 有一個軟件開發工具包，來幫助您創建、編譯 Java 應用程序。Java SDK 已經修改過多次，您可以從 Sun 的 Java Web 站點下載 Java 2 SDK，Standard Edition 1.4。

其他的供應商在許可下，已經生產出了他們自己的 Java SDK 實現。和 J2EE 應用程序服務器一樣，這些供應商包括 IBM 與 BEA，還有一些開放源代碼實現。直到 1.1.4 版時，Microsoft 纔有了實現。

Java 2 SDK 包含有類庫，在創建自己的 Java 源代碼以及構建和執行這些應用程序的編譯器和二進制文件時可以使用這些類庫。SDK 的 bin 目錄中包含一個 Javac.exe 文件，可用來將 Java 源代碼（*.java 文件）編譯成 Java 字節碼（*.class 文件）。但是，和 .NET 應用程序一樣，只有最頑固、保守的工作才完全從命令行執行，而大多數工作使用基於 GUI 的 IDE 來創建與編譯 Java 應用程序。

構建 Java 應用程序

當用 Java 編譯器編譯 Java 類時，Java 中的每個類就生成一個單獨的 .class 文件，.class 文件是標準的編譯單元。然後 JVM 就可以按照下面的格式執行該 .class 文件：

java myapp.class

但是，.class 文件不是與 .NET 中的程序集完全對應，這是因爲 .NET 程序集既是執行的單元又是分發的單元。Java 開發人員利用 Java 存檔 (JAR) 文件可以創建包含多個 .calss 文件的可發佈應用程序。儘管 JAR 文件可以包含任何類型的文件並擁有一個內部目錄結構，就像一個 ZIP 文件，但一個基本 JAR 文件就是一個已編譯的 Java 類集合。可以利用 SDK 的 /bin 目錄中的 Jar.exe 文件來添加、列出 .class 文件或從 JAR 文件解壓出 .class 文件。

可以用 JVM Java.exe 文件來執行 JAR 文件。格式爲：

java jar myapp.jar

只利用本機操作系統命令和 Java 2 SDK 提供的基本工具就可以構建與部署一個完整的 J2EE 應用程序，如果您真希望這樣做的話。但是這種方法非常乏味並且容易出錯。相反，開發人員經常使用的構建工具，如 ANT，它是 Apache Jakarta 項目的一部分。 ANT 是一種與平臺無關的構建工具，它自動編譯、打包和部署應用程序。它利用 XML 構建文件來決定編譯和部署項目需要完成的任務。

有關更多 ANT 的信息，請參閱 Apache ANT Web 站點。

定位與共享類

Java 平臺沒有與全局程序集緩存對等的東西。但是，應用程序可能仍需要引用或共享其他的類。Java 中，利用名稱爲 CLASSPATH 的環境變量來完成此項工作。這類似於 Autoexec.bat 啓動文件中的 PATH 語句，或者 Windows 中的 System Profile 屬性。

默認的類路徑就是當前的目錄。如果您願意，可以將環境變量 CLASSPATH 設置爲一個或多個不同的目錄。這樣做時，必須明確將該路徑包含到主要的 Java 2 SDK 工具 JAR 以及當前的目錄中。因此，運行於 Windows 上的 Java SDK 1.3 版中的簡單 CLASSPATH 語句如下所示：

SET CLASSPATH = .;%J2EE_HOME%/LIB/J2EE.JAR;

如果應用程序需要其他的類或者 JAR 文件，則在運行該應用程序之前就要修改 CLASSPATH 變量。按照如下所示引用當前的 CLASSPATH 變量就可以做到這一點。

SET CLASSPATH = %CLASSPATH%;C:/OTHERAPP/RESOURCES.JAR;C:/OTHERAPP/CLASSES

這樣就將該新目錄添加到了現有的 CLASSPATH 中，因此當 Java 應用程序加載和要求某個類時，應用程序還要搜索目錄 C:/OtherApp/Classes 中的所有類或者搜索 JAR 文件 C:/OtherApp/Resources.jar。

Javac.exe 編譯器和 Java.exe 執行工具都可以接受參數，以包含或修改 CLASSPATH 變量。Java IDE 也允許您包含 CLASSPATH 語句。通過將這些庫作爲 JRE 的擴展安裝，也可以不設置 CLASSPATH 就能將庫自動添加到類搜索序列中。

注如果 Java 應用程序生成 ClassNotFoundException，幾乎就可以確定這是因爲 CLASSPATH 語句中沒有所需的庫。

實現其他環境變量

Java 應用程序使用的環境變量往往比基於 .NET 的應用程序使用的環境變量多。這是因爲 Java 應用程序可以在多種操作系統上運行，所以它們需要能夠處理不同的環境。環境變量提供了一種簡單的方法，確保設置與控制配置以及應用程序執行路徑的一致性。

表 2.1:公共環境變量
變量名稱	作用
JAVA_HOME	Sun Java SDK 的安裝位置
J2EE_HOME	Sun J2EE SDK 的安裝位置
ANT_HOME	ANT 的主目錄
PATH	Windows PATH 語句

使用 Java 集成設計環境

幾家供應商生產了 IDE 包來協助進行創建和編輯工作，範圍從增強的文本編輯器到類似於 Visual Studio .NET 的功能齊全的包。有些是需要付費的包，其他的是免費的。這裏的例子包括：

•	Sun One Studio
•	JCreator
•	Borland JBuilder
•	Java GUI Builder
•	JPad Pro
•	CodeGuide
•	NetBeans
•	AnyJ

注雖然可以利用 Visual Studio .NET 中的 Visual J# 來創建與編輯 Java 應用程序，但是 J# IntelliSense 技術只適用於 Java SDK 1.1.4 及以上版本的 Java API 類，並且需要利用 Javac.exe 從命令行來編譯應用程序。

所有的 IDE 包都允許在 IDE 環境內編譯應用程序。另一種方法是像 Visual Studio 一樣，可以從命令行編譯應用程序。

創建 Web 應用程序

對於表示層組件，Java 在 .NET 體系結構中使用 ASP.NET 的地方實現 JSP。JSP 提供了開發 Web 應用的服務器端技術，而且 JSP 頁是 HTML 與 Java 代碼的混合體。

基於 Java 的 Web 應用利用了動態編譯 JSP 頁與 servlet 的概念。servlet 就是一個 Java 編程語言類，它擴展了承載通過請求－響應編程模型訪問的應用程序的計算機的功能。也可以將 Java 的 servlet 看作是爲用戶請求提供動態內容的可移植組件。

第一眼看上去，JSP 和 servlet 非常相似，兩者都產生動態的內容。可以用 Java 編程語言在 JSP 頁或者 servlet 內創建任何腳本元素。另外，在運行時 JVM 將 JSP 編譯成 servlet，因此二者使用的是同一種引擎。但是，開發 servlet 需要編寫 Java 類，因此比開發 JSP 需要更高的編程技巧。可以將 servlet 看作是包含有 HTML 內容的 Java 代碼。

和 servlet 一樣，JSP 爲用戶提供動態的內容，但比 servlet 的抽象度更高。可以將 JSP 看作是包含有動態 Java 代碼的靜態 HTML。

可以將 JSP 和 servlet 寄宿在多種環境上。這包括免費提供的環境如 Apache Tomcat，以及大型的商業軟件與供應商支持的實現。

爲實現基於 JSP 的應用程序，可以利用 Java IDE 來設計應用程序。幾種 IDE 都包含有實時編輯 JSP 頁的工具，可以預覽到任何更改圖形或控件後的效果。

注目前 JSP 規範的版本號爲 v1.2，servlet API 的版本號是 v2.3。

爲了部署 Web 應用程序，要將它們打包到一個稱爲 Web 應用程序存檔 (WAR) 文件的可部署單元中。這類似於將 Java 應用程序打包到 JAR 中。然後就可以輕鬆地將該 WAR 文件部署到 Web 服務器上。

承載組件

JSP 頁和servlet 的主要功能就是通過表示層中的瀏覽器與用戶進行交互。但是，在業務層中執行業務規則時需要利用稱爲 Enterprise Java Beans (EJB) 的組件。EJB 是 COM+ 組件或託管代碼組件的對等組件，並可提供下列服務：

•	維護狀態
•	事務性支持
•	方法級安全
•	記錄日誌
•	模擬
•	消息隊列支持

EJB 有三種形式：

•	會話 bean
•	實體 bean
•	消息驅動 bean。

會話 bean 管理業務邏輯，例如定義客戶關係管理系統運營的規則。會話 bean 可以是無狀態的，或者可以維護狀態，在對象的生存期內將客戶端約束在會話 bean 上。通常會話 bean 提供某種服務，例如執行某個任務（如對客戶端進行身份驗證）。

實體 bean 代表的是持久性存儲區中的對象。實體 bean 的每一個實例都對應數據庫表中的一行數據。有兩類實體 bean：容器託管持久性 (CMP) bean，由容器託管，而 bean 託管持久性 (BMP) bean 自己管理持久性。

對於 CMP 實體 bean，容器利用映射文件託管 bean 和數據庫字段之間的映射。該映射文件通常將這些映射保存爲 XML 部署描述符。容器託管所有與數據庫的通信。與 BMP 相比，CMP具有以下優點：

•	容易配置
•	容易維護
•	不需要數據庫代碼

由於抽象度較高，CMP 的主要缺點是它的性能差。但是，J2EE 規範已經引入了一些新功能，例如虛擬訪問器，它提高了使用 CMP 的 bean 的性能。

對於 BMP 實體 bean，開發人員負責編寫所有的 JDBC 代碼，以在 bean 和數據存儲區之間傳輸數據。BMP 要求開發人員編寫的與數據有關的代碼比 CMP 的還要多得多，但是使用 BMP 仍然有幾個很好的理由：

•	靈活性更大
•	性能更好
•	可以與多個數據庫源連接

Java 開發人員將會利用 CMP 與標準數據庫（例如 Oracle）或者在每秒交易量小的地方進行連接。在需要數據訪問速度快或需要開發人員靈活地與非標準數據庫如 LDAP 目錄連接的場合，正是 BMP 的用武之地。

需要將消息驅動 bean (MDB) 與 JMS API 結合使用，以異步處理消息。消息驅動 bean 就是 JMS 消息的使用者。客戶端不直接訪問 MDB，他們將 JMS 消息發送到偵聽 MDB 的目標。這樣就能夠重用 MDB，並且還意味着開發人員不必擔心到何處獲得消息。

使用 MDB 的兩大優勢是，MDB 可以並行處理用戶的請求，與使用非基於消息的實體 Java bean 的串行調用相比，響應速度較快。並且，在搜索多個數據源時，MDB 實現可以擔保對用戶的響應時間。

構建企業 JavaBean

當構建企業 JavaBean 時，開發人員必須要創建該 bean 的實現類以及許多接口。客戶端通過開發人員在 bean 接口中定義的方法來訪問會話和實體 bean。這些接口決定了客戶如何與 EJB 進行通信。消息驅動的 bean 和實體與會話 bean 是有區別的，這是因爲它們沒有接口，它們只包含一個 bean 實現類。

實體或會話 bean 上定義的接口取決於一個關鍵因素：是遠程訪問還是本機訪問該 bean？

遠程客戶端的情況爲：

•	在與客戶端獨立的 JVM 中運行的應用程序或組件（儘管該應用程序不要求必須在獨立的 JVM 中運行。）
•	在不同的計算機上執行的應用程序或組件。
•	Web 組件，例如 servlet、客戶端應用程序，或者另一個 EJB。
•	客戶端不知道（或者需要知道）EJB 位置的場合。

如果 EJB 服務於遠程客戶端，開發人員必須創建兩個接口：一個遠程接口與一個本機接口。遠程接口定義特定於 bean 的業務方法，例如 AuthenticateCustomer。本機接口定義管理 bean 實例的方法。例如，會話 bean 擁有創建與移除 bean 實例的方法。實體 bean 也包含有定位的方法。定位方法允許客戶端定位實體 bean，例如，findByPrimaryKey。

如果有下面幾種情況，則爲本地客戶端：

•	客戶端組件或應用程序在與 EJB 相同的 JVM 中執行。
•	客戶端可以是 Web 組件或者 EJB。
•	EJB 的位置對於客戶端來說是不透明的。

如果要求 EJB 爲本地客戶端服務，也需要創建兩個接口，一個本地接口與一個本地本機接口。本地接口定義 bean 的業務方法，定義的方法類似於遠程接口。本地本機接口類似於遠程本機接口，這是因爲它定義操作 bean 實例的方法以及定位的方法。

通常，本地客戶端調用本地接口的方法比遠程調用的效率更高。在典型的 J2EE 應用程序中，會話 bean 提供遠程客戶端訪問，但是實體 bean 通常情況下提供本地客戶端訪問。使用 CMP 的實體 bean 幾乎總是利用本地訪問。

部署應用程序

構建與部署 J2EE 應用程序涉及許多步驟，從而確保部署了應用程序工作所需的所有內容。除了包含 EJB 或者其他類的 JAR 文件，應用程序可能還需要 WAR 文件。WAR 文件就是具有 Web 應用程序所需結構的 JAR。最後，企業存檔文件 (EAR) 可以包含 WAR 與填充有 EJB 和其他內容的 JAR。

可以利用部署描述符來配置部署設置，它是具有定義的結構的 .XML 文件。部署描述符指定設置，例如安全性、事務性支持以及日誌記錄，它告知應用程序服務器如何部署與支持應用程序中的組件。此外，這些設置與組件服務中的設置是關聯的。有些部署描述符設置是 J2EE 規範的一部分，但是其他的與應用程序服務器有關，並特定於供應商。

.NET 和 J2EE 的特性對比

表 2.2 是 .NET 與 J2EE 特性與功能的對比。但是，每種平臺的背景組成不同，所以直接比較 .NET 與 J2EE 有時會不合適。例如，MSMQ 是一種產品，而 JMS 是一個 API。因此，不能簡單地去掉某個組件而代之以其他平臺的對等組件。

表 2.2：.NET 與 J2EE 的功能對比
特性或服務	Microsoft .NET 元素	J2EE 元素	註釋
技術類型	產品	標準	-
中間件供應商	Microsoft 及其合作伙伴	50 多個供應商	-
客戶端 GUI	Windows 窗體環境	AWT/SWING	SWING/AWT 是 J2SE 的一部分
Web GUI	ASP.NET	JSP	-
Web 腳本	ISAPI HttpHandler HttpModule	Servlet Filter	-
Web 應用程序宿主	Internet Information Server	多種（取決於供應商的實現）	J2EE 的示例包括Apache Tomcat
解釋程序	CLR	JRE	-
服務器端業務邏輯組件	.NET 類或者服務組件 (COM+)	EJB Session Beans	-
服務器端數據組件 1	具有 DB 邏輯的服務組件	有 Bean 託管持久性的 EJB	-
服務器端數據組件 2	ADO.NET 數據集	有容器託管持久性的 EJB	只是一個近似的對等物
目錄訪問	通過 LDAP 實現 Active Directory 服務接口 (ADSI)	通過 LDAP 實現 Java 命名與目錄服務 (JNDI)	LDAP 的兼容性使得目錄服務之間的切換非常簡單。
遠程調用	.NET Remoting	RMI-IIOP	-
數據訪問	ADO.NET	JDBC, SQL/J, JDO	-
消息處理	Microsoft 消息隊列	JMS	Microsoft 消息隊列是一種產品。 JMS 是一種規範，因此需要底層實現。
事務性支持	COM+/分佈式事務控制器 (DTC)	JTA	-