Best Practices Remote Loader


This is an overview of Best Practices when using a DirXML Remote Loader.


A DirXML Remote Loader can implement SSL or TLS and that part always works (even if the destination application itself does not support Encryption you can still protect the connection by putting the DirXML Remote Loader on the Connected Application server or in a secure area with an SSLized connection to the DirXML Engine, and then the last part of the connection is just from the RL to localhost which is typically considered safe regardless of the presence or absence of encryption.

DirXML Remote Loader reduces the burden memory-wise on the engine side, which is a good thing. If possible using a DirXML Remote Loader in every case is a good idea (though obviously not possible with some drivers like eDirectory which cannot use a Remote Loader).

The engine handles all of the logic, query responses, documents, custom classes, and shims that cannot be moved to a DirXML Remote Loader as it is along with the Java environment and everything else eDirectory does. Offloading work to another process, even if it is on the same box, means you are giving EDirectory more of its memory back for things that cannot be exported (LDAP, logins, replication, etc.). Also because the DirXML Engine is not handling connections to applications there can be a performance increase on the DirXML Engine side because of less work to be done. The end application may also experience better performance since it is not waiting on replies from the engine which may be heavily burdened but instead works with a Remote Loader dedicated to that one interaction.

Shim Upgrades#

Using a DirXML Remote Loader makes driver (shim) upgrades easier because you do not need to take down EDirectory to reload new JARs. Simply stop the DirXML Remote Loader, replace DirXML Driver files, and bring it back up. The DirXML Engine attempts to reconnect the entire time and finally does so once the DirXML Remote Loader is back up with the new software. Only one driver was down and not all of the others within the IDM engine.

Shim JAR Conflicts#

Best Practices Remote Loader will allow additional paths for each DirXML Remote Loader instance. So there will not be any shim JAR conflicts.

protects EDirectory#

Using a DirXML Remote Loader protects eDirectory, and everything in it, from a crash caused by the third-party application's code (Oracle, PostgreSQL, MySQL, mssql, etc.) so while the DirXML Remote Loader will crash that won't hurt anything really (meaning eDirectory and all your other IDM drivers keep on working). Anything depending on the eDirectory instance that would have crashed instead keeps on working. Health Monitoring or auditing can tell you one component is down instead of end users and your manager calling you to tell you your entire world has fallen apart.


In summary whenever possible use a DirXML Remote Loader. DirXML Remote Loader is very lightweight (do some testing and see how light it really is), DirXML Remote Loader protects the parts of your infrastructure that really matter (eDirectory, the rest of the engine, etc.), and makes many upgrades easier to manage with less downtime and risk while providing encryption for every application including those that otherwise would not provide support for connection encryption.

More Information#

There might be more information for this subject on one of the following: