Share via

2.3.3 CIM Methods

  • Article

The method signature (that is, the return type) input parameters and output parameters are encoded by using embedded CIM object encodings. Methods are as specified in [DMTF-DSP0004] section 4.9 and are specified syntactically in the methodDeclaration rule, as specified in [DMTF-DSP0004] Appendix A.

The method signature consists of two embedded CIM objects of a CIM class called __PARAMETERS. Within the embedded objects, the parameters appear as properties. The parameter name as it appears in the method is the CIM property name, and the type of the parameter is the CIM property type.

This is illustrated in the following example.

 class MyClass2  :  MyClass
 {
   [execute, performance={"fast", "sideffects"}] 
   uint32 Restart([in] string ServiceName, [out] int32 Status);
 }

In the preceding CIM class example, there is a method called Restart. The parameters are encoded in the same way as other CIM class definitions. Each method definition contains two CIM class definitions: one for the input parameters and one for the output parameters. These classes always have the same name, __PARAMETERS, but reflect the parameters of the current method that is being encoded; so there is no immutable definition for the class. In this example, the two CIM class definitions appear as follows.

  
 [abstract]
 class __PARAMETERS
 {
   [in, ID(0)] string ServiceName;
 }
 [abstract]
  
  
 class __PARAMETERS
 {
  [out, ID(1)] sint32 Status
  uint32 ReturnValue;
 }

Remarks

  • Both CIM class definitions MUST be marked with an abstract qualifier. The first CIM class definition is used to package any in parameters to the method, and the second is used to package any out parameters.

  • There is one definition to contain all input parameters (regardless of where they appear in the method signature) and one definition that encodes all output parameters and the return value.

  • The order of declaration in these classes is the order in which the parameters appear. Because the parameters appear in an explicit order in the Managed Object Format (MOF) signature but are split between two separate CIM class definitions in the encoding, an ID attribute is added for each parameter. The ID attribute represents the ordinal position of that parameter in the original signature.

  • The return value, which has no name in the CIM method declaration, does have an explicit name in the output CIM class definition and is always ReturnValue. Because of this reserved name, a method cannot explicitly contain ReturnValue as a named parameter.

  • The __PARAMETERS CIM class is not a true CIM class because the format changes for each method and the format is not separately usable as a real CIM class definition. It is just a valid method to reuse the encoding mechanism for classes. Because classes require names, __PARAMETERS is nothing more than that name.

Therefore, a method encoding contains two apparent CIM class definitions (in the InputSignature and OutputSignature rules in ABNF) that encode the parameters for the method.

Any qualifiers on the individual parameters become qualifiers on the properties of those names within the __PARAMETERS CIM class definition.