| DCOM Explained by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98

Previous | Table of Contents | Next

Replication with “publish/subscribe”-The solution to the above problems is achieved using the concept of a “publish and subscribe” Directory service.

The Directory is similar in principle to the replicated file but with some important differences. A single database of information is replicated across all nodes. This database contains all the information needed by all the applications being run using the middleware. But no single file is the master. Instead, each process registers all its resources—queues, methods, components, and so on—with the local Directory service. The Directory service on that node then replicates the information to all the other nodes.

By using this self-registering approach, coupled with replication, the Directory service is highly available (no single point of failure), reliable (the data is bound to be up-to-date), and the design provides excellent performance (all access can be from the node). Furthermore, it requires no administrative effort—saving time and reducing if not eliminating errors.

One additional advantage with this design of Directory service is that since all the processes must be running permanently in memory, and the Directory service knows the information it has is always up-to-date (that is, the server processes have registered themselves so the details of where they are is correct) the Directory service itself can monitor the processes to ensure they are still running and if any fail, restart them automatically. Thus this form of Directory service helps in automatic fault handling.

The directory is stored in memory on each machine. If a machine fails and is then restored or booted up, the directory “self-configures.”

Because the Directory information is memory based, however, it suffers from the same limitations as those we saw for the simple replicated Directory—small machines may have difficulty holding the data on very large configurations in memory, requiring a compromise solution. Thus, although performance is potentially excellent, smaller client machines may suffer from slightly reduced performance because of the need to access another node to get Directory data. The use of “proxy Directory” services, as they are known, however, need not affect availability or reliability, which will continue to be excellent.

Another small disadvantage with this approach is that the developer may have to add code to his program to register the process and its resources. On the whole, this is a minor irritation to the developer rather than a major problem as he or she may have to write perhaps a single line of code to perform the registration. In the better products even this is not needed; the middleware performs the registration for the developer.

It should also be recognized that some of the information in the Directory—users, groups, access control lists, and so on—will still need to be set up manually by the administrator. This aspect of administration is not removed.

Another disadvantage with this approach is that it cannot be used with triggering. Why do I say this? In order for the processes to register themselves with the Directory service, they must be loaded into memory and be running permanently in memory. Where triggering is used, the processes are stored in files or libraries on disk and only loaded when they are needed. As such, they cannot register themselves as they are not executing processes.

This point is a rather interesting one as, generally speaking, the replicated/ publish/ subscribe type of Directory service is provided with heavy-duty enterprise-oriented products such as DCE and the DTPMs (Distributed Transaction Processing Monitors) like TOP END and Tuxedo. Enterprise-oriented middleware is geared towards high performance, availability, and reliability as key design goals of the entire product, and the concept of triggering is simply not one which is compatible with the idea of high performance applications. To trigger a process, the process has to be loaded. This degrades performance significantly, and the whole aim of transaction processing systems is that they should be high performance.

Thus, a publish/subscribe Directory service may provide a highly available, reliable, and high-performance Directory service, but the developer must remember that all the processes he needs must be permanently running in memory for the Directory to work. It also means that the nodes that store the components must have enough memory to be able to support permanently running server processes.

Previous | Table of Contents | Next