Magazine Article

Design for performance, Part 3: Remote interfaces; Learn to avoid performance hazards when designing Java classes

Goetz, Brian

2001

Overview

When you obtain a reference to a remote object through a directory service, you don't receive an actual reference to that object, but rather a reference to a stub object that implements the same interface as the remote object. When you invoke a method on the stub object, the stub has to marshal the method parameters -- convert them into a byte-stream representation, a process similar to serialization. The stub sends the marshaled parameters over the network to a skeleton object, which unmarshals them and invokes the actual remote method you wanted to invoke. Then the method returns a value to the skeleton, the skeleton marshals the return value and ships it to the stub, and the stub unmarshals it and returns the value to the caller. Phew! That's a lot of work for a single method call. Clearly, despite an outward similarity, a remote method invocation is a more expensive operation than a local method invocation. The above description glosses over some important details that are significant for program performance. What happens when a remote method returns not a primitive type, but an object? That depends. If the returned object is a type that supports remote method invocation, then it creates a stub and skeleton object, as is the case when looking up a remote object in the registry. That is clearly an expensive operation. (Remote objects support a form of distributed garbage collection, which involves each of the participating JVMs maintaining a thread for talking to the remote garbage collection thread of other JVMs, and sending reference status information back and forth.) If the returned object doesn't support remote invocation, then all of the object's fields and any objects referenced by the returned object have to be marshaled, which could also be an expensive operation. A third technique for further lightening the load on the RMI layer would be to not make the DirectoryEntry a remote object, but instead define it as an ordinary object with fields or accessors for name, address, email address, and so forth. (In a CORBA system, we would use the analogous object-by-value mechanism.) Then, when the email application calls getEntryByName(), it will retrieve an entry object by value -- which doesn't require the creation of a stub or skeleton, and the invocation of getEmailAddress() will be a local invocation instead of a remote one.

• Publisher: Foundry
• Subject: Goetz, Brian