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

Previous | Table of Contents | Next

No Directory-This heading may totally confuse you, but it is worth describing one other solution that has been used to provide the equivalent of a Directory service, but where no Directory—database of information—is ever actually used.

It is a solution provided in the Visigenic VisiBroker product—an ORB based on CORBA but which uses its own unique way of providing Directory services. It is worth pointing out from the start that VisiBroker’s Directory services are entirely geared towards finding objects—they provide none of the facilities for handling security, storing statistics, and so on, so the solution is limited. It is, however, quite a fascinating one.

CORBA does not include within its core specification any description of how objects should be found—in other words, a Directory service. The CORBA Naming service (their Directory service) is an additional COS (CORBA Object Services) component and one which does not have to be provided for an ORB to be deemed CORBA compliant. Consequently, the implementors of the early CORBA specifications could choose to provide any internal service they wanted to enable objects to be found on the network. This gave Visigenic the flexibility to design their own service and they used a technology they had already developed called SMART Agents.

VisiBroker as it stands without the Naming Service does not have a “Directory” or Naming file. Instead, the SMART Agent does all the work of finding objects. There need be only one copy of the Smart Agent on the network, or the administrator may decide to have more than one copy (for fault tolerance and performance reasons).

A server within VisiBroker contains one or more objects. It can be continuously running—that is, loaded up and running on a continual basis—or it can be installed in a library and then triggered when required. Where a server is continuously running and as such loaded into memory as an executing process, the skeleton within the server (libraries provided with the ORB) perform a UDP broadcast to find a Smart Agent. Once the server has found an agent (it could be any agent on the network; it doesn’t matter which one), the server and agent are then aware of each other’s existence. No connection, however, is established as UDP is a connectionless protocol.

The Agent and the server monitor each other using the ping protocol and UDP. If the Smart Agent crashes, the server recognizes that the connection has been broken and performs another UDP broadcast to find another Agent with which to connect. No Directory files or persistent information is kept in memory. If the Agent crashes or is removed, no trace is left that the Agent ever existed on that machine.

Where a server is kept in the library to be triggered, the administrator must set up an Implementation Repository on each machine that provides the names of the Servers on that machine and the file name (path name) of their location in the filing system on disk. A component of VisiBroker called the Object Activation Daemon then monitors the Implementation Repository and acts on behalf of the servers. In this case, the administrator must manually add and remove servers if he or she adds them to a library, removes them from the library, or changes their library name.

Instead of the servers establishing a communication link with the Smart Agent, the Object Activation Daemon establishes the communication. It also performs a UDP broadcast to find a Smart Agent. This time the Agent and the Object Activation Daemon monitor each other using the ping protocol and UDP. If the Smart Agent crashes, the Object Activation Daemon recognizes that the connection has been broken and performs another UDP broadcast to find another Agent with which to connect.

When the client wishes to communicate with a server, it first issues a UDP broadcast to find the nearest Smart Agent. This broadcast need only be issued once in the life of the client; from then on the client and Agent monitor each other using the ping protocol.

If the client wants to invoke an object, it can use the specific name of the object, or it can use a “type” name. Where the type name is used, the Smart Agent will pick an instance of the object on the network.

To find an object, the Smart Agent will examine the communications “links” it has (the pings). If it has established communication with the Object Activation Daemons, it will request the daemons to examine their Implementation Repositories. If the communication is direct with servers, the servers will be examined. Where the Smart Agent cannot find the object, it will perform a UDP broadcast to other Smart Agents requesting that they perform a search.

If the object is found through the Object Activation Daemon, it will load a copy of the server into memory. Once the server has been loaded, or where the server was already loaded, a direct connection is then established between the client and the server. Once the connection between client and server has been established, a direct TCP/IP connection is made rather than one based on UDP.

This solution is quite unique and novel, but it does have its limitations. From the availability viewpoint, the solution has the potential to provide good availability. By duplicating Smart Agents around the network, a Smart Agent should always be available to handle requests.

Reliability should also be good where the processes are not triggered, as the information is always going to be up-to-date. This solution incorporates the concepts of publish and subscribe, but in a different and novel way, and, as such, problems of out-of-date or inconsistent Directory information will not arise. Where triggering is used there is the possibility that errors are introduced, and there is also the additional administrative overhead associated with setting up all the Implementation Repositories.

But where I do see problems is in performance. A tremendous amount of network accesses are needed to find the agents, provide pinging to ensure the agent and servers are still in existence, and provide searches where local agents cannot find the object. It is not just the amount of network traffic that this solution incurs that is the problem, but the fact that most of the Directory type searches have to be made over the network—they are not local searches. So overall, this solution is not geared to high performance, although it is one providing reliability and availability.

In summary-Overall I believe the best solution is the replicated publish and subscribe Directory service, despite the limitations it imposes on triggering. It provides excellent availability and reliability, is geared towards extremely high performance, and incurs only a small overhead in the additional disk space needed to store replicated data. It can be made secure—the administrator can control who has access to the data and even where very large configurations are being used will scale well.

Even the problems caused by the use of memory to store the replicated directory information need not incur any significant overheads with only a possible slight degradation in performance caused by the need to access a proxy server Directory.

Previous | Table of Contents | Next