It is an excellent exercise to contemplate the results of concurrent distribution services. Suppose that two programmers, each with the ability to add new code (object types) to the system and acquire external communication function, decide to implement this type of communications. Further assume that these two do not know about each other. We will assume that these two services are isomorphic as that will illustrate all of our points.

There are two interesting cases:

Assume first that services A and B both connect sites x and y. An object reference may be carried in messages from x to y via A and thence back from y to x via B. At this point invocation of the repatriated reference will cause a signal from x to y via B and then a signal from y to x via A. This works but slowly. If there is an EQ capability that is uncoordinated with either A or B then EQ will declare the original reference unequal to the returned reference. Is this a violation of the EQ axioms?

This question forces us to be more careful. We must inquire about bootstrap procedures; perhaps the above test cannot be carried out. We have described the general state of a distribution service but how does the first remote capability and its forwarder come about.

Implementations of CORBA that I have seen (VisiBroker and RMI by Sun) both use registries which provide a global ascii name space. The respective literatures would lead one to think that all remote references arise by invoking the registry. But this name space is unprotected. Perhaps it is feasible for each registered objects to be sufficiently suspicious of messages while access to other remote objects can be limited by capability discipline.

The standard registry is aware of multiple sources and thus tends to find local providers. For efficiency an itinerant service should rely on local sub-contractors. On the other hand it is responsible for its own integrity. These goals are in partial conflict. I think that this difficult problem is outside the scope of pure distribution theory. A pure form of the dilemma is the space resource capability. In Keykos this is the SpaceBank. Few other systems disseminate the authority to use space by capabilities. If a space resource capability is transmitted over a link then the invocation of such a capability returns space that is probably at the wrong end of the link. In Keykos, trying to use a page in the wrong city is theoretically possible but almost never feasible. Space and time resources must almost always be local. Code that distinguishes such resources must be aware of distribution. Indeed this is a segue into distribution management.

Suppose that our two distribution entrepreneurs seeded their links so that there was no closed loop. It is easy to see that no loop could arise and thus the EQ dilemma above could not arise. We must be careful about initial conditions. More on this subject later and elsewhere. (It turns out that there can be a one site version of the EQ dilemma. Some programmer has two accounts on the same capability system. He does not know that it is the same system. He builds his distributor for his own purposes. He will never learn that the two publicly available capabilities are indeed the same. His code will run correctly even though it can be argued that EQ is misbehaving. Perhaps our axioms are wrong.)

We proceed to the three site case. The EQ problem cannot arise for there are no loops. Messages from site x to site z go thru two forwarders. If there are good communications between sites x and z then we will want to extend our protocols to the multi site scheme.