Module Installer Framework

Document #: 231ZR021
Authors: N. Asokan (ZRL)
Editor: N. Asokan (ZRL)
Reviewer: CRM
Status: Draft Version. 1, SEMPER internal
Date: April 25, 1997

Abstract

Introduction

The "distribution" of the module must be available in a separate directory. The directory should contain:

• A Java Properties file which defines all mandatory properties. Currently the standard mandatory properties are:
  • name - name of the module (e.g. SET)
  • block - SEMPER block to which the module belongs (e.g. payment)
  • author - identification tag for the author of the module (e.g. ZRL; there is no standard name space for this yet)
  There may be additional block-specific mandatory properties (e.g. a payment module must define purseClassName). In addition, a number of optional properties are supported by the standard Installer:
  • dlls - primary names of dynamically linkable libraries installed by the module; e.g. CRM is the primary name for the Cryptomathic crypto library.
  • packages top-level package names for package sub-trees installed by the module; e.g. semper.payment.SET. A module is allowed to claim package names either within its own space in the SEMPER package hierarchy (e.g. SET adapter for the payment block can install any package prefixed with semper.payment.SET or any name outside the SEMPER hierarchy.
• If the packages property was set, then there must be one directory for each package sub-tree specified, containing the classes for the package subtree (there can be sub-packages in the package). E.g. if packages was set to <Digicash semper.payment.ecash> then there must be two sub-directories by the same names in the distribution. The Digicash directory will be moved to lib/java/classes/Digicash directory and the semper.payment.ecash directory will be moved to lib/java/classes/semper/payment/ecash. Missing directories is considered a critical failure.
• If the dlls property was set, then there can be various versions of the each dll specified (one for each platform). The files are named: lib<BASENAME>.so.<OS> in the case of Unix (e.g. libCRMlib.so.aix) and <BASENAME>.windows.dll in the case of Windows (e.g. CRMlib.windows.dll). The correct file will be moved to lib/java/dll/<OS> directory. Missing dlls is not considered a critical failure (since some dlls seem to be available/necessary only for some platforms) .

For interactive installation, the properties file must be named props.txt.

The installation process consists of the following steps:

• sanity check of the Properties file
• ownership check: the first author to claim a name in a given name space (e.g. dll name space, package name space), retains that ownership until it is explicitly relinquished. Only the owner of a name can make changes to a file corresponding to that name.
• copying of packages into place
• pre-installation method execution from the Install class in the module (if available)
• copying of dlls into place
• installation hook execution from the block into which the module is being installed (if available)
• post-installation method execution from the Install class in the module (if available)

Installation Hooks

A block can implement the BlockInstallHook interface in a class and register the class with the Installer. The Installer will invoke the appropriate interface methods from an object of this class whenever a module is installed into the block. See payment block installation hook for an example.

The module itself can avail itself of an installation hook by having a class named Install which implements the ModuleInstallHook interface. The class must be available in the main package for that module (i.e. the package named semper.<BLOCK>.<MODULE-NAME> For example, the installation hook for the SET module of the payment block must be named semper.payment.SET.Install).

Example

• Create a distribution directory
• First, write a installation hook called semper.payment.ecash.Install implementing the Install which implements the ModuleInstallHook interface. The implementation of the preInstall method can query the user for a temporary directory and submit that to the environment interaction front-end for registration.
• compile the classes of the Digicash and semper.payment.ecash packages and move them under the distribution directory with the same names
• compile the various versions of the ecash library (say libecash.so.aix, libecash.so.solaris, and ecash.windows.dll and copy them under the distribution directory
• Create a properties file in the distribution directory with the name props.txt containing:

        name=ecash
        block=payment
        creator=DIC
        packages=Digicash semper.payment.ecash
        dlls=ecash
        purseClassName=semper.payment.ecash.ecashPurse
        

• ship the distribution

Miscellany