Head First EJB

There’s a “helper” on the server as well...

The Remote object has the method the client wants to call. But when the stub makes a network connection to the server, something on the server has to take the information in the incoming stream and turn it into a method call on the Remote object. You could put the networking code into your Remote object, but that defeats the whole point of RMI—to make it as easy for your client to call a method on an object across the network as it is to call a method on an object in the same heap. The goal of RMI is to promote network transparency. In other words, the fact that the objects are in different machines should be nearly transparent to the developer. Which means to you... less code—simpler code.

So, with that as the goal, RMI takes care of the server-side of the method call as well. The thing on the server-side that accepts the socket connection is called a skeleton. It’s the counterpart to the client stub. In the early versions of RMI, for every stub there was a matching skeleton object. Today, though, that’s not always true. The functionality of the skeleton has to happen somehow on the server-side, but an actual skeleton object is optional. We won’t go into any of the details because it doesn’t make any difference to us with EJB. How the container chooses to implement its skeleton behavior is up to the vendor.

All we care about is that something is on the server that the stub knows how to talk to, and that something knows how to interpret ...