| Previous | Table of Contents | Next |
Even when it is not required by implementation differences, there are other reasons to partition an environment into different
ORBs.
For security reasons, it may be important to know that it is not generally possible to access objects in one domain from another.
For example, an “internet ORB? may make public information widely available, but a “company ORB? will want to restrict what
information can get out. Even if they used the same ORB implementation, these two ORBs would be separate, so that the company
could allow access to public objects from inside the company without allowing access to private objects from outside. Even
though individual objects should protect themselves, prudent system administrators will want to avoid exposing sensitive objects
to attacks from outside the company.
Supporting multiple ORBs also helps handle the difficult problem of testing and upgrading the object system. It would be unwise
to test new infrastructure without limiting the set of objects that might be damaged by bugs, and it may be impractical to
replace “the ORB? everywhere simultaneously. A new ORB might be tested and deployed in the same environment, interoperating
with the existing ORB until either a complete switch is made or it incrementally displaces the existing one.
Management issues may also motivate partitioning an ORB. Just as networks are subdivided into domains to allow decentralized
control of databases, configurations, resources, management of the state in an ORB (object reference location and translation
information, interface repositories, per-object data) might also be done by creating sub-ORBs.