Desarrollo sustentable

The previous section gave an overview of the most prevalent existing technologies that support application interface specification. From this presentation it is clear that all of the technologies discussed offer the means for distributed applications to describe an interface (and in particular their adaptation interface) through a predefined interface

definition language. Moreover, all technologies support the dynamic inspection of this interface and the dynamic invocation of methods exported through the interface.

As discussed in section 4.3, applications that communicate with the adaptation sup- port platform discussed here should also provide one additional feature through their interface specification, i.e. an adaptation interface specification should include human readable descriptions of the semantics of the interface. In more detail, an adaptation interface should offer mechanisms to allow the retrieval of textual descriptions of the application itself, the functionality implemented by the adaptation methods and the meaning of state variables reported by the application.

As seen in section 4.4.1, none of the existing technologies support this functionality by default. However, it is possible to use these technologies to support such a feature. In more detail, apart from the adaptation interface that applications expose, applications could be required to implement a description interface. A possible description interface for adaptive application is shown bellow:

interface I D e s c r i p t i o n

{

int G e t A p p D e s c r i p t i o n (out string s D e s c r i p t i o n ); int G e t M e t h o d D e s c r i p t i o n (in string sMethod ,

out string s D e s c r i p t i o n ); int G e t V a r D e s c r i p t i o n (in string sVarName ,

out string s D e s c r i p t i o n );

}

The methodGetAppDescription returns the description of the application,GetMethod- Descriptionreturns the description of the requested method and GetVarDescription re- turn the description of a variable defined in the application interface. This interface could be queried by a user support module in order to give human readable descriptions of the application’s interface.

A possible alternative approach can be applied in the case of an XML based inter- faces specification language, such as the one used by the Web Services architecture. One of the characteristics of XML is the fact that an existing XML language can be ex- tended with additional tags without breaking backwards compatibility. In more detail, a WSDL definition of a message sent to a web service has the following format:

<message name="SetBandwidth">

<part name="bandLimit" type="xsd:integer"/> </message>

Representing the invocation of the methodSetBandwidth(int bandLimit). Based on the backwards compatibility feature of XML it is possible to extend this definition with an additional tag without breaking the support for standard web service clients:

< definitions .... xmlns:ad="http: // www.comp.lancs.ac.uk/wsdl−adapt−schema/" /> ....

<message name="SetBandwidth">

<part name="bandLimit" type="xsd:integer"/> <ad:description>

Sets the upper bandwidth limit for the network traffic ... </ad:description>

</message>

With this definition the application can communicate with the platform using the standard Web Service infrastructure, while a user support module can query the appli- cation interface and present it to the user (possibly passing it through an XSL filter).

Summarising the discussion on existing technologies, it is clear that existing tech- nologies can support the requirements for interface definition for adaptive context-aware applications. In particular, the use of an XML based approach seems appealing as it al- lows a more elegant incorporation of user readable descriptions of the applications’ interfaces.

This design chapter does not make specific claims about the technologies that should be used for the communication between adaptive applications. Instead, in the following section we present a platform-independent interface description language that can either be used as it is or taken as a guideline for the implementation of a custom interface definition mechanism.

4.4.2.1 Service Interface Definition

According to the discussion in section 4.3, the features that the interface specification mechanism should have are:

• Allow dynamic inspection of the application’s interface.

• Allow dynamic invocation.

In this section we present an XML based interface description language that meets these requirements. In particular the application exports an XML document that is roughly divided into three parts (Figure 4.7)

The first part of the interface description includes application specific information. In particular, the interface defines the name of the applications as well as a unique id that allows the distinction between multiple instances of the same application. It is the application’s responsibility to make sure the id is unique among multiple instances of the application. This can be achieved trivially by creating an id using the current host’s MAC address and the process id of the running application.

The second part of the application’s interface specification involves the identifica- tion of all adaptation methods implemented by the application. The identification of the adaptation methods is indicated by a string representing the name of the adaptation method, and a set of parameters that can be passed as in or out arguments by the plat- form. This information can be used to construct the invocation event that will trigger the application to execute the requested adaptation method.

The third part of the application’s interface specification involves the identification of a set of state variables that represent the current state of the application. These state variables are identified by a name and a basic type such as integer, string, etc.

Each of these parts includes a<description>tag that provides a textual description of the interface’s semantics. Moreover, the definition of an adaptation method can in- clude the indication of related state variables that are affected by attributes passed by the invocation. This indication of a related state variable allows the identification of pos- sible dependencies between actions and state variable. Referring back to section 3.2.5, this dependency is an indication of the possible relationship between an actuator and a monitoring entity. This related variable specification can be used by the end user to help better understand the application’s behaviour and the dependencies of adaptation actions and state variables.

The interface description presented is intended to allow adaptive applications to ex- port their adaptive interface and allow the platform to control their adaptive behaviour. However, in a typical adaptive system in addition to the adaptive applications there are system monitoring components responsible for retrieving information about the sys- tem’s environment. For example, such monitoring components might include a network interface monitoring tool, a power monitoring tool or a location monitoring tool. Ex-

<?xml version="1.0" encoding="ISO−8859−1"?> <application> <name>WebBrowser</name> <uniqueId>1234</uniqueId> <description> ... </description> <methodList> <method> <name>SetBandwidth</name> <description> ... </description> < attributeList > < attribute > <name>bandLimit</name> <type>Integer</type> <relatedVariable>Bandwidth</relatedVariable> </ attribute > </ attributeList > </method> </methodList> < stateVariableList > <stateVariable> <name>Bandwidth</name> <type>Integer</type> <description> ... </description> </stateVariable> </ stateVariableList > </ application>

Figure 4.7: Sample XML description of an adaptive web browser

isting platforms supporting adaptive applications tend to incorporate such monitoring functionality within the platform itself [Noble98, Friday96]. In contrast, the platform presented here follows a different approach. In order to support extensibility of the sys- tem, monitoring components are treated as first class system components that collabo- rate with the platform to support application adaptation. The approach proposed by this design is for the same application interface mechanism to be used by both system mon- itoring components and applications. Although conceptually monitoring components are only sources of information while adaptive applications are receivers of adaptation triggering, the design of the adaptation platform does not make any distinctions between the two. The reason for such an approach is twofold:

• Monitoring components usually correspond to a specific device within the sys- tem. This means that they can support hardware specific adaptation. For example a component responsible for the wireless network card could set that card to sleep- ing mode when triggered.

• Application state variables can be useful for the controlling adaptation in other applications in the system. For example, the fact that a particular application is currently using the network may be an important factor for the adaptation policy of other applications in the system.

This design approach offers a greater level of flexibility in the design of an adaptation support platform. In particular, the platform can be extended with the incorporation of new monitoring tools as and when required. Moreover, adaptation policy rules can include information about both applications running in the system and monitoring tools and can trigger adaptation not only to adaptive applications but also to the system’s devices.

Summarising, the application interface that was discussed in this section is used by the platform for the registration of adaptive applications and system monitoring tools. This interface describes the state information offered by the application and the adaptive methods that can be invoked by the platform. Using this specification the platform constructs an application manager component that handles all communication with the application.