/wiki / ejb

Ejb — Map of Content

2026-09-02T00:00:00.000Z

Map of Content for Ejb — 115 concepts. Start here to navigate ejb.

Core Concepts

Account Bean BMP Example — concept
Activation — concept
Application vs System Exceptions — concept
Atomic Name — concept
Bean-Managed Persistence — concept
Bidirectional vs Unidirectional Relationships — concept
Business Interface Pattern — concept
CDATA Hack for XML — concept
Client-Initiated Transactions — concept
Client Think Time — concept
CMP Abstract Accessors and Methods — concept
CMP Entity Bean Lifecycle — concept
cmp-vs-bmp — concept
cmp-vs-bmp-relationships — concept
Component Architecture & SOA — concept
Compound Name — concept
Container-Managed Persistence — concept
Count Bean Example — concept
Declarative vs Programmatic Transactions — concept
Distributed Objects — concept
Don't Rely on ejbRemove() — concept
ejbActivate() — concept
EJB Client JAR — concept
EJB Context — concept
ejbCreate() — concept
EJB Deployment Descriptor — concept
EJB Development Lifecycle — concept
ejbHome() — concept
EJB-JAR File — concept
EJB Lifecycle — Stateful — concept
EJB Lifecycle — Stateless — concept
ejbLoad() — concept
EJB Naming Service — concept
EJB Object — concept
ejbPassivate() — concept
ejbPostCreate() — concept
EJB Query Language (EJB-QL) — concept
ejbRemove() — concept
EJB Roles — concept
ejbStore() — concept
EJB Verification & Generation — concept
Entity Bean Identity — concept
Entity Bean Instance vs Data — concept
Entity Bean — concept
Entity Bean Transaction Rules — concept
Entity Context — concept
Explicit vs Implicit Middleware — concept
Finder Methods — concept
Flat vs Nested Transactions — concept
getPrimaryKey() — concept
Home Interface — concept
Instance Pooling — concept
J2EE Compliance — concept
J2EE Specification — concept
j2ee-tech-stack-compared — concept
JAAS — concept
Java IDL — concept
JavaMail — concept
Java Platforms — concept
JAXP — concept
JAX-RPC — concept
J2EE Connector Architecture — concept
JDBC — concept
Java Message Service (JMS) — concept
JMS Programming Model — concept
JNDI Architecture — concept
JNDI Binding — concept
JNDI Context — concept
JNDI — concept
JNDI Naming Concepts — concept
JNDI Service Provider Interface — concept
JSP — concept
JTA and JTS — concept
Local Home Interface — concept
Location Transparency — concept
Many-to-Many Relationship in EJB — concept
Message-Driven Bean (MDB) — concept
Message-Oriented Middleware (MOM) — concept
Middleware — concept
Normalized vs Denormalized Database Schema — concept
Object-Relational Mapping — concept
Object Serialization — concept
One-to-Many Relationship in EJB — concept
One-to-One Relationship in EJB — concept
Pass-by-Reference in RMI — concept
Pass-by-Value in RMI — concept
Passivation — concept
Persistence Concepts — concept
Pluggable Message Providers — concept
Subscribe Messaging — concept
Poison Message — concept
Primary Key Class — concept
Primary Key — concept
Queue Partitioning for Business Processing — concept
Remote Interface — concept
Resource Pooling — concept
RMI-IIOP — concept
RMI Remote Method Invocation — concept
Serialization vs ORM — concept
Servlets — concept
Session Bean Lifetime — concept
Session Bean — concept
Session Bean Relationships — concept
Session Bean Subtypes — concept
SessionContext — concept
setEntityContext() — concept
Stateful Session Bean — concept
stateful-vs-stateless-session-beans — concept
Stateless Session Bean — concept
Stateless Session Bean Pooling — concept
Subcontext — concept
Transaction Demarcation in EJB — concept
Transactions in EJB — concept
unsetEntityContext() — concept
Why Bean Doesn't Implement Component Interface — concept

Mechanisms & How Things Work

Auto-generated — edit to curate. Pages that explain processes/flows.

Comparisons & Tradeoffs

(No synthesis yet — create via ingest or query —save)

rmi-registry

2026-09-02T00:00:00.000Z

The Problem

Auto-created stub for broken link [[rmi-registry]] — needs human content.

Formal Definition

Per Wikipedia: “To be written.”

Explanation

Stub — fill with plain language explanation.

How It Works

To be written.

Visual Explanation

digraph rmi-registry {
  rankdir=LR
  node [shape=box style=filled fillcolor="#f0f4ff" fontname="Helvetica"]
  A [label="Stub: rmi-registry"]
  B [label="To be written"]
  A -> B [label="needs content"]
}

Semantic Network

graph semantic_rmi-registry {
  layout=neato
  node [shape=ellipse fontname="Helvetica" fontsize=11 style=filled]
  THIS [label="rmi registry" fillcolor="#ffd700" fontsize=13 style="filled,bold"]
  REL1 [label="Related" fillcolor="#f0f0f0"]
  THIS -- REL1 [label="related"]
}

Key Properties

To be written.

Real-World Example

# TODO: add example

Connections

Related: Index — auto stub, needs proper links

Edge Cases & Gotchas

To be written.

account-bean-bmp-example

2026-04-29T00:00:00.000Z

The Problem

Students need a concrete BMP (Bean-Managed Persistence) example that shows all pieces: remote interface, home interface, primary key class, bean class with JDBC code, deployment descriptor, and client code—without the fluff.

Core Idea

The Account Bean is a BMP entity bean representing a bank account. It demonstrates: Account remote interface, AccountHome home interface with finder methods, AccountPK primary key class, AccountBean with JDBC code for CRUD, ejb-jar.xml with <persistence-type>Bean</persistence-type>, and client code using JNDI lookups.

How It Works

1. Remote Interface (`Account.java`)

import javax.ejb.EJBObject;
import java.rmi.RemoteException;
 
public interface Account extends EJBObject {
    public void deposit(double amt) throws RemoteException;
    public void withdraw(double amt) throws RemoteException, AccountException;
    public double getBalance() throws RemoteException;
}

2. Home Interface (`AccountHome.java`)

public interface AccountHome extends EJBHome {
    public Account create(String accountID, String ownerName) 
        throws RemoteException, CreateException;
    public Account findByPrimaryKey(AccountPK key) 
        throws RemoteException, FinderException;
    public double getTotalBankValue() 
        throws RemoteException, AccountException; // Home method
}

3. Primary Key Class (`AccountPK.java`)

public class AccountPK implements Serializable {
    public String accountID;
    public AccountPK() {}
    public AccountPK(String id) { this.accountID = id; }
}

4. Deployment Descriptor (`ejb-jar.xml`)

Key elements: <persistence-type>Bean</persistence-type>, <prim-key-class>examples.bmp.AccountPK</prim-key-class>, <resource-ref> for JDBC.

5. Client Code

Looks up Home via JNDI, calls home.create(), account.deposit(100), home.findByPrimaryKey(pk).

Visual Explanation

Key Properties

BMP: Bean writes all JDBC code (ejbCreate → INSERT, ejbLoad → SELECT, etc.)
AccountPK: Wrapper for primary key (String accountID)
Home methods: getTotalBankValue() runs from pool, not specific instance
Resource reference: <resource-ref> configures JDBC DataSource in JNDI
CMT: Deployment descriptor sets <transaction-type>Container</transaction-type>

Connections

Built from: Bean-Managed Persistence — this is a BMP example
Built from: Primary Key Class — AccountPK is the PK class
Built from: Home Interface — AccountHome with finder methods
Built from: Remote Interface — Account interface
Built from: JDBC — BMP uses JDBC for all DB operations
Builds into: EJB Deployment Descriptor — XML config shown
Related: Finder Methods — findByPrimaryKey() is a finder
Related: AccountException — custom application exception

Edge Cases & Gotchas

SQL exceptions: Must handle SQLException in BMP JDBC code
Withdraw validation: Check balance before withdrawing (throw AccountException)
Home methods: Run on pooled bean, not associated with specific EJB object
Resource reference: Must configure jdbc/bmp-account in container-specific descriptor
12-mark question: Focus on interfaces, PK class, XML—not full JDBC code

application-vs-system-exceptions

2026-04-29T00:00:00.000Z

The Problem

When something goes wrong in your EJB, how should the container handle it? Should it tell the client? Should it rollback the transaction? Should it alert the administrator? Different errors need different treatments.

Core Idea

EJB defines two exception types with different handling strategies:

Application Exceptions: Routine business problems (bad input, insufficient funds). Always thrown back to the client—the client needs to know and handle these.
System Exceptions: Critical failures (database down, NullPointerException). Container intercepts these, may alert admin, and usually discards the bean (it’s in an undefined state).

How It Works

Aspect	Application Exception	System Exception
Examples	`CreateException`, `InsufficientFundsException`	`NullPointerException`, DB connection failure
Thrown to client?	Always	May be wrapped as `RemoteException`
Transaction	Client decides rollback	Container may auto-rollback
Bean state	Bean remains usable	Bean is discarded (undefined state)
Defined in	`javax.ejb` package or custom	`java.lang.RuntimeException` or `RemoteException`

Visual Explanation

Key Properties

EJB Object intercepts exceptions: It decides what to do before reaching client
Application exceptions are part of business logic: They carry valuable data for the client
System exceptions leave bean in undefined state: Container stops using that bean instance
Two rules of thumb:
1. Application exceptions → always thrown to client
2. System exceptions → container can do anything (alert, discard, throw)

Connections

Built from: EJB Object (intercepts exceptions)
Builds into: Transactions (exceptions affect transaction outcome)
Related: EJB Container (handles system exceptions)
Contrasts with: Regular Java (all exceptions handled the same way)

Edge Cases & Gotchas

Unchecked exceptions are system exceptions: RuntimeException subclasses are treated as system exceptions
Don’t rely on ejbRemove() for cleanup: If a system exception occurs, ejbRemove() may never be called
Transparent failover: Some containers redirect to another bean for stateless beans after system exceptions

atomic-name

2026-04-29T00:00:00.000Z

The Problem

In a hierarchical naming system like JNDI, we need a way to refer to individual name components. How do we represent the smallest, indivisible unit of a name that cannot be further subdivided?

Core Idea

An atomic name is a simple, basic, indivisible name in JNDI. Examples include etc, fstab, usr, bin — each is a single component that cannot be split further. They are the building blocks of compound names.

How It Works

Atomic names are the leaf components in a compound name
In /etc/fstab, the atomic names are etc and fstab
In JNDI, each binding in a context has a distinct atomic name
Atomic names are combined with a syntax (like /) to form compound names
They serve as keys in the binding table of a context

Visual Explanation

Key Properties

Indivisible: Cannot be split into smaller naming components
Syntax-independent: The atomic name itself doesn’t include separators
Unique within context: Each atomic name in a context maps to one binding
Case-sensitive: Typically, atomic names are case-sensitive
Building block: Combined to form compound names

Connections

Built from: JNDI Naming Concepts — atomic names are part of JNDI naming
Builds into: Compound Name — atomic names combine to form compound names
Related: JNDI Context — contexts contain bindings with atomic names
Related: JNDI Binding — each binding has an atomic name as its key

Edge Cases & Gotchas

Special characters: Some characters may have special meaning in compound name syntax
Length limits: Providers may impose limits on atomic name length
Reserved words: Some names may be reserved by the provider

business-interface-pattern

2026-04-29T00:00:00.000Z

The Problem

EJB component interfaces (Remote/Local) extend EJB-specific interfaces (EJBObject, EJBLocalObject) which have methods meant for clients, not beans. If beans don’t implement the component interface (to avoid pollution), how do we get compile-time checking that the bean has all required business methods?

Core Idea

Define a “pure” business interface containing only your business method signatures—no EJB dependencies. Have both the Remote/Local interface AND the bean class implement this business interface. This gives compile-time checking without polluting the bean with EJB client methods.

How It Works

// 1. Pure business interface (no EJB stuff)
public interface HelloBusinessMethods {
    String hello() throws RemoteException;
}
 
// 2. Remote interface extends BOTH EJBObject and business interface
public interface HelloRemote extends javax.ejb.EJBObject, HelloBusinessMethods {}
 
// 3. Local interface also extends business interface
public interface HelloLocal extends javax.ejb.EJBLocalObject, HelloBusinessMethods {}
 
// 4. Bean implements business interface (+ SessionBean)
public class HelloBean implements SessionBean, HelloBusinessMethods {
    public String hello() { return "Hello, World!"; }
}

Visual Explanation

Key Properties

Compile-time safety: If bean misses a business method, compilation fails
No pollution: Bean doesn’t implement EJBObject methods
Shared contract: Both bean and EJB object share the same business method signatures
One downside: Local interface inherits RemoteException from business interface (if business interface declares it)

Connections

Built from: Why Bean Doesn't Implement Component Interface
Builds into: Remote Interface, Local Home Interface
Related: Session Bean, Entity Bean
Contrasts with: Direct implementation (bean implements remote interface directly)

Edge Cases & Gotchas

RemoteException leakage: Business interface meant for both remote and local still declares RemoteException—local clients don’t need it
EJB 3.x+ solves this: Uses @Local and @Remote annotations—no need for this pattern
Not mandatory: Most developers just let the container verify at deployment time (not compile time)

client-think-time

2026-04-29T00:00:00.000Z

The Problem

When analyzing server capacity, we might assume each client needs a dedicated bean instance. But users don’t click buttons continuously—they read pages, think, and then act. How can we leverage this idle time to serve more clients with fewer resources?

Core Idea

Client think time is the period when a user is viewing a page or thinking between actions. During this time, the server-side bean instance can be reassigned to serve other clients, dramatically improving resource utilization.

How It Works

User clicks button: Server assigns bean, executes method, returns response
User reads page: Server returns bean to pool (5-10 minutes of idle time)
Pool reuse: Same bean serves other clients during this idle period
Result: 50-100 beans can serve 10,000 clients

This is the key insight that makes instance pooling viable for human-facing applications.

Visual Explanation

Key Properties

Human behavior: Users spend most time reading, not clicking
Resource multiplier: 50 beans can serve 10,000 clients
Key to pooling: Makes stateless session bean pooling effective
Not applicable: Automated clients (APIs) may not have think time
Exam keyword: Mention in instance pooling answers

Connections

Built from: Instance Pooling — think time enables pooling efficiency
Related: Stateless Session Bean — primary beneficiary
Related: Session Bean Lifetime — beans returned to pool during think time
Builds into: Scalability — think time improves scalability

Edge Cases & Gotchas

API clients: May not have think time (continuous requests)
Timeout: Session may timeout during long think time
Stateful beans: Have dedicated state, can’t leverage think time for pooling

component-architecture-soa

2026-04-29T00:00:00.000Z

The Problem

Monolithic applications mixed everything together—UI, business logic, and data access all in one codebase. This made code impossible to reuse across different applications and hard to maintain as the application grew.

Core Idea

“Divide and Conquer” applied to software architecture. Break a large application into small, independent pieces (components/services), where each component handles a specific responsibility. These components can be reused across multiple applications.

How It Works

Decomposition: Identify distinct responsibilities and split them into separate components
Interface Definition: Each component exposes a contract (interface) defining what it can do
Independent Deployment: Components can be developed, deployed, and updated independently
Reusability: Same component can serve multiple applications

In EJB, the component architecture manifests as:

Enterprise Beans = business logic components
Interfaces (Remote/Local) = contracts
Container = runtime environment managing components

Visual Explanation

Key Properties

Components are independent and self-contained
Communication happens through well-defined interfaces
Promotes code reuse across applications
Enables parallel development by different teams
Scalability: Scale individual components based on demand

Connections

Built from: Session Bean, Entity Bean
Builds into: EJB Container (hosts components)
Contrasts with: Monolithic architecture (all-in-one)
Related: Middleware (infrastructure for component communication)

Edge Cases & Gotchas

Over-decomposition leads to distributed monolith—too many tiny components with complex dependencies
Network overhead: Component calls cross process/JVM boundaries (unlike monolithic in-process calls)
Versioning: Updating a component interface can break all dependent applications

compound-name

2026-04-29T00:00:00.000Z

The Problem

A single atomic name can only identify objects at one level of the hierarchy. How do we refer to objects deep in a tree structure, like /usr/people/ed/.cshrc? We need a way to combine multiple atomic names into a full path.

Core Idea

A compound name is zero or more atomic names combined using a specific syntax (like / in file paths). It represents a full path through the naming hierarchy. Examples: /etc/fstab, /usr/bin, java:comp/env/jdbc.

How It Works

Atomic names are concatenated with a separator (e.g., / for file-like, . for DNS-like)
/usr/people/ed has four atomic names: usr, people, ed
Each level is resolved sequentially: look up usr, then people within usr, then ed within people
In JNDI, compound names can span multiple naming systems (federation)
JNDI compound names may use different syntaxes depending on the provider

Visual Explanation

Key Properties

Hierarchical: Represents a path through the naming tree
Syntax-dependent: Uses provider-specific separator characters
Resolved sequentially: Each component is looked up in the context of the previous component
Can span contexts: May traverse multiple subcontexts
JNDI examples: java:comp/env/ejb/MyBean, jdbc/myDataSource

Connections

Built from: Atomic Name — compound names are made of atomic names
Builds into: JNDI Binding — bindings use compound names for lookup
Related: JNDI Naming Concepts — compound names are a core concept
Related: JNDI Context — contexts resolve compound names
Related: Subcontext — compound names traverse subcontexts

Edge Cases & Gotchas

Syntax differences: LDAP uses commas (,), file system uses slashes (/)
Escaping: Special characters in atomic names may need escaping in compound names
Absolute vs relative: Some compound names are relative to a context
Parsing errors: Incorrect syntax causes InvalidNameException

count-bean-example

2026-04-29T00:00:00.000Z

The Problem

Learning EJB concepts abstractly is hard. Students need a concrete, minimal example that demonstrates stateful session beans, passivation/activation, and the full EJB lifecycle in action.

Core Idea

The Count Bean is a simple stateful session bean example that maintains a conversational state (an integer counter val). It demonstrates the full EJB development cycle: remote interface, home interface, bean class, deployment descriptor, and client code.

How It Works

Remote Interface (Count): Extends EJBObject, declares count() business method that throws RemoteException
Bean Class (CountBean): Implements SessionBean, has val as conversational state, implements count() to increment and return val
Lifecycle Callbacks: ejbCreate(int val) initializes state, ejbPassivate() serializes to storage, ejbActivate() restores from storage
Home Interface (CountHome): Extends EJBHome, declares create(int val) which maps to ejbCreate()
Deployment Descriptor: Declares <session-type>Stateful</session-type> in ejb-jar.xml
Client: Looks up Home via JNDI, calls home.create(10), calls count() to increment

The example shows passivation when pool limit (2 beans) is reached, then activation when beans are reused.

Visual Explanation

Key Properties

Stateful: Maintains conversational state (val) across method calls
Passivation: Bean serialized to storage when pool is full or idle
Activation: Bean restored from storage when needed again
Serialiable state: val is serialiable (primitive int)
JNDI lookup: Client finds Home Object via JNDI, not new
No this: Bean uses SessionContext.getEJBObject() to get self-reference

Connections

Built from: Stateful Session Bean — CountBean is a stateful bean
Built from: Remote Interface — Count interface extends EJBObject
Built from: Home Interface — CountHome is the factory
Built from: Passivation — demonstrated when pool limit reached
Built from: Activation — demonstrated when bean reused
Builds into: EJB Development Lifecycle — full example of the lifecycle
Related: SessionContext — provides getEJBObject() for self-reference
Related: Instance Pooling — pool management triggers passivation

Edge Cases & Gotchas

Stateful cannot be pooled: Unlike stateless, each client gets dedicated bean
Passivation failure: val must be serialiable, or passivation fails
this danger: Never pass this to other beans—use getEJBObject()
Pool limit: Container-specific setting controls when passivation occurs
Server crash: Passivated state may be lost if server crashes

distributed-objects

2026-04-29T00:00:00.000Z

The Problem

Traditional objects live in a single JVM—if you want to call a method on an object running on a different server, you can’t just use object.method(). Network programming is complex: you need sockets, serialization, protocol handling, and error recovery.

Core Idea

A distributed object is a Java object running on a remote server, but it can be accessed as if it were local. The EJB container (via RMI-IIOP) handles all network complexity—the client calls methods on a proxy, and the container forwards the call to the actual object on the server.

How It Works

Server side: The EJB object (proxy) is registered with the naming service (JNDI)
Client lookup: Client uses JNDI to find the home object reference
Proxy creation: Home object creates an EJB object (proxy) for the client
Method invocation: Client calls methods on the proxy; proxy forwards via network to the actual bean
Result return: Bean’s response travels back through proxy to client

Visual Explanation

Key Properties

Objects can be accessed across network boundaries (different machines, different JVMs)
Location transparency: Client doesn’t know or care where the object physically lives
RMI-IIOP protocol: Standard wire protocol for EJB distributed objects
Proxy pattern: Client never talks directly to the bean—always through EJB object

Connections

Built from: RMI, JNDI, EJB Naming Service
Builds into: EJB Object, Home Interface, Distributed Objects
Related: Middleware (handles network complexity), Location Transparency (clients don’t know object location)
Contrasts with: Local objects (in-process, no network overhead), Local Home Interface (same JVM, no RMI)

Edge Cases & Gotchas

Network failures: Remote exceptions (RemoteException) can occur—not present with local objects
Serialization overhead: Parameters must be serializable for network transfer
Latency: Network calls are 100-1000x slower than in-process calls
Stateless beans preferred for distributed access: No client-specific state to transfer

dont-rely-on-ejbremove

2026-04-29T00:00:00.000Z

The Problem

Developers often put critical cleanup code in ejbRemove()—closing database connections, deleting temporary shopping cart data, etc. But what if ejbRemove() is never called?

Core Idea

The EJB container MAY call ejbRemove() when it decides to destroy a bean instance. BUT it is NOT guaranteed. If the server crashes, or if a critical system exception occurs, the bean is destroyed without ejbRemove() being called. Never rely on ejbRemove() for critical cleanup.

How It Works

Normal case: Container calls ejbRemove() when client calls remove() or when bean times out
Crash case: Server crashes → ejbRemove() never called → resources leaked
Exception case: System exception occurs → container discards bean → ejbRemove() may not be called

Solution: Use external cleanup utilities (e.g., a periodic job that deletes abandoned shopping carts from the database).

Visual Explanation

Key Properties

Not a destructor: Unlike C++ destructors, ejbRemove() is not guaranteed
Container’s choice: EJB spec allows container to skip ejbRemove() in some cases
Periodic cleanup needed: For resources that MUST be cleaned (like temp DB records), use a scheduled job
Session beans: Stateless beans may be destroyed without ejbRemove() (pool management)

Connections

Built from: Session Bean, Entity Bean (both have ejbRemove())
Builds into: EJB Container (decides when to call it)
Related: System Exceptions (can bypass ejbRemove())
Contrasts with: Java finalize() (also unreliable), C++ destructors (reliable)

Edge Cases & Gotchas

Shopping cart example: If ejbRemove() isn’t called, abandoned carts stay in DB forever—need a cleanup job
Database connections: Don’t close them in ejbRemove()—use ejbPassivate() or let container manage pooling
Exam trick question: “Where should you put critical cleanup code?” → Answer: Nowhere in the bean—use external utilities

ejb-client-jar

2026-04-29T00:00:00.000Z

The Problem

Clients need the EJB interfaces and stubs to call beans. But giving them the full EJB-JAR (which includes your business logic/bean class) is a security risk and wastes disk space. How can you give clients only what they need?

Core Idea

The optional EJB Client JAR is a smaller archive containing only the files clients need: interfaces (Home, Remote/Local), helper classes, and generated stubs. You specify it in the deployment descriptor with <ejb-client-jar>HelloClient.jar</ejb-client-jar>. Clients deploy just this JAR, not the entire EJB-JAR.

How It Works

Developer creates Client JAR: Bundles interfaces + stubs + helpers
Declare in XML: <ejb-client-jar> tag in ejb-jar.xml
Deployer gives Client JAR to clients: Clients add it to their classpath
Client uses JAR: Can lookup and call beans without having bean implementation

Visual Explanation

Key Properties

Optional: Most deployments don’t use it (hard disk space is cheap)
Security: Hides business logic implementation from clients
Smaller footprint: Useful for applets or disk-constrained environments
Declared in deployment descriptor: Container tells deployer which JAR to create

Connections

Built from: Home Interface, Remote Interface (included in client JAR)
Builds into: JNDI (client uses JAR to lookup beans)
Related: EJB-JAR File (the full version)
Contrasts with: Full EJB-JAR (includes secret bean implementation)

Edge Cases & Gotchas

Mostly obsolete: Modern deployments use Web Services or REST—not EJB direct clients
Laziness prevails: Most deployers just give clients the full EJB-JAR (easier)
Applet environment: Only critical use case—applets have very limited disk space

ejb-context

2026-04-29T00:00:00.000Z

The Problem

Enterprise beans live inside a managed container. Sometimes the bean needs to query the container—“Who is the current user?”, “Is this transaction going to rollback?”, “What’s my home object?”. But beans shouldn’t directly access container internals.

Core Idea

EJBContext is the bean’s gateway to the container. It’s an object that encapsulates everything the bean needs to know about its environment. The container injects this context (via setSessionContext() or setEntityContext()), and the bean can query it at any time.

How It Works

The container calls setSessionContext(SessionContext ctx) during bean creation. The bean stores this reference. Later, the bean can use it:

Security: getCallerPrincipal(), isCallerInRole(String role)
Transactions: getRollbackOnly(), setRollbackOnly(), getUserTransaction()
Home access: getEJBHome(), getEJBLocalHome()

Visual Explanation

Key Properties

Callback injection: Container injects context via setSessionContext()—never created by bean
Dynamic: Context changes over bean’s lifecycle (e.g., transaction status changes)
Two types: SessionContext (for session beans), EntityContext (for entity beans)
Environment bridge: Bean can access JNDI environment entries via context

Connections

Built from: EJB Container (provides the context)
Builds into: Transactions (via setRollbackOnly())
Related: Session Bean, Entity Bean
Contrasts with: Regular Java objects (no container, no context)

Edge Cases & Gotchas

Don’t store context in static variables: Context is per-bean-instance, static is shared
Context valid only inside container: Can’t use it outside container-managed methods
Null check: Always check if context is set before using (during ejbCreate() it’s already set)

Code Example

public class HelloBean implements SessionBean {
    private SessionContext ctx;
 
    public void setSessionContext(SessionContext ctx) {
        this.ctx = ctx;
    }
 
    public String hello() {
        // Who is calling?
        Principal caller = ctx.getCallerPrincipal();
        // Am I in a transaction that will rollback?
        boolean rollback = ctx.getRollbackOnly();
        return "Hello, " + caller.getName();
    }
}

ejb-development-lifecycle

2026-04-29T00:00:00.000Z

The Problem

Building an EJB component involves more than just writing Java code. You need to compile, package, configure, and deploy—missing any step results in a non-functional component. What’s the correct order?

Core Idea

The EJB development lifecycle is an 8-step process from raw Java files to a running, tested component in the container. Each step has a specific purpose and must be done in order.

How It Works

Write Java files: Component interfaces, home interfaces, bean class, helper classes
Write deployment descriptor: ejb-jar.xml with bean metadata (or use IDE/XDoclet to generate)
Compile: javac to convert .java → .class
Create EJB-JAR: Use jar utility to package .class files + ejb-jar.xml
Deploy: Copy JAR to container’s deployment folder or use vendor tools
Configure: Set database connections, thread pools via vendor console/config files
Start container: Verify the JAR loaded successfully
Test: Write a client, generate stubs, compile, run, and verify

Visual Explanation

Key Properties

Standardized process: Every EJB component follows these steps (vendor-neutral)
Step 5 is vendor-specific: Each container has its own deployment mechanism
Step 6 is vendor-specific: Configuration differs (Web console vs config files)
Deployment descriptor is key: Tells container how to manage the bean

Connections

Built from: Deployment Descriptor, Home Interface, Remote Interface
Builds into: EJB Object (generated in step 5), EJB Container
Related: EJB-JAR File (output of step 4)
Contrasts with: Simple Java app (just compile and run—no deployment descriptor needed)

Edge Cases & Gotchas

Forgetting step 2: Without ejb-jar.xml, container doesn’t know about your beans
Classpath issues: Step 3 needs EJB APIs (javax.ejb.*) in classpath
Vendor tools automate: Modern IDEs (Eclipse, IntelliJ) automate steps 2-4

ejb-jar-file

2026-04-29T00:00:00.000Z

The Problem

You’ve written your bean class, interfaces, and deployment descriptor. How do you package them for deployment to any EJB container? You need a standard format that bundles everything together.

Core Idea

The EJB-JAR file is a standard Java archive (.jar) containing all the classes (bean class, home/remote/local interfaces, helpers) plus the ejb-jar.xml deployment descriptor. This single file is what you deploy to the container—it’s vendor-neutral and portable.

How It Works

Compile: javac converts .java → .class for all your files
Package: jar cvf MyBean.jar *.class ejb-jar.xml creates the archive
Deploy: Copy JAR to container’s deployment folder or use vendor tools
Container verifies: Checks the JAR structure and generates EJB Object/Home Object

Visual Explanation

Key Properties

Standard format: Any EJB container can read an EJB-JAR file
Contains: Classes + META-INF/ejb-jar.xml (deployment descriptor)
Optional: May include META-INF/webservices.xml or vendor-specific files
Vendor-neutral: Write once, deploy on any EJB container

Connections

Built from: Home Interface, Remote Interface, Deployment Descriptor
Builds into: EJB Verification & Generation (container processes the JAR)
Related: EJB Client JAR (subset of files for clients)
Contrasts with: Regular JAR (no ejb-jar.xml, not deployable to EJB container)

Edge Cases & Gotchas

Missing ejb-jar.xml: Container rejects the JAR—deployment fails
Classpath issues: All dependencies must be in the JAR or server classpath
Vendor-specific files: Some containers need extra files in META-INF/ (e.g., weblogic-ejb-jar.xml)

ejb-naming-service

2026-04-29T00:00:00.000Z

The Problem

Clients need to find Home Objects to create beans. But hardcoding server addresses in client code creates tight coupling—if the server moves, all clients break. What’s the solution?

Core Idea

EJB uses naming and directory services (via JNDI) to store and look up resources (Home Objects, environment properties, database drivers) by logical name (nickname), not physical address. Clients use ctx.lookup("HelloHome") to find Home Objects—the naming service resolves the actual location.

How It Works

Deployer binds nickname: Container registers Home Object with JNDI using a name (e.g., "HelloHome")
Client sets up JNDI properties: Context.INITIAL_CONTEXT_FACTORY + Context.PROVIDER_URL
Client looks up: ctx.lookup("HelloHome") → JNDI returns Home Object reference
Naming service types: LDAP, CORBA Naming Service (COS Naming), or in-process JNDI tree

Visual Explanation

Key Properties

Location transparency: Client doesn’t know physical server address
Standard API: JNDI (javax.naming.*) works with any naming service
JNDI properties: INITIAL_CONTEXT_FACTORY (e.g., com.sun.jndi.ldap.LdapCtxFactory) + PROVIDER_URL (e.g., ldap://louvre:389)
Beyond Home Objects: Also stores environment properties, database resources, message queues

Connections

Built from: JNDI, Location Transparency
Builds into: Home Interface (what gets looked up)
Related: Distributed Objects (clients access objects via naming)
Contrasts with: RMI Registry (limited to RMI, not generalized naming)

Edge Cases & Gotchas

JNDI properties are environment-specific: Different containers need different factory/URL settings
Network partition: If naming service is unreachable, all lookups fail
Nickname collisions: Two beans with same JNDI name cause deployment errors

ejb-roles

2026-04-29T00:00:00.000Z

The Problem

Large enterprise software projects involve multiple stakeholders with different responsibilities. Without clear role separation, code, deployment, and operations become chaotic—developers might hardcode server paths, or deployers might not know which security settings to apply.

Core Idea

EJB formalizes the software development lifecycle by dividing it into distinct roles, each with clear responsibilities. This separation of concerns ensures that code is portable, reusable, and professionally managed.

How It Works

The EJB specification defines these roles:

Role	Responsibility
Bean Provider	Writes the Java code (Bean Class, Interfaces) and business logic
Application Assembler	Combines multiple beans into a complete application
EJB Deployer	Installs and configures the application on the server
System Administrator	Monitors the live system, ensures server health
Container/Server Provider	Builds the application server (e.g., Oracle, IBM, JBoss)

Visual Explanation

Key Properties

Bean Provider only writes business logic—never server-specific code
Application Assembler doesn’t need to know implementation details of each bean
Deployer uses vendor-specific tools but deploys standard EJB-JAR files
Portability: Code written by Bean Provider runs on any EJB container

Connections

Built from: Deployment Descriptor (used by Deployer)
Builds into: EJB Container (provided by Container Provider)
Related: Session Bean, Entity Bean (created by Bean Provider)
Contrasts with: Monolithic development (no role separation)

Edge Cases & Gotchas

In small teams, one person may wear multiple roles (Bean Provider + Assembler + Deployer)
Container Provider role is only for big vendors (Oracle, IBM, Red Hat)—most developers are Bean Providers
Miscommunication between Assembler and Deployer causes deployment failures

ejb-verification-generation

2026-04-29T00:00:00.000Z

The Problem

After deploying an EJB-JAR file, how does the container ensure your bean is valid? And who writes the EJB Object and Home Object code—you or the container?

Core Idea

When you deploy an EJB-JAR, the container performs two critical tasks:

Verification: Checks that your bean class, interfaces, and deployment descriptor are valid (reports errors like “missing ejbCreate() method”)
Generation: Automatically creates the EJB Object and Home Object implementations (plus RMI-IIOP stubs/skeletons)—you only write the interfaces, the container writes the actual classes

How It Works

Verification checks:

Bean class implements the correct interface (SessionBean, EntityBean)
ejbCreate() method exists and matches home interface’s create()
Deployment descriptor is well-formed XML
All required exceptions are declared

Generation outputs:

EJB Object class (implements your Remote Interface)
Home Object class (implements your Home Interface)
RMI-IIOP stubs (for remote clients) and skeletons

Visual Explanation

Key Properties

You never write EJB Object or Home Object code: Container generates them from your interfaces
Verification prevents runtime errors: Catch missing methods before the bean is used
Vendor-specific generation: Each container has its own tools (sometimes proprietary)
Intelligent error reporting: Commercial tools tell you exactly what’s wrong

Connections

Built from: Home Interface, Remote Interface, Deployment Descriptor
Builds into: EJB Object, Home Object (generated)
Related: EJB Development Lifecycle (step 5: deploy triggers this)
Contrasts with: Regular Java (no verification, no generation—you write everything)

Edge Cases & Gotchas

Generated classes are container-specific: You can’t take JBoss-generated stubs and use them on WebLogic
Verification happens at deployment, not compile time: Your code compiles fine, but deployment fails
Some containers generate lazily: EJB Object might be generated on first client lookup, not at deployment

ejbactivate

2026-04-29T00:00:00.000Z

The Problem

When a passivated stateful session bean is needed again, the container must restore its state from secondary storage back into memory. The bean needs to know when this happens to reinitialize any non-serializable resources (like database connections, JMS connections).

Core Idea

ejbActivate() is a callback method that the EJB container calls on a stateful session bean AFTER it has been passivated and is now being restored to the ready state. It’s the counterpart to ejbPassivate().

How It Works

Container decides — based on client request, container selects a passivated bean
Deserialization — container reads bean state from storage
ejbActivate() called — container calls this method AFTER state is restored
Bean reinitializes — open resources, reconnect to services that weren’t serialized

For entity beans, ejbActivate() is called when an entity bean is moved from the pool to the ready state (associated with a specific primary key).

Visual Explanation

Key Properties

Callback method — container calls it, not the client
Stateful SB — reinitialize transient resources after passivation
Entity Bean — called when bean moves from pool to ready (associated with PK)
No parameters — container doesn’t pass any arguments

Connections

Built from: Passivation — ejbActivate is the reverse process
Built from: Activation — the overall process this method participates in
Contrasts with: ejbPassivate() — called before passivation
Related: Stateful Session Bean — primary user of this callback
Related: Entity Bean — also uses this callback in lifecycle

Edge Cases & Gotchas

Only for stateful session beans and entity beans (NOT stateless)
Don’t do business logic here — just resource reinitialization
If this method throws an exception, the bean may be discarded

ejbpassivate

2026-04-29T00:00:00.000Z

The Problem

When a stateful session bean is idle (no client activity for a while), the container may want to free up memory by serializing the bean to secondary storage. Before serialization, the bean needs to release any non-serializable resources (like open database connections, network sockets).

Core Idea

ejbPassivate() is a callback method that the EJB container calls on a stateful session bean BEFORE it is passivated (serialized to storage). It allows the bean to release resources that cannot be serialized.

How It Works

Container decides — bean is idle, container chooses to passivate it
ejbPassivate() called — BEFORE serialization, container calls this method
Bean releases resources — close DB connections, JMS connections, etc.
Serialization — container serializes bean to secondary storage
Memory freed — bean instance returned to pool or garbage collected

When the client needs the bean again, ejbActivate() will be called to restore resources.

Visual Explanation

Key Properties

Callback method — container calls it, not the client
Release non-serializable resources — main purpose
Stateful SB only — stateless beans don’t have passivation
No parameters — container doesn’t pass any arguments

Connections

Built from: Passivation — ejbPassivate is part of this process
Contrasts with: ejbActivate() — called after activation (reverse)
Related: Stateful Session Bean — primary user of this callback
Related: Activation — the overall lifecycle process
Related: Instance Pooling — passivated beans free up pool slots

Edge Cases & Gotchas

Only for stateful session beans (NOT stateless, NOT entity beans)
Don’t do business logic here — just cleanup
If this method throws an exception, passivation fails and bean stays in memory

entity-bean-identity

2026-04-29T00:00:00.000Z

The Problem

Session beans are all equivalent (especially stateless)—there’s no way to distinguish one from another. But entity beans represent specific data records (like a specific bank account). How do you identify which entity bean instance represents which record?

Core Idea

Entity beans have an identity—a primary key that uniquely distinguishes each instance. This allows:

Comparing two entity beans (“Are they the same account?”)
Clients referring to specific entities by their primary key
Sharing entities across multiple clients (unlike session beans which are client-dedicated)

The identity is typically the primary key of the database row the entity represents.

How It Works

Define primary key class: AccountPK with fields matching the table’s primary key
getPrimaryKey() method: Entity beans implement this to return their primary key
Finder methods: ejbFindByPrimaryKey(PK) locates the correct database record
Client reference: Client can pass primary keys to other clients, enabling shared access

Visual Explanation

Key Properties

Primary key = identity: Two entity beans with same PK represent the same data
Shared across clients: Unlike session beans, multiple clients can use the same entity
Not just for databases: Identity concept applies even if using object databases
getPrimaryKey() in BMP: Bean uses PK to know which record to load/store in ejbLoad()/ejbStore()

Connections

Built from: Entity Bean, Primary Key Class
Builds into: Finder Methods (locate entities by identity)
Related: ejbCreate(), ejbLoad(), ejbStore()
Contrasts with: Session Bean (no identity—anonymous workers)

Edge Cases & Gotchas

Composite primary keys: Sometimes PK has multiple fields—need a custom PK class
Identity crisis in pool: Pooled entity beans can represent different records at different times (container swaps the data)
getPrimaryKey() not for clients: It’s for BMP beans to know which record to access

entity-bean-instance-vs-data

2026-04-29T00:00:00.000Z

The Problem

The term “Entity Bean” is used loosely—sometimes it means the in-memory Java object, sometimes it means the database record. This confusion makes discussions about entity beans unclear. What’s the difference?

Core Idea

The EJB spec clarifies two distinct concepts:

Entity Bean Instance: The in-memory Java object (an instance of your entity bean class). It’s the “view” into the database.
Entity Bean Data: The actual persistent data stored in the database (the record/row).

The instance loads data from the database (in ejbLoad()), modifies it in memory, and saves it back (in ejbStore()).

How It Works

Database Record (Entity Bean Data)
    ↓ ejbLoad()
In-Memory Object (Entity Bean Instance)
    ↓ business methods modify fields
In-Memory Object (with changes)
    ↓ ejbStore()
Database Record (updated)

Visual Explanation

Key Properties

Instance is temporary: Created when needed, may be pooled/reused for different data
Data is permanent: Survives server crashes, lives in database
One-to-one mapping: At any moment, one instance represents one data record
Container manages sync: ejbLoad() and ejbStore() keep instance and data in sync

Connections

Built from: Entity Bean, ejbLoad(), ejbStore()
Builds into: BMP, CMP
Related: Persistence Concepts
Contrasts with: Session beans (no persistent data, only in-memory instances)

Edge Cases & Gotchas

Stale data: If another client modifies the DB directly, in-memory instance has old data (until next ejbLoad())
Instance pooling: The same Java instance might represent Ray’s account now, Bob’s account later (container reuses instances)
Transparent to client: Client doesn’t know or care about instance vs data distinction—they just call methods

explicit-vs-implicit-middleware

2026-04-29T00:00:00.000Z

The Problem

Distributed applications need middleware services: security, transactions, threading, network communication. Who should write this code—the application developer or the infrastructure?

Core Idea

Explicit Middleware: Developer manually writes code for networking, security, threading. You control everything but spend 80% of your time on infrastructure.
Implicit Middleware: The EJB container automatically handles middleware services. Developer writes only business logic; the server manages security, transactions, and networking behind the scenes.

How It Works

Aspect	Explicit Middleware	Implicit Middleware (EJB)
Networking	Developer writes socket/RMI code	Container generates stubs/skeletons
Security	Developer checks permissions in code	Container intercepts and checks roles
Transactions	Developer begins/commits transactions	Container manages via deployment descriptor
Threading	Developer manages thread pools	Container manages bean pooling

Visual Explanation

Key Properties

Implicit middleware = Productivity: Developer focuses on business value, not infrastructure
EJB Container is the implicit middleware provider: It intercepts calls and adds services
Declarative approach: In EJB, you declare requirements in ejb-jar.xml—container implements them
Vendor-specific: Each container provider (JBoss, WebLogic) implements the implicit middleware differently

Connections

Built from: Middleware, EJB Container
Builds into: Transactions, JNDI (both provided implicitly)
Contrasts with: RMI (explicit—you write all networking code)
Related: CMT vs BMT

Edge Cases & Gotchas

Debugging is harder with implicit middleware: When something fails, is it your code or the container?
Less control: You can’t fine-tune threading or connection pools—container decides
Vendor lock-in: Implicit middleware behavior varies across vendors (though standard APIs stay same)

j2ee-compliance

2026-04-29T00:00:00.000Z

The Problem

How do customers know if a vendor’s application server truly implements all J2EE APIs correctly? Vendors might claim compliance but cut corners or implement APIs incorrectly. We need a standardized way to verify and certify implementations.

Core Idea

J2EE compliance is achieved when a vendor’s product passes the Test Compatibility Kit (TCK) provided by Sun. Compliant products earn the “J2EE-compliant” brand, assuring customers that the product correctly implements the specification.

How It Works

Sun provides three things: Specifications (PDFs), TCK (test suite), and RI (reference implementation)
Vendor implements all J2EE APIs (EJB, JMS, JDBC, etc.)
Vendor runs TCK tests against their implementation
If all tests pass, Sun issues J2EE compliance certification
Customers can check reviews (e.g., TheServerSide.com) to compare compliant products

Compliance encourages competition while ensuring code portability.

Visual Explanation

Key Properties

TCK (Test Compatibility Kit): Comprehensive test suite from Sun
Certification: “J2EE-compliant” brand issued by Sun
Reference Implementation: Free, low-end implementation for developers
Vendor competition: Compliance encourages innovation and price competition
Customer confidence: Certified products guaranteed to work per spec

Connections

Built from: J2EE Specification — compliance verifies spec implementation
Builds into: EJB Container — containers must be J2EE-compliant
Related: Java Platforms — compliance applies to J2EE platform
Related: Component Architecture — compliant servers implement component model

Edge Cases & Gotchas

Incompatibilities: Ambiguities in spec can cause vendor differences despite compliance
Human nature of competition: Vendors may interpret ambiguous specs differently
Version lag: Some vendors slow to implement new J2EE versions
Proprietary extensions: Vendors add features beyond spec, creating lock-in

j2ee-specification

2026-04-29T00:00:00.000Z

The Problem

Enterprise software needs a standard set of APIs and behaviors so that applications work across different vendor implementations. Without a specification, each vendor creates proprietary, incompatible systems, locking customers into a single vendor.

Core Idea

J2EE is a specification (a set of rules/PDFs), not a product. It defines the APIs and behaviors that vendors must implement to be “J2EE-compliant.” This ensures portability across different application servers (WebLogic, GlassFish, JBoss).

How It Works

JCP (Java Community Process) creates the specification documents (PDFs)
Each specification version locks down specific API versions (EJB 2.1, Servlet 2.4, etc.)
Vendors implement the specification in their products
Sun provides a Test Compatibility Kit (TCK) to verify compliance
Compliant products can be certified and branded as “J2EE-compliant”

J2EE 1.4 bundles EJB 2.1, JMS 1.1, JTA 1.0, etc. as the de facto versions.

Visual Explanation

Key Properties

Not a product: Specification is a document, not software you run
Vendor-neutral: Not tied to one vendor, encourages competition
Portable: Code runs on any compliant server
Versioned: Each J2EE version bundles specific API versions
Community-driven: Created by JCP with industry experts

Connections

Built from: Component Architecture & SOA — J2EE implements component architecture
Builds into: EJB Container — EJB is part of J2EE
Related: J2EE Compliance — how vendors prove they implement the spec
Related: Java Platforms — J2EE is one of three Java platforms
Contrasts with: Proprietary System — J2EE is open standard

Edge Cases & Gotchas

Ambiguities: Specifications may have ambiguous points leading to vendor differences
Version mismatches: Mixing APIs from different J2EE versions causes issues
Vendor extensions: Vendors may add proprietary features beyond the spec
Compliance != Compatibility: Technically compliant products may still differ

J2EE Technology Stack — Platform Components Compared

2026-04-29T00:00:00.000Z

The Problem

J2EE has many APIs (EJB, JMS, JDBC, JNDI, Servlets, JSP, etc.). Students often memorize them as a random list. How do we organize them into a logical structure that shows relationships and purposes?

Core Idea

J2EE technologies can be grouped into 5 logical layers: Presentation/Web, Business Logic, Communication/Integration, Data/Persistence, and Foundation Services. This layered view shows how technologies relate and depend on each other.

Comparison by Layer

1. Presentation / Web Technologies (Client-Facing)

Technology	Purpose	Key Characteristic
Servlets	HTTP request/response handling	Java classes, foundation of web tier
JSP	Dynamic HTML generation	Compiles to servlets, HTML-centric

Relationship: JSP compiles to servlets. Both handle web requests but JSP separates UI from logic.

2. Business Logic Layer (The Brain)

Technology	Purpose	Key Characteristic
EJB	Server-side business components	Container-managed services (transactions, security)

Relationship: EJB is the cornerstone of J2EE. Servlets/JSP often call EJBs for business logic.

3. Communication & Integration

Technology	Purpose	Key Characteristic
RMI-IIOP	Synchronous distributed objects	Official J2EE remoting, CORBA-compatible
JMS	Asynchronous messaging	Two domains: PTP (Queue) and Pub/Sub (Topic)
JCA	Legacy system integration	Resource adapters for SAP, CICS, etc.
JAX-RPC	Web Services (SOAP)	Two endpoint models (servlet or EJB-based)
Java IDL	CORBA integration	Cross-language communication

Relationship: RMI-IIOP is used by EJBs for remoting. JMS provides async alternative. JCA connects to legacy. JAX-RPC for web services.

4. Data & Persistence

Technology	Purpose	Key Characteristic
JDBC	Relational database access	Universal API, works with any RDBMS
JAXP	XML parsing	Implementation-neutral (DOM/SAX)

Relationship: EJBs often use JDBC for database access. JAXP for XML data in web services.

5. Foundation Services (Middleware)

Technology	Purpose	Key Characteristic
JNDI	Naming and directory	Location transparency, unified API for all directories
JTA/JTS	Transactions	Distributed transactions across resources
JAAS	Security	Pluggable authentication and authorization
JavaMail	Email	Platform-independent email sending

Relationship: JNDI is used by EJBs to look up resources. JTA provides transactions. JAAS provides security.

Visual Explanation

Key Insights

Layered dependency: Presentation → Business → Integration → Data, with Foundation Services supporting all layers
EJB is central: Most technologies either support EJBs or are used by them
Two communication paradigms: Synchronous (RMI-IIOP) vs Asynchronous (JMS)
Modern equivalent: Spring Boot simplifies this by embedding many of these (Spring Data = JDBC, Spring Security = JAAS, etc.)
Exam strategy: Group by layer, not alphabetically—shows understanding of architecture

Connections

All technology pages listed above:
- Servlets, JSP
- Session Bean, Entity Bean, Message-Driven Bean
- RMI-IIOP, JMS, JCA, JAX-RPC, Java IDL
- JDBC, JAXP
- JNDI, JTS, JAAS, JavaMail
Related: Java Platforms — all are part of J2EE
Related: Middleware — foundation services are middleware

Edge Cases & Gotchas

Overlap: Some technologies span layers (JNDI is used in web tier too)
Version differences: J2EE 1.4 vs Java EE 5+ have different API versions
Modern replacements: JAX-RPC → JAX-WS, Java IDL rarely used today
Spring alternative: Modern apps use Spring which abstracts many of these

jaas

2026-04-29T00:00:00.000Z

The Problem

J2EE applications need standardized security: verifying who the user is (authentication) and what they’re allowed to do (authorization). Without a standard API, each application implements security differently, leading to inconsistencies and security holes.

Core Idea

JAAS (Java Authentication and Authorization Service) is the standard API for performing security operations in J2EE. It enables plugging in authentication mechanisms into J2EE application servers and provides both authentication and authorization services.

How It Works

Authentication: Verifies user identity (login, password, certificates, etc.)
Authorization: Determines what authenticated user can do (roles, permissions)
Pluggable: Different authentication mechanisms can be plugged in (LDAP, database, Kerberos, etc.)
J2EE integration: Works with EJB security (Chapter 13 covers EJB security details)
Standard API: Part of J2EE platform

JAAS uses a callback mechanism for authentication and Policy-based authorization.

Visual Explanation

Key Properties

Pluggable authentication: Swap auth mechanisms without code changes
Authentication + Authorization: Both identity and permissions
J2EE standard: Part of J2EE platform
Callback-based: Flexible authentication dialog
Policy-based: Authorization via security policies

Connections

Built from: EJB Container — container uses JAAS for EJB security
Related: Java Platforms — JAAS is part of J2EE
Builds into: Application vs System Exceptions — security exceptions
Related: Middleware — security is a middleware service

Edge Cases & Gotchas

Configuration complexity: JAAS config files can be tricky
Callback handling: Custom callbacks need careful implementation
Policy management: Authorization policies must be properly configured
Chapter 13: See EJB-specific security details there

java-idl

2026-04-29T00:00:00.000Z

The Problem

Java applications need to communicate with objects written in other languages (C++, Python, etc.) in a distributed environment. CORBA is the standard for cross-language distributed objects, but Java needs a way to participate in CORBA ecosystems.

Core Idea

Java IDL is Sun’s Java-based implementation of CORBA (Common Object Request Broker Architecture). It allows Java objects to integrate with other languages through CORBA services, making J2EE fully compatible with CORBA.

How It Works

IDL (Interface Definition Language): Language-neutral way to define interfaces
Java IDL: Maps IDL interfaces to Java interfaces
CORBA ORB: Object Request Broker handles cross-language communication
IIOP protocol: Internet Inter-ORB Protocol for CORBA communication
J2EE compatibility: Full CORBA compatibility completes Java 2 Platform

Appendix B of the source discusses CORBA interoperability in detail.

Visual Explanation

Key Properties

Cross-language: Java can talk to C++, Python, etc.
CORBA standard: Implements CORBA 2.x specification
IIOP protocol: Standard wire protocol for CORBA
J2EE integration: Part of J2EE platform
Full CORBA services: Leverages complete CORBA service set

Connections

Built from: RMI — similar concept, Java-only vs cross-language
Related: RMI-IIOP — RMI over IIOP protocol (used in J2EE)
Builds into: Distributed Objects — Java IDL enables cross-language distributed objects
Related: Java Platforms — Java IDL is part of J2EE

Edge Cases & Gotchas

Legacy technology: CORBA/IDL largely replaced by REST/JSON
Complexity: CORBA has steep learning curve
IIOP firewall issues: IIOP may be blocked by firewalls
Modern alternative: Use REST or gRPC for cross-language communication

java-platforms

2026-04-29T00:00:00.000Z

The Problem

Java targets different types of devices and use cases: tiny mobile devices, standard desktop applications, and large enterprise servers. One-size-fits-all doesn’t work—each needs different APIs and capabilities. How does Java organize its platform offerings?

Core Idea

Java has three platforms in a hierarchical relationship: J2ME (Micro Edition) for mobile/embedded, J2SE (Standard Edition) for desktop/apps, and J2EE (Enterprise Edition) for server-side enterprise applications. Each platform is a conceptual superset of the next smaller platform.

How It Works

J2ME (Micro Edition): Restricted Java for mobile devices (phones, PDAs, set-top boxes). Limited APIs due to performance/memory constraints.
J2SE (Standard Edition): Core Java libraries (I/O, GUI, networking). Foundation for all Java development.
J2EE (Enterprise Edition): Builds on J2SE, adds enterprise APIs (EJB, JMS, JDBC, etc.). Conceptual superset of J2SE.

A J2EE-compliant product must implement all of J2SE plus the J2EE-specific APIs.

Visual Explanation

Key Properties

Hierarchical: J2EE ⊃ J2SE ⊃ J2ME (conceptual superset)
J2SE foundation: All platforms build on standard Java core
J2EE barrier to entry: Implementing J2EE is huge undertaking (includes all J2SE + enterprise APIs)
Industry consolidation: High barrier led to few major J2EE players
J2ME restrictions: Limited by device memory and processing power

Connections

Builds into: J2EE Specification — J2EE is one platform
Built from: Component Architecture — J2EE implements this
Related: EJB Container — EJB is part of J2EE
Related: J2EE Compliance — compliance applies to J2EE platform

Edge Cases & Gotchas

“Conceptual superset”: Not strict subset/superset in code terms
J2SE in J2EE: J2EE products must pass J2SE tests too
Modern names: J2ME → Java ME, J2SE → Java SE, J2EE → Java EE
Android: Not part of this hierarchy—uses different APIs

javamail

2026-04-29T00:00:00.000Z

The Problem

J2EE applications often need to send email notifications (order confirmations, password resets, alerts). Without a standard API, developers must deal with vendor-specific email protocols (SMTP, POP3, IMAP) directly.

Core Idea

JavaMail enables sending email messages in a platform-independent, protocol-independent manner from Java programs. It depends on JavaBeans Activation Framework (JAF), which also becomes part of J2EE.

How It Works

Protocol-independent: Works with SMTP, POP3, IMAP without code changes
Session creation: Obtain javax.mail.Session (often via JNDI)
Message construction: Create MimeMessage with subject, body, recipients
Transport: Use Transport.send() to send the message
J2EE integration: Use in servlets, JSP, or EJB components

Example: Send order confirmation email from an e-commerce site.

Visual Explanation

Key Properties

Platform-independent: Works on any Java platform
Protocol-independent: Supports SMTP, POP3, IMAP
JAF dependency: Requires JavaBeans Activation Framework
J2EE standard: Part of J2EE platform
Server-side use: Commonly used in J2EE deployments

Connections

Built from: Java Platforms — JavaMail is part of J2EE
Related: EJB Container — EJB components can use JavaMail
Related: Servlets — servlets commonly send emails
Related: JSP — JSP pages can trigger email sending

Edge Cases & Gotchas

JAF required: Forgetting JAF causes ClassNotFound errors
SMTP configuration: Must configure SMTP host correctly
Authentication: SMTP may require username/password
Not covered: The source book does not cover JavaMail in detail

jax-rpc

2026-04-29T00:00:00.000Z

The Problem

Java applications need to build and consume web services (SOAP-based) in a standardized way. Without a common API, each developer would implement SOAP/XML parsing differently, leading to interoperability issues.

Core Idea

JAX-RPC (Java API for XML RPC) is the main technology for developing web services on J2EE. It defines two endpoint models: one based on servlet technology and another based on EJB. It specifies runtime requirements for web service support in J2EE.

How It Works

Endpoint models: Servlet-based (easier) and EJB-based (full container services)
SOAP messaging: JAX-RPC handles SOAP request/response serialization
WSDL support: Generates and parses WSDL descriptions
Deployment: “Web Services for J2EE” spec defines deployment requirements using JAX-RPC programming model
J2EE integration: Works with J2EE security, transactions, and lifecycle

Chapter 5 of the source book discusses JAX-RPC support for EJB applications.

Visual Explanation

Key Properties

SOAP-based: Uses SOAP protocol for XML RPC
Two endpoint models: Servlet (simple) and EJB (full services)
J2EE standard: Part of J2EE 1.4 specification
WSDL integration: Works with WSDL service descriptions
Runtime requirements: Specifies how containers must support web services

Connections

Built from: EJB Container — EJB endpoint model uses container services
Related: Java Platforms — JAX-RPC is part of J2EE
Builds into: Web Services — JAX-RPC enables web service development
Contrasts with: REST — JAX-RPC is SOAP/XML, REST is simpler HTTP

Edge Cases & Gotchas

Deprecated: JAX-RPC replaced by JAX-WS in modern Java EE
SOAP complexity: XML serialization has overhead
EJB endpoint overhead: Full container services may be unnecessary for simple services
WS- standards*: Many additional specs beyond core JAX-RPC

jaxp

2026-04-29T00:00:00.000Z

The Problem

J2EE applications frequently need to parse XML documents (for B2B interactions, legacy system data mapping, or persisting XML to databases). Without a standard API, developers use different XML parsers inconsistently, leading to vendor lock-in and portability issues.

Core Idea

JAXP (Java API for XML Parsing) is the de facto API for parsing XML documents in J2EE applications. It’s implementation-neutral, working with various XML parsing technologies like DOM and SAX.

How It Works

Implementation-neutral: JAXP API works with any compliant parser (Xerces, Crimson, etc.)
DOM parsing: Loads entire XML into memory as a tree (good for small docs, random access)
SAX parsing: Event-based, reads XML sequentially (good for large docs, memory-efficient)
Used from: Servlets, JSP, or EJB components
J2EE standard: Part of J2EE platform

Common use cases: B2B Web Services (SOAP uses XML), legacy data mapping, XML persistence.

Visual Explanation

Key Properties

Implementation-neutral: Switch parsers without changing code
DOM support: Tree-based parsing for random access
SAX support: Event-based parsing for large documents
J2EE standard: Part of J2EE platform
Widely used: SOAP, B2B, XML persistence all use JAXP

Connections

Built from: Java Platforms — JAXP is part of J2EE
Related: JAX-RPC — JAX-RPC uses XML/SOAP (parsed by JAXP)
Builds into: Web Services — XML parsing is core to web services
Related: EJB Container — EJB components can use JAXP

Edge Cases & Gotchas

DOM memory: Large XML docs can cause OutOfMemoryError with DOM
SAX complexity: Event-based model is harder to program
Parser configuration: Must ensure correct parser is on classpath
Namespace support: Proper namespace handling requires care

jca

2026-04-29T00:00:00.000Z

The Problem

Enterprises have existing systems (mainframes with CICS/TUXEDO, ERP systems like SAP/Siebel, proprietary systems) that J2EE applications need to access. Without a standard way to connect, each vendor writes custom, incompatible integrations, leading to maintenance nightmares.

Core Idea

JCA (J2EE Connector Architecture) enables J2EE applications to access existing enterprise information systems (EIS) through standard resource adapters. Write once, deploy to any J2EE-compliant server. Handles transactions, security, lifecycle, and thread management automatically.

How It Works

Resource Adapter: JCA-compliant adapter for the EIS (like SAP adapter)
System Contracts: Adapter implements contracts for connection management, transaction management, and security
Application: Uses standard J2EE APIs to call the adapter
Container manages: Transactions, security, lifecycle, threading handled by container
Portable: Deploy same adapter to any J2EE-compliant server

Chapter 17 discusses legacy integration in more detail.

Visual Explanation

Key Properties

Write once, run anywhere: Single adapter works on all J2EE servers
Container-managed: Transactions, security, lifecycle handled by container
ISV benefit: Independent Software Vendors (SAP, Siebel) write one adapter
Standard contracts: Connection, transaction, security contracts defined by JCA spec
Legacy integration: Bridges modern J2EE with legacy systems

Connections

Built from: EJB Container — container manages JCA adapters
Related: Java Platforms — JCA is part of J2EE
Builds into: Message-Driven Bean — JCA 1.5+ supports MDB for non-JMS messages
Related: Middleware — JCA is middleware for legacy integration

Edge Cases & Gotchas

Adapter quality: Poorly written adapters can cause issues
Transaction propagation: XA transactions across EIS systems can be complex
Connection pooling: Adapter must properly implement connection management
JCA versions: JCA 1.5 added Message Inflow (for MDBs)

jndi-architecture

2026-04-29T00:00:00.000Z

The Problem

Java applications need to access different naming and directory services (LDAP, NIS, Novell NDS), but each has its own protocol and API. Learning and coding to multiple vendor-specific APIs is complex and creates vendor lock-in. How can we provide a single, unified interface?

Core Idea

JNDI has a two-part architecture: the Client API (for application developers) and the Service Provider Interface or SPI (for vendor implementations). The Client API provides a uniform interface for all directory operations, while the SPI allows vendors to plug in their specific protocols behind a common interface.

How It Works

Client API layer: Application code uses javax.naming classes (InitialContext, Context) to perform lookups, bindings, and searches
SPI layer: Vendors implement javax.naming.spi interfaces to bridge JNDI calls to their specific protocols
Service Providers: LDAP provider maps JNDI calls to LDAP protocol; NIS provider maps to NIS protocol, etc.
Pluggable architecture: Swap providers without changing application code
J2EE integration: J2EE servers bundle custom JNDI implementations, often fault-tolerant and integrated with other services (RMI-IIOP, JDBC, JMS)

Analogous to JDBC: Client API = JDBC API; SPI = JDBC Drivers.

Visual Explanation

Key Properties

Unified API: Single API for all directory types (LDAP, NIS, NDS, filesystem)
Protocol insulation: Application code doesn’t know or care about underlying protocol
Pluggable providers: Vendors implement SPI to support their directory service
Federated directories: Combine multiple directories (LDAP + NDS) into one logical view
Portable: Code works across different JNDI implementations
J2EE integration: Used for EJB lookups, DataSource lookups, JMS connection factories

Connections

Built from: JNDI — JNDI is the naming service this architecture implements
Builds into: EJB Naming Service — EJB uses JNDI for bean lookups
Contrasts with: RMI — RMI Registry is narrower, JNDI is broader
Related: JDBC — similar API/driver architecture pattern
Builds into: Location Transparency — JNDI enables location-independent lookups
Related: EJB Container — containers provide JNDI implementations

Edge Cases & Gotchas

Provider not found: If the service provider class isn’t on classpath, lookups fail
Different JNDI trees: Each server vendor may use different JNDI naming conventions
Performance: JNDI lookups have overhead; cache references when possible
Federated directories: Can be complex to configure and debug
InitialContext: Must be configured with correct environment properties for the provider

jndi-binding

2026-04-29T00:00:00.000Z

The Problem

In a naming system, we need to associate names with objects so clients can look them up. How do we represent the association between a name (like autoexec.bat) and the actual object it refers to (the file data on disk)?

Core Idea

A binding is an association of a name with an object. For example, autoexec.bat is bound to the file data on your hard disk. In JNDI, bindings are the fundamental associations that make up contexts—each context contains a set of bindings.

How It Works

A binding maps a name (atomic name) to an object
In file system: autoexec.bat → file data on disk
In JNDI: MyBean → EJB Home Object reference
A compound name like /usr/people/ed/.cshrc consists of multiple bindings resolved sequentially
Bindings are created with Context.bind(name, obj) and looked up with Context.lookup(name)

Visual Explanation

Key Properties

Name → Object: The core association in naming systems
Atomic name key: Bindings are keyed by atomic names within a context
Mutable: Bindings can be added, removed, or changed
Type-independent: The bound object can be any Java object
Serializable: Objects bound in JNDI should typically be serializable

Connections

Built from: Atomic Name — bindings use atomic names as keys
Built from: JNDI Context — contexts contain bindings
Builds into: Compound Name — compound names resolve through multiple bindings
Related: JNDI Naming Concepts — bindings are a core concept
Related: JNDI — JNDI provides the API for managing bindings

Edge Cases & Gotchas

Overwriting bindings: Rebinding a name replaces the existing binding
Null bindings: Binding null may be allowed or may throw exception
Object serialization: Bound objects must be serializable for some providers
Garbage collection: Binding keeps a reference to the object (prevents GC)

jndi-context

2026-04-29T00:00:00.000Z

The Problem

In a hierarchical naming system, we need containers that group related name-to-object associations together. How do we represent a “folder” in the naming tree that contains multiple bindings?

Core Idea

A context is a set of zero or more bindings, where each binding has a distinct atomic name. In the UNIX file system, a folder like /etc is a context containing bindings to files like mtab and exports. Each context is also a subcontext of its parent.

How It Works

Context implements javax.naming.Context interface
Contains bindings: name → object mappings
Operations: lookup(name), bind(name, obj), unbind(name), list()
Subcontext: A context within a context (like /usr/people within /usr)
Each subcontext is a full context itself, capable of containing more bindings

In JNDI, the root context is obtained via new InitialContext(). Subcontexts are created with createSubcontext().

Visual Explanation

Key Properties

Container of bindings: Groups related name→object associations
Hierarchical: Can contain subcontexts, forming a tree
Context operations: lookup, bind, unbind, rename, list, createSubcontext
InitialContext: The entry point for JNDI operations
Serializable: Contexts can be bound into other contexts

Connections

Built from: JNDI Binding — contexts contain bindings
Built from: JNDI Naming Concepts — contexts are central to JNDI
Builds into: Subcontext — a context within a context
Related: JNDI — JNDI provides the Context API
Related: Atomic Name — bindings in a context have atomic names

Edge Cases & Gotchas

Closing contexts: Always close contexts to free resources
Concurrent access: Context operations may not be thread-safe
Lazy loading: Large contexts may not load all bindings immediately
Context destruction: Destroying a context may not recursively destroy subcontexts

jndi-naming-concepts

2026-04-29T00:00:00.000Z

The Problem

JNDI organizes names and objects in a tree structure similar to a file system. Without understanding the fundamental naming concepts (atomic names, compound names, bindings, contexts), developers cannot effectively navigate or manipulate the JNDI directory tree.

Core Idea

JNDI uses a hierarchical naming model with five key concepts: atomic names (indivisible), compound names (combinations), bindings (name→object associations), contexts (sets of bindings), and subcontexts (contexts within contexts). This mirrors the file system model.

How It Works

Atomic Name: A simple, indivisible name (e.g., etc, fstab, usr)
Compound Name: Multiple atomic names combined with syntax (/etc/fstab, /usr/bin)
Binding: Association of a name with an object (autoexec.bat → file data)
Context: A set of bindings with distinct atomic names (/etc contains mtab, exports)
Subcontext: A context within a context (/usr/people is a subcontext of /usr)

A compound name like /usr/people/ed/.cshrc represents multiple bindings resolved sequentially through the tree.

Visual Explanation

Key Properties

Tree structure: Hierarchical, like a file system
Atomic names: Cannot be subdivided further
Compound names: Path-like combinations of atomic names
Bindings: Name-to-object mappings, core of JNDI operations
Contexts: Containers for bindings, can be nested (subcontexts)
JNDI compound names: Can use different syntaxes (slash, dot, etc.)

Connections

Built from: JNDI — JNDI implements these naming concepts
Builds into: JNDI Context — contexts are central to JNDI operations
Related: JNDI Binding — bindings are the associations within contexts
Related: Atomic Name, Compound Name
Related: Subcontext — subcontexts enable hierarchical organization

Edge Cases & Gotchas

Compound name syntax: Different providers may use different separators
Reserved characters: Some characters may need escaping in names
Context destruction: Destroying a context may not destroy its subcontexts
Lazy loading: Large contexts may load bindings lazily
Compound name parsing: Be careful with provider-specific parsing rules

jndi-spi

2026-04-29T00:00:00.000Z

The Problem

JNDI defines a common client API, but how do different directory vendors (LDAP, NIS, Novell) make their services accessible through that API? There needs to be a standardized way for vendors to plug their proprietary protocols into the JNDI framework.

Core Idea

The JNDI SPI is a framework that naming and directory service vendors implement to bridge JNDI client API calls to their specific protocols. It’s the “converse” of the API—while the API is for client developers, the SPI is for vendor implementors.

How It Works

Vendor implements javax.naming.spi interfaces (InitialContextFactory, StateFactory, etc.)
Provider maps JNDI operations (lookup, bind, search) to vendor-specific protocol operations
For example, LDAP provider converts ctx.lookup("cn=John") into an LDAP search operation
Provider handles connection management, authentication, and protocol details
Client code remains unchanged regardless of which provider is plugged in

Sun provides a free LDAP service provider; vendors can write their own for proprietary directories.

Visual Explanation

Key Properties

Vendor extensibility: Any vendor can implement a JNDI provider
Protocol translation: Converts generic JNDI calls to specific protocol operations
Pluggable: Replace providers without changing client code
Standardized: javax.naming.spi package defines the contract
Bundled with J2EE: Many J2EE servers bundle custom JNDI implementations

Connections

Built from: JNDI Architecture — SPI is one half of JNDI
Builds into: JNDI — SPI enables JNDI’s unified interface
Related: JDBC Drivers — similar plugin architecture for databases
Contrasts with: JNDI Client API — SPI is for vendors, API is for developers

Edge Cases & Gotchas

Provider not found: Classpath must include the provider library
Version compatibility: Provider must match JNDI version
Connection pooling: Provider may or may not implement connection pooling
Thread safety: Provider implementations must be thread-safe

jsp

2026-04-29T00:00:00.000Z

The Problem

Writing HTML in Java servlets is painful—Java code is mixed with HTML strings. Web designers who don’t know Java need to modify the look-and-feel. How can we separate presentation from business logic?

Core Idea

JSP (JavaServer Pages) is similar to servlets but centered on look-and-feel. JSP scripts are HTML-like with embedded Java code, compiled into servlets. They enable non-Java staff to maintain the UI separately from business logic.

How It Works

JSP script: HTML file with embedded Java (scriptlets, expressions, declarations, directives)
Lifecycle: Translation (JSP → servlet source) → Compilation (servlet source → .class) → init() → service() → destroy()
Directives: <%@ page %> (page settings), <%@ include %> (static includes), <%@ taglib %> (custom tags)
Scripting elements: <%! %> declarations, <% %> scriptlets, <%= %> expressions
EL (Expression Language): ${bean.property} syntax for accessing Java beans without scriptlets
JSTL: Standard tag library (<c:if>, <c:forEach>, <c:out>) enabling logic without Java code
Implicit objects: request, response, session, application, out, pageContext, config, page, exception
Compilation: JSP is compiled into a servlet on first access
Separation: UI in JSP, business logic in EJB/servlets
J2EE integration: Can call EJB components, use JNDI, etc.

JSP is perfect when you want physically separate, easily maintainable UI code.

Visual Explanation

Key Properties

HTML-centric: Looks like HTML with embedded Java
Compiles to servlet: Under the hood, it’s a servlet
Lifecycle: Translation → Compilation → init → service → destroy
Directives: page, include, taglib — control page behavior
EL (Expression Language): ${} syntax, auto-scoped attribute lookup
JSTL: Core, formatting, SQL, XML, functions tag libraries
Implicit objects: 9 pre-defined objects accessible in any JSP
No compiler needed: At deployment time
Non-Java friendly: Web designers can maintain JSPs
Separate maintenance: UI separated from business logic
J2EE standard: Part of J2EE platform

Connections

Built from: Servlets — JSP compiles to servlets
Built from: Java Platforms — JSP is part of J2EE
Builds into: EJB Container — JSP can call EJBs
Related: JSP — alternative to servlets for presentation
Contrasts with: Session Bean — JSP is presentation, EJBs are business logic

Edge Cases & Gotchas

Scriptlet pollution: Avoid too much Java in JSP (use JSTL/EL)
First-access delay: Compilation happens on first access
Chapter 22: See EJB with JSP examples there
Modern alternative: Consider Facelets/Thymeleaf in modern apps

jta-jts

2026-04-29T00:00:00.000Z

The Problem

Distributed transactions across multiple databases or systems need coordination. Without a standard API, each vendor implements transactions differently, breaking portability and making it hard to build reliable enterprise applications.

Core Idea

JTA (Java Transaction API) and JTS (Java Transaction Service) provide reliable transaction support for J2EE components. JTA is the API that developers use; JTS is the underlying transaction service implementation (based on CORBA OTS).

How It Works

JTA API: Developer uses UserTransaction interface (looked up via JNDI)
Transaction demarcation: begin(), commit(), rollback() methods
JTS: Implements CORBA Object Transaction Service (OTS) specification
Distributed transactions: Coordinates transactions across multiple resources (XA protocol)
Container-managed: EJB containers can manage transactions declaratively (CMT)

Chapter 12 explains JTA/JTS in detail.

Visual Explanation

Key Properties

JTA: API for transaction demarcation (developer-facing)
JTS: Service implementation (CORBA OTS-based)
Distributed: Coordinates across multiple resources
XA support: Two-phase commit protocol
J2EE standard: Part of J2EE platform
CMT integration: EJB container can manage transactions declaratively

Connections

Built from: Transactions in EJB — JTA/JTS provide transaction support
Builds into: CMT vs BMT — JTA enables both models
Related: EJB Container — container uses JTA/JTS for CMT
Related: Java Platforms — JTA/JTS are part of J2EE

Edge Cases & Gotchas

Heuristic outcomes: Transactions may have heuristic commits/rollbacks
Timeout: Transactions can timeout, causing rollback
Nested transactions: J2EE uses flat transactions, not nested
Resource enlistment: Resources must support XA for distributed transactions

local-home-interface

2026-04-29T00:00:00.000Z

The Problem

The regular Home Interface uses RMI-IIOP for network communication—even when the client and bean are in the same JVM. This adds unnecessary overhead (serialization, network stack) for local calls.

Core Idea

The Local Home Interface (javax.ejb.EJBLocalHome) is the high-performance version of the Home Interface. It’s used when the client and bean are in the same JVM—no network calls, no RemoteException, direct memory access.

How It Works

Extends EJBLocalHome: Unlike regular Home which extends EJBHome (which extends java.rmi.Remote)
No RemoteException: Since there’s no network call, there’s no possibility of network failure
Returns Local Interface: create() returns HelloLocal (local interface), not remote
Fast: Uses pass-by-reference semantics within the same JVM

Visual Explanation

Key Properties

No RemoteException: Cleaner method signatures
Pass-by-reference: Parameters passed directly (not serialized)
Faster: No RMI-IIOP overhead
Same JVM requirement: Cannot be used for remote clients

Connections

Built from: Home Interface (remote version)
Builds into: Remote Interface (contrast: remote has network overhead)
Related: EJB Object, Session Bean
Contrasts with: Home Interface (remote, has RemoteException)

Edge Cases & Gotchas

Mixing local and remote: If you look up a LocalHome via JNDI from a remote client, you’ll get an error
ClassLoader issues: In same JVM but different ClassLoaders can still cause problems
Transaction propagation: Local calls propagate transactions automatically (unlike remote which may require distributed transactions)

Code Example

public interface HelloLocalHome extends javax.ejb.EJBLocalHome {
    HelloLocal create() throws javax.ejb.CreateException;
    // Note: No RemoteException!
}

location-transparency

2026-04-29T00:00:00.000Z

The Problem

In distributed systems, clients need to know where a service lives (machine name, IP address, port). If the service moves to a different server, you must rewrite and recompile all client code. This creates tight coupling between clients and server locations.

Core Idea

EJB achieves location transparency through JNDI (Java Naming and Directory Interface). Clients look up beans by a logical name (nickname) like "HelloHome", not by physical address. The JNDI naming service maps this nickname to the actual Home Object reference—change the server, update JNDI, client code stays the same.

How It Works

Deployer binds nickname: During deployment, container registers Home Object with JNDI using a nickname (e.g., "HelloHome")
Client looks up by nickname: ctx.lookup("HelloHome") — no machine names in client code
JNDI resolves location: JNDI service (LDAP, COS Naming, or in-process) finds the actual object reference
Server moves?: Just update JNDI — client code unchanged

Visual Explanation

Key Properties

“Write Once, Run Anywhere”: Client code portable across different server deployments
Naming services: JNDI supports LDAP, CORBA Naming, in-process JNDI trees
Vendor-independent: The lookup code is standard JNDI—works on any EJB container
Purchased components: If you buy pre-written beans (no source), location transparency is essential—you can’t rewrite them

Connections

Built from: JNDI, Home Interface (what gets looked up)
Builds into: Distributed Objects (clients can access beans anywhere)
Related: Middleware (JNDI is a middleware service)
Contrasts with: Hard-coded addresses (client breaks if server moves)

Edge Cases & Gotchas

JNDI properties still machine-specific: Context.PROVIDER_URL specifies naming service location—but this is configuration, not code
Network partition: If JNDI service is unreachable, lookup fails (even if bean is running)
Nickname collisions: Two beans with same JNDI name cause deployment errors

persistence-concepts

2026-04-29T00:00:00.000Z

The Problem

Objects live in RAM—when the program stops, they’re gone. To keep data permanently (across restarts, for other applications to use), objects must be saved to persistent storage (database, filesystem). What are the ways to persist Java objects?

Core Idea

There are two main ways to persist Java objects:

Serialization: Convert the entire object to a byte stream (blob) and save it. Simple but not queryable.
Object-Relational Mapping (ORM): Decompose the object into fields and store them as rows/columns in a relational database. Queryable and debuggable.

Entity Beans use ORM (not serialization) for persistence.

How It Works

Mechanism	How	Pros	Cons
Serialization	`ObjectOutputStream` → byte blob	Simple, built-in	Not queryable, hard to debug
ORM	Map fields → table columns	Queryable, standard SQL	More complex setup
Object DB	Store as native object	No mapping needed	Not widely adopted

Visual Explanation

Key Properties

Entity Beans use ORM: They map to relational database tables (not serialization)
EJB doesn’t dictate ORM tool: You can use JDBC (BMP) or container-managed (CMP)
Modern tools: Hibernate, TopLink, JDO—automate ORM (popular in EJB 3.x+)
Queryable: Unlike serialization, ORM lets you run SQL queries like “find all accounts with balance > $1000”

Connections

Built from: Object-Relational Mapping, Entity Bean
Builds into: Bean-Managed Persistence (JDBC), Container-Managed Persistence (auto)
Related: JDBC (API for ORM implementation)
Contrasts with: Session beans (non-persistent, RAM-only)

Edge Cases & Gotchas

Serialization is easier but limiting: Good for simple caching, bad for business data
ORM has a learning curve: Mapping complex object relationships to tables requires skill
JDO (Java Data Objects): Alternative to EJB entity beans for persistence (portable across databases)

primary-key

2026-04-29T00:00:00.000Z

The Problem

In databases, we need a way to uniquely identify each row/record. Without a unique identifier, we can’t reliably update, delete, or reference specific records. Multiple records might have identical data but represent different entities.

Core Idea

A primary key is a column (or set of columns) whose values uniquely identify each row in a database table. In EJB entity beans, the primary key is wrapped in a PrimaryKeyClass object that the container uses for identity management.

How It Works

In relational databases:

Uniqueness — no two rows can have the same primary key value
Non-null — primary key cannot be NULL
Immutable — once set, primary key shouldn’t change

In EJB Entity Beans:

PrimaryKeyClass — wrapper class implementing Serializable and optionally hashCode/equals
getPrimaryKey() — method to retrieve current entity’s primary key
Finder methods — return primary keys to locate entities
Container uses PK — for pooling, identity, and relationship management

Visual Explanation

Key Properties

Unique identification — each entity instance has distinct primary key
Serializable — PrimaryKeyClass must implement java.io.Serializable
Simple or composite — single field or multiple fields combined
Container-managed — EJB container tracks entities by primary key

Connections

Built from: Entity Bean — entity beans use primary keys for identity
Built from: Entity Bean Identity — PK defines entity identity
Builds into: Finder Methods — return primary keys
Builds into: getPrimaryKey() — method to retrieve PK
Builds into: Primary Key Class — wrapper class for PK
Related: JDBC — SQL uses primary keys for WHERE clauses

Edge Cases & Gotchas

Composite keys — need custom PrimaryKeyClass with proper equals() and hashCode()
Auto-generated keys — database can generate (e.g., AUTO_INCREMENT), must sync to bean
Changing PK — don’t change primary key after creation; it breaks identity

resource-pooling

2026-04-29T00:00:00.000Z

The Problem

Creating expensive resources like database connections, socket connections, or threads for each client request is inefficient. These resources take time to create and are limited. How can we reuse them efficiently?

Core Idea

Resource pooling is the practice of maintaining a pool of ready-to-use resources (DB connections, sockets, threads) that are shared across clients. When a client needs a resource, it’s taken from the pool; when done, it’s returned for reuse.

How It Works

Pool creation: Container pre-creates N connections (e.g., 50 DB connections)
Client request: Client needs DB access → gets connection from pool
Usage: Client uses connection for SQL operations
Return: Connection returned to pool (not closed/destroyed)
Reuse: Next client gets the same connection

JDBC drivers, JMS connection factories, and EJB instances all use pooling.

Visual Explanation

Key Properties

Expensive resources: DB connections, sockets, threads are pooled
Container-managed: EJB container manages resource pools
Enormous efficiency: Same connection serves many clients
Shared by beans: Entity beans, session beans share DB connection pool
Configurable: Pool min/max size set in container config

Connections

Built from: Instance Pooling — bean pooling is one type of resource pooling
Builds into: JDBC — JDBC connections are pooled
Related: JMS — JMS connections also pooled
Related: EJB Container — container manages resource pools

Edge Cases & Gotchas

Leaked connections: Forgetting to close() returns connection to pool
Pool exhaustion: All connections busy → clients wait or fail
Transaction scope: Connection must remain same within transaction
Pool sizing: Too small = wait; too large = waste memory

rmi-iiop

2026-04-29T00:00:00.000Z

The Problem

RMI (Remote Method Invocation) originally used JRMP (Java Remote Method Protocol), which only works between Java objects. To integrate with CORBA (cross-language), we need RMI to use IIOP (Internet Inter-ORB Protocol) as its transport.

Core Idea

RMI-IIOP is RMI extended to use the IIOP protocol, enabling CORBA integration. It’s the official API used in J2EE (not plain RMI). EJB objects are fully networked RMI-IIOP objects callable from other JVMs.

How It Works

EJB Object: Implements javax.ejb.EJBObject which extends java.rmi.Remote
RMI-IIOP: Uses IIOP protocol instead of JRMP
Remote exceptions: All remote methods must throw java.rmi.RemoteException
Parameter passing: Primitives, serializable objects, RMI-IIOP remote objects
CORBA integration: Can interoperate with CORBA objects via IIOP

Appendix A covers RMI-IIOP in detail.

Visual Explanation

Key Properties

IIOP protocol: Standard CORBA wire protocol
Official J2EE: Used instead of plain RMI in J2EE
RemoteException: All remote methods must declare this
Parameter rules: Only certain types can be passed (primitives, serializable, remote objects)
CORBA compatible: Enables cross-language calls

Connections

Built from: RMI — RMI-IIOP extends RMI
Builds into: EJB Object — EJB objects are RMI-IIOP objects
Related: Java IDL — Java IDL also uses CORBA/IIOP
Related: Distributed Objects — RMI-IIOP enables distributed Java objects
Contrasts with: RMI Registry — RMI-IIOP uses IIOP, not JRMP

Edge Cases & Gotchas

Parameter restrictions: Not all objects can be passed (must be serializable or remote)
RemoteException: Forgetting to declare it causes compile error
Firewall issues: IIOP may be blocked (use HTTP tunneling if needed)
Appendix A: See full RMI-IIOP details there

serialization-vs-orm

2026-04-29T00:00:00.000Z

The Problem

You need to save a Java object permanently. Should you serialize it to a byte stream, or map it to a relational database? What are the trade-offs?

Core Idea

Aspect	Serialization	ORM (Object-Relational Mapping)
Storage format	Byte blob (unreadable)	Relational table (readable)
Querying	Cannot query (must deserialize everything)	Full SQL queries (`SELECT * WHERE balance > 1000`)
Debugging	Hard (blob is unreadable)	Easy (inspect table with SQL)
Tooling	Built into Java (`Serializable`)	Requires ORM tool (Hibernate, TopLink, JDBC)
Performance	Fast for single objects	Better for large datasets (indexed queries)
EJB Entity Beans	Not used	Used (JDBC for BMP, container for CMP)

How It Works

Serialization approach:

// Save
ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("account.dat"));
oos.writeObject(bankAccount);
// Load
ObjectInputStream ois = new ObjectInputStream(new FileInputStream("account.dat"));
BankAccount account = (BankAccount) ois.readObject();

ORM approach:

// Save (BMP style with JDBC)
PreparedStatement ps = conn.prepareStatement("INSERT INTO accounts (id, owner, balance) VALUES (?, ?, ?)");
ps.setString(1, account.getAccountID());
ps.setString(2, account.getOwnerName());
ps.setDouble(3, account.getBalance());
ps.executeUpdate();

Visual Explanation

Key Properties

ORM is superior for business data: Queryability and debuggability win for enterprise apps
Serialization still useful: For caching, session replication in clusters, simple use cases
Entity beans mandate ORM: The EJB spec envisions ORM (not serialization) for entity beans
Modern ORM tools: Hibernate (most popular), TopLink, JDO—reduce manual JDBC code

Connections

Built from: Persistence Concepts, Object-Relational Mapping
Builds into: Entity Bean (uses ORM, not serialization)
Related: JDBC (API for ORM in BMP), BMP
Contrasts with: Direct database access (no objects—just SQL)

Edge Cases & Gotchas

Serialization version UID: If you change the class, deserialization fails without serialVersionUID
ORM impedance mismatch: Object model ≠ relational model (inheritance, collections are hard to map)
EJB 3.x uses JPA: Java Persistence API—modern evolution of EJB entity beans + ORM

servlets

2026-04-29T00:00:00.000Z

The Problem

Web servers need to dynamically generate responses (HTML, JSON) based on client requests. Static HTML files aren’t enough. How do we extend web server functionality to handle dynamic requests?

Core Idea

Servlets are networked components that extend web server functionality. They are request/response-oriented: take HTTP requests from clients (browsers), process them, and issue responses back. Ideal for web tasks like rendering HTML interfaces.

How It Works

HTTP request: Browser sends request to web server
Servlet container: Web server delegates to servlet (e.g., Tomcat)
Lifecycle: Container loads servlet class → calls init() (once) → service() (per request) → destroy() (once)
Service method: doGet(), doPost(), doPut(), doDelete() handle the request
Filters: Intercept requests before they reach the servlet for logging, authentication, compression
Response generation: Servlet writes HTML/JSON to response
EJB integration: Servlets can look up and call EJB components

Servlets differ from EJBs: no declarative transactions, simpler management by container.

Visual Explanation

Key Properties

Request/response: Handles HTTP requests and generates responses
Web tier: Part of presentation layer in J2EE
Lifecycle: init() (once) → service() (per request) → destroy() (once)
Session management: HttpSession API for maintaining user state across requests
Filters: Servlet Filters for cross-cutting concerns (logging, auth, compression)
No EJB features: Lacks declarative transactions, sophisticated container management
Simpler: Better for simple request/response needs
Compiled to: JSP scripts compile into servlets
J2EE standard: Part of J2EE platform

Connections

Built from: Java Platforms — Servlets are part of J2EE
Related: JSP — JSP compiles to servlets
Builds into: EJB Container — servlets can call EJBs
Related: JSP — JSP is alternative presentation technology
Contrasts with: Session Bean — servlets handle web, EJBs handle business logic

Edge Cases & Gotchas

Thread safety: Servlets are shared across requests, must be thread-safe — avoid instance variables
No transactions: Use EJB if you need declarative transactions
Session management: Servlets can use HTTP sessions but EJBs shouldn’t
Filter ordering: Filter execution order follows web.xml declaration order
async supported: Servlet 3.0+ supports async processing for long-lived connections

session-bean-lifetime

2026-04-29T00:00:00.000Z

The Problem

How long does a session bean live? Is it days? Years? Can it survive a server crash? Understanding bean lifetime is crucial for deciding what data to store in a session bean vs a database.

Core Idea

Session beans are short-lived, non-persistent objects. Their lifetime is roughly the duration of the client session—when the client disconnects or times out, the container may destroy the bean. Session beans live in RAM and do NOT survive server crashes.

Contrast with Entity Beans which can live for months/years (persistent in database).

How It Works

Client session starts: Client calls create() on home interface → container creates bean
During session: Bean serves the client (could be milliseconds or hours)
Client disconnects: Bean is destroyed (or returned to pool for stateless)
Server crashes: ALL session beans are lost (in-memory only)
Timeout: If client is idle too long, container destroys bean

Visual Explanation

Key Properties

Non-persistent: Session beans are NOT saved to permanent storage
Client-scoped: Lifetime tied to client session (not permanent)
Container-managed: Container decides exactly when to destroy
RAM-only: Live in memory, not on disk

Connections

Built from: Session Bean, EJB Container (manages lifetime)
Builds into: Stateful Session Bean (dedicated lifetime), Stateless Session Bean (pool-based lifetime)
Contrasts with: Entity Bean (persistent, survives crashes, lives for years)
Related: Passivation (stateful beans may be temporarily stored to disk)

Edge Cases & Gotchas

Don’t store critical data in session beans: If server crashes, it’s gone
Stateless beans may be destroyed after EVERY method call: Don’t expect data to persist between calls
Timeout values are configurable: Deployer sets session timeout in vendor-specific config

/wiki / ejb

Ejb — Map of Content

Core Concepts

Mechanisms & How Things Work

Comparisons & Tradeoffs

Suggested Reading Order

rmi-registry

The Problem

Formal Definition

Explanation

How It Works

Visual Explanation

Semantic Network

Key Properties

Real-World Example

Connections

Edge Cases & Gotchas

account-bean-bmp-example

The Problem

Core Idea

How It Works

1. Remote Interface (Account.java)

2. Home Interface (AccountHome.java)

3. Primary Key Class (AccountPK.java)

4. Deployment Descriptor (ejb-jar.xml)

5. Client Code

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

application-vs-system-exceptions

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

atomic-name

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

business-interface-pattern

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

client-think-time

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

component-architecture-soa

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

compound-name

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

count-bean-example

The Problem

1. Remote Interface (`Account.java`)

2. Home Interface (`AccountHome.java`)

3. Primary Key Class (`AccountPK.java`)

4. Deployment Descriptor (`ejb-jar.xml`)