Example: Browser Configuration

 The background of the example is a simple configuration management architecture using mobile agents, as a special form of mobile code (s. section ), based on Java technology for executing tasks in intranets.

The term mobile agent is used to denote executable code which migrates to different execution environments to perform its tasks. The work does not rely on other specific aspects of mobile agents for this particular application.

Every host which supports the management architecture has an agent system running serving as a common platform for agents. Objectspace Voyager [#!Voy2000!#] is used as mobile agent platform. The primitive agents are initialized with a list of hosts and move from one host in the list to the next to locally execute their task. After execution of the task on the last host, the agents terminate. The configuration procedure must set the size of the disk cache and the memory cache of the browser. The setting of these parameters must be system dependent in order to get the optimal cache size, hence the opportunity for code adaptation to fit to local circumstances.

The example agents are programmed to set the size of the disk and the memory cache to a reasonable percentage, e.g. 10%, of the free disk space for the disk cache and of the physical memory for the memory cache.

The agents must support various CPU architectures and operating system configurations, e.g. Windows NT/x86, Linux/x86, AIX/PowerPC, etc. and different web browser types, e.g. Netscape Communicator, Microsoft Internet Explorer, Lynx. The access to system information, like physical memory size and free disk space, is in most cases not provided by Java functions and must be implemented in platform dependent functions. Even if the configuration files for the browsers are in text format and accessible by platform independent Java APIs, e.g. Netscape, Lynx, there are still the syntactical differences between the configuration files of different browsers.

The support of different platforms and applications and the lack of standardized interfaces for this task forces the agent programmer to instrument the agent with various implementation variants for various platforms and browser types. As pointed out earlier, this could result in an implementation that uses static customization (s. section ) for choosing between different forms of behavior. To motivate the adaptation framework presented in this work, a more advanced solution is however assumed in the following based on code adaptation.

The collection of system information and the configuration of the browser is e.g. done in the function configBrowserCache(int,int) that may look as presented in in figure , for a non-adaptable program.

 

Figure: Non-adaptable version of configBrowserCache  

Assuming that methods implemented by the object m_memory of the class Memory reads the size of the physical memory, the object m_harddisk of the class Harddisk reads the size of free disk space and the size of total disk space. The configuration of the browser is done by m_configuration of class Configuration. The objects m_memory, m_harddisk and m_configuration are member variables and therefore marked by convention with the prefix m_.

The classes Memory, Harddisk and Configuration or some of their methods must be implemented in different ways and using different technologies. E.g. for Linux the getPhysicalMemorySize() functions can be implemented in pure Java reading the text file meminfo in the /proc file system, in contrast to a Windows environment, where either a native diagnostic tool or a C function of the Win32 API must be used instead. The C functions can be embedded into the Java code by using the Java Native Interface (JNI) [#!Li1999!#].

Before the various aspects of adaptation are discussed, a short overview of adaptation will be presented in the following section.