How many different directories do you have on your network? If you’re running NetWare, you’ve got NDS. You’ve got Active Directory if you’re running Windows 2000. You’ve got another one if you run Lotus Notes, and additional ones if you have applications like Netscape or PeopleSoft.
Having many different directories can be an administrative nightmare. As users join and leave your company or change their roles, you must make multiple changes in different places using different administrative tools. Fortunately, Novell recently released DirXML to help ease these problems. In this Daily Drill Down, I’ll take a look at DirXML and show you how it works.
DirXML is an application that runs on top of NDS. Novell has taken its expertise in directories and merged it with the flexibility of XML to create a product that allows you to integrate the directories of entirely different applications. When you make a change in one directory, DirXML automatically translates and makes the change to the other applications that it supports.
To do this, Novell started by looking at XML itself. XML (eXtensible Markup Language) was initially developed as an extension of HTML, the common language used to create Web pages on the Internet. However, the X in XML is what makes XML unique. Novell leveraged XML’s extensibility to use it as a way to move data between disparate applications.
HTML uses set tags to define how graphics and characters appear on a Web document. XML gives programmers ways to define tags and then use the tags to organize, define, and structure data. XML allows applications to share data, even if the applications use different formats or structures with the data.
Seeing the power and flexibility of XML, Novell applied it to NDS. DirXML takes information from NDS and then replicates it to the directories of non-Novell applications. It does so automatically in the background. Any changes you make in the familiar NetWare Administrator utility can automatically appear in Lotus Notes, Active Directory, or other applications.
This allows you to make sure that your updates are consistent across all of your applications. You don’t have to worry about making sure you didn’t miss making a change in an application.
What if you don’t particularly like NetWare Administrator, but prefer another application’s management utility? No problem. DirXML doesn’t care what application initiates the change. It makes sure that all the changes are applied across all of the applications it supports.
How does it work?
When you install DirXML, it makes extensions to your NDS schema. These extensions accommodate the information that DirXML uses to transform data types. New object types that DirXML creates in your NDS tree include:
- Driver Set—This object defines a collection of drivers.
- Driver—This object defines all the components of a driver, including rules, style sheets, and the application shim.
- Rule—This is an XML document that defines a rule that will be applied to the NDS event by the DirXML engine.
- Style sheet—This object represents an XSLT document that defines a transformation of the NDS XML code into another data format.
Using the properties of these NDS objects, DirXML can move data between NDS and just about any application. DirXML requires three things to work properly: an application shim, a supported application, and NDS. The DirXML engine makes the connection between the application shim, DirXML objects, and data, and it also passes events between NDS and the target application.
The DirXML engine consists of the Rules Processor and the XSL Processor. DirXML first converts NDS events into XML documents in DOM format. Using the Rules Processor, DirXML then applies rules to the XML document. Next, the DirXML engine uses the XSL Processor to transform the data into the target application’s native data format. Once the XML document has been completely processed, the event data is handed to an application shim, which delivers the formatted data to the target application.
To determine how events flow through the DirXML engine, DirXML uses publish and subscribe channels. These channels act as filters to define not only which events will flow through the DirXML engine but also which direction the data flows.
As you can probably guess by the names, publisher and subscriber channels refer to the directions in which NDS and the target application share changes. Subscriber channels are those that the DirXML driver uses to subscribe to and pull changes from NDS. Conversely, publish channels are those channels that the DirXML driver uses to publish changes back to NDS.
DirXML uses filters for both the publisher channel and the subscriber channel so that only events that are relevant are processed. If you don’t define a filter, then by default, no data events will be exposed to either system.
When data is received on the channel, it is passed through the DirXML engine. Once the data has been processed by the DirXML engine, it is handed to the application shim.
The application shim communicates directly with the target application. It acts as an API translator, taking data from DirXML and using the native application’s own APIs to present the data in a way the application understands.
Following the rules
When DirXML moves data between NDS and the target application, it uses the DirXML engine, which in turn transforms the data based on a set of rules. But, when you move data, you might not want to move certain types of data. Or data in one field in NDS may act differently in another directory. DirXML’s rules handle the associations of the objects and their properties between NDS and the application. Types of rules include:
- Event rule
- Schema Mapping rule
- Matching rule
- Create rule
- Placement rule
Event rules control how events performed on one application translate into events in the other application. As events pass through the channels, they do so in an XML format. In the process, these events can become essentially a different kind of event. A create event in NDS might actually become an add event in the target application.
The Schema Mapping rule overcomes problems that can occur with directories that have different schemas. The problem of conflicting schema may even occur with applications that use similar technologies. For example, two LDAP-based directories may have different schemas even though both use LDAP to normally access the data.
The Schema Mapping rule reads the NDS schema from NDS. The target application’s DirXML driver supplies DirXML with an updated view of its schema. With the two schemas side by side, the Schema Mapping rule maps the fields between NDS and the target application. The data moves from field to field based on these rules, even if the data has a different format or field name in the target application.
The Matching rule works in a manner similar to the Schema Mapping rule. However, rather than associating the differences in the layouts in two different directories, the Matching rule associates object properties from one directory to another. The Matching rule defines the minimum criteria that two objects must meet to be considered the same.
The Matching rule checks the attributes of an object in NDS and compares them to the attributes of an object in the target application. If the attributes defined in the rule match, the Matching rule treats the objects as one object. Otherwise, it creates a new object.
For example, you could have a Matching rule that checks a user object’s name, address, and telephone number. When you update the object in one directory, the Matching rule will use the rule to check for an object in the other directory with an identical name, address, and telephone number. When it finds it, it applies the change you just made. If it doesn’t find a match, it will create a new user object with the change you just made.
The Create rule manages the way objects are created. It checks to make sure that the data that is heading for a target application conforms to the application’s format. This ensures that the data isn’t malformed or incomplete.
The Placement rule defines how newly created objects are placed in the directory. These criteria can be based on class, attribute, or path. In other words, rules can be defined that determine where, in a connected application, the new object is to be created.
What applications will work with DirXML?
For DirXML to talk to an application, it must have the appropriate drivers. Even though XML is the generic format used by DirXML to carry data between different applications, the application driver allows the application then to read the XML delivered to it by DirXML.
While DirXML holds the promise of connecting many different applications, the first version of DirXML only includes a limited set of supported drivers. Drivers shipping with DirXML 1.0 include:
- Active Directory
- Lotus Notes
- Microsoft Exchange
- Netscape LDAP
Novell plans to release additional drivers for other applications as they become available. If your application isn’t supported and you don’t have time to wait for Novell to create a driver for you, you’re not completely out of luck. That is, unless you can’t program.
Novell provides an SDK (Software Developer Kit) for DirXML that supports C++ and Java. Using the SDK, a programmer can even create drivers that work with custom in-house applications.
What do I need to run DirXML?
To use DirXML, you must have installed NDS eDirectory 8.5. However, that doesn’t mean that you’re locked into having a NetWare 5 server on your network. Although eDirectory 8.5 works best with NetWare 5, you can also use Windows NT, Windows 2000, Linux, or even Solaris. Novell hopes to provide support for Compaq Tru64 soon.
Hardware requirements will vary depending on the software platform you’re running. DirXML runs on an Intel Pentium PC-based server or a Sun Microsystems SPARC-based server. For Intel-based servers, Novell recommends you have at least 128 MB of RAM, although it will run on a server with 64 MB of RAM. For Intel servers using Linux, Novell recommends 64 MB of RAM, but claims DirXML will work on servers with as little as 32 MB. Novell also recommends 128 MB of RAM on SPARC-based servers.
What’s it going to cost me?
Novell has priced DirXML differently than most of its products. Most Novell products are licensed on a per-user basis and can be purchased independently of other Novell software. Not so with DirXML.
Nor can you go down to the local software superstore to buy DirXML. DirXML is only available from Novell Consulting Services or Consulting Systems Integrator partners. Eventually, Novell will begin extending the availability to systems integrators, independent consultants, and other deployment specialists. You can contact Novell's Consulting Services at 1-800-714-1700.
Pricing for DirXML includes the cost of eDirectory. The actual cost of the DirXML/eDirectory combination depends on your individual requirements. As an example, Novell suggests that the license fee of DirXML software to a large company wanting to connect multiple systems consisting of PeopleSoft, Oracle, NDS, and Notes, and supporting over 10,000 users, would be approximately $350,000.
XML is going to be one of the most important standards created in the computer industry. Its flexibility will allow many different vendors to share data in ways heretofore undreamed of. With the introduction of DirXML, Novell has leveraged XML’s flexibility and its own expertise in network directories to glue directories together. In this Daily Drill Down, we took a look at what DirXML is, how it works, and what it can do for you.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.