Note: Also see Local Home Interface for same-JVM version, and Why Bean Doesn't Implement Component Interface for design rationale.
What methods can a client actually call on an Enterprise Bean? The client needs to know the available business operations without having access to the implementation (bean class). The interface should be separate from implementation for loose coupling.
The Remote Interface defines the business methods that clients can invoke on an Enterprise Bean. It declares WHAT the bean does, not HOW it does it. The container implements this interface and the client uses it to call bean methods.
- Bean provider defines the Remote Interface (extends EJBObject in EJB 2.x)
- Container implements the interface and creates an EJB Object
- Client obtains reference to Remote Interface via Home Interface or dependency injection
- Client calls methods on Remote Interface
- Calls are forwarded through EJB Object to actual bean implementation
- All remote communication is handled transparently
- Declares business methods: What operations the bean exposes
- Extends EJBObject: Inherits infrastructure like remove(), getPrimaryKey()
- One-per-bean-type: Each bean type has its own Remote Interface
- Local variant: Local interface for same JVM calls (optimization)
- In EJB 3.x: Annotations replace many interface requirements
- Method signatures only: No implementation logic here
- Built from: EJB Object — container implements Remote on behalf of bean
- Builds into: Session Bean — Remote interface defines session bean methods
- Builds into: Entity Bean — Remote interface defines entity bean methods
- Related: Home Interface — Home creates, Remote executes
- Related: Local Interface — same JVM variant
- All methods in Remote Interface must throw RemoteException (checked)
- In local calls, Remote Interface overhead can be avoided by using Local Interface
- EJB 3.x uses POJOs with annotations — explicit interfaces less required
- The interface should only declare business methods, not lifecycle methods