In a world full of objects, locating the object that you need to get a job done could be a tough problem. Depending on the application, the need to locate a specific instance of an object in a department or even throughout the enterprise may frequently arise. The need to find all the departments that have events posted for a given month is a good example. We bypassed the problem by creating our own
class. EventsFinder
If the underlying system offers an object location service, however, the problem can be solved easily. Having a global location service will also enable effective pooling of computing resources. In this case, a component based application would consult the location service each time it needs to instantiate a server object to do some work, and the service can pick the component instance which is running on the 'most available' machine or based on certain pre-set criteria.
Part of this problem can be solved today using File Monikers and their
capability (as with URL Monikers that we examined earlier, you can use File Monikers to reunite an object instance with its persistent data, assuming that the data is saved on disk as a file). Another part will be resolved with the introduction of a global 'class store' in future releases of Windows NT. The availability of a global directory service in the future will further unify the location and naming of all network and local resources, providing yet another step in the right direction.BindToObject()
What is still missing, though, is the ability to support the equivalence of a 'global running objects table' across an administrative domain, an intranet, or the entire Internet. The problem is very complex and requires tracking of a very large set of highly dynamic data items. Until a general solution becomes available, each project requiring such a service must reinvent the wheel in an ad hoc manner.