Content uploaded by Stefan Fischer
Author content
All content in this area was uploaded by Stefan Fischer on May 03, 2016
Content may be subject to copyright.
Towards Unmanaged Multimedia Adaptations using
Automated Aspect Weaving
Muhammad A. Khan
Institute of Operating Systems & Computer Networks
Technical University of Braunschweig
Germany
khan@ibr.cs.tu-bs.de
Stefan Fischer
Institute of Telematics
University of Luebeck
Germany
fischer@itm.uni-luebeck.de
Abstract—The goal of this research is to devise a new architecture for integrating aspect oriented methodologies
existing in the software engineering community to develop an Adaptive Composition and Runtime Environment
(ACRE) for unmanaged adaptation of multimedia applications. The architecture of ACRE presented in this paper can
transform non-adaptive applications by injecting adaptive behaviors into them and then execute them in a QoS-aware
manner. The integrated environment presented in this paper, works at the level of JVM and the underlying OS for
application transformation and adaptive resource handling. The proposed environment can be used to provide a
sufficient degree of user perceived QoS in smart home/ office environments, without programming adaptive behaviors
in the applications.
Keywords – Aspects, Middleware, Adaptation.
1. INTRODUCTION
The existing Quality of Service (QoS) API’s need expert knowledge to program adaptive behaviors into the
applications, whereas in the future environments (like smart home/office) computers are becoming ubiquitous, and we
are likely to see a significant increase in the number of computing devices with a correspondingly increasing number
of applications and distributed interactions. This will render the design of adaptive applications very complex and their
interactions un-manageable, especially when certain quality of service is required. Since it is not possible to have that
many human experts to cope with this situation, the solution lies in development of systems which require no or
minimal user involvement to adapt their functionality to varying operating environments.
2. BACKGROUND AND RELATED WORK
Adaptive mobile applications are generally built using two approaches; either the adaptation is performed by the
system which underpins the application or the application itself monitors and adapts to change [1]. These two
approaches differ from each other in the levels of efficiency and flexibility. Programming adaptive behaviors into
applications is more efficient, but is practically very cumbersome, it is difficult for the application designer to predict
the runtime behavior of an application and in particular, to estimate all possible scenarios which can occur at runtime
on a system-wide basis [2]. Handling the adaptation responsibility to the underlying system (usually middleware) is
less efficient but more flexible, since the application code does not need to explicitly handle adaptive behaviors. Most
of the recent research has benefited from the latter approach by using different techniques to develop QoS middleware,
among which are included Meta Object Protocols (MOPS) [8] for separation of concerns and behaviors [9], reflection
[5] [6] and Aspect oriented Programming [7]. A wealth of research is available in literature, mainly in the area of
adaptive, reflective and in particular aspect oriented middleware, where specific languages for describing QoS aspects
[11] have been developed, and existing middleware has been custom tailored to provide QoS [12]. A comprehensive
comparison of different aspect weavers and aspect oriented middleware is provided in [13]. While different aspect
oriented middleware systems have their own pros and cons, a commonality found in them is the assumption that, the
applications running on top of such systems are using the API’s provided by the middleware. The systems based on
this assumption give the benefit of interoperability, and will generally be capable of adapting a wide range of
applications, if aspects are directly woven into the application code, this will be more efficient and will be feasible if
adaptation is required for a specific class of applications and can be used to transform non-adaptive applications into
adaptive ones. An example of this is found in TRAP/J project [10]. While TRAP/J can be used as a tool to make
applications adaptive, this requires selecting classes to be adapted and defining adaptive behaviors for them. Our
approach can be seen as an example of the same principles, however, since it is in the context of a framework (Java
Media Framework : JMF), where the structure of applications is pre-defined, it gives us the benefit of specifying
adaptive concerns at a higher level of abstraction and system-wide manner in the form of profiles and makes the
adaptations more self-managed, at the cost of limiting the applicability to a specific framework.
Adaptation, in all its forms (software, resource or service), affects multiple elements of a system and has been
identified as a cross-cutting concern, particularly in the context of pervasive computing [3]. Because managing a
system’s quality of service in a dynamic, adaptive way requires knowledge of both the applications and infrastructure,
middleware is the proper place to insert it. This needs to be done statically as well as dynamically, since QoS
management will depend upon design, configuration, deployment and runtime information [4]. The system we are
describing in this paper is although not a full fledged middleware, it features static customization and adaptive
(re)configuration and execution of applications as well as adaptive resource management.
3. ARCHITECTURE & IMPLEMENTATION OF ACRE
We implemented our test system using Java Media Framework (JMF), which defines a number of interfaces
abstracting different media processing components and devices, found as hardware in real life. The main components
of the Adaptive Composition and Runtime Environment (ACRE) are shown in Fig1 and Fig 2.
Profiles are described in xml and each profile describes a set of possibilities specific to a particular system element,
however, all the possibilities cannot be realized in all situations. Application profile describes the application category
Network Profile
Aspect Engine
JMF API Provided Application Code
Aspectized Code
M
a
pi
n
g
In
tr.
Fig 1: Static Customization
Application Profile
….Others….
Device Profile
Resource Monitor / Manager
Battery Network CPU RAM
Adaptation Engine Comm. Interface
Aspectized Code
Fig 2 : Dynamic Reconfiguration
Adaptation Preferences
Operating Context
(streaming media, email, point to point video etc) and possible operating modes (e.g, if the application is capable of
rendering more than one video formats). It also specifies the application priority indicator for each application, which
is a numeric value used by the resource manager to distribute resources across different applications at application
start-up time and then re-distribute during execution. The Network profile describes the types of network (e.g; LAN,
WLAN, GSM/GPRS) across which an application may switch during its life. This determines how expensive an
adaptation would be (since different networks may have different charging policies; connection-time based, amount of
data transmitted based or free of charge). The system can be extended to incorporate any other profiles.
The Mapping Interface maps these system-wide concerns onto provided application(s). Conflicting adaptation
requirements may arise when the user specified adaptation preferences to be taken into account at runtime, cannot be
realized by the possible reconfigurations mapped onto the code. In real implementation it means non-existence of
certain “adaptation hook” in the aspectized code to which an advice could be attached. The aspectized code produced
statically is reconfigured at runtime, taking into account adaptation preferences and checking the operating context of
the application. The differences between profiles used during static customization and adaptation preferences used at
runtime is that the profiles describe the ‘possibilities’ while the adaptation preferences are the user’s adaptation
requirements, all of which may or may not be realizable.
In actual implementation, adaptation requirements are translated onto different plug-ins of the JMF. Therefore the
process of mapping different profiles and preferences to make applications adaptive is effectively a two step process.
In the first step, aspects are generated from profiles and are woven across different plug-ins constituting a JMF
application. In the second step, adaptation preferences dynamically reconfigure the plug-ins. For example, normal
codecs are made rate-adaptive by inserting mechanism for frame dropping and adaptive bit-rate control, special effects
like converting a colored image to grey scale are adaptive enabled/disabled at runtime, while insertion of hooks takes
place statically. This reconfiguration of media processing elements facilitates fine-grain adaptation and management of
complete RTP sessions. In our test system, a receiver is always an ‘adaptation slave’ while the sender is the master, i-
e; if the adaptation is to be invoked because, only the receiver needs it (e.g, because of the low battery level or cpu
power dropping which are device-owned resources), it can send a request to the sender, and wait for the
acknowledgement of the adaptation request, however, if the sender wants to adapt, it will check the receiver but, does
not need to wait for the acknowledgement (it has the system state information). Our implementation benefits from
adaptation and resource management at two levels: adaptations inside the JVM and resource distribution at the
operating system level. In our test system, in addition to JVM, we are using linux virtual machines for resource
monitoring and (re)distribution among the applications.
4. CONCLUSIONS & OUTLOOK
0
10
20
30
40
50
60
70
80
90
1 2 3 4 5 6 7 8 9 101112131415161718192021222324252627282930313233343536373839404142
Time Points
CPU Load
0
1
2
3
4
5
6
7
8
9
10
% Packet Loss
Server CPU Load
Client CPU Load
% Packet Loss
Fig 3 : Sample Adaptation w.r.t bandwidth variations
The implementation was tested to adapt a pre-written (non-adaptive) video conferencing application transmitting
H.263 coded CIF size frames in WLAN, to adapt to bandwidth variations. The results are shown in the Fig 3.The
application was configured to adapt down (decrease frame rate) and adapt up (increase frame rate) according to the
two threshold values (arbitrarily set). As an example of adaptation policy in this case, reaching the upper threshold
value of percentage packet loss triggers the ‘adapt-down’ behavior, while staying in the ‘adapt-down state’ for five
consecutive time-points triggers the ‘adapt-up’ behavior. In Fig 3, ‘adapt-down’ is invoked at time-point 13, upon
crossing the threshold of 5% loss, and again at time-point 25, while ‘adapt-up’ is invoked at after 5 stable time-points
at 30.
In our current implementation, the ‘operating context’ shown in Fig 2, is limited to smart home WLAN, but will be
expanded to other environments in future. While the proposed environment facilitates adaptations with minimal user
involvement, the applicability is limited to applications written using JMF API. In our current implementation, the
adaptation policy is programmed statically in the Adaptation Engine. In order to make it more flexible, we are
implementing it in a more dynamic way, so that the current limitation is removed by remotely updateable policy. This
will entail investigating a compromise between the distribution of control between the user preferences and
administratively updatable adaptation policy, such that the system as a whole still relies on minimal user involvement,
while resorting very little to some sort of administrator for updateable adaptation policy. This will be a very limited
compromise on autonomy of the system, thus keeping it significantly distinguished from other approaches requiring
the user to program adaptation behaviors, while offering comparable flexibility.
REFERENCES
[1] C. Efstratiou, K. Cheverst, N. Davies and A. Friday, “Architectural Requirements for the Effective Support of
Adaptive Mobile Applications”, Middleware 2000.
[2] M. A. Khan and S. Fischer, “A Reflective Runtime Environment for Dynamic Adaptation of Streaming Media on
Resource Constrained Devices”, (HICSS-38), 2005.
[3] A. Rashid and G. Kortuem, “Adaptation as an Aspect in Pervasive Computing”, Workshop on Building Software
for Pervasive Computing, (OOPSLA 2004)
[4] G. Duzan, J. Loyall, R. Schantz, R. Shapiro and J. Zinky, “Building Adaptive Distributed Applications with
Middleware and Aspects”, (AOSD 2004).
[5] G. Blair, G. Coulson, N. Davies, P. Robin and T. Fitzpatrick, “Adaptive Middleware for mobile Multimedia
Application”, (NOSDAV, 1997)
[6] David, P.C., Ledoux, T., Bouraqadi-Saadani, M.N., “Two-step Weaving with Reflection using AspectJ”,
(OOPSLA 2001)
[7] G. Kiczales et al, “Aspect Oriented Programming”, (ECOOP 1997)
[8] G. Kiczales, J. Rivieres and D. Bobrow, “The Art of Metaobject Protocols”, MIT Press, 1992
[9] A. Oliva and L. E. Buzato, “Composition of Metaobjects in Guarana”, (COOTS 1999).
[10] S. M. Sadjadi, P. K. McKinley, B. H. C. Cheng and R. E. K. Stirewalt, “TRAP/J: Transparent Generation of
Adaptable Java Programs”, (DOA-2004)
[11] J. P. Loyall et al, “QoS Aspect Languages and Their Runtime Integration”, 4th Workshop on Languages,
Compilers, and Run-time Systems for Scalable Computers, 1998.
[12] N. Wang et al, “Total Quality of Service Provisioning in Middleware and Applications”, The Journal of
Microprocessors and Microsystems, Elsevier, vol. 26, number 9-10, January 2003.
[13] N. Loughran et al, “Survey of Aspect-oriented Middleware”, http://www.comp.lancs.ac.uk/computing/aop/
