CHAMELEON framework

CHAMELEON framework

CHAMELEON allows the development and deployment of Java applications that, via the different adaptation alternatives (i.e., different implementations), are generic and can be correctly adapted with respect to a dynamically provided execution context. A complete description of the CHAMELEON Framework can be found in [PhDThesis'10 - A Framework For Context Aware Adaptable Software Applications And Services ]. The figure below shows the framework architecture.

• The Programming Model is the basis for the CHAMELEON Development Environment ( download the Development Environment Eclipse plug-in ). It is a standard Java development environment that provides developers with a set of ad-hoc extensions to Java for easily specifying, in a flexible and declarative way, the generic code (Please refer to [PhDThesis'10]). Methods are the smallest building blocks that can be adapted. Below we show a snippet of a simple adaptable MIDlet for consuming an e-learning service.

  
  adaptable public class e-learningMidlet extends MIDlet
                              implements CommandListener {
      State state;
  
      public e-learningMidlet(){...}
  
      /* Life-cycle management methods */
      protected void pauseApp(){...}
      protected void startApp(){...}
      protected void destroyApp(){...}
  
      /* State management methods */
      adaptable protected void saveState();
      adaptable protected void restoreState();
  
      /* e-Learning specific methods */
      adaptable void connect();
      adaptable void getLesson();
      ...
  }
  
  //----------------------------------------------------------
  
  alternative class GPRS adapts e-learningMidlet {
  
      void connect() {
          Annotation.slsAnnotation("Cost(low),e-lQuality(low)");
          Middleware.connectViaGPRS();
      }
  
      void getLesson() { /* streaming of the lesson slides */ }
  
      protected void saveState() { ... /* save into the state the
                            number of the current slide */ ...}
  
      protected void restoreState() { ... /* restore the saved state */}
  }
  
  //-----------------------------------------------------------
  
  alternative class WiFi adapts e-learningMidlet {
  
      void connect() {
        Annotation.slsAnnotation("Cost(high),e-lQuality(high)");
        Middleware.connectViaWiFi();
      }
  
      void getLesson() { /* streaming of the video lesson
                          with its multimedia content */
          Annotation.resourceAnnotation("Battery(high)");
          ...
      }
  
      protected void saveState() { ... /* save into the state the
                     current frame of the video lesson */ ...}
  
      protected void restoreState() { ... /* restore the saved state */}
  }
  
  


The adaptable class e-learningMidlet contains four adaptable methods: connect, getLesson, saveState and restoreState (bearing the keyword adaptable). Adaptable methods do not have a definition in the adaptable class where they are declared but they are defined within adaptation alternatives (see the keywords alternative and adapts). It is possible to specify more than one alternative for a given adaptable class provided that for each adaptable method there exists at least one alternative that contains a definition for it. Such a generic code will be preprocessed and a set of standard Java application alternatives will be derived by suitably combining the adaptable methods implementations provided in the various alternatives. These are then compiled using standard Java compilers.
The CHAMELEON framework is used to adapt the e-learning service according to the execution- and network-context of the student mobile device and to his/her requested SLS (see below). In particular, the adaptable e-learningMidlet has two alternatives, each one providing implementation for all the adaptable methods. The GPRS alternative connects via GPRS and, considering the limited speed of this connection, allows for streaming (via the getLesson method) the lesson slides only. The WiFi alternative connects via WiFi and, exploiting the higher connection speed, allows for streaming the high-quality video lesson with all its multimedia content (slides plus other interactive multimedia objects). Upon student request of the e-learning service, the suitable Midlet alternative for consuming such a service will be delivered and deployed on the device with an On-The-Fly fashion by using our suitable implementation of the Over-The-Air (OTA) provisioning technique for automatic delivery and deployment of adapted applications.
Annotations may also add information about particular code instructions (see the keyword Annotation). They are specified at the generic code level by means of calls to the ``do nothing'' methods of the dedicated Annotation class. In this way, after compilation, annotations are encoded in the bytecode through well recognizable method calls to allow for easy processing. For instance, the method call Annotation.slsAnnotation("Cost(high), e-lQuality(high)"), first line of the connect method in the WiFi alternative, specifies that the WiFi connection, and hence the WiFi alternative, bears a high cost, but provides a high quality e-learning lesson. On the other hand, the method call Annotation.resourceAnnotation("Battery(high)"), first line of the getLesson method, demands for a high battery state-of-charge, since the streaming of the video lesson along with its multimedia content calls for a considerable amount of energy to be consumed.

• The Resource Model is a formal model that allows the characterization of the computational resources demanded by an application an supplied by and execution context. The Resource Model, enables the framework to reason on the set of adaptation alternatives and allows it to decide the ``best-fit'', depending on execution context information.
  
  Resource Definition:

  
  defineRES Battery as {low,medium,high}
  defineRES WiFi as Boolean
  defineRES WiFiNet as Boolean
  defineRES GPRS as Boolean
  defineRES GPRSNet as Boolean
  

  Resource Sets:

  DemandGPRS = {GPRS(true), GPRSNet(true)};
  DemandWiFi = {WiFi(true), 
                WiFiNet(true), Battery(high)};
  
  Supply 1 = {GPRS(true), WiFi(true), GPRSNet(true), 
  	     WiFiNet(false), Battery(low)};
  Supply 2 = {GPRS(true), WiFi(true), GPRSNet(true), 
  	     WiFiNet(true), Battery(high)};
  
  

  Broadly speaking a resource is any item that is required to accomplish an activity or complete a task. Some resources are subject to consumption (e.g., energy, heap space), while others, if present, are never exhausted (e.g., function libraries, network radio interfaces). Thus, we model a resource as a typed identifier that can be associated to Natural, Boolean or Enumerated values. Natural values are used for consumable resources whose availability varies during execution. Boolean values define resources that can be present or not (i.e. non-consumable ones). Enumerated values can define non-consumable resources that provide a restricted set of admissible values (e.g. screen resolution, network type). Above we show an example of some resource definitions. A resource instance is an association res(val) where a resource res is coupled to its value val in typeof(res) (e.g. WiFi(true)). A resource set is a set of resource instances with no resource occurring more than once. It is used to specify both the resource demand of an alternative and the resource supply of an execution environment.
  Please refer to [PhDThesis'10,CAMPUS'08,FASE'09,TechRep10] (and references therein) for more details.
• The SLS Model is a formal model that allows the specification of extra-functional preferences. Together with the Resource Model, the SLS Model enables the framework to choose the ``best'' adaptation alternative depending on both execution context information and consumer specific preferences. This model bases itself around the same formalisms as the Resource Model.
  
  SLS Definition:

  
  defineSLS Cost as {low, high};
  defineSLS e-lQuality as {low, high};
  

  SLS Sets:

  SLSGPRS = {Cost(low), e-lQuality(low)};
  SLSWiFi = {Cost(high), e-lQuality(high)};
  
  

  Please refer to [PhDThesis'10,08">CAMPUS'08,FASE'09,TechRep10] (and references therein) for more details.
• The Abstract Resource Analyzer (ARA) ( download the Abstract Resource Analyzer ) is an interpreter that, abstracting a standard JVM, is able to analyze Java applications and derive their resource consumption also deriving, if specified, the SLSs. ARA is parametric with respect to the characteristics of the execution environment as described through a resource consumptions profile that expresses the impact that computational elements (i.e., the Java Bytecode Language instructions) have on resources (see also the Execution Environment below). Specifically, resource consumption profiles associate resources consumption to particular patterns of Java bytecode instructions specified by means of regular expressions. Basically, we can look at ARA as a function that takes as input a Java application's bytecode, a resource consumption profile and gives as output a resource set that represents the resource demand of the application, and (optionally) an SLS set that represents the offered SLS (i.e., the resources needed for that program to be safely executed by the target execution environment with the offered SLS). Note that the same bytecode instruction impact depends on the execution environment, since the same bytecode instruction may require different resources in different execution environments.
  
  Please refer to [PhDThesis'10,CAMPUS'08,FASE'09,TechRep10] (and references therein) for more details.
• The ExecutionEnvironment can be any device that will host the execution of the code. We target execution environments provided by PDAs, smart phones, etc. The execution environment is not strictly part of our framework, however, it has to provide a declarative description of the resources it makes available to consume/provide the service (i.e., the resource supply) and the resource consumption profile. In other words, it has to be a CHAMELEON-enabled device running a Client-side CHAMELEON component that is able to communicate with a Server-side CHAMELEON component.
  ( download the Client-side and Server-side CHAMELEON components )
  
  Please refer to [PhDThesis'10,CAMPUS'08,FASE'09,TechRep10] (and references therein) for more details.
• The Customizer takes in the resource supply, the provided profile, explores the possible adaptation alternatives' space and, according to compatibility and goodness (see Resource and SLS Models above), decides the actual best alternative. It will deliver standard bytecode via Over-The-Air (OTA) delivering.
  
  Please refer to [PhDThesis'10,CAMPUS'08,FASE'09,TechRep10] (and references therein) for more details.

CHAMELEON has been fully implemented in Java (although other languages are eligible) and uses XML-based data encoding for the Resource and SLS Models. It is worth mentioning that, even though both the ARA and the Customizer could be space and time consuming, they are executed on the server-side of the framework which should not suffer resource limitations.

Paola ::©www.di.univaq.it/inverard
Marco ::©www.di.univaq.it/marco.autili
Paolo ::©www.di.univaq.it/paolo.dibenedetto
::last modified: --\--\--