ADSI Extension Architecture
ADSI extensions are based on the COM aggregation model with several enhancements. Extensions still must satisfy all COM rules. Please consult the COM specification for more information.
For convenience, let's quickly review the COM aggregation model.
An aggregate, also known as an inner object, is an object that an aggregator creates. Your extension object is an aggregate.
An aggregator, also known as an outer object, is an object that creates an aggregate. ADSI is an aggregator.
The inner object delegates its IUnknown to the aggregator's IUnknown.
ADSI extensions add the following enhancements to COM aggregation in order to satisfy its requirements:
- Allows each extension writer to extend ADSI objects independently. An extension writer may register its extension with ADSI and not worry about the existence of other extensions. In the COM aggregation model, the aggregator must know the aggregate's CLSID. ADSI relaxes this requirement by making itself act as the aggregator for all extensions. Therefore, instead of forming a layer of nested components, extensions are siblings to each other.
- Allows one object, one IDispatch. From day one, Automation support has been one of the most important features of ADSI. Automation support is achieved because ADSI supports the IDispatch interface. Extension writers are also encouraged to support the IDispatch interface. However, there should be only one IDispatch interface on a given object. ADSI integrates and collects the many IDispatch interfaces from different extensions and presents them as one consistent IDispatch to the Automation controller. Each extension, when aggregated, must re-route its IDispatch calls to the IDispatch provided by ADSI.
All these solutions are possible because of services that the ADSI Object Manager provides, which reside on each ADSI provider.
The following figure shows the ADSI Extension Model architecture.
ADSI supports two levels of extension:
- Early Binding Support. This is the first level of extension. An extension must support registration and implement new interfaces. The extension consumers must use tools or scripting hosts that support early binding, for example, Visual C++ , Visual Basic.
- Late Binding Support. This happens when an extension satisfies all early binding requirements, and implements an additional interface, IADsExtension. Extension consumers can use any tool that is able to act as an Automation controller, such as the Windows Script Host, Active Server Pages, or HTML with VBScript.