• ↑↓ pour naviguer
  • pour ouvrir
  • pour sélectionner
  • ⌘ ⌥ ↵ pour ouvrir dans un panneau
  • ←→ pour naviguer
  • esc pour rejeter
⌘ '
raccourcis clavier

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

BusinessInterface BI Business Interface (pure, no EJB) + hello() RI Remote Interface extends EJBObject, Business Interface BI->RI LI Local Interface extends EJBLocalObject, Business Interface BI->LI Bean HelloBean implements SessionBean, Business Interface BI->Bean

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

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)