 |
|
|
|
|
|
|
|
|
| April 2001 | |
|
|
| DeveloperNet University Course | |
|
|
|
PBXSimulator Lab Project Description
Objective: After studying the concepts in this section, you should be able to describe the lab application and the labs which you will perform to operate on it.
Before you get started on the labs, you need to understand PBXSimulator (the application you'll be writing a driver for).
Introduction to the PBXSimulator
DirXML was designed to be flexible enough to connect any disparate data repository with NDS. However, the form the DirXML driver will take depends on the features available in the application you're writing it for.
The closer your system resembles a combination of DirXML and NDS, the easier the DirXML driver will be to develop and the more efficient it will be. So, like the combination of DirXML and NDS, the ideal disparate application will have its own:
- Event system
- Exposed data access APIs
- Hierarchical data organization
- Communicate directory events using XML as its native language
In many cases, directories external to NDS don't have one or more of these features. This means you'll have to make compromises in the design and performance of your DirXML driver.
The lab driver in this course works with an application called PBXSimulator. Note that for the purposes of DirXML, PBXSimulator is a less than ideal application because it does not communicate natively with XML, has no event system, and has a flat data model. These deficiencies make PBXSimulator ideal for these labs because it gives you experience in overcoming them.
Figure 1: An Example of PBX Simulator's Interface
Data Synchronization between PBXSimulator and NDS
In previous lessons, you learned that NDS has an event system that notifies the DirXML engine of NDS changes. The engine sends commands resulting from these notifications to the Subscriber side of your DirXML driver in the form of XDS documents. The subscriber shim interprets the XDS documents, and if the external system has exposed data access APIs, the shim calls them to immediately implement the appropriate changes in the external directory. So, by using the NDS event system, DirXML can achieve immediate data synchronization from NDS to the external directory.
If you want to achieve real-time data synchronization on the Publisher side (the side that pushes a change to NDS), the external directory must also have an event system. This enables the Publisher side of the DirXML driver to be instantly notified of changes in objects (records) from the external directory.
Keep in mind that some systems don't have a native event system because those systems weren't designed to hook up with other directories. For example, many PBX systems don't have event systems. Yet, PBX systems maintain lists of users and associated phone numbers in a kind of directory that you might want to synchronize with an NDS directory. When the PBX operator changes a phone number, you want the new value pushed to the NDS directory. And when the NDS administrator changes User Name or Title information, you want that information pushed to the appropriate entry in the PBX system.
In order to be notified of changes in an external directory, drivers connecting to applications without event systems must usually poll the application for change events. If the application doesn't have data access APIs, directly querying the application's data store is impossible. In cases like these, you must implement other strategies to poll for changes. For example, if the application maintains a change log file describing all of the changes made to its data, the driver can parse the log file periodically to figure out what changes need to be made to NDS to synchronize with the application's database.
PBXSimulator has exposed data access APIs, but no event system. So, the lab driver polls PBXSimulator for changes accumulated to its database.
PBX Simulator's Containment Levels
Besides its not having an event system, PBXSimulator's available levels of containment is another major difference between it and NDS. Containment in NDS's hierarchical data organization is virtually unlimited, while containment in PBXSimulator must always occur at a location in a department.
Figure 2 shows PBXSimulator's locale editing window. This window is displayed by clicking PBXSimulator's Edit Locations button.
Figure 2: PBXSimulator's Locale Editing Window
In Figure 2, you can see that the location "Provo" contains finance, engineering, and education departments. You can view the departments for other locations by double-clicking on their location names. PBXSimulator doesn't allow you to create a new account without selecting both location and a department.
The DirXML Labs
During the rest of this course you will perform projects in each of the PBXSimulator DirXML driver's critical areas. All of the labs listed below use the lab base described above:
Lab 1: Installing the Basic Lab Driver. This lab gives you exercise in installing the basic lab driver. This lab will help you become familiar with DirXML driver configuration in general and enable you to perform the subsequent labs.
Lab 2: Analyzing NDS.DTD to Construct XDS Trees. Driver shims and XSLT stylesheets must communicate with the DirXML engine using XDS documents. This lab gives you some practice in interpreting NDS.DTD to learn what the composition of these trees is supposed to be so that the engine will do what you intend for it to do.
Lab 3: Parsing Input Parameters in the Basic Lab Driver. This lab gives you exercise in adding functionality to the basic lab driver. In the first lab, a string specifying the location of the "pbx" folder accessed by the driver shims is hard-coded into the shims themselves. This means the executables must be recompiled if the "pbx" folder is ever moved. To make the driver more configurable, this lab has you add code to the shims so that they can parse input parameters to obtain file pathnames the administrator has entered during configuration.
Lab 4: Programming the Publisher Shim to Modify NDS User Objects. The previous labs were configured to create User objects in the NDS tree whenever accounts were created in PBXSimulator. Lab 1's Publisher shim contains the code needed to parse the external directory's add and delete event descriptions using W3C DOM. During this lab, you'll be asked to program the publisher shim to modify NDS User objects whenever their associated account in PBXSimulator is changed.
Lab 5: Programming the Subscriber Shim to Modify PBXSimulator Accounts. During the fourth lab, you learned to enable the Publisher shim code to use W3C DOM APIs to modify User objects. In this lab, you will learn to do the same thing in the opposite direction. During this lab, you will be asked to program the subscriber shim to modify PBXSimulator accounts whenever their associated NDS User object is changed.
Lab 6: Programming Stylesheets. The flexible solution for implementing business rules is usually a style-sheet. Stylesheet programming is different from the code in shims in that stylesheet code is not compiled. Instead, stylesheet programs are composed using the Extensible Stylesheet Language Transformation Language (XSLT) which is interpreted by XSLT processors to manipulate/construct XML documents. Since XSLT is interpreted, this means that the administrator can modify stylesheets as needed for each installation without having to rebuild/recompile the driver. During this lab you will learn to program basic identity transformations of XML documents stylesheet programming with XSLT.
|
|||||||||||||||
