ADSI Extensions

An ADSI extension is a special COM object that allows developers to extend an ADSI object. Each extension is associated with a specified class in the directory. With this extension model, developers can add methods to give more dynamic meaning to an object. In a traditional directory programming model, an object is accessed by getting and setting the object's attributes. Using ADSI extensions, you can add more functionality to a directory object.

The way in which extension methods are implemented is up to the extension writer. An extension writer may even implement a method that is completely outside the scope of the directory. For example, imagine that a developer of backup and restore software is planning to extend an object called computer. The developer will need to create two methods: BackUp and Restore. These methods will operate remotely on the physical computer that the computer object in the directory is pointing to. By participating as an extension, the component automatically gains access to the ADSI infrastructure and is viewed by ADSI clients as an integral part of the object.

Of course, not all components are viable ADSI extensions. The following guidelines should help you decide if creating an ADSI extension is appropriate:

• Create an extension to integrate your component with the directory object. Since there is a user object in the directory, an HR developer may wish to create an ADSI extension that will populate other information in the directory every time a user is created.
• Create an extension if your component requires a directory lookup. Your component may require a directory as a starting point for a lookup. For example, say you are creating a new application. Your application object, FooApp, can be published in the directory. Your application may support status notifications on a collection of mail servers. You decide to make this application an ADSI extension.

  Now, a user may search for all instances of FooApp in the directory. For each object returned, the user may issue a call to NotifyNow(), for instance. Your application/extension will be able to get more information about the current object in the directory and notify each server asynchronously.

• Create an extension as a junction point between namespaces and programming models. For example, an ISV invents a new object model for print services. The printQueue object is already defined in the directory. The ISV can create an ADSI extension and associate it with the printQueue object. ADSI users will be able to bind to a printQueue object and start using the object model for the ISV. From the ADSI client's perspective, this junction point is transparent.
• Create an extension to simplify tasks. Many tasks in the directory can be accomplished by searching and setting multiple attributes in an object or multiple objects. By creating a single function to manipulate multiple attributes, it simplifies development for application and script writers.

For ADSI clients, extensions enrich the ADSI programming environment in many ways:

• Developers creating ADSI clients do not have to learn a new programming model. The extensions are part of ADSI. They would use the same paradigm for searching, data manipulation, and securing objects.
• Administrators can manage related directory-enabled applications using extensions.
• Extension consumers can view an ADSI object and extension as one integrated object.
• Existing components may be integrated with ADSI, which allows extensions to leverage existing investments and create a powerful synergy between components.

ADSI extensions were designed with the following goals:

• Easy to implement. With the current existing Microsoft® technology, Visual C++® and Active Template Library, you can develop an extension in just a few hours.
• Clients view one IDispatch. From the perspective of script and Automation writers, the extension methods and properties are transparently blended into one ADSI object.
• Independent. Extension writers can independently extend ADSI without prior knowledge of existing extensions.

Consider this scenario, a corporate developer or an ISV needs to develop a backup program. This backup program allows an administrator to back up all computers in the organizational unit he or she manages. With an ADSI extension, the following script is possible:

Dim ou as IADsContainer
Set ou = GetObject("LDAP://OU=Sales, DC=Microsoft, DC=COM")
ou.Filter = Array("computer")
For each comp in ou
   Debug.Print comp.Get("dnsHostName")
   Debug.Print comp.LastBackUp
   comp.BackUpNow
Next

LastBackUp is a property and BackUpNow is a method that the extension writer provides. The code illustrates the benefits for both extension consumers and providers. The extension writer does not have to reinvent a new way of filtering, searching, and accessing the directory. The extension consumer, on the other hand, does not have to re-learn a new programming paradigm. New methods and properties that the extension writer provides are viewed as if they are part of ADSI.

This section describes the following topics:

• ADSI Extension Architecture
• Getting ADSI Interfaces From Your Extension
• ADSI Extension Type Libraries
• ADSI and Extensions: What's Happening Under the Hood?
• Late Binding Support
• IADsExtension Usage
• Supporting Dual or Dispatch Interfaces
• Late Binding: What's Happening Under the Hood?
• Revisiting COM Aggregation Rules with ADSI Extensions
• What Does a Client See?
• Resolution of Multiple Aggregation Components Supporting the Same Interface
• Late Binding vs. Vtable Access in the ADSI Extension Model
• Resolution of Function/Property Name Conflicts in Automation in Extensions
• More on the Resolution of Automation Conflicts: Same Function Name but Different Parameters