Federation: Using system services with wrappers

Because a wrapper must coexist with other federated server processes, you must be careful when using operating system services.

A complete inventory of the services that the federated server uses is not possible; it is better to assume that the federated server uses any system service and plan accordingly. This requirement applies as well to any third-party software that a wrapper could include. If it is not possible to guarantee good behavior, then some functionality must be isolated in its own process space.

The first step is to minimize the use of operating systems services wherever possible. The second step is to use those systems services routines that are provided through the wrapper utilities; it is especially important that memory management be done using these utilities.

Lastly, the wrapper must ensure that it uses services that change the system state correctly. For instance, if a wrapper uses signal handlers, it must install and remove them every time a wrapper routine is called; when the wrapper returns control to the federated server, its signal handlers cannot be left active. Another example is the use of alarms. A wrapper must restore the alarm state whenever it returns to the federated server.

Known restrictions on systems services:

Memory management must be done through the supplied utility functions and classes.
input/output (I/O) to stdout, stderr, stdin, cin, cout, cerr does not work.
Windows®: Wrappers must use the Win32 routine GetEnvironmentVariable(), not getenv().
Wrappers must not use the Unix and Windows system services for tokenization, strtok and strtok_r. The wrapper interface provides replacement system services for tokenization.