CPA Components and User Interaction

Within CAMCS at a more detailed level than presented in the CAMCS archi-tecture diagram, there are several components that support the operation of CPAs. Figure 3.3 shows an overview of these components, which are divided up into three layers; the Management Layer, and CPA Layer, and the Execution Layer.

Figure 3.3: A detailed view of the components of CAMCS, which can be di-vided into three layers. The Management Layer contains many components shared by all CPAs. The CPA Layer contains the CPAs, along with compo-nents that each CPA has a unique copy of, and finally, the Execution Layer, containing components used during task execution.

The Management Layer contains common components shared by all CPAs to support their operation. Some of these CPA components can be thought of as interfaces to allow individual CPAs to communicate with a specific larger com-ponent of CAMCS, such as the User Context Manager, which just interfaces CPAs to the Context Processor. The other CPA components are not interfaces, and wrap their own functionality, such as the Notification Manager.

A CPA uses the components in the Management Layer through the CPA Man-ager (as singletons). Every CPA has a reference to the CPA ManMan-ager. The CPA Manager is also used for authenticating user access to CPAs when requests are received from the mobile device. User access to CPAs is mediated by CAMCS,

with username and password basic clear-text authentication over HTTP.

• Discovery Handler

The Discovery Handler encapsulates all functionality related to Service Discovery, as seen in the CAMCS system architecture diagram. The CPA passes the user-provided task description to this handler, which contacts the service registry using this description. The registry returns a list of discovered services for the task, to the CPA.

• Task Starter

Once the mobile user has chosen a service, and provided all the input parameters, the CPA passes this information to the Task Starter. The Task Starter creates a Task Executable (discussed in Chapter 5) for executing the task, and passes a map containing the user provided parameters.

• Profile Manager

The Profile Manager is related to the Context Processor, allowing the user to switch between Context Profiles, which are discussed in Chapter 4.

Context Profiles can determine what behaviour a CPA should undertake under its own initiative.

• User Context Manager

The User Context Manager is effectively an interface allowing a CPA to query and retrieve user context data, stored with the Context Processor component, when required for service discovery, or task execution.

• Notification Manager

The Notification Manager is used to send Push-style notification mes-sages from a user’s CPA to the mobile device, to inform him/her of some event, such as "Discovery Complete", or "Task Complete".

The CPA Layer contains a CPA for every user. The data for all CPAs is stored in a backend database. Every CPA contains its own unique copy of the following components:

• Task Manager

The Task Manager stores a CPAs Current Tasks, and Completed Tasks. The completed tasks make up a CPAs Task History. All operations, such as

creating new tasks, storing of selected services and input parameters, and retrieving task results, take place through the Task Manager.

• Account Manager

The Account Manager stores a user’s credentials for connecting their CPA to third-party cloud services, which are used for features such as Context Awareness, and with some of the pluggable modules. The Ac-count Manager also contains the operations to contact those services, and push/pull information to/from them. This is presented in full in Chapter 7.

The Execution Layer at the bottom, contains all the components related to task execution on behalf of CPAs:

• Task Executable

Task Executables are used to run tasks, and are created by the Task Starter. All information related to running a task, such as the selected service, and the user’s input parameters, are passed into the Task Exe-cutable as a map. The Task ExeExe-cutable is the component that makes the remote call to the cloud-services over HTTP, passing the parameter in-formation, and it also prepares the result data retrieved back from the service for storage by the CPA. The Task Executable implementation is discussed in more detail in Chapter 5.

• Task Listener

The Task Listener, as the name suggests, is a listener which listens for events in relation to task execution, such as task completion, moving a multi-step task (known as a task using a Service Flow, discussed in Chap-ter 5) to the next step, or a task error. It notifies the CPA of these events (so that in turn, the CPA can notify the mobile user with the Notification Manager). It is also responsible for passing the task result, from the Task Executable, back to the CPA for storage with the Task Manager.

A flow diagram showing how the execution of a new task uses the components in these three layers, is shown in Figure 3.4. This middleware architecture and component design was derived from the need of a middleware solution that was user oriented, to ensure user adoption. The components are centered around CPAs, and the functionality that they require to complete task work for the user in a disconnected, asynchronous fashion. An alternative design

Table 3.1: A summary of how the common approaches to mobile cloud com-puting meet the user experience requirements outlined in this chapter, includ-ing CAMCS. √

indicates an approach solves a problem, ∗ indicates depen-dence on the individual services.

Cloudlets Partitioning Code Offload Remote Display Other Middleware CAMCS

Latency √ √ √ √

consideration was to use an agent-based approach. However, agent-based so-lutions typically consist of agents sitting in a pool, waiting to complete only one type of task upon request, rather than a personalised dynamic solution that could be used to complete a range of tasks. Consideration was also given to using specific cloud-based applications as use-case examples, which would deliver functionality to mobile devices through the web browser, rather than the use of a native application. However, once again, applications based on specific use-cases are not dynamic in the range of services that can be offered to the user. The use of a native application on the mobile device was also de-sirable in order to obtain full un-hindered access to the device APIs.

In the next section, an evaluation takes place to describe how CAMCS can meet the requirements that have been outlined for an integrated user experience.

3.4 Evaluation

CAMCS can address the requirements outlined in this chapter, and therefore provides a comprehensive solution for many of the problems outlined in pre-vious projects, while placing user experience as the primary motivation behind the design and approach decisions - see Table 3.1.

• Latency shall not be noticeable during interaction with CAMCS because of the low-volume data that will be transferred between the mobile de-vice and CAMCS. Task data will consist of textual data of small size. As a result of the disconnected nature, there is no need for continuous data transfer which can make latency more noticeable to the user, and addi-tionally, there will be no real-time requirement in this work. Interactivity with solutions like remote display and middlewares, do not take latency

Figure3.4:AsequencediagramshowinghowthecomponentsofCAMCSareusedbyCPAstocompleteatask.Thesolidlines showthemainflowofstepsthroughthesystem.Thedashedlinesshowstepswheretheuserisnotifiedofaneventusingthe NotificationManager.Thedottedlineshowswheretheuserprovidesmoreinformationbeforethemainflowcanproceed.

into account.

• Bandwidth utilisation is low, as the user only needs to signal the CPA to carry out work and pass required information, which has already been stated to be in the form of textual task descriptions. VM state, entire mo-bile applications or code-bases, do not need to be transferred between the mobile device and CAMCS, as in other work. To minimise the workload overhead on mobile devices, the CAMCS Client is used on the device to communicate with CAMCS in the cloud. Solutions such as Cloudlets and remote display, both require large-volume data transfer because of the VM-based approaches used.

• CAMCS uses applications and services deployed in the cloud rather than on the mobile device; resource intensive applications are not executed on the device, which reduces its workload and in turn, will benefit from time and energy savings. The mobile user does not directly interact with a service through their mobile device, as this interaction is delegated to his/her CPA. The mobile device is only responsible for running the CAMCS Client application, which is a thin-client, rather than a fat-client.

Not all approaches reduce the device overhead; for example, Cloudlets require the device display to be active at all times for the user to interact with the VM running on the Cloudlet.

• CAMCS can address mobility concerns such as disconnections by storing task results for the user until he/she has an Internet connection to con-nect to their CPA. A CPA in the cloud carries out all the complex work of discovering and invoking services, freeing the mobile device to per-form other work. All the solutions presented in the related work, with the exception of middlewares, cannot tolerate disconnection.

• The ability of CAMCS to include context awareness support will enhance the user experience. It can gather various new contexts in suitable con-ditions, and infer context from task and context history, all the while tak-ing advantage of the cloud resources such as data-stores and processtak-ing power. Gathered context data can be used to personalise both service discovery, and service execution, so that the result of the task is relevant to a user’s situation. Cloudlets and remote display solutions, based on desktop operating systems, are not designed to take mobile contextual data as input.

• CAMCS is a middleware designed to serve mobile devices. Specifically, it optimises the presentation of service outputs to the mobile device through the user’s CPA, such as optimised request/response data for-mats using JSON markup, and communication architectures with REST over standard HTTP. Where possible, platform neutral technologies are used.

• The CAMCS Client adapts its operation based on the state of the mobile network at any given time, by delaying tasks being sent to the user’s CPA until such a time that the predicted network quality has improved. This is presented in Chapter 6. Solutions such as application partitioning and code offloading, also observe the state of the network before a decision is made to offload, but the methodology the related works use to perform this profiling result in an overhead. Other solutions do not observe the network state.

• CAMCS and other middlewares are the only solutions that can claim to use standards-based solutions. This is because CAMCS, and most mid-dlewares, work with cloud-based services deployed using standard SOA patterns and technologies, whereas other approaches require applica-tions to be modified for compatibility with the proposed solution, mainly with application partitioning and code offloading solutions.

The requirements outlined and evaluated above, do not exclude individual applications from being feasible as a mobile cloud computing solution, if for example, one requirement is not met. It is up to the software developer, or the application itself to mediate how a resource is used. For example, if an appli-cation is susceptible to latency, or requires high-volume data transfer, then the mobile user should be made aware that the preferred network connection for operation is a Wi-Fi network, rather than a cellular network. The mobile user should not expect the same level of a user experience over the cellular network in such a case.

In Chapter 8, where CAMCS is evaluated, the requirements will be revisited to determine if CAMCS conforms with them.

3.5 New Mobile Cloud Usage Scenarios and En-abled Features

Several new kinds of applications and services can be enabled by the CAMCS approach to mobile cloud integration.

• Real-Time Context Aware Services

Real-time services, which can respond to the users current and inferred context, possibly from context history, can be enabled by CAMCS. Such applications and services can actively or passively recommend activities or a course of action to users based on context, such as reminders or in-formation about tasks they have to carry out based on location context.

For example, the purchase of items from a shopping list, or if in an unfa-miliar location, can suggest places of interest based on past activities. In the case of the shopping list reminder scenario, the CPA could actively check store stock for the user, and if unavailable, direct to a new store nearby that has the desired item(s) in stock, without user intervention.

As another example, based on the current time of day or even year, such as during the day during school-term, it can notify parents to a routing of least traffic congestion to a school. This would stop occurring out of school term. The CPA can actively consult with traffic services, and per-haps could even make the information available to other applications or devices in the car such as a SatNav. This kind of application is explored in chapter 4.

• Collaborative Services

Each CAMCS user will have invoked and discovered different services.

In a vision of the next generation of mobile applications by Sankara-narayanan et al [20], they propose collaborative applications and services that share information to provide a seamless user experience, rather than the current generation of applications and services that work in isola-tion. An example the authors used was a traveller attending a confer-ence. A calendar application with details of the conference such as lo-cation and time/date, could share this information automatically with airline and hotel services to find the best flights and accommodation to a location near the conference venue. CAMCS could enable such an approach, if the CPA can share details of discovered services with each

other. This could be further enhanced if CPA users who share some re-lationship such as friends or work colleagues are made known to each other, in which case they share similar interests and context. Any col-laboration scenario would be subject to strict privacy control. This is explored briefly in Chapter 7.

• Additional CPA Services

The CPA concept can be expanded so that the CPA can carry out its own work, rather than simply looking up and invoking services. For exam-ple, the CPA can be extended to provide additional applications for the user, such as data processing and synchronisation with multiple services that the user is interested in, such as the synchronisation of data among social networks or sharing of files in a workplace domain. Some of these application models are also explored in Chapter 7.

• Extensible Middleware

The CAMCS functionality can be extended by adding in components on a plug-in basis to carry out other tasks on behalf of the mobile user, possi-bly utilising cloud based services, and taking advantage of the cloud in-frastructure. Such functionality could include support for computation-ally intensive batch processing jobs, or a client for long running queries on databases within a workplace or scientific domain, such as has been undertaken with the additional CPA services described previously.

• API for Developers

As CAMCS is a cloud-based middleware, it shall be deployable on any cloud servers supporting the appropriate language runtimes. For ex-ample, it could be deployed within the private cloud of a company to provide internal workplace services to employees through their mobile devices. The primary interaction with CAMCS will take place through RESTful endpoints, providing an API for CAMCS to perform various tasks. A developer can extend the RESTful API endpoints to target new (or existing) functionality offered by CAMCS, such as access to new ser-vices as previously described, and hook into user CPAs via the CPA Man-ager.

• Performance Enhancing Proxy for Mobile Clients

In addition to extending the CAMCS middleware with additional

appli-cation and service models, CAMCS can also serve as a more traditional performance enhancing proxy, sitting between the mobile device and cloud-based services. Middleware services such as data caching, con-tent delivery, and compression of HTTP payload data, are examples of features that can be provisioned to mobile clients.

3.6 Conclusions

Future approaches to mobile cloud computing will need to tackle several of the issues that are dominating the current work in this research area. After deter-mining a set of requirements for future mobile cloud works to provide an in-tegrated user experience, the Context Aware Mobile Cloud Services (CAMCS) middleware was introduced, which can meet these requirements. User interac-tions with CAMCS for completing tasks, mainly through the use of each user’s Cloud Personal Assistant (CPA), were presented. The design of CAMCS was presented, including the structure of the middleware, and the various compo-nents it uses to complete its work. It was shown how these compocompo-nents are used for the purposes of completing user tasks. Finally, the CAMCS approach was analysed to determine how it can meet the user experience requirements outlined, and new application scenarios that CAMCS can enable, were pre-sented.

In the next chapter, the implementation of the Context Processor component of CAMCS is presented. This will show how user context data is collected from the mobile device, and how a user’s CPA can use this data with cloud-based services to personalise their results to the his/her situation.

This chapter was based on [98], with the following exceptions: Subsections 3.3.2 and 3.3.3 are new, and Section 3.4 has been modified. Various modifica-tions have been made to the text throughout the chapter, to fit with the flow of the thesis. Some of Section 3.3.3 will appear in [101].