Figure 7.2 shows the various layers through which an operator's request passes and through which the response returns when a managed object is accessed.
A command from the operator or higher-level management system originates with the application logic which handles graphical screens, interpretation of command-line interfaces, etc. The command is then mapped to the abstract object model. This is not a trivial activity and I discuss possible approaches in Chapter 13, in particular the section on Semantic Knowledge starting on page 248. Fundamentally, the Object Abstraction layer has to know that, when the operator enters a command to create a new OSPF service, for example, then this means the creation of instances of various CIM classes. This knowledge may be hard-coded, table-driven or driven from the model.
Once the actual CIM commands have been determined, they are encapsulated in CIM-XML and passed to the HTTP client. This is responsible for any negotiation required with the WBEM server and the correct transfer of the request.
Once the request reaches the WBEM server, it is passed from the HTTP server to have the CIM-XML reconstituted into CIM commands. The CIM Object Manager (CIMOM) examines these and determines how they should be handled: by the CIMOM itself, with reference to the schema stored in the repository, or by a provider. If it is passed to the provider, then the provider accesses the real device or service to retrieve the requested information or carry out the requested configuration.
The response from the provider follows the reverse path back to the operator.