 |
|
|
|
|
|
|
|
|
| April 2001 | |
|
|
| DeveloperNet University Course | |
|
|
|
DirXML Features
Module Objective: After studying the concepts in this section, you should be able to describe the features of DirXML in general terms.
DirXML is flexible enough to connect completely disparate directories like those shown below.
Figure 1: The NDS to NDS driver synchronizes data between two NDS trees, running on servers in NDS Tree1 and NDS Tree2.
This flexibility comes from the following features:
XML/XDS Conversant
Many data processing applications are being upgraded to communicate with XML.
DirXML's own XML vocabulary for communicating directory information is called XDS. You will learn how to program your driver to read and write XDS documents during this course's labs.
The DirXML engine on the NDS server converts NDS events into XDS documents that can be readily translated into other XML vocabularies, making it easy to mate DirXML drivers up with XML conversant applications.
External Application Generated Associations
DirXML extends the schema with several new classes and attributes. All classes in the schema get a new multi-valued attribute named "DirXML-Associations".
Each driver must supply a unique key for every object that it adds to NDS via DirXML. Generally, the driver creates this key from the object's data in the external application. DirXML installs this unique key as a value into the associated NDS object's "DirXML-Associations" attribute. This way the associated record/object can be uniquely referenced in NDS and on the external application side as well.
Because the association value is contrived by the driver, independently accessing external application data, the external application can use whatever it is already using as a unique key for the object and need not know anything about DirXML or NDS.
The association attribute is multivalued, so that each DirXML driver that is synchronizing data with a particular NDS object can add its own association.
Configurable Schema Mapping Rules
DirXML does not require the external application to use NDS attribute and class names. DirXML's mapping rules allow NDS type names to be translated to corresponding names in the external application and vice versa.
For example, if the external application is a database which uses the field name "Last Name" to reference a User's family name, a DirXML mapping rule can map the value corresponding to the NDS attribute name "Surname" to the external application's "Last Name" field when sending information to NDS. The same information will be mapped the other way when sent to the external application.
Mapping rules can be easily edited, making it easy to adapt to data type modifications on either the NDS side or the external application side.
Programmable Create Rule
Each application that is being synchronized with NDS might have different conditions for creating a new entry. The create rules can be configured to list those conditions, and the DirXML engine will ensure that the entry has values for all the required attributes before it is created. For example, NDS requires a name, a surname, and an object class to create a User. If the PBX database requires a first name, surname, telephone number, and location, DirXML ensures the entry has values for these attributes before it sends a create command to the PBX database.
Selectable Data Source Authority
The types of data which flow in each direction, to and from NDS are specified in filters. These filters can be set up so that selected types of data can only flow in one direction.
For example in the PBXSimulator scenario, the PBXSimulator application is the authoritative data source for telephone number attributes in User objects. Other applications with DirXML drivers can obtain telephone number values but they cannot change them. This would make sense in a corporate environment where you would want the PBX to control the phone numbers since that is where they originate.
In addition, access to objects and attributes may be granted to or revoked by configuring ConsoleOne's DirXML configuration objects. This allows fine-grained control over read and write access to data in the directory by an external application
This ability to select data source authority promotes data consistency across applications and the enterprise.
Filtered Replicas
The DirXML architecture allows the NDS administrator to select only the data that is relevant for sharing with the external application in a special filtered NDS replica stored on the same machine as the DirXML driver.
For example, in the case of a DirXML driver synchronizing a HR database, the database might want to share user-type objects with NDS, but would not be interested in network resource objects such as servers, printers, and volumes.
NDS, would want to share a user's given name, surname, initials, telephone numbers, and work location, but would probably not be interested in storing the user's family information and employment history (unless another DirXML connected application needed access to this information).
So, the filtered replica on the DirXML driver's machine would be configured to contain just the subset of NDS information pertinent to the driver instead of all the classes and attributes contained in the tree's NDS schema. This way, updating the replica and synchronizing it with the rest of the NDS tree becomes much more efficient.
Ultimately, the data type names selected for data filters in either direction must also be included in the data type names selected for the filtered replica for the driver.
Configurable Data Transformation and Business Rule Programming
DirXML uses eXtented Stylesheet Language Transformations (XSLT) stylesheets as a mechanism for performing data transformation and implementing business rules.
For example, if an external application stores date information in a string-based date format (e.g., MM/DD/YYYY), then an XSLT transformation rule can ensure that NDS date information (generally stored as the number of seconds since 1/1/1970) is converted before being sent to the external application.
Further, if a log of transactions is needed, another XSLT rule can be added to accumulate the date and other information about the transaction to a logging document.
In fact, the XSLT stylesheets in DirXML can implement virtually any kind of business rule or policy on the data passing through the driver.
|
|||||||||||||||
