A
Attached Object（附屬對象）- EJB 3.0 - 表示實體 Bean 的一個實例，該實例及其所持的來自數據庫的數據目前被實體管理器（Entity Manager）所管理。
B
Bean Class（Bean 類）- EJB 1.x，EJB 2.x，EJB 3.0 - Bean 類是 EJB 組件的產物，這個 EJB 組件持有業務邏輯的實現。在面向對象表示法中，我們會把這個類視爲實現類（例如 CustomerImpl）。對於 EJB 我們則使用“Bean 類”這個術語（例如 CustomerBean）。
Bean-managed Persistence（Bean 管理的持久化）- EJB 2.x，EJB 3.0 - 實體 Bean 的兩種持久化機制之一。當實體 Bean 採取 Bean 管理的持久化（BMP）時，開發人員須負責實現持久化邏輯。總的來說，這意味着你必須將實體 Bean 的持久化屬性恰如其分地與持久層進行匹配。要達到這個目的，你必須在 Bean 類中爲持久層實現訪問邏輯（例如，使用 JDBC 訪問數據庫，或使用 JCA 訪問既有系統）。
- EJB 容器決定操作產生的時間。
- 開發人員決定完成一些什麼操作。
注意：在 EJB 3.0 中，Bean 管理的持久化已經不復存在。
BMP - EJB 2.x，EJB 3.0 - Bean-managed Persistence（Bean 管理的持久化）的縮寫。
Business Interface（業務接口）- EJB 3.0 - 業務接口包含一個 EJB 組件中業務方法的聲明。此外，它是 EJB 3.0 裏描述 POJI 類型接口的術語。與 EJB 2.x 組件接口不同，這些業務接口不能擴展 javax.ejb.EJB[Local]Object。同一個業務接口不允許同時作爲一個 EJB 組件的本地和遠程業務接口。
會話 Bean（Session Beans）必須有業務接口。消息驅動Bean（Message-Driven Beans）必須擁有一個符合其使用的消息類型（例如 javax.jms）的（業務）接口。在 EJB 3.0，消息驅動 Bean 的這個接口也可以被稱作業務接口，不過該接口要比功能性接口更技術化一些。EJB 3 實體不一定需要用業務接口來表現。
C
Callback Methods（回調方法）- EJB 2.x，EJB 3.x - 在 EJB 2.x 裏，Bean 類必須按照 Bean 的類型（javax.ejb.SessionBean、javax.ejb.MessageDrivenBean 或 javax.ejb.EntityBean）實現其回調接口。首先，這些接口指明你擁有的 EJB 類型。其次，這些接口聲明瞭回調方法，EJB 容器調用這些方法，管理EJB 組件的生命週期。開發人員必須在 Bean 類中實現接口聲明的回調方法。
在 EJB 3.0 中，上述回調接口不再需要由 Bean 類來實現了。由於開發人員不再被強制去實現這些回調方法，開發時間及工作量均得以縮減。但是，仍然可以使用一系列已定義的標註（annotations）來接手 EJB 組件的生命週期管理，標註可以標記在任意的方法上，這樣可以根據使用的標註在定義的時間執行這些方法。你可以把這些標註用在所有的 EJB 類型上。標註 @PostConstruct、@PreDestroy、@PostActivate 和 @PrePassivate 可被應用於會話 Bean 和消息驅動 Bean 上；而對於 EJB 3 實體來說，下列標註可用：@PrePersist、@PostPersist、@PreRemove、@PostRemove、@PreUpdate、 @PostUpdate 和 @PostLoad。
CMP - EJB 2.x，EJB 3.0 - Container-managed Persistence（容器管理的持久化）的縮寫。
Component Interface（組件接口）- EJB 1.x，EJB 2.x，EJB 3.0 - 組件接口是 EJB 組件的業務接口。它有兩種形式：作爲本地接口（僅能在同一進程內訪問→參見 Local Interface）和/或作爲遠程接口（可以跨機器和進程進行訪問→參見 Remote Interface）。組件接口必須擴展自 javax.ejb.EJB[Local]Object。
Configuration by Exception（按異常配置）- EJB 3.0 - 按異常配置的方法隨着 EJB 3.0 一起被引入。這個方法的目標之一就是減少對於 EJB 組件的配置和/或者開發的開發次數和工作量。
開發人員只須在異常情況下（正因如此稱爲“按異常配置”）爲 EJB 組件提供配置或者運行期控制信息，也就是說，僅須在所期望的行爲與已定義且給定的某個類型 EJB 組件的標準行爲相悖的情況下提供。其目標是爲了減少對配置參數的顯式說明的必要性，這些配置參數用於通常預期的EJB組件行爲以及對EJB容器的需求。
具體言之，這就是說在 EJB 3.0 中，許多功能和/或行爲默認情況下已經爲 EJB 組件設置好了。這些缺省行爲應涵蓋絕大多數 EJB 組件（和/或相應 EJB類型）的典型用例。假如標準行爲不適合需求的情況，那麼開發人員可以很容易地重載這些默認數值和/或標準行爲。
Container-Managed Persistence（容器管理的持久化）- EJB 2.x，EJB 3.0 - 實體 Bean 的兩種持久化機制之一。如果你正在使用容器管理的持久化（CMP），你可以不必編寫代碼處理實體 Bean 與持久層間的同步。代碼是由應用服務器的工具生成的。開發人員的任務只需要集中在持久化屬性的聲明及不同實體 Bean 之間的關係。運行時期的同步由 EJB 容器的一個特殊部件來完成——即所謂的“持久化管理器”。
D
DD - EJB 1.x，EJB 2.x，EJB 3.0 - Deployment Descriptor（部署描述符）的縮寫。
Detached Entity（遊離實體，也譯作“脫管實體”）- EJB 3.0 - 參見 Detached Object（遊離對象）。
Detached Object（遊離對象，也譯作“脫管對象”）- EJB 3.0 - 表示一個 EJB 3 實體的實例，該實例脫離了將它持久化或者取得它的持久化上下文環境。因此，這樣的對象不再受實體管理器所管理，其數據與數據庫之間的同步不再可能進行。但應用程序仍舊可以使用遊離對象，可以訪問其可用的狀態，並進行更改，但（實體管理器）不會對這些操作進行跟蹤。
遊離對象的產生可以分爲很多種情況。例如，對一個 EJB 3 實體進行序列化就是其中之一。經過序列化，EJB 3 實體將轉化成一個遊離對象。
Dependency Injection（依賴注射）- EJB 3.0 - 依賴注射（DI）這個名詞是反轉控制（Inversion of Control）模式的一個特殊形式。Martin Fowler 發明了這個術語（參看 http://martinfowler.com/articles/injection.html）——這是因爲目前的一些輕量級容器/框架中反轉控制的使用形式，其性質更像是類/對象的引用的注射。
將 DI 引入EJB 3 的動機是爲了簡化對 EJB 組件資源的查找。我們不再需要在 EJB 組件中編寫任何基於 JNDI API 的代碼了——即便你還是可以隨意使用它。
EJB 的 DI 技術意味着開發人員可以從編寫基於 JNDI API 代碼實現資源查找的桎梏中解脫出來。相反他只須在 EJB 組件中標註實例變量或者 setter 方法，或者在相應 XML 中聲明這樣的依賴說明，就可以從容器中請求到資源的引用。接着，容器在運行期，執行 EJB 組件某個方法之前，把必要或者請求的資源引用注射到 EJB 組件中，也就是說，EJB 組件不再需要主動從它的容器中一個接一個地請求資源，取而代之的是通過容器的注射來取得它們。
使用標註（annotations）比使用 XML 要方便許多，它將是 EJB 3 的首選方案。在這裏 DI 只是訪問 JNDI context 及獲取引用的一個簡化機制。
Deployment Descriptor（部署描述符）- EJB 1.x，EJB 2.x，EJB 3.0 - 部署描述符是一個 XML 文件，它包含生成、執行 EJB 組件的編譯期和運行期信息。開發人員通過簡單地在部署描述符中聲明某些關鍵字的方式實現功能和/或行爲，而不需要編寫一行代碼，因此這種方式又稱作聲明式編程（declarative programming）。例如 EJB 組件的事務處理行爲就是通過這種方式控制的。
E
Eager Load（貪婪加載，亦作“提前加載”）- EJB 3.0 - 貪婪加載是 Java Persistence API 中定義的兩種數據抓取策略（fetching strategies）之一。簡而言之，貪婪加載表示 EJB 3.0 實體的持久化數據是從數據庫中直接且完整地讀取，並且被寫入該 EJB 3.0 實體的相應實例屬性中的。此 EJB 3.0 實體中所有被引用到的持久化實體（EJB 3.0 實體或者可嵌入對象）也將以類似的方式加載。事實上，貪婪加載實現的實際特點和廠商的各自實現有關。
貪婪加載的優點是，數據在一個回合中一次性抓取完畢。當應用程序訪問這些屬性時，它們的數據已經被取好，擺在那裏了。而對較大的持久化對象網絡或者對象樹使用貪婪加載的缺點是會導致漫長的加載時間以及大量的內存消耗。
EJB - EJB 1.x，EJB 2.x，EJB 3.0 - Enterprise JavaBeans 的縮寫，Java EE 平臺下服務器端組件模型的名稱。
EJB 3.0 Entity（EJB 3.0 實體）- EJB 3.0 - EJB 3.0 實體是一個輕量級的持久化業務域對象。在 Java Persistence API 中，它被稱爲持久化實體。其原因是，Java Persistence API 不再應該僅在 Java EE 下專用，而應該也能在 Java SE 環境下使用。
EJB Component（EJB 組件）- EJB 1.x，EJB 2.x，EJB 3.0 - EJB 組件是所有 EJB 類型（→參見 EJB Types）的通用名詞。
EJB Types（EJB 類型）- EJB 1.x，EJB2.x，EJB 3.0 - EJB 規範在 EJB 2.x 中定義了三種 EJB 類型：
- Session Bean（會話 Bean，具有有狀態和無狀態兩種性質）
- Message-Driven Bean（消息驅動 Bean）
- Entity Bean（實體 Bean）
在 EJB 3 中定義了下列的 EJB 類型：
- Session Bean（會話 Bean，具有有狀態和無狀態兩種性質）
- Message-Driven Bean（消息驅動 Bean）
- EJB 3 實體
注意：在 EJB 3 中，會話 Bean 和消息驅動 Bean 將被通稱爲 Enterprise Beans。輕量級持久化業務域對象將被明確地命名爲 EJB 3 實體或者持久化實體。
EJB QL - EJB 1.x，EJB 2.x - EJB Query Language（EJB 查詢語言）的縮寫。
EJB Query Language（EJB 查詢語言）- EJB 1.x，EJB 2.x - EJB QL 是 Enterprise JavaBeans 組件架構的查詢語言。它與 SQL 相似，但專注於對象。它隨着 EJB 3.0 一起被升級，但在 EJB 3.0 中被稱爲 Java 持久化查詢語言（Java Persistence Query Language，Java Persistence QL）。
Embeddable Object（可嵌入對象）- EJB 3.0 - 如果有這樣的 POJO，它們不是 EJB 3 實體，因而不具備持久化性質，可以被嵌入 EJB 3 實體中作爲屬性，那麼這樣的對象就稱爲可嵌入對象。這些可嵌入對象的屬性裝載的是對象的外圍 EJB 3 實體所關聯的數據表的數據。
例如，你可以將一個數據表映射到一個 EJB 3 實體及嵌入它的另外一些 POJO 上，將一個非常規的數據表映射到一個對象網絡上。
@Entity
@Table(name="CUSTOMER")
public class Customer implements java.io.Serializable {
private int id;
private Address address;
private String lastName;
private String firstName;
public Customer(String lastName, String firstName,String street, String city) {
this.address = new Address(street, city);
this.lastName= lastName;
this.firstName = firstName;
}
...
@Embedded
@AttributeOverrides(
@AttributeOverride(name="street", column=@Column(name="STREET")),
@AttributeOverride(name="city",column=@Column(name="CITY")) })
public Address getAddress() {
return address;
}
public void setAddress(Address address) {
this.address = address;
}
@Column(name="LASTNAME")
public String getLastName() {
return lastName;
}
public void setLastName(String lastName) {
this.lastName = lastName;
}
...
Embeddable Object
@Embeddable
public class Address implements java.io.Serializable {
private String street;
private String city;
...
}
Enterprise Bean - EJB 3 - 會話 Bean 和消息驅動 Bean 可以被更概括地稱爲 Enterprise Beans。請注意 EJB 3 實體不能被稱作 Enterprise Beans。但對於 EJB 3 實體則不能使用這個通稱，因爲它們可以也能被用於 Java SE 環境。
Entity Bean（實體 Bean）- EJB 2.x - 在EJB 2.x，用於持久化實體的 EJB 類型稱爲實體 Bean。
Entity Manager（實體管理器）- EJB 3.0 - Java EE 和 Java SE 的新成員，隨 EJB 3.0 一同引入。（正像在JDO和Hibernate一樣）它是一個核心的持久化管理器。實體管理器負責實體（POJOs）的持久化映射，它在數據庫中創建持久化實體，對它們加載、存儲、刪除和搜索操作，同時也關注實體在併發訪問時的一致性（併發處理）。
F
Fetching-Strategy（抓取策略）- EJB 3.0 - 在 EJB 3.0 規範的 Java Persistence API 中，定義了兩種抓取策略：延遲加載（Lazy Load）和貪婪加載（Eager Load，亦作“提前加載”）。和 Hibernate 以及其它持久方案提供工具（如 TopLink）相比，這兩種策略以及其性質只有少數可選方案。對這兩種抓取策略的進一步細化及改進的工作，大致計劃在規範的後續版本中開展。
絕大多數情況下，貪婪加載策略被預設爲 Java Persistence API 的缺省方案。延遲加載僅在開發人員顯式聲明時才被使用。持久方案提供者運行時（Persistence Provider Runtimes，例如 Hibernate）被要求實現並提供貪婪加載機制。延遲加載則僅被持久方案提供者進行時實現者視爲需注意事項而已。EJB 3.0 規範沒有提供更多的關於延遲加載機制應當如何實現的細節，這樣將帶來許多風險，譬如，因爲不同廠商架構和技術實現的分歧所帶來的互操作性弱的問題。
H
Home Interface（Home 接口）- EJB 1.x，EJB 2.x - EJB 組件的 Home 接口包含創建、刪除或加載 EJB 組件實例的方法。由於客戶端無法跨越機器和進程界限，直接創建、刪除或者加載 EJB 組件的實例，它們必須強制使用相應 EJB 組件的 Home 接口。Home 接口提供多種功能。通過使用 Home 接口，我們得以實現 EJB 組件和客戶端的解耦。Home 接口實現了“工廠方法（Factory Method）”設計模式，它以兩種形式存在：
- Remote Home Interface（遠程 Home 接口）——用於跨機器和進程的遠程訪問
- Local Home Interface（本地 Home 接口）——用於進程內調用的本地訪問
在 EJB 3.0 中，會話 Bean 不再強制使用 Home 接口，就是說，它們可以不必實現 Home 接口。而 EJB 3 實體也不再需要 Home 接口了。但是，規範中並沒有規定 Home 接口應當消失。
I
Interceptor（攔截器）- EJB 3.0 - 在 EJB 3.0 中，對業務方法的調用進行攔截成爲可能——與基於 CORBA 系統相似，在這些系統中攔截器的廣泛使用已經有一段歷史了。你可以在需要時分析及操作參數，並且允許或者禁止業務方法的執行。由於攔截器機制的出現，面向方面編程（aspect oriented programming）走入了基於 EJB 開發——起碼是起始階段。攔截器允許將技術性功能（比如日誌、跟蹤、安全）透明地織入業務方法中。攔截器的開發人員可以實現任何代碼，這些代碼將在攔截器被激活，對EJB對象的某個方法調用進行攔截時被執行。
Inversion of Control（反轉控制）- EJB 3.0 - 反轉控制（IoC）是框架的一個常見性質，一般常用好萊塢原則“don't call us, we'll call you”一語來作詮釋（譯註：這裏的 call 一語雙關，既包含通俗意義上“打電話”之意，更主要地，在編程上也做“函數/方法調用”解），意即程序執行過程中的責任是落在框架上，而不在組件上。就是說，組件所賴以構建的框架，要求相應的組件實現框架的某些回調方法（callback methods）。接着，框架在運行期調用這些回調方法，將信息注入，觸發預定行爲。
在 EJB 3.0 環境下，IoC 和依賴注射兩個詞常作爲同義詞互相代用，即便細節上它們有一些語義的區別（→參見 Dependency Injection）。在 EJB 3.0 中使用的是反轉控制的一個特殊形式，叫做依賴注射。
J
Java Persistence API（Java 持久化 API）- EJB 3.0 - EJB 3.0（Java Community Process 中的 JSR 220）中開發出了 Java Persistence API。Java Persistence API 將成爲 Java EE 和 SE 的標準持久化方案，其中一項重要性質就是可以被用於任意 POJO，並不僅限於 EJB 組件。因此 Java Persistence API 對於不需要在應用程序中使用 EJB 組件的開發人員同樣是可用的。領導 Hibernate、TopLink、JDO 和 EJB 持久化解決方案的專家參與了 Java Persistence API 的開發。
Java Persistence QL - EJB 3.0 - Java Persistence Query Language（Java 持久化查詢語言）的縮寫。
Java Persistence Query Language（Java 持久化查詢語言）- EJB 3.0 - Java 持久化查詢語言是 Enterprise JavaBeans 組件架構的查詢語言，與 SQL 相似，但是更專注於對象。與 EJB SQL 相比，Java 持久化查詢語言進行了大幅度的改進。EJB QL 的許多遺缺功能都在 Java 持久化查詢語言中被實現。Java 持久化查詢語言比 EJB QL 擁有更加豐富的功能集合，且看起來有點像 Hibernate HQL。
L
Lazy Load（延遲加載）- EJB 3.0 - 正像其它持久化解決方案一樣，延遲加載在此也代表這樣一種策略：持久化實體（EJB 3.0 實體）的持久化數據僅在對持久對象和/或其屬性的實際訪問發生時，才從數據庫中讀入。用延遲加載標記過的所有的屬性或與其它持久化實體連接的關係，僅在對它們的相應訪問發生的時候，才實時（just in time）地從數據庫加載。
延遲加載實現的實際性質取決於廠商各自的實現。
延遲加載的優點在於，數據僅在出現對某個屬性或者關係的存取時才被取用，這樣做可以減少對內存的消耗；其缺點則是，應用程序可能會因爲對持久化數據進行即時抓取而減慢運行速度。
Local Home Interface（本地 Home 接口）- EJB 2.x - 本地類型的 Home 接口稱爲本地 Home 接口。它就是所謂的高速 Home 接口，因爲它僅在 EJB 組件客戶端處於同一個容器（進程）的情況下才被使用。本地 Home 接口和遠程 Home 接口一樣用於創建、刪除和加載 EJB 組件。本地 Home 接口比起遠程 Home 接口結構要輕便一些，因爲前者無法通過 RMI 調用，並且不具備在網絡上進行列集（marshalling），散集（unmarshalling）以及傳送（transmitting）的功能。客戶端與 EJB 組件間的通信是進程內的，因此比遠程 Home 接口更快。本地 Home 接口不能接受遠程方法調用。
在 EJB 3.0 中，會話 Bean 不再強制使用 Home 接口，就是說，它們可以不必實現 Home 接口。而 EJB 3 實體也不再需要 Home 接口了。但是，規範中並沒有規定 Home 接口應當消失。
Local Interface（本地接口）- EJB 2.x，EJB 3.0 - 僅允許本地通信的業務接口（EJB 3）技術上的變體或者 EJB 組件的組件接口（EJB 2.x）稱爲本地接口。它僅允許客戶端和組件之間的進程內通信。當一個 EJB 組件只包含本地接口而沒有遠程接口時，將無法對組件進行遠程訪問。
M
Managed Entity/Managed Object（受管實體/受管對象）- EJB 3.0 - 受管實體是一個帶有持久化性質的 EJB 3.0 實體的實例。該實體目前與一個持久化上下文環境（persistent context）相關聯，因此它受實體管理器（Entity Manager）的管理。
Message-Driven Bean（消息驅動 Bean）- EJB 2.x，EJB 3.0 - 消息驅動 Bean（MDB）被用於在 J2EE 和 Java EE 應用程序中實現異步工作流，是消息代理的消息消費者。MDB 可以從消息代理取得異步消息，並進行處理。因而在消息系統的環境中，消息驅動 Bean 作爲消息的終點。
消息驅動 Bean 既不包含 Home 接口也不包含組件接口（EJB 1.x，EJB 2.x）或業務接口（EJB 3.0）。注意：EJB 3 規範規定，消息驅動 Bean必須有一個業務接口。具體來說，該業務接口是一個根據使用的具體消息類型的接口。在 EJB 3 中，消息驅動 Bean 的這個接口又叫做業務接口，儘管它比功能性接口更爲技術性。由於 MDB 沒有一個實際的業務接口，消息驅動 Bean 對客戶端是不可見的，即 MDB 不能被直接使用。
Meta-Annotations（元標註）- EJB 3.0 - 元標註是 Java 編程語言的動態語言擴充，它們在 JSR 175 中被引入 JDK 5.0（也叫 Java 1.5）。標註允許在 Java 代碼中放置元信息（meta information），這些元信息可以在編譯期和運行期被取值。它們可以用來進行代碼生成或者控制對象或者 EJB 組件的運行期行爲。
Multi-table Mapping（多表映射）- EJB 3.0 - 多表映射表示 EJB 3.0 實體可以被映射到多個物理數據庫表格上。除非你顯式地在 Bean 管理的持久化中寫代碼實現，否則 EJB 2.x 不具備這項功能。在 EJB 3.0 裏，一個 EJB 3.0 實體不再只有和數據表以 1:1 對應的單一形式了。相反地，它是邏輯業務對象的技術層面的包裝器，這個邏輯業務對象的數據可以分佈在若干個表格中。在 EJB 3.0 實體中，使用標註（annotations）方便地指明哪些表格/字段是相應數據的來源，也可以在 XML 中指定 O/R 映射。實體管理器則負責在運行期解析關係模型，爲 EJB 3.0 實體裝載數據（參考圖示）。
被映射到三個數據表的 EJB 3.0 實體
@Entity
@Table(name="CUSTOMER")
@SecondaryTables({
@SecondaryTable(name="ADDRESS")
@SecondaryTable(name="TYPE") })
public class Customer implements java.io.Serializable {
private int id;
private String firstName; // from table "CUSTOMER"
private String lastName; // from table "CUSTOMER"
private String street; // from secondary table "ADDRESS"
...
// Attribute from main table ?CUSTOMER“
@Column(name="LASTNAME")
public String getLastName() {
return lastName;
}
...
// Attribute from secondary table "ADDRESS"
@Column(name="STREET", table="ADDRESS")
public String getStreet() {
return street;
}
...
// if no @Column annotation is specified,
// it is assumed that column name equals attribute name
public String getFirstName() {
return firstName ;
}
}
P
Persistence Provider Runtime（持久方案提供者運行時）- EJB 3.0 - “持久方案提供者運行時”這個術語指代 Java Persistence API 的持久化實現的運行期環境。在 Java EE 中，它可能是一個帶有集成持久化方案實現的 Java EE 容器，或者一個與第三方持久化方案提供工具實現集成的 Java EE 容器。在 Java SE 中，它是一個單獨的持久化方案提供工具的實現（就像 Hibernate）。
Plain Old Java Interface（簡單傳統 Java 接口，也譯作無格式普通 Java 接口）- EJB 3.0 - 這個術語與 2004 年在各種刊物和電子雜誌突然出現。“簡單傳統Java接口/無格式普通Java接口（Plain Old Java Interface，POJI）”這個術語代表一個簡單的 Java 接口，這個接口沒有被某個基礎架構或其他技術層面的關聯代碼所“污染”。EJB 3.0 的環境中也引入了這個術語。EJB 3.0 的核心思想是，從開發人員的角度看，EJB 組件在使用上以及它們的微架構方面變得不那麼複雜。
Plain Old Java Object（簡單傳統 Java 對象，也譯作無格式普通 Java 對象）- EJB 3.0 - 這個術語於 2004 年在各種刊物和電子雜誌突然出現。“簡單傳統 Java 對象/無格式普通 Java 對象（Plain Old Java Object，POJO）”這個術語代表一個簡單的 Java 類（或者應該叫做 POJC ;-)），這個類並沒有被某個基礎架構或其他技術層面的關聯代碼所“污染”，在更復雜的系統中這種“污染”的情況很典型。EJB 3.0 的環境中也引入了這個術語。EJB 3.0 的核心思想是，從開發人員的角度看，EJB 組件在使用上以及它們的微架構方面變得不那麼複雜。目標就是使它們變得簡單到可以被視爲 POJO。
POJI - EJB 3.0 - Plain Old Java Interface的縮寫。
POJO - EJB 3.0 - Plain Old Java Object的縮寫。
R
Remote Home Interface（遠程 Home 接口）- EJB 1.x，EJB 2.x - 遠程Home接口使遠程客戶能夠通過網絡創建、加載或者刪除 EJB 的實例。客戶端使用 RMI/IIOP 協議進行遠程方法調用，與遠程 Home 接口通訊。在分佈式系統中，當網絡中任意指定機器上的客戶端需要 EJB 時，必須使用遠程 Home 接口。
在 EJB 3.0 中，會話 Bean 不再強制使用 Home 接口，就是說，它們可以不必實現 Home 接口。而 EJB 3 實體也不再需要 Home 接口了。但是，規範中並沒有規定 Home 接口應當消失。
Remote Interface（遠程接口）- EJB 1.x，EJB 2.x - 允許遠程通信的業務接口（EJB 3）技術上的變體或者 EJB 組件的組件接口（EJB 1.x，2.x），成爲遠程接口。當一個 EJB 組件包含遠程接口時，其他進程的客戶端可以跨越進程和機器的阻隔調用該組件。這個通信方式採用 RMI/IIOP。即便客戶端和 EJB 組件在同一個進程中（例如客戶端本身就是一個 EJB 組件的情況），並且客戶端使用遠程接口，通訊方式還是採用 RMI/IIOP。在這種情況下這會導致通訊效率不必要的損耗。改進的方法是使用組件的本地接口，可以使性能得以提升。
S
SFSB - EJB 1.x，EJB 2.x，EJB 3.0 - Stateful Session Bean（有狀態會話 Bean）的縮寫。
SLSB - EJB 1.x，EJB 2.x，EJB 3.0 - Stateless Session Bean（無狀態會話 Bean）的縮寫。