INTRO:sfcc - Small Footprint CIM Client Library
INTRO:sfcc - Small Footprint CIM Client Library
The small footprint CIM client library is a C API allowing client applications
to interface with CIM implementations (e.g. CIM servers). Due to it's small
memory and disk footprint it is well-suited for embedded environments.
SFCC provides a generic layer to load the underlying libraries to communicate to the
CIM server via 2 methods:
1- http interface
2- local connect interface
SFCC provides the libraries for cimxml via http and SFCB provides a library
which is loaded by SFCC to provide local connect.
When using the http interface the CIM server can physically be located on the same
system as SFCC or a remote system and communication is over the http protocol.
When using the local connect interface the CIM server must be SFCB and physically
located on the same system as SFCC and is provided via SFCB and SFCC libraries.
Communication is accomplished via localconnect sockets. Note that the local connect
will use a library that is part of sfcb so the application must have the same
authorization as the installer of sfcb.
If the sfcb libraries have not been installed to the default location
(<libdir>/sfcb), SFCC will need to be configured to find them. Use
"configure SFCB_LIBDIR=<dir>" to inform the SFCC build where to find the
Applications using SFCC determine which method to use by calling the NewCIMCEnv
library function which establishes the environment for using one of the above
The initial version of sfcc is based on concepts of the Common Manageability
Programming Interface (CMPI) defined by the Open Group. A client program
using version 1 of sfcc usually needs to include the following headers or
a subset thereof and link against libcmpisfcc.so:
The current version of sfcc has undergone some structural changes in order
to support different backend implementations, like local communication to
a CIM server or even direct provider calls.
For this purpose a three-layer architecture has been chosen, consisting of
a frontend layer, the core CIM C API and a backend layer.
The core CIM C API which in fact is also an application binary interface (ABI)
just offers two functions: NewCIMCEnv and ReleaseCIMCEnv.
These are used to establish or to remove a CIM client environment which can
be used to connect to a CIM server and perform CIM operations against
A CIM client environment needs to be implemented by a backend which is a
shared library offering a defined entry point with a name like
which is used to return a pointer to a CIMCEnv structure containing a function
pointer table exposing the services supported by the backend. This is very
similar to the way a CMPI provider is implemented.
Currently sfcc ships with a CIM XML backend which should be the most common
protocol for CIM-based client-server communication. The sfcb CIM server also
ships with a local connect backend. The effort to write a backend for a CIM server
is roughly comparable to the effort of writing a CMPI provider adapter/manager.
While it's possible to write programs directly against the core CIM C API,
it's likely that this will not be appropriate for everybody. Therefore
it's possible to add frontend APIs (aka language bindings) on top of the
core CIM C API. Currently there's one frontend in sfcc v2: the v1
There's a number of reasons why the original sfcc API is not well suited to
serve as the core CIM C API.
Most problematic is that the object creation functions are not implemented
via function pointer tables but with fixed entry points which would
add overhead and complication for backend implementations.
The core CIM C API groups these functions in the CIMCEnv function pointer
Another, more cosmetic issue, is that the original sfcc implementation
in fact uses modified CMPI headers which disallows to mix provider and
client code in the same executable. The new core CIM C API headers have
their own declarations prefixed with CIMC (instead of CMPI or CMCI).
Compatibility with version 1 is ensured via a frontend implementation.
This allows old applications to take advantage of new backends without
the need to rewrite them.
There are however some restrictions to keep in mind:
A. Removed Functions
Some functions have been removed from the set of public functions, as they
are considered internal stuff, which shouldn't be of concern to clients.
As consequence of this it was necessary to re-version the library which
will require a re-linking of your application.
B. Feature Freeze
The version 1 sfcc API is frozen: new features won't be backported.
The proper way to select the backend is via the NewCIMCEnv call. The first
argument is used to construct the backend library name and the entry point.
example 1 - sets up the CIM XML environment.
CIMCEnv ce = NewCIMCEnv("XML",0,&rc,&msg);
will load the shared library libcimcClientXML.so, locate the
function _Create_XML_Env and call it to establish the environment.
example 2 - sets up the local connect environment.
CIMCEnv ce = NewCIMCEnv("SfcbLocal",0,&rc,&msg);
will load the shared library libcimcClientLocal.so, locate the
function _Create_SfcbLocal_Env and call it to establish the environment.
This also implies that any future library that implements the functions
specified in the cimc layer could also be loaded by specifying "XXX" to
load the libcimcClientXXX.so library.
If you checkout from CVS run autoconfiscate.sh to prepare for building.
# make install
These make the test cases under TEST as well.
# configure CPPFLAGS='-DDEBUG'
Builds a version of the library with debug output enabled.
Note that to pass the tests it is necessary to install the following
provider packages from the SBLIM project
- sblim-cmpi-base (available in tar.bz2 format)
- cmpi-tests (currently available
Necessary for initialization:
NewCIMCEnv - sets up the environment to use for communication to the CIM server.
usage for local connect
ce = NewCIMCEnv("SfcbLocal",0,&rc,&msg);
usage for http connect
ce = NewCIMCEnv("XML",0,&rc,&msg);
connect - establishes the connection to the CIM server
CIM Request functions:
Since the enumeration functions can result in an array of responses there
are 2 functions to control getting the responses.
enumeration special functions
The hasNext function will return a boolean value
0 - no more responses
1 - more responses available
The getNext function will return the next response for the enumeration.
The release function is used to release resources associated with the specific