DCOM Explained
by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98 |
Previous | Table of Contents | Next |
Directory services and middleware
We have seen that a Directory service is a database used at runtime by network software, system management software, DBMSs, and so on. More particularly, it is the store of information used by middleware to drive the inner workings of the software at runtime.
When security is checked, for example, the middleware should look up the Directory to see if the user is a valid registered user, check the password to ensure the user is authentic, and check the access control lists to ensure that user is entitled/authorized to access the process it has requested. When a client process wants to invoke a method on a component, it will use the component name or interface name, and the middleware will look up its Directory to determine the actual physical location (the machine and possibly file location) of the process requested. Similarly, when a process sends a message to a queue, the middleware will look up the Directory to determine the location of the queue.
The middleware may also use the Directory to store performance data on queue sizes, response times, message frequency, loading on processes, number of threads, and so on. It may access the Directory to find out the information it needs to balance the load between processes on multiple machines.
In essence, the Directory service is a fundamentally important part of the inner workings of middleware. A considerable amount of information needed to handle distributed computing and generated as a result of the actual running of the applications is stored in the Directory.
All middleware needs a Directory of some sort to make it work. So the next fundamental question we might ask is what makes a good Directory?
What makes a good Directory service?
A Directory service should be reliable, provide high availability, and provide extremely good performance if it is to give the sort of support needed to run a distributed application. But how do you build reliability, availability, and good performance into the design of a Directory service? The easiest way to show what makes a good Directory service is to describe some of the solutions used in middleware products and highlight their advantages and disadvantages.
The single file approach-Directory services of many of the CORBA products and some RPC products are based on a design where the Directory is stored on a single node. The file is not replicated or partitioned in any way. The administrator simply sets up the single file of data on that machine and then provides a configuration file on all the other machines that give the location of the Directory for use by the middleware.
Whenever a service is requested or process invoked, the middleware first looks up the local configuration file and then, using this, makes a call across the network to the Directory service to get the information it needs. The Directory itself is usually stored on disk. Only rarely is it copied into memory at system startup.
The advantages of this approach are that the administrator has only one file to create, along with the configuration files, so administrative overheads are quite low. It is also easier to restrict access to the file, thus ensuring only the administrator can change the information in it or look at its contents. The disadvantages, however are quite extensive.
First, a single file on a single node means that there is a single point of failure. If the node itself goes down, the file the Directory is stored on fails, or any of the lines to that node fail, the entire application fails.
Second, performance even of modest-sized applications and for any large applications could be severely affected, as every request from a client for a service requires the middleware to access the file across the network, incurring both the overheads of network communication and the additional overhead that results from shared access from multiple nodes and processes to the one Directory resource. Where the Directory is on disk, rather than in memory, further performance degradation may occur. Thus the single file approach does not provide a reliable, available, or high performance solution to the Directory service requirements.
Previous | Table of Contents | Next |