Frequently Asked Questions


1.

Table 7.1 on page 129, shows no methods for creating, deleting, and otherwise manipulating namespaces. Why?

namespaces are manipulated by using the normal intrinsic methods on the cim_namespace class.

2.

What is the difference between a method such as EnumerateClassNames() and EnumerateClasses()?

the first of these methods, eponymously, returns a list of the names of the classes. the second returns all details of the classes. similarly for enumerateinstancenames() and enumerateinstances()-the former simply returns a list of names, the latter all the gory details of the instance. if a large number of instances is likely to be selected by a call to enumerateinstances(), it may be better to call enumerateinstancenames() and then call getinstance() on each returned name as this will spread the traffic load.

3.

Where can I find additional examples of the XML which is sent between the WBEM client and the WBEM server?

in the appendices of standard dsp0200. examples of the xml requests and responses are given for many of the major operations.

4.

Figure 7.7 shows the XML sent to the WBEM server to create an instance of CIM_IndicationFilter. When I compare it with Figure 7.8 I notice that it does not have KEYBINDINGS. Why?

the entity which is passed to deleteinstance is an instance name (object path). the entity which is passed to createinstance is an instance (and an instance name is returned). this is another manifestation of the name/instance difference discussed in faq 25. when deleting an instance, the wbem server only needs the name (path) of the instance. this name is simply the concatenation of the key properties. when creating an instance, the wbem server needs all of the properties of the instance, not just the keys. it has access to the definition of the class and can therefore deduce which of the properties are keys.

5.

Does the WBEM client/server interface support a transactional model whereby a number of configuration changes can be entered and committed (or abandoned ) together?

no. a presentation on this topic was given by cisco systems at the dmtf 2003 global management conference. the presentation outlined a number of possible approaches, none of which has yet been accepted. it is this lack of transactional support which primarily gives wbem its enterprise rather than carrier flavour. in the high reliability world of the carrier it is not acceptable that every command be entered and executed individually, perhaps placing the system temporarily into an inconsistent state. it must be possible to enter batches of commands, have the anticipated results checked for consistency before they are applied and then have them executed atomically: all the commands or none being executed. similarly, it must be possible for the system to roll back a transaction to remove the effect of a set of commands. the need for a transactional model is recognised throughout the industry: rfc3512, for example, when discussing snmp management contains the paragraph: configuration activity causes one or more state changes in an element. while it often takes an arbitrary number of commands and amount of data to make up configuration change, it is critical that the configuration system treat the overall change operation atomically so that the number of states into which an element transitions is minimized. the goal is for a change request either to be completely executed or not at all. this is called transactional integrity. transactional integrity makes it possible to develop reliable configuration systems that can invoke transactions and keep track of an element's overall state and work in the presence of error states. transactions are already present to some extent within wbem since a service can be modelled in cim. this allows an operator to enter a single command to create an instance of the service. a provider for that service could then execute a number of lower-level commands to provision the individual components of the service. such a provider could also have the knowledge necessary to roll back (i.e., remove) the actions it has already taken if a later action fails. this gives the impression of a transaction-oriented interface to the operator but the responsibility for the transaction lies with each individual provider, with little help from the wbem architecture.

6.

What is the difference between HTTP and HTTPS?

http (hypertext transfer protocol) is a stateless protocol used between a client (making a request) and a server (responding to the request). each exchange consists of a message going from the client to the server and a response message coming back-no state is held at the server between exchanges. this is the protocol which browsers use across the internet to fetch information from servers. https (secure hypertext transfer protocol) is http over secure sockets layer (ssl), which means that the http packets are encrypted before being sent.

Answers

1.

Namespaces are manipulated by using the normal intrinsic methods on the CIM_Namespace class.

2.

The first of these methods, eponymously, returns a list of the names of the classes. The second returns all details of the classes. Similarly for EnumerateInstanceNames() and EnumerateInstances() ”the former simply returns a list of names , the latter all the gory details of the instance.

If a large number of instances is likely to be selected by a call to EnumerateInstances(), it may be better to call EnumerateInstanceNames() and then call GetInstance() on each returned name as this will spread the traffic load.

3.

In the appendices of standard DSP0200. Examples of the XML requests and responses are given for many of the major operations.

4.

The entity which is passed to DeleteInstance is an instance name (object path ). The entity which is passed to CreateInstance is an instance (and an instance name is returned). This is another manifestation of the name/instance difference discussed in FAQ 25.

When deleting an instance, the WBEM server only needs the name (path) of the instance. This name is simply the concatenation of the key properties.

When creating an instance, the WBEM server needs all of the properties of the instance, not just the keys. It has access to the definition of the class and can therefore deduce which of the properties are keys.

5.

No. A presentation on this topic was given by Cisco Systems at the DMTF 2003 Global Management Conference. The presentation outlined a number of possible approaches, none of which has yet been accepted.

It is this lack of transactional support which primarily gives WBEM its enterprise rather than carrier flavour. In the high reliability world of the carrier it is not acceptable that every command be entered and executed individually, perhaps placing the system temporarily into an inconsistent state. It must be possible to enter batches of commands, have the anticipated results checked for consistency before they are applied and then have them executed atomically: all the commands or none being executed. Similarly, it must be possible for the system to roll back a transaction to remove the effect of a set of commands.

The need for a transactional model is recognised throughout the industry: RFC3512, for example, when discussing SNMP management contains the paragraph:

Configuration activity causes one or more state changes in an element. While it often takes an arbitrary number of commands and amount of data to make up configuration change, it is critical that the configuration system treat the overall change operation atomically so that the number of states into which an element transitions is minimized. The goal is for a change request either to be completely executed or not at all. This is called transactional integrity. Transactional integrity makes it possible to develop reliable configuration systems that can invoke transactions and keep track of an element's overall state and work in the presence of error states.

Transactions are already present to some extent within WBEM since a service can be modelled in CIM. This allows an operator to enter a single command to create an instance of the service. A provider for that service could then execute a number of lower-level commands to provision the individual components of the service. Such a provider could also have the knowledge necessary to roll back (i.e., remove) the actions it has already taken if a later action fails. This gives the impression of a transaction-oriented interface to the operator but the responsibility for the transaction lies with each individual provider, with little help from the WBEM architecture.

6.

HTTP (Hypertext Transfer Protocol) is a stateless protocol used between a client (making a request) and a server (responding to the request). Each exchange consists of a message going from the client to the server and a response message coming back ”no state is held at the server between exchanges. This is the protocol which browsers use across the Internet to fetch information from servers.

HTTPS (Secure Hypertext Transfer Protocol) is HTTP over Secure Sockets Layer (SSL), which means that the HTTP packets are encrypted before being sent.




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