jms源碼

『壹』 ejb到底是什麼東東就是一些java bean嗎

盡供你參考!
EJB是sun的伺服器端組件模型，最大的用處是部署分布式應用程序，類似微軟的.com技術。憑借java跨平台的優勢，用EJB技術部署的分布式系統可以不限於特定的平台。

EJB (Enterprise JavaBean)是J2EE的一部分，定義了一個用於開發基於組件的企業多重應用程序的標准。其特點包括網路服務支持和核心開發工具(SDK)。

在J2EE里，Enterprise Java Beans(EJB)稱為Java 企業Bean，是Java的核心代碼，分別是會話Bean（Session Bean），實體Bean（Entity Bean）和消息驅動Bean（MessageDriven Bean）。

1.Session Bean用於實現業務邏輯，它可以是有狀態的，也可以是無狀態的。每當客戶端請求時，容器就會選擇一個Session Bean來為客戶端服務。Session Bean可以直接訪問資料庫，但更多時候，它會通過Entity Bean實現數據訪問。

2.Entity Bean是域模型對象，用於實現O/R映射，負責將資料庫中的表記錄映射為內存中的Entity對象，事實上，創建一個Entity Bean對象相當於新建一條記錄，刪除一個Entity Bean會同時從資料庫中刪除對應記錄，修改一個Entity Bean時，容器會自動將Entity Bean的狀態和資料庫同步。

3.MessageDriven Bean是EJB2.0中引入的新的企業Bean，它基於JMS消息，只能接收客戶端發送的JMS消息然後處理。MDB實際上是一個非同步的無狀態Session Bean，客戶端調用MDB後無需等待，立刻返回，MDB將非同步處理客戶請求。這適合於需要非同步處理請求的場合，比如訂單處理，這樣就能避免客戶端長時間的等待一個方法調用直到返回結果。

EJB實際上是SUN的J2EE中的一套規范,並且規定了一系列的API用來實現把EJB概念轉換成EJB產品.EJB是BEANS,BEANS是什麼概念,那就是得有一個容納她,讓她可勁造騰的地方,就是得有容器.EJB必須生存在EJB容器中.這個容器可是功能強大之極!她首先要包裝你BEAN,EJB的客戶程序實際上從來就不和你編寫的EJB直接打交道,他們之間是通過HOME/REMOTE介面來發生關系的.它負責你的BEAN的所有的吃喝拉薩睡,比如BEAN的持續化,安全性,事務管理...

一.什麼是 EJB?

一個技術規范：EJB 從技術上而言不是一種"產品"
EJB 是一種標准描述了構建應用組件要解決的:
可擴展 (Scalable)
分布式 (Distributed)
事務處理 (Transactional)
數據存儲 (Persistent)
安全性 (Secure)

二.Sun 對 EJB 的期望

提供一個標準的分布的、基於 OO 的組件架構
屏蔽復雜的系統級功能需求
Write once, run anywhere
與非 Java 應用之間的互操作能力
兼容 CORBA 標准

三.為什麼選擇 EJB?

EJB 伺服器完成"繁雜"的工作：應用開發人員關注於業務邏輯的實現而不是底層的實現機制(類似於 4GL 語言設計的目標)
支持事務處理
多個業務操作同時成功，或全部失敗
可以通過在代碼外的描述來定義事務處理級別
可擴展性
EJB 可以根據您應用的增長而擴展
EJB 伺服器往往還提供了負載均衡和
安全性：由 EJB 伺服器提供資源的訪問許可權控制

四.EJB 架構

為了滿足架構的目標，規范中描述了
伺服器 (Server)
容器 (Container)
類 (Class) 和實例 (Instance)
Home 和 Remote 介面
客戶端 (Client)

五. 簡化的編程模型

關注於業務邏輯實現：EJB 負責生命周期 (lifecycle), 數據存儲 (persistence), 事務處理語義 (transactional semantic), 安全(security), ...
通用的編程模型：各種服務的高層 API
Java 是其編程語言

EJB( 業務邏輯代碼 ) 表示了與特定商業領域（例如銀行、零售等行業）相適應的邏輯。它由
運行在業務邏輯層的 enterprise bean 處理。一個 enterprise bean 可以從客戶端接受數據，對
它進行處理，並將其發送到企業信息系統層以作存儲；同時它也可以從存儲器獲取數據，
處理後將其發送到客戶端應用程序。
有三種類型的 enterprise beans：session beans、entity beans 和 message-driven beans。
Session bean 描述了與客戶端的一個短暫的會話。當客戶端的執行完成後，session bean 和
它的數據都將消失；與之相對應的是一個 entity bean 描述了存儲在資料庫表中的一行持久
穩固的數據，如果客戶端終止或者服務結束，底層的服務會負責 entity bean 數據的存儲。
Message-driven bean 結合了 session bean 和 Java 信息服務（JMS）信息監聽者的功能，它允
許一個商業組件非同步地接受 JMS 消息。

EJB3.0的介紹
[編輯本段]

由於EJB2.0的復雜性，在Spring和Hibernate等輕量級框架出現後，大量的用戶轉向了，在大家的呼聲中，EJB3.0規范終於發布了。
期待已久的EJB3.0規范在終於發布了。在本文中將對新的規范進行一個概要性的介紹，包括新增的元數據支持，EJBQL的修改，實體Bean模型訪問 bean上下文的新方法和運行時環境等等。作者還討論了EJB在未來要作出的調整以及EJB3.0與其他開發規范之間的關系。

開始

無論如何由於EJB的復雜性使之在J2EE架構中的表現一直不是很好。EJB大概是J2EE架構中唯一一個沒有兌現其能夠簡單開發並提高生產力的組建。EJB3.0規范正嘗試在這方面作出努力以減輕其開發的復雜性。EJB3.0減輕了開發人員進行底層開發的工作量，它取消或最小化了很多(以前這些是必須實現)回調方法的實現，並且降低了實體Bean及O/R映射模型的復雜性。

在本文中，我首先會介紹EJB3.0中幾個主要的改變。它對進一步深入了解EJB3.0是非常重要的。隨後，我會從更高的層面來描述已經被提交到EJB3.0規范中的細節，並一個個的講解新的規范中的改變:實體Bean,O/R映射模型，實體關系模型和EJB QL(EJB查詢語言)等等。

背景

EJB3.0中兩個重要的變更分別是:使用了Java5中的程序注釋工具和基於Hibernate的O/R映射模型。

Java5中的元數據工具

Java5(以前叫J2SE1.5或Tiger) 中加入了一種新的程序注釋工具。通過這個工具你可以自定義注釋標記，通過這些自定義標記來注釋欄位、方法、類等等。這些注釋並不會影響程序的語義，但是可以通過工具(編譯時或運行時)來解釋這些標記並產生附加的內容(比如部署描述文件)，或者強制某些必須的運行時行為(比如EJB組件的狀態特性)。注釋的解析可以通過源文件的解析(比如編譯器或這IDE工具)或者使用Java5中的APIs反射機制。注釋只能被定義在源代碼層。由於所有被提交到 EJB3.0草案中的注釋標記都有一個運行時的RetentionPolicy，因此會增加類文件佔用的存儲空間，但這卻給容器製造商和工具製造商帶來了方便。

Hibernate

目前Hibernate非常受歡迎，它是開發源代碼的Java O/R映射框架，目的是把開發人員從繁瑣的數據持久化編程中解脫出來。它也有一個標準的HQL(Hibernate 查詢語言)語言，你可以在新的EJB QL中看到它的影子。Hibernate在處理如數據查詢、更新、連接池、事務處理、實體關系處理等方面非常簡單。

概覽

在已經提交的EJB3.0規范中主要涉及兩個方面的改變:

1. 一套以注釋為基礎的EJB編程模型，再加上EJB2.1中定義的通過部署描述符和幾個介面定義的應用程序行為。
2. 新的實體Bean持久化模型，EJBQL也有許多重要的改變。

還有一些有關上述的提議，比如:一個新的客戶端編程模型，業務介面的使用以及實體Bean的生命周期。請注意EJB2.1編程模型(包括部署描述符和home/remote介面)仍然是有效的。新的簡化模型並沒有完全取代EJB2.1模型。

EJB注釋

EJB規范組織一個重要的目標是減輕原始代碼的數量，並且他們為此給出了一個完美而簡介的辦法。在EJB3.0的里，任何類型的企業級 Bean只是一個加了適當注釋的簡單Java對象(POJO)。注釋可以用於定義bean的業務介面、O/R映射信息、資源引用信息，效果與在 EJB2.1中定義部署描述符和介面是一樣的。在EJB3.0中部署描述符不再是必須的了;home介面也沒有了，你也不必實現業務介面(容器可以為你完成這些事情)。

比如，你可以使用@Stateless注釋標記類把Java類聲明為一個無狀態回話bean。對於有狀態回話bean來說，@Remove注釋可以用來標記一個特定的方法，通過這個注釋來說明在調用這個方法之後bean的實例將被清除掉。

為了減少描述組件的說明信息，規范組織還採納了由異常進行配置(configuration-by-exception)的手段，意思是你可以為所有的注釋提供一個明確的預設值，這樣多數常規信息就可以據此推斷得出。

新的持久化模型

新的實體bean也是一個加了注釋的簡單Java對象(POJO)。一旦它被EntityManager訪問它就成為了一個持久化對象，並且成為了持久化上下文(context)的一部分。一個持久化上下文與一個事務上下文是松耦合的;嚴格的講，它隱含的與一個事務會話共存。

實體關系也是通過注釋來定義的，O/R映射也是，並提供幾種不同的資料庫規范操作，在EJB2.1中這些要通過開發人員自己的設計模式或者其它技術來完成的(比如，自增長主鍵策略)。

深入研究

現在是時候詳細了解EJB3.0草案了。讓我們開始探討所有EJB中四種企業級bean，並看看他們在新的規范中是什麼樣子。

無狀態回話bean

在EJB3.0規范中，寫一個無狀態回話bean(SLSB)只需要一個簡單的Java文件並在類層加上@Stateless注釋就可以了。這個bean可以擴展javax.ejb.SessionBean介面，但這些不是必須的。

一個SLSB不再需要home介面，沒有哪類EJB再需要它了。Bean類可以實現業務介面也可以不實現它。如果沒有實現任何業務介面，業務介面會由任意public的方法產生。如果只有幾個業務方法會被暴露在業務介面中，這些方法可以使用@BusinessMethod注釋。預設情況下所有產 生的介面都是local(本地)介面，你也可以使用@Remote注釋來聲明這個介面為remote(遠程)介面。

下面的幾行代碼就可以定義一個HelloWorldbean了。而在EJB2.1中同樣的bean至少需要兩個介面，一個實現類和幾個空的實現方法，再加上部署描述符。

import javax.ejb.*;

/**
* A stateless session bean requesting that a remote business
* interface be generated for it.
*/
;@Stateless
;@Remote
public class HelloWorldBean {
public String sayHello() {
return "Hello World!!!";
}
}

有狀態回話bean

除了幾個SFSB的特別說明之外，有狀態回話bean(SFSB)和SLSB一樣精簡:

一個SFSB應該有一個方法來初始化自己(在EJB2.1中是通過ejbCreate()來實現的)。在EJB3.0的規范中建議這些初始化操作可以通過自定義方法完成，並把他們暴露在業務介面中。在使用這個bean之前由客戶端來調用相應的初始化方法。目前規范組織就是否提供一個注釋來標記某個方法用於初始化還存在爭議。

Bean的提供者可以用@Remove注釋來標記任何SFSB的方法，以說明這個方法被調用之後bean的實例將被移除。同樣，規范組織仍然在討論是否要有一種機制來處理這種特殊的情況，即當這個方法出現異常的情況下bean的實例是否被移除。

下面是對以上問題我個人的觀點:

是否應該有一個注釋來標明一個方法進行初始化呢?我的觀點是――應該有，這樣容器就可以在調用其他方法之前至少調用一個方法來進行初始化。這不僅可以避免不必要的錯誤(由於沒有調用初始化方法)而且可以使容器更明確的判斷是否可以重用SFSB實例。我暫且把這個問題放一放，規范組織只考慮為一個方法提供一個注釋來聲明它是一個初始化方法。

對於第二個問題我的觀點也是肯定的。這有利於Bean的提供者合客戶端程序對其進行控制。只有一個遺留的問題:那就是一旦調用這個方法失敗，是否能移除這個bean 的實例?答案是不能，但是它將會在回話結束的時候被移除。

消息驅動Bean

消息驅動Bean是唯一一種必須實現一個業務介面的Bean。這個介面指出bean支持的是哪一種消息系統。對於以JMS為基礎的MDB來說，這個介面是javax.jms.MessageListener。注意MDB業務介面不是一個真正意義上的業務介面，它只是一個消息介面。

實體Bean

實體Bean使用@Entity注釋來標記，所有實體bean中的屬性/欄位不必使用@Transient注釋來標記。實體bean的持久化欄位可以通過JavaBean-style機制或者聲明為public/protected欄位來實現。

實體bean可以使用助手類來描述其狀態，但是這些類的實例並沒有持久化唯一性(persistent identity)的特性(即，唯一標識這個bean的欄位等)，實際上這些助手類與他們的實體bean實例是緊密結合的;並且這些對象還是以非共享方式來訪問實體對象的。

實體關聯

EJB3.0同時支持Bean之間雙向的合單向的關聯，它們可以是一對一、一對多、多對一或者是多對多的關聯。然而雙向關聯的兩端還要分為自身端 (owning side)和對方端(inverse side)不同的端。自身端負責向資料庫通告關聯的變更。對於多對多的關聯自身端必須明確的聲明。實際上對方端通過isInverse=true進行注釋 (由此自身端就不必說明了而是由另一段推斷出)。看來上面的描述，規范組織還能說讓EJB變的簡單了嗎?

O/R映射

EJB3.0中的O/R映射模型也有了重要的改變，它從原來的abstract-persistence-schema-based變成了現在的Hibernate-inspired模式。盡管目前規范組織還在就此進行討論但是一個明確的模型將會出現在下一個版本的草案中。

舉例來說，O/R映射模型將通過bean類中的注釋來聲明。而且此方法還會指出對應的具體表和欄位。O/R映射模型提供了一套自有的SQL; 而且除了提供一些基本的SQL外還支持某些高層開發的功能。比如，有一個通過@Column注釋聲明的欄位columnDefinition，那麼可以寫這 樣的SQL:columnDefinition="BLOB NOT NULL"

客戶端程序模型

一個EJB客戶端可以通過@Inject注釋以一種「注入」的方式獲得一個bean的業務介面引用。你也可以使用另一個注釋 @javax.ejb.EJBContext.lookup()來完成上面的操作，但是規范中沒有告訴我們一個普通的Java客戶端怎樣獲得一個Bean 的實例，因為這個普通的Java客戶端是運行在一個客戶端容器中，它無法訪問@javax.ejb.EJBContex對象。現在還有另外一種機制來完成上面的工作那就是使用一個超級上下文環境對象:@javax.ejb.Context()。但是規范中沒有指出該如何在客戶端中使用這個對象。

EJB QL

EJB QL可以通過@NamedQuery來注釋。這個注釋有兩個成員屬性分別是name和queryString.一旦定義了這些屬性，就可以通過 EntityManager.createNamedQuery(name)來指向這個查詢。你也可以創建一個標準的JDBC風格的查詢並使用 EntityManager.createQuery(ejbqlString)或EntityManager.createNativeQuery (nativeSqlString)(這個方法用於執行一個本地查詢)來執行查詢。

EJB QL有兩個地方可以定義其參數。javax.ejb.Query介面提供了定義參數、指向查詢、更新數據等等方法。下面是一個EJBQL指向查詢的例子:

查看復制到剪切板列印

. ..
;@NamedQuery(
name="findAllCustomersWithName",
queryString="SELECT c FROM Customer c WHERE c.name LIKE :custName"
)
.. ..
;@Inject public EntityManager em;
customers = em.createNamedQuery("findAllCustomersWithName")
.setParameter("custName", "Smith")
.listResults();

下面列出了一些EJB QL的增強特性:

支持批量更新和刪除。

直接支持內連接和外連接。FETCH JOIN運行你指出關聯的實體，Order可以指定只查詢某個欄位。

查詢語句可以返回一個以上的結果值。實際上，你可以返回一個依賴的類比如下面這樣:

SELECT new CustomerDetails(c.id, c.status, o.count)
FROM Customer c JOIN c.orders o
WHERE o.count > 100 l 支持group by 和having。

支持where子句的嵌套子查詢。

在提交的EJB3.0草案中，EJB QL與標准SQL非常的接近。實際上規范中甚至直接支持本地的SQL(就像我們上面提到的那樣)。這一點對某些程序員來說也許有些不是很清楚，我們將在下面進行更詳細的講解。

多樣性

方法許可(Method permissions)可以通過@MethodPermissions和@Unchecked注釋來聲明;同樣的，事務屬性也可以通過 @TransactionAttribute注釋來聲明。規范中仍然保留資源引用和資源環境引用。這些一樣可以通過注釋來聲明，但是有一些細微的差別。比如，上下文(context)環境要通過注入工具控制。容器根據bean對外部環境引用自動初始化一個適當的已經聲明的實例變數。比如，你可以象下面這樣獲得一個數據源(DataSource):

;@Resource(name="myDataSource") //Type is inferred from variable
public DataSource customerDB;

在上面的例子中如果你不指定引用資源的名稱(name)那麼其中的customerDB會被認為是默認值。當所有的引用屬性都可得到時侯@Injec注釋就可以這樣寫:

查看復制到剪切板列印

1. ;@Inject public DataSource customerDB;

;@Inject public DataSource customerDB;

容器負責在運行時初始化customerDB數據源實例。部署人員必須在此之前在容器中定義好這些資源屬性。

更好的消息是:那些以前必須檢測的異常將一去不復返。你可以聲明任意的應用程序異常，而不必在再拋出或捕獲其他類似 CreateException和FinderException這樣的異常。容器會拋出封裝在javax.ejb.EJBException中的系統級異常或者只在必要時候拋出IllegalArgumentException或IllegalStateException異常。

EJB文件處理模式

在我們結束本節之前，讓我的快速的瀏覽一下容器提供商在EJB處理模式方面可能的變更。規范中對此並沒有明確的表態，但我可以想到至少兩種模式。

一種辦法是首先利用EJB文件生成類似於EJB2.1部署模式的文件(包括必要的介面和部署描述符)然後再用類似於EJB2.1的方式來部署這個EJB組件。當然，這樣產生的部署描述符可能並不標准但是它可以解決同一個容器對EJB2.1和EJB3.0兼容的問題。下面這幅圖描述了這一過程。

另一種方法是一種類似於JSP托放的部署模式。你可以把一個EJB文件放到一個預先定義的目錄下，然後容器會識別這個EJB並處理它，然後部署並使之可以使用。這種方法可以建立於上面那種方法之上，在支持反復部署時有很大的幫助。考慮到部署的簡單性也是EJB3.0規范的目的之一，我真誠的希望在下一個草案出來時能夠確定一個模式(至少能有一個非正式的)。

你有什麼想法?

EJB3.0規范的制定正在有序的進行，為了使EJB的開發變得更加容易，EJB規范組織作出的努力是有目共睹的。就像他們說的那樣，一切對會變得簡單，但做到這一點並不容易。目前已經定義了50個注釋標記(還有幾個將在下一個草案中發布)，每一個都有自己的預設規則和其他的操作。當然，我真的不希望EJB3.0變成EJB2.1的一個翻版"EJB 3.0 = EJB 2.1 for mmies"(希望這個等式不要成立)。最後，我還是忍不住要提一些我自己的觀點:

首先，規范確實使反復部署變得容易了，並且有一個簡單的模式來訪問運行時環境。我還是覺得home介面應該放棄。

在早期的EJB規范中，實體bean用於映射一個持久化存儲。理論上(也許只是理論上)可能需要把實體bean映射到一個遺留的EIS (enterprise information system)系統中。出於將來擴展的考慮這樣作是有好處的，並且可以使更多的業務數據模型採用實體bean。也因此其伴隨的復雜性使得實體bean不被看好。在本次提交的草案中，一個實體bean只是一個資料庫的映射。並且是基於非抽象持久化模式和簡單的數據訪問模式的更加簡單開發。

我對模型變更持保留態度，我認為在EJB中包含SQL腳本片斷並不是個好注意。一些開發人員完全反對包含某些「SQL片段 (SQLness)」(比如@Table 和 @Column注釋)。我的觀點是這些SQLness是好的，據此我們可以清楚的知道我們到底要資料庫作些什麼。但是某些SQL段我看來並不是很好，比如 columnDefinition="BLOB NOT NULL"，這使得EJB代碼和SQL之間的耦合太過緊密了。

盡管對於本地SQL的支持看似很誘人，其實在EJB代碼中嵌入SQL是一個非常糟糕的主意。當然，有些辦法可以避免在EJB中硬編碼SQL，但是這應該在規范中說明，而不能是某些開發人員自己定義的模式。

假設@Table注釋只用於類。在運行時通過@Table注釋的name屬性定義的表名稱將必須對應一個實際的資料庫表。規范對此應該給予清楚的說明和一致的模式。

規范還需要更清楚的說明客戶端編程模型，尤其是普通java客戶端。規范中所有的參考都假設或者隱含的使用EJB客戶端。而且規范中對客戶端的向後兼容方面也沒有給出明確的說法。

Transient注釋應該重新命名以避免和已有的transient關鍵字發生沖突。事實上，在這一點上我們更樂於稍微的背離一下 configuration-by-exception原則並且定義一個@Persistent注釋來明確的定義持久化欄位 @Persistent注釋 可以僅僅是一個標記注釋或者它可以有幾個屬性來關聯O/R映射注釋。

與其他規范的關聯

目前可能影響到EJB3.0的JSR有JSR175(java語言元數據工具)和JSR181(Java Web服務元數據)

JSR175已經初步完成並且不會和EJB3.0有太大的沖突;但是JSR181與EJB3.0有兩個關聯的地方:

Web service介面:EJB規范將採用一種機制適應JSR181以便可以把一個bean實現為一個Web service並告訴Web service如何被客戶端調用。

JSR 181計劃採用不同的機制來處理安全問題。在早期的規范中EJB建議使用一個一致的機制(MethodPermissions)，但是JSR 181計劃使用一個稍微不同的方式(SecurityRoles和SecurityIdentity注釋)。同樣的RunAs注釋的定義也存在這些許差別。這一問題還在解決中最終會在J2EE層的規范中維持其一致性。

在J2EE 1.5中的一些開發規范可能與EJB3.0有關聯。除了上面說到的幾個關聯之外現在沒有其他的開發規范與EJB3.0有沖突。

結束語

在使EJB的開發變得簡單高效之前，我們還有很長一段路要走。規范組織在降低EJB的開發難度方面起了個好頭。O/R映射模型的提議還處在早期階段，規范組織正在完善它。我希望它不要太復雜也不要與SQL過分的耦合。

『貳』 搭建集群伺服器tomcat,weblogic,jboss哪個性能最好

tomcat伺服器佔用資源少，穩定且免費。是一個輕量級的伺服器，主要是應用於中小型項目 ，當並發訪問的用戶比較少時，可以選用tomcat伺服器。tomcat伺服器是運行jsp和servlet的很好的容器，但是它不支持EJB等。項目在tomcat中的部署很方便。
weblogic伺服器：
而相比之下，weblogic伺服器則功能更強大了一些，它屬於應用級伺服器，它不盡支持jsp和servlet，而且還支持更多的java的規范。 他用於開發，集成，部署和管理大型的分布式web應用，網路應用和資料庫應用。這種大型的伺服器有著自己獨特的優勢，即標准領先（它的標准包括ejb，jsb，jms，jdbc，xml和wml），擴展性無限（它的體系架構具有高擴展性，主要包括哭戶籍連接的共享，資源pooling以及動態網頁和ejb組件集群），快速開發（憑借對ejb和jsp的支持，以及其對servlet組件的架構體系，可加速部署應用），部署靈活，可靠等。但是一般的系統部署基本不會用到它，因為一般非基於ejb等的分布式開發項目，僅僅用tomcat即可滿足我們的需求，所以無需動用重量級的weblogic。

jboss伺服器：
jboss是一個基於j2ee的開放源碼應用伺服器，它也是免費的。它是一個管理ejb的容器，jboss核心服務僅支持ejb伺服器，所以是不包括jsp和servlet的web容器。當然了，它可以和tomcat等進行綁定使用來同時支持jsp，servlet以及ejb的規范。jboss有一個典型的特點：當有servlet的系統調用到jboss裡面的ejb時不經過網路，因為jboss和web伺服器在同一個java虛擬機中運行，這可以大大提高運行效率和安全性。
這三個只有weblogic是商業的軟體，所以你希望性能好的話，就用weblogic最好。

『叄』 JAVA與J2EE

隨著Internet網路的迅速發展，基於互聯網的企業應用要求軟體平台具有開放性、分布性和平台無關性。於是就相繼出現了RPC/COM/CORBA等技術，但這些技術在實際應用中存在著許多不足和局限。它們的特定協議難以通過防火牆，因而不適於Web上的應用開發。為了進一步開發基於Web的應用，出現了Sun公司的Sun ONE（Open Net Environment 開發網路環境）和Microsoft公司的.NET等Web 服務技術體系。

Sun ONE體系結構以Java語言為核心，包括J2SE/J2EE/J2ME和一系列的標准、技術及協議。它包括Sun獨有的iPlanet軟體系列，其中有在市場上受歡迎的LDAP目錄伺服器軟體，以及Forte for Java——便於在任何環境下書寫Java 語言的軟體工具。我們很容易就能從網上免費獲得和使用包括Java 集成開發環境、Java資料庫和中間件（Application Server）伺服器等產品，以及它們的源代碼。Sun ONE更接近或能滿足互聯網在智能化Web服務方面對分布性、開發性和平台無關性的要求。

隨著Java技術的不斷發展，它根據市場進一步細分為:針對企業網應用的J2EE（Java 2 Enterprise Edition）、針對普通PC應用的J2SE（Java 2 Standard Edition）和針對嵌入式設備及消費類電器的J2ME（Java 2 Micro Edition）三個版本。本文就Sun ONE的Java核心應用——J2SE/J2EE/J2ME作一些介紹。

J2EE技術應用

J2EE是Sun公司推出的一種全新概念的模型，比傳統的互聯網應用程序模型更有優勢。

J2EE模型

J2EE的應用編程模型（J2EE Blueprints）提供了一種用於實施基於J2EE多層應用的文檔和實例套件的體系模型，簡化了這項復雜的工作。它被開發人員用作設計和優化組件，以便開發人員從策略上對開發工作進行分工。

J2EE應用編程模型要求開發者將自己的工作分成兩類：商業邏輯和表示邏輯，其餘則由系統資源自動處理，不必為中間層管道進行編碼。這樣，開發人員就能將更多的時間花在商業邏輯和表示邏輯上。對重視縮短項目周期的公司來說，這種轉變深受歡迎。

J2EE平台

J2EE平台是運行J2EE應用的標准環境，由J2EE部署規范（一套所有J2EE平台產品都必須支持的標准）、IETF標准集和CORBA標准組成。最新的J2EE平台還添加了JavaBean組件模型。開發人員可以利用JavaBean組件模型來自定義Java類實例，並可通過已定義的事件訪問Java類。

J2EE支持EJB，因此開發人員可以執行多用戶交易功能。當在J2EE伺服器上運行時，Enterprise JavaBeans將應用邏輯分成可再利用和可擴展的代碼段。Enterprise JavaBeans並不是新特徵，但是通過定義標准客戶端和服務API，J2EE增強了它的能力和可移植性。

EJB在伺服器的一個容器內運行，提供所有典型的中間層服務，如事務管理、安全、遠程客戶連接、生存周期管理和資料庫連接緩沖。為了讓事務系統在存在EJB容器的情況下運行，開發人員只需在部署描述文件中定義Beans的事務屬性即可。

J2EE通過定義一組標準的結構來實現它的優勢，例如：

1.J2EE Application Programming Model，是一種用於開發多層次、瘦型客戶用戶程序的標准設計模型；

2. J2EE Platform，是一個標準的平台，用來整合J2EE的應用程序，並指定一系列的介面和方法；

3. J2EE Compatibility Test Suite，是一套兼容測試組件，用來檢測產品是否同J2EE平台兼容；

4.J2EE Reference Implementation，用來示範J2EE的能力。

J2EE伺服器

Sun的J2EE伺服器通過Java 命名和目錄介面（JNDI）、認證、HTTP及與Enterprise JavaBeans兼容的能力，提供命名和目錄服務。JNDI是Java平台的一種標准擴展版，向企業內的命名和目錄服務提供具有Java功能的，帶有統一介面的應用，包括LDAP。

J2EE伺服器還利用了Java Servlet技術。Java Servlet可以看作是運行在伺服器上的一個小程序，它向開發人員提供以組件為基礎創建基於Web應用的、獨立於平台的方法。它不像利用CGI那樣具有性能局限。Java Servlet是一種擴展Web伺服器功能的簡單技巧。由於它是用Java編寫的，因而能夠訪問整個Java API庫，也包括用於訪問企業資料庫的JDBC API。

JSP是Java Servlet的一種擴展。Java Servlet提供開發和顯示來自伺服器的互動式Web頁。如今JSP又有了進一步的改進，它使得創建和支持靜態模板和動態內容相結合的HTML和XML頁面更加容易。

安全性

J2EE平台定義了一種標準的公開存取控制規則，當程序在企業平台上開發時就已被程序師定義和解釋了。J2EE也需要提供一個標準的注冊機制，以便應用程序不會將這些注冊機制和邏輯相混合，從而使相同的工作執行於大量的不同環境中時並不需要改變源代碼。例如：J2EE應用程序開發人員可以指定幾個安全級別，當用戶訪問數據時，他們可寫出代碼來檢查當前用戶許可權的級別。在開發階段，開發人員賦予多組用戶適當的安全級，使應用程序在執行限制操作之前能夠容易的判斷限制級。

J2EE 平台是Java技術企業級應用的最佳平台，它可以讓程序員迅速、快捷地開發和分布企業級應應用程序。以下便是它的相關技術：

1.Enterprise JavaBeans Architecture，企業級JavaBeans 定義了一個應用程序介面。它可以使程序員迅速開發、發布和管理跨平台的、基於組件的企業級應用程序。

2.JavaServer Pages，JSP 技術提供了一種簡單、快速的方法來創建動態網頁。通過它，可以快速地開發基於Web的應用程序，並且這些應用程序都是與平台無關的。因為JSP與ASP很相似，所以熟悉ASP的人學習它就很容易了。

3.Java Servlet，提供了應用程序介面。通過它可以簡單快速地開發並擴展伺服器功能。就發展趨勢來看，它將來有可能取代CGI。

4.J2EE Connector，提供了一種標准結構來聯接不同的企業信息平台。

5.Java Naming and Directory Interface(JNDI)，在Java 平台與商業信息之間，JNDI提供了統一、無縫的標准化連接。通過使用JNDI，程序員可以在企業多命名與目錄服務之間傳送Java 應用程序。

6.Java Interface Definition Language(JIDL),通過使用CORBA，可以提供協同工作的能力。JIDL包括一個IDL-to-Java 編譯器和支持IIOP（Internet Inter-Orb Protocol）的ORB。

7.JDBC,幾乎是為所有的資料庫提供了統一的介面，同時可以創建高級工具和介面。

8.Java Message Service(JMS)，它幾乎規范了所有企業級消息服務，如可靠查詢、發布消息、訂閱雜志等各種各樣的PUSS/PULL技術的應用，並且為它們提供了一個標准介面。

9.Java Transaction API(JTA)，為分布式系統中可處理的應用程序規定了一個高級的管理規范。

10.JavaMail,JavaMail應用程序介面提供了一整套模擬郵件系統的抽象類。通過JavaMail，可以創建郵件或消息應用程序。

11.RMI-IIOP,使用它就可以只用Java 技術和Java RMI介面開發客戶機與伺服器的遠程介面。

J2EE使用固定的文件格式捆綁某個模塊：用.ear文件捆綁J2EE應用程序；用.jar捆綁Enterprise Bean。例如，一個.ear文件包含一個.xml文件作為其分布描述，還包含一個或多個.jar和.war文件；一個.jar文件除了包含它的分布描述外，還包含了作為Enterprise bean的.class文件。

J2EE應用程序的開發階段分為四步：1.Enterprise Bean創建；2.Web Component創建；3.J2EE應用程序裝配；4.J2EE應用程序分布。以下是J2EE兼容產品部分列表：

BEA WebLogic Server 6.0、Borland App Server、HP Bluestone Total-e-Server、IBM WebSphere Application Server、IONA iPortal Application Server、iPlanet Application Server、Macromedia JRun Server、Oracle 9i Application Server、SilverStrean Application Server、Sybase EAServer、TogetherSoft ControlCenter、Java 2 SDK Enterprise Edition。

J2ME技術的應用

J2ME（Java 2 Platform Micro Edition）是為無線電子市場所設計的，包括JVM規范和API規范。其API規范是基於J2SE（Java 2 Standard Editon)的。J2ME 定義了一套合適的類庫和虛擬機技術。這些技術可以使用戶、服務提供商和設備製造商通過物理（有線）連接或無線連接，按照需要隨時使用豐富的應用程序。

J2ME又被稱為Java 2 微型版，被使用在各種各樣的消費電子產品上，例如智能卡、手機、PDA、電視機頂盒等方面。當然了，J2ME也提供了Java語言一貫的特性，那就是跨平台和安全網路傳輸。它使用了一系列更小的包，而且Javax.microedition.io 為J2SE包的子集。J2ME可以升級到J2SE和J2EE。

在J2ME出現之前，我們更多接觸到的是Java卡（Java Card）、嵌入式Java（Embedded Java）和實時Java（Real Time Java）等。其中Java卡是針對SIM卡、智能卡等設備而定製的最小Java子集，比J2ME還要小，移植性也不強。嵌入式Java則針對特殊用戶自行配置Java類庫和VM（Virtual Machine，虛擬機）。它對資源需求極小，可運行在無圖形用戶介面和網路的設備上，可以添加用戶專用的API，但是它就無法移植。實時Java是由IBM領導的實時定製Java專家組負責實施的，現在還在不斷完善中。不過，從嚴格意義上來說，它們都不是真正的J2ME。

像其它版本一樣，J2ME具有很多Java技術特性，主要有：

1.可以在各種支持Java的設備上運行；

2.代碼短小；

3.充分利用Java語言的優勢；

4.安全性好；

5.用J2ME實現的應用可以方便地升級到J2SE、J2EE。

J2ME的配置和框架

為了支持用戶和嵌入式市場提出的靈活性和可定製性要求，J2ME被設計得更加模塊化和可縮放化。J2ME在設備原有的操作系統上建造了3層軟體來實現這種要求：

1.JVM層，這層基於宿主操作系統，按照某一種J2ME的配置，實現了JVM。

2.配置層，這層對於用戶可見度要低一些，但對框架層非常重要。它針對「水平」市場的需求，定義了Java虛擬機的最小功能集和Java類庫的最小集合。在某種意義上，配置層定義了開發者在所有設備上都可以使用Java特性和類庫的「最小公分母」。

3.框架層，這層對於用戶和應用程序提供者來說是最常見的。它針對「垂直」市場的需求，定義了Java虛擬

『肆』 消息隊列(mq)是什麼

是生產者先將消息投遞一個叫隊列的容器中，然後再從這個容器中取出消息，最後再轉發給消費者。

消息隊列是 Microsoft 的消息處理技術，它在任何安裝 Microsoft Windows 的計算機組合中，為任何應用程序提供消息處理和消息隊列功能，無論這些計算機是否在同一個網路上或者是否同時聯機。

消息隊列網路是能夠相互間來回發送消息的任何一組計算機。網路中的不同計算機在確保消息順利處理的過程中扮演不同的角色。它們中有些提供路由信息以確定如何發送消息，有些保存整個網路的重要信息，而有些只是發送和接收消息。

消息隊列的類型介紹：

消息隊列目前主要有兩種類型：POSIX消息隊列以及系統V消息隊列，系統V消息隊列目前被大量使用。每個消息隊列都有一個隊列頭，用結構struct msg_queue來描述。隊列頭中包含了該消息隊列的大量信息。包括消息隊列鍵值、用戶ID、組ID、消息隊列中消息數目等等。

消息隊列就是一個消息的鏈表，可以把消息看作一個記錄，具有特定的格式以及特定的優先順序。對消息隊列有寫許可權的進程可以向消息隊列中按照一定的規則添加新消息；對消息隊列有讀許可權的進程則可以從消息隊列中讀走消息。消息隊列是隨內核持續的。