MOBILE CONTEXT AWARE APPLICATION

Embed Size (px)

Citation preview

  • 8/3/2019 MOBILE CONTEXT AWARE APPLICATION

    1/11

    MOBILE CONTEXT AWARE APPLICATION

    Rafat A. AL-msiedeen

    [email protected]

    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