As previously described, the design of a given Client Solution is dependent almost entirely on the design goals and scope of that Solution. The only required component of any given Client Solution is the Policy DLL. In this section, we'll describe the interface functions and major points to consider in implementing a Policy DLL.
The FESF Policy Service calls callback functions in the Policy DLL to determine Policy, gather data, provide an opportunity for the Policy DLL to exercise control over particular functions, and to perform other support operations. The Policy DLL is loaded dynamically by the FESF Policy Service via a call to the Windows function LoadLibrary based upon the FESF configuration information in the Windows Registry (see Arranging for FesfPolicy to Load Your Policy DLL). After the Policy DLL is loaded, FESF calls PolicyDllInit to allow the Policy DLL to perform initialization processing. This initialization includes the Policy DLL calling FePolSetConfiguration to inform FESF of various configuration choices, including providing pointers to FESF for the callback functions that the Policy DLL supports.
While the role of the Client Solution's Policy DLL is always the same in any FESF system (it is always the primary interface between FESF and the Client's implementation), different Client Solution architectures may result in the Solution's Policy DLL doing very different processing. In some architectures, almost no processing is done in the Policy DLL aside from argument preparation and data marshalling. The Policy DLL is essentially stateless. In these architectures, actual policy determination and key management is done by a service with which the Policy DLL communicates. That service may either be hosted locally (on the same system as the Policy DLL) or remotely (on a server on a LAN system, for example).
In other Solution architectures, Clients may design their Policy DLL to be a more active participant in policy determination. In these architectures, the Policy DLL might store policy and key information locally, and only invoke a remote policy and/or key management service when local information is not available.
And, of course, there are infinite variations on the two Solution architectures that we've described.
Each approach to building a Policy DLL has its particular advantages and disadvantages. The Solution chosen will ultimately depend on what best meets the needs for the overall product being built and the environment in which it will be used. In any case, FESF does not impose any specific requirement or restriction on the Client Solution architecture, beyond the requirement that returns from Policy DLL callback functions must be prompt.
As an example of one basic approach to building a Solution using FESF – and as a demonstration of how to use the provided support services and perform common operations – OSR provides the complete source and executables for a Sample Solution. For more information about this sample, please refer to the FESF Sample Solution Guide.