Modelos emergentes para el desarrollo de aplicaciones móviles sociales: people as a service y social devices. Prueba de concepto.

3 ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA GRADO EN INGENIERÍA DEL SOFTWARE MODELOS EMERGENTES PARA EL DESARROLLO DE APLICACIONES MÓVILES SOCIALES: PEOPLE AS A SERVICE Y SOCIAL DEVICES. PRUEBA DE CONCEPTO. EMERGING MODELS FOR THE DEVELOPMENT OF SOCIAL MOBILE APPLICATIONS: PEOPLE AS A SERVICE, AND SOCIAL DEVICES. A PROOF OF CONCEPT. Realizado por JOSÉ ANDRÉS CORDERO BENÍTEZ Tutorizado por CARLOS CANAL VELASCO Departamento LENGUAJES Y CIENCIAS DE LA COMPUTACIÓN UNIVERSIDAD DE MÁLAGA MÁLAGA, noviembre 2014 Fecha defensa: El Secretario del Tribunal 5 Resumen: Actualmente los dispositivos móviles han ganado una gran importancia en nuestra sociedad y están presentes en cualquier lugar. Estos dispositivos tienen una gran cantidad de información sobre sus dueños y datos contextuales de sus alrededores, y muchos canales de comunicación. No obstante con los modelos actuales los dispositivos móviles no pueden obtener ventaja de esta situación. Por estos motivos, han comenzado a surgir recientemente nuevos modelos de aplicaciones móviles. People-as-a-Service (PeaaS) permite interacciones entre dispositivos móviles cercanos, usando perfiles sociológicos de sus dueños para crear comunicaciones entre dispositivos interesados. Social Devices es un modelo reciente que implementa el concepto de PeaaS, aprovechando que los dispositivos están casi siempre con el usuario crea una nueva línea de interacciones entre los dispositivos cercanos con el objetivo de aumentar las relaciones sociales. Para ello cada dispositivo es capaz de proveer y consumir servicios de dispositivos cercanos, manteniendo la información del usuario en el propio dispositivo y compartiéndola solamente cuando esté autorizado. Este concepto también puede integrarse con tecnologías como Internet-de-las-Cosas y la Computación Ubicua, permitiendo que los dispositivos se conecten con otros objetos cercanos tales como ascensores, semáforos o tu propio vehículo. En particular existe una plataforma que implementa ambos conceptos, y que es el objeto de estudio de este trabajo: OrchestratorJS. La plataforma aún se encuentra en desarrollo y no es demasiado estable, además de no contar con ninguna documentación. El objetivo de este trabajo es explorar la plataforma y crear una documentación básica que pueda ser utilizada por cualquiera que esté interesado en ella, actuando como punto de partida para futuros trabajos. Palabras clave: Social Devices, People-as-a-Service, Cooperación basada en proximidad, Computación Ubicua, OrchestratorJS. 6 Abstract: Nowadays mobile devices have gained a great importance in our society and they are present everywhere. These devices have a huge amount of data about their owners and context data of their surroundings, and many communication channels. Nevertheless with current models mobile devices cannot take advantage of this situation. For these reasons, new models for mobile applications have appeared recently. People-as-a-Service (PeaaS) allows interactions between mobile devices in their surroundings, using sociological profiles of their owners to create communication between interested devices. Social Devices is a recent model that implements the PeaaS concept, taking advantage the devices are almost always with the user it creates a new kind of interactions between nearby devices with the main target of improve social relations. For this purpose each device is able to provide services to nearby devices and consume them, keeping the user’s data in the device and sharing it only when it is authorized. This concept could be integrated with technologies like Internet-of-Things and Ubiquitous Computing, allowing devices to connect with nearby objects like elevators, traffic lights or your own vehicle. In particular, there is a new platform that implements both concepts, which is the study object of this work: OrchestratorJS. The platform is still under development and is not too stable yet, furthermore there is no documentation available. The main target of this work is to explore the platform and to create a basic documentation which could be used for anybody interested on the in, acting as a starting point for future works. Keywords: Social Devices, People as a Service, Proximity-based Cooperation, Ubiquitous Computing, OrchestratorJS. 7 Index INDEX ............................................................................................................................................... 7 INTRODUCTION AND GOALS ........................................................................................................ 9 CHAPTER 1: PEOPLE-AS-A-SERVICE ........................................................................................ 13 CLOUD-ENABLED MOBILE DEVICES ................................................................................................ 13 PEOPLE-AS-A-SERVICE .................................................................................................................. 15 PEAAS ARCHITECTURE ................................................................................................................. 16 CURRENT IMPLEMENTATIONS ......................................................................................................... 18 THE INTERNET OF PEOPLE ............................................................................................................. 22 INTEGRATION WITH SOCIAL DEVICES AND INTERNET OF THINGS ...................................................... 26 CHAPTER 2: SOCIAL DEVICES ................................................................................................... 31 THE ACTION-ORIENTED PROGRAMMING MODEL ............................................................................. 32 REQUIREMENTS AND CHARACTERISTICS OF SOCIAL DEVICES .......................................................... 37 ARCHITECTURE ............................................................................................................................. 39 ORCHESTRATOR.JS ....................................................................................................................... 40 TOOLS .......................................................................................................................................... 41 GETTING THINGS WORK ................................................................................................................. 49 ANDROID CLIENT ........................................................................................................................... 52 CHANGES AND ADDITIONAL FEATURES ............................................................................................ 54 GOALS.......................................................................................................................................... 56 EXAMPLE: THE COFFEE BREAK MACHINE ....................................................................................... 57 CHAPTER 3: RELATED TECHNOLOGIES .................................................................................. 61 ANDROID PROGRAMMING .............................................................................................................. 61 MONGODB ................................................................................................................................... 67 NODE.JS ....................................................................................................................................... 70 CHAPTER 4: GETTING STARTED WITH SOCIAL DEVICES ..................................................... 75 DEPENDENCIES ............................................................................................................................. 75 INSTALLATION ............................................................................................................................... 76 GETTING STARTED ........................................................................................................................ 79 EXECUTING A FIRST ACTION ........................................................................................................... 82 STARTING THE DEVELOPMENT ........................................................................................................ 83 CHAPTER 5: APPLICATION HITHERE! ....................................................................................... 89 CHAPTER 6: APPLICATION EGREETINGS ................................................................................ 97 CHAPTER 7: APPLICATION FOLLOWME ................................................................................. 103 CHAPTER 8: APPLICATION HAVEYOUMET ............................................................................ 109 CHAPTER 9: APPLICATION TREASUREHUNT ........................................................................ 115 CONCLUSIONS AND FUTURE WORK ...................................................................................... 119 CONCLUSIONES Y TRABAJO FUTURO ................................................................................... 121 ANNEX 1: NPM MODULES ......................................................................................................... 123 REFERENCES ............................................................................................................................. 127 8 9 Introduction and goals Nowadays smart devices have an excellent potential and connectivity, and can be used for multiple purposes: entertaining, socializing or sharing information. We have applications capable to do everything with the help of web services and cloud computing. However, we have currently some limitations. These days everything is something-as-a-service. We are used to Software-as-aService and Platform-as-a-Service that have been well accepted by the industry. Now, when the usage of mobile devices have become customary for the majority of population, probably it is the moment of a new model. Mobile devices are becoming the most important piece in the communications, and they contain a lot of information about the owner. We could use this advantage to create a new type of communication, where devices interact with other devices as people would do. The goal of this work is to learn about a new model, called People-as-a-Service [18][19], where mobile devices can deploy services to interact with other devices in their surroundings. In particular, this work studies the platform called Social Devices, developed as a research work by the University of Tampere in conjunction with Nokia [26]. This platform is currently in development and there is no documentation or further information available. The main target of this work is to analyse the potential of the platform Social Devices, to study all the capabilities and create a base documentation about it that could be used for future works. I have created some case studies to study the potential and capabilities of the platform, which are completely documented to prepare the way for future projects. All the effort has been concentrated in researching and understanding the platform, documenting everything properly to facilitate the work for future projects using this platform and technology. The platform is not finished and there is a long way to integrate everything, I have been collaborating with Niko Mäkitalo and his team in the University of Tampere improving some aspects of the platform and the Android client. The code is public to everyone and can be accessed in the next link: https://github.com/nikkis This work uses NodeJS 1 and Python 2 as basic technologies to develop new capabilities and functionality in the platform. The server service, called OrchestratorJS is currently developed in NodeJS, and the capabilities in Python. On the other hand, the client is focused in mobile devices, so we use Java as main technology to develop the client functionality for Android devices. 1 http://nodejs.org/ 2 https://www.python.org/ 10 This document is divided into three main parts: - The first part includes the chapters from 1 to 3, which are a brief introduction to the technologies used in this work: Cloud Computing 1 , specially the model People-as-a-Service and the Action-Oriented Programming Model [1], which are used as basic architecture for the Social Devices platform. The server is developed using Node.js [35], and connected to a MongoDB [32] Database. Android Programming [4] is the technology used in the client. - The second part contains all the relevant information to understand the Social Devices Platform and OrchestratorJS. I explain in Chapter 4 how the platforms behaves, their architecture and the base of knowledge. Also I explain how to prepare and install the environment to start the development. - The third part includes the chapters from 5 to 9, one chapter for each case study. I have developed 5 small applications that can be used as a proof of concept to see what the platform can offer. Each chapter contains all the documentation to use the application and details about its implementation. Social Devices has currently two functional platforms implementing the concept. In chapter 4 we will see the first implementation, called Social Devices Platform (SDP) as an introduction to the new platform Orchestrator.js (OJS) [25]. 1 http://en.wikipedia.org/wiki/Cloud_computing 11 Motivation This project is aligned with the strategic objectives of the research groups SCENIC, from the University of Málaga, and QUERCUS, from Extremadura on Mobile Cloud Computing and related with the research projects SeaClouds 1 and SOFIA 2 , in which is currently working the University of Málaga as many other universities across Europe. These research groups are focused in cloud technologies and mobile computing. Cloud Computing is a new concept and there is a long future for it. It reduces time-tomarket and provides on-demand scalability at a low cost to the business and a new concept is being developed: People-as-a-Service. PeaaS is a new technology in development and there are only a few platforms that integrates the concept. The purpose of this project is to create a proof of concept of what People-as-a-Service can bring to us, focused in the platform Social Devices, currently in development as a PhD, by Niko Mäkitalo in the University of Tampere. The target of this project is to do the proper investigation into the platform and elaborate a well know-how about it, exploring the possibilities and preparing all the documentation for further research and developments, as there is no documentation about it. The platform is currently in development and is not completely stable. The concept of PeaaS will be also interesting for people, because this new technology will allow new ways of interacting between people and devices, providing new capabilities in how we use them. Combined with Internet of Things, people will be able to interact with the surroundings, the devices will know the context data of the user, and change its behaviour depending on it, making the work for the user without forcing him to send commands to the device. Social Devices is a new platform that can be used for this purpose, it was introduced in 2011 as a joint work by Nokia Research Center, Aalto Univesity, and Tampere University of technology [26]. Smartphones have not only a lot of information about theis owners, but also capabilities that enable them to resemble humans (they can translate text into speech, for example). 1 http://www.seaclouds-project.eu/ 2 http://sofia.lcc.uma.es/ 12 19 For example, an advertiser can use this platform to create an application that sends advertising to special targets, based in their geographical position, age, interests, social status, etc. The nimBees architecture [Figure 2] is a specialization of the one defined for the PeaaS model. Hence, the server and mobile architectures are designed as follows: - Catalogue server. Based on the concept of the catalogue server, a non-mobile element with a fixed and well defined service entrypoint where every new mobile device added to the PeaaS network must be connected, in order to authenticate and provide information about itself, and to retrieve information about the rest of connected devices. This catalogue server is called The Hive in nimBees. - Mobile Service Environment. They are basically mobile applications that must be installed on every mobile device that wants to be part of a PeaaS network, providing an execution platform in which PeasS-designed services can be deployed and executed. This is divided in four layers of abstraction: o Service Manager: This layer constitutes the core of the mobile service environment. It provides the capabilities required for deploying, removing, running or stopping services in the service container, and a basic communication interface to establish a link with the catalogue server. It also provides an interface to the user of the device to configure the mobile service environment properly. In nimBees the inference engine is also included in this level. It consists on a component that monitors user activity to extract behavioural patterns that enrich the personal information profile. The information generated by this component is used to determine whether the owner matches the user profile required by the advertiser for a certain service execution. o Service Container: This layer provides the execution environment where the PeaaS-based services are allocated, similar to a virtualization engine. The lifecycle of the allocated services is managed by the service manager layer. In nimBees this layer has been implemented as a scripting engine that provides an execution environment in which run the nimBees services, which are written using an own scripting language. o Permission Control Layer: The access permissions to the resources and services provided by the mobile device are verified by this layer, thereby avoiding access to certain resources by unauthorized services. Users can block the access to certain resources or information in every moment and for any service. o Resources access Layer: This layer abstracts PeaaS-based services from platform-specific implementations of each resource and service offered by mobile devices, providing a standard interface to be used homogeneously by the services. In nimBees the access to the device’s 20 resources is provided to the deployed services in form of “sources of information”. Such source can be accessed by the scripting language with the proper syntax. In conclusion, nimBees is a new platform that uses the power of People-as-a-Service concept to provide a new communication channel to the users, which can be used for advertising companies to communicate with specific groups of users in a new and move powerful segmentation capabilities. Introducing BeeFun Mobile marketing is a great niche for PeaaS, Google and Facebook are clear examples of how collecting sociological information from advertising targets has become extremely important to companies [10] [16], but with their model is difficult to gain user satisfaction. They try to create apps as tools for launching personalized recommendations to device owners, while digital advertisers can get segmented data about the users and show targeted and relevant advertising to them. However, the sociological profile is always centralized on company servers, providing no transparency to the user and without a privacy guarantee about his data. Here is where PeaaS presents an alternative applied to mobile marketing that could benefit both consumers and advertisers. BeeFun 1 is a mobile app developer for Android and iOS that makes use of the nimBees messaging infrastructure. It was developed by Gloin and allow users to interact with new kinds of targeted messages based in criteria such as age, city of residence, sex, current location, etc. It is a potential example for this market and the capability to provide rapid feedback on its benefits. What BeeFun offers is the ability for advertisers to anonymously query advertising targets’ sociological profiles to retrieve collective information about their preferences, areas of interest, and so on. This completely segmented data lets advertisers refine their marketing strategies and potentially increase their campaigns’ effectiveness. Furthermore, the interoperation possibilities supported by PeaaS, and consequently by BeeFun, let advertisers send out interactive ads to the app’s users on the basis of their profiles. Interoperation between advertisers and targets is carried out through the services that advertisers can deploy in the devices. BeeFun is at the moment a merely a proof of concept and the applications and services have to be written in his proprietary scripting language, which contains basic instructions to ask the inference engine about the user’s sociological profiles, request notifications and visual content to display on the user interface, and return and execution response to advertisers. 1 http://www.beefunapp.com/ 21 All the services that advertisers can deploy in mobile devices are maintained in an external catalogue of a Hive system, which registers all mobile devices connected to the network and manages the deployment and execution of services and applications in the devices. The most important thing of this system, and which differentiates the PeaaS model from others (like Google of Facebook), is the accordance with the fourth pillar. The sociological profiles are always kept in their devices, with only some of the information, voluntarily given by the users) saved in the hive. This basic information allows the advertisers to interact with targets, because it would be difficult to find the targets without a centralized system. The hive system lets the system preselect potential targets on the basis of this information. Then, the devices’ inference engines still must evaluate the target’s suitability. Conclusions Through this implementation of PeaaS we can explore new forms of mobile marketing that allow advertisers to reach their targets more precisely. It allows accessing detailed sociological profiles of the targets and retrieving collective information about them. Targets are able to provide their opinions about products and ads while preserving their privacy, what is an innovation in this field. The technology allows the generation of a view of collective interests, which could be relevant for market studies. By focusing on people and their mobile devices as information sources, we can continue to think of a new advanced computing models that provide numerous benefits. Mobile-centric computing architectures can prove their great capability to generate sociological profiles through applications such as BeeFun. Applying this model in fields with a high social impact could be extremely beneficial for society. PeaaS could let organizations identity patterns that could be contributing to health disorders among large communities. They could user this information to plan strategic actions that could help increase individuals’ life expectancies. In government, PeaaS could allow retrieval of collective information about citizens’ political views and preferred courses of action to enhance living standards and promote democracy. However, the success of PeaaS requires a wide adoption by mobile device users, they need to receive some benefits in exchange for participating. PeaaS gives users more control over their privacy, but perhaps they could receive benefits from the companies using their information. For example, discounts for people using the PeaaS platform. Additionally, a third-party company that uses the platform to reach users could monetarily compensate those users or give them its products or services for free or a discounted price. 22 The Internet of People There is growing interest in developing applications on the Internet of Things. The main objective of these applications is to integrate technology into people’s everyday life in order to be a service to them. However there are many things to improve in the implementation. Usually, the user needs to set parameters within the application, and reconfigure them when the context changes. Nowadays Internet is available almost everywhere, connecting everyday physical objects to the Net is getting ever easier. One of the main goals behind such smart integration of devices is to simplify people’s lives by having technology work for them seamlessly [6]. For instance, you can remotely switch on your house’s air-conditioning system using your smartphone to get a comfortable temperature when arriving home. However, how IoT technologies are currently integrated with human still leaves much room for improvement [17]. We need to develop suitable mechanisms to properly adapt to people’s context and make the tecnology able to work for people. Currently people are forced to change their context to fit technological requirements. Technology should take people’s context into account, learn from it, ant take proactive steps according to their situation and exceptations, avoiding user intervention as much as possible. In this desirable scenario, the air-conditioning system will know where we are in our way back home, instead of switching on at specific preconfigured time. Enabling such scenarios requires moving from the Internet of Things to the Internet of People (IoP) [30]. In this infrastructure, smartphones play a central role, reflecting their current user as the main interface allowing people to be connected to the Internet. However, the smartphones have to meet a serie of requirements and capabilities [28]: - The smartphone needs to be capable of learning about its owner and their context, constructing a digital profile. - It needs to transparently negotiate and propose interactions with other devices on the Internet, reacting to stimuli and handling relationships. - It needs to be able to manage digital profiles and act accordingly, providing its owner’s context as a service for others, and scanning for services that might be of interest to its owner or to update the digital profile. The infrastructure to support the IoP concept can be achieved with a combination of the Social Devices 1 and People-as-a-Service platforms. Social Devices enhances the proactive capabilities of smartphones to orchestrate their interactions with other devices connected to the IoT. PeaaS provides smartphones with serving capabilities that allow people to offer services from their devices, including their context and sociological profile. The combination of these two contributes to constructing an IoP by allowing 1 http://socialdevices.github.io/ 23 people’s context information to be included in the coordination and interaction management of IoT devices. The main benefit is the integration of people as first-class citizens in the IoT universe, opening the way to the development of new kinds of humanfriendly services and applications. As smartphones contains a lot of information about their owners, and sensors to retrieve contextual information about the surroundings of it and, consequently, about the owner, they are the perfect device to be the central piece of this new concept [30]. Smartphones can reduce the complexity of user interaction with IoT-linked devices. They can know the user’s circumstances, as they are almost always with the user. The contextual data can be used to know information about the user and to learn about him and to detect how the person behaves when they are at certain locations or surrounded by certain other people. One of the most important aspects of People-as-a-Service is the fact that all the information about the user is kept in the owner’s device, and is securely provided as a service to third parties directly from the smartphone. The user can limit who can access to that information and know who and when is receiving it. The user can control his sociological profile and all the information easily, just modifying or deleting it from the device. PeaaS allows a variety of information to be collected, such as the moods, trends, social statuses, and health habits of a group of people, in order to define their digital profile. Current IoT technology needs people-centric enhancements. As set out in (Miranda et al., 2014) [30], the goals for any pervasive computing context should be: - Be social: Interactions in which things, devices and people participate must be social. The IoP should allow for heterogeneity by supporting the different types of devices that people use, allowing them to interact with people and other devices. Users need to be empowered to adjust their preferences and policies about when and with whom their devices are socializing. - Be personalized: Interactions between devices must be personalized to the sociological profiles and contexts of their users, providing a transparent mechanism for this customization. Users must be able to adjust their preferences in order to control how their profile is used by other IoP stakeholders. - Be proactive: The triggering of interactions must be proactive, not manually commanded by the user. The IoT should allow for device heterogeneity to allow them all to interact more proactively, without the need of manage all connected things. Users must be empowered to adjust their preferences to control how proactive their surrounding things are, this is done by proactivity policy. It is very important because can introduce security risks. - Be predictable: Interactions must be predictable and triggered according to a predictable context that the user had previously identified, and with a specific 24 behaviour defined. Users must be able to identify and tag that context, define the expected behaviour and set the privacy policies for sharing their information. The user has to know how an interaction can be stopped immediately and how to prevent a misbehaviour in future. Internet of People Middleware architecture Figure 3. Architectural description of the IoP middleware. In this architecture, the central component is the Device Registry, who maintains the information about the different devices managed by the system. The devices are classified into Companion and NonCompanion. Companion devices are those that maintain contextual and sociological information about their owners, while NonCompanions are “things” which can register their capabilities and additional information about their state. The Action Repository manages the middleware’s set of actions. Each action defines how the devices should interact with each other and with people. The Application Repository component stores the different applications defined in the IoT context and managed by the middleware. 25 The Application Manager allows people to enable or disable the different applications according to whether they would like to be present and contribute with their sociological profiles. The application and action specifications may include requests to the different Sociological Profile components of the Companion devices involved, so that the specified behaviour can be adapted to the user’s context, personality of mood. Sociological Profiles The Sociological Profile component is a fundamental part of every Companion device. This component maintains the information that has been gathered and inferred about people and their contexts. This information covers people’s behaviour, preferences and also contextual data such as location. Devices can also process contextual information such as a proximity graph of surrounding people/devices/things. Companion devices can also notify the registry about significant changes in their Sociological Profile, so that subscribed applications will be notified when an on-change event occurs, allowing them to re-run the queries to get the freshly updated information. The component also allows users to define and adjust the sharing schema for the profile. Users should define what information will be available for which applications, devices of users, and in which context the information should be provided. Finally, the Sociological Profile provides an interface for device owners to personalize the way in which the device behaves under specific circumstances. Conclusion Internet of Things is having a successful growth, however, people’s interaction with this kind of systems is still far from friendly. The term Internet of People has been used before, but it referred to traditional Web systems designed only for humans to use. Now the idea of this term is to bring the Internet of Things closer to people. Most of the profile’s customizable policies and preferences will be supported by a user-friendly wizard. The component will progressively learn the customization during the device’s use from the interactions and contexts in which it is involved, and from the owner’s decisions about how the device should behave in those interactions. To construct more human-like, predictable, proactive and social interactions between people and “things”, the IoP middleware offers a Web-based IDE and tools 1 , which we will discuss in next chapter. 1 http://orchestratorjs.org 26 Integration with Social Devices and Internet of Things People-as-a-Service and Social Devices combined provides new interactions and capabilities to users when they are co-located, but IoT can be also integrated with them, providing new capabilities and communications with everyday objects near the user. In some years 50 billion of devices could be connected [11]. Some IoT-related scenarios have been already implemented and introduced using Social Devices, for example The Social Coffer Machine [25]. This coffee machine asks to the user, based on his context, if he wants to have a coffee, and then the machine invited other people to join the coffee break. Vázquez and López-de-Ipina [50] have been working on this subject too, they introduced the concept of semantic device as a system “able to spontaneously discover, exchange and share context information with other fellow semantic devices as well as augment this context information via reasoning in order to better understand the situation and perform the appropriate reactive response.” [48][49]. They have developed four prototypes of what they call Social Devices, integrated with The Internet of Things to make some objects capable to interact with users. They reutilize the concept of Semantic Gadget, which was introduced by Lassila and Adler as devices capable of performing “discovery and utilization of services without human guidance or intervention” [24]. This concept emphasizes even more the benefits of the communication with other devices in order to determine the appropiate behaviour. Internet is the enabling technology in this case, since the knowledge provided by local devices can be complemented with information obtained from the Internet (which is provided by other devices, services or humans). Flexeo’s SensorMap: a wireless sensor network This is the first prototype by Vazquez and Lopez-de-Ipina. The goal of this project was designing a system for remotely monitoring wireless sensor networks through the Internet, and integrating all the data into business processes in order to execute datamining operations and determine correlations among data. Scenarios related to “heatlh at home” and remote monitoring of industrial facilities were designed in order to test the resulting system. As an additional outcome, a mash-up of sensor collected data and Google Maps was developed, called SensorMap. This subsystem illustrated the potential applications of publishing up-to-date sensor data on the Internet in order to dynamically integrate different sources of information for providing higher level services. The next [Figure 4], from [50], shows a sensorized chair with two pressure sensors (at the seat and at the back) connected to a wireless sensor network node in order to provide information about its use to local and remote objects. [Figure 5] contains a 27 screenshot of the SensorMap application showing the state of the chair (if someone is sat on and/or leaned backwards). Figure 4. Pressure sensors in the chair. Figure 5. Flexeo’s SensorMap showing the state of a chair. 28 RealWidgets: from the desktop to the real world With RealWidgets they wanted to embody the functional capabilities of these digital entities into real world tiny wireless displays, in order to have small “windows” deployed everywhere opened to the information from the Internet. The RealWidget is formed by an OLED display, with high resolution and contrast while small energy consumption, integrated with a CrossbowMote2 wireless sensor network node. A computer acted as a gateway between the Internet and the wireless sensor network, running a RealWidget Management Application that connected to the required sites on the Web, downloaded the information, analyzed it and finally sent the content to the appropriate widget as configured by the user. [Figure 6] illustrates a RealWidget showing information about the liquid level in a remote chemical container that was monitored by a wireless sensor network over the Internet. Figure 6. RealWidged alerting about the liquid level in a tank. Two buttons were provided for interacting with the RealWidget, basically for managing the energy by postponing the information for a later time, or immediately discarding it. 35 Service Description Action registry A registry for all possible actions and interfaces that are available. Device registry A registry for all devices and their installed capabilities. This registry may also contain additional dynamic information about the devices, such as device proximities and states, as well as contain information about users and device owners. Trigger registry A registry that consists of a triggering table, which holds information about possible triggers and corresponding actions; and of an active triggers table, which holds information about trigger instances that have been observed, are still alive, and have not yet been successfully scheduled. Scheduling Management of the scheduling task. Execution Management of the action execution, that is, synchronization and coordination of the devices. Table 3. The Services in the Action-Oriented Programming Model Infrastructure. Figure 10. Actors, artefacts and responsibilities in the action-oriented programming model infrastructure. 36 There are several actors and they interact with the artefacts in different ways [Figure 10]. - The infrastructure provider deploys and administers the Action-Oriented infrastructure. - The capability developer is responsible for implementing the capabilities for the devices, accordingly to the defined interfaces. - The action developer uses the interfaces to execute the necessary capabilities in each device. The developer doesn’t know the identities or characteristics of the devices, and how the capabilities are implemented. - The user installs the desired capabilities to the device. - The device could be considered as an actor too, it will register itself to the infrastructure at runtime, and constantly reports dynamic information about its state. The order of the illustrated events can be different, because the action developer can reuse existing device capabilities instead of writing code for new device capabilities to support multiple mobile platforms. The three basic steps to create an Action-Oriented program would be the following: - Define or implement the interfaces for the necessary capabilities of the device. - Define the actions to be executed, the program itself, and specify the needed preconditions for starting the action. - Define the triggers that initiate the actions. 37 Requirements and characteristics of Social Devices Our devices have a lot of information about us, maybe our mobile phone knows where we want to drive when we enter in the car, and it can communicate our destiny automatically to our GPS system. Also at the office, employees’ devices can synchronize each user calendar to stablish the day and time of a meeting, and then communicate the result to each employee. The concept can be taken beyond, for example, our device knows we have a meeting in the third floor, so it could send that information to the elevator when we enter in it. The key of Social Devices is to utilize resources and capabilities of multiple physically co-located devices and the proximity of the devices in a user observable manner. Some of these devices can be stationary, like an elevator or the screen in a meeting room. This technology would fit well in conjunction of other technologies like pervasive computing 1 [7] or Internet of Things [17]. However, Social Devices requires some devices capabilities to be able to work in each device. The device must be a computationally capable device and be able to interact with other devices and users in their proximity, for example via Bluetooth. This requirement is easy to accomplish for devices like mobile phones, laptops or computers, but is difficult for other kind of devices like elevators, GPS systems, cars, etc. The capable devices need to have identities, so the platform would be able to keep track of the device identities. Devices collaborate in a way that is often personal to the user and related to user preferences. There is a centralized registry where devices need to register their identity and capabilities. The platform allows to register multiple devices for each user and select which of them is the principal, the most used. Another requirement is the need to know which other devices are nearby the device. Social Devices interactions work in a co-located way, and require that users and devices are near each other. Thus, the proximity of devices needs to be discovered and stored in the Social Devices Platform, who maintains proximity information in a form of a mathematical graph, where nodes denote devices and edges denote the distance of the devices. This information is acquired by the devices and reported to the centralized server, who updates the proximity graph. There is also a need to know what different collaborative actions are available between devices. The platform manages action descriptions centrally. As we have seen, an action has a body and a precondition. The body describes what the action will do, and the precondition is a set of requirement to be comply the device to be able to execute the action. Each device has a set of enabled capabilities that can be used by the running actions, having a required capability could be a precondition to execute a determined action. Also we may need to know which kinds of devices can participate in an action, what will be also captured in the action precondition. 1 Pervasive computing, also called ubiquitous computing, is a concept where computing is made to appear everywhere and anywhere. 38 Capabilities are a way to manage permissions in Social Devices. The user can enable or disable different capabilities. For example, there is a capability able to speak aloud by synthesizing text, if the user doesn’t want the device can speak, he can disable the capability. However the user won’t be able to execute actions that require that capability. The condition when actions are executed needs to be decided automatically at runtime, but the preconditions are not only about static capabilities of devices, but they may constrain dynamic properties changing on the device. Dynamic conditions that affect whether a device can participate in an action are monitored via device states. The devices continuously report their states to the central server, so it has all the necessary information to decide if the action can take place or not. States can be based on general preferences of the user as, for example, if the device is in silent mode. All the conditions have to be evaluated without user interaction, but continuous searching for devices and evaluating preconditions is computationally hard. Here is where triggers take place to mark the need for action execution. Certain actions are attempted to be scheduled when a certain trigger is received. A trigger can be an update in the state of the device, a proximity change or an external event. The devices only need to identify the condition to raise a trigger, which will be received by the central server, who decides whether and which action must be initiated. Also when executing an action, one has to decide which concrete devices will participate in it. The main task is to relate the potentially available devices to the preconditions stated in the action description and to decide the roles that will be assigned. Sometimes the same set of devices can participate in the action with different roles, for example in a dialog application. Finally, the action needs to be executed, but each device has a different software and hardware features. The action coordination or orchestration requires defining a control flow for each device, regardless the different software or hardware specifications. In the SDP there is a generic system where various cooperation possibilities are available defining a platform into which coordination is built in. These requirements and characteristics are necessary primarily for user and private devices, because they must allow the owner to change their preferences and save the privacy of the user. However, for public Social Devices, like an elevator, there is no need to evaluate preconditions or capabilities, cause is a simple device which only will accept requests of nearby devices and act accordingly. 39 Architecture This is the basic architecture of Social Devices, the devices are registered in the Controller component in the server, and the user can install the interfaces and capabilities he wants. Once connected, the device will look for nearby devices and report them to the server, what will trigger some events. The server then evaluates if there is an action available to be executed for this device, and orchestrator executes it. Figure 11. The basic architecture of Social Devices, and connections done step by step. 40 Orchestrator.js We have seen a small description about Social Devices Platform, who implements the concept of Social Devices. However we have seen it as an introduction to the new platform, called Orchestrator.js and implemented by the same group of developers. This new platform is the focus of this work, and it is more powerful than SDP. Orchestrator.js (OJS) is a completely new middleware that supports Social Devices concept. It is implemented as a single cloud service that offers a complete set of tools to implement and prototype Social Devices applications. It is specially designed to implement interactions between devices and people, and for observing situations when these interactions should proactively get triggered. Social Devices applications differ from traditional mobile apps, but Orchestrator.js can be easily hosted on any regular computer and be used for quickly developing multidevice applications. The main task of Orchestrator.js is to maintain persistent connection to devices, store applications and contextual information of devices, and offer means for triggering applications. Architecture Orchestrator.js is based on Node.js 1 and the communication is based on Socket.IO 2 Protocol. This offers highly efficient input/output operations between Orchestrator.js server and its devices. The server is formed by the following components: - The Orchestrator Core creates new action instances and makes sure that the actions work properly. It maintains the connections to devices and coordinates the devices by handling incoming and outgoing events based on the logic defined in actions. - The Application Manager stores and executes the applications, allowing users to start/stop them, and stores user-related settings that may be required by the application. The applications are like daemons or child processes that run constantly and monitor changes with help of observers. When the app detects changes, it uses some scheduling algorithm defined by the developer to determine whether some interaction should take place. - The Device Registry maintains contextual state information about each device, which is stored to MongoDB 3 database. Moreover, the registry maintains the proximity graph of the devices, which is formed based on Bluetooth signal strength values (RSSI). This allows triggering applications for a set of devices that are close to each other. 1 Node.js is a server-side JavaScript platform built on Chrome’s JavaScript runtime. 2 Socket.IO is a new non-standardized protocol for relying events between device and server. 3 MongoDB is an open-source document Non-SQL database. 41 - The Action Repository contains the action definitions stored by the developers. Basically these definitions are JavaScript files which each contains precondition, error handling, and the description of joint behaviour of devices and interactions between users by utilizing device capabilities. - The Capability Repository contains descriptions of each capability, like Java’s interfaces. The functionality is not written here, this only defines what methods the capability must implement, and what parameter each method takes. The developers must implement the capabilities like they wish and using whatever language, as long as they follow the capability description. Tools OrchestratorJS offers a web-based user interface named Web Console. Users can manage their profile and their devices, and to start and stop the applications from this console. It can be used directly from mobile phone’s browser and also be embedded inside mobile apps with WebView UI components. Figure 12. Web Console view where the user can add, modify or remove his devices. From this view, users can add, remove and manage their devices. In [Figure 12] we can see 2 devices registered to my account. Each device has an identifier, composed by the username and the device name. We can see all the registered devices in the Device Monitor view [Figure 13]. In this view we have all the information available by the platform of all the devices. For example, we can see the Bluetooth Address, UUID, Owner, Type of device, enabled capabilities, and the context data. Only registered devices can be used in the platform, so when a new user wants no use the application, he has to register the device using the Web Console, and enable all the desired capabilities. Devices can be modified and removed, so if the user doesn’t want to continue using the platform, he can remove his registered devices. All the information about that device will be totally removed from the platform, and won’t be possible to use it anymore. 42 Figure 13. Device Monitor with my registered devices. All the enabled capabilities appear in the view, they are codified as a coloured square. We can enable the desired capabilities in the server-side from the same view where we register new devices. Figure 14. Register new Device view. From this view we can add all the information about the device, and enable the capabilities we want to use. 43 The Web Console also offers a Web-based IDE for implementing the applications without install any software. Developers can define capabilities, actions and observers directly from their browsers, and trigger them manually for a predefined set of devices. We can see, create and modify actions from the Actions  Definitions menu. We will see a view like [Figure 15]. All the defined actions will appear on the right menu, also create a new Action is possible with the first option. On the left we have a big editor where we can introduce the body of the action. This editor is very powerful, it will colours the syntax while we are coding and show the line numbers. This IDE allows us to program actions entirely without the need of an external software. We can save the action directly to the server pressing the Push button. Figure 15. Example of the Actions Definition view, with the Apocalymbics action loaded in the editor. We have two fields below the editor which allows us to execute the action in a device. Parameters can be devices or simple data like Strings, Integers, etc. Figure 16. We can select devices to execute the action directly in the dropdown list. 44 Capabilities are implemented with the native platform specific tools, like with Eclipse (Android), however, the OrchestratorJS platform offers a tool for defining the capability descriptions. This view [Figure 17] is pretty similar to the Actions Definition view, with all the capabilities on the right menu and the editor on the left. Figure 17. Capabilities interface example, in this case with the PlayerCapability loaded. In this interface we can define all the functionality for this capability. We can add comments to explain them. All of the functions defined in the interface must be implemented in the device [Figure 18]. Figure 18. Implementation example of the function setVolume of the PlayerCapability in Android. OrchestratorJS is available for Android, iOS, .NET Gadgeeter and Python using these capabilities. We only have to implement the capabilities in each device in their native language, and the Platform will call the functions. 51 If we need to read information from a website we can use the class request. Invoking actions is done with the httprequest class and calling the REST API of the platform. Figure 26. Calling an action from an application. Invoking an action is achieved sending the corresponding POST message to the REST API. We can also create and manage Fibers, which will allow us to create periodic actions, poll websites, and check if any user has request information, etc. A Fiber is basically as a Thread in any conventional programming language. In the same way, we can use any function and library in NodeJS. The possibilities are endless: access a database, create sockets, connect to a web service, etc. Figure 27. A basic Fiber printing a message each 10 seconds while the application is running. 52 Android Client Now we understand how the server works, let’s see how the Android client connects to the server, manages capabilities and executes the actions sent by the platform. The main class in Android is the OrchestratorJSActivity.java. This class contains the basic functionality of the client: connection to the server, management of capabilities, invocation of actions, settings and configurations. All the classes must be inside the main package com.ojs. The main class will execute when we open the application, it has a minimalized view with two small buttons, to connect and disconnect. The first time we execute the application it probably won’t connect to our server because it needs to be configured. In chapter 4 we will see how to install and configure everything. When the device connects to the platform a small message appears, if the connection is lost it will be also noticed with a small message at the bottom of the screen. The device will try to load all the enabled capabilities. Capabilities are differentiated through packages, each package means a different capability. All the capabilities must be in a package called com.ojs.capabilities.myCapability and they must implement the public method initCapability( Context applicationContext ). Figure 28. initCapability method from the hashTagCapability. 53 Note: The name of the package and the capability class are very important. The client will try to locate the capability in a package with the same name as the capability in the server, but with the first letter in lowercase. Also the name of the class that implements the capability must have exactly the same name as in the server’s capability interface. As we can see in [Figure 28], the capability name is HashTagCapability, which is the name in the server’s capability interface. The name of the class implementing that capability must be the same, and the name the package is hashTagCapability, with the same letter in lowercase and inside the package com.ojs.capabilities. The capability must also implements the method initCapability as in the figure. In one of these steps fail, the capability will be automatically disabled from the client 1 . Once this is accomplished, the capability will be able to load in the device and it is ready to execute the actions sent by the server. The capability should implement all the functions defined by the server’s capability interface. If one of the functions is not implemented, the device will send an exception to the server when an action tries to trigger the method. Usually a capability will create a new Activity in the device, this is not too much different as creating a normal activity in a usual Android application. Methods in capabilities can have arguments to receive information from the server, in this example I have the method showNotification, which receives a title and a message. Both arguments are sent to the new activity through an Intent. Figure 29. Implementation code in Java for the method showNotification of NotificationCapability. Then, we can read the Intent in the created activity and use the data properly. 1 This is one of the features I have implemented. 54 Figure 30. NotificationCapability interface deployed in the server. The capability installed in the client should implement all of these functions. Changes and additional features To accomplish the target of this project and be able to develop the five test applications I have to make some changes and develop new features in the platform. I will explain here what these changes are and how they work: - Triggering observers when the arriving data is the same: In the original platform when context data arrives to the platform, it didn’t trigger the observer if the content was exactly the same as the platform already had. I have changed this behaviour because sometimes I need to trigger the observer. For example, in some applications the server asks the user to introduce data, like the phone number. When the user introduces this data the application can start, however, if the user introduced the same phone number as the existing one in the platform (what is very probable), the application didn’t trigger the action. - Changed the RSSI Bluetooth values: I have created 5 different ranges to determine the distance of a device based in the RSSI Bluetooth value. I changed this values because it would be better if we have a better approximation of the distance. Also the original values had negative values (and my devices send a value between 0 and 255), and sometimes the proximity graph didn’t draw correctly because values were too much high. - Added support for Bluetooth proximity in the Android client: originally when I started my project the Android client had no Bluetooth support. I have implemented it in my version. Later, a Bluetooth service was integrated in the main platform. However, both services can coexist in the application. I had implemented the Bluetooth support as a capability, what the user can enable or disable from the device. Server applications call this capability when an update of the Bluetooth proximity is needed. 55 - Automatically disable unimplemented capabilities in the Android client: if a new capability interface is deployed in the server, probably our installed Android application has no support for it. I have changed the behaviour of how capabilities are activated, so the user won’t be able to enable capabilities not implemented in the client. Uninstalled capabilities can’t be selected in the menu [Figure 31]. - Handle disconnection from the server to finish capabilities: in my implementation I use some capabilities as a service, this services can, for example, constantly update Bluetooth proximity or GPS position. I have added a trigger when the connection with the server is lost, to allow finish some operations that have no much sense to be in execution once the client is disconnected. - Improved debug messaged and clean-up: sometimes the console was difficult to read because some debug messages appear really fast. I have done small improvements in this aspect to be able to read the debug console in an easier way. I have also added some error messages to the Android client. Figure 31. Not installed applications can’t be enabled. - Bug fixes: some small fixes and improvements in the platform and the client, to avoid crashes and random disconnections of the users. 56 Goals The main goal of OJS is to support Social Devices concept, this means that the middleware is targeted to facilitate and increase interactions between people and devices when they meet face-to-face. The objective is to coordinate devices wherever they are in the proximity of each other. Service compositions may be different as another platform, the main separation is that the devices can independently socialize, starting to resemble humans, and getting similar characteristics. Apart the main goal, there is a set of four goals the system should meet [8] (Bronsted, Hansen, & Ingstrup, Service composition issues in pervasive computing, 2010): Context Awareness The system should be able to respond context changes by providing information or executing a command. OJS is specially designed to compose the services in an ad hoc manner as the interactions (actions) are very momentary by their nature. Furthermore, OJS can report and store heterogeneous and sparse context data. As we have seen, the platform supports the implementation of observers, which can be used for reporting and receiving notifications to react these changes in the context data. The developers can define their own logic to do that, and decide how to inform the user. Managing Contingencies The second goal is to manage contingencies. OJS actions are JavaScript modules that contain the interaction definition (body), but also contain three optional methods: precondition, warning and error. If the error method has been defined it gets called when an exception is thrown in the action body, or in device-side code. OJS automatically relays exceptions from device to the server. - The developer can use the error method to trace what happened, and react accordingly, for example informing the user. If the error method is not defined, the default method kills the action process. - The precondition is used for making sure that the action can take place, which helps to prevent the contingencies already beforehand. For example, we can define as a precondition that a certain device must be connected, or the context data has a special value. So the action won’t be executed until these preconditions are not satisfied. - The warning method works similarly than error method, but it is used by the device-side developer to manually inform the action about some minor error cases. The default handler does not kill the action. 57 Leveraging Device Heterogeneity According to the third goal, the system should distribute responsibilities in the composition on the basis of capabilities of different types of devices. One of the main concepts of the Action-Oriented Programming Language are capabilities which are used for describing what a device can do. This makes it straightforward for the app developer to pick appropriate devices for the interactions and set their roles. The contextual information stored in registry, as well as the information in social media and other party services, can be accessed within app and interactions. It is possible to define algorithms to always select the device that best fits for each purpose. Moreover, the constantly extending support for mobile and embedded devices allows taking advantage of many of the everyday physical objects to OJS, which also supports the goal as it helps to build custom devices to some specific purposes. Empowering Users The fourth goal demands that a pervasive app should change purpose and functionality over their life time, and also that the automatic solutions for this do not always work, so the middleware should offer means for the user to recompose the service. The architecture of OJS and the concepts of AcOP model allow users to control interactions in several ways. The user can now easily control what application he wants to run and what interactions his phone can take part to, by enabling or disabling device capabilities. If the user never wants the phone to talk, he can easily disable that capability. If the device is taking part in an undesired interaction, he can easily stop the application. Example: The Coffee Break Machine As we introduced before, there is an example of Coffee Machine developed using the Social Devices concept, and integrated in the Orchestrator.js Platform [25]. Here we will see a small abstract of how this prototype was developed. I think this is a very interesting prototype because it illustrates how the platform can be integrated to apply the Internet of Things and the Internet of People models. In this implementation, Bob is a worker that takes the bus every morning to his office. His mobile phone detects when he is in the bus and vibrates to ask if he wants to have a coffee when he arrives to the office. The phone sends data from sensors to Device Registry of the OrchestratorJS Platform, for example with GPS location or nearby WIFI networks, to know the user is leaving home and way to the office. 58 Figure 32. Partial code of the Coffee Machine Prototype. The user receives a notification asking if he wants to have the coffee, he can always decline having a coffee, or just ignore the notification and it will vanish after a short period. The contextual data can be stored in any format, and then be processed by the app. Maybe it’s necessary to translate the GPS coordinates to address, or calculate the distance and speed to know when Bob will arrive the office. The Device Registry allows storing contextual data in any format and publishing it through pub/sub API. Coffee Break app has two observers that get notified when user’s location changes, and when coffee is ready [Figure 33]. In lines 13 to 18 the application checks if the user hasn’t yet been asked about having coffee. When all the conditions are met, the application calls the REST API using the httprequest library to trigger the MakeCoffee action. The second observer [line 28] checks when the coffeeReady context data arrives from the Coffee Machine, which indicates that the coffee is ready. The application will then trigger the InviteForCoffee action to invite Bob and all his colleagues at the office to have a coffee together in the coffee room. 59 Figure 33. OrchestratorJS and all the components used in the Coffee Machine implementation. The application was developed using the Web IDE and it is a small example of what can be done with the platform. This prototype was developed using the platform Framework for .NET Gadgeeter. This framework allows to make the technology available for different kinds of hardware devices, which can help to integrate with IoT. 60 67 Activity States An activity can be in one of the different states during the course of its execution within an application: - Active / Running: The activity is at the top of the Activity Stack and is the foreground task visible on the device screen, with the focus and interacting with the user. This would be the last activity to be terminated in case the device is low of resources. - Paused: The activity is visible to the user, but does not currently have focus, for example because there is a dialog or another small activity on top asking for an action from the user. These paused activities are hold in memory, and can be quickly restored when gains the focus again. - Stopped: The activity is not visible to the user and it is retained in memory like in paused state. However activities with this state have a higher risk of be terminated in low memory situations. - Killed: The activity has been terminated by the runtime system to free up memory. The activity is no longer present in the Activity Stack and has to be restarted. Usually, when the runtime system is going to change the state of an activity, it sends a notification before the change. This allows the activity to react accordingly. For example, we can save all the work before being killed. MongoDB MongoDB [31] is a cross-platform Documented-Oriented Database 1 . It is classified as a NoSQL database and the data is saved in a structure of JSON-like documents with dynamic schemas, making the integration of data in certain types of applications easier and faster. It was developed by the software company 10gen (now MongoDB Inc.) in October 2007 as a component of a planned Platform-as-a-Service product. In 2009 it was shifted to an open source development model. MongoDB focuses on flexibility, power, speed and ease of use [32]: - Flexibility: MongoDB stores data in JSON documents, which is serialized to BSON (Binary JSON). JSON provides a rich data model that seamlessly maps to native programming language types, and the dynamic schema makes it easier to evolve your data model than with a system with enforced schemas such as a Relational Database. 1 A Document-Oriented Database is a kind of NoSQL database designed for storing, retrieving, and managing document-oriented information, also known as semi-structured data [13]. 68 - Power: MongoDB provides a lot of the features of a traditional Relational Database Management System such as secondary indexes, dynamic queries, sorting, rich updates, upserts (update if exists, insert if it doesn’t), and easy aggregation. This gives the wide functionality from a RDBMS, with the flexibility and scaling capability that the non-relational model allows. - Speed and scaling: By keeping related data together in documents, queries can be much faster than in a relational database where related data is separates into multiple tables and then needs to be joined later. MongoDB also makes it easy to scale out your database. Auto-sharding 1 allows to scale your cluster linearly by adding more machines. It is possible to increase capacity without any downtime, which is very important on the web when load can increase suddenly and bringing down the website for extended maintenance can cost your business large amounts of revenue. - Ease of use: MongoDB works hard to be very easy to install, configure, maintain, and use. To this end, MongoDB provides few configuration options, and instead tries to automatically do the “right thing” whenever possible. This means that MongoDB works right out of the box, and you can dive right into developing your application, instead of spending a lot of time fine-tuning obscure database configurations. Some important features that MongoDB supports are: - Replication: MongoDB provides high availability with replica sets. A replica set consists of two or more copies of the data. Each replica set member may act in the role of primary or secondary replica at any time. The primary replica performs all writes and reads by default. Secondary replicas maintain a copy of the data on the primary using built-in replication. When a primary replica fails, the replica set automatically conducts an election process to determine which secondary should become the primary. Secondaries can also perform read operations, but the data is eventually consistent by default. - Aggregation: MapReduce can be used for batch processing of data and aggregation operations. The aggregation framework enables users to obtain the kind of results for which the SQL GROUP BY clause is used. - Server-side JavaScript execution: JavaScript can be used in queries, aggregation functions (such as MapReduce), and sent directly to the database to be executed. - Capped collections: MongoDB supports fixed-size collections called capped collections. This type of collection maintains insertion order and, once the specified size has been reached, behaves like a circular queue. 1 http://en.wikipedia.org/wiki/Shard_(database_architecture) 69 How it works MongoDB can be managed in Linux from a command-line terminal. To connect to a running MongoDB server we simply execute the command: mongo [--host localhost] [--port 21017] Parameters host and port are optional, if they are not specified it will automatically connect to a database listening on port 21017 on the localhost interface. To show a list of the databases existing in the server we can execute the command: show dbs We can switch to a database using the command use and the name of the database. Note that if the database doesn’t exist it will create it automatically. That’s why MongoDB is completely flexible DBMS: use mydb db The last command db will show the current selected database. Now you are using the new created database called mydb. This new database is empty at this moment, and it won’t be shown in the list of databases returned by the show dbs until any data is stored on it. Let’s insert some data in JSON (called documents). Creating a new document is done in the same way as we would do in JavaScript: Now we can insert this new documents into the database. We will insert them in a collection called myTest: The show collections command will show all the collections existing in the database. The find command will output all the documents existing in the specified collection. 70 We can specify arguments with the value of the keys, so it will return only the documents matching the specified search: Updating and deleting data is not very different or complicated. MongoDB provides also mechanisms to iterate through returned data from queries, called Cursors. An important example of where MongoDB is very useful is combined with Internet of Things [33]. Internet of Things needs to store information from huge amounts of sensors and objects, such amount of data is too much for a relational database. Bosch has built its Internet of Things suite on MongoDB, bringing the power of big data to a new range of Industrial Internet applications including manufacturing, automotive, retail, energy and many others. Internet of Things is a big challenge for databases, each new generation of ‘things’ comes with new sensors, which create new data and new functionality requirements. Relational databases make it hard to incorporate new data and iterate on your data model. MongoDB can manage data of any structure, no matter how often it changes. You can ship new functionality without redesigning the database, allowing build apps that could never build before. Also, relational databases are not designed to handle data from 40 billion devices, while MongoDB is built to scale out on commodity hardware. Finally, MongoDB can analyse data of any structure directly within the database and in real time. In relational databases you probably need to process data and prepare for output in the correct format. Node.js Node.js [29] is a way of running JavaScript on the server, it allows to create Web applications using JavaScript entirely. Node.js is an interface to the V8 JavaScript runtime, the fast JavaScript interpreter implemented by Google that runs in the Chrome browser. Conventional servers, like Apache, spawns a new thread for each connection to the server, but this doesn’t scale well and it’s very easy to quickly lose performance or the site goes down. With Node.js this is not the case, you will need to handle the core server architecture yourself. This can be overwhelming when you start out with Node.js, but there are modules to make this easier, and result will be a high performance web application. JavaScript is an event-based language, so anything that happens on the server triggers a non-blocking event. Each new connection fires an event, received data from a form fires an event, requested data from the database fires an event. This means a 71 Node.js website will never lock up and can support tens of thousands of concurrent users [9]. In Node.js you don’t have a main code that runs constantly in the background, you don’t have to check if something has finished to continue, you will never wait for the response of a database request. In Node.js you specify functions that should be run of completion of something else, and that functions will execute when they are triggered by the specified event. Figure 38. A basic Hello World program in Node.js. [Figure 38] shows a Hello World program that simply prints the Hello World! message when a new connection is created in the port 8080. This basic example can help to understand how asynchronous class work. Node.js is based in an event driven model, what is event-driven programming? I liked this description from a Princeton University Page [15] (Event-driven programming, 2014): “In computer programming, event-driven programming or event-based programming is a programming paradigm in which the flow of the program is determined by events—i.e., sensor outputs or user actions (mouse clicks, key presses) or messages from other programs or threads. Event-driven programming can also be defined as an application architecture technique in which the application has a main loop which is clearly divided down to two sections: the first is event selection (or event detection), and the second is event handling. In embedded systems the same may be achieved using interrupts instead of a constantly running main loop; in that case the former portion of the architecture resides completely in hardware. Event-driven programs can be written in any language, although the task is easier in languages that provide high-level abstractions, such as closures. Some integrated development environments provide code generation assistants that automate the most repetitive tasks required for event handling.” 72 To do a login system, we simply call the database query when the user sends the form data, Node.js sends the query to the database, but it won’t wait for the response. When the response from the database arrives, we will have a different function triggered when the data arrives, which will send the result back to the user. This allows the server to execute instructions (for another user, for example) instead of wasting CPU cycles waiting for an IO response [52]. Event-driven programming is more complex than usual programming, however Node.js platform provides abstractions and modules that make it easier to create eventdriven applications. Node.js is single threaded, it can use only 1 CPU at any given time, but it provides functionality to have multiple processes listen on the same port. Each individual process can use a single CPU so you can scale out a multi-CPU server by using multiple processes. You can also take advantage of scaling across multiple host by using a reverse proxy, load balancing web server [20]. Figure 39. How a Node.js application scales on a per processor basis and across servers. Node.js can also take a huge advantage of JSON, JavaScript Object Notation, which facilitates data transmission between the server and the application without the need of XML. JSON is lightweight, human-readable and can be parsed directly in JavaScript. Node.js is also a good choice to develop RESTful services very efficiently and can handle thousands of requests concurrently, where PHP would just collapse. The major downside to Node.js is that it is still in the early stages of development, meaning that some features are likely to change as development progresses. In fact, the documentation includes a stability index, which shows how risky use of each feature is currently [Figure 40]. 73 Figure 40. Stability index. In conclusion, Node.js scales much better than other platforms: consumes less memory and is faster. The development can be complicated to people not familiarized with the event-driven programming model and with JavaScript, however is a good alternative to develop small and middle web applications with thousands of connected users as could be, for example, a RESTful service. Integration with MongoDB Node.js can be easily integrated with MongoDB using the package MongoJS, which lets you access MongoDB using an API that is extremely similar to MongoDB’s JavaScript shell. The package can be installed from NPM simply using the command: npm install mongojs Let’s see some examples. First step would be the connection from Node.js to MongoDB: var databaseUrl = "mydb"; var collections = ["users", "messages"]; var db = require("mongojs").connect(databaseUrl, collections); This example will create a new connection called db connected to the database mydb using the default hostname and port (localhost and 21017). We can specify different values as: var databaseUrl = "username:[email protected]/mydb"; 74 The parameter collections can be used to specify the set of collections out applicaton uses. This parameter is optional, but I recommend to set it because it will allow us to emulate a MongoDB JavaScript client like API within our Node.js application. Now, to find a document the syntax is very similar to the MongoDB console: db.users.find({sex: "female"}, function(err, users) { if ( err || !users) console.log("No female users found"); else users.forEach( function(femaleUser) { console.log(femaleUser); } ); }); This will return all the female users. This query is not like usual queries in other different programming languages. We are not waiting until the result of the query, we are sending the query to the DB and specifying the function that will be executed when the database returns the result. Saving a new document into the MongoDB database is also very similar: db.users.save({email: “[email protected]”, password: “testMongoDB”, sex: “male”}, function(err, saved) { if ( err || !saved ) console.log(“User not saved”); else console.log(“User saved”); }); Finally, let’s see how to update a document. In this case we are changing the password of the user [email protected]. db.users.update({email: "[email protected]"}, {$set: {password: "testUpdate"}}, function(err, updated) { if ( err || !updated ) console.log("User not updated"); else console.log("User updated"); }); As you have probably realized, all the functions has a parameter err, which will allow us to determine if an error occurred, and a parameter with the result of the operation. In the first query, the parameter users will include the list of results. 75 Chapter 4 Getting started with Social Devices In this chapter we will see how to install and configure the OrchestratorJS Platform and all the needed software to get the platform prepared to use and develop. This guide explains how to install the platform and all the required software in Ubuntu. I have used a Virtual Machine to install everything, but it is valid for any version and computer. Note: It’s very important to keep the same version of some of the dependencies, especially the npm modules, as the newer versions have changed some names and functions and they are not backward compatible. Dependencies My test server runs on Ubuntu 14.04 LTS, however should be no problem in run another Linux Distribution or version. However this tutorial and all the dependencies included in the CD-ROM are specific for this version, and could not be valid in any other version or distribution. - Ubuntu 14.04 LTS. - NodeJS v0.10.25. - Npm 1.3.10. - MongoDB Shell version 2.4.9. - OrchestratorJS Platform from my Github repository 1 . - Android Client for OrchestratorJS, which can be downloaded from my repository 2 . To test the applications we would need at least two Android devices, with Android 4.0 or higher, and Bluetooth capabilities. Note: Due the Platform is still under development, some applications could stop working if specifications change in the Github repository. If you want to test these applications properly I encourage you use my repository instead the official. 1 https://github.com/Jacb667/OrchestratorJS.git 2 https://github.com/Jacb667/OrchestratorJSAndroid.git 76 Installation Install Node.js Probably you can install it from the repository of your Linux Distribution, but if it’s not possible here you have one repository you might use. To add the repository to Ubuntu 14.04 you can run a terminal and write these commands: sudo add-apt-repository ppa:chris-lea/node.js sudo apt-get update Once the repository is successfully added, we can install Node.js: sudo apt-get install python-software-properties python g++ make nodejs If you have any problem to install Node.js or you want to install it in a different platform you can download and install from the Node.js website: http://nodejs.org/download/ Install MongoDB As in Node.js, probably you can install it automatically from your distribution’s repository, if not, you can add this repository to Ubuntu and install it: sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 7F0CEB10 echo ‘deb http://downloads-distro.mongodb.org/repo/ubuntu-upstart dist 10gen’ | sudo tee /etc/apt/sources.list.d/mongodb.list sudo apt-get update sudo apt-get install mongodb-10gen If you have any problem you can download and install it from the MongoDB website: http://www.mongodb.org/downloads Check if everything is correct We can check if all the dependencies was correctly installed executing these simple commands in the terminal: Figure 41. Terminal screen in Ubuntu showing the version of all the installed dependencies. 83 When these capabilities are enabled, we can go to the menu Actions  Definitions and select the action called DialogTest. This action [Figure 47] will send a basic dialog to the device, asking to answer YES or NO. The question will be also said loudly by the device, using the Text-To-Speech Capability called TalkingCapability. The action will then sleep for one second continuously while the user answers the question, once the user has answered, the action leaves the loop and reads the response, which will be output to the server console. Then, it calls the TalkingCapability again, which will say the chosen option to the user. To execute the action we can go down to the arguments field and select our device in the list. This parameter will be sent to the action as the d1 parameter of the function. Then, pressing the button trigger will send the action to the device. The device will say the question using the TalkingCapability and show the question and the options to choose. To understand how capabilities work, you can go now to the settings view in your device and disable the TalkingCapability. If you execute the same action now, it will show the question and ask the user for an option, but the device won’t use the Text-ToSpeech feature. Starting the development In this section I will explain the most important technical details that every developer should know about the platform. I think this information can be a great starting point for any developer interested in create new applications for the OrchestratorJS Platform. Note: At the moment of this work there is no further information about how to develop applications for the platform, all of this information is the result of my investigation, and could vary in future versions. Capabilities Capabilities are the main piece to develop when starting to implement a new functionality, as they are the only piece that is implemented in the client device, and thus, the only way to create new features. We will use the Web IDE to create a new capability. To open the IDE, select the menu Capabilities in the main menu of the OrchestratorJS main page. 84 [Figure 48] shows the basic interface of a new capability called CapabilityName with a function functionName. All the code inside the interface should be inside the JSON object module.exports. Inside the object we can add functions in the same way as we create JSON Objects, in the format functionName : function (parameters…). Figure 48. Basic code of a new functionality. We can add as much functions as we want, all of these functions must be implemented in the client to avoid problems and runtime errors. In this example I have created a function called functionName with 3 parameters: parameterA, parameterB, and parameterC. There is no need to specify the type of these parameters, the client will map them automatically through the name. Let’s see how this capability would be implemented in an Android client. First step will be create the right package to store the new capability. This package must be inside the package com.ojs.capabilities and the name of the package must be capabilityName, with the first letter in lowercase. Inside the package we have to create the main class of the capability. The class has to be named exactly the same as the capability: CapabilityName. Figure 49. Implementation of the method functionName in CapabilityName. Parameters of the method must be named as we defined in the interface, but they can be whatever type, including a JSONObject. Also we can specify a return type. The returned value will be taken by the server when executing the action, but the server won’t wait for it. 85 We can specify anything inside the body of the function. For example creating a new Android Activity, calling a web service, asking an input from the user, etc. The method initCapability is mandatory, we have to specify it in the main class of all the capabilities. This method will be executed when the client connects to the server and it allows to adjust any initialization settings the capability could need. [Figure 50] shows how to send context data to the server. The context data must be a JSONObject, which can include any kind of data (JSONArrays, Strings, Integers, Booleans, Doubles, Floats, etc.). This data needs a name to differentiate it in the serverside. Figure 50. Sending context data to the platform. Actions Let’s create an action which uses the new capability. To create an action from the Web IDE we can go to the menu Actions  Definitions. Actions have to be declared also inside the module.exports object, and they are really a new JSON Object. The body of the action must be always a function declared with the name body. Additional functions can be declared, for example, an exception handler, which will be executed when the device throws an exception. [Figure 51] shows a small example action which calls the method functionName from our capability. I included the library misc.js, which has a sleep method that will be useful as the return value from our capability method won’t block the action waiting for the result. We need to poll the method until the value arrives. I have implemented an exceptionHandler in this example, this method is optional and by default it will print the exception message in console and stop the action. We can specify here any behaviour to treat the exception. 86 Figure 51. Action example using our new capability CapabilityName. The body function has a parameter called device, this will be the device to execute the action. This parameter can be set in the arguments list when triggering the action. Applications Finally, we will implement a simple application which will call our new Action. Simply we have to go to the Apps menu and select the button NEW APP in the grid. This will open us the Web IDE with an example code of how to implement basic things. An application will basically monitor context data received from the devices and trigger actions based on that data. We can also create threads (Fibers) to execute periodic tasks, like poll a website or service. [Figure 53] shows the first part of a basic application. The first we should do is to include all the required modules from Node.js: Then, the JSON Object modules.exports is declared, in the same way of actions and capabilities, we have to define the name of the object and the value. An application wil have basically two objects: 87 - Settings: this object will include a list of parameters required for the application. This parameters will be requested to the user when running the application [Figure 52]. - Logic: this object contains a function with the body of the application. The settings defined can have a default value specified. Figure 52. When the user runs the application, it will be asked to introduce all the parameters defined in the settings object. In the example in [Figure 53] I have defined an observer [Line 16] which is reading the online context data. This data is automatically sent to true when a new device is connected to the platform. If the device is connected (if the contextValue is set to true), and the identity of the connected device is the identity the user has specified in the parameter deviceId, the program will continue, otherwise it will return without executing any instruction. Then, the application will call the REST API using the httprequest module, executing the action ActionName on the device contained in the variable deviceIdentity. Figure 53. Example application (part 1). 88 [Figure 54] shows the second part of the code. This part only creates a thread (Fiber) that simply prints the word tick in console every 10 seconds. Figure 54. Simple example of a Fiber of the application (part 2). Note: Always remember to save your code before executing it. To save your code simply press the button ‘Push’. If you change something in your code and you press the button ‘Start’ or ‘Trigger’ (for actions), it will execute the code saved in the server, not the code you are editing in your browser. 89 Chapter 5 Application hiThere! In this chapter I will introduce the first study application. The application hiThere! is the first of five applications to prove the potential of the platform. Also I will explain how the entire application, its actions, and its capabilities are developed, to help to understand the implementation process. The goal of this application is to read the list of contacts from the device, and automatically send a notification to the user if one of his contacts is in the surroundings. This is achieved using a Bluetooth detection of nearby devices. Each user will be asked to introduce his mobile phone number, this phone number will be mapped to the user’s identity in the platform and, consequently, to his Bluetooth MAC address, which will be used to detect the proximity. [Figure 55] shows how the application at high level. Now I will explain its details in deep, as actions, capabilities and context data. Figure 55. Activity diagram with the behaviour of the application hiThere! 90 Implementation I will explain now the most important things about the implementation. This application will use the actions: PhoneDialog, GetContactList, SendNotification and UpdateProximity. The PhoneDialog action will call the method askPhoneNumber from the phoneNumberCapability. In the client this method simply starts a new Android’s Activity, which will show a dialog to the user to input the mobile phone number. The platform sends two parameters: a message to show to the user, and a timeout, which indicates the number of seconds to automatically close the Activity if the user doesn’t introduce the phone number. The Activity will send the phone number introduced by the user in an asynchronous message, as a context data. The code in [Figure 56] shows the method to send the context data to the platform. Figure 56. Fragment of code that sends the phoneNumber introduced by the user as context data to the OrchestratorJS Platform. 91 // Devices without a valid phone number cannot participate in this app pubsub.on( 'phoneNumber', function( contextValue, deviceIdentity ) { console.log(deviceIdentity + ": " + contextValue); phoneMap[deviceIdentity] = contextValue; } ); This is the code of the observer listening for the context data called phoneNumber, the application will receive the phone number introduced by the user and will store it in an object indexed with the device identity. At the end of the application there is a Fiber that constantly executes updating the proximity of all connected devices. This will iterate through all the connected devices (devices which we have the phone number in the map) and request their Bluetooth proximity using the UpdateProximity action. // Update Bluetooth visibility of all connected devices Fiber( function() { while ( true ) { console.log( 'bluetooth tick' ); // Iterate through all the devices and update the proximity. Object.keys(phoneMap).forEach(function(key) { console.log( "request proximity on " + key ); var params = { actionName: 'UpdateProximity', parameters: [ 'device:' + key ] }; httprequest( { uri: '/api/1/actioninstance', method: "POST", form: params }, function( error, response, body ) {} ); }); tools.sleep( 30 ); } } ).run(); 92 BluetoothCapability is as I added Bluetooth support to the OrchestratorJS Platform. One of the lasts versions of the platform has added Bluetooth support too, but it is implemented as a service that runs constantly on the device. My capability is compatible with this method, but my capability allows the developer to ask for a Bluetooth update only when it is needed. This capability has some initialization code in the Android device, that code is executed when the user connects to the platform. The most important piece of code in this capability is the Bluetooth discovery: Figure 57. Piece of code that shows how the Bluetooth discovery is implemented. This Receiver is executed for each discovered device in Android. What I do is storing all the discovered devices in the mDevicesMap, which stores the Bluetooth MAC address of the device and the RSSI, to be used as an approximation of the distance between both devices. The capability has a timeout configured by the developer, after that timeout the client will send all the discovered devices. In the action UpdateProximity I configured this value as 10 seconds. That means that the device will send all the discovered devices after 10 seconds, but it will continue looking for devices and when it finishes will send all of them again. The delivery is done in a similar way as the phone number, each device is a JSON Array with the Bluetooth MAC address and the RSSI. All the devices are stored in another JSON Array, and finally everything is wrapped into a JSON Object [Figure 58]. 99 If the device is disconnecting from the platform, the application will delete all the stored data (the objects sendedMap and connectedDevices). When the user creates a new visiting card, it is sent to the platform as context data called visitingCard. This data contains all the fields and the image in Base64 format: private void sendVisitingCard() { String name = tname.getText().toString(); String address = taddress.getText().toString(); String phone = tphone.getText().toString(); String description = tdescription.getText().toString(); String email = temail.getText().toString(); byte[] b = {}; Bitmap bm = BitmapFactory.decodeFile(selectedImagePath); if (bm == null) bm = ((BitmapDrawable)timage.getDrawable()).getBitmap(); ByteArrayOutputStream baos = new ByteArrayOutputStream(); bm.compress(Bitmap.CompressFormat.JPEG, 50, baos); b = baos.toByteArray(); String image = Base64.encodeToString(b, Base64.DEFAULT); try { // Object to be sent JSONObject sendData = new JSONObject(); // Visiting card JSONObject visitingCard = new JSONObject(); visitingCard.put("name", name); visitingCard.put("address", address); visitingCard.put("phone", phone); visitingCard.put("email", email); visitingCard.put("description", description); visitingCard.put("image", image); sendData.put("visitingCard", visitingCard); OrchestratorJsActivity.ojsContextData(sendData); } catch (JSONException ex) { ex.printStackTrace(); Toast.makeText(this, "Error!", Toast.LENGTH_SHORT).show(); } Toast.makeText(this, "Visiting Card created succesfully!", Toast.LENGTH_SHORT).show(); } Then, the server will receive this JSON Object and store the visiting card in the connectedDevices map, with the device identity as key. This data is stored in the server to facilitate the share of the information between devices without having to request the 100 information from the user each time. However the data is removed from the server when the user disconnects. Finally, the last new part in this code is the proximityDevices. This code works in a similar way to the code in the last application, however in this case the visiting card will be sent to every user (connected to the platform) in proximity. Also I have added a configurable timeout in settings, set by default to 10 minutes. This means that the visiting card will be sent maximum once each 10 minutes. // Request data from proximity pubsub.on( 'proximityDevices', function ( contextValue, deviceIdentity ) { if (deviceIdentity in connectedDevices) { // My visitingCard to send var visitingCard = connectedDevices[deviceIdentity]; for (var i = 0; i < contextValue.length;i++) { var device = contextValue[i][0]; if (device in connectedDevices) { var now = new Date().getTime(); if (sendedMap[deviceIdentity] != null && sendedMap[deviceIdentity][device] != null && sendedMap[deviceIdentity][device] > now) { console.log("I have already sent to this device!!"); } else { // Don't send to this device in at least 10 minutes sendedMap[deviceIdentity][device] = new Date().getTime() + settings.timeout; var parameters = [ 'device:' + device, visitingCard.name, visitingCard.phone, visitingCard.address, visitingCard.email, visitingCard.description, visitingCard.image ] executeActionDevice( 'ShowVisitingCard', parameters ); Note that the code has been simplified, I have removed logs and debug information not needed in this example. 101 Actions can receive only primitive data (Strings, Integers, Doubles, Floats, and Booleans) as parameters, they don’t allow JSON Objects as parameters, which is the reason I have to send all the fields in the visiting card one by one instead of sending the entire object. When all the requirements are met the action ShowVisitingCard is executed in the target device, showing my visiting card to the other device. Each device will send the visiting card based on his own proximity. This means that when two devices meet, maybe they don’t interchange their visiting cards in the same moment. Some devices can take more time to discover nearby devices. [Figure 61] shows the code from ShowVisitingCardActivity which takes all the arguments, including the image, and shows the visiting card to the user. Figure 61. Example of code to read all the arguments and show the visiting card to the user. The image is sent as a String codified in Base64. This string is decoded and showed in an ImageView. 102 Conclusions This application can be very useful to businessmen who have a lot of meetings in a day. Their mobile devices can send the visiting card automatically to everybody in their surroundings. This can be a cheap way to do publicity. For example, the application could run in a small device at the entrance of a shop, and it will send the visiting card to the people who pass in front of the shop. This system could be used to offer discount coupons to clients or to make small adverts. Of course, some people can think this may be disturbing, however they can disable the capability in any moment and they will stop receiving visiting cards. 103 Chapter 7 Application followMe FollowMe is the third application. This basic application asks the user to enter their preferences in a hashtag way. Then, the application will get all the user’s hashtags and match them based on the devices in your proximity. With this application you can easily find people with your interests in your surroundings. When the devices find one or more common hashtags, they ask the users if they want to share their data with the other user. If both users answer “yes”, their social network data will be shared each other. Implementation When a new device connects to the application, it automatically sends two actions. The first, RequesthashTags, is a view to request the user to introduce his interests. The second action, RequestSocialData, will request the social network data of the user. Figure 62. First part of the followMe code application with the login observer. This data will be sent by the Android client, and receive by two different observers: // Observer for hashTags pubsub.on( 'hashTags', function( contextValue, deviceIdentity ) { deviceHashTags[deviceIdentity] = contextValue; console.log("hashTags " + deviceHashTags[deviceIdentity]); } ); 104 // Observer for socialData pubsub.on( 'socialData', function( contextValue, deviceIdentity ) { contactDetails[deviceIdentity] = contextValue; console.log("socialData " + contactDetails[deviceIdentity]); } ); The user has no limit in the number of hashtags he can use. To add a new hashtag he has to simply press the button New tag. To remove a hashtag he can swipe it from the list. Used hashtags are also saved in the Android client, so the user doesn’t have to specify them when he disconnects and connects again. They will be there and the user can send them back to the server of edit them before delivering. Finally, this application also uses the UpdateProximity action, which updates the proximity of all connected devices each 20 seconds. This is the code to retrieve the saved social networks from the Android device: public void requestDetails() throws Exception { Log.d(OrchestratorJsActivity.TAG, "requesting Social Network data!"); try { JSONObject sendData = new JSONObject(); JSONArray socialData = new JSONArray(); Account[] accounts = AccountManager.get(applicationContext_).getAccounts(); for (Account account : accounts) { if (account.type.equalsIgnoreCase("com.twitter.android.auth.login")) { JSONObject cuenta = new JSONObject(); cuenta.put("twitter", account.name); socialData.put(cuenta); } else if (account.type.equalsIgnoreCase("com.facebook.auth.login")) { JSONObject cuenta = new JSONObject(); cuenta.put("facebook", account.name); socialData.put(cuenta); } } sendData.put("socialData", socialData); OrchestratorJsActivity.ojsContextData(sendData); 105 This code will read your social network data from Twitter and Facebook. Support for more accounts can be provided, and an option to let the user which of them he prefers to share or not. [Figure 63] shows the main implementation of the proximityDevices observer. This is the main code of the application. This observer will iterate all the nearby devices reported by your device, comparing their hashtags with yours to find potential matches. It has a cool down timer like the last application to avoid sending the notification several times to the same user. Figure 63. Main implementation of the proximityDevices observer. 106 However, this application doesn’t user your proximity data to send your information (like the eGreetings app). In this case, the first device who finds the potential hashtag match will start the action. The timer will be set in both devices, to avoid to call the action again when the second device’s proximity sensor finds the current device. Once the application has found all the common hashtags, it will call the action SendRequestInformationDialog with 5 parameters: the device identity I have found, my own device identity, the list of common hashtags, the JSON Object converted to String (Stringified) with the contact details of the first device, and the contact details of myself. [Figure 64] shows the implementation code of the action. This action will send a dialog to both devices asking if they want to share their contact details with each other. This is done using the capability DialogCapability, one of the original capabilities from the OrchestratorJS Platform. This capability will create a small dialog with the options YES and NO, with a timeout of 60 seconds. If both users answer YES to the sharing of contact details, both devices will share the information each other and the action will finish. Figure 64. Implementation of the action SendRequestInformationDialog. As we have seen in previous examples, requesting data directly from a capability is not synchronized, what means that the action won’t wait for the response. That means 107 that the action has to poll it constantly until it receives the response. This is achieved using the sleep method from the misc.js library, which will sleep the running action for 1 second. Conclusions This application can be useful to meet new people with same interests. Probably every day when you are going to the work, shopping, or home, you pass near people with your same interests. This system can be very useful to help people in the street. If someone is looking for something he can configure an alert in the device, for example, he is looking for a room to rent in the neighborhood. Probably you are renting a room, so you can configure the advert in your device and when you are nearby in the street Social Devices will do the rest to join you. 108 115 Chapter 9 Application treasureHunt The last application is a small treasure hunting game where the users can play and compete each other. This application also combines GPS location with Bluetooth proximity to know where you are and what do you have in your surroundings. Each treasure can have some information like a name, a description or hint, the GPS location, a score, etc. There is also a scoreboard with the scores of the players. Implementation Treasures are static devices, they cannot move and they can be implemented in any device with Bluetooth capabilities. They won’t need to execute the client neither Internet connection. For example, a treasure could be a small Arduino or similar device with Bluetooth capabilities. They are set in the first lines of the application: This application makes use of the following capabilities: - RequestPlayerProfile: This is very similar to the used in the last application, it requests data from the user, like the username and the avatar that will be shown to another players. This action will call the capability locateCapability. - RequestLocateTreasure: Very similar to the RequestLocatePerson of the last application, but this will show the list of all nearby treasures, so we can pick one to start the hunting. - SendPlayerList: as the name says, this will be the action responsible for sending the scoreboard to all the players. The scoreboard is sent when a new user connects to the application, and each time a user finds a treasure. - SetBluetoothTreasure: similar to SetBluetoothTarget, this action will send special data like position and Bluetooth MAC address of the target treasure. - SendNotification: basic notification to inform the user when something was wrong. For example, when he has already found a treasure. 116 Figure 72. Example of views. The first shows all the nearby treasures, the user should select one of them to start the location. Each treasure shows the distance to the current position of the user. The second figure is an example of the scoreboard. The code of the observer locateTreasure is similar to the locatePerson in the last application, however now we have to check if the user has already found the selected treasure: 117 Finally, the MapTreasureCapabilityActivity will do the same as MapLocateCapabilityActivity, it will check periodically the location of the treasure, giving hints of the orientation and distance. When the treasure is inside the Bluetooth range, the screen will change its color according to the distance. When you are closer enough the treasure (about 2-3 meters), you will get your score, and the possibility to select another treasure to hunt. The scoreboard will be sent to all the players to know you have found a new treasure. Figure 73. Code of the observer foundTreasure. [Figure 73] shows the code of the foundTreasure observer. This observer will give you the corresponding points (5 in this case, but they can be configured). Then, it will ask you to select a new treasure to hunt, and send the scoreboard to all the connecter players. You will see a small animation [see figure at right] giving you the score. This treasure will be automatically disabled for you, so you won’t get your points again. 118 119 Conclusions and future work Social Devices is aimed to increase, facilitate and enrich social interactions between people in various kinds of co-located and face-to-face situations. In this work I have presented the latest platform implementing this concept: OrchestratorJS. This platform allows to create and manage all the devices, capabilities, actions and apps through the website without the need of external tools. Furthermore we have seen how the concept can be integrated with such technologies like Internet of Things and pervasive computing, which are not the main target of the platform, but has a big potential with them. To facilitate the development, the platform is based in the Action-Oriented Programming Model, which offers abstractions for developers that help them to structure pervasive applications. The development of applications is very flexible and modular because the main piece are Actions, a small piece of code which can create a small interaction between some devices. Actions are reusable and easily integrated in any application. In this work I have presented several prototypes of thirds using the People-as-aService concept or related with it. To finish this work, I have developed five study cases which show the potential of the platform. These applications are only small examples, with an important didactical objective, because at the moment of this work there was no documentation about how to start the development in the platform. In the future, the platform could have new features and capabilities, recently the Bluetooth support has been added, and probably GPS support will be a feature soon. Probably in the videogames field this kind of platforms can have an important future, there are two example videogames where users can start the game and invite people in their surroundings to start playing. With the different frameworks and the REST API, the technology can also be extended to many different types of devices. Furthermore the new Bluetooth 4.0 Low Energy can be a perfect solution to avoid the current Bluetooth problems, which make the devices to waste huge amounts of energy when finding or communicating with nearby devices. Without Bluetooth Low Energy won’t be possible the deployment of a technology like Social Devices. 120 121 Conclusiones y trabajo futuro Social Devices está orientado a aumentar, facilitar y enriquecer las interacciones sociales entre las personas de diferentes formas cooperativas en situaciones cara a cara. En este trabajo presento la última plataforma que implementa este concepto: OrchestratorJS. Esta plataforma permite crear y gestionar todos los dispositivos, capacidades, acciones y aplicaciones desde un sitio web sin necesidad de herramientas externas. Además hemos visto como el concepto puede ser integrado con tecnologías como Internet de las Cosas y computación ubicua, que no son el principal objetivo de la plataforma, pero tiene un gran potencial en ellas. Para facilitar el desarrollo, la plataforma está basada en el Modelo de Programación Orientado a Acciones, que ofrece abstracciones que ayudan a estructurar aplicaciones ubicuas. El desarrollo de aplicaciones es muy flexible y modular ya que la pieza principal son las Acciones, un pequeño fragmento de código que capaz de crear una pequeña interacción entre varios dispositivos. Las acciones son reutilizables y fácilmente integrables en cualquier aplicación. En este trabajo he presentado varios prototipos de terceros utilizando el concepto de People-as-a-Service o relacionados con él. Para terminar este trabajo, he desarrollado cinco casos de estudio que muestran el potencial de la plataforma. Estas aplicaciones son sólo pequeños ejemplos, con un importante objetivo didáctico, ya que en el momento de este trabajo no existe documentación sobre cómo empezar a desarrollar para esta plataforma. En un futuro, la plataforma podría tener nuevas características y capacidades, recientemente se ha añadido soporte Bluetooth, y probablemente el soporte GPS será pronto una nueva funcionalidad. Probablemente en el campo de los videojuegos este tipo de plataformas puedan tener un importante futuro, existen dos videojuegos de ejemplo donde los usuarios pueden comenzar a jugar e invitar a personas a su alrededor para jugar juntos. Con los diferentes marcos de trabajo y la API REST, la tecnología puede también extenderse a muchos tipos diferentes de dispositivos. Además la nueva versión de Bluetooth 4.0 de baja energía puede ser la solución perfecta para evitar los problemas del Bluetooth actual, que hace que los dispositivos gasten grandes cantidades de energía cuando buscan o se comunican con los dispositivos cercanos. Sin Bluetooth de baja energía no será posible el despliegue de una tecnología como Social Devices. 122 123 Annex 1: npm modules Due to the amount of problems can appear because there are always new updates of the NodeJS libraries, I have done a dump of all my installed modules in npm. The idea is to keep exactly the same version of all the modules here appear, to avoid any problem. For example, the Sockets.IO library is one of the most problematic libraries, because from version 1.0 it doesn’t offer backward compatibility and the OrchestratorJS Platform won’t work as expected. Here is the set of commands to install npm modules to the right version. At the moment these commands should be enough, but in the future more things could vary. However the way to install old versions would be the same: npm install [email protected] npm install cr[email protected] npm install ej[email protected].5 npm install [email protected] npm install [email protected] npm install [email protected] npm install forever-monit[email protected].3 npm install [email protected] npm install [email protected] npm install [email protected] npm install no[email protected] npm install no[email protected].1 npm install [email protected] npm install passport-loca[email protected] npm install [email protected] npm install socket.i[email protected].16 npm install socket.io-clien[email protected]6 npm install [email protected] To install the required version we only have to specify the name of the module and the desired version, separated with ‘@’. In the next page is the entire dump of npm installed modules. 124 ├── [email protected] ├── [email protected] ├── [email protected] ├─┬ [email protected] │ ├── buffer-[email protected].1 │ ├── command[email protected] │ ├─┬ [email protected] │ │ ├── [email protected] │ │ ├── cooki[email protected] │ │ ├── formi[email protected].14 │ │ ├── [email protected] │ │ ├── [email protected] │ │ └─┬ [email protected] │ │ └── mim[email protected] │ ├── [email protected] │ ├── [email protected] │ ├── [email protected] │ ├── [email protected] │ ├── [email protected] │ ├── [email protected] │ ├── range-p[email protected].4 │ └─┬ [email protected] │ └── [email protected] ├── [email protected] ├─┬ [email protected] │ ├─┬ [email protected] │ │ ├── [email protected] │ │ └─┬ winst[email protected] │ │ ├── asy[email protected] │ │ ├── cyc[email protected] │ │ ├── pkg[email protected].3 │ │ ├── req[email protected].203 │ │ └── [email protected] │ ├── [email protected] │ ├─┬ flatiro[email protected] │ │ ├─┬ broad[email protected] │ │ │ ├── eventemitter[email protected] │ │ │ └─┬ win[email protected].2 │ │ │ ├── a[email protected].22 │ │ │ ├── c[email protected].2 │ │ │ ├── e[email protected] │ │ │ ├── [email protected] │ │ │ ├── [email protected] │ │ │ └── stack-trac[email protected] │ │ ├── direc[email protected]0 │ │ ├─┬ optim[email protected] │ │ │ └── wor[email protected].2 │ │ └─┬ promp[email protected] │ │ ├─┬ rea[email protected] │ │ │ └── mute-strea[email protected] │ │ ├── [email protected] │ │ └─┬ win[email protected].2 │ │ ├── a[email protected].22 │ │ ├── c[email protected].2 │ │ ├── e[email protected] │ │ ├── [email protected] │ │ ├── [email protected] │ │ └── stack-trac[email protected] │ ├─┬ [email protected] │ │ ├─┬ broad[email protected] │ │ │ ├── eventemitter[email protected] │ │ │ ├─┬ nco[email protected] │ │ │ │ ├── a[email protected].9 │ │ │ │ ├── i[email protected] │ │ │ │ └─┬ [email protected] │ │ │ │ ├── [email protected] │ │ │ │ └── [email protected] │ │ │ ├─┬ uti[email protected] │ │ │ │ ├── a[email protected].9 │ │ │ │ ├── [email protected] │ │ │ │ ├── [email protected] │ │ │ │ ├── m[email protected].5 │ │ │ │ ├── n[email protected] │ │ │ │ └── r[email protected].5 │ │ │ └─┬ win[email protected].2 │ │ │ ├── a[email protected].9 │ │ │ ├── c[email protected].2 │ │ │ ├── e[email protected] │ │ │ ├─┬ [email protected] │ │ │ │ ├── [email protected] │ │ │ │ ├── cookie-j[email protected] │ │ │ │ ├── [email protected] │ │ │ │ ├─┬ form-dat[email protected] │ │ │ │ │ └─┬ combined[email protected].4 │ │ │ │ │ └── [email protected] │ │ │ │ ├─┬ [email protected]0.2 │ │ │ │ │ ├── [email protected] │ │ │ │ │ ├── crypti[email protected].3 │ │ │ │ │ ├── [email protected] │ │ │ │ │ └── [email protected] │ │ │ │ ├── json-str[email protected] │ │ │ │ ├── [email protected].11 │ │ │ │ ├── node-uui[email protected] │ │ │ │ ├── oauth-si[email protected] │ │ │ │ ├── [email protected] │ │ │ │ └── tunnel-a[email protected] │ │ │ └── stack-trac[email protected] │ │ ├─┬ minim[email protected].12 │ │ │ ├── [email protected] │ │ │ └── sig[email protected].0 │ │ ├─┬ ps-tr[email protected] │ │ │ └─┬ [email protected] │ │ │ └─┬ [email protected] │ │ │ └── [email protected] │ │ └── [email protected] │ ├─┬ [email protected] │ │ ├── [email protected] │ │ ├── [email protected] │ │ ├─┬ optim[email protected] │ │ │ └── wor[email protected].2 │ │ └── pkgin[email protected] │ ├─┬ nssocke[email protected] │ │ ├── [email protected] │ │ └── [email protected] │ ├─┬ optimis[email protected] │ │ └── wordw[email protected] │ ├── [email protected] │ ├── timespa[email protected]