Rule Based Context Awareness - Proposal 1

In order to achieve a good level of scalability and flexibility a rule based context awareness can be useful. The idea is to realize the implementation profiles including the association, generating and matching function as rules.

The adaptation obtains the rules as initialization parameter. On every host the rules are interpreted by the adaptation mechanism of the agent and the names of the fitting implementation classes are resolved. For the example of the browser configuration, the rules could look like in figure .

 

Figure: Example for context awareness rules  

The section variables defines the profile values of the environment which are used and the functions which are executed to retrieve the profile values from the system. It implements the generating function of the profile values. The definition of predicates provides the generalization of values, e.g.  unix :=OS in {Linux,AIX}. This is the realization of the matching function. The association function is defined in the section matching. The matching section declares the matching function for every implementation class. The implementation classes behind the arrow in the matching section are suitable, when the evaluation of their expression returns true. The association function is basically realized by logical operators and, or and not.

The application programmer must define the rules for every implementation group. In figure the rules for the implementation group IConfiguration are shown. If the adaptation wants to load the suitable implementation class specifying the functionality interface, all expressions of the implementation group in the section matching are evaluated. The implementation class is selected from the group whose expression returns true.

On a host running an UNIX operating system, with Netscape as default browser, the expression of Configuration_UX_NETSCAPE will return true and the resting expressions of the group return false. In this case the context awareness decides that Configuration_UX_NETSCAPE is the right implementation class.

If none of the implementation classes can be chosen, a runtime error is reported by the context awareness to the mobile code, that a class can not be found. If a new operating system, and a suitable implementation class is added to the system, the rules must be extended by a new predicate and an expression for the new implementation class.

The quality of this approach is strongly dependent on the semantic power of the rule language. If it is only a simple language, like in the example shown above, a small number of environments can be described only. The introduction of an additional language - if the rules are considered as a new language - conflicts with the requirement R1 which does not allow an additional language to the programming language of the mobile code.

The advantage of this technique is the open context awareness which is able to interpret every definition of new profile values or even implementation classes during runtime. If the mobile code does not rely on a static set of rules, but loads the current rules for every adaptation, it is possible to introduce new implementation classes into the system without termination of the core or rewriting of the adaptation mechanism.

If the number of implementation classes increases dramatically, a graphical editor could support the administration of the rule file. The price of these advantages is the loose coupling between the rules and the implementation classes, which is a violation of requirement R3, because the rules are totally independent from the mobile code and changes in the implementation require updating the rules in order to avoid inconsistency. Faults can occur very easily, if the consistency between rules and implementation classes is not checked.

Another approach is the introduction of a component model similar to Java Beans [#!Eng1997!#]. This concept is explained in more detail in the following section.