Cloud Collaboration

Cloud collaboration is a type of enterprise collaboration that allows employees to work together on documents and other data types, which are stored off-premises and outside of the company firewall. Employees use a cloud-based collaboration platform to share, edit and work together on projects. Cloud collaboration enables two or more people to work on a project at once.

A cloud collaboration project begins when one user creates the file or document and then gives access to certain individuals; for example, the project creator may share a link to the project that allows others to view and edit it. Users can make changes to the document at any time, including when employees are viewing and working simultaneously. All changes are saved and synced so every user sees the same version of the project.
Cloud collaboration has become more sophisticated as vendors try to attract customers. It is common for a collaboration tool to include a way for project participants to see who else is viewing the document and to communicate with each other while working, such as through comments or a chat function. Tools also often allow users to set up email alerts for when a file is changed. These and other functions help increase worker efficiency and productivity.
Employee's motivations for using cloud collaboration tools vary, but the impetus is often that workers find the cloud tool to be better in some way than an old tool. Employees may think the cloud collaboration tool is faster, looks nicer, is easier to use and more.
Desire for a better collaboration tool can lead employees to choose and use a tool without prior approval of IT, a practice known as shadow IT. IT departments should be on the lookout for this, but they should also be open to the positive impact a cloud collaboration tool can have on group communication and teamwork.

Common Cloud

The lines between local computing and cloud computing sometimes get very, very blurry. That's because the cloud is part of almost everything on our computers these days. You can easily have a local piece of software (for instance, Microsoft Office 365) that utilizes a form of cloud computing for storage (Microsoft One Drive).
That said, Microsoft also offers a set of Web apps, now called Office Online, that are online-only versions of Word, Excel, PowerPoint, and One Note accessed via your Web browser without installing anything. That makes them a version of cloud computing (Web-based=cloud).
Some other major examples of cloud computing you're probably using:
Asus ChromebitGoogle Drive: This is a pure cloud computing service, with all the storage found online so it can work with the cloud apps: Google Docs, Google Sheets, and Google Slides. Drive is also available on more than just desktop computers; you can use it on tablets like the iPad$349.00 at Amazon or on smartphones, and there are separate apps for Docs and Sheets, as well. In fact, most of Google's services could be considered cloud computing: Gmail, Google Calendar, Google Maps, and so on.
Apple iCloud: Apple's cloud service is primarily used for online storage, backup, and synchronization of your mail, contacts, calendar, and more. All the data you need is available to you on your iOS, Mac OS, or Windows device (Windows users have to install the iCloud control panel). Naturally, Apple won't be outdone by rivals: it offers cloud-based versions of its word processor (Pages), spreadsheet (Numbers), and presentations (Keynote) for use by any iCloud subscriber. iCloud is also the place iPhone users go to utilze the Find My iPhone feature that's all important when the phone goes missing.
Amazon Cloud Drive: Storage at the big retailer is mainly for music, preferably MP3s that you purchase from Amazon, and images—if you have Amazon Prime, you get unlimited image storage. The Cloud Drive also holds anything you buy for the Kindle. It's essentially storage for anything digital you'd buy from Amazon, baked into all its products and services.
Hybrid services like Box, Dropbox, and Sugar Sync all say they work in the cloud because they store a synced version of your files online, but most also sync those files with local storage. Synchronization to allow all your devices to access the same data is a cornerstone of the cloud computing experience, even if you do access the file locally.
Likewise, it's considered cloud computing if you have a community of people with separate devices that need the same data synched, be it for work collaboration projects or just to keep the family in sync. For more, check out the The Best Cloud Storage Services for 2015.
Cloud HardwareRight now, the primary example of a device that is completely cloud-centric is the Chromebook. These are laptops that have just enough local storage and power to run the Chrome OS, which is essentially turning theGoogle Chrome Web browser into an operating system. With a Chromebook, most everything you do is online: apps, media, and storage are all in the cloud. Coming soon are Chrome Bits, smaller-than-a-candy-bar drives (pictured) that turn any display with an HDMI port into a usable computer running Chrome OS.
Of course, you may be wondering what happens if you're somewhere without a connection and you need to access your data. This is currently one of the biggest complaints about Chrome OS, although its offline functionality is expanding.
The Chromebook isn't the first product to try this approach. So-called "dumb-terminals" that lack local storage and connect to a local server or mainframe go back decades. The first Internet-only product attempts included the old NIC (New Internet Computer), the Netpliance iOpener, and the disastrous 3Com Audrey. You could argue they all debuted well before their time—dial-up speeds of the 1990s had training wheels compared to the accelerated broadband Internet connections of today. That's why many would argue that cloud computing works at all: the connection to the Internet is as fast as the connection to the hard drive. Or is it?

Personal data storage on mobile cloud

One of the key concerns for people about using a mobile cloud is that their personal data on mobile device could be stored on, or accessed by the cloud. A mobile device contains contact lists, text messages, personal photos and videos, calendars, location information, and these data can reveal many things about someone’s personal life. However, a personal computer also stores many such personal data such as photos and other multimedia, chat logs, emails, passwords, financial records or access to such records, calendar and contact lists. Today, thousands of monetary transactions are being done in online shopping sites such as eBay, and Amazon. Therefore, the risks involved in mobile cloud are not necessarily greater than those involved in traditional clouds. However, the issue here is whether the means of handling those risks have been properly implemented in the mobile cloud. Despite reservations, people do tend to use their mobile devices with the cloud. Some recent examples of mobile cloud storage are Apple’s iCloud, Google Drive and Dropbox. Apple iCloud enables users of iOS devices to synchronize their application data such as photos, iTunes music, calendars, email, and messages. An initial 5 GB of iCloud storage is free for an Apple user, with additional storage available for a monthly fee. Although iCloud offers an Apple user an impressive user friendly feature suite (such as Find my Phone), it is only for data related to Apple devices. In contrast, Dropbox is less specialized, but works across heterogeneous platforms including Microsoft Windows, Linux, Mac OS, iOS, Android, and Blackberry. Dropbox also allows sharing stored data with friends, and file revisions.

Data management

For many cloud users and providers, managing data on the cloud raises many complications. In mobile cloud computing, as the name itself suggests, data that would traditionally be only accessible only to the mobile device’s owner, would now be stored on, accessible to, shared with external devices or users. For many mobile users, this raises privacy and security questions. Also, data representation in mobile devices vary, and in a heterogeneous mobile cloud, this would lead to problems with portability and interoperability. Computations in a mobile cloud would be spread across a distributed file system, where multiple devices may need to access and modify files.

Furthermore, special considerations must be given to accessing files from mobiles over wireless networks. In a mobile cloud, users geographical locations are not fixed, and bandwidth must be conserved because of data access costs. However, it is also vital that mobile databases contain policies to safeguard against data loss while ensuring it conforms to mobility constraints. We discuss these issues in the following subsections. Issues regarding data privacy and security are not discussed here, since they have already been explained at length in Section 4.4: Privacy, Security and Trust.

Energy awareness

Because a mobile device operates on a finite supply of energy contained in its battery, energy is one of the key resources that needs to be used carefully [99]. In the context of mobile clouds, the cost of participation (such as power consumption) should be less than the benefit gained [100]. Also, it will enable the mobile device to take appropriate component level action to minimize unnecessary energy consumption, and hence, lengthen the system’s life span by unloading unneeded software components, redeploying energy intensive components to more resourceful hosts, and collocating frequently communicating hosts, as suggested in [101]. For these reasons, being aware of a device’s energy usage is vital.
In the following we discuss the research on energy consumption, mainly focusing on work on energy profiling and energy usage estimation.
Energy profiling. In PowerScope  [102] the authors present a profiling tool for mobile applications. The tool maps power usage to specific code components in applications and the operating system, allowing an analysis of power draining procedures. Using this analysis, the developers can modify their software to be more energy efficient. The authors report a 46% energy saving by using PowerScope to profile an adaptive video application run on the Odyssey platform [44]. Experiments were carried out with several laptops and pocket computers. Profiling is done offline after collecting data, to ensure no overheads are added to the analysis. A digital multimeter measures the electric current used by the profiling computer and the energy profile is generated using these correlated current measurements. The apps can only be profiled on an open source operating system however, as small modifications to the kernel are required.
In [103], Rice and Hay present a power consumption measurement framework, specifically for mobile phones. In particular, they explore the effect of message size and send buffer size when transmitting data on two Android 1.5-based phones. Power usage during connection to a WiFi network and idle power costs for WiFi, 3G and 2G are also discussed. Power consumption is measured by sampling the voltage drop across the phone battery and a high precision resistor. The mobile device first downloads the test script from a central server and uploads the results to the same server. The central server aligns the test results with the traces and logs. Their findings can be summarized as follows:
1.
When connecting to a WiFi network through DHCP, a significant portion of the time and therefore power, are taken by the ARP Probe packets and the delay between them.
2.
In the case of idle power, WiFi has the lowest energy cost, followed by 3G and 2G respectively. However, it should be noted that the locations of the base stations will also affect radio transmission.
3.
Although it would be logical to expect that the energy cost per byte will decrease as the message size increases, results show that this is not the case. There appears to be a sharp increase of power cost from sending a 7 kB message to 8 kB. However, the reason for this is not clear.
4.
The choice of buffer size can significantly affect the power consumption.
The work discussed previously measures the energy via hardware. A different approach is to take the measurements via software to query battery levels as done in PowerSpy [104], implemented in the Windows operating system. PowerSpy operated in two stages; event tracking and analysis. In the event tracking stage, the application is run and tracked for CPU time, I/O activity and energy consumption. In the analysis stage, the data acquired in the previous stage is processed. To filter out the energy consumed by I/O activities, an estimation of energy usage by various devices to run particular tasks (such as energy used by the disk to read 1 kB) as specified by the devices manufacturer, is used. This estimation is subtracted from the total of recorded energy use, and the remainder is taken as the energy taken up by CPU threads. Next, energy consumption is drilled down to individual threads, on the assumption that CPU power usage is proportional to the number of CPU cycles spent on a thread.
Work done by Cano et al. [105] and [106] provides insight into the energy consumption of the Bluetooth protocol. The focus of their work is on the different states of Bluetooth such as Startup, Standby, Inquiry, Connection and especially the low power modes provided by the protocol.
Energy usage estimation. Work done by Chiyoung et al.  [101] and Seo et al. [107]focused on the energy (electrical) consumption estimation of Java based pervasive systems at the level of its system level components. The initial estimation in [101] is done prior to runtime—during construction time. Then the estimation is refined during runtime automatically depending on certain system parameters such as size of data exchanged over the network, inputs to the components’ interfaces, and invocation frequency of components’ interfaces. The exact formulas for calculating the estimation are given in [107]. Their methodology gives an Energy Cost Framework as follows:
•
Overall Energy cost = Computational energy cost + Communicational energy.
•
System Energy cost = Overall Energy cost + Overall infrastructure energy cost
where infrastructure cost is the cost incurred by the operating system. The computational cost is determined by the level of its public interfaces and the computational cost of an jth invocation of an ith interface on a given JVM is modeled in terms of byte codes, native methods and monitor operations. Communication cost due to the jth invocation of component c1’s interface I1 on host H1 is calculated in terms of the size of the transmitted and received data and the energy consumption of transmission/receive cost of H1. The authors claim that based on their evaluations in which they ran distributed applications on Kaffe 1.15 JVM on Compaq iPAQ PDAs, their estimations are within 5% of the actual power consumption.

Risk assessment using context-awareness

In MobiCloud [37], context information is used to facilitate risk assessment and routing decisions. MobiCloud introduces Virtual Trusted and Provisioning Domains (VTaPDs), which is a service that can isolate different information flows in in different domains by way of programmable router technologies. VTaPDs identify these separate flows and create virtual domains. By doing this, a user is able to securely run multiple applications on different security domains, and to separate services for different settings based on context. The MANET’s contextual information such as device sensing values, location, and neighboring device status are recorded by the VTaPD manager, and used for risk management and intrusion detection procedures. Parameter values related to devices, network, content, and security such as battery level, connectivity, predefined goals, and privacy, are used to provide context-aware service migrations. Risk management is aided through context information because the status of the entire system (end-to-end communication delay, reachability of the destination, security status of each mobile node, etc.) is available. From this centralized data collection and processing, knowledge of the full MANET system is gained, and MobiCloud can easily identify malicious nodes.

4.5.3. Identifying potential resources and common activities using context-awareness

In [12], a Context Manager component is deployed to sense context information and store it to be used for other components such as Application Manager, which launches, intercepts and modifies an application according to the current context. Location and number of nearby devices in the vicinity are the key contexts, with location information used for mobility traces, and number of devices used to aid the forming of the mobile cloud. Thus, the system is made aware if a new device enters the resource pool, or leaves it, thereby leading to better scalability and content distribution. Furthermore, this information is used to infer if a particular device is ‘stable’ or not, which is essential to decide if it is following a common movement pattern with the other devices, leading to common activities.

Context-aware service provisioning

It has been suggested that, mobile clouds can utilize the sensing abilities of their mobile devices such as location, acceleration, etc. and act as providers of context awareness/information. In [95] the authors suggest utilizing the sensing capabilities of mobile Internet devices to provide such context-aware service provisioning. Consider a mobile device connected to a remote cloud service through the Internet. As the context of the user changes, this prompts invocation of different cloud services based on the current context. With this kind of context-awareness, a service would not be bound to a user. Instead, when a mobile user invokes a cloud service, the request is accompanied by his/her context information, and the most suitable service is selected based on that information. Therefore, context is used to provide personalized services, and also as fault tolerant mechanisms such as rectifying low quality of service problems. Here, the authors identify a model consisting of four layers of context elements:
1.
Monitored context: refers to current monitored context consisting of: device context which includes the environmental and device settings, user preference for user-specific preference settings, such as those regarding services selection and invocation, situational context relating to monitored data on user location, time etc., and Service Context information such as QoS.
2.
Types of gaps: refers to gaps that happen as a result of content changes. For example, when the user’s service is changed from Service1 to Service2 owing to a context change, there is a gap between the two services. Mainly, two types of gaps are identified: gap on functionality that relates to an available service and the needed service, and gap on nonfunctionality relating to differences in QoS values between the previous service and the current one.
3.
Types of causes: refers to the factors that can cause the aforementioned gaps. A service may have multiple interfaces, and an interface may have different implementations. Similarly, there can be different component instantiations for the same service component. The gaps arise because of the mismatches between these: Service-level Unmatched, Service Interface-level Unmatched, Service Component-level Unmatched, and Component Instance-level Unmatched.
4.
Adapters: refers to the remedial actions that should be taken to remove the aforementioned causes.
Based on this model, the authors propose a context aware service provisioning architecture consisting of three tiers: User Layer that is made up by the mobile devices where the applications run on, Agent Layer that adapts the services according to context, and Service Layer that deploys the services.
Volare [96] introduces a middleware for monitoring the context of a mobile device that is connected to a cloud service, and dynamically adapts the services so as to make them more resource efficient, reliable and cost efficient. Acting as an intermediary, VOLARE intercepts service discovery requests from applications while monitoring mobile device’s context such as battery consumption, CPU usage, network bandwidth, user preferences like low power operation etc. Depending on this contextual information, VOLARE tries to adapt each service request by comparing the current QoS level with predefined thresholds. Instead of modifying the applications, a declarative language has been created to describe the adaptation policies. If at any time, the QoS level and the cost changes beyond the predefined values, VOLARE will automatically rebind to another service that can satisfy the requirements.
In MoCA [59], a proxy can register an ‘interest expression’ on a mobile, i.e., “FreeMem <10 kB” for a particular client, which would result in the proxy getting notified if and when the client’s free memory drops below 10 kB. These context specific “interests” depend on those specific applications requirements. For example, if the proxy gets an update that a client’s wireless connectivity has gone down a certain point, it could take certain actions such as compressing the data.
Using ‘Intelligent access’ for Mobile Cloud Computing is discussed in [97], where use of context information provided by terminals, network nodes, or sensors deployed in the users environment enables efficient network access management across different Radio Access Technologies (RATs) such as GPRS, WCDMA/HSPA, LTE, WiMAX, cdma2000 and WLAN. Conventional intelligent access schemes assume that all categories of dynamic context information such as user profiles, terminal status and sensor information and external sensor networks would aid in improving mobile access. However, mobile cloud computing requires a wireless connection with a set of different necessities than classical heterogeneous access scenarios: connectivity for long periods, scalable bandwidth, network selection and usage based on energy costs. To satisfy these requirements, the paper proposes Intelligent Radio Network Access (IRNA). The status and attributes of each RAT is considered, while at the same time effort is taken to entertain the user requirements based on environmental factors. Their proposed context management architecture (CMA), based on the producer–consumer role model such as given in [98], is responsible for acquiring, processing, managing, and delivering context information. To control the supply of context information according to the mobile cloud’s requirements, the framework has a Context Quality Enabler (CQE). The CMA is made up of three components:
1.
Context Provider (CP): this is where the context information originates from and is provided to other components of the architecture. The communication between CPs and other components are done through context requests.
2.
Context Broker (CB): acting as a middleman, the CB keeps a registry of available CPs and their capabilities, and provides a CP look-up service. Also, the CB itself is able to forward the data it receives from CPs.
3.
Context Consumer: these are the entities that take context data as inputs for their actual functionality, e.g.: network services, applications for end users, and service enablers.
In MiPeG [25], a middleware for integrating mobile devices into grid environments, several mechanisms for providing and using context awareness are discussed. Context information such as location, resources and environment conditions is used to adapt the services provided by the grid, using Semantic Web technologies, thus supporting the ‘pervasive grid’ concept. The ‘Context Reasoning Engine’ forms the main component of the context service. Its responsibilities include handling the context, information gathering from sensing devices, and forming higher level semantic rules depending on the context information received.
Subscribe to: Posts (Atom)