Enumeration and association traversal operations return a CloseableIterator. Make sure that this iterator gets always closed. In current implementations the iterator is closed automatically when you iterate behind the last element. However there's no guaranteee whatsoever that this behaviour is kept for future releases. Moreover you have to ensure that the iterator is closed when you stop iterating before the end is reached either normally or caused by an exception.
If you fail to close the iterator we will leak a network socket.
final CloseableIterator iterator = client.enumerateInstanceNames(new CIMObjectPath( "CIM_RegisteredProfile", "root/cimv2")); try { while (iterator.hasNext()) { final CIMObjectPath path = (CIMObjectPath) iterator.next(); System.out.println(path.toString(); } } finally { iterator.close(); }
The WBEMClient class is designed for thread-safety. It contains a HTTP client pool that allows to reuse network connections used for previous operations. You are able to set configuration properties that apply to the current thread only.
Bottom line: We did a lot of work to ensure that sharing a WBEMClient between threads is safe and convenient to use. Therefore create just one WBEMClient per CIMOM and share it. I don't know a compelling reason for having a pool of multiple clients per CIMOM. This is a pattern used with other client libraries that had not been thread-safe.
The SBLIM CIM Client for Java offers three different XML parsers: DOM, SAX and PULL. All three produce identical results out of a CIM-XML response. What is different is the way the are producing these results.
The DOM parser produces a DOM structure out of the CIM-XML. This is quite convenient to debug, but consumes by far the most memory and is also the slowest approach.
The SAX parser creates Java CIM objects (javax.cim.*) directly without building a DOM structure first. That saves memory and is much faster. The SAX parser is also the default parser.
The PULL parser is based on the SAX code. But instead of parsing the whole CIM-XML response in one step, it does just parse as much XML as needed to create the next JAVA CIM object. With every call to Iterator.next() by the application another chunk of the response is parsed.
The SBLIM CIM Client for Java throttles the HTTP stream so that the CIMOM does not send us parts of the response we do not need yet. This throttling has caused problem with a view CIMOMs in the past and because of this we did not choose the PULL parser as default. However the PULL parser has the least memory consumption and what's more important the memory footprint is independent of the size of the response. It is overall a bit slower than the SAX parser, but return the first object much faster.
Bottom line: When you are dealing with large numbers of objects and you CIMOM works with the PULL parser ... choose the PULL parser. For all other case SAX is the first choice. DOM shouldn't be used in a production environment.
The SBLIM CIM Client for Java can produce a lot of trace data. That's nice during your application development or when you have to analyze a problem at customer site. It's wasting performance and capacity if tracing runs in healthy production system.
Traces are much bigger than logs. This data has to be written, that comes at a cost of performance. The trace code analyses the stack trace on every message that is written. That eats up performance too.
Bottom line: Tracing is convenient for problem determination, but nothing suitable for a healthy production environment. So do not ship your product with tracing configured by default.
The SBLIM CIM Client for Java has a good number of configuration options. Probably you can live with the defaults we have chosen in most of the times. But have look first. There are some option you cannot find a good default for. E.g. the HTTP timeout. We've chosen zero as default which means that we will never timeout while waiting on a CIMOM response. That might not be what you want.
The SBLIM CIM Client for Java supports the local authentication mechanism of OpenPegasus. In order to use it you have to set a configuration property:
... final Subject subject = new Subject(); subject.getPrincipals().add(new UserPrincipal("root")); WBEMClientSBLIM client = (WBEMClientSBLIM) WBEMClientFactory.getClient("CIM-XML"); client.setProperty(WBEMConfigurationProperties.HTTP_AUTHENTICATION_MODULE, PegasusLocalAuthInfo.class.getName()); client.initialize(path, subject, new Locale[] { Locale.US }); ...
With this property you specify the authentication module to be used. We ship two modules:
org.sblim.cimclient.internal.http.WwwAuthInfo
: Usual basic and digest HTTP authentication. User & password
or certificate required.org.sblim.cimclient.internal.http.PegasusLocalAuthInfo
: OpenPegasus local authentication. Only username required.You might also create you own module by subclassing org.sblim.cimclient.internal.http.AuthInfo
. Keep in mind this is
"internal" API, so it might be subject to change.
An object path has the general form of [scheme:host:port//]namespace:[classname[.key=value]*]
. We distinguish 3 types of object paths:
So far, so good. The scheme:host:port
part is optional, so you may not rely on it. Therefore the SBLIM CIM Client for Java ignores the host information
when calling CIMObjectPath.equals()
.
Unfortunately the CIM-XML protocol specification defines quite strange behaviour regarding object paths. E.g. an instance retrieved via EnumerateInstances contains one, but retrieved via GetInstance contains none at all. The SBLIM CIM Client hides this as best as possible from the application. Therefore you can expect a full object path any time, but the host information is still optional. See the table below:
SBLIM CIM Client for Java | CIM-XML | |||||
---|---|---|---|---|---|---|
Operation | host | namespace | clasname/keys | host | namespace | clasname/keys |
EnumerateClassNames | no | yes | yes | no | no | yes |
EnumerateClasses | no | yes | yes | no | no | yes |
GetClass | no | yes | yes | no | no | yes |
EnumerateInstanceNames | no | yes | yes | no | no | yes |
EnumerateInstances | no | yes | yes | no | no | yes |
GetInstance | no | yes | yes | no | no | no |
AssociatorNames | maybe | yes | yes | maybe | maybe | yes |
Associators | yes | yes | yes | yes | yes | yes |
ReferenceNames | maybe | yes | yes | maybe | maybe | yes |
References | yes | yes | yes | yes | yes | yes |