Some of the framework modules integrate with external technologies. Once again, the integration process takes advantage of DIF's plugable architecture and IoC. It's possible to replace the default implementations with others that suit the user's needs best.
Keep in mind that while all the hotspots referred on the previous page can be used to connect new implementations there were typically be things that the regular user wouldn't want to change. This modules would be core features such as code generation services, DEM managers, dispatcher features, session and parameters. The need to change any of these elements would come in very particular situations and would requires a deeper understanding of the framework.
Typically a user might want to integrate more service-oriented features such as a different logging framework, encryption utilities, authorization and authentication contrivances. The most common integration points are described below, as well as their out-of-the-box and planned implementations.
Current implementation: The standard configurations options are stored in the Registry (for Windows environments) or on a file system structure (for Unix/Linux environments). The framework configurations mechanism is based on this API.
Future implementations: Support to database persistency of configuration options.
Current implementation: DIF's logging mechanism is based on the Logger, a log wrapping API that you can check here. This API is not really a logging framework but simply a wrapper for the logging platform. Please read the link above to understand Logger advantages. As can be read on the aforementioned page, the underlying logging appliance for Logger is Log4J. As such, this is the framework's default logging platform.
Current implementation: DIF's authorization uses a credential system based on users and groups. It currently supports a static user/group identity repository system in RAM or LDAP (AD and openLDAP) integration through this API.
Future implementations: Database backend, and the OID LDAP.
Current implementation: The default authentication mechanism that ships with DIF performs authentication locally. It doesn't support centralized authentication natively.
Future implementations: Integration with Microsoft Authentication Server and Kerberos.
Current implementation: DIF's authorization uses a credential system based on users and groups. It currently supports a static user/group credential system in RAM, or Database (any SQL database) credential repository.
Current implementation: DIF uses an ORM mechanism that allows connection to any relational database management system (RDBMS). See the complete information here.