Core Implementation

An ADSI provider supports the following features.

• ADsPath strings in both COM and URL format. By definition, an Active Directory object can always be retrieved using an ADsPath. For the ADsPath syntax definition, see ADsPaths. Providers support whatever syntax their directory service requires using the ParseDisplayName implementation described in the next bulleted item.
• A top-level Namespace object that supports IParseDisplayName::ParseDisplayName and IADsOpenDSObject. This object contains the root nodes for this namespace. Part of the ParseDisplayName implementation must include a parser that checks for syntax errors for its own namespace. This object must also support IADs and IADsOpenDSObject.
• The IADs interface. This includes a simple property cache implementation through IADs::GetInfo and IADs::SetInfo. Operations that get or set object properties occur in cached mode. Cache values are written to the underlying directory store during SetInfo. An ADSI method, however, is not cached, but executes immediately.
• The IADsPropertyList, IADsPropertyEntry and IADsPropertyValue interfaces for directly accessing and enumerating the properties in the property cache. For directory services that do not expose a schema, this interface allows you to manipulate the properties of an object.
• The IDirectoryObject interface for non-Automation clients. This uses on-the-wire protocol for maximum performance and bypasses the property cache.
• The IADsContainer interface. Every Active Directory object has a parent container that controls its lifetime. Note that on ADs container objects, GetInfo affects only the container properties and not its contents. SetInfo on ADs container objects affects only newly created objects and the container properties, and does not affect objects that already exist within the container.
• The IDispatch interface. This is the Automation interface for languages like Java and Visual Basic that do not use compile-time binding. Related to this is the type library information that a provider must supply. For more information, see Implementation Issues for ADSI Providers.
• A schema class container object and the appropriate syntax, property, and schema class objects that support IADsSyntax, IADsProperty, and IADsClass respectively. At a minimum, each root node must contain its own schema class container object.
• The IADsMembers interface, if any supported attributes are collections of ADSI objects, such as security groups.
• The IADsCollection interface, if any supported attributes are collections of the same directory element type with Add and Remove capability.
• The IEnumXXXX enumeration support for all specific enumerator objects.
• Routines to map syntax and convert native data to the VARIANT data type. ·Follow ADSI conventions for provider-supplied ADSI objects. Include help files and type libraries documenting the interface properties and methods. See
• Meta-Schema Interfaces, a minimal implementation required. Because you map your directory service names for the appropriate attributes to the ADSI property names when implementing the meta-interfaces, client applications can display directory service objects in a uniform manner across all directory services.
• As with any COM implementation, you must return E_NOTIMPL for unimplemented interfaces and E_ADS_PROPERTY_NOT_SUPPORTED for unimplemented properties. For more information about dual interfaces and how they affect property implementation, see Dual Interfaces.