EJB Internals

What is this EJB, remote, local, and home interface stuff? It's actually quite simple.

The EJB is what you implement and what runs on the J2EE server. It contains the actual code that makes up the brains of the EJB. But you don't have direct access to the EJB: the J2EE container creates, invokes methods, and destroys instances of the EJB as it sees fit.

What you can ask the container for is a home object, which is nothing but an object factory. This factory object can be used to produce objects that have the same "remote interface" as the EJB. The term "remote interface" in this context does not refer to an interface in the strict Java-sense, but to an interface "by convention". It contains the exposed (= public = "business") methods of the EJB, but nothing else that has to to with the EJBs life cycle.

The object obtained by calling create() onthe home object is a "stub". It is being automatically created on the fly[1], mirrors the EJB, but does not contain any business logic whatsoever. All it does is package the arguments of your call and send them over the network. On the other side a "skeleton" is unpacking the arguments, and the actual business method is called on the EJB (the instance created by the J2EE container). Then the whole process is reversed for sending back the return value of the call (or exceptions). The packing/unpacking process is known as marshalling.

Summary: Obtain a home object, and then use this factory object to obtain an object that implements the same "remote interface" as the EJB. Having to deal with a home object is an artifact of J2EE; the object with the remote interface is what you are interested in.

I found the term "home interface" very confusing, because I obtain the home interface on a remote machine, and obivously using the home interface places a call on the server! "Home" refers to the fact that it is part of a mechanism that is "at home" on the J2EE server. This mechanism creates EJB instances "at the home" of the server when I call create(), and returns a stub object I can use to invoke business methods.

Often EJBs will call other beans on the same J2EE server. To save call time, EJBs can be accessed locally. To do that, you obtain a local home object, and use it to produce a local object that mirrors the EJB.

This means you actually have four interfaces:

• (Remote) home interface (to obtain a remote factory object)
• Remote interface (which is implemented "by convention" by the EJB)
• Local home interface (to obtain a local factory object)
• Local interface (which is implemented "by convention" by the EJB)

If your EJB's name is "Foo", then class/interface names are often as follows (according to Sun):

• FooBean for the EJB
• FooHome for the (remote) home interface
• Foo for the remote interface
• LocalFooHome for the local home interface
• LocalFoo for the local interface

FooEJB would be used for the JNDI name of the EJB.

More thoughts and insights

Transactions

Another advantage of not having direct access to the EJB: the container controls calls. Whenever a call is made to a stub, the container intercepts this call and can execute its own code, ie. to perform transaction management. At some point it calls the method on the EJB. When the call returns, the container again can execute its own code, ie. to perform error processing.

This principle is used for processing transactions. I always wondered "how can J2EE undo things done by my code"? It can't! Only operations that manipulated a database (and when the database connection has been obtained from the container) can be undone. If you ie manipulated instance variables, it's back to "do it yourself".

Security

J2EE security works simlilarly. Nobody but the J2EE container can access the EJB. Since all calls go through the container, the container can enforce security by checking the role of the caller against the settings of the EJB. How does it know the role of a caller when the call comes in remotely "from somewhere"?

When configured, the web container enforces user identification via basic, form based, or certificate authentication ...

Authentication can be passed from container to container ...

[#1] This wasn't always like that: in the olden times, you had to use a tool to create the stub and skeleton classes.