Using KCML in an ASP environment
The ASP, or Application Service Provider, model is one where customers subscribe to data processing services provided by a third party who will then manage all DP aspects on their behalf. In some ways this is a return to the old bureau model. The high costs of managing in house applications had lead many companies to turn to ASP providers who have economies of scale and specialist staff.
The configuration on an ASP system is somewhat different to a standard KCML installation as it has to implement security for each copy of the application that is running on the host machine.
Affected areas are:-
Each customer's application should run with its own copy of KCML which will be installed into seperate directories. Isolating the KCML installations allows one system to be upgraded without affecting other applications. The Connection Manager can be configured to execute alternative KCML installations by the use of the $ASP_KCML_DIR environment variable. Each KCML installation shares the kconf.xml configuration by symbolically linking the file from the Connection Manager's directory into the alternative KCML directories.
Normally all instances of KCML on a server, even if executing from different directories, share a common $PSTAT and user count. In an ASP environment, each application will their own, isolated, $PSTAT memory segment. To achieve this systems must be numbered (in a range from 1 to 65535) and the SYSTEMID environment variable must be set to the appropriate number before KCML starts. KCML will check for this and create a special $PSTAT segment for that system number. This means that the #PART numbers will be unique only within that system and can be reused on other systems. #TERM terminal numbers are allocated from the file pointed to be the TERMFILE environment variable and there should be different files for each system.
Each system will also need its own license file and that file must contain a Systemid line appropriate to the system number. When ordering the license you must specify the system number you require. If each system has its own KCML directory then the file can have its usual name of lic.txt but on a shared system things are more complicated. In this case the simplest scheme is toE rename the file to lic.n.txt where n is the SYSTEMID number. If the environment variable exists then KCML will look for a file with that name first before looking for the generic name.
If you are using the Connection Manager then a service should be setup for each system in the kconf.xml configuration file and the SYSTEMID and other system specific environemnt variables can be set in the <environment> section for the service. All users must be explicitly listed in the <validusers> section.
With several customer systems on the same machine the service provider will need to be certain that all data files are created with the right permissions. On Unix servers this means each system has its own group, allocating the systems users to that group and making sure the UMASK is set to 007, ie allow owner & group, deny access for everyone else. his will prevent users from one application opening another application's files.
Each application should also be protected by using the Connection Manager's Access Control Lists (ACLs) which allow the specified user IDs and client network addresses to connect.
Some applications may require background processes, such as a global library process, to be started when the host machine is booting. This is normally achieved by the use of Unix shell scripts, a typical example is the script that starts the Remote Licence Daemon.
Writing a shell script that enumerates all the applications served by the Connection Manager would be a non-trivial task. The Connection Manager can execute shell scripts which will also inherit the application's environmnent variables, for further information see Connection Manager ASP support: Starting background processes.
This is the recommended method of starting the Remote Licence Daemon, kplicserver, as the daemon will inherit the $SERVICE and $SYSTEMID environment variables. When $SERVICE is set, the Remote Licence Daemon will only accept requests that are allowed by that service's valid clients access contol list. The Remote Licence Daemon will also use the same $PSTAT segment as KCML when $SYSTEMID is set so that each customer has their own isolated licence table, see Remote Licence Daemon Configuration.
ASP support for ODBC access is only supported when using the Connection Manager, see ODBC in an ASP environment. It will restrict access to the application's data using the same access control lists that control a normal application session. The ODBC server, kiodbc, also supports $SYSTEMID so that each customer system has their own set of ODBC licences.
See also:
Connection Manager ASP support,