The Distributed Database System

 

Argument list for all messages passed

For this design of the DDS, in all request messages, the method name is added as the first argument as a string with the name of the method to be invoked. The second argument is always the count of the number of arguments for this method. (the provided methodID in the request message is not used).

If the argument to be added is a real object on the sending node (eg. a table object, a Cell object, etc), then through java reflection, the type of the object is determined, and then a ServerProxy object for that real object is created, along with a new capability for the object. This new capability is then added to the message.

The Response message also includes an IPC Header. The RPC header for the response message has only a ResponseType field, along with the returned result arguments (out args). The Response Type field indicates a valid response or an error message from the sending computer. For this implementation, the ClassID and ClassVersion Number were originally added to the ResponseMessage also. Later in the development, it was determined that they were no longer needed, as this information was added to the capability, but it was not taken out.

On the NameServer, NameContext objects are used to store class names and ComHandles of remote machines containing the classes (used for class based RPC), and capabilities for server side objects on remote machines. Each NameContext has a unique name within its own NameContext, along with a hashtable containing a mapping of class names to ComHandles, and object names to object capabilities. For this design, the NameServer contains a root name context, under which all other machines register a name context for themselves. Every node that allows public access to its classes and objects, registers a NameContext object under the NameServer's root name context, including the NameServer itself. So, for this design, there will be three NameContexts under the root name context: one for the client (which allows access to it's cell and table objects), one for the NameServer (which allows access to its NameContext objects), and one for the DBServer (which allows access to its database and other objects).

Other important data structures used included four different hashtables. The Server contains the hashtables ObjectRegistry, ClassRegistry, and serverCapability registry. The RPC.Client contains a client capability registry hashtable.

The Object Registry contains a mapping of real server side objects to ServerProxy objects. The ClassRegistry contains a mapping of ClassID and Version numbers to class names. The server capability registry contains a mapping of capabilities to ServerProxy objects. On the Client side, the client capability registry contains a mapping of Client capabilities to Client Proxy objects.

 

 

[PhilipHenderson.com Home][Portfolio index][Distributed Database Main Page]