An object request broker manages interactions between distributed objects. It knows about the objects that are requesting services and handles object communications. The communicating objects do not need to know the location of other objects nor do they need to know anything about their implementation. As the IDL interface insulates the objects from the ORB, it is possible to change the object implementation in a completely transparent way. The object location can change between invocations and this is transparent to other objects in the system.
This is illustrated in Figure 1 that illustrates how two objects o1 and o2 may communicate through an ORB. The calling object (o1) has an associated IDL stub that defines the interface of the object that is providing the required service. The implementer of o1 embeds calls to this stub in their object implementation when a service is required. The IDL is a superset of C++ so it is very easy to access this stub if you are programming in C++ and fairly easy in C or Java. Language mappings to IDL have also been defined for other languages such as Ada and COBOL.
Figure 1 Object communications through an ORB
The object that is providing the service has an associated IDL skeleton that links the interface to the implementation of the services. Simplistically, when a service is called through the interface, the IDL skeleton translates this into a call to the service in whatever implementation language has been used. When the method or procedure has been executed, the IDL skeleton translates the results into IDL so that it can be accessed by the calling object. Where an object both provides services to other objects and uses services that are provided elsewhere it needs both an IDL skeleton and IDL stubs.
An IDL stub is required for every object that is used.
Object request brokers are not usually implemented as separate processes but are a set of libraries that can be linked with object implementations. Therefore, in a distributed system, each computer that is running distributed objects will have its own object request broker. This will handle all local invocations of objects. However, when a request is made to a service that is to be provided by a remote object than this requires inter-ORB communications.