Goals in pool management design

A pool manager needs to be created in an extensible way to allow for the future deployment and management of a number of different kinds of servers, some not yet designed. It needs to be able to manage each type of server explicitly, rather than as a homogenous mass of instances whose specific type it doesn’t know. A pool manager also needs to be designed to allow for extending and modifying any management algorithms as needed to cope with peaks of demand, changes in usage patterns, and so on. A useful addition is to make your pool manager capable of remote management through an ActiveX interface since invariably the business object server machine will be in the least convenient place—often in a locked room and well away from both those who use it and those who need to administer the objects on it.

Objects to be managed A pool manager is an important corporate resource and has to be capable of managing different object server types. For it to do this, you have to make it capable of configuring itself to add new objects and to treat those objects the same regardless of their class. There is a proviso here: the pool manager does need to recognize what type or class it is so that calls for a particular class of object can be handled in the most convenient way. Unfortunately, to treat the instances of different classes or types of object as generically as possible, you have to break one of the unwritten laws of ActiveX object instantiation and sacrifice performance for generic code. So instead of instantiating in your pool manager with the typical:

Private oNewObject as ObscureObjectClass
Set oNewObject = New ObscureObjectClass

you would actually need to use the normally execrable:

Private oNewObject as Object
Set oNewObject = CreateObject(sClassname)

Although the first code example has all the advantages of early binding and we’re even using the New keyword only when we explicitly want to create the object, we must use the second example because we want to add new classes to be managed without changing the references or recompiling the project. We also want to store the class names as text somewhere. (I have used the Windows NT Registry in the past, although the efficacy of this is debatable—but another time, huh?)