Revisiting Our Basic Design

2. The client calls the factory to get a reference to a particular account server. The factory, which is not at all generic, is obligated to return a reference to a server that implements Account . Because it acts as an intermediary for the client, however, it has the opportunity to launch an account server and return a reference to the server that it just launched. 3. The client uses the account server.

17.2.1 Revisiting Our Basic Design

One consequence of our decision to use the Account interface has now become apparent. In order to reduce our applications resource consumption and enable it to scale, we need to write another server: our factory. This second server has nothing to do with the business logic were attempting to implement. Instead, it serves as a sort of remote constructor. This is fairly disturbing. If the factory is difficult to implement, or substantially complicates the implementations of the other components in the system, then maybe we should reconsider going with the bank option. Fortunately, factories are pretty simple pieces of code and can easily be added to our current system. Well implement a basic factory in the next section; the actual factory code is straightforward, the server implementations dont need any changes at all, and using our factory requires relatively few changes to the client. The fact that the factory has no business logic, and looks like a generic solution to a common problem, may seem to im ply that RMI should have facilities for automatically doing this sort of thing. Actually, it does. In JDK 1.2 and beyond, you can use the RMI activation framework instead of implementing your own factory. Well discuss the activation frameworklater in this chapter. Moreover, the additional layer of indirection provided by a factory gives us three fairly substantial benefits: Factories are the ideal places to insert extra querying functionality. To a client program, the factory looks a lot like a naming service: clients query the factory and receive stubs for a server. This means that a factory is an ideal place to put application-specific querying functionality, should the application require it. Factories are very useful for tracking usage patterns logging and debugging. A factory is, by definition, a place that all clients need to visit before they gain access to a server. If you want to track resource usage or client-behavior patterns, the factory is a wonderful place to start. [ 2] [ 2] So is a naming service. There are two distinctions. First, a naming service isnt application -specific and other applications might be using it. Second, factory code is easier to modify its project -specific. Factories enable fine-grained control of the server lifecycle. Right now, our discussion centers around starting and stopping servers. But theres a lot more that a factory can do. In particular, questions about when to make data persistent are easier to resolve when youre using a factory-based architecture. Well return to this topic a little later in the chapter.

17.3 Implementing a Generic Factory