How DirXML Works

Test Objective Covered:

2. Describe how DirXML works.

Before beginning this topic, you need to understand that DirXML is a complex product. We're going to discuss how it works at the conceptual level only. When DirXML was first released in 2000, I had the opportunity to sit in on a class taught by the software engineers who wrote the product.

The class was full of experienced network consultants . However, by the time the class ended two weeks later, we all had acquired a permanent stupefied look on our faces (accompanied by a nervous twitch). The complexity of the product and the level of detail presented in the class made our heads hurt!

Based on that experience, I will endeavor to make DirXML as easy to understand as I can in this book. Let's get started by reviewing the structure of the DirXML product and its various components .

DirXML Components

DirXML is composed of the following elements:

• The data source

• The data destination

• The DirXML engine

• The DirXML drivers

• The subscriber channel

• The publisher channel

• The subscriber channel rules and filters

• The publisher channel rules and filters

These are shown in Figure 7.3.

Figure 7.3. DirXML components.

Let's talk about each component. The data source is the system (usually eDirectory) that is monitored for add, modify, and delete events. It's the authoritative data source mentioned earlier.

The data destination is the system to which data from the data source is being synchronized. The DirXML engine is the heart of DirXML. The DirXML engine itself is composed of two components: the eDirectory interface and the join engine . The eDirectory interface is used by the DirXML engine to connect with the eDirectory service on the server where eDirectory is running.

The join engine processes each add, modify, or delete event that comes to the DirXML engine and applies the various rules you've configured to the event. We'll talk more about rules and filters later in this chapter.

An DirXML driver is a product-specific driver that is used as an interface between DirXML and the product. The Starter Pack version of DirXML that comes with NNLS includes licensed drivers for Windows NT Domains, Active Directory, and eDirectory (which allows you to synchronize two eDirectory trees). It also includes evaluation drivers for PeopleSoft, Lotus Notes, and Microsoft Exchange.

DirXML drivers themselves are composed of two parts . Each driver contains an XML interface that is used to process XML documents going to and coming from the DirXML engine. Each driver also contains a product-specific interface that is used to convert information to and from the native data format of the product.

The subscriber channel is used to send events from the data source through the DirXML engine into the destination system. The publisher channel is used to receive events from the destination system through the DirXML engine and into the data source.

Warning

The names of the two channels would lead one to believe that their functions are the opposite of what they really are. This is a point of considerable confusion.

Remember that the subscriber channel moves data to the data destination and that the publisher channel moves data from the data destination.

Each channel contains its own set of rules and filters . The publisher and subscriber channel rules define what action is to be taken for a given event. Such items evaluated include whether "add" events should be ignored or propagated and whether "delete" events be ignored or propagated.

The publisher and subscriber channel filters are used to specify exactly what information you want synchronized. Let's discuss rules and filters in more depth.

DirXML Filters and Rules

Knowing how to configure rules and filters is key to effectively managing a DirXML implementation. Rules and filters help you define the direction data flows in the DirXML system and what data is replicated and what data is not.

Establishing these elements is how you define an authoritative data source. An authoritative data source is the "point of entry" into the system for network information. From this authoritative data source, data is replicated to the rest of the system.

Configuring Authoritative Data Sources with Filters

You can filter by object class or by specific attributes within an object class. For example, you could specify that users but not groups be synchronized from one system to the others. You could also specify that certain attributes of the user object, such as the mailing address, not be synchronized while the remaining attributes are.

To create an authoritative data source, you remove objects or attributes from the publisher channel filter while adding them to the subscriber channel filter. By doing this, you create a data flow in a single direction. This is shown in Figure 7.4.

Figure 7.4. Establishing authoritative data sources with DirXML filters.

Once you have your filters in place, you next need to configure the various rules for each channel.

DirXML Rules

DirXML rules define what action should be taken for a given event. The DirXML engine monitors the following types of events:

• Add Object events

• Modify Object events

• Rename Object events

• Move Object events

• Delete Object events

• Password Modification events

DirXML uses a number of different rules. Matching rules exist on both the publisher and the subscriber channels. The matching rule is the first rule applied on both channels. The matching rule is invoked whenever an Add Object event is detected .

Tip

The term entry used here refers to any database entry in the various systems synchronized by DirXML, including eDirectory.

Within the rule, you specify the attributes you want entries matched on between systems. For example, you could specify that entries be matched between systems on the given name and surname attributes.

When an Add Object event is detected, the matching rule is invoked and a connection is made between the data source and destination systems. The matching rule then attempts to find an existing entry in the destination system that matches the new entry based on the given name and surname attributes.

If a single match is found in the destination system, an association is established between the two entries. Essentially, the new entry in the source system is said to be the same as the entry found in the destination system.

To understand associations, you need to understand that the databases synchronized by DirXML each use different attributes to function as unique identifiers for database entries. No two entries in the DirXML system can have attributes that share the same values.

In one system, it might be the globally unique ID (GUID) attribute. In another system, it could be the employee number attribute.

When DirXML is installed, the eDirectory schema is extended, and each object in the tree has an association attribute added to it. If the matching rule identifies an association between two entries, the association attribute of the eDirectory object is populated with the ID of the correlating entry in the other system. This is shown in Figure 7.5.

Figure 7.5. Object associations.

If multiple matches are found based on the matching rule criteria, DirXML will discard the event. If no match is found, the Add Object event is propagated on to the next rule.

Besides the matching rules are a handful of others to be aware of:

• Creation rules ” Creation rules also exist on both the publisher and the subscriber channels. The creation rule is applied after the matching rule has been applied.

  The create rule is invoked when an Add event has been detected. The creation rule establishes the attributes that must be populated in the newly created entry in order for the Add event to be propagated.

  For example, you could specify that only entries that have the Given Name and Surname attributes populated be created in the other system.

• Placement rules ” Placement rules exist on both the publisher and subscriber channels. The placement rule is also invoked when an Add event is detected and is applied after the matching and creation rules have been applied.

  The placement rule assumes the Add event has met all the criteria specified in the previous rules and is a valid event. The placement rule determines where in the tree or in the product being synchronized the new entry is to be created.

  The placement rule is usually only needed if the information is being synchronized to a product that uses a hierarchical structure (such as eDirectory or Active Directory). If the information is being synchronized to a flat-file product, the placement rule isn't needed.

  Placement of the new object can be configured based either on the placement of the original entry or on specific attributes of the new entry.

• Schema-mapping rules ” Schema-mapping rules exist on both the publisher and the subscriber channels. On the subscriber channel, the schema-mapping rule is applied before the matching rule. On the publisher channel, the schema-mapping rule is applied after the placement rule has been applied.

  The schema-mapping rule is needed because different database systems use different schemas. DirXML uses the schema-mapping rule to specify which eDirectory objects and attributes map to which entries and attributes in the other system.

  For example, you may map the Given Name attribute in eDirectory to the First Name attribute in the remote system. You might map the Surname attribute in eDirectory to Last name. You could also map the Uid attribute in eDirectory to the User Name attribute in the other system.

One important point to remember is that these rules apply only during Add Object events. Once the Add Object event has been fully propagated, an association is established between the entry in the source system and the entry in the destination system. This association remains until one of the entries is deleted or the network administrator breaks the association.

From there on, any other event, such as a Modify, Rename, or Delete event, that is completed on one of the associated objects is immediately completed on the corresponding object in the other system (depending, of course, on how your filters are configured). The rules discussed here are not needed and, therefore, are not applied.

In addition to filters and rules, both the subscriber and the publisher channels provide transformation stylesheets .

Transformation Stylesheets

Transformation stylesheets are used by both channels to customize the functionality of DirXML. Before delving into these stylesheets, you should know that you don't have to know about them to pass the CLE certification. We're going to briefly cover them, however, so you will understand what they are and how they work if you encounter them when working with DirXML. The transformation stylesheets provided by DirXML include those listed in Table 7.1.

Table 7.1. DirXML Transformation Stylesheets

STYLESHEET	LOCATION	FUNCTION
Data transformation	Subscriber channel (input transformation)	Different systems expect data to be entered in different formats. Data transformation stylesheets are used to convert data from one format to another.
	Publisher Channel (output transformation)
		For example, one system may store phone numbers without parentheses or dashes, as in 8885551234.
		Another system may store them with parentheses and dashes, as in [phone].
		The data transformation stylesheet is used to convert data to the appropriate format as it passes through the DirXML channel.
Command transformation	Subscriber channel	Command transformation stylesheets are used to customize the commands associated with DirXML events.
	Publisher channel
Event transformation	Subscriber channel	Event transformation stylesheets allow you to customize how DirXML responds to events.
	Publisher channel	There may be times you don't want an Add event to be propagated as an Add event. You may want it propagated as a Delete or a Modify event to the other system.

That's it for the conceptual structure of DirXML. Let's next turn to a discussion of what happens to your system when DirXML is installed. After that, we'll start configuring some drivers.