|
| > Online Courses > Introduction to DirXML
|
|
|
Driver Design Considerations
Before designing and writing a DirXML driver, consider the following.
Know Your Application
You are expected to be the expert with the application you want to share data with eDirectory. The following are some of the things you need to be aware of when designing a DirXML driver for your application.
Data Conversion
If you do most of your development in source code, it is recommended to limit accessibility for the administrator in order to increase the ability to configure the driver with XML style sheets. Allowing most, if not all, driver administration and tweaking via the XML style sheets allow the Administrator of the driver to make changes without re-compiling the driver each time changes are made.
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
If your external application runs on a different server than your DirXML driver, you can use a directory protocol such as LDAP or a socket connection for remote communication.
Password
If your DirXML driver needs to login to an external database, eDirectory can store information and send that information to the DirXML driver during the driver's initialization phase. eDirectory provides optional C-based APIs to allow the secure manipulation of passwords in eDirectory.
Understand the Interface Capability
It is very important to understand your application's interface when designing a DirXML driver. The following are some items you should fully understand about your application.
APIs
The driver is responsible for communications between eDirectory and the external application or database. The DirXML driver can communicate directly with the external application or with another process that communicates directly with the external application. This communication can be through sockets, files, LDAP or whatever method works best for you.
Events
How are your going to gather the information from your application? Are you going to use an Event system or a log file? For example, say you want to connect eDirectory to an Oracle database. You would probably need to use Oracle API triggers to gather the information you want. If you wanted to exchange data with a Human Resources application like Peoplesoft, you would probably use the Peoplesoft API set to trap the data you want, thereby setting off triggers to get the data.
Loopback Detection
The DirXML engine has been designed to detect two kinds of loopback. One, it ensures that a change in eDirectory that is sent to your driver cannot be sent back to eDirectory as a change that eDirectory needs to make. Two, it also ensures that a change sent by your driver to eDirectory is not sent back to your driver as a change needed in your external database.
If the DirXML engine is connected to three or four DirXML drivers and is responsible for all loopback detection, too much of its processing time will be spent in loopback detection. On the other hand, if each driver implements loopback functionality, the DirXML engine can spend most of its processing time sending and receiving legitimate changes, thereby greatly increasing drive efficiency.
Security Issues
Be aware of any security concerns. For example, passwords to external databases. Also, you may want to have an encrypted channel, such as SSL or other to ensure that the data you are transferring is secure. As mentioned before, eDirectory makes a great repository for storing passwords and other sensitive data.
Identify Schema
Be very familiar with the schema for both eDirectory and the external application, and you need to design your driver to handle those differences. For example, a class definition can flag an attribute as mandatory, naming, single-valued, or multi-valued. If your external application has no concept of these definitions, 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 attribute. DirXML does not require that both databases 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 either write a program that extends the schema with these attributes or you can instruct the system administrator to create them manually with ConsoleOne.
Attributes will often have different formats for the information. Where possible, you should use XML style sheets to handle the data transformation.
Consider Schema Extensions
Extending the eDirectory schema can have many benefits to you as a DirXMl driver writer. The main one being that you can create eDirectory schema definitions to accommodate disperse data types in your application. However, if you choose to extent the eDirectory schema, keep these things in mind:
- Follow the Novell recommendations for naming, chiefly, no "_" or ":" characters are allowed.
- Be judicious, extensions are not easy to remove, so design carefully.
- Reuse your schema extensions wherever possible. This way you keep the eDirectory schema uncluttered.
- Use auxiliary classes if possible. They are easier to remove whereas base classes are not.
- Be sure to include the auxiliary classes in the appropriate filters.
Write Documentation
A little documentation goes a long way. Be sure to document how to set up your driver so it can talk to eDirectory. Documentation is a must if you make extensive use of XML style sheets to setup your driver. If you require driver code to be changed, thereby requiring the driver to be recompile, then the document needs to be very detailed. Otherwise you end-user will end up thoroughly confused.
ConsosoleOne Snapins
ConsoleOne is currently Novell's premier utility for administering eDirectory and NetWare, although this may be soon replaced with Web-based portal software and gadgets. Novell's DeveloperNet web site contains a ConsoleOne Developer Kit that helps you design your own ConsoleOne snapins. You have the ability to create a snapin to install your driver or to configure your driver or even extend the eDirectory schema for your driver's use. Using Novell's ConsoleOne SDK can streamline your driver development efforts by providing a way to create installation and other utilities to support your driver.
Filters
The DirXML engine has been designed to filter changes so that commands only contain the attributes and classes specified in the filter. However, DirXML runs more efficiently in a multiple driver installation 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 filtered-out data is not sent across the wire.
The filters can be different for the driver Subscriber and driver Publisher.
Summary
In summary, as you design your DirXML driver, you need to plan on a method to handle the following:
- Data Conversion
- Remote Communications
- Loopback Detection
- Driver Filtering
- Data Gathering
- Schema Differences.
Also, remember to create good documentation, use ConsoleOne snapins if appropriate, and filter your data.
 |
|
