Deciding on the Best Interface

Both ADSI and the LDAP API have advantages and disadvantages. The following sections present various factors to consider when deciding which interface works for your situation.

The Programming Language Makes a Difference

For developers using C and C++, the choice of interfaces requires some consideration. Using the Windows LDAP API is straightforward, albeit sometimes primitive, whereas programming using the ADSI COM interfaces from C and C++ can be nightmarish to the uninitiated. However, if you are familiar with other COM components, such as ADO, working with ADSI will seem familiar and natural.

For other programming languages, using ADSI is a no-brainer, with one caveat. The language you use must support the Automation feature of COM, which Microsoft-provided languages do. Automation (discussed more thoroughly in the section "Automation" later in this chapter) is the mechanism that allows scripting languages such as VBScript and JScript to access the functionality in COM objects. Other scripting languages, such as Perl, PHP, and Rexx, are also available and can access ADSI objects.

Microsoft's Java development environment, Visual J++, works well with ADSI. However, other Java tools might not support the required COM interfaces, and Microsoft's support for Visual J++ is waning given the current push toward a new language named C# (pronounced C sharp) and the past legal battles with Sun Microsystems over implementation specifics.

JScript is Microsoft's implementation of the JavaScript language and has very little in common with the Java programming language. Specifically, JScript is the implementation of the standardized ECMAScript Edition 3, or ECMA 262, programming language. JScript is very popular in client-side HTML scripting, whereas VBScript is more popular for server-side scripting.

Platform Considerations

A deciding factor for C and C++ developers could be the client platform. ADSI is strictly a Windows-based technology. Even though Active Directory runs only on Windows 2000 servers, the information contained in a domain's Active Directory can be accessed from any platform—Windows or not—that has a network connection to the domain.

If you are creating an application that must run on Macintosh or UNIX-based systems, ADSI can't be used. If you anticipate porting your application to a non-Windows platform, you might want to use the Windows LDAP API initially on Windows. Since other operating systems have RFC 1823 implementations of the LDAP API, the porting process might be easier.

---

ADSI Can Be Used Regardless of Platform

Even though ADSI is only available for Windows, users of other platforms can still benefit from it. By using server-side applications such as Active Server Pages and writing ADSI code that runs on the server, the Web browser becomes a platform-independent front end to the directory application.

For companies with large investments in UNIX-based engineering workstations, this approach might be a better solution than writing separate client applications for each platform. See Chapter 11 for more information.

---

Performance

As a systems-level programmer, I'm always wary of technologies and languages that isolate developers from the underlying details. Usually my concern is with performance—what overhead am I paying for an object model? When I learned that the LDAP provider in ADSI calls the LDAP API functions to accomplish its work, I immediately thought that by calling those functions directly my applications would achieve a large performance boost, at the expense of a nice object model and language support. I'm happy to report that the performance overhead of ADSI is minimal. Since ADSI is an in-process COM component, method calls and property access in C and C++ are almost the same as calling a function directly.

With ADSI, performance can actually be improved over the lower-level LDAP API in some cases by caching object attribute data. In general, performance is not hampered significantly by using ADSI rather than making direct calls to the LDAP API library.

Documentation and Resources

Another consideration is the learning curve for the developer along with documentation and sample source code. Microsoft's documentation for developing with Active Directory is geared toward using ADSI. The majority of resources and sample code available use ADSI. While a number of excellent books on programming with LDAP are available, most focus on working with any LDAP directory and do not address Active Directory specifically. If you are unfamiliar with both LDAP and COM programming, I suggest that you dive into COM, as the knowledge gained will be beneficial in working with other Windows technologies now and in the future.

What This Book Uses

If you haven't already guessed, I'm an advocate of using ADSI to work with Active Directory, but I'm biased because I've been working with COM since it was originally introduced and have created my own COM objects and interfaces that ship with Windows. Trust me when I say that ADSI is easier to use and more powerful.

Also, developers no longer work in one language, and business solutions are rarely provided in a single monolithic application. This situation is a major reason for Microsoft's push toward language-independent object models and is reflected in my approach in this book.

With the exception of the LDAP sample presented earlier in this chapter, in this book I'll use ADSI from within Visual C++, Visual Basic, and Windows Script. Note that I didn't say programming languages. ASP and Windows Script include engines for VBScript and JScript and can support other languages, such as Perl. When using a scripting language, I use VBScript.