Since IDM is such a complex field, we should have a seperate design document that has a few example scenario's and best practices how to design/ implement.
The Remote Loader does more than simply keep the shim close to the application. That, by itself, may seem like a good or bad decision for one reason or another but there are definite benefits to running a shim outside the engine. As a result using a Remote Loader in every case where possible is recommended. Some drivers cannot be run in a Remote Loader environment (eDirectory, for example) though for the most part those drivers are the exception to the rule. The definite benefits from using the Remote Loader are listed below.
First, the Remote Loader (RL) can implement SSL and that part always works (even if the destination application itself does not support encryption you can still protect the connection by putting the RL on the application server or in a secure area with an SSLized connection to the engine, and then the last part of the connection is just from the RL to localhost which is considered safe regardless of the presence or absence of encryption).
Second, it reduces the burden memory-wise on the engine side, which is a good thing. If possible using a 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 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 engine is not handling connections to applications there can be a performance increase on the 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.
Third, it makes driver (shim) upgrades easier because you do not need to take down eDirectory to reload new JARs. Simply stop the Remote Loader, replace JARs, and bring it back up. The IDM engine attempts to reconnect the entire time and finally does so once the Remote Loader is back up with the new software. Only one driver was down and not all of the others within the IDM engine.
Fourth, it 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 RL 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 Remote Loader. It is very lightweight (do some testing and see how light it really is), it 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.