With each implementation class exactly one implementation profile is associated, which is specified and implemented by the component developer. This profile is loaded and executed in the current environment where the mobile agent is running. The result of the execution of an implementation profile is an environment profile which can be used to decide which implementation class can be used in the detected environment.
It is important to realize that profile information, while strictly belonging to implementation classes, should be kept apart from them in terms of object structure, because of the stages involved in the decisions taken during the adaptation process: Profiles have to be aquired at a new site, in order to determine whether implementation classes have to be brought in as well. Hence the profiles act like (small) probes that precede (optional) migration of (larger) implementation classes over the network as the mobile agent moves between different hosts.
The implementation profile includes placeholders profile values and code to calculate their values. Profile values stand for particular characteristics, such as installed operating system or available memory size. The profile value includes methods to inspect the environment accordingly. We call this code generating function. To compare profile values with the value requested by the implementation class, we use other methods and call them matching functions, which are also part of the implementation profile. Alternativelly, this metric can be aligned with normal object comparison semantics, by overriding a programming language's intrinsic comparators, such as equals in the case of Java-based profiles.
For instance an implementation class which has the functionality to configure Netscape running on an Intel-based processor with Windows 2000 would have an implementation profile as shown in Fig. 5. It may not be obvious why the configuration of a web browser, for instance, should depend on the CPU architecture. We use this particular relationship to exemplify cases where a configuration decision may depend on the result of a local benchmark (e.g. choose larger cache if network connecetivity is slow), and the benchmark in turn involves such particular dependencies as upon CPU-architecure.
Continuing with the above example, this would generate the environment profile values for the environment through the generating function as shown in Fig. 6 if executed on a PowerPC running AIX and Netscape as default web browser.
After comparing the profile values of the implementation class and the profile values of the environment the context awareness tool may conclude in this case that the implementation class Configuration_X86_WINNT_NETSCAPE is not suitable for the environment because the CPU architecture and the operation system does not match closely enough. Hence the profile of another implementation which implements the same functionality interface must be located in another iteration.
This is a very simple but instructive example. The profile values in the example are attributes which can be deduced relatively easily. The generating function can be simple too, such as comprising a call to System.getProperty("os.name") in Java. However, the concept is also useful for more complicated configuration tasks. An adaptable agent configuring e.g. a SAP e-business application may need implementation profiles including ABAP calls to determine specific SAP parameters.