next up previous
Next: 3.1.3 Information model Up: 3.1 Management models in Previous: 3.1.1 Organizational model

3.1.2 Communication model

In contrast to existing management architectures, CORBA has no need for a separate management protocol as objects cooperate in invoking each others' methods. The communication infrastructure is the Object Request Broker (ORB) which transmits a client call to a server object regardless of their actual location i.e., from the clients' perspective there is no difference whether the server object resides on the local or on a remote machine. The prerequisite for achieving location transparency is that the ORBs running on different systems are able to interoperate. The corresponding mechanisms have been specified in the second version of CORBA ([2]).

Client calls are accepted by the ORB either through the Client Stubs or the Dynamic Invocation Interface (DII). The flexibility of the DII consists in allowing a client to build its requests in a dynamic way. The implication for management is that no modification has to be applied to the managing system if changes occur at some managed systems.

The CORBA analogon of management operations is the invocation of methods on a remote object. For an acceptable performance, it is necessary that a managing system is able to issue asynchronous requests to a managed system. As asynchronous i.e. non-blocking calls are currently not supported by CORBA, service requests can be either synchronous or use deferred synchronous semantics. The latter is much more suitable for management as, upon submission of the call, the managing system obtains a handle to be used later to inquire about the state of the operation. Asynchronous calls can be simulated by deferred synchronous calls in conjunction with best-effort semantics.


next up previous
Next: 3.1.3 Information model Up: 3.1 Management models in Previous: 3.1.1 Organizational model
Copyright Munich Network Management Team