Architectural Options


In Figure 4.3 I have made the tacit but perhaps typical assumption in allocating components to devices; I have assumed that the client code will not be implemented on the device being managed, but probably in the operators' workstations and the WBEM server and providers will be implemented on the device. Although this is typical, it is not required by the standards ”they are silent on the subject of the distribution of components.

Where the external operator interface is other than WBEM (for example, a command-line interface or SNMP), the WBEM client may need to reside on the managed device, as shown in Figure 3.3.

For other devices it might be impractical to have the WBEM server and repository running on the managed device because of memory or processing constraints. Then it might be necessary to have these running on a management workstation or intermediate computing device with the providers running on the managed device remotely. In this case, the WBEM server could interface with "Provider Proxies," which themselves interact with the real providers over some form of communications infrastructure. Most of the available WBEM server implementations either support the concept of remote providers or have declared the intention of doing so shortly. The emerging standard specification for the interface between the WBEM server and its providers (CMPI) explicitly allows for a remote connection to the providers. If you are using a WBEM server which does not support them, then producing a home-crafted interface using a technology such as an embedded ORB would probably not be too difficult.

These two architectures are illustrated in Figure 4.5, where Architecture A has the conventional distribution with the WBEM server on the managed device and Architecture B illustrates the condition when the managed device cannot contain the WBEM server. Architecture B could potentially lead to significant problems if, as I have heard proposed, the WBEM server was actually implemented on each operator's workstation. Without co-ordination between the different workstations (something that would be difficult to achieve), the alterations made to the structure of the information held in the repository would not propagate to other workstations. If co-ordination were built in between the workstations, then the failure of the "master" workstation could be difficult to handle. Bear in mind that a workstation is normally the least reliable component of the systems illustrated in Figure 4.5. It would also be difficult to co-ordinate the access to the remote providers between the various WBEM servers.

click to expand
Figure 4.5: Different WBEM Server Locations

Even if the WBEM server can be executed on the device being managed, this may be an inappropriate location for a model which defines services across several devices. In this case, a hierarchy of WBEM servers may be more appropriate, with a high-level server containing the model of the interdevice services and communicating with low-level servers that hold device-specific models. This is illustrated in Figure 4.6 where the communication is performed by providers of the high-level model ( B ) acting as WBEM clients to the lower-level WBEM servers ( C ).

click to expand
Figure 4.6: A Hierarchy of WBEM Servers

The ability to use the same abstract model at different levels of management like this is unique to WBEM, being possible neither with SNMP nor TMN. Using a single protocol with commands referring to a common model removes the "integration tax" normally met in a hierarchical management system.




A Practical Approach to WBEM[s]CIM Management
A Practical Approach to WBEM[s]CIM Management
ISBN: 849323061
EAN: N/A
Year: 2006
Pages: 152

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net