This needs much more work. It needs pointers to explanations of Keykos features. Some of the explanations exist, others do not. It is a good introduction to engineering issues of the order of stacking abstractions. (Forming domains from nodes should not be distributed!)

The following is suitable for applications that are distributed for purposes of latency toleration or access to specialized computational facilities. It does not describe how applications that subscribe to servers, but does not preclude that. Here is a similar note.


Here is a scenario of how an application distributes itself. It is an application requirement to be distributed and some application code is aware of distribution requirements.

In this plan distribution savvy application code arranges the distribution before the application begins to run. The application is divided hierarchically into several parts. As the higher parts are instantiated the lower parts are called upon to instantiate themselves. Some of these parts are distribution savvy. For such parts, the distributor (a portion of the instantiation code), will come to hold capabilities to resources at remote sites, perhaps thru market mechanisms. The special case of Keykos may be instructive. If the distributor holds a key to a remote space bank and invokes a local factory requesting a new object, passing a key to the remote bank and expecting to get a key to a resulting remote object, the call will fail for the bank key will not be recognized as a valid bank key. This is good because there was a contract between the factory and builder that the builder’s code would not be allowed outside the factory’s site. If we modify the factory and the factory contract then we may get beyond the test of the bank key. The next problem is when the factory invokes a domain creator that is similarly modified to accept the remote bank key. The domain creator proceeds apace until it invokes the domain tool passing a key to a remote node. The domain tool is not fooled. It requires a real node key. Virtualizing the domain tool does not seem promising.

More promising is for the distributor to contact a factory at the remote site. If there is a conventional collection of services available at the conventional sites then there should be a conventional directory of keys to factories at each site. If the factory’s service is not too specialized then there should be a like factory at the remote site. The distributor can reasonably access this directory. It may be important to note that a sensory key to a directory of sensory things is sensory. With this setup the distributor can easily create objects at remote sites and acquire the remote keys to them. Those objects need not be aware of the distribution.

The factory builder is able to build factories at remote sites nearly as easily as at his own site. He must, of course assess the ability of that site to protect his code. If the factory has requester’s keys as components then this pattern repeats recursively until the necessary infrastructure is present at the remote site.

The above considerations ignore the Java Applet style of distribution. This is an important case that I will discuss later.