MOBILE CONTEXT AWARE APPLICATION Rafat A. AL-msiedeen Rafatals3ode@yahoo.

com

1. Introduction:....................................................................................................................1 1.1What is Mobile Computing?.......................................................................................2 1.2The Need for Dependability:......................................................................................2 1.3The Need for Adaptability:.........................................................................................3 1.4New Environment, New Features:..............................................................................3 1.5Infrastructural Requirements:.....................................................................................3 1.6Context:.......................................................................................................................3 1.7Adaptation and Adaptability:......................................................................................4 1.8Functionality Adaptation:...........................................................................................5 1.9A Definition of Contextual Services:..........................................................................5 1.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:....................8 1.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:.........................................8 1.10.3.4Push Model for Discovering Device Capabilities:..........................................9 1.10.3.5On-Demand Probing: A Hybrid Capability Discovery Model:......................9 1.11The OMG CORBA Component Model:...................................................................9 1.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 increasing requirement 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 using mobile 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 communication and 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

All things are affected by change. This is especially true for mobile computing environments. Everything, from devices used, resources available, network bandwidths to user contexts, can change drastically at run-time. It therefore becomes imperative for software systems and applications to be able to adapt to these changes in order to provide a suitable and relatively stable working environment for users [2]. The key property of computing services is their correctness, and the important property related to correctness is robustness. Another fundamental property for computing services is dependability; the dependability is a key requirement of software components and that, in order to make truly computer-based services, it is important to enhance 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 be deployed. The feature model characterize based on function and non-functional variabilities. 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 device mobility: a user carrying out his tasks on a device while moving about, taking advantage of wireless connections. The other dimension is user mobility: allowing users to move from one device to another still being able to carry out their tasks access their information and continue where they left off. Data mobility and code mobility are some techniques which can be employed to achieve user and device mobility. The Mobile computing is the use of mobile devices and notso-mobile devices, taking advantage of wireless means, to create a seamless 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 when considering the tremendous growth in both the complexity and crucial character of roles nowadays assigned to computer. The overwhelming growth in computer performance and ease to use experienced led society to depend more and more on services supplied by computers such as: health care, airborne equipment, public administration, transportation, communication. The criticality associated with many 2

tasks nowadays appointed to computer does require a huge degree of dependability. The awareness of this fact (dependability) becomes widespread, as can be proven by recalling the attention of the public to the so-called Millennium Bug problem [3].

1.3

The Need for Adaptability:

The growth in performance and ease to use ultimately led to an urgent need for dependability. The advent of mobile computing is to prompt a number of new requirements for the programs appointed to supply mobile services; the role of the environment is central one in them. The key idea is that, while in the past each application component was conceived, designed and implemented having a fixed scenario of environmental conditions that could only vary under exceptional circumstances [3].

1.4

New Environment, New Features:

The mobile computing environment is very different from the traditional networked environment. The essential features and demands, which set the mobile computing environment apart, include: device heterogeneity, device resource limitation, network bandwidth limitations and instability, high mobility, context awareness, and proximity interactions [2].

1.5

Infrastructural Requirements:

Current computing infrastructure and architectural models are inadequate to provide for the new features of mobile computing. Some of these requirements include: location tracking, data delivery and synchronization: mobile networking, ad-hoc networking, context determination 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 four types 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 along the following axes: (1) Device and run-time resources; mobile devices have different

processing power, memory size, display capabilities, input devices, output devicesetc; the amount of resource keeps changing at run-time, such as: available memory and energy. (2) Network infrastructure; devices connect to the network through various networking technologies WLAN, Bluetooth and GPRS. Mobile hosts move from one location to another, network characteristics change. (3) User preferences and environmental factors; not only do the device and network affect application, they also need to take into account user preferences and environmental consideration to provide appropriate, intuitive and customized services to the user, these consideration include time, location, nearby devices, nearby people, etc [2]. The context divided into four categories; (1) Computing context; network connectivity, communication bandwidth, nearby resources. (2) User context; user profiles, location, social situation. (3) Physical context; lightning, noise conditions, temperature. (4) Time context: time of day, week, month, season [2]. The contextual changes are categorize into four types; (1) Device resources; memory, processing power, energy. (2) Network properties; network available, network type, protocol. (3) Environmental context; location, time, entities available nearby. (4) User preferences; these are specific choices which the user has made to decide the execution of particular application [2]. 1.7 Adaptation and Adaptability: Adaptability is the ability to change a run-time characteristic in response to a trigger. It is the ability to detect a change in the external environment and despond to that change. And the adaptation is the action taken to achieve adaptability by change of a certain property. The change of a single property often affects more than one run-time characteristic; i.e. the adaptation is used to achieve adaptability [2]. Adaptive applications and systems have adaptability. They can change their run-time characteristics in response to an external trigger or change. These run-time characteristics can be considered in several dimensions which include: (1) memory adaptability; the ability to adapt to the changes in run-time memory available. Every device has different amounts of memory and processing power available. (2) Energy adaptability; the ability of an application, or system, to adapt its energy usage. Power is one of the most limited resources in a mobile environment. (3) Network adaptability; the ability of systems to change their network behaviors in response to changes in the network infrastructure. (4) Device adaptability; the ability to adapt to device configuration. User move from one device to another and the application will need to follow the users. The devices may have different input and output capabilities. (5) Context Adaptability; the ability to adapt to various external factors including location, time, user preference, and presence of nearby entities; i.e. means responding to contextual changes [2]. Some sort of adaptation is employed as a response to the change. Adaptation can be seen as a means of achieving adaptability. Adaptation can categorize into five categories, based on the change factor; include: (1) data adaptation; mobile application usually need to access data for information or for entertainment, such as emails, stock quotes, etc. data

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 level parameters. 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 the amount of energy consumed, either by turning the power off or moving to a less energyconsuming. Many of techniques are hardware related. (4) Migration adaptation; this involves changing the location of execution, for example, by moving to another machine with 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 users performing 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 occurs in 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 able to 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 the services 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 and context aware applications are one of the new challenges in distributed computing area [5].

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 typically delivered 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 still significant variabilities between devices in terms of: hardware resources, middleware versions, 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 high cost 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 of finding 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 new mobile device [4]. 6

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 a sets 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, a provisioning 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 are the 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 when the resource requirements of the deployable components greatly exceed the available resources on the device. (4)Exploit Non-Functional Requirements; non-functional requirements 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 the lowest 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 into broad 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 developed to 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 these capabilities 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 components for a set of device capabilities, none of these techniques or tools addresses how resource constraints are considered in the selection process. For mobile device, resource constraints 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

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 called Over_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 provisioning server. 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 to fulfill 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 to describe 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 productline rules into a constraint satisfaction problem [CSP], and using a constraint solver to derive 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. The values 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 cellular network. 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

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 or dynamic 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 precompiled device information database. New device are released frequently and thus a repository 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 faces a 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, the push 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 sending device 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 device information 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 description repository 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 Pull Models. 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 programming languages, operating systems, networks, and CORBA product seamlessly. The CCM defines a framework to support the whole life cycle of software development process include: 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 automatic deployment facilities, and support various operating systems like Linux, Solaris, and Windows NT/2000/XP [5].

1.12 Framework of Component-based Mobile Web Application Development:

Considering the current methods of cross-platform mobile application development, propose a frame of component-based hierarchical development, mobile application development divided into 4 layers: (1) Application Layer; mainly adapt with Ajax technology, Ajax means the combination of asynchronous JavaScript and XML. JavaScript is a kind of lightweight language, user interface designed is colorful with the help of JavaScript and CSS.XML means extensible markup language, the same of HTML. (2) JS Engine Layer; this layer is aim to parse the JavaScript code of application layer. The process of parsing is to map the methods and properties of script with matched interface of component layer, to implement specific function by these component interfaces. (3) Component Layer; this layer is the core of component-based crossplatform of mobile application development, it support application layer with unified interface by parsed through JS Engine Layer, mask differences of underlying operating system in this layer. The interfaces packed in component are implemented on designated platform; include Networking, Graphics, File System, Store Manage and System Service component. (4) OS Layer; this layer is a set of different mobile operating system, such as windows mobile, iPhone, Palm, Android and so on [1]. Component layer is to pack the main function into single component, include networking, graphic, file system, store management, and system service. The interface of each component is defined according certain standards. JS Engine is to map the interface of component layer to method and property called in application layer. All the five components are implemented on each platform in accordance with the feature of specific OS. For more detail description of each component in component layer; the networking include network connectivity and disconnect, select mode of connections, diagnosis of network fault and so on. Graphic deal with the output of graphics and images, to convey information between system and drawing program. File system include the function of create new file, delete file, find file and so on. The store management mainly refers to the memory allocation and destruction. System service: mainly call for local service, including dial phone, send message, open camera, and other system service. These components provide upper layer with a unified interface, shielding the various operating system differences [1].

Figure_1.2: Framework of Component-based Mobile Web Application Development [1].

1.13 References:

10

[1] B. Pan, K. Xiao, and L. Luo, "Component-Based Mobile Web Application of CrossPlatform". 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