Who writes the class that really DOES implement the component interface? In other words, who makes the EJBObject class?

The container. You declare the methods, but the container implements your component interface. Remember, your component interface is the one that extends EJBObject, so the container has to implement not just your business methods, but also the methods of EJBObject (which we haven’t yet looked at).

Q:

Q: But how does the container know what to put in those methods? I’m the one who declared those methods...

A:

A: Remember, the container isn’t implementing the real business logic. The true functionality for those business methods lives in your bean class—the class that you implement. The class implementing the component interface is going to be the EJBObject. The bodyguard. The Remote object. And remember that the EJBObject is only pretending to be the bean. It can respond to the remote method calls coming from the client (via the stub), but the EJBObject’s only job is to capture the incoming client calls to the bean. After that, it’s up to the container/server to take over.

We don’t really know how the EJBObject is implemented—it’s completely up to the vendor. But we don’t really care. All you need to know is that an EJB container is required by the spec to generate the code for the EJBObject (and its corresponding stub).

Get Head First EJB now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.