A. 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過分的耦合。
B. j2ee都包括什麼
什麼是J2EE呢？從整體上講，J2EE是使用Java技術開發企業級應用的一種事實上的工業標准(Sun公司出於其自身利益的考慮，至今沒有將Java及其相關技術納入標准化組織的體系)，它是Java技術不斷適應和促進企業級應用過程中的產物。目前，Java平台有三個版本：適用於小型設備和智能卡的J2ME(Java 2 Platform Micro Edition)、適用於桌面系統的J2SE和適用於企業級應用的J2EE。Sun推出J2EE的目的是為了克服傳統Client/Server模式的弊病，迎合Browser/Server架構的潮流，為應用Java技術開發伺服器端應用提供一個平台獨立的、可移植的、多用戶的、安全的和基於標準的企業級平台，從而簡化企業應用的開發、管理和部署。J2EE是一個標准，而不是一個現成的產品。各個平台開發商按照J2EE規范分別開發了不同的J2EE應用伺服器，J2EE應用伺服器是J2EE企業級應用的部署平台。由於它們都遵循了J2EE規范，因此，使用J2EE技術開發的企業級應用可以部署在各種J2EE應用伺服器上。
為了推廣並規范化使用J2EE架構企業級應用的體系架構，Sun同時給出了一個建議性的J2EE應用設計模型：J2EE Blueprints。J2EE Blueprints提供了實施J2EE企業級應用的體系架構、設計模式和相關的代碼，通過應用J2EE Blueprints所描述的體系模型，能夠部分簡化架構企業級應用這項復雜的工作。J2EE Blueprints是開發人員設計和優化J2EE組件的基本原則，同時為圍繞開發工作進行職能分工給出了指導性策略，以幫助應用開發設計人員合理地分配技術資源。
下面我們參照J2EE Blueprints，結合最新版的J2EE規范(J2EE 1.4)，從整體上闡述如何使用J2EE架構企業級應用。
圖2給出了使用J2EE架構企業級應用的體系架構。J2EE將組成一個完整企業級應用的不同部分納入不同的容器(Container)，每個容器中都包含若干組件(這些組件是需要部署在相應容器中的)，同時各種組件都能使用各種J2EE Service/API。J2EE容器包括：
◆ Web容器伺服器端容器，包括兩種組件JSP和Servlet，JSP和Servlet都是Web伺服器的功能擴展，接受Web請求，返回動態的Web頁面。Web容器中的組件可使用EJB容器中的組件完成復雜的商務邏輯。
◆ EJB容器 伺服器端容器，包含的組件為EJB(Enterprise JavaBeans)，它是J2EE的核心之一，主要用於伺服器端的商業邏輯的實現。EJB規范定義了一個開發和部署分布式商業邏輯的框架，以簡化企業級應用的開發，使其較容易地具備可伸縮性、可移植性、分布式事務處理、多用戶和安全性等。
◆ Applet容器客戶端容器，包含的組件為Applet。Applet是嵌在瀏覽器中的一種輕量級客戶端，一般而言，僅當使用Web頁面無法充分地表現數據或應用界面的時候，才使用它。Applet是一種替代Web頁面的手段，我們僅能夠使用J2SE開發Applet，Applet無法使用J2EE的各種Service和API，這是為了安全性的考慮。
◆ Application Client容器 客戶端容器，包含的組件為Application Client。Application Client相對Applet而言是一種較重量級的客戶端，它能夠使用J2EE的大多數Service和API。
通過這四個容器，J2EE能夠靈活地實現前面描述的企業級應用的架構。
在View部分，J2EE提供了三種手段：Web容器中的JSP(或Servlet)、Applet和Application Client，分別能夠實現面向瀏覽器的數據表現和面向桌面應用的數據表現。Web容器中的Servlet是實現Controller部分業務流程式控制制的主要手段；而EJB則主要針對Model部分的業務邏輯實現。至於與各種企業資源和企業級應用相連接，則是依靠J2EE的各種服務和API。
在J2EE的各種服務和API中，JDBC和JCA用於企業資源(各種企業信息系統和資料庫等)的連接，JAX-RPC、JAXR和SAAJ則是實現Web Services和Web Services連接的基本支持。
J2EE的各種組件
我們就J2EE的各種組件、服務和API，進行更加詳細的闡述，看看在開發不同類型的企業級應用時，根據各自需求和目標的不同，應當如何靈活使用並組合不同的組件和服務。
· Servlet
Servlet是Java平台上的CGI技術。Servlet在伺服器端運行，動態地生成Web頁面。與傳統的CGI和許多其它類似CGI的技術相比，Java Servlet具有更高的效率並更容易使用。對於Servlet，重復的請求不會導致同一程序的多次轉載，它是依靠線程的方式來支持並發訪問的。
· JSP
JSP(Java Server Page)是一種實現普通靜態HTML和動態頁面輸出混合編碼的技術。從這一點來看，非常類似Microsoft ASP、PHP等技術。藉助形式上的內容和外觀表現的分離，Web頁面製作的任務可以比較方便地劃分給頁面設計人員和程序員，並方便地通過JSP來合成。在運行時態，JSP將會被首先轉換成Servlet，並以Servlet的形態編譯運行，因此它的效率和功能與Servlet相比沒有差別，一樣具有很高的效率。
· EJB
EJB定義了一組可重用的組件：Enterprise Beans。開發人員可以利用這些組件，像搭積木一樣建立分布式應用。在裝配組件時，所有的Enterprise Beans都需要配置到EJB伺服器(一般的Weblogic、WebSphere等J2EE應用伺服器都是EJB伺服器)中。EJB伺服器作為容器和低層平台的橋梁管理著EJB容器，並向該容器提供訪問系統服務的能力。所有的EJB實例都運行在EJB容器中。EJB容器提供了系統級的服務，控制了EJB的生命周期。EJB容器為它的開發人員代管了諸如安全性、遠程連接、生命周期管理及事務管理等技術環節，簡化了商業邏輯的開發。EJB中定義了三種Enterprise Beans：
◆ Session Beans
◆ Entity Beans
◆ Message-driven Beans
· JDBC
JDBC(Java Database Connectivity，Java資料庫連接)API是一個標准SQL(Structured Query Language，結構化查詢語言)資料庫訪問介面，它使資料庫開發人員能夠用標准Java API編寫資料庫應用程序。JDBC API主要用來連接資料庫和直接調用SQL命令執行各種SQL語句。利用JDBC API可以執行一般的SQL語句、動態SQL語句及帶IN和OUT參數的存儲過程。Java中的JDBC相當與Microsoft平台中的ODBC(Open Database Connectivity)。
· JMS
JMS(Java Message Service，Java消息服務)是一組Java應用介面，它提供創建、發送、接收、讀取消息的服務。JMS API定義了一組公共的應用程序介面和相應語法，使得Java應用能夠和各種消息中間件進行通信，這些消息中間件包括IBM MQ-Series、Microsoft MSMQ及純Java的SonicMQ。通過使用JMS API，開發人員無需掌握不同消息產品的使用方法，也可以使用統一的JMS API來操縱各種消息中間件。通過使用JMS，能夠最大限度地提升消息應用的可移植性。 JMS既支持點對點的消息通信，也支持發布/訂閱式的消息通信。
· JNDI
由於J2EE應用程序組件一般分布在不同的機器上，所以需要一種機制以便於組件客戶使用者查找和引用組件及資源。在J2EE體系中，使用JNDI(Java Naming and Directory Interface)定位各種對象，這些對象包括EJB、資料庫驅動、JDBC數據源及消息連接等。JNDI API為應用程序提供了一個統一的介面來完成標準的目錄操作，如通過對象屬性來查找和定位該對象。由於JNDI是獨立於目錄協議的，應用還可以使用JNDI訪問各種特定的目錄服務，如LDAP、NDS和DNS等。
· JTA
JTA(Java Transaction API)提供了J2EE中處理事務的標准介面，它支持事務的開始、回滾和提交。同時在一般的J2EE平台上，總提供一個JTS(Java Transaction Service)作為標準的事務處理服務，開發人員可以使用JTA來使用JTS。
· JCA
JCA(J2EE Connector Architecture)是J2EE體系架構的一部分，為開發人員提供了一套連接各種企業信息系統(EIS，包括ERP、SCM、CRM等)的體系架構，對於EIS開發商而言，它們只需要開發一套基於JCA的EIS連接適配器，開發人員就能夠在任何的J2EE應用伺服器中連接並使用它。基於JCA的連接適配器的實現，需要涉及J2EE中的事務管理、安全管理及連接管理等服務組件。
· JMX
JMX(Java Management Extensions)的前身是JMAPI。JMX致力於解決分布式系統管理的問題。JMX是一種應用編程介面、可擴展對象和方法的集合體，可以跨越各種異構操作系統平台、系統體系結構和網路傳輸協議，開發無縫集成的面向系統、網路和服務的管理應用。JMX是一個完整的網路管理應用程序開發環境，它同時提供了廠商需要收集的完整的特性清單、可生成資源清單表格、圖形化的用戶介面；訪問SNMP的網路API；主機間遠程過程調用；資料庫訪問方法等。
· JAAS
JAAS(Java Authentication and Authorization Service)實現了一個Java版本的標准Pluggable Authentication Mole(PAM)的框架。JAAS可用來進行用戶身份的鑒定，從而能夠可靠並安全地確定誰在執行Java代碼。同時JAAS還能通過對用戶進行授權，實現基於用戶的訪問控制。
· JACC
JACC(Java Authorization Service Provider Contract for Containers)在J2EE應用伺服器和特定的授權認證伺服器之間定義了一個連接的協約，以便將各種授權認證伺服器插入到J2EE產品中去。
· JAX-RPC
通過使用JAX-RPC(Java API for XML-based RPC)，已有的Java類或Java應用都能夠被重新包裝，並以Web Services的形式發布。JAX-RPC提供了將RPC參數(in/out)編碼和解碼的API，使開發人員可以方便地使用SOAP消息來完成RPC調用。同樣，對於那些使用EJB(Enterprise JavaBeans)的商業應用而言，同樣可以使用JAX-RPC來包裝成Web服務，而這個Web Servoce的WSDL界面是與原先的EJB的方法是對應一致的。JAX-RPC為用戶包裝了Web服務的部署和實現，對Web服務的開發人員而言，SOAP/WSDL變得透明，這有利於加速Web服務的開發周期。
· JAXR
JAXR（Java API for XML Registries）提供了與多種類型注冊服務進行交互的API。JAXR運行客戶端訪問與JAXR規范相兼容的Web Servcices，這里的Web Services即為注冊服務。一般來說，注冊服務總是以Web Services的形式運行的。JAXR支持三種注冊服務類型：JAXR Pluggable Provider、Registry-specific JAXR Provider、JAXR Bridge Provider(支持UDDI Registry和ebXML Registry/Repository等)。
· SAAJ
SAAJ(SOAP with Attachemnts API for Java)是JAX-RPC的一個增強，為進行低層次的SOAP消息操縱提供了支持。
下面我們通過假設一個企業應用的J2EE實現，來了解各種組件和服務的應用。假設應用對象是計算機產品的生產商/零售商的銷售系統，這個銷售系統能夠通過自己的網站發布產品信息，同時也能將產品目錄傳送給計算機產品交易市場。銷售系統能夠在線接受訂單(來自自己的Web網站或者來自計算機產品交易市場)，並隨後轉入內部企業管理系統進行相關的後續處理。
參見圖3，這個企業應用可以這種方式架構。該企業應用的核心是產品目錄管理和產品定購管理這兩個業務邏輯，使用EJB加以實現，並部署在EJB容器中。由於產品目錄和定購信息都需要持久化，因此使用JDBC連接資料庫，並使用JTA來完成資料庫存取事務。
然後使用JSP/Servlet來實現應用的Web表現：在線產品目錄瀏覽和在線定購。為了將產品目錄發送給特定的交易市場，使用JMS實現非同步的基於消息的產品目錄傳輸。為了使得更多的其它外部交易市場能夠集成產品目錄和定購業務，需要使用Web Services技術包裝商業邏輯的實現。由於產品定購管理需要由公司內部雇員進行處理，因此需要集成公司內部的用戶系統和訪問控制服務以方便雇員的使用，使用JACC集成內部的訪問控制服務，使用JNDI集成內部的用戶目錄，並使用JAAS進行訪問控制。由於產品訂購事務會觸發後續的企業ERP系統的相關操作(包括倉儲、財務、生產等)，需要使用JCA連接企業ERP。
最後為了將這個應用納入到企業整體的系統管理體系中去，使用Application Client架構了一個管理客戶端(與其它企業應用管理應用部署在一台機器上)，並通過JMX管理這個企業應用。
C. 懂java的請進！！！急！
1、應該是從事j2ee方向。
2、eclipse編程開發工具、container是java中的一個容器、struts是一個MVC框架（有特色的部分是自定義標簽）、hibernate（用來做持久層）、spring（也是一個MVC框架）、sql*資料庫方面、xml配置文件。
從這些來看，可能是用eclipse來進行編碼工作，container做容器。struts+spring+hibernate配合起來用。
3、這些東西基本上都是做一個項目要用到的東西，是都要學的。
4、如果是真正懂技術的項目經理來講的話，應該是會學到一些東西的，畢竟人家有經驗嘛。
5、安排的很有針對性，建議自己打好基礎，技術都是相通的，掌握了基礎是最重要的。
6、以上回答均是出自本人，並未轉載，說的不好，別仍雞蛋我
D. java中的EJB容器是什麼
EJB容器：Enterprise java bean 容器。更具有行業領域特色。他提供給運行在其中的組件EJB各種管理功能。只要滿足J2EE規范的EJB放入該容器，馬上就會被容器進行高效率的管理。並且可以通過現成的介面來獲得系統級別的服務。例如郵件服務、事務管理。WEB容器和EJB容器在原理上是大體相同的，更多的區別是被隔離的外界環境。WEB容器更多的是跟基於HTTP的請求打交道。而EJB容器不是。它是更多的跟資料庫、其它服務打交道。但他們都是把與外界的交互實現從而減輕應用程序的負擔。例如SERVLET不用關心HTTP的細節，直接引用環境變數session,request,response就行、EJB不用關心資料庫連接速度、各種事務控制，直接由容器來完成。
可以參考這篇文章：http://blog.csdn.net/jnqqls/article/details/9068681