漫談EJB

2019-11-18 16:13:23

字體：大中小

來源：轉載

供稿：網友

　　本文面向的觀眾是對J2EE技術有興趣的入門者。

java語言

Java語言最早被稱為Oak，它是為了實現嵌入式的消費類電子產品應用而產生的，它的作者是James Gosling。Ed Frank, Patrick Naughton, Jonathan Payne, Chris Warth在隨后的幾年時間中為Java語言加入了大量的特性，并把Java語言的目標做了一個重新的定位，定位于適合Internet的語言。

Java語言是一種多用途的語言、并發的語言、以類為基礎，面向對象的語言。它的設計盡可能的做到和操作系統是無關的，也就是Java所宣傳的那句話：“一次編寫，到處運行?！盝ava的設計參考了C和C++語言，因此熟悉C和C++的程序員對Java語言上手很快，而Java設計的原則是能夠利用Java語言快捷的編寫應用，所以我們可以發現，在Java語言中，并沒有那些C和C++中的復雜的機制。最明顯的就是C中被大量使用的指針，由于它的隨意性，被Java以引用來代替了。而C++中的操作符重載、模板、泛型的特性也因為使用比較復雜，Java也不予采用。但是目前Java仍然不斷的推出新的特性，以滿足應用的發展。例如在新推出的JDK1.4中，Java語言就能夠支持Assertment機制和Perl語言中最有用的正則表達式機制。

　　Java語言主要由以下五種元素組成：標識符、關鍵字、文字、運算符和分隔符。這五種元素有著不同的語法含義和組成規則，它們互相配合，共同完成Java語言的語意表達。

1：標識符。變量，類和方法都需要一定的名稱，我們將這種名稱叫做標識符。

2：關鍵字。關鍵字是Java語言本身使用的標識符，它有其特定的語法含義。所有的Java關鍵字將不能被用作標識符。

3：數據類型。Java有著不同的數據類型。比較值得一提的是字符串數據類型，字符串數據類型是用一對雙引號括起來的字符序列，字符串數據實際上是由String類所實現，而不是Ｃ語言中所用的字符數組。每一個字符串數據將產生一個String類的新的實例，用戶不必對字符串與類這個概念發生關系而感到擔心，由于類的特性，你不必擔心如何去實現它們，它們會自己照顧好自己，需要說明的是字符串在Java里作為類只是出于安全的考慮。

4：運算符。任何語言都有自己的運算符，Java語言也不例外，如＋、－、＊、／等都是運算符，運算符的作用是與一定的運算數據組成表達式來完成相應的運算。對不同的數據類型，有著不同的運算符。

5：分隔符。分隔符用來使編譯器確認代碼在何處分隔。‘’‘’‘;’‘:’都是Java語言的分隔符。

學習 Java 語言很簡單，畢竟 Java 語言也只包含五十多個關鍵詞（keyWord）與幾十個算符（Operator），再加上 Java 語法（syntax）也很簡單，所以一般人可以很快就學會 Java 語言。危險的是，很多人認為已經完全掌控 Java 語言，但其實對于內部的運作機制仍不能掌握，這些盲點有時候會讓你無法完全掌控 Java 語言。克服這些盲點的方式是看「The Java Language Specification, 2nd Ed.」（沒有中文版）來徹底弄懂 Java 程序語言，并看「Inside the Java Virtual Machine, 2nd Ed.」來徹底掌握 Java 虛擬機器的運作方式。學會了語言，并不代表就可以設計出好的對象導向系統架構。想要成為對象導向的專家，往往需要：(1) 多看相關的書，特別是 Design Pattern 和 Refactoring 的書。(2) 多觀摩別人的程序（例如 Java API 的 design 與 implementation）(3) 多寫程序。學會 Java 語言之后，還需要學會一些 API 才能寫出有用的程序。Java 的 API 非常多，必須規劃好一個學習路徑，才不會在浩瀚的 API 大海中迷失。必備的 API 包括了：IO、New IO、Collection Framework、Network、RMI、JAXP... 等。至于其它的 API，就看你的需求而定，大致上分成：

* GUI 類：JavaBean -> Swing -> JavaHelp -> Java2D -> Image IO -> JAI -> Java 3D ...
* EnterPRise 類：JDBC -> JDO -> Servlet -> jsp -> EJB -> JMS -> JTA/JTS...
* J2ME 類（這一類不是我的專長，無法提供學習順序建議）

Java語言通常都是根據Java虛擬機規范（The Java Virtual Machine Specification）中的定義，編譯為字節碼指令集和二進制格式。因此我們接下來就討論Java虛擬機（JVM）

JVM

我們已經談過Java語言的語法類似于C和C++，但是摒棄了C和C++中復雜、疑惑和不安全的特性。Java語言最早是用來構建消費類網絡設備的軟件的，因此它要支持多主機的架構，并要求能夠提供安全的軟件組件。為了滿足這些需求，編譯好的代碼就必須能夠通過網絡來傳播，能夠在任何客戶端上運行，同時還要保證客戶端是足夠安全的。

Java虛擬機是Java和Java 2 平臺的基石。它能夠保證Java語言和硬件、操作系統無關，保證編譯后的代碼最小，并保護用戶不受惡意程序的攻擊。Java虛擬機到底是什么呢。其實它就是一臺不實際存在的計算機。和真實的計算機類似，它也有自己的指令集，并可以在運行環境中分配內存區域。使用虛擬機機制來實現編程語言并不是Java的創舉，這已經是非常普遍的做法了，最著名的許你就莫過于UCSD Pascal的P-Code機。

只要瀏覽器檢測到目前所處理的Web文件內容含有一個Java Applet，瀏覽器將會為這個Java小程序另外開一個JVM，執行這個Java應用小程序。在JVM中執行的Java小程序可以得到充分安全的保護。如同我們上面所說，JVM是一個自給自足的作業環境，就像是一臺獨立的計算機一樣。例如，在JVM運作的Applet，無法存取主機操作系統。優點是：

1. 系統中立。Java應用程序可以在任何JVM中運作，不論該系統使用何種硬件、軟件。

2. 安全。正因JVM跟操作系統沒有任何接觸，Java程序很難損害到其它檔案或應用程序。

缺點是，由于在JVM運作的程序獨立在操作系統之外，也就無法享受操作系統各項特殊功能。

Java技術之所以在今天得到了如此廣闊的應用，其中它的安全性是不能不提的。不同于其它技術（例如Microsoft的ActiveX）中安全性作為附加設計和補丁，Java從設計之初便考慮到了安全性。因此Java的安全性是在語言層次實現的。Java的安全性由下列三個方面保證：

　　1、語言特性（包括數組的邊界檢查、類型轉換、取消指針型變量）。

　　2、資源訪問控制（包括本地文件系統訪問、Socket連接訪問）。

　　3、代碼數字簽名（通過數字簽名來確認代碼源以及代碼是否完整）。

　　Java的源代碼是先編譯成為一種字節碼的中間代碼，存放這種代碼的文件就是.class的文件。真正執行的時候是將class文件裝載到JVM（虛擬機）中，然后由JVM解釋執行的。所以數組的上下界檢查及合法的類型轉換是通過JVM得到保證的。Java通過一個類裝載器類(ClassLoader)將虛擬機代碼文件（即class文件）裝載到JVM中，當完成裝載后，一個被稱做安全管理器（SecurityManager）的類開始運行，例如當一個Applet的class文件被缺省的類裝載器裝載到JVM中后，JVM會立即為它裝載一個SecurityManager的子類AppletSecurity，由這個管理器來驗證操作。代碼的所有動作（例如文件讀寫）都要先經過驗證，只有被該安全管理器接受的動作才能完成，否則就會拋出SecurityException異常。

　　對于JDK1.0，權限被籠統的劃分為兩大塊。一是擁有所有的權限，一個是僅擁有"沙箱"（sandBox）權限，這也是普通的Applet所擁有的權限。這時本地文件讀寫或是與源主機（Orignal Server）以外的主機連接都是被禁止的。這種劃分的最大問題就是缺乏靈活性。例如我們希望一個Applet在用戶信任的情況下能夠對本地文件系統的某個目錄進行讀寫，但并不要通過Socket與其它主機連接。這是JDK1.0的權限劃分就不能達到要求。JDK1.1后改進了權限的劃分，引入了權限集（PermissionSet）的概念。

由于我們的文章并不是討論JVM，因此，我們只是對JVM做一個簡單的介紹。如果需要詳細了解的，可以參考『The JavaTM TMVirtual Machine Specification』。

客觀的看待Java

相對于其他編程語音，Java有一個無庸置疑的優點：用戶以及編譯器第一次不必了解生成可執行代碼的特定CPU細節。Java引入了一個編譯代碼中間層，叫做字節代碼，并使用一個虛擬抽象的機器，而不是一個真實的機器。當Java編譯器結束了一個源文件的編譯后，你所得到的不是可以立即在一個給定平臺上運行的代碼，而是可以在任何真實的平臺上運行的字節代碼，唯一的條件就是這個平臺要理解和支持Java。這些發展包含著一個文化的變革。作為一個開發人員，你只需要確定Java虛擬機(JVM)提供的抽象層，不同的OS銷售商負責執行代碼層，從而將中立于平臺的字節代碼映射到主機平臺的機構中。在這種情況下，Java似乎是統一分布式計算機世界的領袖候選人了?！熬帉懸淮?，永遠運行”（并且無論在哪里）就成為Java誘人但卻真實的口號。

但我們平心而論，Java的跨平臺并不是一個非常誘人的特性？跨平臺理論的發展很好地證明了這一點。我們看到，將Java代碼從一個平臺移植到另一個平臺?Java這個語言最重要和最受吹捧的特點?并不象宣傳的那樣容易。任何Java平臺都有其自己的虛擬機，它可以理解通用的字節代碼，并且及時地將其編譯為本地代碼。矛盾由此產生，不同虛擬機的執行也很不相同，這一點足以使代碼的移植比預期耗費多得多的時間，而且基本上不是自動的。在企業用戶的角度上來說，也很少會有企業會頻繁的更換平臺，因此這個特性是否能夠帶來高價值是很難評價的。

那么，Java模型的好處在哪里呢？首先，Java是一種先進的、面向對象的語言，包含了預防常見錯誤的內置功能，并在僅僅一兩個對象中攜帶了許多經常需要用到的功能。與C++相比，Java更易于讀寫，不容易出錯，而且更加美觀，但是它速度較慢也不太靈活。想實現在任何軟件和硬件平臺上都可虛擬移植，Java盡可能少地使用了公分母模型，也就是說放棄了將每個平臺開發到極限的能力。第二，虛擬機的概念本身就是可移植和可共用的，因此對于分布式環境來說是理想的。Java對于為非Windows平臺開發代碼是最好的語言。

那么對于Windows平臺來說，Java又怎么樣呢？讓Java適應Windows是不可能的，這是由于Sun的許可約束問題。但是Java實在是太吸引人了，Microsoft比誰都能更清楚這一點。Microsoft在以前推出的Visual J++證明了這一點，但是可惜的是，Microsoft又犯了霸權的老毛病，Visual J++并不好用。因此，Microsoft又一次采取了“拿來主義”的手法，很好地利用了Java 的眾多特性，隆重推出了Windows平臺的新銳力量，它就是相當簡單但十分強大的面向對象的C#編程語言。C#超過了C++，它天生就包含了.NET框架類庫中的所有類，并使語法簡單化。說到這里已經有一些離題了，不過Java也不是說在Windows平臺上就不能夠使用，JDK和大部分的IDE都支持Windows平臺。

Java技術的架構－－J2ME、J2SE和J2EE

通常我們以 JDK（Sun 所開發的一套 Java 開發工具）的版本來定義 Java 的版本。JDK 1.0 版于 1996 年初公開，JDK 1.1 版于 1997 年初公開，JDK 1.2 版于 1998 年底公開?；谑袌鲂袖N的考量，Sun 在 JDK 1.2 版公開后旋即將 Java 改名為「Java 2」，將 JDK 改名為「Java 2 Software Development Kit（以下簡稱 J2SDK）」。J2SDK（原稱 JDK）1.3 于 2000 年 4 月公開，此版本仍稱做「Java 2」。目前 J2SDK 1.4 也已經公開了，大家可以到Sun的官方Java站點上查閱到大量的JDK1.4的信息。

Java 技術根據硬件平臺與適用環境的差異，分成幾個分支。JDK 1.1 的時代，適用于一般消費性電子產品等，嵌入式系統的 Java 平臺是 PersonalJava 與 EmbeddedJava，此二者并無明確的界線，大致上來說，運算資源、內存、以及顯示裝置比較豐富者，使用 PersonalJava，例如 Set-Top Box、視訊電話 ... 等；反之，資源較有限者使用 EmbeddedJava，例如呼叫器、行動電話 ... 等。除了 PC 使用的 Java 平臺、IA 使用的 PersonalJava 與 EmbeddedJava 平臺之外，JavaCard 也是一個 Java 平臺，使用于 Smart Card（IC Card）上。

Java 2 出現后，推翻了先前的 PersonalJava 與 EmeddedJava 的分法，改分成 Java 2 Platform Enterprise Edition（簡稱 J2EE）、Java 2 Platform Standard Edition（簡稱 J2SE）、Java 2 Platform Micro Edition（簡稱 J2ME）。J2EE 適用于服務器，目前已經成為企業運算、電子商務等領域中相當熱門的技術；J2SE 適用于一般的計算機；J2ME 適用于消費性電子產品。除了這三者之外，JavaCard 依然是獨立的一套標準。

目前，Java技術的架構包括三個方面：

J2EE(Java 2 Platform Enterprise Edition )?企業版 (J2EE) 是為面向以企業為環境而開發應用程序的解決方案。
J2SE（Java 2 Platform Stand Edition）?標準版 (J2SE) 為桌面開發和低端商務應用提供了可行的解決方案。
J2ME(Java 2 Platform Micro Edition )?小型版(J2ME)是致力于消費產品和嵌入式設備的最佳解決方案

J2EE

J2EE已經成為開發商創建電子商務應用的事實標準。正是認識到J2EE平臺作為一種可擴展的、全功能的平臺，可以將關鍵的企業應用擴展到任何Web瀏覽器上并可適合多種不同的Internet數據流、可連接到幾乎任何一種傳統數據庫和解決方案、使企業經理根據多家企業所提供的產品和技術開發和部署最佳的解決方案進而降低開發網絡化應用的費用和復雜性這一巨大優勢，很多廠家都表示將對J2EE給予支持，并將J2EE技術作為大型BToB市場和海量交易處理的安全穩定的端到端平臺。J2EE技術的基礎就是J2SE標準版，它鞏固了標準版中的許多優點。其最終目的就是成為一個能夠使企業開發者大幅縮短投放市場時間的體系結構。它為靈活配置各種多層企業應用軟件,特別是B2B、B2C等電子商務應用,提供了強大的服務功能。最近又新加了Connector API服務,使企業應用的開發和部署有了一系列成熟的技術。

J2SE

J2SE是Java 2平臺的標準版, 它適用于桌面系統，提供CORBA標準的ORB技術,結合Java的RMI支持分布式互操作環境。它運行在Java虛擬機上。在引入了Java IDL后, J2SE支持IIOP通信。它是高可移植性、異構性的實現環境和健壯平臺，也是實現可伸縮性、可移植性、分布式異構互操作應用軟件開發的標準平臺。

J2ME

J2ME提供了HTTP高級Internet協議，使移動電話能以Client/Server方式直接訪問Internet的全部信息，不同的Client訪問不同的文件，此外還能訪問本地存儲區，提供最高效率的無線交流。J2ME是Java 2平臺的微型版,它分成CDC(connected device configuration)和CLDC(connected limited device configuration)兩部分。CDC運行在連接虛擬機上,為手提式計算機一類較復雜的移動設備提供應用平臺；CLDC運行在核心虛擬機(KVM)上,它實現MIDP(Mobile Information Device Profile)移動信息設備應用平臺，即針對手機之類的設備建立移動計算平臺。

在小型的J2ME（Java 2 Micro Edition）方面，主要是應用在內存容量小、體積也較小的電子裝置上。小至智能卡、行動電話，個人數字助理都是運用J2ME的最佳平臺。Java在Palm的應用上，PalmOS 4.0內含KJava，Sun也推出針對PalmOS使用的J2ME版本。所以，以既有的Java程序設計知識，就可以在Palm PDA上開發出Palm的各式各樣應用系統。Java和Palm這兩個標準平臺的結合，將是下一波PDA應用的趨勢。Java在手機的應用上，Nokia、Motorola、EriCSSon 都將推出利用J2ME技術的新手機，所以Java程序設計師有更多的平臺可供施展。此種結合J2ME及無線通訊技術的無線開放應用平臺，將提供行動商務極佳的解決方案。

在中型的J2SE（Java 2 Standard Edition）方面，Sun推出一個新的解決方案，稱為Java Web Start。原先的Java Applet是在WebBrowser 中間開出一塊方形區域來執行Java程序，但是這樣在執行效能和兼容性上都受限于原有的 Web Browser?，F在新推出的Java Web Start則是在操作系統上直接執行的Java application，但是可以在網頁上激活。如此一來既可和網頁結合，在執行上也更快、更有效率。并且，Sun和IBM都將推出支持64位運算的Java版本，這對一般計算機上執行的客戶端Java應用系統的開發將會是一大利器。

另外在大型的J2EE（Java 2 Enterprise Edition）應用上，可以說"J2EE"已經成為服務器運算環境的標準。Java Servlets、JSP（Java ServerPages）、EJB（Enterprise JavaBeans）、JavaMail、JDBC、JMS等，都是各家廠商產品開發的重點方向。J2EE兼容的是一般Intel個人計算機（linux、Windows.....）、麥金塔以及各家高效能高穩定度的UNIX伺服主機，未來必定成為服務器運算市場上的主要選擇之一。

除了以上這三大Java組合之外，Java和xml的整合也是未來的重點。Sun公司已經推出Java處理XML的標準延伸API - Java API for XML Parsing (JAXP)，可以讓各家所制作的XML解析器有接口上的標準。所以在Java程序中，只要了解一套API(JAXP)就可以完全處理XML文件，讓XML的應用更加方便。Java這個跨平臺的開發環境，加上XML這個跨平臺的資料格式，此種跨平臺優勢組合勢將成為未來訊息傳遞及資料交換的主要應用技術，如虎添翼地結合成一個最佳的跨平臺解決方案。

藉由J2SE (Java 2 Standard Edition)可以開發在PC上的應用軟件，藉由J2ME (Java 2 Micro Edition) 可以跨足更廣大的家電、智能卡、電子裝置等市場，再藉由J2EE (Java 2 Enterprise Edition ) 可以整合伺服主機運算環境。Java技術的應用范圍幾乎已經無所不在，Java技術更可以在網際網絡及電子商務各領域中，提供全方位的解決方案。

隨著應用領域的不同，Java 有許多 API（Application Programming Interface），這些 API 分成三大類：

? Java Core API：由 Sun 制定的基本 API，任何 Java 平臺都必須提供。

? Java Standard Extension API (javax)：由 Sun 制定的擴充 API，Java 平臺可以選擇性地提供或加裝。

? 廠商或組織所提供的 API：由各家公司或組織所提供。

其中 Core API 和 Standard Extension API 已經逐漸涵蓋了大部份的信息應用領域，例如多媒體、數據庫、Web、企業運算、語音、實時系統、網絡、電話、影像處理、加解密、GUI、分布式運算 ......。如果你有某項需求尚未有標準的 Java API 可遵循，你可以向 Sun 提出制定新 API 的請求。經過審核之后，你的要求可能會通過、駁回 ...... 等。如果通過，就會開始進入制定 API 的程序。Java API 的制定過程因為公開，且經過許多業界技術領先公司的共同參與，所以相當完善而優異。

EJB的生態環境

在sun公司提供的EJB規范中，我們一個完整的基于EJB的分布式計算結構由六個角色組成，這六個角色可以由不同的開發商提供，每個角色所作的工作必須遵循Sun公司提供的EJB規范，以保證彼此之間的兼容性。

EJB組件開發者: 開發并銷售 EJB。
應用組合者: 將不同的 EJB 搭建成應用。
部署者: 使用相應工具在運行環境下配置 EJB。
EJB 服務器提供者: 開發并銷售 EJB 服務器
EJB 容器供應商: 開發并銷售 EJB 容器
系統管理員: 監視運行時情況

1、EJB組件開發者(Enterprise Bean Provider)

　　EJB組件開發者負責開發執行商業邏輯規則的EJB組件，開發出的EJB組件打包成ejb-jar文件。EJB組件開發者負責定義EJB的remote和home接口，編寫執行商業邏輯的EJB class,提供部署EJB的部署文件(deployment descriptor)。部署文件包含EJB的名字，EJB用到的資源配置，如JDBC等。EJB組件開發者是典型的商業應用開發領域專家。

　　EJB組件開發者不需要精通系統級的編程，因此，不需要知道一些系統級的處理細節，如事務、同步、安全、分布式計算等。

　　2、應用組合者(Application Assembler)

　　應用組合者負責利用各種EJB組合一個完整的應用系統。應用組合者有時需要提供一些相關的程序，如在一個電子商務系統里，應用組合者需要提供JSP(Java Server Page)程序。

　　應用組合者必須掌握所用的EJB的home和remote接口，但不需要知道這些接口的實現。

　　3、部署者(Deployer)

　　部署者負責將ejb-jar文件部署到用戶的系統環境中。系統環境包含某種EJB Server和EJB Container。部署者必須保證所有由EJB組件開發者在部署文件中聲明的資源可用，例如，部署者必須配置好EJB所需的數據庫資源。

　　部署過程分兩步：部署者首先利用EJB Container提供的工具生成一些類和接口，使EJB Container能夠利用這些類和接口在運行狀態管理EJB。部署者安裝EJB組件和其他在上一步生成的類到EJB Container中。部署者是某個EJB運行環境的專家。

　　某些情況下，部署者在部署時還需要了解EJB包含的業務方法，以便在部署完成后，寫一些簡單的程序測試。

　　4、EJB 服務器提供者(EJB Server Provider)

　　EJB 服務器提供者是系統領域的專家，精通分布式交易管理，分布式對象管理及其它系統級的服務。EJB 服務器提供者一般由操作系統開發商、中間件開發商或數據庫開發商提供。

　　在目前的EJB規范中，假定EJB 服務器提供者和EJB 容器提供者來自同一個開發商，所以，沒有定義EJB 服務器提供者和EJB容器提供者之間的接口標準。

　　5、EJB 容器提供者(EJB Container Provider)

　　EJB 容器提供者提供以下功能：

　　提供EJB部署工具為部署好的EJB組件提供運行環境。EJB容器負責為EJB提供交易管理，安全管理等服務。

　　EJB 容器提供者必須是系統級的編程專家，還要具備一些應用領域的經驗。EJB 容器提供者的工作主要集中在開發一個可伸縮的，具有交易管理功能的集成在EJB 服務器中的容器。EJB 容器提供者為EJB組件開發者提供了一組標準的、易用的API訪問EJB 容器，使EJB組件開發者不需要了解EJB服務器中的各種技術細節。

　　EJB容器提供者負責提供系統監測工具用來實時監測EJB容器和運行在容器中的EJB組件狀態。

　　6、系統管理員(System Administrator)

　　系統管理員負責為EJB服務器和容器提供一個企業級的計算和網絡環境。

　　系統管理員負責利用EJB 服務器和容器提供的監測管理工具監測EJB組件的運行情況。

將責任分離的另一個好處是在代碼級上，可以將基于EJBs的系統邏輯的分派給更適合的專家。SUN的EJB規范建議使用幾個獨立的角色，對于確定運作環境的責任鏈是非常重要的。舉例說，EJB提供者是由商業專家和分析人員扮演的角色，他們確定一個組織內的最佳信息流程。但是仍舊有Second Domain Expert，如應用程序匯編人員，他們集成不同的EJB組件并確保它可以確保滿足應用程序的需求。

還有兩種角色歸入到系統級的部分，第一個是配置人員，他們負責實際的安裝和配置基于EJB的系統。這需要有設置目錄服務和集成現有應用程序的經驗。第二個是系統管理員，他們要提供全天的監視和支持，確保應用程序正常運作。盡管系統管理員這個角色不需要是Java編程專家，但是他需要能夠應付以下問題：

設置Java Virtual Machine (JVM)并關聯系統環境參數（如：CLASSPATH）
使用Java Archive (jar)命令保存類文件
懂得WEB服務器和Servlet的工作原理。
要能通過監視運行中程序的狀態確定優化方法。

很明顯，有些角色是可以交叉的，比如系統管理員和配置人員。盡管配置人員可能是將類文件復制到服務器而系統管理員需要確定配置人員是否復制到了正確的位置。

相關網址：http://www.linuxaid.com.cn/support/showfom.jsp?i=2984

EJB技術的基礎是另外兩種技術：RMI-IIOP和JNDI。要想了解EJB，一定要先了解RMI-IIOP和JNDI。因此，我們在介紹EJB細節之前，先了解這兩項技術。我們的介紹比較基本，因此大多數組織只要了解這些就已經夠了。

Java RMI-IIOP

Java RMI-IIOP（Java Remote Method Invocation over the Internet Inter-ORB Protocol）是J2EE的網絡機制。Java RMI-IIOP允許你編寫分布式對象，使得對象的通信范圍能夠在內存中，跨Java虛擬機，跨物理設備。

Remote Method Invocation

RPC（remote procedure call）是一臺機器的進程調用另一臺機器的進程的過程。而remote method invocation則比RPC的概念更進一步，允許分布式對象間的通信。RMI-IIOP允許調用遠程對象的方法，而不僅僅是過程。這有利于面向對象編程。Java RMI （Remote Method Invocation 遠程方法調用）是用Java在JDK1.1中實現的，它大大增強了Java開發分布式應用的能力。Java作為一種風靡一時的網絡開發語言，其巨大的威力就體現在它強大的開發分布式網絡應用的能力上，而RMI就是開發百分之百純Java的網絡分布式應用系統的核心解決方案之一。其實它可以被看作是RPC的Java版本。但是傳統RPC并不能很好地應用于分布式對象系統。而Java RMI 則支持存儲于不同地址空間的程序級對象之間彼此進行通信，實現遠程對象之間的無縫遠程調用。

remote method invocation決不簡單，需要考慮幾個問題：

marshalling和unmarshalling.在不同機器間通過網絡傳遞變量（包括Java基本類型和對象），如果目標機器表示數據的方式和原機器不同該怎么辦？例如二進制庫不同。因此marshalling和unmarshalling就是傳遞變量的過程。

變量傳遞方法.變量有兩種傳遞方法：pass-by-value和pass-by-reference。對于前者，你的目標方法只需使用一份copy，但對于后者，遠程方法對變量的任何修改都會影響到源數據。

網絡和機器的不穩定.需要有一種機制保證一個JVM崩潰之后，不會影響系統的正常運作。

在 Java 分布式對象模型中，remote object 是這樣一種對象：它的方法可以從其它 Java 虛擬機（可能在不同的主機上）中調用。該類型的對象由一種或多種 remote interfaces（它是聲明遠程對象方法的 Java 接口）描述。遠程方法調用 (RMI) 就是調用遠程對象上遠程接口的方法的動作。更為重要的是，遠程對象的方法調用與本地對象的方法調用語法相同。

Remote Interface

RMI-IIOP遵循了接口和實現的原則。你寫的所有網絡代碼都是應用于接口，而不是實現。實際上，你必須使用RMI-IIOP中的范例，沒有其它的選擇。直接在你的對象實現上執行遠程調用是不可能的，你只能在對象類的接口上單獨進行這一操作。

所以我們在使用RMI-IIOP時，你必須建立一個客戶接口，叫做remote interface。這個遠程接口應該擴展java.rmi.Remote接口。

Remote Object Implementation

遠程對象和客戶機的物理位置并不是很重要?？梢赃\行在同一地址空間或是跨Internet運行。

為了使對象成為一個遠程對象，你需要執行一下步驟：

繼承javax.rmi.PortableRemoteObject。PortableRemoteObject是進行遠程調用的基類，當你的遠程對象調用構造器時，PortableRemoteObject對象的構造器也會自動被調用。

不繼承javax.rmi.PortableRemoteObject。如果你的遠程對象需要繼承其它的類，而Java不允許多重繼承，因此你不能繼承PortableRemoteObject。這時，你需要手動調用javax.rmi.PortableRemoteObject.exportObject()。

Stub和Skeletons

我們來看看在RMI-IIOP背后隱藏的網絡架構。RMI-IIOP的一個好處就是你可以不用管你要調用的對象是本地的還是遠程的。這就叫做local/remote transparency。

RMI應用程序通常包括兩個獨立的程序：服務器程序和客戶機程序。典型的服務器應用程序將創建多個遠程對象，使這些遠程對象能夠被引用，然后等待客戶機調用這些遠程對象的方法。而典型的客戶機程序則從服務器中得到一個或多個遠程對象的引用，然后調用遠程對象的方法。RMI為服務器和客戶機進行通信和信息傳遞提供了一種機制。

在與遠程對象的通信過程中，RMI使用標準機制：stub和skeleton。遠程對象的stub擔當遠程對象的客戶本地代表或代理人角色。調用程序將調用本地stub的方法，而本地stub將負責執行對遠程對象的方法調用。在RMI中，遠程對象的stub與該遠程對象所實現的遠程接口集相同。調用stub的方法時將執行下列操作：(1) 初始化與包含遠程對象的遠程虛擬機的連接；(2) 對遠程虛擬機的參數進行編組（寫入并傳輸）；(3) 等待方法調用結果；(4) 解編（讀?。┓祷刂祷蚍祷氐漠惓＃?5) 將值返回給調用程序。為了向調用程序展示比較簡單的調用機制，stub將參數的序列化和網絡級通信等細節隱藏了起來。在遠程虛擬機中，每個遠程對象都可以有相應的skeleton（在JDK1.2環境中無需使用skeleton）。Skeleton負責將調用分配給實際的遠程對象實現。它在接收方法調用時執行下列操作：(1) 解編（讀?。┻h程方法的參數；(2) 調用實際遠程對象實現上的方法；(3) 將結果（返回值或異常）編組（寫入并傳輸）給調用程序。stub和skeleton由rmic編譯器生成。

要實現local/remote transparency可沒有那么簡單。為了屏蔽你調用的是遠端主機上的對象，RMI-IIOP需要模擬一個本地對象供你調用。這個本地對象叫做stub。它負責接受本地的方法調用請求，把這些請求委托給真正實現它們的對象（可以通過網絡定位）。這樣就使得遠程調用看起來就和本地調用一樣。

利用RMI編寫分布式對象應用程序需要完成以下工作：(1) 定位遠程對象。應用程序可使用兩種機制中的一種得到對遠程對象的引用。它既可用RMI的簡單命名工具rmiregistry來注冊它的遠程對象，也可以將遠程對象引用作為常規操作的一部分來進行傳遞和返回。（2）與遠程對象通信。遠程對象間通信的細節由RMI處理，對于程序員來說，遠程通信看起來就像標準的Java方法調用。（3）給作為參數或返回值傳遞的對象加載類字節碼。因為RMI允許調用程序將純Java對象傳給遠程對象，所以，RMI將提供必要的機制，既可以加載對象的代碼又可以傳輸對象的數據。在RMI分布式應用程序運行時，服務器調用注冊服務程序以使名字與遠程對象相關聯?？蛻魴C在服務器上的注冊服務程序中用遠程對象的名字查找該遠程對象，然后調用它的方法。

定位遠程對象。應用程序可使用兩種機制中的一種得到對遠程對象的引用。它既可用 RMI 的簡單命名工具 rmiregistry 來注冊它的遠程對象；也可將遠程對象引用作為常規操作的一部分來進行傳遞和返回。

與遠程對象通訊。遠程對象間通訊的細節由 RMI 處理；對于程序員來說，遠程通訊看起來就象標準的 Java 方法調用。給作為參數或返回值傳遞的對象加載類字節碼因為 RMI允許調用程序將純 Java 對象傳給遠程對象，所以 RMI 將提供必要的機制，既可以加載對象的代碼又可以傳輸對象的數據。服務器調用注冊服務程序以使名字與遠程對象相關聯?？蛻魴C在服務器注冊服務程序中用遠程對象的名字查找該遠程對象，然后調用它的方法。RMI 能用 Java系統支持的任何 URL 協議（例如 HTTP、FTP、file 等）加載類字節碼。

stub只是解決了一半的問題。我們還希望遠程對象也不用考慮網絡問題。因此遠程對象也需要一個本地的skeleton來接受調用。skeleton接受網絡調用并把調用委托給遠程對象實現。

你的J2EE服務器應當提供一種方法來產生必須的stub和skeleton，以減輕你的對網絡問題考慮的負擔。典型的是通過命令行工具來完成，例如sun的J2EE參考實現包就使用了一個名為rmic（RMI compiler）的工具來產生stub和skeleton類。你應當把stub部署在客戶機上，并把skeleton部署在服務器上。

對象序列化和變量傳遞

在RMI分布式應用系統中，服務器與客戶機之間傳遞的Java對象必須是可序列化的對象。不可序列化的對象不能在對象流中進行傳遞。對象序列化擴展了核心Java輸入/輸出類，同時也支持對象。對象序列化支持把對象編碼以及將通過它們可訪問到的對象編碼變成字節流；同時，它也支持流中對象圖形的互補重構造。序列化用于輕型持久性和借助于套接字或遠程方法調用(RMI)進行的通信。序列化中現在包括一個 API（Application Programming Interface，應用程序接口），允許獨立于類的域指定對象的序列化數據，并允許使用現有協議將序列化數據域寫入流中或從流中讀取，以確保與缺省讀寫機制的兼容性。

為編寫應用程序，除多數瞬態應用程序外，都必須具備存儲和檢索 Java對象的能力。以序列化方式存儲和檢索對象的關鍵在于提供重新構造該對象所需的足夠對象狀態。存儲到流的對象可能會支持 Serializable（可序列化）或 Externalizable（可外部化）接口。對于Java對象，序列化形式必須能標識和校驗存儲其內容的對象所屬的 Java類，并且將該內容還原為新的實例。對于可序列化對象，流將提供足夠的信息將流的域還原為類的兼容版本。對于可外部化對象，類將全權負責其內容的外部格式。序列化 Java 對象的目的是：提供一種簡單但可擴充的機制，以序列化方式維護 Java對象的類型及安全屬性；具有支持編組和解編的擴展能力以滿足遠程對象的需要；具有可擴展性以支持 Java 對象的簡單持久性；只有在自定義時，才需對每個類提供序列化自實現；允許對象定義其外部格式。

java.rmi.Remote 接口

在 RMI 中，遠程接口是聲明了可從遠程 Java 虛擬機中調用的方法集。遠程接
口必須滿足下列要求：

遠程接口至少必須直接或間接擴展 java.rmi.Remote 接口。
遠程接口中的方法聲明必須滿足下列遠程方法聲明的要求：
遠程方法聲明在其 throws 子句中除了要包含與應用程序有關的異常（注意與應用程序有關的異常無需擴展 java.rmi.RemoteException ）之外，還必須包括 java.rmi.RemoteException 異常（或它的超類，例如java.io.IOException 或 java.lang.Exception ）。
遠程方法聲明中，作為參數或返回值聲明的（在參數表中直接聲明或嵌入到參數的非遠程對象中）遠程對象必須聲明為遠程接口，而非該接口的實現類。

java.rmi.Remote 接口是一個不定義方法的標記接口：

public interface Remote

遠程接口必須至少擴展 java.rmi.Remote 接口（或其它擴展java.rmi.Remote 的遠程接口）。然而，遠程接口在下列情況中可以擴展非遠程接口：

遠程接口也可擴展其它非遠程接口，只要被擴展接口的所有方法（如果有）滿足遠程方法聲明的要求。
例如，下面的接口 BankAccount 即為訪問銀行帳戶定義了一個遠程接口。它包含往帳戶存款、使帳戶收支平衡和從帳戶取款的遠程方法：

public interface BankAccount extends java.rmi.Remote
{
public void deposit(float amount)
throws java.rmi.RemoteException;
public void withdraw(float amount)
throws OverdrawnException, java.rmi.RemoteException;
public float getBalance()
throws java.rmi.RemoteException;
}

下例說明了有效的遠程接口 Beta。它擴展非遠程接口 Alpha（有遠程方法）和接口 java.rmi.Remote：
public interface Alpha
{
public final String okay = "constants are okay too";
public Object foo(Object obj)
throws java.rmi.RemoteException;
public void bar() throws java.io.IOException;
public int baz() throws java.lang.Exception;
}

public interface Beta extends Alpha, java.rmi.Remote {
public void ping() throws java.rmi.RemoteException;
}

RemoteException 類

java.rmi.RemoteException 類是在遠程方法調用期間由 RMI 運行時所拋出的異常的超類。為確保使用 RMI 系統的應用程序的健壯性，遠程接口中聲明的遠程方法在其 throws 子句中必須指定 java.rmi.RemoteException（或它的超類，例如 java.io.IOException 或 java.lang.Exception）。

當遠程方法調用由于某種原因失敗時，將拋出 java.rmi.RemoteException 異常。遠程方法調用失敗的原因包括：

通訊失敗（遠程服務器不可達或拒絕連接；連接被服務器關閉等。）
參數或返回值傳輸或讀取時失敗
協議錯誤

RemoteException 類是一個已檢驗的異常（必須由遠程方法的調用程序處理并經編譯器檢驗的異常），而不是 RuntimeException。

RemoteObject 類及其子類

RMI 服務器函數由 java.rmi.server.RemoteObject 及其子類java.rmi.server.RemoteServer、java.rmi.server.UnicastRemoteObject和 java.rmi.activation.Activatable 提供。

java.rmi.server.RemoteObject 為對遠程對象敏感的 java.lang.Object方法、hashCode、 equals 和 toString 提供實現。

創建遠程對象并將其導出（使它們可為遠程客戶機利用）所需的方法由類UnicastRemoteObject 和 Activatable 提供。子類可以識別遠程引用的語義，例如服務器是簡單的遠程對象還是可激活的遠程對象（調用時將執行的遠程對象）。java.rmi.server.UnicastRemoteObject 類定義了單體（單路傳送）遠程對
象，其引用只有在服務器進程活著時才有效。類 java.rmi.activation.Activatable 是抽象類，它定義的 activatable遠程對象在其遠程方法被調用時開始執行并在必要時自己關閉。

實現遠程接口

實現遠程接口的類的一般規則如下：

該類通常擴展 java.rmi.server.UnicastRemoteObject，因而將繼承類java.rmi.server.RemoteObject 和java.rmi.server.RemoteServer 提供的遠程行為。
該類能實現任意多的遠程接口。
該類能擴展其它遠程實現類。
該類能定義遠程接口中不出現的方法，但這些方法只能在本地使用而不能在遠程使用。

例如，下面的類 BankAcctImpl 實現 BankAccount 遠程接口并擴展java.rmi.server.UnicastRemoteObject 類：

package mypackage;

import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;

public class BankAccountImpl extends UnicastRemoteObject implements
BankAccount

{
private float balance = 0.0;

public BankAccountImpl(float initialBalance)
throws RemoteException
{
balance = initialBalance;
}

public void deposit(float amount) throws RemoteException
{
...
}

public void withdraw(float amount) throws OverdrawnException,
RemoteException
{
...
}

public float getBalance() throws RemoteException
{
...
}
}

注意：必要時，實現遠程接口的類能擴展除java.rmi.server.UnicastRemoteObject 類以外的其它一些類。但實現類此時必須承擔起一定的責任，即導出對象（由 UnicastRemoteObject 構造函數負責）和實現從 java.lang.Object 類繼承的 hashCode、 equals 和toString 方法的正確遠程語義（如果需要）。

遠程方法調用中的參數傳遞

傳給遠程對象的參數或源于它的返回值可以是任意可序列化的 Java 對象。這包括 Java 基本類型, 遠程?Java 對象和實現 java.io.Serializable 接口的非遠程 Java 對象。有關如何使類序列化的詳細信息，參見 Java“對象序列化規范”。本地得不到的作為參數或返回值的類，可通過 RMI 系統進行動態下載。

傳遞非遠程對象

非遠程對象將作為遠程方法調用的參數傳遞或作為遠程方法調用的結果返回時，是通過復制傳遞的；也就是使用 Java 對象序列化機制將該對象序列化。因此，在遠程對象調用過程中，當非遠程對象作為參數或返回值傳遞時，非遠程對象的內容在調用遠程對象之前將被復制。從遠程方法調用返回非遠程對象時，將在調用的虛擬機中創建新對象。

傳遞遠程對象

當將遠程對象作為遠程方法調用的參數或返回值傳遞時，遠程對象的 stub 程序即被傳遞出去。作為參數傳遞的遠程對象僅能實現遠程接口。

引用的完整性

如果一個對象的兩個引用在單個遠程方法調用中以參數形式（或返回值形式）從一個虛擬機傳到另一個虛擬機中，并且它們在發送虛擬機中指向同一對象，則兩個引用在接收虛擬機中將指向該對象的同一副本。進一步說就是：在單個遠程方法調用中，RMI 系統將在作為調用參數或返回值傳遞的對象中保持引用的完整性。

類注解

當對象在遠程調用中被從一個虛擬機發送到另一個虛擬機中時，RMI 系統在調用流中用類的信息 (URL) 給類描述符加注解，以便該類能在接收器上加載。在遠程方法調用期間，調用可隨時下載類。

參數傳輸

為將 RMI 調用的參數序列化到遠程調用的目的文件里，需要將該參數寫入作為java.io.ObjectOutputStream 類的子類的流中。ObjectOutputStream 子類將覆蓋 replaceObject 方法，目的是用其相應的 stub 類取代每個遠程對象。對象參數將通過 ObjectOutputStream 的 writeObject 方法寫入流中。而ObjectOutputStream 則通過 writeObject 方法為每個寫入流中的對象（包含所寫對象所引用的對象）調用 replaceObject 方法。RMIObjectOutputStream子類的 replaceObject 方法返回下列值：
如果傳給 replaceObject 的對象是 java.rmi.Remote 的實例，則返回遠程對象的 stub 程序。遠程對象的 stub 程序通過對java.rmi.server.RemoteObject.toStub方法的調用而獲得。如果傳給 replaceObject 的對象不是 java.rmi.Remote 的實例，則只返回該對象。

RMI 的 ObjectOutputStream 子類也實現 annotateClass 方法，該方法用類的位置注解調用流以便能在接收器中下載該類。有關如何使用 annotateClass的詳細信息，參見“動態類加載”一節。因為參數只寫入一個 ObjectOutputStream，所以指向調用程序同一對象的引用將在接收器那里指向該對象的同一副本。在接收器上，參數將被單個ObjectInputStream 所讀取。

用于寫對象的 ObjectOutputStream（類似的還有用于讀對象的ObjectInputStream ）的所有其它缺省行為將保留在參數傳遞中。例如，寫對象時對 writeReplace 的調用及讀對象時對 readResolve 的調用就是由 RMI的參數編組與解編流完成的。

與上述 RMI 參數傳遞方式類似，返回值（或異常）將被寫入ObjectOutputStream的子類并和參數傳輸的替代行為相同。

定位遠程對象

我們專門提供了一種簡單的引導名字服務器，用于存儲對遠程對象的已命名引用。使用類 java.rmi.Naming 的基于 URL 的方法可以存儲遠程對象引用?？蛻魴C要調用遠程對象的方法，則必須首先得到該對象的引用。對遠程對象的引用通常是在方法調用中以返回值的形式取得。RMI 系統提供一種簡單的引導名字服務器，通過它得到給定主機上的遠程對象。java.rmi.Naming 類提供基于統一資源定位符 (URL) 的方法，用來綁定、再綁定、解開和列出位于某一主機及端口上的名字-對象對。

J2EE的十三種技術

Java數據庫連接（JDBC）

　　JDBC API以一個統一的方式訪問各種數據庫。與ODBC類似，JDBC將開發者和私有數據庫之間的問題隔離開來。由于它建立在Java上，因此JDBC可以提供平臺無關的數據庫訪問。

　　JDBC定義了4種不同的驅動，具體來說，包括有：

　　類型1：JDBC-ODBC橋

　　在JDBC剛產生時，JDBC-ODBC橋是非常有用的。通過它，開發者可以使用JDBC來訪問一個ODBC數據源。缺點是，它需要在客戶機器上安裝有一個ODBC驅動，該機器通常是應該運行微軟Windows系統的。使用這一類的驅動器，你就會失去JDBC平臺無關的好處。此外，ODBV驅動器需要客戶端的管理。

　　類型2：JDBC-native驅動橋

　　JDBC-native驅動橋提供了一個建筑在本地數據庫驅動上的JDBC接口--沒有使用ODBC。JDBC驅動將標準的JDBC調用轉變為對數據庫API的本地調用。使用類型2的驅動也會失去JDBC平臺無關性的好處，并且需要安裝客戶端的本地代碼。

　　類型3：JDBC-network橋

　　JDBC-network橋不需要客戶端的數據庫驅動。它們使用網絡-服務器中層來訪問一個數據庫。這會引出諸如負載均衡、連接池等技術，數據緩沖也是可能的。由于類型3的驅動通?？蓭硐鄬π〉南螺d時間，它是平臺無關的，并且不需要客戶端的安裝和管理，因此很適合用作Internet的應用。

　　類型4：純Java驅動

　　類型4使用純Java數據庫驅動來提供直接的數據庫訪問。由于類型4驅動運行在客戶端，并且直接訪問數據庫，因此運行在這個模式暗示要使用一個兩層的體系。要在一個n層的體系中使用類型4的驅動，可以通過一個包含有數據訪問代碼的EJB，并且讓該EJB為它的客戶提供一個數據庫無關的服務。

Java命名和目錄接口（Java Naming and Directory Interface，JNDI）

JNDI是Java Naming and Directory Interface 的簡寫，中意為：Java命名及目錄接口，它是為了對高級網絡應用開發中的使用的目錄基礎結構的訪問。實際上這個目錄是一個特殊的數據庫，提供了對存儲數據的快速訪問，不象傳統的目錄服務訪問方式-你必須提供不同的API接口去訪問不同的目錄服務（如：LDAP，NIS，ADS等），而它提供了一種標準的API來訪問類型不同的目錄。據說，使用完整的SDK可以開發那些JNDI還不支持的目錄服務提供者。

JNDI是J2EE的一個API，提供了一套標準的接口，以定位用戶、機器、網絡、對象、以及服務。例如，你可以使用JNDI來定位內部網中的一臺打印機，你也可以使用它來定位Java對象或連接到一個數據庫。JNDI可以用于EJB、RMI-IIOP、JDBC中。它是網絡查找定位的標準方法。　　JNDI API被用來訪問命名和目錄服務。它提供一個相容的模式來訪問和操作企業范圍大的資源，例如一個應用服務器中的DNS、LDAP、本地文件系統或者對象。

　　在JNDI中，一個目錄結構中的每一個節點被稱為context。每一個JNDI的名字都是與一個context相對的，沒有一個絕對名字的概念。一個應用可以使用InitialContext類來得到它的第一個context：

　　　Context ctx = new InitialContext();

　　通過這個初始的context，應用就可以經過目錄樹定位到需要的資源或者對象。例如，假定你已經在WebLogic Server中配置了一個EJB，并且在myApp.myEJB中綁定了home接口。EJB的客戶端，在得到這樣一個初始的context后，然后就可以使用以下的代碼來定位到home接口：

　　　MyEJBHome home = ctx.lookup( "myApp.myEJB" );

　　一旦你得到你所需對象的一個引用--在這個例子中，就是EJB的home接口--然后你可以調用它上面的方法。為了在一個context中查找到一個對象，JNDI還提供方法可以做到：

　　插入或者綁定一個對象到一個context中。在你配置一個EJB時，這是非常有效的方法；
　　
　　從一個context中移去一個對象

　　列出一個context中的所有對象

　　創建和刪除subcontexts

企業Java Beans（Enterprise Java Beans，EJB）

　　J2EE其中一個引人注目的技術是EJB。它提供了一個架構來開發和配置到客戶端的分布式商業邏輯，因此可以明顯減少開發擴展性、高度復雜企業應用的難度。EJB規范定義了EJB組件應該如何及何時與它們的容器交互。由容器來負責提供普通的服務，例如目錄服務、事務管理、安全、資源池和容錯。

　　EJB規范定義了三類基本的bean：

會話beans（session beans）：會話beans為業務流程建模，由于他們通常表示執行某個動作，因此可以把它們當作是動詞。這個執行的動作可以是任何事情，例如增加數量，訪問數據庫，調用其它系統，調用其它企業Bean。我們可以舉出很多的例子，包括一個計價引擎，一個工作流引擎，一個目錄引擎，一個信用卡認證中心，或一個網上證券交易引擎。

　　實體beans（Entity beans）：這是持久保存數據的代表--典型的是存儲在數據庫中--因此在服務器崩潰后數據仍然存在。多個客戶端可以使用EJB來表示同樣的數據。實體beans為企業數據建模，由于它們表示數據對象（就是緩存數據庫信息的Java對象），因此可以把它們當作名詞。實體beans的例子包括一種產品，一項訂單，一個雇員，一張信用卡，或一支股票。會話beans典型的方式是通過實體beans來實現業務目標的，例如一個證券交易引擎（會話beans）處理股票（實體beans）。

Message-Driven beans：Message-Driven beans也表示動作，這一點上它類似于會話beans。它們之間的不同點在于你只能夠通過發送消息給Message-Driven beans的方式來調用它們。Message-Driven beans的例子包括了接受股票交易消息的beans，信用認證消息，或工作流消息。這些Message-Driven beans也可以調用其它的企業beans。

接著，我們討論無狀態和有狀態

　　無狀態的beans（Stateless beans）：這是一個單一使用的服務，不維護任何的狀態，在服務器崩潰時也不再存在，而且生存期也相對地短。例如，一個無狀態的session bean可能用作執行溫度轉換。

　　有狀態的bean：它提供了一個傳統的與客戶端交互的方法，存儲客戶端的狀態。在線購物車就是這樣一個有狀態session ean的典型例子。有狀態session beans在服務器崩潰時也不再存在，而且生存期也相對地短，并且每個實例只可以用在一個單一的線程中。

JavaServer Pages (JSPs)

　　或許你已經對微軟的Active Server Pages (asps)非常熟悉；JSP也是類似的技術，不過它是平臺無關的。它們都是設計來幫助web內容開發者使用相對較少的代碼就可以創建動態的網頁。web設計者即使不懂得編程，也可以使用JSP來創建動態的網頁。JavaServer Page是Html代碼和Java代碼的混合。在客戶請求頁面的時候，服務器就會處理Java代碼，然后返回HTML頁面給瀏覽器。

　　你可以也聽過JHTML，它是一個舊的標準，現在已經被JSP取代了。WebLogic Server不但支持JSP，還支持JHTML。不過，在默認設置下，WebLogic Server是不支持JSP的（對于5.1版本）。你必須編輯weblogic.properties來激活web服務器，對于JSPServlet來說，也是這樣。

Java servlets

　　servlets提供的功能大部分JSP相同，它采用的是一個有點不同的方法。JSP中大部分是HTML代碼，其中只有少量的Java代碼，而servlets則相反，它完全使用Java編寫，并且產生HTML代碼。

　　servlet是一個在服務器上運行的Java小程序，它可以擴展Web服務器的功能。這些服務器端的應用可以在被請求時動態執行，與傳統Web服務器上的CGI Perl腳本差不多。CGI腳本和servlet的一個主要不同是：CGI腳本對于每次請求都啟動一個全新的進程--需要額外的系統開銷--而servlet的執行只要在servlet引擎內啟動一個獨立的線程就性了。因此Servlet的擴展性也更好。

　　在開發servlet時，你通常都要擴展javax.servlet.http.HttpServlet類，并且覆蓋它的一些方法。感興趣的方法包括有：

　　service(): 作為command-specific方法的一個調度程序

　　doGet(): 處理來自一個客戶的HTTP GET請求

　　doPost(): 處理來自一個客戶的HTTP POST請求

還有一些其它的方法來處理不同類型的HTTP請求--可參考HttpServlet API的文本來得到更多相關的信息。

Java IDL/CORBA

　　通過Java的IDL支持，開發者可以將Java與CORBA集成。他們可以創建能配置在一個CORBA ORB中的Java對象，也可以創建作為配置在其它ORB內的CORBA對象客戶端的Java類。對于通過Java將你的新應用和以前的系統集成，后者提供了一個另外的方法。

Java事務體系（JTA）/Java事務服務（JTS）

　　JTA定義了一個標準的API，應用可以通過它來訪問事務監控器。

　　JTS是CORBA OTS事務監控器的一個基本實現。JTS指定了一個事務管理器的實現（Transaction Manager），這個管理器在一個高級別上支持Java事務API（JTA）規范，并且在一個低級別上實現了OMG OTS規范的Java映射。一個JTS事務管理器為應用服務器、資源管理器、standalone應用和通信資源管理器提供事務服務。

JavaMail和JavaBeans激活架構（JavaBeans Activation Framework，JAF）

　　JavaMail是一個用來訪問郵件服務器的API。JavaMail API提供了一套抽象類來模型化一個郵件系統。支持SMTP和IMAP服務器。

　　JavaMail通過使用JavaBeans Activation Framework (JAF) 來處理MIME加密的郵件附件。MIME字節流和Java對象間可以互相轉化。大多數的應用無需要直接使用JAF。

Java信使服務（Java Messaging Service，JMS）

　　JMS是一個用來和面向信息的中層通信的API。它不但支持點對點的域，也支持發布/訂閱域，并且提供對擔保信息傳送、事務信息傳送、持久信息和durable subscribers的支持。對于將你的應用和以前的backend系統集成，JMS提供了另外一個方法。

擴展標記語言（Extensible Markup Language，XML）

　　XML是一個用來定義其它標記語言的的語言。它可被用作商業之間的數據共享。XML的發展是與Java分開的；不過，它的目標和Java類似，都是為了與平臺無關。通過將Java與XML結合，你可以得到一個完全平臺無關的解決方案。多個公司都為在Java和XML間開發一個緊密的集成而工作。具體的信息，可瀏覽Sun站點的Java-XML部分（http://java.sun.com/xml），以及IBM的developerWorks的XML Zone部分（http://www.ibm.com/developer/xml/）。

（出處：http://www.49028c.com）

上一篇：漫談EJB (3)

下一篇：漫談EJB (1)