[Contents] [Previous] [Next] [Index]

Chapter 10
Extending Your Directory Service

t is possible that you will want to write custom programs to obtain all the functionality in your directory service that you need to support your environment. These programs can take the following forms:

In this chapter you will find brief information on the circumstances under which you should consider creating custom programs to extend your directory service. You will also find brief information on the Application Programming Interfaces (APIs) that you can use to create directory server plug-ins and LDAP clients. This chapter includes the following sections:

Building Custom Tools for Data Migration

 As your directory service becomes more complex, it is likely that you will want to build custom clients and tools to move data in and out of your directory. Primarily you will do this if you are interoperating with a legacy directory or application that does not communicate over LDAP. Over time these kinds of interoperability problems should ease as more vendors start to support LDAP. However, for now you may either have to write a custom program to move data between your LDAP directory service and some legacy data store, or you will have to work with your vendor to get them to support LDAP in their application.

There are several basic approaches that you can take if you decide to write a custom program to move data in and out of the directory server:

  1. You can work with LDIF to manipulate your directory contents into a form compatible with the legacy directory. This can mean writing applications to either change LDIF into a form that is compatible with your legacy directory, or taking output from your legacy directory and filtering it into LDIF format. This approach benefits from being the simplest to implement in that the standard Netscape LDAP command line tools work directly with LDIF for import and export operations. This means that you can use PERL scripts, batch files, or shell scripts to automate the import and export operations.
    However, this approach will result in relatively slow data migration. Importing and exporting directory data to and from LDIF is a slow operation compared to direct communication over LDAP. Also, scripts and interpreted languages generally run slower than compiled code. As a result, you should use this approach only if you can live with a batch approach to synchronization -- that is, only if you want to synchronize your directories once or twice a day.
    For information on LDIF and the Netscape LDAP command line tools, see the Netscape Directory Server Administrator's Guide.

  2. Use the LDAP client APIs to write applications or applets that communicate with the directory server over LDAP. Netscape provides LDAP client SDKs in C and in Java that provide you access any of the standard directory server features that are exposed over the LDAP v2 and LDAP v3 protocols (for example, you can write applications that search the directory or that modify data in the directory).
    This approach requires a moderate amount of programming knowledge and possibly a fair amount of time. It also works best if the partner directory also supports an API set that allows you to move data in and out of it.

Building Custom LDAP Clients

 While the Netscape Directory Server ships with several LDAP clients, you may find that these clients do not support your environment. There may be several reasons for this:

As is the case for building custom data migration tools, there are two basic approaches that you can take when building custom LDAP clients:

  1. Use the standard Netscape LDAP command line tools. This approach works best if you want to write some PERL-based CGIs to support a web interface to your directory. This method is used most frequently by sites who want a very simple interface to the directory.

  2. Use the LDAP client APIs. While this approach requires some moderate programming skills, it offers you the ability to create efficient, flexible LDAP clients to support your unique requirements.

The LDAP C and Java SDKs

 Netscape provides several Software Developer Kits (SDKs) to help you write custom clients or tools that speak directly to the directory server over LDAP. You can obtain a client SDK for either the C or the Java programming languages.

Both SDKs allow you to customize the way an LDAP operation is performed by using LDAP controls. For example, the directory server supports LDAP server controls that set up persistent search and that specify that the server is to sort the search results. As a result, you can write an LDAP client that sends a control to make the server sort the search requests.

Both SDKs also allow you to request additional operations from the server (beyond adding, modifying, deleting, and searching for entries). You can do this by defining extended operations -- a mechanism for defining additional services that you want to make available from your directory server. For example, you can write an LDAP client and a server plug-in that request and perform digitally signed operations.

For more information on the LDAP client C and Java SDKs, go to LDAP Directory Developer Central, which is located at the following URL:

http://developer.netscape.com/one/directory/index.html

Writing Server Plug-Ins

If you want to extend the capabilities of the directory server, you can write your own server plug-in. A server plug-in is a shared object or library (or a dynamic link library on Windows NT) containing your own functions.

When starting up, the directory server loads your server plug-in and calls your functions during the course of processing various LDAP requests.

You can write plug-in functions that:

For more information on the directory server plug-in API, go to the Netscape Directory Server Programmer's Guide, which is located at the following URL:

http://developer.netscape.com/library/documentation/directory/plugin/index.htm

[Contents] [Previous] [Next] [Index]

Last Updated: 02/17/98 15:47:52

Copyright © 1997 Netscape Communications Corporation




Изменено 19-Mar-98 10:06
Copyright (С) 1999 Оптилинк