Welcome

Welcome to KonkretCMPI, an open-source tool for rapidly developing CMPI providers in the C programming language. KonkretCMPI makes CMPI provider development easier by generating type-safe concrete CIM interfaces from MOF definitions and by providing default implementations for many of the provider operations. To learn more, read the remainder of this page and see the Documentation page.

Ten reasons to use KonkretCMPI

1. Reduces development effort substantially.
2. Improves type-safety by generating concrete C interfaces from MOF.
3. Provides complete default implementations for many provider operations.
4. Generates initial CMPI provider skeletons from MOF.
5. Requires no additional programming language other than C.
6. Builds on CMPI rather than introducing a new provider interface.
7. Imposes no runtime library dependency.
8. Can be used with existing CMPI providers.
9. Produces providers with a very small footprint.
10. Provides many CMPI convenience functions.

Four ways to use KonkretCMPI

You can use KonkretCMPI incrementally to improve existing CMPI providers or you can use it to write new CMPI providers. There are basically four ways to use KonkretCMPI discussed in the sections below. Whichever way you decide to use it, your provider must include <konkret/konkret.h> and link the static konkret library.

Using the convenience functions

KonkretCMPI provides several convenience functions that make working with CMPI easier. We consider two examples. The first example shows how to print a CMPI instance to standard output.

    CMPIInstance* inst;
    ...
    KPrintInstance(stdout, inst, 0);

This prints all the properties of the CMPI instance. To print object paths, use KPrintObjectPath. The second example shows how to check whether two object paths match.

    CMPIObjectPath* cop1;
    CMPIObjectPath* cop2;
    ...
    if (KMatch(cop1, cop2))
    {
    }

KonkretCMPI provides many other convenience functions as well.

Use the default operation functions

KonkretCMPI provides several default operation functions that implement many of the provider operations for you. These include:

• KDefaultGetInstance
• KDefaultEnumerateInstanceNames
• KDefaultAssociators
• KDefaultAssociatorNames
• KDefaultReferences
• KDefaultReferenceNames

For example, the following implementation of WidgetGetInstance uses KDefaultGetInstance.

    CMPIStatus WidgetGetInstance(
        CMPIInstanceMI* mi,
        const CMPIContext* cc,
        const CMPIResult* result,
        const CMPIObjectPath* cop,
        const char** properties)
    {
        return KDefaultGetInstance(
            _broker, mi, cc, result, cop, properties);
    }

KDefaultGetInstance obtains all Widget instances and finds one that matches. A custom implementation may be more efficient but the default function will often suffice.

Generating class interfaces

KonkretCMPI automatically generates concrete CIM class interfaces from MOF definitions. For example, consider the following MOF class definition.

    class Widget
    {
        string Key;
        string Color;
        uint32 Size;
    };

The command below generates Widget.h which contains a C structure definition of this class and functions for manipulating it.

    $ konkret -m Widget.mof Widget
    Created Widget.h

You can include this header file in your provider and use it to form concrete Widget instances and object paths. The following snippet creates a concrete instance of the Widget class and then converts it to a CMPIInstance and a CMPIObjectPath.

    Widget w;
    CMPIInstance* ci;
    CMPIInstance* cop;
    CMPIStatus st;

    Widget_Init(&w, _broker, KNameSpace(cop));
    Widget_Set_Id(&w, "1001");
    Widget_Set_Color(&w, "Red");
    Widget_Set_Size(&w, 1);

    ci = Widget_ToInstance(&w, &st);
    cop = Widget_ToObjectPath(&w, &st);

For a thorough explanation of how to use generated classes in your provider, see the KonkretCMPI documentation.

Generating provider skeletons

Finally, you can generate provider skeletons automatically. The following command shows how to create WidgetProvider.c from MOF class definitions.

    $ konkret -s Widget -m Widget.mof Widget
    Created Widget.h
    Created WidgetProvider.c

To see the generated skeleton, see the KonkretCMPI documentation.

Six CMPI pitfalls

KonkretCMPI was designed to address the six CMPI pitfalls identified below.

The dynamic nature of CMPI interfaces

The dynamic nature of the CMPI interfaces permits developers to specify keys and properties that

• are not defined in the class
• have misspelled names
• have incorrect types

These errors may slip unnoticed into run-time. KonkretCMPI eliminates these errors by introducing type-safe concrete interfaces that catch each error at compile time.

CMPI code complexity

In general, pure-CMPI providers tend to have high code complexity. KonkretCMPI reduces code complexity substantially with techniques mentioned above.

The CMPIinstance/CMPIObjectPath dichotomy

Forming a CMPI instance often requires adding the same keys to both the CMPIInstance and the CMPIObjectPath. This is a source of potential errors as well as code complexity. KonkretCMPI solves this problem by defining a concrete instance in which the keys are specified once.

CMPI method handling

With CMPI it is very difficult to correctly implement extrinsic methods. The developer must implement a very complex function that correctly processes method names, input parameters, output parameters. KonkretCMPI eliminates this work by generating concrete method skeletons for each extrinsic method. It makes implementing an extrinsic method nearly as easy as implementing an ordinary C function.

Missing support for common CMPI tasks

CMPI developers often find themselves implementing support libraries for common CMPI tasks. This decreases productivity and results in poorly tested utilities. KonkretCMPI provides several convenience functions to mitigate the need for these support libraries. For example, KonkretCMPI provides print routines for CMPIInstance and CMPIObjectPath and it provides a function for comparing tow CMPIObjectPath objects. We expect many more convenience functions to be added in future versions.

Too many CMPI provider operations

CMPI requires that all read-only provider operations be implemented before having a fully functioning read-only provider. For example, to implement an instance provider, one must at least implement the following functions:

• <CLASS>EnumerateInstances
• <CLASS>EnumerateInstanceNames
• <CLASS>GetInstance

Similarly, to implement an association provider, one must at least implement the following functions:

• <CLASS>EnumerateInstances
• <CLASS>EnumerateInstanceNames
• <CLASS>GetInstance
• <CLASS>Associators
• <CLASS>AssociatorNames
• <CLASS>References
• <CLASS>ReferenceNames

KonkretCMPI simplifies this by providing default implementations of all of these except for <CLASS>EnumerateInstances (which is easier to implement with KonkretCMPI). So by just implementing <CLASS>EnumerateInstances, all of the other operations are implemented automatically. In some case you might want to implement some of these others yourself. See the documentation for details.