The first step in designing a driver is to obtain a thorough understanding of the application for which you are writing a driver. You need to understand its application programming interface, security system, schema, procedures for change notification, operating system requirements, and remote protocol support. An in depth knowledge of an application will allow you to design a simple and efficient driver.
As you design your driver, you need to plan on a method to handle the following:
Data conversion. Your driver design should aim to make the driver a pipe with as much data conversion handled with rules and style sheets as possible. You can modify the rules and style sheets to change data conversion in a particular environment, and such modifications do not require recompiling the driver. If data conversion is handled by the driver, you may need to modify the data conversion code and recompile the driver to make it work in a particular environment.
Remote communication. The DirXML driver either runs on the server or is loaded using a remote loader. To use a remote loader, no changes are necessary. DirXML runs on NetWare, NT, Solaris, and Linux. If your application does not run on one of these operating systems, you must design your driver for remote communication. If your application supports a directory protocol such as LDAP, you can use that protocol for remote communication.
Passwords. To access the external application, your driver may need to log in. DirXML can be used to store the login information, and DirXML encrypts the application's password before storing it in eDirectory. DirXML engine version 1.1 DirXML and later can synchronize user passwords between eDirectory and the external application. For versions earlier than 1.1 use Novell Single Sign-on for password solutions.
Loopback detection. The DirXML engine has been designed to detect application loopback. It ensures that a change sent by your driver to eDirectory is not sent back to your driver as a change needed in your external application. Your driver is responsible for eDirectory loopback. It should ensure that a change sent by eDirectory to your driver is not sent back by your driver as a change needed in eDirectory.
Driver filter. The DirXML engine has been designed to filter changes so that the commands only contain the attributes and classes specified in the filter. However, DirXML runs more efficiently when each driver uses its filter to determine what data should be sent to the DirXML engine. If your application is remote, the filtering should be enforced, if possible, on the remote machine so that the eliminated data is not sent across the wire.
Data gathering. Your driver needs to use the most efficient and stable method for determining what has changed in the external application. If the application has an event system, you can use the event system to register for the events and efficiently obtain modification of changes. However, if the external application does not have an event system, you will need to implement another method. Many applications generate a log file of changes, and you can use the file to determine what has changed and to track what changes your driver has made and what changes are new. The disadvantage of using a log file is its format often varies from release to release. Since most application vendors view data sharing as a positive feature, work with the vendor's technical support department to determine the best method.
Schema differences. You need to be very familiar with the schema for both eDirectory and the external application, and you will need to design your driver to handle the differences. For example, an eDirectory attribute definition can flag an attribute as naming, single-valued, or multi-valued. If your external application has no concept of any of these, your driver must be designed to handle the differences.
The class definitions that are being mapped (such as User in eDirectory and System User in the external application) will probably contain different attributes. DirXML does not require that both applications share the same definition, only that both definitions contain the attributes that are going to be synchronized. If the eDirectory schema does not contain required attributes, you can extend the schema. Novell recommends using auxiliary classes rather than adding attributes to existing classes. (For more information, see the NDS Schema Reference.)
Attributes will often have different formats for the information. Where possible, you should use style sheets to handle the data transformation.