!!! Overview[1]
This is an overview of [Best Practices] when using a [DirXML Remote Loader].


!! [SSL]
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
[{$pagename}] 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.

!! Summary
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:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Identity Manager Best Practices: DirXML Remote Loader|http://www.novell.com/communities/node/8822/identity-manager-best-practices-remote-loader|target='_blank'] - based on information observed 2013-07-01