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?
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.
- Developer creates Client JAR: Bundles interfaces + stubs + helpers
- Declare in XML:
<ejb-client-jar>tag inejb-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
- 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
- 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)
- 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