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
graph semantic__EJB_Client_JAR_ {
layout=neato
node [shape=ellipse fontname="Helvetica" fontsize=11 style=filled]
THIS [label=""Ejb Client Jar"" fillcolor="#ffd700" fontsize=13 style="filled,bold"]
REL1 [label="Related Concept" fillcolor="#f0f0f0"]
REL2 [label="Builds Into" fillcolor="#d4edda"]
THIS -- REL1 [label="related"]
THIS -- REL2 [label="builds into"]
}- 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