Visual Basic 4 gave us the ability to distribute parts of an application, and Microsoft recommended using a pool manager to maintain pools of precreated objects that could be given out in response to client requests for service more or less instantaneously on demand. With Visual Basic 5, the requirement for some kind of infrastructure layer in a distributed system still remains.
The pool management idea is that a client application or component asks a pool manager for a reference to an object it wants to use. (See Figure 2-13 on page 64.) The pool manager checks its resource pool and either grants or denies the request. As we have seen, MultiUse instanced servers have blocking problems with a pool manager, so the natural choice is to create SingleUse instanced server object classes. The issue with this approach is that without a pool manager there is nothing to steward resources on the business object server machine; but the pool manager can be designed to do this.
Figure 2-13 A pool management model for tiered development
Note For simplicity, I haven’t shown the pool manager being used by one business object to get references to another business object or a data access object. I don’t mean to imply this shouldn’t happen—in fact, doing this is what distinguishes tiering from layering, as mentioned earlier.