Before talking about clients and their architectures and implementations , it is important to be clear that WBEM clients are not user interfaces. As we have seen before, the chain of components is as follows :
The WBEM client represents the operator in negotiations with the WBEM server; it converts the operator's requests into CIM-XML from whatever language is natural for the operator and it translates the WBEM server's response back. It is not responsible for producing drop-down menus on an operator's workstation, rendering HTML onto a screen, or parsing the text of a command line interface; that is the function of the operator interface software. Of course, the operator interface and WBEM client may be (and often are) implemented in the same piece of code.
We can therefore expect a WBEM client to be a sort of Janus with a relatively simple and stable interface towards the WBEM server and a much more complex and variable interface towards the operator. It is therefore impossible to discuss the WBEM client in isolation ”most of its functionality deals with operator interfaces rather than WBEM. I will therefore spend some time in this chapter looking at possible WBEM client implementations for different types of operator interface.
One important architectural characteristic to remember when designing a WBEM client (or, indeed a provider) is that the client should not know about the providers with which it indirectly interacts ”the WBEM server acts as a broker between the two and no knowledge of a particular provider structure should ever be built into a WBEM client.