Download - MOBILE CONTEXT AWARE APPLICATION
-
8/3/2019 MOBILE CONTEXT AWARE APPLICATION
1/11
MOBILE CONTEXT AWARE APPLICATION
Rafat A. AL-msiedeen
1. Introduction: ....................................................................................................................1
1.1What is Mobile Computing?.......................................................................................2
1.2The Need for Dependability:......................................................................................2
1.3The Need for Adaptability:.........................................................................................31.4New Environment, New Features:..............................................................................3
1.5Infrastructural Requirements:.....................................................................................3
1.6Context:.......................................................................................................................3
1.7Adaptation and Adaptability:......................................................................................41.8Functionality Adaptation:...........................................................................................5
1.9A Definition of Contextual Services:..........................................................................51.10Software Product Line Architecture:........................................................................6
1.10.1Mobile PLA Design Rules:................................................................................7
1.10.2Challenges of Automated Variant Selection For Mobile Devices:....................7
1.10.3Architecture for Over-the-Air Provisioning from a Product Line:....................81.10.3.1Scatter Model:.................................................................................................8
1.10.3.2Obtaining the Device Information Required to Make Reuse Decisions:........8
1.10.3.3Pull Models for Discovering Device Capabilities:.........................................81.10.3.4Push Model for Discovering Device Capabilities:..........................................9
1.10.3.5On-Demand Probing: A Hybrid Capability Discovery Model:......................91.11The OMG CORBA Component Model:...................................................................91.12Framework of Component-based Mobile Web Application Development:...........10
1.13References: .............................................................................................................10
1. Introduction:
3G network is sweeping the world in a large-scale swiftly, following by an increasingrequirement of mobile application by business and consumer. With the raising number of
smart phone users in developed countries and infrastructure construction for
communication networks in developing countries, the numbers of worldwide usingmobile phones will increased with the time. With the coming of third generation mobile
communication networks, as well as the popularity of smart phones, mobile phone are
changing from simple voice communication tools to multi-media data communicationand mobile internet devices. With the popularity of smart phone, it is a trend to develop
application on mobile phone, but now the biggest challenge is that there are various kinds
of operating system without uniform standards [1].
1
mailto:[email protected]:[email protected] -
8/3/2019 MOBILE CONTEXT AWARE APPLICATION
2/11
All things are affected by change. This is especially true for mobilecomputing environments. Everything, from devices used, resourcesavailable, network bandwidths to user contexts, can change drasticallyat run-time. It therefore becomes imperative for software systems and
applications to be able to adapt to these changes in order to provide asuitable and relatively stable working environment for users [2].
The key property of computing services is their correctness, and theimportant property related to correctness is robustness. Anotherfundamental property for computing services is dependability; thedependability is a key requirement of software components and that,in order to make truly computer-based services, it is important toenhance the dependability of the corresponding software programs [3].
The feature models are designed to show the composition rules for the variable
application components and how device capabilities affect what applications can bedeployed. The feature model characterize based on function and non-functionalvariabilities. Developers must consider both functional capabilities such as: the optional
libraries installed on the device, and non-functional capabilities such as: total memory,
when reusing software components [4].
1.1 What is Mobile Computing?
Mobility can be seen in two dimensions, one dimension is devicemobility: a user carrying out his tasks on a device while moving about,
taking advantage of wireless connections. The other dimension is usermobility: allowing users to move from one device to another still beingable to carry out their tasks access their information and continuewhere they left off. Data mobility and code mobility are sometechniques which can be employed to achieve user and devicemobility. The Mobile computing is the use of mobile devices and not-so-mobile devices, taking advantage of wireless means, to create aseamless computing environment enabling access of information,computation and co-operation [2].
1.2 The Need for Dependability:
The need for dependable computer systems is especially evident whenconsidering the tremendous growth in both the complexity and crucialcharacter of roles nowadays assigned to computer. The overwhelminggrowth in computer performance and ease to use experienced ledsociety to depend more and more on services supplied by computerssuch as: health care, airborne equipment, public administration,transportation, communication. The criticality associated with many
2
-
8/3/2019 MOBILE CONTEXT AWARE APPLICATION
3/11
tasks nowadays appointed to computer does require a huge degree ofdependability. The awareness of this fact (dependability) becomeswidespread, as can be proven by recalling the attention of the public tothe so-called Millennium Bug problem [3].
1.3 The Need for Adaptability:
The growth in performance and ease to use ultimately led to an urgentneed for dependability. The advent of mobile computing is to prompt anumber of new requirements for the programs appointed to supplymobile services; the role of the environment is central one in them.The key idea is that, while in the past each application component wasconceived, designed and implemented having a fixed scenario ofenvironmental conditions that could only vary under exceptionalcircumstances [3].
1.4 New Environment, New Features:
The mobile computing environment is very different from thetraditional networked environment. The essential features anddemands, which set themobile computing environment apart, include:device heterogeneity, device resource limitation, network bandwidthlimitations and instability, high mobility, context awareness, andproximity interactions [2].
1.5 Infrastructural Requirements:
Current computing infrastructure and architectural models areinadequate to provide for the new features of mobile computing. Someof these requirements include: location tracking, data delivery andsynchronization: mobile networking, ad-hoc networking, contextdetermination and dissemination, and support for adaption [2].
1.6 Context:
The context it is the circumstances that form the setting for an event, statement, or idea.
The context divided into four categories include: computing context, user context,
physical context, and time context. Also the contextual changes are categorized into fourtypes include: device resources, network properties, environmental context, and user
preferences [2].
The mobile computing environment is characterized by variation. It is marked by the use
of a wide range of devices and technologies. There is no universal device, network
characteristic or configuration. Such variation and change can be broadly classified alongthe following axes: (1) Device and run-time resources; mobile devices have different
3
-
8/3/2019 MOBILE CONTEXT AWARE APPLICATION
4/11
-
8/3/2019 MOBILE CONTEXT AWARE APPLICATION
5/11
adaptation involves changing the data in some manner, such as changing the quality of
the data accessed, transforming data to a more appropriate form, accessing a different set
of data altogether. (2) Network level adaptation; this involves the change of network levelparameters. This can be done in many ways, for example, by using different protocols,
adapting routing information, changing the rate of transmission, network level QoS
management. (3) Energy adaptation; this involves using techniques which change theamount of energy consumed, either by turning the power off or moving to a less energy-
consuming. Many of techniques are hardware related. (4) Migration adaptation; this
involves changing the location of execution, for example, by moving to another machinewith more resources. This is often used in the field of distributed computing and mobile
agents, whereas in the field of mobile computing, it is still rare or under development.
Migration adaptation can be advantageous in a mobile environment. (5) Functionality
adaptation; this involves changing the way an application carries out its functionality.Application in a mobile environment can be seen as fulfilling certain tasks. Functionality
adaptation implies carrying out the same task but in a different manner, either by using a
different mechanism, different algorithm, a different QoS characteristic, or by switching
to another execution mode. It involves changing the execution of the task [2].
1.8 Functionality Adaptation:
Functionality adaptation is probably the most versatile and the least explored of the five
adaptation categories. In a mobile environment, user interaction can be seen as usersperforming certain tasks. Functionality adaptation involves changing the way the task is
carried out in order to respond to the changes in the mobile execution environment or
context. Functionality adaptation involves changing the execution of the application.Functionality adaptation is, in fact, a very powerful tool. If implemented appropriately, it
can be a comprehensive technique which has the potential for enhancing an applications
or a systems adaptability to a very wide range of factors, including network bandwidth,device resource availability, and environmental context. Functionality adaptation occursin programs targeting the mobile computing environment. Reconfiguration is carried out
in response to change in the run-time environment or context. The main purpose for
reconfiguration is adaptation. Methods for achieving functionality adaptation may be ableto learn from some techniques used in dynamic reconfiguration [2].
1.9 A Definition of Contextual Services:
Contextual Mobile Services have a particular behavior. They are available into a well
known place when users are outside of this place; the services are not presented and can
not be used. Next, when users enter into the place, the infrastructure must show them theservices which can be used on their terminals. When users choose a particular service, the
mobile part must be deployed and instantiated on their terminals, so that it can be used.Finally, when users move outside of the network cover zone, the services can not be used.
The contextual services challenges include: heterogeneity of devices, low resources,
distributed applications, service discovery, and service deployment. Ubiquitous andcontext aware applications are one of the new challenges in distributed computing area
[5].
5
-
8/3/2019 MOBILE CONTEXT AWARE APPLICATION
6/11
Figure_1.1: The life cycle of ubiquitous contextual services [5].
1.10 Software Product Line Architecture:
The Product line architectures are an effective mechanism for facilitating the reuse of
software components on different mobile devices. Mobile applications are typicallydelivered to devices using over-the-air provisioning services that allow a mobile phone to
download and install software over a cellular network connection. A product-line
documents the rules that a developer must follow when assembling existing reusable
software components into an application for a new mobile device [4].
Despite the advances in middleware and deployment technologies, there are stillsignificant variabilities between devices in terms of: hardware resources, middlewareversions, hardware capabilities, and service provider restrictions [4].
The design of PLA is typically guided by scope, commonality, and variability (SCV)analysis. The SCV captures key characteristics of software product-lines, including:
scope, which defines the domains and context of the PLA, commonalities, which describe
the attributes that recur across all members of the family of products, and variabilities,which describe the attributes unique to the different members of the family of products
[4].
Product-line architectures are a promising approach to help developers reduce the highcost of mobile application development by facilitating software reuse. And it is leverages
a set of reusable software components that can be composed in different configurations
for different requirement sets. The Constructing of product-line variant consists offinding a way of reusing and composing the product-lines components to create
functional application. A product-line documents the rules that a developer must follow
when assembling existing reusable software components into an application for a newmobile device [4].
6
-
8/3/2019 MOBILE CONTEXT AWARE APPLICATION
7/11
The care was needed when designing a product-line to achieve good constraint solving
performance. The several widely applicable rules, such as grouping components into asets based on limitations in packaging variability, could help ensure best-case solving
performance [4].
1.10.1 Mobile PLA Design Rules:
(1)Maximize Variant Selection Result Caching; if a product-line is designed carefully, aprovisioning server can cache the results of variant selection requests to greatly improve
the performance of provisioning. (2)Limit the Situations Where Resource Constraints
Must be Considered; resource constraint also can limit what the server can cache and arethe most time consuming component of variant selection. (3)Filter out Non-Essential
Resource Consumptive Components; due to the increased cost of finding a variant for
small devices where resources are more limited, to decrease the difficulty of finding a
deployment on small devices, PLA developers should provide non-local-functional
constraints to immediately filter out unessential resource consumptive components whenthe resource requirements of the deployable components greatly exceed the available
resources on the device. (4)Exploit Non-Functional Requirements; non-functionalrequirements can be used to further increase the performance of product-line. Each
component with an unmet non-functional requirement is completely eliminated from
consideration. (5)Prune using low-granularity requirements; the requirements with thelowest granularity filter the largest numbers of variants. (6)Create Service Classes;
another effective mechanism for pruning the solution space with non-functional
requirements is to provide various classes of service that divide the components intobroad categories [4].
1.10.2 Challenges of Automated Variant Selection For Mobile Devices:
(1) There is no clear architecture for automatically discovering and mapping device
capabilities to product-line models; numerous tools and approaches have been developedto capture the rules for composing a product variant. An over-the-air provisioning request
begins by a mobile device sending a request to a provisioning server that include a unique
identifier for the device type, form this unique identifier, the provisioning server must be
able to find the capabilities associated with the device and automatically map thesecapabilities into the model of the target infrastructure. (2) There is no documented
architecture for handling incomplete context information and unknown device types. (3)
There is no method for incorporating resource constraints in variant selection; multiple
models and tools are available for deriving ways of reusing and assembling componentsfor a set of device capabilities, none of these techniques or tools addresses how resource
constraints are considered in the selection process. For mobile device, resourceconstraints are a major concern and must be considered carefully. (4) It is unclear if
automated variant selection can be performed fast enough to support on-demand software
reuse. Determining which components to reuse and how to assemble them must happen
rapidly. (5) There are no documented design rules for facilitating variant selection
7
-
8/3/2019 MOBILE CONTEXT AWARE APPLICATION
8/11
automation. For developers of product-lines it is important to have guidelines for
designing a product-lines composition rules to avoid the worst case scenarios [4].
1.10.3 Architecture for Over-the-Air Provisioning from a Product Line:
The services that allow software to be downloaded over cellular networks are calledOver_the_Air Provisioning. Over-the-air provisioning is typically initiated by a mobile
user dialing a specified mobile number or sending an HTTP request to a provisioningserver. In most scenarios, the provisioning request includes an identifier that the server
uses to determine the type of device issuing the provisioning request and the requesting
devices capabilities. The capabilities of the device are used to help determine what
components are compatible with the device and should be used to assemble a variant tofulfill the request. Once a mobile device has initiated a provisioning request, the devices
functional properties and non-functional properties must be obtained and mapped to the
target infrastructure model of the product-line. Product-line architectures can be used todescribe the rules for reusing software components on different mobile devices [4].
1.10.3.1 Scatter Model:
Graphical Modeling tool for capturing the SCV of a product-line, compiling the product-
line rules into a constraint satisfaction problem [CSP], and using a constraint solver toderive a valid product variant for a mobile device. Researchers developed a tool called
scatter the first captures the requirements of a PLA and the resource of a mobile devices
and then quickly construct a custom variant from a PLA for the devices [4].
1.10.3.2 Obtaining the Device Information Required to Make Reuse Decisions:
The first step in determining how to fulfill a provisioning request using existing software
components is to characterize the unique capabilities of the requesting mobile device.After these capabilities are known, compatible components can be selected and reused in
a product variant. Each reusable component can have an expression associated with it
based on name/value pairs that determine if it can be reused in a particular device. Thevalues of these variables are typically determined using either a Push or Pull architecture
[4].
1.10.3.3 Pull Models for Discovering Device Capabilities:
A pull model extracts device capabilities from device description repository and can provide detailed information with regard to static device capabilities ranging from
supported APIs to hardware specifications. A mobile device may not able to
introspectively determine all of the information available in a device description
repository nor may it be efficient to send this large amount of data across a cellularnetwork. The Pull model does not require error-prone or user-interaction. The
provisioning servers main task is to identify the identifier for the type of device issuing
the request and then query the appropriate device description repository for its
8
-
8/3/2019 MOBILE CONTEXT AWARE APPLICATION
9/11
capabilities. The provisioning server having a large database of device capabilities may
appear to make it possible to build variants for device ahead of time. Device description
repository only contains static capability information and cannot leverage context ordynamic information about a device. The key disadvantage of pull models is that they
limit the information that can be used to guide variant construction since they rely on pre-
compiled device information database. New device are released frequently and thus arepository may not know the capabilities of the latest products. Pre-complied database
also cannot use dynamic information, specific to an individual users device. In situations
where not all required device information is available, the variant selection process facesa challenge which involves handling missing capability information [4].
1.10.3.4 Push Model for Discovering Device Capabilities:
Push model offer an apparent solution to the deficiencies of Pull Model. With a push
model, the mobile device encodes all required capabilities and context information for
deriving a product variant into its provisioning request. The push model can also
incorporate context-dependent data. The push model has its own drawbacks, first, thepush model relies on the user to supply critical information that is used to select product
variant and the user can easily make mistakes, the push model also requires sendingdevice capabilities across the network even though they do not vary across a particular
device model [4]s.
1.10.3.5 On-Demand Probing: A Hybrid Capability Discovery Model:
Integrating Scatter with a provisioning server created the unique challenge that the deviceinformation required to perform variant selection could vary depending on the constraints
of the product-line. The Scatter integration needed to support context information that
would not be available with a Pull Model. On-demand probing uses a device descriptionrepository to obtain static capabilities. If a product-line includes constraints on
capabilities that are unavailable from the repository, Scatter returns a small MIDlet to the
device. On-demand probing combines the best attributes of both the Push and PullModels. The on-demand robbing approach minimizes human interaction and can obtain
dynamics context information for product variant derivation. Resource constraints are a
key difference that makes the selection of software for a device more challenging that
adapting content [4].
1.11 The OMG CORBA Component Model:
The OMG CORBA Component Model Support various heterogeneous programminglanguages, operating systems, networks, and CORBA product seamlessly. The CCM
defines a framework to support the whole life cycle of software development processinclude: design, implementation, packaging, assembling, deployment, and execution.
Open CCM platform implements all the CCM features required by infrastructure for
ubiquitous contextual services, especially packaging, assembling, and automaticdeployment facilities, and support various operating systems like Linux, Solaris, and
Windows NT/2000/XP [5].
9
-
8/3/2019 MOBILE CONTEXT AWARE APPLICATION
10/11
-
8/3/2019 MOBILE CONTEXT AWARE APPLICATION
11/11
[1] B. Pan, K. Xiao, and L. Luo, "Component-Based Mobile Web Application of Cross-
Platform". 2009.
[2] B. N. Moti, "A Component-Based Software System with Functionality Adaptation for
Mobile Computing". The University of Hong Kong. 2002.
[3] V. D. Florio and G. Deconinck, "On Some Key Requirements of Mobile Application
Software". 2000.
[4] J. White, D. Schmidt, E. Wuchner, and A. Nechypurenko, "Automatically Composing
Reusable Software Components for Mobile Devices". 2007
[5] A. Flissi, C. Gransart, and P. Merle, "A Component-based Software Infrastructure for
Ubiquitous Computing". 2005
11