| Previous | Table of Contents | Next |
Even in a single computing environment produced by a single vendor, there are reasons why some of the objects an application
might use would be in one ORB, and others in another ORB. Some objects and services are accessed over long distances, with
more global visibility, longer delays, and less reliable communication. Other objects are nearby, are not accessed from elsewhere,
and provide higher quality service. By deciding which ORB to use, an implementor sets expectations for the clients of the
objects.
One ORB might be used to retain links to information that is expected to accumulate over decades, such as library archives.
Another ORB might be used to manage a distributed chess program in which the objects should all be destroyed when the game
is over. Although while it is running, it makes sense for “chess ORB? objects to access the “archives ORB,? we would not expect
the archives to try to keep a reference to the current board position.