Creating Objects in the Proper Order

IBM Security objects must be created in a particular order because some objects rely on the existence of others. For example, your application must create the Cims object first to establish communication with the Active Directory domain controller. After you create an instance of the Cims object, you must create the Zone object before you can create User, Group, or Computer objects because these objects exist in Active Directory in the context of the zone. The following figures illustrate the order for creating IBM Security-related objects:

Getting and setting object properties

You can read or write most object properties; however a few are read-only. The syntax line in the object reference indicates whether an object property’s value can be read ({get;}) or both read and written ({get; set;}). For example, the nextAvailableUID property can be both read and written:

int nextAvailableUID {get; set;}

To retrieve the existing value for this property, you could include a line similar to this:

read_uid_value = zone.nextAvailableUID

To set a new value for this property, you could include a line similar to this:

zone.nextAvailableUID = set_uid_value

Interface naming conventions

The IBM Security Windows API objects are stored in Active Directory using the IADs interface. The IADs interface is a Microsoft standard that defines basic object features—such as properties and methods—of any Active Directory Service Interface (ADSI) object. The most common ADSI objects include users, computers, services, file systems, and file service operations. The IADs interface ensures that all ADSI objects provide a simple and consistent representation of underlying directory services.

In addition to the basic ADSI objects, IBM Security-specific objects are implemented as IADs interfaces. Using interfaces for the IBM Security objects enables them to change internally without requiring any changes to the API. By convention, when objects are implemented as interfaces rather than class objects, they are identified by a capital “I” as a prefix. The IBM Security-specific objects that are implemented as interface objects have the same names as the classes in IBM Security-specific objects classes, with the addition of the “I” prefix; for example, the IZone interface object corresponds to the Zone class.

For more information about the IADs interface and working with interface objects, see the Microsoft Developer Network Library.