About how: Should the factory be a Singleton? Is it ok to instead of a Singleton have a method startServer() that is called once at the beginning of a program and binds a factory to the registry?
About why: Say a client would like to get a connection to a remote data object. Why should we not bind that data object instead of a factory to the register?
Can you tell me whether this right: If an object is bound in the registry, it stays alive the whole lifetime of the server (and uses memory). Therefore, a singleton factory is useful: only one object, which can create several remote references to a data object, will be bound to the registry and the data objects in the server will be collected by the garbage collector when they become unused.
The point of using the Factory design pattern in RMI isn't that the factory is a singleton, it's that the client can receive multiple types from the factory, but only has to know about the interface that the classes implement. Your last point is correct... instead of running 5 servers for 5 different types of classes that implement the same interface, but are bound under different names, you could just bind one factory into the registry and return the implementation that the client needs. And yes, those objects would be garbage collected when no longer used rather than sitting in memory all the time waiting for connections.
Write once, run anywhere, because there's nowhere to hide! - /. A.C.
Joined: Jul 28, 2004
Nathan, thanks for your answer.
I know that the point of the factory design pattern usually is to return a different implementation depending on client needs, but with RMI this does not seem the most important point. Doesn't usually the RMI factory return a connection which is always the same type?
I think, with RMI, the main use of a factory is to bind only one object to the registry.